Chapter 17/16.4
Rapid Software Development /
Prototyping
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 1
Objectives



To explain how an iterative, incremental
development process can lead to faster
delivery of more useful software
To discuss the essence of agile development methods
To explain the principles and practices of
extreme programming
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 2
Objectives (cont'd)


To explain the roles of prototyping in the
software process
To explain the need for user interface
prototyping. (16.4)
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 3
Topics covered

Rapid Software Development

Agile methods

Extreme programming


Other rapid development approaches:
RAD, visual programming, software
reuse
Software prototyping
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 4
Rationale for rapid software
development



Quickly changing global markets mean
businesses must be responsive to new
opportunities and competition.
Thus, rapid development and delivery is
often the most critical requirement.
Businesses may even be willing to accept
lower quality if rapid delivery of essential
functionality is possible.
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 5
Requirements instability


Being responsive to changing environments
= coping with unstable requirements.
In many such cases:
 a waterfall model of development is
impractical
 evolutionary development based on
iterative specification and delivery is the
only way to deliver software quickly.
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 6
Characteristics of rapid
development processes



Processes of specification, design and
implementation are concurrent.
No detailed specification and design
documentation is minimal.
System may be developed as a series of
increments. (Users evaluate increments
and make proposals for later increments.)
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 7
Recall Mills “incremental
development” process (Ch. 4)
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 8
Advantages of incremental
development

Accelerated delivery of high-priority
customer services.
 Each increment incorporates the (next)
highest priority functionality.

More user involvement in development.
 System is more likely to meet requirements
and users are more committed to system
success.
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 9
Problems with iterative development /
incremental delivery

Management problems
 Progress can be hard to assess (lack of
regular deliverables). poor process visibility
 May require unfamiliar technologies or
special skills.

Contractual problems
 Normal contractual model requires a
requirements specification.
(Cont’d)
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 10
Problems with iterative development /
incremental delivery (cont'd)

V&V problems
 Without a specification, what is the system
being tested against?

Maintenance problems
 Continual change tends to corrupt software
structure.
 Documentation is lacking.

And recall: it may be difficult to partition
requirements into stand-alone increments.
(Cont’d)
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 11
Problems with iterative development /
incremental delivery (cont'd)

For some large systems, evolutionary /
incremental development may be
impractical…

when multiple teams are working at
different sites

when high reliability or safety is required

when maintainability is paramount
(Cont’d)
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 12
Problems with iterative development /
incremental delivery (cont'd)



In such cases, throw-away prototyping,
where an experimental system is
developed as a basis for formulating
the requirements may be used.
This system is “thrown away” when the
requirements have been validated.
We consider throw-away and other types
of prototyping in detail later…
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 13
Agile methods for evolutionary /
incremental development

Dissatisfaction with overhead of waterfall
method led to creation of agile methods.
They:
 Focus on code rather than the design;
 Are based on an iterative development;
 Are intended to deliver working software
quickly which can evolve quickly to meet
changing requirements.
See: www.agilealliance.org
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 14
Principles of agile methods
P rinc ip le
D escrip tio n
C us tom er in vo lv em en t
T h e c us to m e r s h ou ld b e c losely inv olve d t hrou gh ou t the
d eve lopm en t p ro ce ss. T he ir ro le is p ro vide an d p rioritise n ew
system req u irem en ts a nd to ev alu at e th e iterat ions of t he s ystem .
Inc rem en tal d el ive ry
T h e softw are is de ve lop ed in in crem en ts w it h t he c ustom er
spe cifying th e req uire me nt s to be in cl u de d i n e ach i n cr e m e nt.
P eo pl e no t pr oc e ss
T h e skills of t he de v el o pm en t tea m sh ou ld b e rec o gn ised a n d
ex ploi ted . T h e t e am sho uld be le ft to de v elo p the ir own w a ys of
w orking w it h ou t pr escrip tiv e p ro ce sses.
E m brac e c h an g e
E x pec t th e sys tem re q uirem en ts to ch an g e a nd de sign th e sys tem
so th at it c an acc om m o da te th es e c h an g es.
M a in tain sim pl ici ty
F oc us o n sim plic ity in bo th th e so ftw a re be ing d eve lop ed a n d in
th e d ev el o pm en t pr oce ss used . W he re v er p ossib le , ac tiv ely w ork
to elim in at e com pl e xity from the s ystem .
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 15
Problems with agile methods



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 characterizes
agile methods.
Prioritizing changes can be difficult
where there are multiple stakeholders.
(Cont’d)
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 16
Problems with agile methods
(cont'd)


Maintaining simplicity requires extra
work.
Contracts may be a problem as with
other iterative development approaches.
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 17
Sommerville’s position


Agile methods are probably best suited to
small/medium-sized business systems or
PC products.
In particular, they are not well suited for
dealing with: (compare to slide #12)

large-scale development with multiple teams
working at different sites

complex interactions with other systems

high security or safety applications
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 18
Extreme programming (XP)


Perhaps the best-known and most widely
used agile method.
Takes an “extreme” approach to iterative
development:



New versions may be built several times per
day
Increments are delivered to customers every 2
weeks
All tests must run successfully for every build
“iterative development on steroids”
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 19
The XP release cycle
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 20
Extreme programming practices 1
Incr em en tal p lann ing
R e qui rem en ts a re re cord e d on Story C ards and the St or ies to be
inc luded i n a re le as e a re de ter mi ned by th e tim e a va il ab le a nd
the ir relati ve pr iorit y. The deve lope rs br e ak the se S tori es i n to
deve lop m en t ŌT asks Õ.
Sm all R eleas e s
T he mi nim al u sefu l set o f func ti ona lit y tha t prov ide s bu si nes s
va lue i s deve loped fir st. R el eas e s of the sys tem are fr equen t and
inc rem en tall y a dd func ti ona lit y to the fi rst r elea se.
Sim pl e De si gn
E nough de si gn is ca rri ed ou t to m ee t t he cu rr en t requ ir em en ts
and no m ore.
T es t fir st deve lop m en t
An au tom ated un it t es t fram ewo rk is u sed to w rite t ests f or a new
piece of func ti ona lit y be fore tha t fun ct ion a lit y it se lf is
im plem en ted .
R e fa c to ri ng
A ll d e ve lope rs a re expe c te d to re fac tor the code con ti nuous ly as
soon as po ssible code im p rove m en ts are found . T his keeps t he
code sim ple and m ain taina bl e .
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 21
Extreme programming practices 2
P air Pr ogra mmi ng
Deve lop e rs wo rk in pa ir s, che c king ea c h o the rÕs w ork and
p rov iding t he suppo rt to a lw ays do a good job .
Co ll ec tive Owne rs hip
T he pa ir s o f deve lop e rs wo rk on all a re a s of the sys tem, so tha t
no isl ands of expe rti se deve lop and al l t he deve lope rs own a ll t he
code . Anyon e c a n chang e any th ing . “egoless programming”
Con ti nuou s In tegr at ion
A s soon as wo rk on a t ask i s co m pl et e it is i n teg rated i n to the
who le sy st em . Af ter any such in teg rati on , a ll th e un it test s i n the
sy st em m u st pa ss.
S us tainab le pac e
L arg e a m oun ts o f ove r-t ime are not con sid e re d ac c ep tab le a s the
ne t ef fec t i s of ten t o reduc e code qua lit y a nd m ed ium term
p roduc ti vity
On -sit e Cu sto m er
A rep resen tati ve of t he end -u ser o f the sy stem (t he C us to m er)
shou ld be ava il ab le fu ll tim e fo r th e u se o f th e X P te am . In an
ex tr em e prog rammi ng p roce ss, the cus to m er is a m em be r o f th e
deve lop m en t t ea m a nd is r espon si b le for b ri nging sy st em
requ ire m e nts to t he te am for im plem en tati on.
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 22
Summary of XP and agile
principles



Incremental development is supported
through small, frequent system releases.
Customer involvement means full-time
customer engagement with the team.
Focus is on people – not process –
through pair programming, collective
ownership, and a process that avoids
long working hours.
(Cont’d)
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 23
Summary of XP and agile
principles (cont'd)


Change supported through regular
system releases.
Maintaining simplicity (maintainability)
through constant refactoring of code.
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 24
Requirements scenarios




Requirements are expressed as scenarios
or user stories written on cards.
Development team breaks them down into
implementation tasks.
Tasks are the basis of schedule and cost
estimates.
Customer chooses stories for inclusion in
the next release based on priorities and
schedule estimates.
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 25
Story card for document
downloading
Down loadin g an d pri ntin g an articl e
First, y ou select t he art icle that y ou want from a disp layed list .
t hen have to t ell t he syst em how you will pay for it - t his can eit her
be through a subscrip tion, through a comp any account or by credit
card.
You
Aft er t his , y ou get a copy right form from t he syst em to fill in and,
when y ou have submit ted t his, t he art icle you want is downloaded
onto your computer .
You t hen choose a p rinter and a copy of t he art icle is print ed.
t ell t he syst em if printing has been s uccessful.
If the article is a p rint -only art icle, you canÕ
so it is automat ically deleted from your computer
©Ian Sommerville 2000
You
t keep the P DF version
.
Software Engineering. Chapter 17/16.4
Slide 26
XP and change


Conventional SE wisdom is design for
change (via “information hiding”) to reduce
maintenance costs.
XP maintains this is not worthwhile since
changes cannot be reliably anticipated.
(Which position is correct?)
(Cont’d)
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 27
XP and change (cont'd)

(Instead,) XP proposes constant code
improvement (“refactoring”) to make
changes easier when they have to be
implemented.
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 28
Testing in XP

Test-first: write tests before coding.
 helps clarify requirements


Involve Users in test development and
validation.
Use automated test harnesses to run all
previous and new tests before each new
release.
 regression testing
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 29
Task cards for document
downloading
Task 1: Impl emen t pri nci pal workflow
Task 2: Impl emen t articl e catalog an d selecti on
Task 3: Impl emen t payment col lection
Payment may be made in 3 dif
ferent way s. The user
select s which way t hey wish t o pay
. If the user
has a library subscrip tion, then they can inp ut the
subscriber key which should be checked by the
sy stem. Alternatively , they can inp ut an or
ganisat ional
account number . If this is valid, a debit of t he cost
of t he art icle is posted t o t his account . Finally
, they
may input a 16 digit credit card number and expiry
date. This should be checked for validity and, if
valid a debit is p osted t o t hat credit card account .
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 30
Test case description
Test 4: Test cr edit card val idi ty
Input:
A stringrepresentingthe credit card number andtwo integersrepresenting
t he month and y ear when the card expires
Tests :
Check that all by tes in the st ring are digits
Check that the mont h lies bet ween 1 and 12 and the
year is great er t han or equal t o t he current year
.
Using the first 4 digits of t he credit card number
,
check that the card is suer is valid by looking up the
card is suer t able. Check credit card validity by submit ting the card
number and exp iry date informat ion t o t he card
issuer
Ou tput:
OK or error message indicating t hat the card is invalid
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 31
Pair programming in XP

Programmers work in pairs, sitting together
to develop code


but not the same pairs
Helps develop common ownership of code
and spreads knowledge across the team.
 facilitates “egoless programming”

Serves as an informal, continuous review
process
(Cont’d)
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 32
Pair programming in XP (cont'd)


Encourages refactoring since the whole
team benefits
Measurements suggest development
productivity is comparable to two people
working independently (but with all the
benefits of pair programming).
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 33
“Rapid Application Development”
(RAD) environments



Other rapid development approaches have
been around for years.
RAD environments evolved from “fourthgeneration languages” (4GL’s) and are
designed to develop data-intensive business
applications
They rely on a high-level programming
language integrated with a database.
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 34
A RAD environment
Database management system
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 35
RAD environment tools




Database programming language (e.g.,
SQL)
Interface generator to create forms for
data input and display
Links to office applications such as
spreadsheets or word processors
Report generators
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 36
Visual programming with
reuse




Scripting languages such as Visual Basic
support visual programming
Applications are developed by creating
an iconic user interface and associating
components with the graphical icons.
Large libraries of reusable components
exist to support this.
Components may be tailored to suit the
specific application requirements.
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 37
Visual programming
application screen
Hy pert ext
d is pl ay co m po nen t
Dat e co m po nen t
F i le
Ed it
Vi ew s
Lay ou t
Op t io ns
Gen eral
Ind ex
1 2t h J anu ary 2 00 0
R ang e ch ecki ng
s cri pt
Hel p
3 .87 6
Us er p rom p t
com p on ent +
s cri pt
Draw can vas
com p on ent
Tree d isp lay
com p on ent
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 38
Problems with visual
programming



Difficult to coordinate team-based development
No explicit system architecture (hidden)
Complex dependencies between parts of
the program can cause maintainability
problems.
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 39
Component assembly



Systems are created quickly from a set of
reusable components plus a mechanism to
“glue” components together.
Composition mechanism must include
control facilities and a mechanism for
component communication.
Must take into account availability and
functionality of existing components
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 40
Reuse based Application-level
rapid development: COTS


Existing “off the shelf” applications can be
configured and linked together.
For example, a requirements management
system could be built by using:



A database to store requirements;
A word processor to capture requirements and
format reports; and
A spreadsheet for traceability management.
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 41
Compound documents




Some applications/prototypes can be created
by developing a compound document.
This is a document with active elements (such as
a spreadsheet) that allows user computations.
Each active element has an associated
application which is invoked when that element
is selected.
The document itself is the integrator for the
different applications.
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 42
Application linking in
compound documents
C om p ou nd d ocu m ent
Text 1
Tabl e 1
Tabl e 2
W o rd p roces so r
©Ian Sommerville 2000
Text 2
Text 4
S o un d 1
Text 3
S o un d 2
S p read sh eet
Software Engineering. Chapter 17/16.4
Text 5
Au di o pl ayer
Slide 43
What is prototyping?

Some traditional features:
 An iterative process emphasizing
Rapid development
Evaluative use
Feedback
Modification
 Learning (based on feedback)
 Consideration of alternatives
 Concreteness (a “real system” is
developed and presented to real users)
(Cont’d)
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 44
What is prototyping? (cont’d)


Boundary between prototyping and normal
system development blurs when an
evolutionary (e.g., Extreme Programming)
development approach is used.
Thus, our primary focus is throw-away
prototyping.
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 45
Uses of prototypes

Principal use is to help customers and
developers better understand system
requirements.
 Experimentation stimulates anticipation
of how a system could be used.
 Attempting to use functions together to
accomplish some task can easily reveal
requirements problems.
(Cont’d)
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 46
Uses of prototypes (cont’d)

Other potential uses:
1. Evaluating proposed solutions for
feasibility (Experimental Prototyping)
2. “Back-to-back” system testing
3. Training users before system delivery

Prototyping is most often undertaken as
a risk reduction activity.
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 47
Classifying prototypes

By purpose:





Throw-away prototyping – to elicit and validate
requirements
Experimental prototyping – to evaluate proposed
solutions for feasibility, performance, etc.
horizontal vs. vertical (breadth vs. depth)
mockups vs. breadboards (form vs. function)
“Wizard of Oz” prototyping (Turing test reversed)
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 48
Vertical prototype
high
F
I
d
e
l
I
t
y
Horizontal prototype
low
few
Number of features
many
Simulation, prototyping, and
scenarios

What are the differences between
prototyping and simulation?
(Cont’d)
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 52
Simulation, prototyping, and
scenarios (cont’d)

What is the connection between simulation
models / prototypes, and scenarios?


Simulation models are automatic scenario
generators.
Prototypes facilitate manual scenario
generation.
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 53
Simulation, prototyping, and
scenarios (cont’d)

What is the connection between simulation
models / prototypes, and scenarios?


Simulation models are automatic scenario
generators.
Prototypes facilitate manual scenario
generation.
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 54
Simulation, prototyping, and
scenarios (cont’d)

What is the connection between simulation
models / prototypes, and scenarios?


Simulation models are automatic scenario
generators.
Prototypes facilitate manual scenario
generation.
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 55
Prototyping benefits






Misunderstandings are exposed.
Difficulttouse or confusing services are
identified.
Missing services are detected.
Incomplete and/or inconsistent requirements
are found by analysts as prototype is being
developed.
Can demo feasibility and usefulness.
Basis for writing a system specification.
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 56
Prototyping process
What to include & what
NOT to include.
Es t abl is h
p ro to ty pe
o bj ect iv es
Defi ne
p ro to ty pe
fun cti on ali ty
Develo p
p ro to ty pe
Ev alu at e
p ro to ty pe
P ro to ty pi ng
p lan
Ou t li ne
d efi ni ti on
Ex ecut ab le
p ro to ty pe
Ev alu ati on
repo rt
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 57
Throw-away prototyping


Used to reduce requirements risk.
Initial prototype is developed from outline
requirements, delivered for experiment,
and modified until risk is acceptably low.
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 58
Throw-away prototyping
Elicit/validate REQMTS
Ou t li ne
requ irem en ts
S p eci fy
s ys tem
Evalu at e
p ro to ty pe
Dev elo p
p ro to ty pe
Reus abl e
com p on ent s
Develo p
s oft ware
©Ian Sommerville 2000
Vali dat e
s ys tem
Software Engineering. Chapter 17/16.4
Del ivered
s oft ware
s ys tem
Slide 59
Throw-away prototype
delivery
?


Developers may be pressurized to deliver a
throw-away prototype as the final system.
This is problematic...




It may be impossible to meet non-functional
requirements.
The prototype is almost certainly undocumented.
The system may be poorly structured and
therefore difficult to maintain.
Normal quality standards may not have been
applied.
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 60
No, no, no! I
won’t deliver the
prototype to you!
User Mgmt
Developer
Air Tank
Pressurizing the
Developer
Prototypes AS specifications?



Some parts of the requirements (e.g.,
safety-critical functions) may be
impossible to prototype and so don’t
appear in the “specification.”
An implementation has no legal standing
as a contract.
Non-functional requirements cannot
be adequately represented in a system
prototype.
(Some)
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 8
Slide 62
Implementation techniques

Various techniques may be used for developing
prototypes:





Dynamic high-level languages
Database programming (RAD)
Component and application assembly
These are not mutually exclusive – they are
often used together.
Visual programming is also an inherent part of
most prototype development systems.
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 63
Dynamic high-level languages





Include powerful data management facilities – often
typeless and interpretive.
Require large run-time support system – not
normally used for large system development.
Some offer excellent GUI development facilities.
Some have an integrated support environment*
whose facilities may be used in the prototype.
Examples: Lisp (list structure based), Prolog (logic
based), Smalltalk (object-oriented), APL (matrix
processing).
* Function libraries, debuggers, symbolic evaluators, etc.
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 64
Choice of prototyping
language



What is the application domain? (e.g.,
NLP?, matrix manipulation?)
What user interaction is required? (textbased? Web-based?)
What support environment comes with
the language? (e.g., tools, components)
(Cont’d)
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 65
Choice of prototyping
language (cont’d)


Different parts of the system may be
programmed in different languages.
(However, there may be problems with
language communications.)
A multi-paradigm language (e.g., LOOPS)
can reduce this problem.
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 66
User interface prototyping


It is impossible to pre-specify the look
and feel of a user interface in an effective
way. Prototyping is essential.
UI development consumes an increasing
part of overall system development costs.
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 67
User interface prototyping



Aim is to allow users to gain direct
experience with the interface.
Without this, it is impossible to judge
usability.
May employ a two-stage process:
 paper prototypes are developed initially,
 followed by a series of increasingly
sophisticated automated prototypes.
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 68
Paper prototyping



Work through scenarios using sketches
of the interface.
Use storyboards/scenarios to present a
series of interactions with the system.
Paper prototyping is a cost-effective way
of getting user reactions to an interface
design proposal.
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 69
User interface evaluation



Some evaluation of a user interface design
should be carried out to assess its suitability.
Thorough 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.
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 70
Usability attributes
A ttribut e
D escr iption
Lea rn ab ili ty
H ow lo ng d oe s it ta k e a ne w us er to be c om e prod uc tiv e w it h
th e sys te m ?
S pe ed of op erat ion
H ow w el l do es the syste m re sp ons e m atch th e us er Õs w ork
p ra c tic e?
R o bus tn ess
H ow to le ran t is th e sys te m of use r e rror?
R e co v erab ili ty
H ow go od is th e sys te m at rec o ve rin g from user e rr ors ?
A da p ta b ilit y
H ow closely is th e sys te m t ie d t o a s in gl e m od el of w ork?
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 71
Simple evaluation techniques


Questionnaires for user feedback.
Video recording of system use and
subsequent tape evaluation. (“protocol
analysis”)


Instrumentation of code to collect
information about patterns of use and user
errors.
Including code in system to collect on-line
user feedback.
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 72
Key points



An iterative approach to software
development leads to faster delivery of
software.
Agile methods are iterative development
methods that aim to reduce development
overhead and so produce software faster.
Extreme programming includes practices
such as systematic testing, continuous
improvement, and customer involvement.
(Cont’d)
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 73
Key points (cont’d)



Testing in XP is a particular strength since
tests are developed before code is written.
Rapid Application Development (RAD)
environments include database
programming languages, form generation
tools, and links to office applications.
Throw-away prototyping is used to explore
requirements and design options.
(Cont’d)
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 74
Key points (cont’d)


Prototypes give end-users a concrete
impression of a system’s capabilities.
Rapid development of prototypes is
essential. This usually requires leaving
out functionality or relaxing non-functional
constraints.
(Cont’d)
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 75
Key points (cont’d)



Prototyping techniques include the use
of very high-level languages, database
programming and prototype construction
from reusable components.
Prototyping is essential for parts of the
system such as the user interface which
cannot be effectively pre-specified.
Users must be involved in prototype
evaluation.
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 76
Chapter 17/16.4
Rapid Software Development /
Prototyping
©Ian Sommerville 2000
Software Engineering. Chapter 17/16.4
Slide 77