Date post: | 21-Dec-2015 |
Category: |
Documents |
View: | 218 times |
Download: | 3 times |
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