5.1

Lecture 5

System Design:Process and Task Design

IMS2805 - Systems Design and Implementation

5.2

References

HOFFER, J.A., GEORGE, J.F. and VALACICH (2002) 3rd ed., Modern Systems Analysis and Design, Prentice-Hall, New Jersey, Chap 15

HOFFER, J.A., GEORGE, J.F. and VALACICH (2005) 4th ed., Modern Systems Analysis and Design, Prentice-Hall, New Jersey, Chap 13

WHITTEN, J.L., BENTLEY, L.D. and DITTMAN, K.C. (2001) 5th ed., Systems Analysis and Design Methods, Irwin/McGraw-Hill, New York, NY. Chapter 10

WILLCOCKS, L., MASON, P. (1987). Computerising work: People, systems design and workplace relations, Paradigm, London.

5.3

The data flow diagrams and process descriptions produced in the systems analysis phase need to be translated into processes (programs and procedures) during the systems design stage.

These need to be designed with quality criteria in mind: maintainability etc.

Programmers may be more concerned about whether the code works or is elegant.

Physical process design

5.4

Considerations: How do we build a design? How do we document it? How do we measure its quality? How do we improve it? How does it relate to the requirements

specification?

A Design Approach

5.5

We would also like: Documentation as a natural by product To isolate the effect of a given problem To apply principles of re-use To progress from the abstract to the

concrete A large degree of partitioning.

A Design Approach

5.6

A lot of software resources are spent on maintenance

To hep avoid this we need to be able to:

deliver error free designs design easy to maintain systems design software systems that are easy

to test and validate

Structured Design

5.7

Partition the system into "black boxes" Organise the "black boxes" into hierarchies suitable for computer implementationUse diagrams to make the system structure easy to understandUse a set of strategies for developing a design solution from a well defined statement of a problem (e.g. a DFD)Use a set of criteria for evaluating the quality of a given design solution Produce systems that are easy to understand,

reliable, flexible, and efficient to maintain

Structured Design

5.8

Results in:

Small, independent black-box modules arranged

in a hierarchy that models the business area.

It is organised in a top-down fashion, with details

isolated at the bottom.

The chart is called :

A STRUCTURE CHART

Structured Design

5.9

A system is easier to write and test if we divide it into

MODULES

MODULE: A named,bounded, set of statementsto do a single task, havingan identifier by which it canbe referenced as a unit.

GET VALIDTRANSACTION

Each of thesemodules iscodedseparately

Structure Charts

5.10

Start and end here

• Top members (managers) co-ordinate and control• Subordinates process• A manager should have no more than 7+2 immediate subordinates reporting directly to it

USE A HIERARCHY:

input output

Structure charts

5.11

• manager calls worker

• worker executes

• manager resumes

• each module does something for its boss

• it may appoint subordinates

Structure Charts

5.12

A reference to the name of another module

A calls B

A

B

A

B

ControlData

X

A reference to an identifier definedwithin another module.

A is making reference to a data itemX that exists inside B. The referenceis from A to B, but the data flowsfrom B to A.

Module connections

5.13

AFFERENT• Sends info. from below up to its bosses

EFFERENT• Sends info. down to its subordinates

CO-ORDINATE

TRANSFORM

• Gets info. from boss transforms it and sends new info. back to the boss

• Co-ordinates the communication of its subordinates

Modules for system building

5.14

Each business process will generate its own structure chart, using a design strategy such as Transform Analysis or Transaction Analysis

Each box on the structure chart will be a module with its own specification.

Tie together all structure charts under a transaction monitor, so each structure chart can be 'fired' each time a transaction stimulus of its type arrives (or is selected from a menu).

Deriving structure charts

5.15

A design process which turns data flow diagrams into structure charts.

A transform-centred system has as its focus the derivation of new information from existing data

The input part of the system is known as the afferent part

The output part of the system is known as the efferent part

Transform analysis

5.16

5create

X

6Make

Y

4check

M

3Make

M

2check

A

1Make

A

input 1 A

M

B

N

X Y

input 2

6Put Y

Put YMake Y

Make MGet input2Make AGet input1

Create X

Make B Make N

B

A

Main

Put XGet NGet B

Get A Get M

input1

A

N

M

X

B

Ainput1

input2input2

M

NM

N

B

X

XY

Y

afferent legs

efferent legcentraltransform

Transform analysis - an example

5.17

Design features that lead to systems that are easier to maintain and modify : Small module size Modular independence (decrease

coupling) Black box characteristics Module strength (increase cohesion)

