object oriented sad 6

40
Chapter SIX Implementation, Testing and Pragmatics Making it a reality

Upload: bisrat-girma

Post on 08-Feb-2017

23 views

Category:

Technology


0 download

TRANSCRIPT

Page 1: Object oriented sad 6

Chapter SIX Implementation, Testing and

Pragmatics

Making it a reality

Page 2: Object oriented sad 6

Topics

DocumentationCoding, Testing and inspectionOthers

Installation Training Maintenance

2

Page 3: Object oriented sad 6

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

Page 4: Object oriented sad 6

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

Page 5: Object oriented sad 6

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

Page 6: Object oriented sad 6

Coding

Translating the design specification in to a working system (a reality)

Two important issues Coding style

To make readable and maintainableAdding 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

Page 7: Object oriented sad 6

Software Testing

Testing is the process of exercising aA 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 ?”

Page 8: Object oriented sad 6

What Testing Shows

errorserrors

requirements conformancerequirements conformance

performanceperformance

an indicationan indicationof qualityof quality

Page 9: Object oriented sad 6

Who Tests the Software?

developer independent testerUnderstands the system but, will test "gently"and, is driven by "delivery"

Must learn about the system,but, will attempt to break itand, is driven by quality

Page 10: Object oriented sad 6

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

Page 11: Object oriented sad 6

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.

Page 12: Object oriented sad 6

Software Testing

Methods

Strategies

white-boxmethods

black-box

methods

Page 13: Object oriented sad 6

White-Box Testing

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

Page 14: Object oriented sad 6

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

Page 15: Object oriented sad 6

Black-Box Testing

requirementsrequirements

eventseventsinputinput

outputoutput

Page 16: Object oriented sad 6

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

Page 17: Object oriented sad 6

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.

Page 18: Object oriented sad 6

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.

Page 19: Object oriented sad 6

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.

Page 20: Object oriented sad 6

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.

Page 21: Object oriented sad 6

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.

Page 22: Object oriented sad 6

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.

Page 23: Object oriented sad 6

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.

Page 24: Object oriented sad 6

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.

Page 25: Object oriented sad 6

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.

Page 26: Object oriented sad 6

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

Page 27: Object oriented sad 6

Summary

Introduction Understanding motivations and basic concepts

Terminologies , concepts, processes, approachesModeling 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

Page 28: Object oriented sad 6

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 levelImplementation, testing and Pragmatic

Making it a reality Coding, testing and documentation

28

Page 29: Object oriented sad 6

Peripheral issues- Additions29

Page 30: Object oriented sad 6

Map of Human Computer Interaction

WHAT DOES THE DISCIPLINE OF HCI COVER?WHY STUDY HCI?

Page 31: Object oriented sad 6

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

ComputerComputer Graphics

Dialogue Architecture

Development Process

A a

Page 32: Object oriented sad 6

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)

Page 33: Object oriented sad 6

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

Page 34: Object oriented sad 6

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

Page 35: Object oriented sad 6

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

Page 36: Object oriented sad 6

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)

Page 37: Object oriented sad 6

Why study human use of computer systems?

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!

Page 38: Object oriented sad 6

Why study human use of computer systems?

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

Page 39: Object oriented sad 6

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

Page 40: Object oriented sad 6

End of The chapter and the course

40