Object oriented sad 6

Chapter SIX
Implementation, Testing and
Pragmatics
Making it a reality

Topics
Documentation
Coding, Testing and inspection
Others
 Installation
 Training
 Maintenance
2

Introduction
Pragmatics concerned with how the system
design process we have done so far would be
linked to the reality or how it is would give
sense or meaning to the stakeholders.
These issues will cover Coding, testing along
with documentation and object oriented
benefit realization.
3

Documentation
There are various types of documentations
required in object oriented Software engineering
 System Documentation: detailed information about a
system’s design specifications, its inner workings, and its
functionality.
 User Documentation: written or other visual
information about an application system, how it works, and
how to use it. User documentation is often in the form of
online help, sometimes with Web connections for further
information.
4

Cont…
The system documentation can be for internal
or external to the system being developed.
 Internal System Documentation: comments in source
code, generated during the coding process or automatically
by software compilers or documenters are internal to the
system.
 External System Documentation: outcomes
of all diagrams, including use cases, design classes,
activity and sequence diagrams, etc are categorized
under this sub category.
5

Coding
Translating the design specification in to a working
system (a reality)
Two important issues
 Coding style
 To make readable and maintainable
 Adding as much comments as possible, use
combination of uppercase and lower case in naming
…
 Programming language selection
 A language that supports features required
 For a web based applications vs window based
6

Software Testing
Testing is the process of exercising a
A software/program with the specific intent
of finding errors prior to delivery to the end
user.
Testing is Verification and Validation
“Are we building the right system?”
“Are we building the system right ?”

What Testing Shows
errorserrors
requirements conformancerequirements conformance
performanceperformance
an indicationan indication
of qualityof quality

Who Tests the Software?
developer independent tester
Understands the system
but, will test "gently"
and, is driven by "delivery"
Must learn about the system,
but, will attempt to break it
and, is driven by quality

10
Cont…
 A failure is an unacceptable behaviour exhibited by a system
 The frequency of failures measures the reliability
 An important design objective is to achieve a very low failure
rate and hence high reliability.
 A failure can result from a violation of an explicit or implicit
requirement
 A defect is a flaw in any aspect of the system that contributes, or
may potentially contribute, to the occurrence of one or more
failures
 could be in the requirements, the design and the code
 It might take several defects to cause a particular failure
 An error is a slip-up or inappropriate decision by a software
developer that leads to the introduction of a defect

11
Effective and Efficient Testing
To test effectively, you must use a strategy that
uncovers as many defects as possible.
To test efficiently, you must find the largest possible
number of defects using the fewest possible tests
 Testing is like detective work:
 The tester must try to understand how programmers and
designers think, so as to better find defects.
 The tester must not leave anything uncovered, and must be
suspicious of everything.
 It does not pay to take an excessive amount of time; tester has to
be efficient.

Software Testing
Methods
Strategies
white-box
methods
black-box
methods

White-Box Testing
... our goal is to ensure that all
statements and conditions have
been executed at least once ...

14
Cont…
Also called ‘Glass-box testing’ or ‘structural’ testing
Testers have access to the system design
 They can
 Examine the design documents
 View the code
 Observe at run time the steps taken by algorithms and their
internal data
 Individual programmers often informally employ glass-box
testing to verify their own code

Black-Box Testing
requirementsrequirements
eventseventsinputinput
outputoutput

16
Cont…
Testers provide the system with inputs and observe
the outputs
 They can see none of:
 The source code
 The internal data
 Any of the design documentation describing the system’s internals

17
Writing Formal Test Cases and Test Plans
A test case is an explicit set of instructions designed
to detect a particular class of defect in a software
system.
 A test case can give rise to many tests.
 Each test is a particular running of the test case on a particular
version of the system.

18
Test plans
 A test plan is a document that contains a complete set of test cases for a
system
 Along with other information about the testing process.
 The test plan is one of the standard forms of documentation.
 If a project does not have a test plan:
 Testing will inevitably be done in an ad-hoc manner.
 Leading to poor quality software.
 The test plan should be written long before the testing starts.
 You can start to develop the test plan once you have developed the
requirements.

