Course

Software Engineering
Methodology

NOTE: Presentation is available by your request

Slide 1
User interface design

Lecture 11

Slide 2
 Objectives

 To suggest some general design principles for

user interface design
 To explain different interaction styles
 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 evaluation
Slide 3
 Topics covered
 Design issues
 The user interface design process
 User analysis
 User interface prototyping
 Interface evaluation

Slide 4
The 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.
 Poor user interface design is the reason why
so many software systems are never used.

Slide 5
 Human factors in interface design
 Limited short-term memory
• People can instantaneously remember about 7 items of
information. If you present more, they 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.
Slide 6
 UI 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) and should recognise that
people make mistakes.

Slide 7
 Core Design principles

 User familiarity
• The interface should be based on user-oriented
terms and concepts rather than computer concepts. For
example, 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 commands

Slide 8
Core Design principles

 Recoverability
• The system should provide some resilience to
user errors and allow the user to recover from errors. This
might include an undo facility, 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 available

Slide 9
Interaction styles
 Direct manipulation
 Menu selection
 Form fill-in
 Command language
 Natural language

Slide 10
 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.

Other examples?
Slide 11
Information 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.

Slide 12
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?

Slide 13
Alternative information presentations
Jan Feb Mar April May June
2 842 285 1 3 164 2 789 12 73 2 83 5

4000

3000

2 000

1 000

0
Jan Feb Mar April May June

Slide 14
Analogue 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.

Slide 15
 Presentation methods

1
0 10 20
4 2

Dial with need le Pie char t Ther mometer Horizontal bar

Slide 16
 Displaying relative values

Pressure Temperature
0 100 200 300 400 0 25 50 75 100

Slide 17
User 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.

Slide 18
Interviewing

 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.
Slide 19
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 to be used;
• Sophisticated automated prototypes are
developed later.

Slide 20
Paper prototyping
 Work through scenarios using drafts 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.

Slide 21
 Usability attributes

Attribute Description
Learnability How long does it ta ke 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?

Slide 22
 Simple evaluation techniques

 Questionnaires for user feedback.

 Video recording of system use and
subsequent video 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.

Slide 23
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.

Slide 24
 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.

Slide 25
 Work Activity

 What factors to be taken into account in the design of a

menu-based interface for walk-up systems such as
bank ATMs? Write your comments on the interface of
an ATM that you use.

Slide 26
 Factors to be taken into account when
designing 'walk up and use' systems are:
 System users may be disabled so will not be able to respond quickly to
requests.
 Users may not be able to speak the native language of the country where the
machine is installed.
 System users may be completely unfamiliar with technology and may make
almost any kind of error in using the machine. The interface must minimise the
number of possible errors and must be resilient to any possible error.
 Some system users are likely to be confused by many options.
 Different people may understand the meaning of icons in different ways.
 If the system has navigation options, users are almost certain to become lost.
 Most users will want to use the system for very simple functions (e.g.
withdraw cash from an ATM) and will want to do this as quickly as possible.
 There are many different ATM interfaces so each must be considered
separately.
Slide 27
 User interface
prototyping tools

Slide 28
Outline
1. Sketch
2. Marvelapp
3. Flinto
4. Photo.io
5. Figma
6. InVision

1
Slide 29
Sketch
License: Proprietary
Operating system: macOS
Cost: 99$ (for year)
Latest version: 39.1
Web-site:
https://www.sketchapp.com/

• The sketch community offers

many
plugins
• A lot articles written
• «Export to code»

Slide 30
Marvelapp

License: Proprietary
Operating system: macOS, Windows
Cost: 144 $ (Pro for year), free trial
Web-site: https://marvelapp.com/

• Simple to use
• A browser-based
• Strong integration with Photoshop and
Sketch

Slide 31
Flinto

License: Proprietary
Operating system: macOS, Windows
Cost: 99 $, free trial
Web-site: https://www.flinto.com/

• Simple to
use

Slide 32
Proto.io

License: Proprietary
Operating system: macOS, Windows
Cost: 24 $ (for month for 5 projects), free trial
Web-site: https://proto.io/

• Simple to use
• A browser-
based

Slide 33
FIGMA

License: Proprietary
Operating system: macOS, Windows
Cost: 12 $ (for month), free for 3 projects
Web-site: https://www.figma.com/

