1. Unit-5
• Designing Interface Objects
• Software Quality Assurance
• System Usability
• Measuring User Satisfaction

2. View Layer: Designing Interface Objects
Identifying view Classes
Designing interface Objects
Objective

3. To display and obtain needed information
in an accessible,efficient manner.
Goal of a User Interface (UI)

4. The Purpose of a View Layer Interface
User interface can employ one or more Windows
Each window should serve a clear, specific purpose
Intro:

5. The Purpose of a View Layer Interface (Cont)
Purposes
Forms and data entry windows
Dialog boxes
Application windows

6. Forms and Data Entry Windows
Data entry windows provide access to data that
users can retrieve, display and change in the
application.
For example
•Form Design in VB
•Input Dialog boxes in VB

7. Example for Form Design

8. Example for Input Box

9. Forms and Data Entry Windows (Cont)
Guidelines for designing Forms and Data
Entry Window
Identify the information which we want to display
or change
Identify the task that users need to work with data
on the form or data entry window

10. Forms and Data Entry Windows (Cont)
Data entry tasks include
Navigating rows in a table, such as moving
forward and backward, and going to the first and
last record
Adding and deleting rows
Changing data in rows
Saving and canceling the changes
We can provide buttons & menus to initiate the user tasks

11. Dialog Boxes
Dialog boxes display status information or ask users
to supply information or make a decision before
continuing with a task
For example
Message Dialog boxes in VB
OK only
YES NO

12. Example for Dialog box

13. Dialog Boxes (Cont)
Guidelines for designing Dialog boxes
and Error messages
A dialog box provides an exchange of information or a
dialog between the user and the application
Dialog boxes generally appear after a particular Menu
item or a Command button pressed
Error message
If we will wrongly enter the date in the entry form then the
message show the format for date (DD/MM/YYYY)

14. Guidelines for the Command Buttons
Layout
Position the command buttons are very
important
•Bottom
•Align top right
•Align left border is very popular in web
interface

15. Application Windows( Main Window)
An application window is a container of application
objects or icons
It contains an entire application with which users can
interact

16. Application Windows (cont)
Consist of
Frame or border
Title bar
Scroll bars
Menu bar
Toll bar
Status bar

17. Example

18. Application Windows (cont)
File menu
Open, Save, Save As, Print, Exit
Edit Menu
Cut, Copy, Paste
View Menu
Zoom,show and etc
Help Menu
Fonts
Colors

19. Example

20. Example

21. Prototyping the user interface
Activity diagram
Create user
interface controls
Associate actions to the users
interface controls and their events
Test / Debug
[ No ]
[ Yes ]

22. VIEW LAYER:DESINGING
INTERFACE OBJECTS
Objectives:
• Identifying View Class
• Designing Interface Objects.

23. INTRODUCTION
Two types of Interface
1. User Interface
2. Graphical User Interface

24. The main Goal of UI
To display and obtain needed information in an
accessible, efficient manner.
The Main Goal of GUI
Graphical Representation.
• User Design as a Creative Process

25. Designing View Layer Classes
• An implicit benefit of three layer Architecture.
• Separation of the view layer from the business and access layer.
View Objects
Business Objects
Access Objects

26. View Layer Objects
They are the only exposed objects of an application
with which users can interact.
View Layer Class
That represent the set of operations in the business
that users must perform to Complete their task,
Ideally in a way they find natural,
Easy to remember, and
Useful.

27. The View Layer Objects are represented for two
major aspects of the applications.
1. INPUT – Responding to user interaction
2. OUTPUT-Display or Printing business
objects.

28. View Layer Classes is divided four activities
• Macro level UI design process.
Identifying view layer objects,
User’s perspective.
• Micro level UI design activities.
Design axioms and corollaries, Prototyping.
• Testing usability and User satisfaction.
• Refining and Iterating the design.

29. MACRO LEVEL PROCESS
Two Steps:
1. For every class identified, determine if the
class interacts with a human actor.
1.Identify the view (interface) objects for the
class. 2.
Define the relationship among the view
objects.
2. Iterate and refine.

30. MICRO LEVEL PROCESS
The process of designing view objects
1. For every interface object identified in the
macro UI design process.
2. Iterate and Refine.

31. OBJECTIVE
◘ QUALITY ASSURANCE TESTS
◘ TESTING STRATEGIES
◘ IMPACT OF OBJECT ORIENTATION ON TESTING
◘ TEST CASES
◘ TEST PLAN
◘ CONTINUOUS TESTING
◘ MYER’S DEBUGGING PRINCIPLES

32. QUALITY ASSURANCE TESTS
Why?
Computers are infamous for doing what you tell them to do, not necessarily
what you want them to do.
Debugging:
Is the process of finding out where something went wrong and
correcting the code to eliminate the errors or bugs that cause unexpected
results.
Types of Errors:
 Language(syntax) errors
 Run – time errors
 Logic errors
Categories:
 Error – based Testing
 Scenario(usage) – based Testing
(contd…)

33. Categories
♠ Error – based Testing.
♠ Search for particular clues of interest.
♠ Describe how clues should be tested.
♠ Scenario – based Testing.
♠ Concentrates on what the user does , not on what
the product does.
(contd…)

34. TESTING STRATEGIES
‫۝‬ BLACK BOX TESTING
₤ It is used to represent a system whose inside workings are not available for
inspection.
‫۝‬ WHITE BOX TESTING
₤ Specific logic is important and must be tested to guarantee the systems
proper functioning.
‫۝‬ TOP – DOWN TESTING
₤ It supports testing user interface and system integration.
‫۝‬ BOTTOM – UP TESTING
₤ It starts with the details of the system and proceeds to higher levels by a
progressive aggregation of details until they fit requirements of system.