Design features

5.18

Design features

The smaller the modules produced, the easier they are to write, test, and are less likely to be effected by a change.

The less the inside of one module depends upon another, the easier it will be to test and to maintain.

We should be able to exploit a "black box" without knowing what's inside it.

Cohesion: a module’s binding or functionality

5.19

Design guidelines that lead to systems that are easier to maintain and modify:

FactoringDecompose a system into smaller and smaller parts, organised hierarchically

Span of Controlno superordinate should control more than 7 subordinate modules

CouplingMinimise the extent to which modules are dependent on each other (thereby minimising communication between modules)

Design guidelines

5.20

Reasonable SizeKeep modules reasonably small

CohesionAll activities within a module should

pertain to the same process

Shared UseSubordinate modules should be called

by several superordinate modules where possible

Design guidelines cont.

5.21

These are important design principles related to the concept of “black box” design

Black Box Design

Defined outputsDefined functionUnknown internal processing

(How ?)We should be able to exploit a "black box"

without knowing what's inside it

Coupling and cohesion

5.22

Measure of the strength of association of elements

within a module

LEVELS OF COHESION

FUNCTIONALSEQUENTIALCOMMUNICATIONALPROCEDURALTEMPORALLOGICALCOINCIDENTAL

Black box

Not quite soblack box

Grey box

White box

Strongest, best maintainability

Weakest, worst maintainability

Cohesion

5.23

Functional: the highest level of cohesion in which all instructions in the module pertain to a single function or task

Sequential: instructions are related by data rather than by the task being performed (ie. the output of one instruction becomes the input to the next instruction)

Communicational: each instruction in the module acts on the same data but without any sequential dependence

Levels of cohesion

5.24

Procedural: instructions are related through flow of control, and sequence is still important

Temporal: instructions are related through flow of control, although sequence is not important

Logical: instructions hardly related at all; execution is determined from outside the module

Coincidental: the lowest level, where instructions have no relationship to each other at all

Levels of cohesion

5.25

THE DATA TRAVELLING BETWEEN MODULESIS CALLED COUPLING

UPDATE RENTALINVENTORY

GET VALIDATEDTRANSACTION

QUIT Control Info.VALIDATEDTRANSACTION

Data

(flags)

Coupling

5.26

SHOWS THE DEGREE OF INTERDEPENDENCEBETWEEN TWO MODULES

(shows modular independence and cohesion)

A

B

A

B

The more wemust know of module B to understandmodule AThe more

closely coupledA is to B

WE ARE AIMING FOR LOOSELY COUPLED SYSTEMS

Coupling

5.27

DATA COUPLING

STAMP COUPLING

CONTROL COUPLING

COMMON COUPLING

CONTENT COUPLING

Good, or loose

Bad, or tight

Types of coupling

5.28

Data: highest form: modules are independent of each other and communicate through passing data elements

Stamp: modules communicate through data records rather than data elements; more complex

Control: modules communicate through control flags

Common: modules communicate through common, shared data

Content: lowest form: modules refer to the inner workings of other modules

Types of coupling

5.29

FORMATERROR MESSAGE

FORMATCUSTOMER ERROR

Diagnostic Code

CustError 37

AVOID WIRED-IN VALUES

ALL THE DATA MUST BE HONESTLY SHOWN

Coupling

5.30

The more efficient a system, the harder it may be to modify.

A system designed for flexibility may be slower in running time, and may take up more space.

May have to compromise our modules in practice because of performance

Flexibility and efficiency

Client: Pathology DepartmentSystem: Teaching ResourcesDiagram: 2.2 Lend to staff

Logical

Loan due date

2.2.2

check item available

2.2.1

check borrower

status

2.2.3

update item

2.2.4

record loan

Borrower

Item

Loan

Acceptable staff borrower

staff ID

Available item

Borrowed item

Staff borrower status

Item availability

Item requested

5.32

The output from the systems analysis stage includes: proposed logical DFDs data dictionary entries for procedures, data flows,

data stores Identifying and designing user tasks is a component

of systems design that is frequently overlooked. User procedures are often considered to be defined

by the user manual. Little, if any, thought may be given to the design of the interface (and user manual) to take human procedures into account.

As a result, many systems are poorly accepted and some may not be used at all.

User task design

5.33

It is necessary to define an automation boundary.

Where should this boundary be drawn? What are the activities that should be

undertaken by humans and what undertaken by machines?

In principle, a good system is one that makes best use of both human and machine characteristics in a co-operative activity.