• Simple to use
• A browser-based version
• Designers can give comments on a
design in
Real time

Slide 34
InVision

License: Proprietary
Operating system: macOS, Windows
Cost: 25 $ (for month), single project free
Web-site: https://www.invisionapp.com/

• A browser-based
• Help to create better
communication
Between team
• Uber, Salesforce, Twitter, Linkedin
use
for prototyping

Slide 35
References
1. 7 Essential Prototyping Tools to use with Sketch,
https://medium.com/sketch-app-sources/7-essential-prototyping-
tools-to-use-with-sketch-c7a594f486a0
2. 10 Best Prototyping Tools for UI/UX Designers in 2018,
https://blog.prototypr.io/10-best-prototyping-tools-for-ui-ux-
designers-in-2018-6591ea1e2e71
3. 11 Best Prototyping Tools For UI/UX Designers — How To
Choose The Right One?, https://medium.theuxblog.com/11-best-
prototyping-tools-for-ui-ux-designers-how-to-choose-the-right-one-
c5dc69720c47
4. The 8 best prototyping tools for 2018,
https://www.creativebloq.com/advice/the-8-best-prototyping-tools-
for-2018
5. Top 22 Prototyping Tools For UI And UX,
https://blog.prototypr.io/top-20-prototyping-tools-for-ui-and-ux-
designers-2017-46d59be0b3a9

Slide 36
Software Construction and Reuse

Lecture 12.

Slide 37
Context of software construction

Detailed creation of working, meaningful

software through a combination of coding,
verification, unit testing, integration testing, and
debugging.

Slide 38
Key Points

 Software construction is the key activity in software

development; construction is the only activity that’s
guaranteed to happen on every project.

 The main activities in construction are detailed design,

coding, debugging, integration, and developer testing
(unit testing and integration testing).

 Other common terms for construction are “coding” and

“programming.”

 The quality of the construction substantially affects the quality

of the software.

Slide 39
Software construction fundamentals

The fundamentals of software construction include:

• Minimizing complexity
• Anticipating change
• Constructing for verification
• Standards in construction

Slide 40
What does it mean?

Minimizing complexity is considered one of the

fundamental principles of software construction.

1) Write as little code as possible

2) Write code that is simple
3) Use very few external libraries
4) Develop extremely fast before the code base
become complex

HOW to do this ?
Slide 41
 Minimizing Complexity
 Specific development practices include:
• Using standards & specific coding techniques
• Using quality techniques
 Enabling techniques that minimize complexity in design:
• Abstraction / Coupling / Cohesion
• Decomposition and modularization
• Separation of interface and implementation
• Sufficiency, completeness, and primitiveness
 Strategies that reduce the complexity of the development process:
• Using patterns
• Reuse
• Incremental development
• Error-reduction techniques
• Heuristics

Slide 42
 Approaches to keep it simple

 Use an incremental development and delivery methodology if possible.

 Incorporate customer involvement throughout the development process,

even if the system is not being delivered incrementally. Have frequent
business customer review meetings, and show newly created displays
and functionality.

 Use tools. Have a source code control system and do daily check-ins.
Automate builds. Use a configuration management system.

 Modularize the code, logically and physically.

 Hide information by minimizing the number of objects or functions that

can directly access database tables and records and other information.
The ideal minimum is one.
Slide 43
 Quiz: Choose the correct answer (s)

Coding efficiency can be applied to:

1. Central processing unit (CPU) time

2. Data storage (disk space)
3. I/O time
4. Programming time

Slide 44
 Quiz

Do not contribute to code efficiency

1. Data structures and algorithms

2. Programming style
3. Architecture
4. Detailed design decisions

Slide 45
 Quiz

Do not contribute to code efficiency

1. Data structures and algorithms

2. Programming style – don’t matter in what line “ ) “ is
3. Architecture
4. Detailed design decisions

Slide 46
Quiz: The best steps for improvement ?
Situation. A design team is working on the design of a payroll system. The
system is being revised to accommodate new features that the customer
desires. Previous versions of the design were not well documented, and the
team is taking advantage of the current version to document the new design.
During product implementation, a mixture of experienced and inexperienced
developers were assigned to the project. An orientation process is not in
place that creates a consistent process where expectations were clearly
defined.