35. IMPACT OF OO ON TESTING
٤ Errors.
٥ Less Plausible ( not worth testing for )
٥ More Plausible ( worth testing for now )
٥ New
٤ Impact of Inheritance on Testing.
٤ Reusability of tests.

36. TEST CASES
§ A test case is a set of What – if questions.
§ To test a system you must construct some best input cases, that
describe how the output will look.
§ Next, perform the tests and compare the outcome with the
expected output.
(contd…)

37. Myer’s (objective of testing )
‫ﭳ‬ Testing
Is a process of executing a program with the intent of finding errors.
‫ﭳ‬ Good test case
That has a high probability of finding an as – yet – undiscovered error.
‫ﭳ‬ Successful test case
That detects an as – yet – undiscovered error.
(Contd…)

38. Guidelines (for preparing test cases.)
ổ Describe the feature or service.
ổ If based on use case, then refer its name.
ổ Specify the feature to test and how to test.
ổ Test the normal use.
ổ Test the abnormal but reasonable use.
ổ Test the abnormal and unreasonable use.
ổ Test the boundary conditions.
ổ While revising document the cases.
ổ Reusability and extendibility should be assessed.
ổ Add Questions that arise out of previous ones.

39. Test Plan
‫٭‬ A Test plan is developed to detect and identify potential problems
before delivering the software to its users.
‫٭‬ A test plan offers a road map.
‫٭‬ A dreaded and frequently overlooked activity in software
development.
‫٭‬ Steps:
§ Objectives of the test.
§ Development of a test case
§ Test analysis.
‫٭‬ Regression Testing.
‫٭‬ Beta Testing.
‫٭‬ Alpha Testing. (contd…)

40. Guidelines (for preparing test plan)
≈ Specify Requirements generated by user.
≈ Specify Schedule and resources.
≈ Determine the testing strategy.
≈ Configuration Control System.
≈ Keep the plan up to date.
≈ At the end of each milestone, fill routine updates.

41. CONTINUOUS TESTING
₫ Testing must take place on continuous basis and this refining
cycle must continue throughout the development process until
you are satisfied with the results.
₫ During this iterative process, prototypes will be transformed
incrementally into the actual application.

42. MYER’S DEBUGGING PRINCIPLES
∂ Bug locating principles.
© Think
© If you reach an impasse, sleep on it.
© If the impasse remains, describe the problem to someone else.
© Use debugging tools.
© Experimentation should be done as a last resort.
∂ Debugging principles.
© Where there is one bug , there is likely to be another.
© Fix the error, not just the symptom.
© The probability of solution being correct drops down as the size increases.
© Beware of error correction, it may create new errors.

43. System Usability- Introduction
• The task of satisfying user requirements is basic
motivation of quality
• Usability testing is different from quality
assurance testing in that, rather finding
programming defects.
• It reflects the users need and satisfaction

44. USABILITY TESTING
• Definition:
– ISO Defines the usability as the effectiveness,
efficiency and satisfaction with which a specified set
of users to can achieve a specified set of tasks.

45. USABILITY TESTING
• ISO Definition requires
Defining tasks – What are the tasks
Defining users – who are the users
A means for measuring effectiveness, efficiency and
satisfaction – how do we measure usability

46. USABILITY TESTING
• Usability measures the ease of use as well as
the degree of comfort and satisfaction users
have with the software.
• Usability is one of the most crucial factor so it
should begin in the earlier stage of product
development.

47. USABILITY TESTING
• Usability test cases begin with the identification
of use cases.
• When designing test focus on use cases and
tasks not features.

48. USABILITY TESTING
OOA-
Use case model
Quality assurance
test cases
User satisfaction
Test cases
Usability test cases
Test plan
Jacobson’s Life cycle model

49. Guidelines for Usability testing
• The usability testing should involve all software
components
• Usability need not be more expensive or
elaborate
• All tests need not involve many subjects
• Consider user’s experience as a part of your
software usability
• Apply usability testing early and often.

50. RECORDING THE USABILITY TEST
• When conducting a usability test provide a
comfortable environment.
• Record the test results using a video camera or
a tape recorder.
• If possible involve all design team members in
observing the test and reviewing the results.

51. USER SATISFACTION TEST
• User satisfaction testing is the process of
quantifying the usability test with some
measurable attributes of the test such as
functionality, cost, or ease of use.

52. PRINCIPLE OBJECTIVES
• To act as a communication vehicle between
users and designers.
• To detect and evaluate changes during the
design process.
• To provide a periodic indication of divergence of
opinion about the current design.

53. PRINCIPLE OBJECTIVES (cont…)
• To enable pinpointing specific areas of
dissatisfaction for remedy.
• To provide a clear understanding of just how the
completed design is to be evaluated.

54. GUIDELINES FOR DEVELOPING
USER SATISFACTI0N TEST
The format of every user satisfaction test is basically
the same, but its content is different for each project.

55. A Custom Form For User Satisfaction
Test
10 9 8 7 6 5 4 3 2 1
Ease of use
Functionality
Cost
Intuitive UI
Reliability
Comments
10 9 8 7 6 5 4 3 2 1
10 9 8 7 6 5 4 3 2 1
10 9 8 7 6 5 4 3 2 1
10 9 8 7 6 5 4 3 2 1
Very Easy
Very Functional
Very Inexpensive
Very Intuitive
Very Reliable
Very Hard
Non Functional
Very Expensive
Very Hard to Follow
Not Reliable
I have more to say; I would like to see you
How do you rate the customer tracking project at this time?