19
Information to include in a formal test case
A. Identification and classification:
 Each test case should have a number, and may also be given a
descriptive title.
 The system, subsystem or module being tested should also be clearly
indicated.
 The importance of the test case should be indicated.
B. Instructions:
 Tell the tester exactly what to do.
 The tester should not normally have to refer to any documentation in
order to execute the instructions.
C. Expected result:
 Tells the tester what the system should do in response to the
instructions.
 The tester reports a failure if the expected result is not encountered.
D. Cleanup (when needed):
 Tells the tester how to make the system go ‘back to normal’ or shut
down after the test.

20
The roles of people involved in testing
 The first pass of unit and integration testing is called developer
testing.
 Preliminary testing performed by the software developers who do
the design.
 Independent testing is performed by a separate group.
 They do not have a vested interest in seeing as many test cases
pass as possible.
 They develop specific expertise in how to do good testing, and how
to use testing tools.

21
Testing performed by users and clients
 Alpha testing
 Performed by the user or client, but under the supervision of the
software development team.
 Beta testing
 Performed by the user or client in a normal work environment.
 Recruited from the potential user population.
 An open beta release is the release of low-quality software to the
general population.
 Acceptance testing
 Performed by users and customers.
 However, the customers do it on their own initiative.

Finally
Software testing is four steps procedure
 Initially, tests focus on each component individually,
ensuring that it functions properly as a unit.
 makes heavy use of white-box testing techniques,
exercising specific paths in a module's control structure
to ensure complete coverage and maximum error
detection.

Cont…
Next, components must be assembled or
integrated to form the complete software package.
Integration testing addresses the issues associated
with the dual problems of verification and program
construction.
 Black-box test case design techniques are the most prevalent
during integration, although a limited amount of white-box
testing may be used to ensure coverage of major control
paths.

Cont…
After the software has been integrated (constructed),
a set of high-order tests are conducted. Validation
criteria (established during requirements analysis)
must be tested.
 Validation testing provides final assurance that software meets
all functional, behavioral, and performance requirements.
 Black-box testing techniques are used exclusively during
validation.

Cont….
The last high-order testing step falls outside the
boundary of software engineering and into the
broader context of computer system engineering.
Software, once validated, must be combined with
other system elements (e.g., hardware, people,
databases).
 System testing verifies that all elements mesh properly and
that overall system function/performance is achieved.

Others
Installation
 Putting the system in to work
 Direct/phased/parallel/ one site
Training
 Enabling end users and technical personals to work and mange
the system/software
 For whom and how much?
Maintenance
 Providing continuous support as long as the software/system is
alive.
 Adaptive/perfective/corrective
26

Summary
Introduction
 Understanding motivations and basic concepts
 Terminologies , concepts, processes, approaches
Modeling using UML
 Understanding modeling tools in software development
 Types, categories and structure
Requirement elicitation
 Collecting and organizing users requirement- WHAT- User
needs
 From function, class, and interface points of view
27

Cont…
Requirement Analysis
 Analyzing and modeling requirements-WHAT System
 In terms of Function, Logic and Objects (classes)
System and object design
 Specifying the new system-HOW
 At an architecture level and detail design level
Implementation, testing and Pragmatic
 Making it a reality
 Coding, testing and documentation
28

Peripheral issues- Additions
29

Map of Human Computer
Interaction
WHAT DOES THE DISCIPLINE OF HCI COVER?
WHY STUDY HCI?

Overview: Map of Human Computer Interaction
Input and
Output Devices
Dialogue
Techniques
Dialogue
Genre
Application Areas
Ergonomics
Evaluation
Techniques
Design
Approaches
Implementation
Techniques and Tools
Example Systems
and Case Studies
Human
Language,
Communication
and Interaction
Human
Information
Processing
Use and Context
Human-Machine Fit and AdaptationSocial Organization and Work
Computer
Computer
Graphics
Dialogue
Architecture
Development Process
A a

Use and context of computers
 Problems of fitting computers, their uses, and the context of use