During coding inspection, the lead developer told the developers that were
new to the organization that their code was difficult to follow and understand.
Inspecting their work would need to be rescheduled so that improvements to
their code could be made. Which is the MOST effective way to improve the
understandability of their code?
Slide 47
 How to improve understandability of
code?

a) The developers need to improve the naming of

variables and functions.
b) The developers need to follow well-known industry
coding standard in their work.
c) The developers need to follow company coding
standards in their work.
d) The developers need to explain their work to their
teammates so that they can better understand it.

Slide 48
c) follow company coding standards
 Following existing company-specific coding standards will
provide the most effective way to improve the
comprehension of developed code within the company.

 Option (a) is not correct because improving the names of

variables and methods only addresses a portion of the
readability problem. Option (b) would be a rational choice.
However, the organization's coding standards need to be
followed, and the internal standard may differ from a
preexisting industry standard. Option (d) is incorrect,
because explaining one's own work only works for a short
period of time at best.

Slide 49
Quiz

Which types of testing are typically involved in

construction testing?

a) Beta testing
b) Integration testing
c) Unit testing
d) Configuration testing

Slide 50
 What can be reused ?
Design
patterns Data
Specifications Structures
Compo nent Application
frameworks prod uct lines Aspect-oriented
so ftware develop ment
Class Definitions
Compo nent-based COTS Pro g ram
develop ment integ ration generators
Legacy system
wrapping
Configurable ver tical
ap plications Source Code
Service-o riented
systems
Pro g ram
lib raries

Slide 51
 Reuse-based software engineering

 Application system reuse

• The whole of an application system may be reused
either by incorporating it without change into other
systems (COTS reuse) or by developing application
families.
 Component reuse
• Components of an application from sub-systems to
single objects may be reused.
Object and function reuse
• Software components that implement a single well-
defined object or function may be reused.

Slide 52
Application system reuse
The whole application may be reused, e.g. Billing
systems, payroll systems, registration systems
Key problem ==> portability

Function reuse: software component for a single

function (method) might be reused, e.g. mathematical
function, Individual developer designed tools, Java API,
game components, etc

Major sub-system of an application may

be reused, e.g. ??
Slide 53
Software Reuse

 Reusing trusted (well-tested) components

increases software reliability

 Make reuse easy for future and exploit it now

• Writing code with future reuse in mind
• Write code with clear API
• Writing code from reusable code
• Software libraries, outsourced components

Slide 54
Application Programming Interface (API)
 API is key to proper reusability;
• Should be easy to learn and use, secure and hard to misuse, and
easy to extend and adapt
• Should be stable over long time

 Corporate asset: reusable component with clear API

 API and its implementation must reflect the requirements

 Functional and properly protected

• Does one function only and hides private details

Slide 55
WHY Reuse?

 Reduce development costs

 Increase system reliability
 Reduce overall process risk
 More effective of specialists
 Organizational standards can be built-in.
 Software development time reduced.

Slide 59
 But...

 To make effective use of reusable

components we cannot first design a
system and THEN search for reusable
components.
 The design process MUST be reuse
driven.
 System requirements must be modified
according to the availability of reusable
components

Slide 60
 Reuse benefits 1

Increased dependability Reused software, that has been tried and tested in
working systems, should be more dependable than new
software. The initial use of the software reveals any
design and implementation faults. These are then fixed,
thus reducing the number of failures when the software
is reused.
Reduced process risk If software exists, there is less uncertainty in the costs of
reusing that software than in the costs of development.
This is an important factor for project management as it
reduces the margin of error in project cost estimation.
This is particularly true when relatively large software
components such as sub-systems are reused.
Effective use of specialists Instead of application specialists doing the same work
on different projects, these specialists can develop
reusable software that encapsulate their knowledge.

Slide 61
 Reuse benefits 2

Standards compliance Some standards, such as user interface standards, can be

implemented as a set of standard reusable components. For
example, if menus in a user interfaces are implemented using
reusable components, all applications present the same menu
formats to users. The use of standard user interfaces improves
dependability as users are less likely to make mistakes when
presented with a familiar interface.
Accelerated Bringing a system to market as early as possible is often more
development important than overall development costs. Reusing software
can speed up system production because both development
and validation time should be reduced.

Slide 62
 What sometimes prevents reuse?

 Developers do not know what is available

