cnpm k54ca
Objectives
• To introduce software process models
• To describe three generic process models and when
they may be used
– Waterfall, evolutionary, component-based
• To describe outline process models for
– requirements engineering,
– software development,
– testing and evolution
• To explain the Rational Unified Process model
• To introduce CASE tools to support software process
activities
2 Topics covered
• Software process models
• Process iteration
• Process activities
• The Rational Unified Process
• Computer-aided software engineering
3 The software process
• A structured set of activities required to develop a
software system
– Specification;
– Design;
– Validation;
– Evolution.
• A software process model is an abstract
representation of a process.
– A description of a process from some particular
perspective.
4 Generic software process models
• The waterfall model
– Separate and distinct phases of specification and
development.
• Evolutionary development
– Specification, development and validation are interleaved.
• Component-based software engineering
– The system is assembled from existing components.
• There are many variants of these models
– E.g. formal development where a waterfall-like process is
used but the specification is a formal specification that is
refined through several stages to an implementable design.
5 Waterfall model
Requirement
s definition
System and
software
design
Implementation
and unit testing
Integration
and system
testing
Operation and
maintenance
6 Waterfall model phases
• 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. One phase has to be complete before
moving onto the next phase.
7 Waterfall model problems
• Difficult to respond to changing customer
requirements.
– Because of the partitioning of the project into distinct
stages
• Only appropriate when the requirements are well-
understood and changes will be fairly limited during
the development process.
– Few business systems have stable requirements.
• Mostly used for large systems engineering projects
where a system is developed at several sites.
8 Evolutionary development
• Exploratory development
– Objective is to work with customers and to evolve a
final system from an initial outline specification.
• Should start with well-understood requirements and add
new features as proposed by the customer.
• Throw-away prototyping
– Objective is to understand the system requirements.
• Should start with poorly understood requirements to
clarify what is really needed.
9 Evolutionary development
Outline
description
Specification
Development
Validation
Initial version
Intermediate
version
Final version
Concurrent
activities
Intermediate
version
Intermediate
version
10 Evolutionary development
• Problems
– Lack of process visibility;
– Systems are often poorly structured;
– Require special skills
• E.g. In languages for rapid prototyping
• Applicability
– For small or medium-size interactive systems;
– For parts of large systems (e.g. the user interface);
– For short-lifetime systems.
11 Component-based software engineering
• Based on systematic reuse
– Systems are integrated from existing components or
COTS (Commercial-off-the-shelf) systems.
• Process stages
– Component analysis;
– Requirements modification;
– System design with reuse;
– Development and integration.
• This approach is becoming increasingly used as
component standards have emerged.
12 Reuse-oriented development
Requirement
specification
Component
analysis
Requirement
modification
System design
with reuse
Development
and integration
System
validation
13 Process iteration
• System requirements ALWAYS evolve in the
course of a project so process iteration where
earlier stages are reworked is always part of the
process for large systems.
• Iteration can be applied to any of the generic
process models.
• Two (related) approaches
– Incremental delivery;
– Spiral development.
14 Incremental delivery
• Rather than deliver the system as a single delivery,
the development and delivery is broken down into
increments with each increment delivering part of
the required functionality.
• User requirements are prioritised and the highest
priority requirements are included in early
increments.
• Once the development of an increment is started,
the requirements are frozen though requirements for
later increments can continue to evolve.
15 Incremental development
Define outline
requirement
Assign
requirements
to increments
Design system
architecture
Develop
system
increment
Validate
increment
Integrate
increment
Validate
system
Final
system
System incomplete
16 Incremental development 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.
17 Extreme programming
• An approach to development based on the
development and delivery of very small
increments of functionality.
• Relies on constant code improvement, user
involvement in the development team and
pairwise programming.
• More details in the next lecture
18 Spiral development
• Process is represented as a spiral rather than as a
sequence of activities with backtracking.
• Each loop in the spiral represents a phase in the
process.
• No fixed phases such as specification or design -
loops in the spiral are chosen depending on what
is required.
• Risks are explicitly assessed and resolved
throughout the process.
19 Spiral model of the software process
Risk
analysis
Prototype 1
Concept of
Operation
Simulation, models, benchmarks
W/S
requirements
Requirement
validation
Test
design
Product
design
Detailed
design
Code
Unit test
Integration
test
Acceptance
test
Service
Integration and
Test plan
Development
plan
Requirements plan
Life-sycle plan
REVIEW
Determine objective,
alternative and constraints
Evaluate alternatives,
identify, resolve risks
Develop, verify next-level
product Plan next phase
Prototype 2
Prototype 3
Operational
prototype
Risk
analysis
Risk
analysis
Risk
analysis
20 Spiral model sectors
• Objective setting
– Specific objectives for the phase are identified.
• Risk assessment and reduction
– Risks are assessed and activities put in place to reduce
the key risks.
• Development and validation
– A development model for the system is chosen which
can be any of the generic models.
• Planning
– The project is reviewed and the next phase of the spiral
is planned.
21 Process activities
Specification
Design and implementation
Validation
Evolution
22 Software specification
• The process of establishing what services are
required and the constraints on the system’s
operation and development.
• Requirements engineering process
– Feasibility study;
– Requirements elicitation and analysis;
– Requirements specification;
– Requirements validation.
23 The requirements engineering process
Feasibility
study
Requirements
elicitation &
analysis
Requirements
specification
Requirements
validation
Feasibility
report
System
models
User and
system
requirements
Requirements
documents
24 Software design and implementation
• The process of converting the system
specification into an executable system.
• Software design
– Design a software structure that realises the
specification;
• Implementation
– Translate this structure into an executable program;
• The activities of design and implementation are
closely related and may be inter-leaved.
25 Design process activities
• Architectural design
• Abstract specification
• Interface design
• Component design
• Data structure design
• Algorithm design
26 The software design process
27 Structured methods
• Systematic approaches to developing a software
design.
• The design is usually documented as a set of
graphical models.
• Possible models
– Object model;
– Sequence model;
– State transition model;
– Structural model;
– Data-flow model.
28 Programming and debugging
• Translating a design into a program and removing
errors from that program.
• Programming is a personal activity - there is no
generic programming process.
• Programmers carry out some program testing to
discover faults in the program and remove these
faults in the debugging process.
29 Software validation
• Verification and validation (V&V) is intended to
show that a system
– conforms to its specification and
– meets the requirements
of the system customer.
• Involves checking and review processes and
system testing.
– Testing involves executing the system with test cases
that are derived from the specification.
Verification
Validation
30 The testing process
Component
testing
System
testing
Acceptance
testing
31 Testing stages
• Component or unit testing
– Individual components are tested independently;
– Components: functions or objects or coherent
groupings of these entities.
• System testing
– Testing of the system as a whole.
• Acceptance testing
– Testing with customer data to check that the system
meets the customer’s needs.
32 Testing phases
Requirements
specification
System
specification
System design
Detailed
design
Acceptance
test plan
Sybsystem
integration
test plan
System
integration test
plan
Service
Acceptance
test
System
integration
test
Sybsystem
integration
test
Module and
unit code and
test
33 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.
34 System evolution
Define system
requirements
Assess existing
systems
Propose
system
changes
Modify
systems
Existing
systems
New
system
35 The Rational Unified Process
• A modern process model derived from the work
on the UML and associated process.
• Normally described from 3 perspectives
– A dynamic perspective that shows phases over time;
– A static perspective that shows process activities;
– A practive perspective that suggests good practice.
36 RUP phase model
37 RUP phases
• Inception
– Establish the business case
for the system.
• Elaboration
– Develop an understanding of
the problem domain and the
system architecture.
• Construction
– System design, programming
and testing.
• Transition
– Deploy the system in its
operating environment.
38 RUP good practice
• Develop software iteratively
• Manage requirements
• Use component-based architectures
• Visually model software
• Verify software quality
• Control changes to software
39 Static workflows
Workflow Description
Business modelling The business processes are modelled using business use cases.
Requirements Actors who interact with the system are identified and use cases are developed to
model the system requirements.
Analysis and design A design model is created and documented using architectural models, component
models, object models and sequence models.
Implementation The components in the system are implemented and structured into
implementation sub-systems. Automatic code generation from design models helps
accelerate this process.
Test Testing is an iterative process that is carried out in conjunction with
implementation. System testing follows the completion of the implementation.
Deployment A product release is created, distributed to users and installed in their workplace.
Configuration and
change mgnt
This supporting workflow managed changes to the system (see Chapter 29).
Project
management
This supporting workflow manages the system development (see Chapter 5).
Environment This workflow is concerned with making appropriate software tools available to the
software development team.
40 Computer-aided software engineering
• Computer-aided software engineering (CASE) is
software to support software development and
evolution processes.
• Activity automation
– Graphical editors for system model development;
– Data dictionary to manage design entities;
– Graphical UI builder for user interface construction;
– Debuggers to support program fault finding;
– Automated translators to generate new versions of a
program.
41 CASE technology
• CASE technology has led to significant
improvements in the software process.
– However, these are not the order of magnitude
improvements that were once predicted
• Software engineering requires creative thought -
this is not readily automated;
• Software engineering is a team activity
– For large projects, much time is spent in team
interactions.
– CASE technology does not really support these.
42 CASE classification
• Classification helps us understand the different types
of CASE tools and their support for process activities.
• Functional perspective
– Tools are classified according to their specific function.
• Process perspective
– Tools are classified according to process activities that
are supported.
• Integration perspective
– Tools are classified according to their organisation into
integrated units.
43 Functional tool classification
Tool type Examples
Planning tools PERT tools, estimation tools, spreadsheets
Editing tools Text editors, diagram editors, word processors
Change management tools Requirements traceability tools, change control systems
Configuration management
tools
Version management systems, system building tools
Prototyping tools Very high-level languages, user interface generators
Method-support tools Design editors, data dictionaries, code generators
Language-processing tools Compilers, interpreters
Program analysis tools Cross reference generators, static analysers, dynamic
analysers
Testing tools Test data generators, file comparators
Debugging tools Interactive debugging systems
Documentation tools Page layout programs, image editors
Re-engineering tools Cross-reference systems, program re-structuring systems
44 Activity-based tool classification
45 CASE integration
• Tools
– Support individual process tasks such as design
consistency checking, text editing, etc.
• Workbenches
– Support a process phase such as specification or design,
Normally include a number of integrated tools.
• Environments
– Support all or a substantial part of an entire software
process. Normally include several integrated
workbenches.
46 Tools, workbenches, environments
47 Key points
• Software processes are the activities involved in
producing and evolving a software system.
• Software process models are abstract representations of
these processes.
• General activities are specification, design and
implementation, validation and evolution.
• Generic process models describe the organisation of
software processes. Examples include the waterfall
model, evolutionary development and component-based
software engineering.
• Iterative process models describe the software process
as a cycle of activities.
48 Key points
• Requirements engineering is the process of developing a
software specification.
• Design and implementation processes transform the
specification to an executable program.
• Validation involves checking that the system meets to its
specification and user needs.
• Evolution is concerned with modifying the system after it
is in use.
• The Rational Unified Process is a generic process model
that separates activities from phases.
• CASE technology supports software process activities.
49
Key points
• A particular strength of extreme programming is the
development of automated tests before a program
feature is created. All tests must successfully execute
when an increment is integrated into a system.
• The Scrum method is an agile method that provides a
project management framework. It is centred round a
set of sprints, which are fixed time periods when a
system increment is developed.
• Scaling agile methods for large systems is difficult.
Large systems need up-front design and some
documentation.Key points
• To use agile or plan-driven approach depends on
– the type of software being developed,
– the capabilities of the development team and
– the culture of the company developing the system.
• Extreme programming is
– a well-known agile method that integrates practices
such as
• frequent releases of the software,
• continuous software improvement and
• customer participation in the development team.
55 Key points
• Agile methods are incremental development
methods that focus on
– rapid development,
– frequent releases of the software,
– reducing process overheads and
– producing high-quality code.
• They involve the customer directly in the
development process.
54 Tools
• Use online tool
– www.agilebench.com/
– Manage your project using the tool
– Send me the link
• Setup your own one:
– www.agile-tools.net
53 Scaling out to large companies
• Project managers who do not have experience of agile methods may
be reluctant to accept the risk of a new approach.
• Large organizations often have quality procedures and standards that
all projects are expected to follow and, because of their bureaucratic
nature, these are likely to be incompatible with agile methods.
• Agile methods seem to work best when team members have a
relatively high skill level. However, within large organizations, there
are likely to be a wide range of skills and abilities.
• There may be cultural resistance to agile methods, especially in those
organizations that have a long history of using conventional systems
engineering processes.
52 Scaling up to large systems
• For large systems development, it is not possible to focus only on
the code of the system. You need to do more up-front design and
system documentation
• Cross-team communication mechanisms have to be designed and
used. This should involve regular phone and video conferences
between team members and frequent, short electronic meetings
where teams update each other on progress.
• Continuous integration, where the whole system is built every time
any developer checks in a change, is practically impossible.
However, it is essential to maintain frequent system builds and
regular releases of the system.
51 Scaling out and scaling up
• ‘Scaling up’ is concerned with using agile methods for
developing large software systems that cannot be
developed by a small team.
• ‘Scaling out’ is concerned with how agile methods can
be introduced across a large organization with many
years of software development experience.
• When scaling agile methods it is essential to maintain
agile fundamentals
– Flexible planning, frequent system releases, continuous
integration, test-driven development and good team
communications.
50 Large system development
• Large systems and their development processes are
often constrained by external rules and regulations
limiting the way that they can be developed.
• Large systems have a long procurement and
development time.
– It is difficult to maintain coherent teams who know about
the system over that period
• As people move on to other jobs and projects.
• Large systems usually have a diverse set of
stakeholders.
– It is practically impossible to involve all of these different
stakeholders in the development process.
49 Large systems development
• Large systems are usually collections of separate, communicating
systems, where separate teams develop each system.
– Frequently, these teams are working in different places, sometimes in
different time zones.
• Large systems are ‘brownfield systems’, that is they include and
interact with a number of existing systems.
– Many of the system requirements are concerned with this interaction and so
don’t really lend themselves to flexibility and incremental development.
• Where several systems are integrated to create a system, a
significant fraction of the development is concerned with system
configuration rather than original code development.
48 Scaling agile methods
• Agile methods have proved to be successful for
small and medium sized projects that can be
developed by a small co-located team.
• It is sometimes argued that the success of these
methods comes because of improved
communications which is possible when
everyone is working together.
• Scaling up agile methods involves changing these
to cope with larger, longer projects where there
are multiple development teams, perhaps
working in different locations.
47 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.
46 Teamwork in Scrum
• The ‘Scrum master’ is a facilitator who
– arranges daily meetings,
– tracks the backlog of work to be done,
– records decisions,
– measures progress against the backlog and
– communicates with customers and management outside of the team.
• The whole team attends short daily meetings where
– all team members share information,
– describe their progress since the last meeting, problems that have
arisen and what is planned for the following day.
• This means that everyone on the team knows what is going on and,
if problems arise, can re-plan short-term work to cope with them.
45 The Sprint cycle
• 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,
– All communications are 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.
44 The Sprint cycle
• Sprints are fixed length, normally 2–4 weeks.
– They correspond to the development of a release of
the system in XP.
• 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
– Select the features and functionality to be developed
during the sprint.
43 The Scrum process
42
Outline planning
and architectural
design
Project closure
Review
Select
Develop
Assess
Sprint cycle Scrum
• The Scrum approach is a general agile method but its
focus is on managing iterative development rather
than specific agile practices.
• There are three phases in Scrum.
– The initial phase is an outline planning
• 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.
41 Scrum
40 Agile project management
• The principal responsibility of software project
managers is to manage the project
– So that the software is delivered on time and within the
planned budget.
• The standard approach to project management is plan-
driven.
– Managers draw up a plan for the project showing
• what should be delivered,
• when it should be delivered and
• who will work on the development of the project deliverables.
• Agile requires a different approach, adapted to
incremental development and the particular strengths
of agile methods.
39 Advantages of pair programming
• It supports the idea of collective ownership and
responsibility for the system.
– Individuals are not held responsible for problems with the
code.
• Instead, the team has collective responsibility for resolving these
problems.
• It 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.
– Where pair programming and collective ownership are
used, others benefit immediately from the refactoring so
they are likely to support the process.
38 Pair programming
• In pair programming, programmers sit together
at the same workstation to develop the software.
• Pairs are created dynamically so that all team
members work with each other during the
development process.
• The sharing of knowledge that happens during
pair programming is very important
– It reduces the overall risks to a project when team
members leave.
37 Pair programming
• In XP, programmers work in pairs,
– Sitting together to develop code.
– This helps develop common ownership of code
and spreads knowledge across the team.
– It encourages refactoring as the whole team can
benefit from this.
• Measurements suggest that development
productivity with pair programming is similar
to that of two people working independently.
36 XP testing difficulties
• Programmers prefer programming to testing
– Sometimes they take short cuts when writing tests.
• For example, they may write incomplete tests that do not check
for all possible exceptions that may occur.
• Some tests can be very difficult to write incrementally.
– For example, in a complex user interface, it is often
difficult to write unit tests for the code that implements
the ‘display logic’ and workflow between screens.
• It difficult to judge the completeness of a set of tests.
– Although you may have a lot of system tests, your test set
may not provide complete coverage.
35 Test automation
• Test automation means that tests are written as executable
components before the task is implemented
– These testing components should be
• stand-alone,
• simulate the submission of input to be tested
• check that the result meets the output specification.
– An automated test framework (e.g. Junit) is a system that makes
it easy to write executable tests and submit a set of tests for
execution.
• As testing is automated, there is always a set of tests that
can be quickly and easily executed
– Whenever any functionality is added to the system, the tests
can be run and problems that the new code has introduced can
be caught immediately.
34 Test case description for dose checking
33 Customer involvement in testing
• To help develop acceptance tests for the stories that
are to be implemented in the next release of the
system.
• The customer who is part of the team writes tests as
development proceeds.
– All new code is therefore validated to ensure that it is what
the customer needs.
• However, people adopting the customer role have
limited time available and so cannot work full-time
with the development team.
– They may feel that providing the requirements was enough
of a contribution and so may be reluctant to get involved in
the testing process.
32 Test-first development
• Writing tests before code clarifies the
requirements to be implemented.
• Tests are written as programs rather than data
– So that they can be executed automatically.
• The test includes a check that it has executed correctly.
– Usually relies on a testing framework such as Junit.
• All previous and new tests are run automatically
when new functionality is added
– Thus checking that the new functionality has not
introduced errors.
31 Testing in XP
• Testing is central to XP and XP has developed an
approach where the program is tested after
every change has been made.
• XP testing features:
– Test-first development.
– Incremental test development from scenarios.
– User involvement in test development and validation.
– Automated test harnesses are used to run all
component tests each time that a new release is built.
30 Examples of refactoring
• Re-organization of a class hierarchy to remove
duplicate code.
• Tidying up and renaming attributes and
methods to make them easier to understand.
• The replacement of inline code with calls to
methods that have been included in a
program library.
29 Refactoring
• Look for possible software improvements and
make these improvements
– Even where there is no immediate need for them.
– This improves the understandability of the
software
• So reduces the need for documentation.
– Changes are easier to make because the code is
well-structured and clear.
• However, some changes requires architecture refactoring and
this is much more expensive.
28 XP and change
• Conventional wisdom in software engineering
is to design for change.
– It is worth spending time and effort anticipating
changes as this reduces costs later in the life cycle.
• XP, however, maintains that this is not
worthwhile as changes cannot be reliably
anticipated.
– Constant code improvement (refactoring) to make
changes easier.
27 Examples of task cards for prescribing
medication
26 A ‘prescribing medication’ story
25 Requirements scenarios
• In XP, a customer or user is part of the XP team and is
responsible for making decisions on requirements.
• User requirements are expressed as scenarios or user
stories.
– These are written on cards
– The development team break them down into
implementation tasks.
• These tasks are the basis of schedule and cost estimates.
• The customer chooses the stories for inclusion in the
next release
– Based on their priorities and the schedule estimates.
23 User stories
• Template
• Examples
24
"As a <role>, I want <goal/desire> so that <benefit>"
As a customer
representative, I
want to search
for my customers
by their first and
last name.
Starting
Application The
application
begins by
bringing up the
last document
the user was
working with.
The consultant will enter expenses on an
expense form. The consultant will enter items
on the form like expense type, description,
amount, and any comments regarding the
expense. At any time the consultant can do
any of the below options.
(1) Once this is completed the consultant will
“Submit”. If the expense is under fifty
(<50), the expense will go directly to the
system for processes.
(2) In the event the consultant has not
finished entering the expense, the
consultant may want to “Save for later”.
This instance should then be displayed on
a list (queue) for consultant with the
status of “Incomplete”.
(3) In the event the consultant decides to
clear the data and close the form the
consultant will “Cancel and exit”. This
instance will not be saved anywhere. XP practices (b)
22
Pair
programming
Developers work in pairs, checking each other’s work and providing
the support to always do a good job.
Collective
ownership
The pairs of developers work on all areas of the system, so that no
islands of expertise develop and all the developers take responsibility
for all of the code. Anyone can change anything.
Continuous
integration
As soon as the work on a task is complete, it is integrated into the
whole system. After any such integration, all the unit tests in the
system must pass.
Sustainable
pace
Large amounts of overtime are not considered acceptable as the net
effect is often to reduce code quality and medium term productivity
On-site
customer
A representative of the end-user of the system (the customer) should
be available full time for the use of the XP team. In an extreme
programming process, the customer is a member of the development
team and is responsible for bringing system requirements to the
team for implementation. XP practices (a)
21
Principle or
practice
Description
Incremental
planning
Requirements are recorded on story cards and the stories to be included in a
release are determined by the time available and their relative priority. The
developers break these stories into development ‘Tasks’ .
Small releases The minimal useful set of functionality that provides business value is
developed first. Releases of the system are frequent and incrementally add
functionality to the first release.
Simple design Enough design is carried out to meet the current requirements and no more.
Test-first
development
An automated unit test framework is used to write tests for a new piece of
functionality before that functionality itself is implemented.
Refactoring All developers are expected to refactor the code continuously as soon as
possible code improvements are found. This keeps the code simple and
maintainable. XP release cycle
20
Select user
stories for this
release
Break down
stories to
tasks
Plan release
Evaluate
system
Release
software
Develop/
integrate/test
software XP and agile principles
• Incremental development is supported through
small, frequent system releases.
• Customer involvement means full-time customer
engagement with the team.
• People not process
– through pair programming, collective ownership and a
process that avoids long working hours.
• Change supported through regular system releases.
• Maintaining simplicity through constant refactoring
of code.
19 Extreme programming
• Perhaps the best-known and most widely used
agile method.
• 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 two
weeks;
– All tests must be run for every build and the build
is only accepted if tests run successfully.
18 eXtreme Programming
XP
17 What to choose: Agile or Plan-driven?
– Are there cultural or organizational issues that may
affect the system development?
• Traditional engineering organizations have a culture of plan-
based development, as this is the norm in engineering.
– How good are the designers and programmers in the
development team?
• Agile methods require higher skill levels than plan-based
approaches
– in plan-based, programmers simply translate a detailed design
into code
– Is the system subject to external regulation?
• If a system has to be approved by an external regulator,
requiring detailed documentation (for safety) -> plan-based í
suitable.
16 What to choose: Agile or Plan-driven?
– What type of system is being developed?
• Plan-driven approaches is suitable for systems that require a lot of
analysis before implementation
– E.g. real-time system with complex timing requirements.
– What is the expected system lifetime?
• Long-lifetime systems may require more design documentation to
communicate the original intentions of the system developers to the
support team.
– What technologies are available to support system
development?
• Agile methods rely on good tools to keep track of an evolving design
– How is the development team organized?
• If the development team is distributed or if part of the development is
being outsourced, then you may need to develop design documents
to communicate across the development teams.
15 What to choose: Agile or Plan-driven?
• Most projects include elements of plan-driven and agile
processes. Deciding on the balance depends on:
– Is it important to have a very detailed specification and
design before moving to implementation?
• If so, you probably need to use a plan-driven approach.
– Is an incremental delivery strategy realistic?
• If so, consider using agile methods.
– How large is the system that is being developed?
• Agile methods are most effective when the system can be developed
with a small co-located team who can communicate informally.
• For large systems that require larger development teams so a plan-
driven approach may have to be used.
14 Plan-driven and agile specification
13
Requirement
engineering
Design and
implementation
Requirement
engineering
Design and
implementation
Requirement
specification
Plan-based development
Agile development Plan-driven and agile development
• Plan-driven development
– Separate development stages
• 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
– Development activities are inter-leaved
– The outputs are decided through negotiation during
the development process.
12 Agile methods and software maintenance
• Most organizations spend more on maintaining existing
software than they do on new software development.
– So, if agile methods are to be successful, they have to
support maintenance as well as original development.
• Two key issues:
– Are systems that are developed using an agile approach
maintainable?
• Given the emphasis in the development process of minimizing
formal documentation.
– Can agile methods be used effectively for evolving a
system in response to customer change requests?
• Problems may arise if original development team
cannot be maintained.
11 Problems with agile methods
• It can be difficult to keep the interest of
customers who are involved in the process.
• Team members may be unsuited to the intense
involvement that characterises agile methods.
• Prioritising changes can be difficult where there
are multiple stakeholders.
• Maintaining simplicity requires extra work.
• Contracts may be a problem as with other
approaches to iterative development.
10 Agile method applicability
• Product development where a software company is
developing a small or medium-sized product for sale.
• 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.
• Because of their focus on small, tightly-integrated
teams, there are problems in scaling agile methods to
large systems.
9 The principles of agile methods
8
Principle Description
Customer
involvement
Customers should be closely involved throughout the
development process. Their role is to provide and prioritize new
system requirements and to evaluate the iterations of the
system.
Incremental
delivery
The software is developed in increments with the customer
specifying the requirements to be included in each increment.
People not
process
The skills of the development team should be recognized and
exploited. Team members should be left to develop their own
ways of working without prescriptive processes.
Embrace
change
Expect the system requirements to change and so design the
system to accommodate these changes.
Maintain
simplicity
Focus on simplicity in both the software being developed and in
the development process. Wherever possible, actively work to
eliminate complexity from the system. Agile manifesto
• We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
– Individuals and interactions over processes and tools
– Working software over comprehensive documentation
– Customer collaboration over contract negotiation
– Responding to change over following a plan
• That is, while there is value in the items on the
right, we value the items on the left more.
7 Agile aims
• To reduce overheads in the software process
– e.g. by limiting documentation
• To be able to respond quickly to changing
requirements without excessive rework.
6 Agile motivations
• Dissatisfaction with the overheads software
design methods 1990s led to the creation of
agile methods. These methods:
– Focus on the code rather than the design
– Are based on an iterative approach to software
development
– Are intended to deliver working software quickly
and evolve this quickly to meet changing
requirements.
5 Rapid software development
• Rapid software development
– Specification, design and implementation are
inter-leaved
– System is developed as a series of versions with
stakeholders involved in version evaluation
– User interfaces are often developed using an IDE
and graphical toolset.
4 Rapid software development
• Rapid development and delivery is now often
the most important requirement for software
systems
– Businesses operate in a fast–changing
requirement
• It is practically impossible to produce a set of stable
software requirements
– Software has to evolve quickly to reflect changing
business needs.
3 Topics covered
• Agile methods
• Plan-driven and agile development
• Extreme programming
• Agile project management
• Scaling agile methods
2 Software
Engineering
Agile Software
Development
Chapter 3, SE9
1
• Many level of requirements
– A high-level abstract statement of a service
– A system constraint
– A detailed mathematical functional specification.
• Requirements may serve a dual function
– The basis for a bid for a contract
• Therefore must be open to interpretation;
– May be the basis for the contract itself
• Therefore must be defined in detail;
– Both these statements may be called requirements.
Requirements abstraction (Davis)
“If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organisation’s needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both of these documents may be called the requirements document for the system.”
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.
7Definitions and specifications
8
User requirement definition
1. The software must provide a means of representing and accessing
external files created by other tools.
1. The software must provide a means of representing and accessing
external files created by other tools.
1.1. The user should be provided with facilities to define the type of external files.
1.2 Each external file type may be represented as a specification icon on the user’s
display.
1.3 Each external file type may have an associated tool which may be applied to the
file.
1.4 Facilities should be provided for the icon representing an external file type to be
defined by the user.
1.5 When a user selects an icon representing an external file, the effect of that
selection is to apply the tool associated with the type of the external file to the file
represented by the selected icon.
1.1. The user should be provided with facilities to define the type of external files.
1.2 Each external file type may be represented as a specification icon on the user’s
display.
1.3 Each external file type may have an associated tool which may be applied to the
file.
1.4 Facilities should be provided for the icon representing an external file type to be
defined by the user.
1.5 When a user selects an icon representing an external file, the effect of that
selection is to apply the tool associated with the type of the external file to the file
represented by the selected icon.
System requirement specificationRequirements readers
9
User
requirements
User
requirements
System
requirements
System
requirements
Software
design
specification
Software
design
specification
Client managers
System end-users
Client engineers
Contractor managers
System architects
Client managers
System end-users
Client engineers
Contractor managers
System architects
System end-users
Client engineers
System architects
Software developers
System end-users
Client engineers
System architects
Software developers
Client engineers (perhaps)
System architects
Software developers
Client engineers (perhaps)
System architects
Software developersFunctional 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.
• Non-functional requirements
– Constraints on the services or functions offered by the
system
• Such as timing constraints, constraints on the development
process, standards, etc.
• Domain requirements
– Requirements that reflect characteristics of that
application domain.
10Functional 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 but
functional system requirements should describe
the system services in detail.
11The LIBSYS system
• A library system that provides a single interface to
a number of databases of articles in different
libraries.
• Users can search for, download and print these
articles for personal study.
12
What are the functional
and non-functional
requirements?
What are the functional
and non-functional
requirements?Examples of functional requirements
• The user shall be able to search either all of the
initial set of databases or select a subset from it.
• The system shall provide appropriate viewers for
the user to read documents in the document
store.
• Every order shall be allocated a unique identifier
(ORDER_ID) which the user shall be able to copy
to the account’s permanent storage area.
13Requirements imprecision
• Problems arise when requirements are not
precisely stated.
– Ambiguous requirements may be interpreted in
different ways by developers and users.
• Consider the term ‘appropriate viewers’
– User intention - special purpose viewer for each
different document type;
– Developer interpretation - provide a text viewer that
shows the contents of the document.
14Requirements completeness and consistency
• In principle, requirements should be both
complete and consistent.
– Complete: should include descriptions of all facilities
required.
– Consistent: should be no conflicts or contradictions in
the descriptions of the system facilities.
• In practice, it is impossible to produce a complete
and consistent requirements document.
– Very hard to check/detect inconsistencies,
incompleteness
15Non-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 CASE system, programming
language or development method.
• Non-functional requirements may be more critical
than functional requirements.
– If these are not met, the system is useless.
16Non-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.
17Non-functional requirement types
Performance
requir ements
Space
requir ements
Usa bility
requir ements
Ef ficiency
requir ements
Relia bility
requir ements
Porta bility
requir ements
Inter oper a bility
requir ements
Ethical
requir ements
Leg islative
requir ements
Implementa tion
requir ements
Standar ds
requir ements
Deli very
requir ements
Safety
requir ements
Privacy
requir ements
Product
requir ements
Organisational
requir ements
External
requir ements
Non-functional
requir ements
18Non-functional requirements examples
• Product requirement
– 8.1 The user interface for LIBSYS shall be implemented as
simple HTML without frames or Java applets.
• Organisational requirement
– 9.3.2 The system development process and deliverable
documents shall conform to the process and deliverables
defined in XYZCo-SP-STAN-95.
• External requirement
– 7.6.5 The system shall not disclose any personal
information about customers apart from their name and
reference number to the operators of the system.
19Goals and requirements
• Non-functional requirements may be very difficult to
state precisely and imprecise requirements may be
difficult to verify.
– Goal: a general intention of the user
• Such as ease of use.
• Verifiable non-functional requirement
– A statement using some measure that can be objectively
tested.
• Goals are helpful to developers as they convey the
intentions of the system users.
20Examples
• A system goal
– Should be easy to use by experienced controllers and
– should be organised in such a way that user errors are
minimised.
• A verifiable non-functional requirement
– Experienced controllers shall be able to use all the
system functions after a total of two hours training.
– After this training, the average number of errors made
by experienced users shall not exceed two per day.
21Requirements measures
22
Property Measure
Speed Processed transactions/second
User/Event response time
Screen refresh time
Size M Bytes
Number of ROM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systemsRequirements interaction
• Conflicts between different non-functional
requirements are common in complex systems.
23
Speed SecurityDomain requirements
• Derived from the application domain and describe
system characteristics and features that reflect
the domain.
• Domain requirements can be new functional
requirements, constraints on existing
requirements or define specific computations.
• If domain requirements are not satisfied, the
system may be unworkable.
24Library system domain requirements
• There shall be a standard user interface to all
databases which shall be based on the Z39.50
standard.
• Because of copyright restrictions, some
documents must be deleted immediately on
arrival. Depending on the user’s requirements,
these documents will either be printed locally on
the system server for manually forwarding to the
user or routed to a network printer.
25Domain requirements problems
• Understandability
– Requirements are expressed in the language of the
application domain;
• Often not understood by software engineers.
• Implicitness
– Domain specialists understand the area so well that
they do not think of making the domain requirements
explicit.
26Good user requirements
• Should describe functional and non-functional
requirements in such a way that they are
understandable by system users who don’t have
detailed technical knowledge.
• User requirements are defined using natural
language, tables and diagrams as these can be
understood by all users.
27Problems with natural language
• Lack of clarity
– Precision is difficult without making the document
difficult to read.
• Requirements confusion
– Functional and non-functional requirements tend to be
mixed-up.
• Requirements mixture
– Several different requirements may be expressed
together.
28LIBSYS requirement
4..5 LIBSYS shall provide a financial accounting
system that maintains records of all payments
made by users of the system. System managers
may configure this system so that regular users
may receive discounted rates.
29Editor grid requirement
2.6 Grid facilities To assist in the positioning of entities on
a diagram, the user may turn on a grid in either
centimetres or inches, via an option on the control panel.
Initially, the grid is off. The grid may be turned on and off
at any time during an editing session and can be toggled
between inches and centimetres at any time. A grid option
will be provided on the reduce-to-fit view but the number
of grid lines shown will be reduced to avoid filling the
smaller diagram with grid lines.
30Requirement problems
• Database requirements includes both conceptual and
detailed information
– Describes the concept of a financial accounting system that
is to be included in LIBSYS;
– However, it also includes the detail that managers can
configure this system - this is unnecessary at this level.
• Grid requirement mixes three different kinds of
requirement
– Conceptual functional requirement (the need for a grid);
– Non-functional requirement (grid units);
– Non-functional UI requirement (grid switching).
31Structured presentation
32
2.6.1 Grid facilities
The editor shall provide a grid facility where a matrix of horizontal
and vertical lines provide a background to the editor window. This
grid shall be a passive grid where the alignment of entities is the
user's responsibility.
Rationale: A grid helps the user to create a tidy diagram with well-
spaced entities. Although an active grid, where entities 'snap-to' grid
lines can be useful, the positioning is imprecise. The user is the best
person to decide where entities should be positioned.
Specification: ECLIPSE/WS/Tools/DE/FS Section 5.6
Source: Ray Wilson, Glasgow OfficeGuidelines for writing requirements
• Invent a standard format and use it for all
requirements.
• Use language in a consistent way.
– Use shall for mandatory requirements, should for
desirable requirements.
• Use text highlighting to identify key parts of the
requirement.
• Avoid the use of computer jargon.
33System requirements
• More detailed specifications of system functions,
services and constraints than user requirements.
• They are intended to be a basis for designing the
system.
• They may be incorporated into the system
contract.
• System requirements may be defined or
illustrated using system models (Chapter 8).
34Requirements and design
• In principle, requirements should state what the
system should do and the design should describe
how it does this.
• In practice, requirements and design are
inseparable
– A system architecture may be designed to structure
the requirements;
– The system may inter-operate with other systems that
generate design requirements;
– The use of a specific design may be a domain
requirement.
35Problems with NL specification
• Ambiguity
– The readers and writers of the requirement must
interpret the same words in the same way. NL is
naturally ambiguous so this is very difficult.
• Over-flexibility
– The same thing may be said in a number of different
ways in the specification.
• Lack of modularisation
– NL structures are inadequate to structure system
requirements.
36Alternatives to NL specification
37
Notation Description
Structured
natural
language
This approach depends on defining standard
forms or templates to express the requirements
specification.
Design
description
languages
This approach uses a language like a
programming language but with more abstract
features to specify the requirements by defining
an operational model of the system. This
approach is not now widely used although it can
be useful for interface specifications.Alternatives to NL specification (2)
Notation Description
Graphical
notations
A graphical language, supplemented by text annotations is
used to define the functional requirements for the system.
An early example of such a graphical language was SADT.
Now, use-case descriptions and sequence diagrams are
commonly used .
Mathemat
ical
specificati
ons
These are notations based on mathematical concepts such as
finite-state machines or sets. These unambiguous
specifications reduce the arguments between customer and
contractor about system functionality. However, most
customers don’t understand formal specifications and are
reluctant to accept it as a system contract.
38Structured language specifications
• The freedom of the requirements writer is limited
by a predefined template for requirements.
• All requirements are written in a standard way.
• The terminology used in the description may be
limited.
• The advantage is that the most of the
expressiveness of natural language is maintained
but a degree of uniformity is imposed on the
specification.
39Form-based specifications
• Definition of the function or entity.
• Description of inputs and where they come from.
• Description of outputs and where they go to.
• Indication of other entities required.
• Pre and post conditions (if appropriate).
• The side effects (if any) of the function.
40Form-based node specification
41
Insulin Pump/Control Software/SRS/3.3.2
Function Compute insulin dose: Safe sugar level
Description Computes the dose of insulin to be delivered when the current measured sugar level is
in the safe zone between 3 and 7 units.
Inputs Current sugar reading (r2), the previous two readings (r0 and r1)
Source Current sugar reading from sensor. Other readings from memory.
Outputs CompDose – the dose in insulin to be delivered
Destination Main control loop
Action CompDose is zero if the sugar level is stable or falling or if the level is increasing but the
rate of increase is decreasing. If the level is increasing and the rate of increase is
increasing, ...
Requires Two previous readings so that the rate of change of sugar level can be computed.
Pre-condition The insulin reservoir contains at least the maximum allowed single dose of insulin..
Post-condition r0 is replaced by r1 then r1 is replaced by r2
Side-effects NoneTabular specification
• Used to supplement natural language.
• Particularly useful when you have to define a
number of possible alternative courses of action.
42Tabular specification
43
Condition Action
Sugar level falling (r2 < r1) CompDose = 0
Sugar level stable (r2 = r1) CompDose = 0
Sugar level increasing and rate of
increase decreasing ((r2-r1)<(r1-r0))
CompDose = 0
Sugar level increasing and rate of
increase stable or increasing. ((r2-
r1) ≥ (r1-r0))
CompDose = round ((r2-r1)/4)
If rounded result = 0 then
CompDose = MinimumDoseGraphical models
• Graphical models are most useful when you need
to show how state changes or where you need to
describe a sequence of actions.
• Different graphical models are explained in
Chapter 8.
44Sequence diagrams
• These show the sequence of events that take
place during some user interaction with a system.
• You read them from top to bottom to see the
order of the actions that take place.
• Cash withdrawal from an ATM
– Validate card;
– Handle request;
– Complete transaction.
45Sequence diagram of ATM withdrawal
ATM Database
Card
Card number
Card OK
PIN request
PIN
Option menu
<<exception>>
invalid card
Withdraw request
Amount request
Amount
Balance request
Balance
<<exception>>
insufficient cash
Debit (amount)
Debit response
Card
Card removed
Cash
Cash removed
Receipt
Validate card
Handle request
Complete
transaction
46Interface specification
• Most systems must operate with other systems
and the operating interfaces must be specified as
part of the requirements.
• Three types of interface may have to be defined
– Procedural interfaces;
– Data structures that are exchanged;
– Data representations.
• Formal notations are an effective technique for
interface specification.
47PDL interface description
48
interface PrintServer {
// defines an abstract printer server
// requires: interface Printer, interface PrintDoc
// provides: initialize, print, displayPrintQueue,
cancelPrintJob, switchPrinter
void initialize ( Printer p ) ;
void print ( Printer p, PrintDoc d ) ;
void displayPrintQueue ( Printer p ) ;
void cancelPrintJob (Printer p, PrintDoc d) ;
void switchPrinter (Printer p1, Printer p2, PrintDoc d)
;
} //PrintServer
interface PrintServer {
// defines an abstract printer server
// requires: interface Printer, interface PrintDoc
// provides: initialize, print, displayPrintQueue,
cancelPrintJob, switchPrinter
void initialize ( Printer p ) ;
void print ( Printer p, PrintDoc d ) ;
void displayPrintQueue ( Printer p ) ;
void cancelPrintJob (Printer p, PrintDoc d) ;
void switchPrinter (Printer p1, Printer p2, PrintDoc d)
;
} //PrintServerThe requirements document
• The requirements document is the official
statement of what is required of the system
developers.
• Should include both a definition of user
requirements and a specification of the system
requirements.
• It is NOT a design document. As far as possible, it
should set of WHAT the system should do rather
than HOW it should do it
49Users of a requirements document
50
System customers
Specify the requirements and read them to
check that they meet their needs. They
specify changes to the requirements
Specify the requirements and read them to
check that they meet their needs. They
specify changes to the requirements
Managers
Use the requirements documents to plan a
bid for the system and to plan the system
development process
Use the requirements documents to plan a
bid for the system and to plan the system
development process
System engineers Use the requirements to understand what
system is to be developed
Use the requirements to understand what
system is to be developed
System test
engineers
Use the requirements to develop validation
tests for the system
Use the requirements to develop validation
tests for the system
System
maintainance
engineers
Use the requirements to help understand
the system and the relationships between
its parts
Use the requirements to help understand
the system and the relationships between
its partsIEEE requirements standard
• Defines a generic structure for a requirements
document that must be instantiated for each
specific system.
– Introduction.
– General description.
– Specific requirements.
– Appendices.
– Index.
51Requirements document structure
• Preface
• Introduction
• Glossary
• User requirements definition
• System architecture
• System requirements specification
• System models
• System evolution
• Appendices
• Index
52Key points
• Requirements set out what the system should do and
define constraints on its operation and
implementation.
• Functional requirements set out services the system
should provide.
• Non-functional requirements constrain the system
being developed or the development process.
• User requirements are high-level statements of what
the system should do. User requirements should be
written using natural language, tables and diagrams.
53Key points
• System requirements are intended to
communicate the functions that the system
should provide.
• A software requirements document is an agreed
statement of the system requirements.
• The IEEE standard is a useful starting point for
defining more detailed specific requirements
standards.
Requirements engineering processes
• Vary widely depending on
– the application domain,
– the people involved and
– the organisation developing the requirements
• Generic activities common to all processes
– Requirements elicitation
– Requirements analysis
– Requirements validation
– Requirements managementThe requirements engineering process
Feasibility
Study
Requirements
elicitation and
analysis
Requirements
specification
Requirements
validation
Feasibility
report
Feasibility
report
System models System models
User and
system
requirements
User and
system
requirements
Requirements
document
Requirements
documentRequirements engineering
System requirements
specification and modeling
User requirements
specification
Business requirements
specification
Feasibility
study
Prototyping
Reviews
System requirements
document
System
requirements
elicitation
User
requirements
elicitation
Requirements
elicitation
Requirements
elicitation
Requirements
Specification
Requirements
Specification
Requirements
validation
Requirements
validationFeasibility studies
• A short focused study that checks
– If the system contributes to organisational
objectives?
– If the system can be engineered using current
technology and within budget?
– If the system can be integrated with other
systems that are used?Feasibility study implementation
• Based on information assessment (what is required),
information collection and report writing.
• Questions for people in the organisation
– What if the system wasn’t implemented?
– What are current process problems?
– How will the proposed system help?
– What will be the integration problems?
– Is new technology needed? What skills?
– What facilities must be supported by the proposed
system?Elicitation and analysis
• Also called requirements discovery.
• Involves technical staff working with customers to
find out about
– the application domain,
– the services that the system should provide and
– the system’s operational constraints.
• May involve end-users, managers, engineers
involved in maintenance, domain experts, trade
unions, etc.
– These are called stakeholders.Problems of requirements analysis
• 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
– Eg. the business environment change.The requirements spiral
Classification
and
organization
Classification
and
organization
Prioritization
and
negotiation
Prioritization
and
negotiation
Discovery Discovery Documentation DocumentationProcess activities
• Discovery
– Interacting with stakeholders to discover their requirements.
– Domain requirements are also discovered at this stage.
• Classification and organisation
– Groups related requirements and organises them into coherent
clusters.
• Prioritisation and negotiation
– Prioritising requirements and resolving requirements conflicts.
• Documentation
– Requirements are documented and input into the next round of the
spiral.Requirements discovery
• The process of gathering information about
the proposed and existing systems and
distilling the user and system requirements
from this information.
• Sources of information include
documentation, system stakeholders and the
specifications of similar systems.ATM stakeholders
• Bank customers
• Representatives of other banks
• Bank managers
• Counter staff
• Database administrators
• Security managers
• Marketing department
• Hardware and software maintenance engineers
• Banking regulatorsViewpoints
• Viewpoints are a way of structuring the
requirements to represent the perspectives of
different stakeholders.
– Stakeholders may be classified under different
viewpoints.
• This multi-perspective analysis is important as
there is no single correct way to analyse
system requirements.Types of viewpoint
• Interactor viewpoints
– People or other systems that interact directly with the system.
• In an ATM, the customer’s and the account database are interactor
viewpoints.
• Indirect viewpoints
– Stakeholders who do not use the system themselves but
influence the requirements.
• In an ATM, management and security staff are indirect viewpoints.
• Domain viewpoints
– Domain characteristics and constraints that influence the
requirements.
• In an ATM, an example would be standards for inter-bank
communications.Viewpoint identification
• Identify viewpoints using
– Providers and receivers of system services;
– Systems that interact directly with the system being
specified;
– Regulations and standards;
– Sources of business and non-functional requirements.
– Engineers who have to develop and maintain the system;
– Marketing and other business viewpoints.LIBSYS viewpoint hierarchy
Ar ticle
providers
Finance
Library
manager
Library
staff
Users
Interactor Indirect
All VPs
Classification
system
UI
standards
Domain
External Staff Students Cataloguers
System
managersInterviewing
• RE team puts questions to stakeholders about
the system that they use and the system to be
developed.
• There are two types of interview
– Closed interviews where a pre-defined set of
questions are answered.
– Open interviews where there is no pre-defined
agenda and a range of issues are explored with
stakeholders.Interviews in practice
• Normally a mix of closed and open-ended
interviewing.
• Good for getting an overall understanding of what
stakeholders do and how they might interact with
the system.
• Not good for understanding domain requirements
– Requirements engineers cannot understand specific
domain terminology;
– Some domain knowledge is so familiar that people find it
hard to articulate or think that it isn’t worth articulating.Effective interviewers
• Interviewers should be open-minded, willing
to listen to stakeholders and should not have
pre-conceived ideas about the requirements.
• Effective interviewers
– Should prompt the interviewee with a question or
a proposal
– Should not simply expect them to respond to a
question such as ‘what do you want’.Scenarios
• Scenarios are real-life examples of how a
system can be used.
• They 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
finishesLIBSYS scenario (1)
Initial assumption: The user has logged on to the LIBSYS system and has
located the journal containing the copy of the article.
Normal:
•The user selects the article to be copied. He or she is then prompted by the
system to either provide subscriber information for the journal or to indicate
how they will pay for the article. Alternative payment methods are by credit
card or by quoting an organisational account number.
•The user is then asked to fill in a copyright form that maintains details of the
transaction and they then submit this to the LIBSYS system.
•The copyright form is checked and, if OK, the PDF version of the article is
downloaded to the LIBSYS working area on the user’s computer and the user
is informed that it is available. The user is asked to select a printer and a copy
of the article is printed. If the article has been flagged as ‘print-only’ it is
deleted from the user’s system once the user has confirmed that printing is
complete.
Initial assumption: The user has logged on to the LIBSYS system and has
located the journal containing the copy of the article.
Normal:
•The user selects the article to be copied. He or she is then prompted by the
system to either provide subscriber information for the journal or to indicate
how they will pay for the article. Alternative payment methods are by credit
card or by quoting an organisational account number.
•The user is then asked to fill in a copyright form that maintains details of the
transaction and they then submit this to the LIBSYS system.
•The copyright form is checked and, if OK, the PDF version of the article is
downloaded to the LIBSYS working area on the user’s computer and the user
is informed that it is available. The user is asked to select a printer and a copy
of the article is printed. If the article has been flagged as ‘print-only’ it is
deleted from the user’s system once the user has confirmed that printing is
complete.LIBSYS scenario (2)
What can go wrong:
•The user may fail to fill in the copyright form correctly. In this case, the form
should be re-presented to the user for correction. If the resubmitted form is
still incorrect then the user’s request for the article is rejected.
•The payment may be rejected by the system. The user’s request for the
article is rejected.
•The article download may fail. Retry until successful or the user terminates
the session.
•It may not be possible to print the article. If the article is not flagged as
‘print-only’ then it is held in the LIBSYS workspace. Otherwise, the article is
deleted and the user’s account credited with the cost of the article.
Other activities: Simultaneous downloads of other articles.
System state on completion: User is logged on. The downloaded article has
been deleted from LIBSYS workspace if it has been flagged as print-only.
What can go wrong:
•The user may fail to fill in the copyright form correctly. In this case, the form
should be re-presented to the user for correction. If the resubmitted form is
still incorrect then the user’s request for the article is rejected.
•The payment may be rejected by the system. The user’s request for the
article is rejected.
•The article download may fail. Retry until successful or the user terminates
the session.
•It may not be possible to print the article. If the article is not flagged as
‘print-only’ then it is held in the LIBSYS workspace. Otherwise, the article is
deleted and the user’s account credited with the cost of the article.
Other activities: Simultaneous downloads of other articles.
System state on completion: User is logged on. The downloaded article has
been deleted from LIBSYS workspace if it has been flagged as print-only.Use cases
• Use-cases are a scenario based technique in
the UML
– Identify the actors in an interaction and
– Describe the interaction itself.
• A set of use cases should describe all possible
interactions with the system.
• Sequence diagrams may be used to add detail
to use-cases
– Show the sequence of events processing.Article printing use-case
Article printingLIBSYS use cases
Ar ticle printing
Article search
User administration
Supplier Catalogue services
Library
User
Library
StaffArticle printing
User
item:
Article
copyrightF orm:
Form
request
complete
myWorkspace:
Workspace
myPrinter:
Printe r
request
return
copyright OK
deliver
ar ticle OK
send
confirm inform
deletePrint article sequence
User
item:
Article
copyrightF orm:
Form
request
complete
myWorkspace:
Workspace
myPrinter:
Printe r
request
return
copyright OK
deliver
ar ticle OK
send
confirm inform
deleteSocial and organisational factors
• Software systems are used in a social and
organisational context.
– This influences the system requirements.
• Social and organisational factors are not a single
viewpoint but are influences on all viewpoints.
• Good analysts must be sensitive to these factors
– but currently no systematic way to tackle their
analysis Ethnography (nhân chủng học)
• A social scientists 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.Ethnography and prototyping
Ethnographic
analysis
Ethnographic
analysis
Debriefing
meetings
Debriefing
meetings
Focused
ethnography
Focused
ethnography
Prototype
evaluation
Prototype
evaluation
Generic
system
development
Generic
system
development
System
prototyping
System
prototypingScope of ethnography
• Requirements that are derived from the way
that people actually work
– Rather than the way in which process definitions
suggest that they ought to work.
• Requirements that are derived from
cooperation and awareness of other people’s
activities.Requirements validation
• Concerned with demonstrating that the
requirements define the system that the
customer really wants.
• Requirements error costs are high so
validation is very important
– Fixing a requirements error after delivery may
cost up to 100 times the cost of fixing an
implementation error.Requirements checking
• Validity
– Does the system provide the functions which best support the
customer’s needs?
• Consistency
– Are there any requirements conflicts?
• Completeness
– Are all functions required by the customer included?
• Realism
– Can the requirements be implemented given available budget and
technology
• Verifiability
– Can the requirements be checked?Requirements validation techniques
• Requirements reviews
– Systematic manual analysis of the requirements.
• Prototyping
– Using an executable model of the system to check
requirements. (Chapter 17)
• Test-case generation
– Developing tests for requirements to check
testability.Requirements reviews
• Regular reviews should be held while the
requirements definition is being formulated.
• Both client and contractor staff should be
involved in reviews.
• Reviews may be formal (with completed
documents) or informal.
– Good communications between developers,
customers and users can resolve problems at an
early stage.Review checks
• Verifiability
– Is the requirement realistically testable?
• Comprehensibility
– Is the requirement properly understood?
• Traceability
– Is the origin of the requirement clearly stated?
• Adaptability
– Can the requirement be changed without a large
impact on other requirements?Requirements management
• The process of managing changing requirements
– During the requirements engineering process and system
development.
• Requirements are inevitably incomplete and
inconsistent
– New requirements emerge during the process
• Business needs change
• A better understanding of the system is developed
– Different viewpoints have different requirements and
these are often contradictoryRequirements change
• The priority of requirements from different
viewpoints changes during the development
process.
• System customers may specify requirements
from a business perspective that conflict with
end-user requirements.
• The business and technical environment of
the system changes during its development.Requirements evolution
Initial
understanding
of problem
Initial
understanding
of problem
Changed
understanding
of problem
Changed
understanding
of problem
Initial
requirements
Initial
requirements
Changed
requirements
Changed
requirements
TimeEnduring and volatile requirements
• Enduring requirements
– Stable requirements derived from the core activity
of the customer organisation.
• E.g. a hospital will always have doctors, nurses, etc.
May be derived from domain models
• Volatile requirements
– Requirements which change during development
or when the system is in use.
• In a hospital, requirements derived from health-care
policyRequirements classification
Type Description
Mutable Requirements that change because of changes to the
environment in which the organisation is operating. For
example, in hospital systems, the funding of patient care may
change and thus require different treatment information to be
collected.
Emergent Requirements that emerge as the customer's understanding of
the system develops during the system development. The design
process may reveal new emergent requirements.
Consequential
Requirements that result from the introduction of the computer
system. Introducing the computer system may change the
organisations processes and open up new ways of working
which generate new system requirements
Compatibility Requirements that depend on the particular systems or business
processes within an organisation. As these change, the
compatibility requirements on the commissioned or delivered
system may also have to evolve.Requirements management planning
• During the requirements engineering process, you
have to plan:
– Requirements identification
• How requirements are individually identified;
– A change management process
• The process followed when analysing a requirements change;
– Traceability policies
• The amount of information about requirements relationships that
is maintained;
– CASE tool support
• The tool support required to help manage requirements change;Traceability
• Traceability is concerned with the relationships
between requirements, their sources and the system
design
• Source traceability
– Links from requirements to stakeholders who proposed
these requirements;
• Requirements traceability
– Links between dependent requirements;
• Design traceability
– Links from the requirements to the design;A traceability matrix
Req. id 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2
1.1 D R
1.2 D D D
1.3 R R
2.1 R D D
2.2 D
2.3 R D
3.1 R
3.2 RCASE tool support
• Requirements storage
– Requirements should be managed in a secure, managed
data store.
• Change management
– The process of change management is a workflow process
whose stages can be defined and information flow
between these stages partially automated.
• Traceability management
– Automated retrieval of the links between requirements.Requirements change management
• Should apply to all proposed changes to the
requirements.
• Principal stages
– Problem analysis.
• Discuss requirements problem and propose change;
– Change analysis and costing.
• Assess effects of change on other requirements;
– Change implementation.
• Modify requirements document and other documents to reflect
change.Change management
Identified
problem
Problem analysis &
change specification
Problem analysis &
change specification
Change
analysis and
costing
Change
analysis and
costing
Change
implementation
Change
implementation
Revised
requirementsKey points
• The RE process includes
– a feasibility study,
– requirements elicitation and analysis,
• iterative involving domain understanding,
requirements collection, classification, structuring,
prioritisation and validation
– requirements specification and
– requirements management.Key points
• Systems have multiple stakeholders with different
requirements.
• Social and organisation factors influence system
requirements.
• Requirements validation is checking for validity,
consistency, completeness, realism and verifiability.
• Business changes inevitably lead to changing
requirements.
• Requirements management includes planning and
change management.
Objectives
• To explain why the context of a system should
be modelled as part of the RE process
• To describe behavioural modelling, data
modelling and object modelling
• To introduce some of the notations used in
the Unified Modeling Language (UML)
• To show how CASE workbenches support
system modelling
2Content
• Context models
• Behavioural models
• Data models
• Object models
• CASE workbenches
3System modelling
• System modelling helps the analyst to understand
the functionality of the system
– Models are used to communicate with customers.
4Multiple models
• Different models present the system from different
perspectives
– External perspective showing the system’s context or
environment;
• Represent all external entities that may interact with a system.
– Behavioural perspective showing the behaviour of the
system;
• Internal working of system’s elements
– Structural perspective showing the system or data
architecture
• Elements and their relationships
5Model types
• Data processing model showing how the data is
processed at different stages.
• Composition model showing how entities are
composed of other entities.
• Architectural model showing principal sub-systems.
• Classification model showing how entities have
common characteristics.
• Stimulus/response model showing the system’s
reaction to events.
6Context models
• Context models are used to illustrate the
operational context of a system –
– Show what lies outside the system boundaries
– Social and organisational concerns may affect the
decision on where to position system boundaries
7The context of an ATM system
– Does not show physical locations, how they are
connected, how data is moving around..
ATM system ATM system
Account DB Account DB
Usage DB Usage DB
Branch
Accounting
system
Branch
Accounting
system
Branch
counter
system
Branch
counter
system
Security
system
Security
system
Mantainance
system
Mantainance
system
8Process models
• Process models show the overall process and
the processes that are supported by the
system.
• Data flow models may be used to show the
processes and the flow of information from
one process to another.
9Equipment procurement process
Get cost
estimates
Accept
delivery of
equipment
Check
delivered
items
Validate
specifica tion
Specify
equipment
required
Choose
supplier
Place
equipment
order
Install
equipment
Find
suppliers
Supplier
database
Accept
delivered
equipment
Equipment
database
Equipment
spec.
Check ed
spec.
Delivery
note
Delivery
note
Order
notification
Installation
instructions
Installation
acceptance
Equipment
details
Checked and
signed order form
Order
details plus
blank order
form
Spec. +
supplier +
estimate
Supplier list
Equipment
spec.
10Behavioural models
• Used to describe the overall behaviour of a
system
• Two types of behavioural model:
– Data processing models that show how data is
processed as it moves through the system;
– State machine models that show the systems
response to events.
• Both of them are required to describe the
system’s behaviour
11Data-processing models
• Data flow diagrams (DFDs) may be used to model the
system’s data processing.
• These show the processing steps as data flows
through a system.
• DFDs are an intrinsic part of many analysis methods.
– Widely used
• Simple and intuitive notation that customers can
understand.
• Show end-to-end processing of data.
12Example: Order processing DFD
Complete
order form
Complete
order form
Validate
order
Validate
order
Record
order
Record
order
Send to
supplier
Send to
supplier
Adjust available
budget
Adjust available
budget
Order details +
blank order form
Filled form Signed form
Signed form
Checked
and signed
order +
order
notification
Order
file
Order
file
Budget
file
Budget
file
Signed form
Order details Order amount +
account details
13Data flow diagrams
• Model the system from a functional
perspective.
• Tracking and documenting how the data
associated with a process
– Helpful to develop an overall understanding of the
system.
• May be used to show the data exchange
between a system and other systems
14Example: Insulin pump DFD
Blood sugar
sensor
Blood sugar
analysis
Insulin
requirement
computation
Insulin
delivary
controller
Blood
Blood
parameters
Insulin
requirement
Insulin
Blood sugar level
Pup control
commands
Insulin
pump
15State machine models/Statecharts
• Model the behaviour of the system in
response to external and internal events.
– So are often used for modelling real-time systems.
• Show system states as nodes and events as
arcs between these nodes.
– When an event occurs, the system moves from
one state to another.
16Statecharts
• Allow the decomposition of a model into sub-
models (see following slide)
• A brief description of the actions is included
following the ‘do’ in each state
• Can be complemented by tables describing
the states and the stimuli
• Are an integral part of the UML
17Microwave oven statechart
Full power
Enabled
do: operate
oven
Full
power
Half
power
Half
power
F ull
power
Number
Door
open
Door
closed
Door
closed
Door
open
Star t
do: set power
= 600
Half power
do: set power
= 300
Set time
do: get number
exit: set time
Disa bled
Operation
Cancel
Waiting
do: display
time
Waiting
do: display
time
do: display
'Ready'
do: display
'Waiting'
Timer
Timer
18Microwave oven state description
State Description
Waiting The oven is waiting for input. The display shows the current time.
Half power The oven power is set to 300 watts. The display shows ‘Half power’.
Full power The oven power is set to 600 watts. The display shows ‘Full power’.
Set time The cooking time is set to the user’s input value. The display shows the
cooking time selected and is updated as the time is set.
Disabled Oven operation is disabled for safety. Interior oven light is on. Display
shows ‘Not ready’.
Enabled Oven operation is enabled. Interior oven light is off. Display shows ‘Ready
to cook’.
Operation Oven in operation. Interior oven light is on. Display shows the timer
countdown. On completion of cooking, the buzzer is sounded for 5
seconds. Oven light is on. Display shows ‘Cooking complete’ while buzzer
is sounding.
19Microwave oven stimuli
Stimulus Description
Half power The user has pressed the half power button
Full power The user has pressed the full power button
Timer The user has pressed one of the timer buttons
Number The user has pressed a numeric key
Door open The oven door switch is not closed
Door closed The oven door switch is closed
Start The user has pressed the start button
Cancel The user has pressed the cancel button
20Data models
• Used to describe the logical structure of data
processed by the system.
• An entity-relation-attribute model sets out the
entities in the system, the relationships between
these entities and the entity attributes
• Widely used in database design. Can readily be
implemented using relational databases.
• No specific notation provided in the UML but objects
and associations can be used.
21LIBSYS data model
Source
title
publisher
issue
date
pages
1
Article
title
authors
pdf file
fee
has-links
1
Buyer
name
address
billing info
places
fee-payable-to
n
1
n
published-in
delivers
in
m n
1
1
1
Copyright
Agency
name
address
Country
copyright form
tax rate
1
Order
order number
total payment
date
tax status
in
1
22Data dictionaries
• Data dictionaries are lists of all of the names used
– Also include descriptions of the entities, relationships and
attributes
• Advantages
– Support name management and avoid duplication;
– Store of organisational knowledge linking analysis, design
and implementation
• Many CASE workbenches support data dictionaries.
23Data dictionary entries
Name Description Type Date
Article Details of the published article that may be
ordered by people using LIBSYS.
Entity 30.12.2002
authors The names of the authors of the article
who may be due a share of the fee.
Attribute 30.12.2002
Buyer The person or organisation that orders a
copy of the article.
Entity 30.12.2002
fee-
payable-to
A 1:1 relationship between Article and the
Copyright Agency who should be paid the
copyright fee.
Relation 29.12.2002
Address
(Buyer)
The address of the buyer. This is used to
any paper billing information that is
required.
Attribute 31.12.2002
24Object models
• Describe the system in terms of classes and their
associations
• A class is an abstraction over a set of objects with
common attributes and the services (operations)
• Various object models may be produced
– Inheritance models;
– Aggregation models;
– Interaction models.
• UML is an effective standard for object-oriented
modelling
25Object models
• Natural ways of reflecting the real-world
entities manipulated by the system
• More abstract entities are more difficult to
model using this approach
• Class identification is a difficult process
– Requiring a deep understanding of the application
domain
• Classes reflecting domain entities are reusable
across systems
26UML classes notations
• Object classes are
rectangles with the
– name at the top,
– attributes in the middle
section and
– operations in the bottom
section;
• Relationships between
object classes are shown
as lines linking objects;
• Inheritance is referred to
as generalisation
27Inheritance models
• Organise the domain classes into a hierarchy
• Classes at the top of the hierarchy reflect the common
features of all classes
• Classes inherit their attributes and services from super-
classes
– These services may then be specialised as necessary
• Class hierarchy design can be a difficult process if
duplication in different branches is to be avoided
28User class hierarchy
Name
Address
Phone
Reg istration #
Library user
Reg ister ()
De-reg ister ()
Af filiation
Reader
Items on loan
Max. loans
Borrower
Depar tment
Depar tment phone
Staff
Major subject
Home ad dress
Student
29Multiple inheritance
• Allows object classes to inherit from several
super-classes
– Rather than inheriting the attributes and services
from a single parent class
• Can lead to semantic conflicts
– When attributes/services with the same name in
different super-classes have different semantics
• Multiple inheritance makes class hierarchy
reorganisation more complex
30Multiple inheritance
31Object aggregation
• An aggregation model shows how classes that
are collections are composed of other classes.
• Aggregation models are similar to the part-of
relationship in data models.
32Object aggregation example
33Interaction models
• A behavioural model shows the interactions
between objects to produce some particular
system behaviour that is specified as a use-
case.
• In UML to model interaction between objects
use:
– Use sequence diagrams
– Collaboration diagrams
34Sequence diagram example
35Collaboration diagram example
36Structured methods
• Incorporate system modelling as an inherent
part of the method
– For requirement elicitation and analysis
• Define
• a set of models,
• a process for deriving these models, and
• rules and guidelines that should apply to the
models
• Supported by some CASE tools
37Structured method’s weaknesses
• Do not model non-functional system
requirements
• Do not usually include information about
whether a method is appropriate for a given
problem
• May produce too much documentation
• The system models are too detailed and
difficult for users to understand.
38CASE workbenches
• A coherent set of tools that is designed to support
related software process activities such as analysis,
design or testing.
• Analysis and design workbenches support system
modelling during both requirements engineering and
system design.
• These workbenches may support a specific design
method or may provide support for a creating
several different types of system model.
39An analysis and design workbench
40Analysis workbench components
• Diagram editors
• Model analysis and checking tools
• Repository and associated query language
• Data dictionary
• Report definition and generation tools
• Forms definition tools
• Import/export translators
• Code generation tools
41Key points
• A model is an abstract system view. Complementary
types of model provide different system information.
• Context models show the position of a system in its
environment with other systems and processes.
• Data flow models may be used to model the data
processing in a system.
• State machine models model the system’s behaviour
in response to internal or external events
42Key points
• Semantic data models describe the logical structure
of data which is imported to or exported by the
systems.
• Object models describe logical system entities, their
classification and aggregation.
• Sequence models show the interactions between
actors and the system objects that they use.
• Structured methods provide a framework for
developing system models.
Objectives
• To introduce architectural design and to
discuss its importance
• To explain the architectural design decisions
that have to be made
• To introduce three complementary
architectural styles covering organisation,
decomposition and control
• To discuss reference architectures are used to
communicate and compare architectures
1Topics covered
• Architectural design decisions
• System organisation
• Decomposition styles
• Control styles
• Reference architectures
2Software architecture
• Architectural design is the design process for
identifying
– Sub-systems making up a system and
– Framework for sub-system control and communication.
– Output is a description of the software architecture
3Architectural design
• An early stage of the system design process
• Represents the link between specification and
design processes
• Often carried out in parallel with some
specification activities
• It involves identifying major system
components and their communications
4Advantages of architecture
• Stakeholder communication
– Architecture may be used as a focus of discussion
by system stakeholders.
• System analysis
– Means that analysis of whether the system can
meet its non-functional requirements is possible.
• Large-scale reuse
– The architecture may be reusable across a range
of systems.
5Quality attributes
• 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
• Usability, Interoperability, Portability, …
6Performance
Architectural conflicts/trade-offs
• Using large-grain components improves
performance but reduces maintainability
• Introducing redundant data improves availability
but makes security more difficult
• Localising safety-related features usually means
more communication so degraded performance
7
SecuritySystem structuring
• Concerned with decomposing the system into
interacting sub-systems
• The architectural design is normally expressed
as a block diagram presenting an overview of
the system structure
• More specific models showing how sub-
systems share data, are distributed and
interface with each other may also be
developed
8Packing robot control system
9
Object
identification
system
Object
identification
system
Arm controller Arm controller
Gripper
controller
Gripper
controller
Vision system Vision system
Packing
system
Packing
system
Conveyer
controller
Conveyer
controller
Packaging
selection
system
Packaging
selection
systemBox and line diagrams
• Very abstract - they do not show the nature of
component relationships nor the externally
visible properties of the sub-systems
• However, useful for communication with
stakeholders and for project planning
10Architectural design decisions
• Architectural design is a creative process so
the process differs depending on the type of
system being developed
• However, a number of common decisions
span all design processes
11Architectural design decisions
• Is there a generic application architecture that can
be used?
• How will the system be distributed?
• What architectural styles are appropriate?
• What approach will be used to structure the system?
• How will the system be decomposed into modules?
• What control strategy should be used?
• How will the architectural design be evaluated?
• How should the architecture be documented?
12Architecture reuse
• Systems in the same domain often have
similar architectures that reflect domain
concepts
• Application product lines are built around a
core architecture with variants that satisfy
particular customer requirements
• Application architectures are covered in
Chapter 13 and product lines in Chapter 18
13Architectural styles
• The architectural model of a system may conform to
a generic architectural model or style
• An awareness of these styles can simplify the
problem of defining system architectures
• However, most large systems are heterogeneous and
do not follow a single architectural style
– Different styles in different components/sub-systems
14Architectural models
• Used to document an architectural design
• Static structural model that shows the major system
components
• Dynamic process model that shows the process
structure of the system
• Interface model that defines sub-system interfaces.
• Relationships model such as a data-flow model that
shows sub-system relationships
• Distribution model that shows how sub-systems are
distributed across computers
15System organisation
• Reflects the basic strategy that is used to
structure a system
• Three organisational styles are widely used:
– A shared data repository style;
– A shared services and servers style;
– An abstract machine or layered style.
16The repository model
• 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.
17CASE toolset architecture
18
Project repository Project repository
Design
editor
Design
editor
Code
generator
Code
generator
Program
editor
Program
editor
Design
editor
Design
editor
Code
generator
Code
generator
Design
translator
Design
translatorRepository model characteristics
• Advantages
– Efficient way to share large amounts of data;
– Sub-systems need not be concerned with how data is
produced
– Centralised management e.g. backup, security, etc.
– Sharing model is published as the repository schema.
• Disadvantages
– Sub-systems must agree on a repository data model.
Inevitably a compromise;
– Data evolution is difficult and expensive;
– No scope for specific management policies;
– Difficult to distribute efficiently.
19Client-server model
• Distributed system model which shows how
data and processing is distributed across a
range of components
• 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
20Film and picture library
21
Internet Internet
Client 1 Client 1 Client 2 Client 2
Web
server
Film and
photo
info.
Web
server
Film and
photo
info.
Video
server
Film clip
files
Video
server
Film clip
files
Picture
server
Digitalized
photos
Picture
server
Digitalized
photos
Catalog
server
Library
catalog
Catalog
server
Library
catalog
Client 3 Client 3Client-server characteristics
• Advantages
– Distribution of data is straightforward;
– Makes effective use of networked systems.
– May require cheaper hardware;
– Easy to add new servers or upgrade existing servers.
• Disadvantages
– No shared data model so sub-systems use different data
organisation. Data interchange may be inefficient;
– Redundant management in each server;
– No central register of names and services - it may be hard
to find out what servers and services are available.
22Abstract machine (layered) model
• 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.
23Version management system
24
Version Management layer Version Management layer
Object management system layer Object management system layer
Database system layer Database system layer
Operating System layer Operating System layerModular decomposition styles
• Styles of decomposing sub-systems into
modules.
• No rigid distinction between system
organisation and modular decomposition.
25Sub-systems and modules
Sub-system
• A system in its own right
• Operation is independent of
the services provided by
other sub-systems
Module
• A system component
• Provides services to other
components
• Not normally be considered
as a separate system.
26Modular decomposition
• Another structural level where sub-systems are
decomposed into modules
• Two modular decomposition models covered
– An object model
• System is decomposed into interacting objects
– A pipeline or data-flow model
• System is decomposed into functional modules which transform
inputs to outputs
• If possible, decisions about concurrency should be
delayed until modules are implemented
27Object models
• Structure the system into a set of loosely
coupled objects with well-defined interfaces
• Decomposition is identifying object classes,
their attributes and operations
• When implemented, objects are created from
these classes and some control model used to
coordinate object operations
28Invoice processing system
29
issue ()
sendReminder ()
acceptPayment()
sendReceipt ()
invoice#
date
amount
customer
invoice#
date
amount
customer#
invoice#
date
amount
customer#
customer#
name
address
credit period
Customer
Payment
Invoice
ReceiptObject model (dis)advantages
• Advantages
– Loosely coupled so objects implementation can be
modified without affecting other objects
– Close to real-world entities
– OO implementation languages are widely used
• Disadvanages
– Object interface changes may cause problems
– Complex, abstract entities may be hard to
represent as objects
30Function-oriented pipelining
• 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
31Invoice processing system
32
Read
issued
invoices
Identify
payments
Issue
receipts
Find
payments
due
Receipts Receipts
Issue
payment
reminder
Reminder
s
Reminder
s
Invoices Invoices Payments PaymentsPipeline model (dis)advantages
• Advantages
– Supports transformation reuse
– Intuitive organisation for stakeholder
communication
– Easy to add new transformations
– Relatively simple to implement as either a
concurrent or sequential system
• Disadvantages
– Requires a common format for data transfer
– Difficult to support event-based interaction
33Control styles
• Are concerned with the control flow between
sub-systems
• Distinct from the system decomposition model
• Centralised control
– One sub-system has overall responsibility for control
and starts and stops other sub-systems
• Event-based control
– Each sub-system can respond to externally generated
events from other sub-systems or the system’s
environment
34Centralised control
• A control sub-system takes responsibility for
managing the execution of other sub-systems.
• Call-return model
– Top-down subroutine model where control starts at the
top of a subroutine hierarchy and moves downwards.
Applicable to sequential systems.
• Manager model
– Applicable to concurrent systems. One system component
controls the stopping, starting and coordination of other
system processes. Can be implemented in sequential
systems as a case statement.
35Call-return model
36
Main
program
Main
program
Routine 3 Routine 3 Routine 2 Routine 2 Routine 1 Routine 1
Routine 1.1 Routine 1.1 Routine 2.1 Routine 2.1 Routine 3.1 Routine 3.1Real-time system control
37
System
controller
System
controller
user
interface
user
interface
Sensor
processes
Sensor
processes
Actuator
processes
Actuator
processes
Computation
processes
Computation
processes
Fault
handler
Fault
handlerEvent-driven systems
• Driven by externally generated events where the timing of
the event is out with the control of the sub-systems which
process the event
• Two principal event-driven models
– Broadcast models
• An event is broadcast to all sub-systems.
• Any sub-system which can handle the event may do so;
– Interrupt-driven models
• Used in real-time systems where interrupts are detected by an interrupt handler
and passed to some other component for processing.
• Other event driven models include spreadsheets and
production systems
38Broadcast model
• Effective in integrating sub-systems on different computers in
a network.
• Sub-systems register an interest in specific events. When
these occur, control is transferred to the sub-system which
can handle the event.
• Control policy is not embedded in the event and message
handler. Sub-systems decide on events of interest to them.
• However, sub-systems don’t know if or when an event will be
handled.
39Selective broadcasting
40
Event and message handler Event and message handler
Sub-system 1 Sub-system 1 Sub-system 2 Sub-system 2 Sub-system 3 Sub-system 3Interrupt-driven systems
• Used in real-time systems where fast response
to an event is essential.
• There are known interrupt types with a
handler defined for each type.
• Each type is associated with a memory
location and a hardware switch causes
transfer to its handler.
• Allows fast response but complex to program
and difficult to validate.
41Interrupt-driven control
42
Handler
1
Handler
1
Process
1
Process
1
Handler
2
Handler
2
Process
2
Process
2
Handler
3
Handler
3
Process
3
Process
3
Interrupt
vectorReference architectures
• Architectural models may be specific to some
application domain
• Two types of domain-specific model
– Generic models
• Abstractions from a number of real systems
• Encapsulate the principal characteristics of these systems
• Usually bottom-up models
– Reference models
• More abstract, idealised model
• Provide a means of information about that class of system and of
comparing different architectures
• Usually top-down models
43Reference models
• Derived from a study of the application
domain rather than from existing systems
• May be used as a basis for implementation or
to compare different systems
• Act as a standard for evaluation
• Example
– OSI model: a layered model for communication
systems
44OSI reference model
45
Application
Presentation
Session
Transport
Network
Data Link
Physical
Application
Presentation
Session
Transport
Network
Data Link
Physical
Network
Application A Application B
Data Link
Physical
Network
Data Link
Physical
Communication Network Communication NetworkCASE tools reference model
• Data repository services
– Storage and management of data items
• Data integration services
– Managing groups of entities
• Task management services
– Definition and enaction of process models
• Messaging services
– Tool-tool and tool-environment communication
• User interface services
– User interface development
46The ECMA reference model
47
Object Management Services
Data Integration Services
Task Management Services
User Interface Services
Tools
Communication ServicesKey points
• The software architecture is the fundamental
framework for structuring the system
• Architectural design decisions include decisions on
the application architecture, the distribution and the
architectural styles to be used
– Different architectural models such as a structural model,
a control model and a decomposition model may be
developed
• System organisational models include repository
models, client-server models and abstract machine
models
48Key points
• Modular decomposition models include object
models and pipelining models
• Control models include centralised control
and event-driven models
• Reference architectures may be used to
communicate domain-specific architectures
and to assess and compare architectural
designs
49
Software Engineering
User interface designObjectives
• To suggest some general design principles for user
interface design
• To explain different interaction styles and their use
• To explain when to use graphical and textual
information presentation
• To explain the principal activities in the user
interface design process
• To introduce usability attributes and approaches to
system evaluationTopics covered
• Design issues
• The user interface design process
• User analysis
• User interface prototyping
• Interface evaluationThe user interface
• User interfaces should be designed to match
the skills, experience and expectations of its
anticipated users.
• System users often judge a system by its
interface rather than its functionality.
• A poorly designed interface
– can cause a user to make catastrophic errors.
– is the reason why so many software systems are
never used.Human factors in interface design
• Limited short-term memory
– People can instantaneously remember about 7 items of
information.
• If you present more than this, they are more liable to make mistakes.
• People make mistakes
– When people make mistakes and systems go wrong,
inappropriate alarms and messages can increase stress and
hence the likelihood of more mistakes.
• People are different
– People have a wide range of physical capabilities.
• Designers should not just design for their own capabilities.
• People have different interaction preferences
– Some like pictures, some like text.User interface design principles
• UI design must take account of the needs,
experience and capabilities of the system users.
• Designers should
– be aware of people’s physical and mental limitations
• e.g. limited short-term memory
– should recognise that people make mistakes.
• UI design principles underlie interface designs
– although not all principles are applicable to all
designs.User interface design principles
Principle Description
User
familiarity
The interface should use terms and concepts which are
drawn from the experience of the people who will make
most use of the system.
Consistency The interface should be consistent in that, wherever
possible, comparable operations should be activated in the
same way.
Minimal
surprise
Users should never be surprised by the behaviour of a
system.
Recoverability The interface should include mechanisms to allow users to
recover from errors.
User guidance The interface should provide meaningful feedback when
errors occur and provide context-sensitive user help
facilities.
User diversity The interface should provide appropriate interaction
facilities for different types of system user.Design principles
• User familiarity
– The interface should be based on user-oriented terms and
concepts rather than computer concepts.
• Eg., an office system should use concepts such as letters,
documents, folders etc. rather than directories, file identifiers, etc.
• Consistency
– The system should display an appropriate level of
consistency.
• Commands and menus should have the same format, command
punctuation should be similar, etc.
• Minimal surprise
– If a command operates in a known way, the user should be
able to predict the operation of comparable commandsDesign principles
• Recoverability
– The system should provide some resilience to user
errors and allow the user to recover from errors.
• Undo, confirmation of destructive actions, 'soft' deletes, etc.
• User guidance
– Some user guidance such as help systems, on-line
manuals, etc. should be supplied
• User diversity
– Interaction facilities for different types of user should
be supported.
• For example, some users have seeing difficulties and so
larger text should be availableDesign issues in UIs
• Two problems must be addressed
– How should information from the user be
provided to the computer system?
– How should information from the computer
system be presented to the user?
• User interaction and information presentation
may be integrated through a coherent
framework such as a user interface metaphor.Interaction styles
• Direct manipulation
• Menu selection
• Form fill-in
• Command language
• Natural languageInteraction styles
Interaction
style
Main advantages Main disadvantages Application
examples
Direct
manipulation
Fast and intuitive
interaction
Easy to learn
May be hard to implement.
Only suitable where there is a
visual metaphor for tasks and
objects.
Video games
CAD systems
Menu
selection
Avoids user error
Little typing required
Slow for experienced users.
Can become complex if many
menu options.
Most general-
purpose systems
Form fill-in Simple data entry
Easy to learn
Checkable
Takes up a lot of screen space.
Causes problems where user
options do not match the form
fields.
Stock control,
Personal loan
processing
Command
language
Powerful and flexible Hard to learn.
Poor error management.
Operating systems,
Command and
control systems
Natural
language
Accessible to casual
users
Easily extended
Requires more typing.
Natural language understanding
systems are unreliable.
Information
retrieval systemsMultiple user interfaces
Linux operating systems Linux operating systems
X-windows GUI
manager
X-windows GUI
manager
Command
language
interpreter
Command
language
interpreter
Graphical UI
(Gnome/KDE)
Unix shell
interface
(ksh/csh)LIBSYS interaction
• Document search
– Users need to be able to use the search facilities
to find the documents that they need.
• Document request
– Users request that a document be delivered to
their machine or to a server for printing.Web-based interfaces
• Many web-based systems have interfaces
based on web forms
• Form field can be menus, free text input, radio
buttons, etc.
• In the LIBSYS example, users make a choice of
where to search from a menu and type the
search phrase into a free text field.LIBSYS search form
LIBSYS: Search
Choose collection
Keyword or phrase
Search using
Adjacent words
Search Reset Cancel
All
Title
Yes NoInformation presentation
• Concerned with presenting system
information to system users.
• The information may be presented directly
(e.g. text in a word processor) or may be
transformed in some way for presentation
(e.g. in some graphical form)
• The Model-View-Controller approach is a way
of supporting multiple presentations of dataInformation presentation
Display
Information to
be displayed
Information to
be displayed
Presentation
software
Presentation
softwareModel-view-controller
Model methods
Controller methods View methods
User
inputs
view modification
messages
Model edits
Model queries
and updates
Controller state V iew state
Model stateInformation presentation
• Static information
– Initialised at the beginning of a session. It does
not change during the session.
– May be either numeric or textual.
• Dynamic information
– Changes during a session and the changes must
be communicated to the system user.
– May be either numeric or textual.Information display factors
• Is the user interested in precise information or
data relationships?
• How quickly do information values change?
Must the change be indicated immediately?
• Must the user take some action in response to
a change?
• Is there a direct manipulation interface?
• Is the information textual or numeric? Are relative
values important?Alternative information presentations
0
1 000
2 000
3000
4000
J an Feb Mar April May June
J an
2 842
F eb
285 1
Mar
3 164
April
2 789
May
12 73
June
2 83 5Analogue or digital presentation?
• Digital presentation
– Compact - takes up little screen space;
– Precise values can be communicated.
• Analogue presentation
– Easier to get an 'at a glance' impression of a value;
– Possible to show relative values;
– Easier to see exceptional data values.Presentation methods
1
3
4 2
0 10 20
Dial with needle Pie char t Ther mometer Horizontal barDisplaying relative values
0 100 200 300 400 0 25 50 75 100
Pressure TemperatureData visualisation
• Concerned with techniques for displaying large amounts of
information.
• Visualisation can reveal relationships between entities and
trends in the data.
• Possible data visualisations are:
– Weather information collected from a number of sources;
– The state of a telephone network as a linked set of nodes;
– Chemical plant visualised by showing pressures and
temperatures in a linked set of tanks and pipes;
– A model of a molecule displayed in 3 dimensions;
– Web pages displayed as a hyperbolic tree.Colour displays
• Colour adds an extra dimension to an interface
and can help the user understand complex
information structures.
• Colour can be used to highlight exceptional
events.
• Common mistakes in the use of colour in
interface design include:
– The use of colour to communicate meaning;
– The over-use of colour in the display.Colour use guidelines
• Limit the number of colours used and be
conservative in their use.
• Use colour change to show a change in system
status.
• Use colour coding to support the task that
users are trying to perform.
• Use colour coding in a thoughtful and
consistent way.
• Be careful about colour pairings.Error messages
• Error message design is critically important
– Poor error messages can mean that a user
rejects rather than accepts a system.
• Messages should be polite, concise, consistent
and constructive.
• The background and experience of users
should be the determining factor in message
design.Design factors in message wording
Factor Description
Context Wherever possible, the messages generated by the system should reflect the
current user context. As far as is possible, the system should be aware of what the
user is doing and should generate messages that are relevant to their current
activity.
Experience As users become familiar with a system they become irritated by long,
‘meaningful’ messages. However, beginners find it difficult to understand short
terse statements of a problem. You should provide both types of message and
allow the user to control message conciseness.
Skill level Messages should be tailored to the user’s skills as well as their experience.
Messages for the different classes of user may be expressed in different ways
depending on the terminology that is familiar to the reader.
Style Messages should be positive rather than negative. They should use the active
rather than the passive mode of address. They should never be insulting or try to
be funny.
Culture Wherever possible, the designer of messages should be familiar with the culture
of the country where the system is sold. There are distinct cultural differences
between Europe, Asia and America. A suitable message for one culture might be
unacceptable in another.User error
• Assume that a nurse misspells the name of a
patient whose records he is trying to retrieve.
Please type the patient’s name in the box then click OK
MacDonald, R.
Patient’s name
OK CancelGood and bad message design
System oriented error message
User-oriented error message
Patients Help Retry Cancel
R. MacDonalk is not a registered patient
Click on Patients for a list of patients
Click on Retry to re-input the patient’s name
Click on Help for more information
Error #27
Invalid Patient id ?
OK CancelThe UI design process
• UI design is an iterative process involving
close liaisons between users and designers.
• The 3 core activities in this process are:
– User analysis: Understand what the users will do
with the system;
– System prototyping: Develop a series of
prototypes for experiment;
– Interface evaluation: Experiment with these
prototypes with users.The design process
Executable
prototype
Design
prototype
Produce paper-
based design
prototype
Produce
dynamic design
prototype
Evaluate design
with end-users
Implement
final user
inter face
Evaluate design
with end-users
Analyse and
understand
user activitiesUser analysis
• If you don’t understand what the users want
to do with a system, you have no realistic
prospect of designing an effective interface.
• User analyses have to be described in terms
that users and other designers can
understand.
• Scenarios where you describe typical episodes
of use, are one way of describing these
analyses.User interaction scenario
Jane is a student of Religious Studies and is working on an essay
on Indian architecture and how it has been influenced by
religious practices. To help her understand this, she would like
to access some pictures of details on notable buildings but can’t
find anything in her local library.
She approaches the subject librarian to discuss her needs and
he suggests some search terms that might be used. He also
suggests some libraries in New Delhi and London that might
have this material so they log on to the library catalogues and do
some searching using these terms. They find some source
material and place a request for photocopies of the pictures
with architectural detail to be posted directly to Jane.
Jane is a student of Religious Studies and is working on an essay
on Indian architecture and how it has been influenced by
religious practices. To help her understand this, she would like
to access some pictures of details on notable buildings but can’t
find anything in her local library.
She approaches the subject librarian to discuss her needs and
he suggests some search terms that might be used. He also
suggests some libraries in New Delhi and London that might
have this material so they log on to the library catalogues and do
some searching using these terms. They find some source
material and place a request for photocopies of the pictures
with architectural detail to be posted directly to Jane.Requirements from the scenario
• Users may not be aware of appropriate search
terms so need a way of helping them choose
terms.
• Users have to be able to select collections to
search.
• Users need to be able to carry out searches
and request copies of relevant material.Analysis techniques
• Task analysis
– Models the steps involved in completing a task.
• Interviewing and questionnaires
– Asks the users about the work they do.
• Ethnography
– Observes the user at work.Hierarchical task analysis
Retrieve pictures
from remote
libraries
Discover
possible
sources
Establish
search
terms
Search for
pictures
Request
photocopies
of found items
1 2 3 4.
Select
library
Log in to
catalogue
Search for
pictures
Modify
search terms
Record
relevant
items
3.1 3.2 3.3 3.4 3.5
Enter search
terms
Initiate
search
Review
results
3.3.1 3.3.2 3.3.3
do 1, 2,
3 until pictures found, 4
do 3.1, 3.2,
3.3 until pictures found,
3.4 if necessary , 3.5
do 3.3.1, 3.3.2, 3.3.3Interviewing
• Design semi-structured interviews based on
open-ended questions.
• Users can then provide information that they
think is essential; not just information that
you have thought of collecting.
• Group interviews or focus groups allow users
to discuss with each other what they do.Ethnography
• Involves an external observer watching users
at work and questioning them in an
unscripted way about their work.
• Valuable because many user tasks are
intuitive and they find these very difficult to
describe and explain.
• Also helps understand the role of social and
organisational influences on work.Ethnographic records
Air traffic control involves a number of control ‘suites’ where the
suites controlling adjacent sectors of airspace are physically located
next to each other. Flights in a sector are represented by paper strips
that are fitted into wooden racks in an order that reflects their
position in the sector. If there are not enough slots in the rack (i.e.
when the airspace is very busy), controllers spread the strips out on
the desk in front of the rack.
When we were observing controllers, we noticed that controllers
regularly glanced at the strip racks in the adjacent sector. We pointed
this out to them and asked them why they did this. They replied that,
if the adjacent controller has strips on their desk, then this meant that
they would have a lot of flights entering their sector. They therefore
tried to increase the speed of aircraft in the sector to ‘clear space’ for
the incoming aircraft.
Air traffic control involves a number of control ‘suites’ where the
suites controlling adjacent sectors of airspace are physically located
next to each other. Flights in a sector are represented by paper strips
that are fitted into wooden racks in an order that reflects their
position in the sector. If there are not enough slots in the rack (i.e.
when the airspace is very busy), controllers spread the strips out on
the desk in front of the rack.
When we were observing controllers, we noticed that controllers
regularly glanced at the strip racks in the adjacent sector. We pointed
this out to them and asked them why they did this. They replied that,
if the adjacent controller has strips on their desk, then this meant that
they would have a lot of flights entering their sector. They therefore
tried to increase the speed of aircraft in the sector to ‘clear space’ for
the incoming aircraft.Insights from ethnography
• Controllers had to see all flights in a sector.
Therefore, scrolling displays where flights
disappeared off the top or bottom of the
display should be avoided.
• The interface had to have some way of telling
controllers how many flights were in adjacent
sectors so that they could plan their workload.User interface prototyping
• The aim of prototyping is to allow users to
gain direct experience with the interface.
• Without such direct experience, it is
impossible to judge the usability of an
interface.
• Prototyping may be a two-stage process:
– Early in the process, paper prototypes may be
used;
– The design is then refined and increasingly
sophisticated automated prototypes are then
developed.Paper prototyping
• Work through scenarios using sketches of the
interface.
• Use a storyboard to present a series of
interactions with the system.
• Paper prototyping is an effective way of
getting user reactions to a design proposal.Prototyping techniques
• Script-driven prototyping
– Develop a set of scripts and screens using a tool
such as Macromedia Director.
– When the user interacts with these, the screen
changes to the next display.
• Visual programming
– Use a language designed for rapid development
such as Visual Basic. See Chapter 17.
• Internet-based prototyping
– Use a web browser and associated scripts.User interface evaluation
• Some evaluation of a user interface design
should be carried out to assess its suitability.
• Full scale evaluation is very expensive and
impractical for most systems.
• Ideally, an interface should be evaluated
against a usability specification. However, it is
rare for such specifications to be produced.Usability attributes
Attribute Description
Learnability How long does it take a new user to
become productive with the system?
Speed of
operation
How well does the system response match
the user’s work practice?
Robustness How tolerant is the system of user error?
Recoverability How good is the system at recovering from
user errors?
Adaptability How closely is the system tied to a single
model of work?Simple evaluation techniques
• Questionnaires for user feedback.
• Video recording of system use and
subsequent tape evaluation.
• Instrumentation of code to collect information
about facility use and user errors.
• The provision of code in the software to
collect on-line user feedback.Key points
• User interface design principles should help guide
the design of user interfaces.
• Interaction styles include direct manipulation,
menu systems form fill-in, command languages
and natural language.
• Graphical displays should be used to present
trends and approximate values. Digital displays
when precision is required.
• Colour should be used sparingly and consistently.Key points
• The user interface design process involves user
analysis, system prototyping and prototype evaluation.
• The aim of user analysis is to sensitise designers to the
ways in which users actually work.
• UI prototyping should be a staged process with early
paper prototypes used as a basis for automated
prototypes of the interface.
• The goals of UI evaluation are to obtain feedback on
how to improve the interface design and to assess if
the interface meets its usability requirements.
Software Engineering
Software testingObjectives
• Distinctions between validation testing and
defect testing
• Principles of system and component testing
• Strategies for generating system test cases
• Essential characteristics of tool used for test
automationTopics covered
• System testing
• Component testing
• Test case design
• Test automationThe testing process
• Component testing
– Testing of individual program components
– Responsibility of the component developer
– Tests are derived from the developer’s experience
• System testing
– Testing of groups of components integrated to
create a system or sub-system
– The responsibility of an independent testing team
– Tests are based on a system specificationTesting phases
Component testing Component testing System testing System testing
Software developer Independent testing teamDefect testing
• The goal of defect testing is to discover
defects in programs
• A successful defect test is a test which causes
a program to behave in an anomalous way
• Tests show the presence not the absence of
defectsTesting process goals
• Validation testing
– To demonstrate that the software meets its
requirements
– A successful test shows that the system operates as
intended
• Defect testing
– To discover faults or defects in the software where its
behaviour is incorrect
• not in conformance with its specification
– A successful test is a test that makes the system
perform incorrectly
• Exposes a defect in the systemThe software testing process
Design test
cases
Design test
cases
Prepare
test data
Prepare
test data
Run prog
w/ test
data
Run prog
w/ test
data
Prepare
test data
Prepare
test data
Test
cases
Test
cases
Test data Test data
Test
results
Test
results
Test
reports
Test
reportsTesting policies
• Only exhaustive testing can show a program is
free from defects
– However, exhaustive testing is impossible
• Testing policies define the approach to be used in
selecting system tests:
– All functions accessed through menus should be
tested;
– Combinations of functions accessed through the same
menu should be tested;
– Where user input is required, all functions must be
tested with correct and incorrect input.System testing
• Involves integrating components to create a
system or sub-system
• May involve testing an increment to be
delivered to the customer
• Two phases:
– Integration testing - the test team have access to
the system source code. The system is tested as
components are integrated
– Release testing - the test team test the complete
system to be delivered as a black-boxIntegration testing
• Involves building a system from its components
and testing it for problems that arise from
component interactions
• Top-down integration
– Develop the skeleton of the system and populate it
with components
• Bottom-up integration
– Integrate infrastructure components then add
functional components
• To simplify error localisation, systems should be
incrementally integratedIncremental integration testing
T3
T2
T1
T4
T5
A
B
C
D
T2
T1
T3
T4
A
B
C
T1
T2
T3
A
B
T est sequence 1 T est sequence 2 T est sequence 3Testing approaches
• Architectural validation
– Top-down integration testing is better at discovering
errors in the system architecture
• System demonstration
– Top-down integration testing allows a limited
demonstration at an early stage in the development
• Test implementation
– Often easier with bottom-up integration testing
• Test observation
– Problems with both approaches
– Extra code may be required to observe testsRelease testing
• The process of testing a release of a system
that will be distributed to customers
• Primary goal is to increase the supplier’s
confidence that the system meets its
requirements
• Release testing is usually black-box or
functional testing
– Based on the system specification only
– Testers do not have knowledge of the system
implementationBlack-box testing
Ie Input test da ta
Oe Output test r esults
System
Inputs causing
anomalous
beha viour
Outputs w hich r ev eal
the pr esence of
defectsTesting guidelines
• How to reveal defects?
– Choose inputs that force the system to generate
all error messages
– Design inputs that cause buffers to overflow
– Repeat the same input or input series several
times
– Force invalid outputs to be generated
– Force computation results to be too large or too
smallTesting scenario
A student in Scotland is studying American History and has been asked to write
a paper on ‘Frontier mentality in the American West from 1840 to 1880’. To do
this, she needs to find sources from a range of libraries. She logs on to the
LIBSYS system and uses the search facility to discover if she can access original
documents from that time. She discovers sources in various US university
libraries and downloads copies of some of these. However, for one document,
she needs to have confirmation from her university that she is a genuine
student and that use is for non-commercial purposes. The student then uses the
facility in LIBSYS that can request such permission and registers her request. If
granted, the document will be downloaded to the registered library’s server and
printed for her. She receives a message from LIBSYS telling her that she will
receive an e-mail message when the printed document is available for
collection.
A student in Scotland is studying American History and has been asked to write
a paper on ‘Frontier mentality in the American West from 1840 to 1880’. To do
this, she needs to find sources from a range of libraries. She logs on to the
LIBSYS system and uses the search facility to discover if she can access original
documents from that time. She discovers sources in various US university
libraries and downloads copies of some of these. However, for one document,
she needs to have confirmation from her university that she is a genuine
student and that use is for non-commercial purposes. The student then uses the
facility in LIBSYS that can request such permission and registers her request. If
granted, the document will be downloaded to the registered library’s server and
printed for her. She receives a message from LIBSYS telling her that she will
receive an e-mail message when the printed document is available for
collection.System tests
1. Test the login mechanism using correct and incorrect logins to
check that valid users are accepted and invalid users are
rejected.
2. Test the search facility using different queries against known
sources to check that the search mechanism is actually finding
documents.
3. Test the system presentation facility to check that information
about documents is displayed properly.
4. Test the mechanism to request permission for downloading.
5. Test the e-mail response indicating that the downloaded
document is available.
1. Test the login mechanism using correct and incorrect logins to
check that valid users are accepted and invalid users are
rejected.
2. Test the search facility using different queries against known
sources to check that the search mechanism is actually finding
documents.
3. Test the system presentation facility to check that information
about documents is displayed properly.
4. Test the mechanism to request permission for downloading.
5. Test the e-mail response indicating that the downloaded
document is available.Use cases
• Use cases can be a basis for deriving the tests
for a system.
– Help identify operations to be tested
– Help design the required test cases
• From an associated sequence diagram, the
inputs and outputs to be created for the tests
can be identifiedCollect weather data sequence chart
:CommsController
request (repor t)
acknowledge ()
repor t ()
summarise ()
reply (repor t)
acknowledge ()
send (repor t)
:WeatherStation :WeatherDataPerformance testing
• Part of release testing may involve testing the
emergent properties of a system
– Performance, reliability…
• Performance tests usually involve planning a
series of tests where the load is steadily
increased until the system performance
becomes unacceptableStress testing
• Exercises the system beyond its maximum
design load.
– Causes defects to come to light
• Particularly relevant to distributed systems
– exhibit severe degradation as a network becomes
overloadedComponent testing
• Component or unit testing is the process of
testing individual components in isolation
• It is a defect testing process
• Components may be:
– Individual functions or methods within an object;
– Object classes with several attributes and
methods;
– Composite components with defined interfaces
used to access their functionality.Object class testing
• Complete test coverage of a class involves
– Testing all operations associated with an object;
– Setting and interrogating all object attributes;
– Exercising the object in all possible states.
• Inheritance makes it more difficult to design
object class tests as the information to be
tested is not localisedInterface testing
• Objectives are to detect faults due to
interface errors or invalid assumptions about
interfaces
• Particularly important for object-oriented
development as objects are defined by their
interfacesInterface testing
B
C
T est
cases
AInterface types
• Parameter interfaces
– Data passed from one procedure to another
• Shared memory interfaces
– Block of memory is shared between procedures or
functions
• Procedural interfaces
– Sub-system encapsulates a set of procedures to be
called by other sub-systems
• Message passing interfaces
– Sub-systems request services from other sub-systemsInterface errors
• Interface misuse
– E.g. parameters in the wrong order
• Interface misunderstanding
– A calling component embeds incorrect assumptions
about the behaviour of the called component
• Timing errors
– The called and the calling component operate at
different speeds and out-of-date information is
accessedInterface testing guidelines
• Parameters are at the extreme ends of their
ranges
• Always test pointer parameters with null
pointers
• Design tests which cause the component to
fail
• Use stress testing in message passing systems
• In shared memory systems, vary the order in
which components are activatedTest case design
• Involves designing the test cases (inputs and
outputs) used to test the system
• The goal of test case design is to create a set
of tests that are effective in validation and
defect testing
• Design approaches:
– Requirements-based testing;
– Partition testing;
– Structural testing.Requirements based testing
• A general principle of requirements
engineering is that requirements should be
testable
• Requirements-based testing is a validation
testing technique where you consider each
requirement and derive a set of tests for that
requirementPartition testing
• Input data and output results often fall into
different classes where all members of a class
are related.
• Each of these classes is an equivalence
partition or domain where the program
behaves in an equivalent way for each class
member
• Test cases should be chosen from each
partitionEquivalence partitioning
System
Outputs
Invalid inputs V alid inputsEquivalence partitions
Betw een 1 0000 and 99999 Less than 1 0000 More than 99999
9999
10000 50000
100000
99999
Input v alues
Between 4 and 1 0 Less than 4 More than 1 0
3
4 7
11
10
Number of input v aluesSearch routine specification
procedure Search (Key : ELEM ; T: SEQ of ELEM;
Found : in out BOOLEAN; L: in out ELEM_INDEX) ;
Pre-condition
-- the sequence has at least one element
T’FIRST <= T’LAST
Post-condition
-- the element is found and is referenced by L
( Found and T (L) = Key)
or
-- the element is not in the array
( not Found and
not (exists i, T’FIRST >= i <= T’LAST, T (i) = Key ))
procedure Search (Key : ELEM ; T: SEQ of ELEM;
Found : in out BOOLEAN; L: in out ELEM_INDEX) ;
Pre-condition
-- the sequence has at least one element
T’FIRST <= T’LAST
Post-condition
-- the element is found and is referenced by L
( Found and T (L) = Key)
or
-- the element is not in the array
( not Found and
not (exists i, T’FIRST >= i <= T’LAST, T (i) = Key ))Search routine - input partitions
• Inputs which conform to the pre-conditions
• Inputs where a pre-condition does not hold
• Inputs where the key element is a member of
the array
• Inputs where the key element is not a
member of the arrayTesting guidelines (sequences)
• Test software with sequences which have only
a single value
• Use sequences of different sizes in different
tests
• Derive tests so that the first, middle and last
elements of the sequence are accessed
• Test with sequences of zero lengthSearch routine - input partitions
Sequence Element
Single value In sequence
Single value Not in sequence
More than 1 value First element in sequence
More than 1 value Last element in sequence
More than 1 value Middle element in sequence
More than 1 value Not in sequence
Input sequence (T) Key (Key) Output (Found, L)
17 17 true, 1
17 0 false, ??
17, 29, 21, 23 17 true, 1
41, 18, 9, 31, 30, 16, 45 45 true, 7
17, 18, 21, 23, 29, 41, 38 23 true, 4
21, 23, 29, 33, 38 25 false, ??Structural testing
• Sometime called white-box testing
• Derivation of test cases according to program
structure
• Objective is to exercise all program
statements (not all path combinations).Structural testing
Test data Test data
Component
code
Component
code
Test outputs Test outputs
Derives TestsBinary search - equiv. partitions
• Pre-conditions satisfied, key element in array.
• Pre-conditions satisfied, key element not in
array.
• Pre-conditions unsatisfied, key element in array.
• Pre-conditions unsatisfied, key element not in
array.
• Input array has a single value.
• Input array has an even number of values.
• Input array has an odd number of values.Binary search equiv. partitions
Mid-point
Elements < Mid Elements > Mid
Equivalence class boundariesBinary search - test cases
Input array (T) Key (Key) Output (Found, L)
17 17 true, 1
17 0 false, ??
17, 21, 23, 29 17 true, 1
9, 16, 18, 30, 31, 41, 45 45 true, 7
17, 18, 21, 23, 29, 38, 41 23 true, 4
17, 18, 21, 23, 29, 33, 38 21 true, 3
12, 18, 21, 23, 32 23 true, 4
21, 23, 29, 33, 38 25 false, ??Path testing
• The objective of path testing is to ensure that
the set of test cases is such that each path
through the program is executed at least
once.
• The starting point for path testing is a
program flow graph that shows nodes
representing program decisions and arcs
representing the flow of control.
• Statements with conditions are therefore
nodes in the flow graph.Binary search flow graph
elemArray [mid] != key
elemArray [mid] > key elemArray [mid] < key
1
2
3
4
5
6
7
8
9
14 10
11
12 13
bottom > top while bottom <= top bottom > top
elemArray
[mid] = keyIndependent paths
• 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 14
• 1, 2, 3, 4, 5, 14
• 1, 2, 3, 4, 5, 6, 7, 11, 12, 5, …
• 1, 2, 3, 4, 6, 7, 2, 11, 13, 5, …
• Test cases should be derived so that all of
these paths are executed
• A dynamic program analyser may be used to
check that paths have been executedTest automation
• Testing is an expensive process phase.
• Testing workbenches provide a range of tools to reduce the
time required and total testing costs.
• Systems such as Junit support the automatic execution of
tests.
• Most testing workbenches are open systems because testing
needs are organisation-specific.
• They are sometimes difficult to integrate with closed design
and analysis workbenches.
Java PathFinderTesting workbench adaptation
• Scripts may be developed for user interface
simulators and patterns for test data
generators.
• Test outputs may have to be prepared
manually for comparison.
• Special-purpose file comparators may be
developed.Key points
• Testing can show the presence of faults in a
system; it cannot prove there are no remaining
faults.
• Component developers are responsible for
component testing; system testing is the
responsibility of a separate team.
• Integration testing is testing increments of the
system; release testing involves testing a system
to be released to a customer.
• Use experience and guidelines to design test
cases in defect testing.Key points
• Interface testing is designed to discover defects
in the interfaces of composite components.
• Equivalence partitioning is a way of discovering
test cases - all cases in a partition should behave
in the same way.
• Structural analysis relies on analysing a program
and deriving tests from this analysis.
• Test automation reduces testing costs by
supporting the test process with a range of
software tools.
11-ch12
Software Engineering
Verification and ValidationClasswork
• Make a mindmap of highlight or in figure wordsObjectives
• What are software verification and validation?
– Their differences
• Program inspection process and its role in
V&V
• Static analysis as a verification technique
• Cleanroom software development processTopics covered
• Verification and validation planning
• Software inspections
• Automated static analysis
• Cleanroom software developmentVerification vs validation
• Verification:
"Are we building the product right?”
– The software should conform to its specification
• Validation:
"Are we building the right product?”
– The software should do what the user really
requiresThe V&V process
• A whole life-cycle process
– V&V must be applied at each stage in the
software process
• Two principal objectives
– The discovery of defects in a system;
– The assessment of whether or not the system is
useful and useable in an operational situation.V&V goals
• Establish confidence that the software is fit
for purpose
– This does NOT mean completely free of defects
– It must be good enough for its intended use
• the type of use will determine the degree of confidence
that is needed.V&V confidence
• Depends on system’s purpose, user
expectations and marketing environment
– Software function
• The level of confidence depends on how critical the
software is to an organisation
– User expectations
• Users may have low expectations of certain kinds of
software
– Marketing environment
• Getting a product to market early may be more
important than finding defects in the programStatic and dynamic verification
• Software inspections (static verification)
– Concerned with analysis of the static system
representation to discover problems
• May be supplement by tool-based document and code
analysis
• Software testing (dynamic verification)
– Concerned with exercising and observing product
behaviour
• The system is executed with test data and its
operational behaviour is observedStatic and dynamic V&V
Software
inspections
Software
inspections
Requirement
specification
Requirement
specification
High-level
design
High-level
design
Formal
specification
Formal
specification
Detailed
design
Detailed
design Program Program
Program
testing
Software
inspectionsProgram testing
• Can reveal the presence of errors, but NOT
their absence
• The only validation technique for non-
functional requirements
– as the software has to be executed to see how it
behaves
• Should be used in conjunction with static
verification to provide full V&V coverageTypes of testing
• Defect testing (Chapter 23)
– Tests designed to discover system defects
– A successful defect test is one which reveals the
presence of defects in a system
• Validation testing
– Intended to show that the software meets its
requirements.
– A successful test is one that shows that a
requirements has been properly implementedTesting and debugging
• Defect testing and debugging are distinct
processes.
• Verification and validation is concerned with
establishing the existence of defects in a program.
• Debugging is concerned with locating and
repairing these errors.
• Debugging involves formulating a hypothesis
about program behaviour then testing these
hypotheses to find the system error.The debugging process
Locate
error
Locate
error
Design
error
repair
Design
error
repair
Repair
error
Repair
error
Retest
program
Retest
program
Test
cases
Test
cases
Test
cases
Test
cases
Design
spec.
Design
spec.V&V planning
• To get the most out of testing and inspection
processes
• Should start early in the development process.
• The plan should identify the balance between
static verification and testing
• Test planning is about defining standards for
the testing process rather than describing
product testsThe V-model of development
Requirement
specification
System
Specification
System
design
Detail design
Module, unit code and test
Service
Acceptance
test
System
integration
test
Syb-system
integration
test
Acceptance
test plan
Acceptance
test plan
System
integration
test plan
System
integration
test plan
Syb-system
integration
test plan
Syb-system
integration
test planThe structure of a software test plan
• The testing process.
• Requirements traceability.
• Tested items.
• Testing schedule.
• Test recording procedures.
• Hardware and software requirements.
• Constraints.The software test plan
The testing process:
A description of the major phases of the testing process.
Requirements traceability:
Testing should be planned so that all requirements are individually
tested.
Tested items:
The products of the software process that are to be tested should be
specified.
Testing schedule:
Schedule and resource allocation for it.
Test recording procedures:
The results of the tests must be systematically recorded.
Hardware and software requirements:
Software tools required and estimated hardware utilisation.
Constraints:
Constraints affecting the testing process such as staff shortages.
The testing process:
A description of the major phases of the testing process.
Requirements traceability:
Testing should be planned so that all requirements are individually
tested.
Tested items:
The products of the software process that are to be tested should be
specified.
Testing schedule:
Schedule and resource allocation for it.
Test recording procedures:
The results of the tests must be systematically recorded.
Hardware and software requirements:
Software tools required and estimated hardware utilisation.
Constraints:
Constraints affecting the testing process such as staff shortages.Software inspections
• Examining the source representation to discover
anomalies and defects
• Do not require execution of a system
– so may be used before implementation
• They may be applied to any representation of the
system
– Requirements, design, configuration data, test data,..
• Shown to be an effective technique for discovering
program errorsInspection success
• Many different defects may be discovered in a
single inspection.
– In testing, one defect may mask another so
several executions are required.Inspections and testing
• Inspections and testing are complementary
– not opposing verification techniques.
• Both should be used during the V&V process
• Inspections can check conformance with a
specification
– not with the customer’s real requirements
• Cannot check non-functional characteristics
– such as performance, usability, etc.Program inspections
• Formalised approach to document reviews
• Intended explicitly for defect detection (not
correction)
• Defects may be logical errors, anomalies in
the code that might indicate an erroneous
condition
– e.g. an uninitialised variable
– or non-compliance with standards
int f() {
int x;
int y = x * 2;
return y;
}
int f() {
int x;
int y = x * 2;
return y;
}Inspection pre-conditions
• A precise specification must be available
• Team members must be familiar with the
organisation standards
• Syntactically correct code or other system
representations must be available
• An error checklist should be prepared
• Management
– Do not use inspections for staff appraisal
• i.e. finding out who makes mistakesThe inspection process
Planning Planning
Overview Overview
Individual
preparation
Individual
preparation
Inspection
meeting
Inspection
meeting
Rework Rework
Follow-up Follow-upInspection procedure
1. System overview presented to inspection team
2. Code and associated documents are
distributed to inspection team in advance
3. Inspection takes place and discovered errors
are noted
4. Modifications are made to repair discovered
errors
5. Re-inspection may or may not be requiredInspection roles
Author or owner The programmer or designer responsible for producing
the program or document. Responsible for fixing defects
discovered during the inspection process.
Inspector Finds errors, omissions and inconsistencies in programs
and documents. May also identify broader issues that are
outside the scope of the inspection team.
Reader Presents the code or document at an inspection meeting.
Scribe Records the results of the inspection meeting.
Chairman or
moderator
Manages the process and facilitates the inspection.
Reports process results to the Chief moderator.
Chief moderator Responsible for inspection process improvements,
checklist updating, standards development etc.Inspection checklists
• Checklist of common errors
• Error checklists are programming language dependent
– Eg. C++: memory leaks, dangling pointers
• In general, the 'weaker' the type checking, the larger the
checklist
– Java: stronger type checking
– PHP: weaker type checking
• Examples: initialisation, constant naming, loop termination,
array bounds, etc.Inspection rate
• Inspection is an expensive process
– 500 statements/hour during overview
– 90-125 statements/hour can be inspected
• Inspecting 500 lines costs about 40 man/hours
effortAutomated static analysis
• Static analysers are software tools for source
text processing
• They parse the program text to discover
potentially erroneous conditions
– Errors and warnings
• They are very effective as an aid to
inspections
– they are a supplement to but not a replacement
for inspectionsStatic analysis checks
Fault class Static analysis check
Data faults Variables used before initialisation
Variables declared but never used
Variables assigned twice but never used between assignments
Possible array bound violations
Undeclared variables
Control faults Unreachable code
Unconditional branches into loops
Input/output faults Variables output twice with no intervening assignment
Interface faults Parameter type mismatches
Parameter number mismatches
Non-usage of the results of functions
Uncalled functions and procedures
Storage management faults Unassigned pointers
Pointer arithmeticStages of static analysis
• Control flow analysis
– Finds unreachable code
• Data use analysis
– Detects
• Uninitialised variables
• Variables written twice without an intervening use
• Variables declared but never used, etc.
• Interface analysis
– Checks the consistency of methods declarations
and their useStages of static analysis
• Information flow analysis
– Identifies the dependencies of output variables
– Does not detect anomalies itself but highlights
information for code inspection or review
• Path analysis
– Identifies paths through the program and their statements
• Potentially useful in the review process
• Both these stages generate vast amounts of
information. Use with care!LINT static analysis
lint_ex.c(8): warning: c may be used before set
lint_ex.c(8): warning: i may be used before set
printarray: variable # of args. lint_ex.c(2) :: lint_ex.c(8)
printarray, arg. 1 used inconsistently lint_ex.c(2) :: lint_ex.c(8)
printarray, arg. 1 used inconsistently lint_ex.c(2) :: lint_ex.c(9)
printf returns value which is always ignored
lint_ex.c(8): warning: c may be used before set
lint_ex.c(8): warning: i may be used before set
printarray: variable # of args. lint_ex.c(2) :: lint_ex.c(8)
printarray, arg. 1 used inconsistently lint_ex.c(2) :: lint_ex.c(8)
printarray, arg. 1 used inconsistently lint_ex.c(2) :: lint_ex.c(9)
printf returns value which is always ignored
1. #include <stdio.h>
2. printarray (int Anarray) {
3. printf(“%d”,Anarray);
4. }
5. main () {
6. int Anarray[5];
7. int i; char c;
8. printarray (Anarray, i, c);
9. printarray (Anarray) ;
10.}
1. #include <stdio.h>
2. printarray (int Anarray) {
3. printf(“%d”,Anarray);
4. }
5. main () {
6. int Anarray[5];
7. int i; char c;
8. printarray (Anarray, i, c);
9. printarray (Anarray) ;
10.}Use of static analysis
• Particularly valuable for languages that have
weak typing
– Many errors are undetected by the compiler
– Eg. C, C++
• Less cost-effective for languages that have
strong type checking
– Detect many errors during compilation
– Eg. Java, C#Verification and formal methods
• Formal methods can be used when a mathematical
specification of the system is produced
• Involve detailed mathematical analysis of the
specification and develop formal arguments that a
program conforms to its mathematical specificationArguments for formal methods
• Uncover errors at requirement specification
– Producing a mathematical specification requires a
detailed analysis of the requirements
• Can detect implementation errors before
testing
– When the program is analysed alongside the
specificationArguments against formal methods
• Difficult
– Require specialized notations that cannot be
understood by domain experts
• Expensive
– Time and human costs to develop a specification
– Even more expensive to show that a program
meets that specificationCleanroom software development
• Derived from the 'Cleanroom‘ process
in semiconductor fabrication
– The philosophy is defect avoidance
rather than defect removal
• This software development process is based on:
– Incremental development;
– Formal specification;
– Static verification using correctness arguments;
– Statistical testing to determine program reliability.The Cleanroom process
Define
software
increments
Define
software
increments
Construct
structured
program
Construct
structured
program
Formally
verify code
Formally
verify code
Integrate
increment
Integrate
increment
Formal specify
system
Formal specify
system
Develop
operational
profile
Develop
operational
profile
Design
statistical tests
Design
statistical tests
Test integrated
system
Test integrated
system
Error reworkCleanroom process characteristics
• Formal specification
– using a state transition model
• Incremental development
– where the customer prioritises increments
• Structured programming
– limit control and abstraction constructs used in the
program
• Static verification
– using rigorous inspections
• Statistical testing of the system (Ch. 24)Formal specification and inspections
• The state based model is a system specification
• The inspection process checks the program against
this model
• The programming approach is defined so that the
correspondence between the model and the system
is clear
• Mathematical arguments (not proofs) are used to
increase confidence in the inspection processCleanroom process teams
• Specification team
– Responsible for developing and maintaining the system
specification
• Development team
– Responsible for developing and verifying the software
• The software is NOT executed or even compiled during this
process
• Certification team
– Responsible for developing a set of statistical tests to
exercise the software after development
• Reliability growth models used to determine when reliability is
acceptableCleanroom process evaluation
• Impressive results
– Very few discovered faults in delivered systems
• The process is no more expensive than other
approaches
• There were fewer errors than in a 'traditional'
development process
• However, the process is not widely used
– How to transfer it to an environment with less skilled or
less motivated software engineersKey points
• Verification and validation are not the same thing
– Verification shows conformance with specification
– Validation shows that the program meets the customer’s
needs
• Test plans should be drawn up to guide the testing
process
• Static verification techniques involve examination
and analysis of the program for error detection
– Without running itKey points
• Program inspections are very effective in discovering
errors
– Program code is systematically checked by a small team to
locate software faults
• Static analysis tools can discover program anomalies
which may be an indication of faults in the code
• The Cleanroom development process depends on
– incremental development
– static verification
– statistical testing
Software Engineering
Project management
1Objectives
• To explain the main tasks undertaken by project
managers
• To introduce software project management and to
describe its distinctive characteristics
• To discuss project planning and the planning process
• To show how graphical schedule representations are
used by project management
• To discuss the notion of risks and the risk
management process
2Topics covered
• Management activities
• Project planning
• Project scheduling
• Risk management
3Software project management
• Concerned with activities involved in ensuring
that software is delivered
– on time and on schedule and
– in accordance with the requirements of the
organisations developing and procuring the
software.
• Project management is needed because software
development is always subject to budget and
schedule constraints that are set by the
organisation developing the software.
4Software management distinctions
• The product is intangible.
• The product is uniquely flexible.
• Software engineering is not recognized as an
engineering discipline
– with the same status as mechanical, electrical
engineering, etc.
• The software development process is not
standardised.
• Many software projects are 'one-off' projects.
5Management activities
• Proposal writing.
• Project planning and scheduling.
• Project costing.
• Project monitoring and reviews.
• Personnel selection and evaluation.
• Report writing and presentations.
6Management commonalities
• These activities are not peculiar to software
management.
• Many techniques of engineering project
management are equally applicable to software
project management.
• Technically complex engineering systems tend
to suffer from the same problems as software
systems.
7Project staffing
• May not be possible to appoint the ideal people to
work on a project
– Project budget may not allow for the use of highly-paid
staff;
– Staff with the appropriate experience may not be
available;
– An organisation may wish to develop employee skills on
a software project.
• Managers have to work within these constraints
especially when there are shortages of trained staff.
8Project planning
• Probably the most time-consuming project
management activity.
• Continuous activity from initial concept through
to system delivery.
– Plans must be regularly revised as new information
becomes available.
• Various different types of plan may be developed
to support the main software project plan that is
concerned with schedule and budget.
9Types of project plan
Plan Description
Quality plan Describes the quality procedures and standards that
will be used in a project. See Chapter 27.
Validation plan Describes the approach, resources and schedule used
for system validation. See Chapter 22.
Configuration
management plan
Describes the configuration management procedures
and structures to be used. See Chapter 29.
Maintenance plan Predicts the maintenance requirements of the system,
maintenance costs and effort required. See Chapter 21.
Staff development
plan.
Describes how the skills and experience of the project
team members will be developed. See Chapter 25.
10Project planning process
Establish the project constraints
Make initial assessments of the project parameters
Define project milestones and deliverables
while project has not been completed or cancelled loop
Draw up project schedule
Initiate activities according to schedule
Wait ( for a while )
Review project progress
Revise estimates of project parameters
Update the project schedule
Re-negotiate project constraints and deliverables
if ( problems arise ) then
Initiate technical review and possible revision
end if
end loop
11The project plan
• The project plan sets out:
– The resources available to the project;
– The work breakdown;
– A schedule for the work.
12Project plan structure
• Introduction.
• Project organisation.
• Risk analysis.
• Hardware and software resource requirements.
• Work breakdown.
• Project schedule.
• Monitoring and reporting mechanisms.
13Activity organization
• Activities in a project should be organised to
produce tangible outputs for management to
judge progress.
• Milestones are the end-point of a process
activity.
• Deliverables are project results delivered to
customers.
• The waterfall process allows for the
straightforward definition of progress
milestones.
14Milestones in the RE process
Activities
Milestones
Feasibility
study
Feasibility
study
Feasibility
report
Feasibility
report
Requirement
analysis
Requirement
analysis
User
requirements
User
requirements
Prototype
development
Prototype
development
Evaluation
report
Evaluation
report
Design study Design study
Architecture
design
Architecture
design
Requirement
specification
Requirement
specification
System
requirements
System
requirements
15Project scheduling
• Split project into tasks and estimate time and
resources required to complete each task.
• Organize tasks concurrently to make optimal
use of workforce.
• Minimize task dependencies to avoid delays
caused by one task waiting for another to
complete.
• Dependent on project managers intuition and
experience.
16The project scheduling process
Identify
activities
Identify
activities
Identify activity
dependencies
Identify activity
dependencies
Estimate
resource
for
activities
Estimate
resource
for
activities
Allocate
people to
activities
Allocate
people to
activities
Create
project
charts
Create
project
charts
Activity
charts and
bar charts
Software
requiremen
ts
Software
requiremen
ts
17Scheduling problems
• Estimating the difficulty of problems and hence
the cost of developing a solution is hard.
• Productivity is not proportional to the number of
people working on a task.
• Adding people to a late project makes it later
because of communication overheads.
• The unexpected always happens. Always allow
contingency in planning.
18Bar charts and activity networks
• Graphical notations used to illustrate the project
schedule.
• Show project breakdown into tasks. Tasks should
not be too small. They should take about a week
or two.
• Activity charts show task dependencies and the
the critical path.
• Bar charts show schedule against calendar time.
19Task durations and dependencies
Activity Duration (days) Dependencies
T1 8
T2 15
T3 15 T1 (M1)
T4 10
T5 10 T2, T4 (M2)
T6 5 T1, T2 (M3)
T7 20 T1 (M1)
T8 25 T4 (M5)
T9 15 T3, T6 (M4)
T10 15 T5, T7 (M7)
T11 7 T9 (M6)
T12 10 T11 (M8)
20Activity network
21Activity timeline
22Staff allocation
23Risk management
• Risk management is concerned with identifying
risks and drawing up plans to minimise their
effect on a project.
• A risk is a probability that some adverse
circumstance will occur
– Project risks affect schedule or resources;
– Product risks affect the quality or performance of
the software being developed;
– Business risks affect the organisation developing or
procuring the software.
24Software risks
Risk Affects Description
Staff turnover Project Experienced staff will leave the project before it is finished.
Management
change
Project There will be a change of organisational management with
different priorities.
Hardware
unavailability
Project Hardware that is essential for the project will not be delivered
on schedule.
Requirements
change
Project and
product
There will be a larger number of changes to the requirements
than anticipated.
Specification
delays
Project and
product
Specifications of essential interfaces are not available on
schedule
Size
underestimate
Project and
product
The size of the system has been underestimated.
CASE tool under-
performance
Product CASE tools which support the project do not perform as
anticipated
Technology
change
Business The underlying technology on which the system is built is
superseded by new technology.
Product
competition
Business A competitive product is marketed before the system is
completed. 25The risk management process
• Risk identification
– Identify project, product and business risks;
• Risk analysis
– Assess the likelihood and consequences of these
risks;
• Risk planning
– Draw up plans to avoid or minimise the effects of
the risk;
• Risk monitoring
– Monitor the risks throughout the project;
26The risk management process
Risk
identification
Risk
identification
List of potential
risks
List of potential
risks
Risk analysis Risk analysis
Prioritised risk
list
Prioritised risk
list
Risk planning Risk planning
Risk avoidance
plans
Risk avoidance
plans
Risk
monitoring
Risk
monitoring
Risk
assessment
Risk
assessment
27Risk identification
• Technology risks.
• People risks.
• Organisational risks.
• Requirements risks.
• Estimation risks.
28Risks and risk types
Risk type Possible risks
Technology The database used in the system cannot process as many transactions per second
as expected.
Software components that should be reused contain defects that l imit their
functionality.
People It is impossible to recruit staff with the skills required.
Key staff are ill and unavailable at critical times.
Required training for staff is not available.
Organisational The organisation is restructured so that different management are responsible for
the project.
Organisational financial problems force reductions in the project budget.
Tools The code generated by CASE tools is inefficient.
CASE tools cannot be integrated.
Requirements Changes to requirements that require major design rework are proposed.
Customers fail to understand the impact of requirements changes.
Estimation The time required to develop the software is underestimated.
The rate of defect repair is underestimated.
The size of the software is underestimated.
29Risk analysis
• Assess probability and seriousness of each risk.
• Probability may be very low, low, moderate, high
or very high.
• Risk effects might be catastrophic, serious,
tolerable or insignificant.
30Risk analysis (i)
Risk Probability Effects
Organisational financial problems force
reductions in the project budget.
Low Catastrophic
It is impossible to recruit staff with the skills
required for the project.
High Catastrophic
Key staff are ill at critical times in the project. Moderate Serious
Software components that should be reused
contain defects which limit their functionality.
Moderate Serious
Changes to requirements that require major
design rework are proposed.
Moderate Serious
The organisation is restructured so that
different management are responsible for the
project.
High Serious
31Risk analysis (ii)
Risk Probability Effects
The database used in the system cannot process
as many transactions per second as expected.
Moderate Serious
The time required to develop the software is
underestimated.
High Serious
CASE tools cannot be integrated. High Tolerable
Customers fail to understand the impact of
requirements changes.
Moderate Tolerable
Required training for staff is not available. Moderate Tolerable
The rate of defect repair is underestimated. Moderate Tolerable
The size of the software is underestimated. High Tolerable
The code generated by CASE tools is inefficient. Moderate Insignificant
32Risk planning
• Consider each risk and develop a strategy to
manage that risk.
• Avoidance strategies
– The probability that the risk will arise is reduced;
• Minimisation strategies
– The impact of the risk on the project or product will
be reduced;
• Contingency plans
– If the risk arises, contingency plans are plans to deal
with that risk;
33Risk management strategies (i)
Risk Strategy
Organisational
financial
problems
Prepare a briefing document for senior
management showing how the project is making a
very important contribution to the goals of the
business.
Recruitment
problems
Alert customer of potential difficulties and the
possibility of delays, investigate buying-in
components.
Staff illness Reorganise team so that there is more overlap of
work and people therefore understand each
other’s jobs.
Defective
components
Replace potentially defective components with
bought-in components of known reliability. 34Risk management strategies (ii)
Risk Strategy
Requirements
changes
Derive traceability information to assess
requirements change impact, maximise
information hiding in the design.
Organisational
restructuring
Prepare a briefing document for senior
management showing how the project is making
a very important contribution to the goals of the
business.
Database
performance
Investigate the possibility of buying a higher-
performance database.
Underestimated
development time
Investigate buying in components, investigate
use of a program generator
35Risk monitoring
• Assess each identified risks regularly to decide
whether or not it is becoming less or more
probable.
• Also assess whether the effects of the risk have
changed.
• Each key risk should be discussed at management
progress meetings.
36Risk indicators
Risk type Potential indicators
Technology Late delivery of hardware or support software, many
reported technology problems
People Poor staff morale, poor relationships amongst team
member, job availability
Organisational Organisational gossip, lack of action by senior
management
Tools Reluctance by team members to use tools, complaints
about CASE tools, demands for higher-powered
workstations
Requirements Many requirements change requests, customer complaints
Estimation Failure to meet agreed schedule, failure to clear reported
defects 37Key points
• Good project management is essential for project
success.
• The intangible nature of software causes
problems for management.
• Managers have diverse roles but their most
significant activities are planning, estimating and
scheduling.
• Planning and estimating are iterative processes
which continue throughout the course of a
project.
38Key points
• A project milestone is a predictable state
– where a formal report of progress is presented to
management.
• Project scheduling involves preparing various
graphical representations showing project
activities, their durations and staffing.
• Risk management is concerned with
– identifying risks which may affect the project and
– planning to ensure that these risks do not develop
into major threats.
39
Bạn đang đọc truyện trên: Truyen4U.Com