together Social organization and work
 humans are interacting social beings
 considers models of human activity:
 small groups, organizations, socio-technical systems
 quality of work life…
 Application areas
 characteristics of application domains, e.g. individual vs group work
 popular styles
 document production, communications, design, tutorials and help, multi-media
information kiosks, continuous control (cockpits, process control), embedded
systems (copiers, home appliances)
 Human-machine fit and adaptation
 improve the fit between the designed object and its use
 how systems are selected and adopted; how users improvise routine systems; how
systems adapt to the user (customization); how users adapt to the system (training,
ease of learning); user guidance (help, documentation, error-handling)

Human characteristics
 To understand the human as an information-processing system,
how humans communicate, and
people’s physical and psychological requirements
 Human information processing
 characteristics of the human as a processor of information
 memory, perception, motor skills, attention, problem-solving, learning and skill
acquisition, motivation, conceptual models, diversity...
 Language, communication and interaction
 aspects of language
 syntax, semantics, pragmatics; conversational interaction, specialized languages
 Ergonomics
 anthropometric and physiological characteristics of people and their
relationship to workspace and the environment
 arrangement of displays and controls; cognitive and sensory limits; effects of
display technology; fatigue and health; furniture and lighting; design for stressful
and hazardous environments; design for the disabled...

Computer system and interface architecture
 The specialized components computers have for interacting with
people
 Input and output devices
 mechanics and characteristics of particular hardware devices, performance
characteristics (human and system), esoteric devices, virtual devices
 Dialogue techniques
 the basic software architecture and techniques for interacting with humans
 e.g. dialog inputs and outputs; interaction styles; issues
 Dialog genre
 The conceptual uses to which the technical means are put
 e.g. interaction and content metaphors, transition management, style and
aesthetics
 Computer graphics
 basic concepts from computer graphics that are especially useful to HCI
 Dialogue architecture
 software architecture and standards for interfaces
 e.g., screen imaging; window managers; interface toolkits; multi-user architectures,
look and feel, standardization and interoperability

The Development Process
 The construction and evaluation of human interfaces
 Design approaches
 the process of design
 e.g. graphical design basics (typography, color, etc); software engineering; task
analysis; industrial design...
 Implementation techniques and tools
 tactics and tools for implementation, and the relationship between design,
evaluation and implementation
 e.g. prototyping techniques, dialog toolkits, object-oriented methods, data
representation and algorithms
 Evaluation techniques
 philosophy and specific methods for evaluation
 e.g. productivity, usability testing, formative and summative evaluation
 Example systems and case studies
 classic designs to serve as example of interface design genres

Why study human use of computer systems?
 Business view:
 to use humans more productively/effectively
 the human costs now far outweigh hardware and software costs
 Personal view:
 people view computers as appliances, and want it to perform as one
 Marketplace view:
 everyday people using computers
 now expect “easy to use system”
 not tolerant of poorly designed systems
 little vendor control of training
 heterogeneous group
 if product is hard to use, people will seek other products
 eg Mac vs IBM (Microsoft Windows)

The system view:
 complex human
 complex computer
 complex interface between the two
The human factors view:
 humans have necessary limitations
 errors are costly in terms of
 loss of time
 loss of money
 loss of lives in critical systems
 loss of morale
 design can cope with such limitations!

 The social view:
 Computers contribute to critical parts of our society, and cannot be ignored
 educate our children
 take medical histories and provide expert advice
 keep track of our credit worthiness
 play(?) war games (and help form policies)
 control air and ground traffic flow
 book travel
 control chemical/oil/nuclear plants
 control space missions
 assist humans with their everyday tasks (office automation)
 control complex machines (aircraft, space shuttles, super tankers)
 help control consumer equipment (cars, washing machines)
 entertainment (games, intellectual stimulation).…
In all these views, economics and human best interests are aligned

You know now
The HCI discipline includes the study of:
 the use and context of computers
 human characteristics
 computer system and interface architecture
 the development process
HCI is worth studying because it aligns both human
interests and economic interests

End of The chapter and the
course
40

Object oriented sad 6

More Related Content

What's hot

Viewers also liked

Similar to Object oriented sad 6

More from Bisrat Girma

Recently uploaded

Object oriented sad 6