to be reused

 ‘Not invented here’ syndrome

 Reuse assets do not meet performance needs

 Reuse across team boundaries raise

coordination and ownership issues

 Version management problems

63
Slide 63
 What sometimes prevents reuse?

Components that are created as part of

an application’s development are NOT
likely to be immediately reusable.

WHY??
We should consider Special features of individual machines:
Machine architecture, Operating system, Run-time system..

Slide 64
 Reuse problems 1

Increased maintenance If the source code of a reused software system or component is

costs not available then maintenance costs may be increased as the
reused elements of the system may become increasingly
incompatible with system changes.
Lack of tool support CASE toolsets may not support development with reuse. It may
be difficult or impossible to integrate these tools with a
component library system. The software process assumed by
these tools may not take reuse into account.
Not-invented-here Some software engineers sometimes prefer to re-write
syndrome components as they believe that they can improve on the
reusable component. This is partly to do with trust and partly to
do with the fact that writing original software is seen as more
challenging than reusing other people’s software.

Slide 65
 Reuse problems 2

Creating and maintaining a Populating a reusable component library and ensuring

component library the software developers can use this library can be
expensive. Our current techniques for classifying,
cataloguing and retrieving software components are
immature.
Finding, understanding and Software components have to be discovered in a
adapting reusable components library, understood and, sometimes, adapted to work
in a new environment. Engineers must be reasonably
confident of finding a component in the library before
they will make routinely include a component search
as part of their normal development process.

Slide 66
 Application system reuse

 Involves the reuse of entire application

systems either by configuring a system for
an environment or by integrating two or more
systems to create a new application.

 Two approaches covered here:

• COTS product integration;
• Product line development (product families).

Slide 67
 Planning for reuse

 Reuse must be carefully planned. If the software must be

done quickly, off-the-shelf systems may be appropriate.

 If the software is intended to be long-lived, components will

need to be modified. Access to the source code is essential
and may not be available from outside suppliers.

 Developers may lack the technical skills necessary to create

and/or integrate reusable components systematically.

 Organizations may not have the support or infrastructure

necessary to build & maintain library of reusable components.

 Use in safety-critical applications may be limited. Access to

the source code may be mandatory.
Slide 68
 Benefits of reuse

 Reduced development costs: fewer components need

to be specified, designed, implemented, and validated.
 Quicker time to market, because both development and
validation time can be reduced.
 Increased dependability, because the software has
been tried and tested.
 Reduced process risk, because the cost is known.
 Standards compliance, because some standards can
be implemented as a set of standard reusable
components.

Slide 69
 Disadvantages of reuse

 Increased maintenance costs if the source code

is not available.
 Difficulty associated with cataloging, archiving,
and retrieving reusable assets across multiple
business units. Creating a component library
can be expensive but necessary.
 Limited documentation of the components.

Slide 70
Software Maintenance

 Maintenance is needed to ensure that the

software continues to satisfy user
requirements.
 Maintenance is applicable to software that is
developed using any software life cycle
model
 Software products change due to corrective
and noncorrective software actions

Slide 71
Software Maintenance purpose
 correct faults;
 improve the design;
 implement enhancements;
 interface with other software;
 adapt programs so that different hardware,
software, system features, etc.
 migrate software and retire software

Slide 72
 Five key maintaining activities

 Maintaining control over the software’s day-to-

day functions;
 Maintaining control over software modification;
 perfecting existing functions;
 Identifying security threats and fixing security
vulnerabilities;
 Preventing software performance from
degrading to unacceptable levels.

Slide 73
 Core types of maintenance

 Corrective maintenance: reactive modification (or

repairs) of a software product problems.
 Adaptive maintenance: modification of a product
to keep it usable in a changed environment.
 Perfective maintenance: modification to provide
enhancements for users, improvement of
documentation, performance, maintainability, etc.
 Preventive maintenance: modification to detect
and correct faults in the product before they
become operational faults.
Slide 74
Software Evolution
“Existing large software is never complete and
continues to evolve” (IEEE)

But…

As it evolves, it grows more complex unless

some action is taken to reduce this complexity

Slide 75
 Questions?

«Software is eating the world»

Marc Andreessen

Slide 76
Digital specialist's rewards expectations

Average month salary

Slide 77