The Automation Boundary

5.34

Humans slow at routine tasks make frequent errors capable of judgement can adapt to new

situations good at problem

solving creative can understand the

context of the work

Computers• fast at routine tasks• accurate in routine

tasks • incapable of

judgement• must be

reprogrammed for new situations

• must be programmed for specific problem types

• not creative• don’t understand

context

Humans vs computers

5.35

cycle time short longconstraints precise loose

constraining discretionaryroutine non-routine

skill level low highskill count few manyspecialisation few tasks

varied tasks

Willcocks, Mason (1987). Computerising work: People, systems design and workplace relations, Paradigm, London.

Describing a Job: Task dimensions

5.36

Frederic Taylor (1856 - 1915) was an early management theorist. He developed a theory of “scientific management” that emphasised the mechanical and physiological character of management.

Scientific Management-based approaches: divide mental from manual labour; job planning and

discretion given to managers maximise specialisation in skills minimise learning and training time achieve a full work load minimise the number and variety of tasks in a job create short-cycle jobs that are as repetitive as

possible

(Willcocks & Mason, 1987)

Scientific Management

5.37

“Scientific management-based approaches can result in large increases in productivity and sometimes have helped to improve the ergonomic aspects of work performance. however, they create organisational rigidities and inflexibilities ... [they] underutilise human capabilities and creativity at work, and are often seen as devices for management to increase control over their subordinates...”

Willcocks & Mason (1987).

“Scientific management” is no longer considered the ideal!

Scientific Management

5.38

The tasks for which we are designing take place in a larger context. the information system is

part of the technical-economic subsystem

there are other components of this technical-economic subsystem (photocopiers, fax ...)

the other subsystems play an important part in work life

So far we have considered the technical analysis and design of a system, what about the social aspects?

Formalmanagerial /

socialsubsystem

Technical-economicsubsystem

Informal social

subsystem

General environment

organisation boundary

(Willcocks & Mason, 1987)

Put the system in context

5.39

Organisation: structure levels of hierarchy rules/procedures management

styles spans of control

People: attitudes motivations trust morale communications social interactions relationships

Technology:• tools• machinery• software• hardware• techniques

Tasks:• work flow• task configurations• information flow

(Willcocks & Mason, 1987)

A socio-technical systems model

5.40

The subsystems shown are interdependent. a change in one subsystem will have

an impact on the other two a change in one subsystem may

require changes in the other two systems designers need to consider all

three subsystems A technically efficient system is no

guarantee of increased productivity and/or job satisfaction.

[Appropriate use of the socio-technical model requires training/education in appropriate social disciplines.]

(Willcocks & Mason, 1987)

The socio-technical model

5.41

Sequence handle data in a “natural” order human eye movement is left-to-right and top-to-

bottom (cultural differences?) Grouping

make use of groups of data to “chunk” tasks “chunking” helps humans reduce information load short term memory capacity ~ 7 plus or minus 2

Repetition repeated tasks need a break - make use of closure

points All these are important ... BUT ...

Rational Task Design

5.42

concentration is affected by: interruptions

phone visitors events in the corridor equipment breakdowns, malfunctions

pressure deadlines pressure to achieve

personal problems problems with family problems with relationships problems with work relationships

Good design should minimise the impact.

What really happens…

5.43

Too much attention to computing solutions often results in poor task design including: highly detailed data entry procedures

(too hard to remember) intolerant error management

(blaming the user for making mistakes) inconsistent procedures (causing confusion) crowded screens (too hard to follow) ambiguous instructions and messages

(need to look them up in the manual - if they can be found at all!)

These issues are significant when you take into account the problems of working in a real environment.

Poor Task Design

5.44

fit the software to the user’s mental model of their organisational task, e.g. invoicing, controlling stock)

understand the user (build a profile of their skills and knowledge) naive, casual, expert

understand the role of the system in the task: mainly data entry OR requests for information OR

active dialogue constant use, frequent use, infrequent use compulsory or discretionary use of the system

design the task to fit

Aims in task design

5.45

Many systems perform functions previously performed manually or with non-computer aids.

If the new system changes the way tasks are performed then: users may need new ways of thinking about the

task, i.e., new perceptual models

dialogs need to be designed to encourage appropriate perceptual models

additional training may be required

Changing Task Structure

5.46

Changes in: technology software capabilities expectations of work social structures

are likely to change our views of task design in future. However, human capabilities change little.

Remember to design for the human in the job.

Future developments