ims9001 systems analysis and design n.
Download
Skip this Video
Download Presentation
IMS9001 - Systems Analysis and Design

Loading in 2 Seconds...

play fullscreen
1 / 69

IMS9001 - Systems Analysis and Design - PowerPoint PPT Presentation


  • 139 Views
  • Uploaded on

IMS9001 - Systems Analysis and Design. Designing system architecture; finalising design specifications. Design (How?). Define how the system will be implemented. System Requirements Specification Report. Various Sources. ANALYSIS. Design ideas/opinions. Select a design

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'IMS9001 - Systems Analysis and Design' - dalmar


Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
ims9001 systems analysis and design
IMS9001 - Systems Analysis and Design

Designing system architecture;

finalising design specifications

design how
Design (How?)
  • Define how the system will be implemented

System Requirements

Specification Report

Various

Sources

ANALYSIS

Design ideas/opinions

Select a design

strategy and specify

details

Design Options

System

Vendors

Hardware/Software

deals

Selected Design

Option

Design in Progress

Report

Technical Design

Report

SystemOwners/Users

IMPLEMENTATION

system architecture
System Architecture
  • System architecture is concerned with the technical and organisational configuration of the design of an application system
  • An architecture defines the technologies to be used by the information systems in terms of its data, process interface and network components.
  • The architecture must be consistent with:-
    • budget constraints
    • organisational constraints
    • existing technology
    • requirements identified by analysis
system architecture components
System Architecture Components
  • Processing
  • Data
  • Communication

These components are interrelated and must be considered in conjunction with each other.

architecture components processing
Architecture Components:Processing
  • The evolution of computing environments has been largely determined by technological advances in computers and the convergence of computing and communications technologies
  • Processing can be:
    • Centralised : e.g Host and terminals
    • Distributed :
      • co-operative as in client/server
      • functionally distributed as in regional processing and centralised reporting
distributed versus centralized systems
Distributed versus Centralized Systems

A distributed system is one in which the DATA, PROCESS, and INTERFACE components of an information system are distributed to multiple locations in a computer network. Accordingly, the processing workload is distributed across the network.

In centralized systems, a central, multi-user computer (ususally a mainframe) hosts all the DATA, PROCESS, and INTERFACE components of an information system. Users interact with the host via terminals (or PC terminal emulators), but virtually all of the processing is done on the host computer.

(From 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 11.)

slide7

Distributed Computing Architecture

Development of distributed computing involves two opposing trends:

1. to break up applications and push the resulting fragments towards the end user.

  • price/performance benefits of developing and executing applications on workstations;
  • demands from end users for local autonomy and additional functionality to improve their productivity.

2 to consolidate data to meet the end user’s need for corporate data

  • affects systems integration requirements and results in the centralisation of applications on large powerful mainframes;
  • increases the need for high levels of integrity, performance and availability.

The pivotal architectural question is:

how and where are computing resources distributed in this architecture ?

why distributed systems
Why Distributed Systems?
  • Modern business systems are already decentralized and distributed.
  • Distributed computing moves information and services closer to the customers and users who need them.
  • Distributed computing consolidates the power of personal computers across the enterprise.
  • Distributed computing solutions are more user-friendly because they utilize the PC as the end user interface.
  • Personal computers and network servers are cheaper than centralized mainframe computers

(From 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 11.)

architecture components computers
Architecture Components:Computers
  • Mainframe - a large, centralised computer (e.g. an IBM AS400, UNISYS, FUJITSU) normally interfacing large numbers of terminals with large, centralised databases, running many concurrent processes.
  • Server - a medium sized computer, normally providing services, particularly shared data resources and printing, to a number of PCs.
  • Terminal - usually a PC, but may be a less intelligent device. Typically running a GUI interface and interacting with a single user at a time.
processing architecture types
Processing Architecture:Types
  • Host-based: all processing is performed on one computer system to which are attached unintelligent, “dumb”, character-based terminals. Processing is totally non-distributed.
  • Master-slave: slave computers are attached to a master computer and perform application processing functions but only as directed by their master. The minimal distribution is uni-directional from master to slave although slave has some limited local processing capability (eg. field editing).
  • Shared-device: PC workstations are attached to a system device, the server, that allows them to share common resources, files, disk and printer. All application processing is performed on the PC and only certain functions are distributed.
host based processing
Host-based Processing

disk

host CPU

(running application)

terminals

master slave processing

disk

Master-slave Processing

host CPU

(running application)

shared device processing

disk

Shared-device Processing

client application

client application

server with shared disk and printer

LAN

client application

processing architecture types1
Processing Architecture:Types

“Co-operative Computing”

  • Client-server: Workstations become clients as they request servers to process significant parts of the application running on the workstation in addition to sharing resources. The application is now distributed and the client and server cooperate to successfully execute the application. The client initiates interaction but the server enforces control over what services and data the client can request and arbitrates conflict between clients.
  • Peer-to-peer: Each participating system is equal and can both request services from and provide services to all other systems. There is no distinction between client and server and in intelligent networks, the server workload can be distributed and shared between participating systems.
client server

disk

Client-server

client

application

client application

server with shared disk and printer

LAN or WAN

client application

peer to peer

disk

disk

disk

disk

disk

disk

Peer-to-peer
file server architecture
File Server Architecture

A local area network (LAN) is a set of client computers (PCs) connected to one or more sever computers either through cable or wireless connections over relatively short distances.

A file server system is a LAN-based solution in which a server hosts only the data layers of an information system. All other layers are implemented on the client computers. Disadvantages include:

  • Frequently excessive network traffic to transport data between servers and clients.
  • Client must be fairly robust (“fat”) because it does most of the work
  • Database integrity can be easily compromised.

(From 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 11.)

client server architecture the clients
Client/Server Architecture—The Clients

A client/server system is a solution in which the presentation, presentation logic, application logic, data manipulation, and data layers are distributed between client PCs and one or more servers.

A thin client is a personal computer that does not have to be very powerful (or expensive) in terms of processor speed and memory because it only presents the user interface to the user.

A fat client is a personal computer or workstation that is typically more powerful (and expensive) in terms of processor speed, memory, and storage capacity. Most PCs are considered to be fat clients.

(From 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 11.)

client server architecture the servers
Client/Server Architecture—The Servers
  • A database server hosts one or more shared databases but also executes all data manipulation commands.
  • A transaction server hosts services that ultimately ensure that all database updates for a single transaction succeed or fail as a whole.
  • An application server hosts the application or business logic and services for an information system.
  • A messaging or groupware server hosts services for e-mail, calendaring, and other work group functionality.
  • A web server hosts Internet or intranet web sites and services, communicating thorugh thin-client interfaces such as web browsers.

(From 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 11.)

distributed computing layers
Distributed Computing Layers
  • Presentation layer—the user interface, the presentation of inputs and outputs to the user
  • Presentation layer logic— any processing required to generate the presentation, such as input editing
  • Application logic layer— the logic and processing to support the business application: the business rules, policies, and procedures, e.g. credit checking, calcualtions
  • Data manipulation layer—the commands and logic required to store and retrieve data to and from the database
  • Data layer—the actual stored business data

(From 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 11.)

client server solutions
Client/Server Solutions
  • A distributed presentation client/server system is a solution in which the presentation and presentation logic layers only are shifted from the server to reside on the client. The application logic, data manipulation, and data layers remain on the server (frequently a mainframe).
  • A distributed data client/server system is a solution in which the data and data manipulation layers are placed on the server(s), and the application logic, presentation logic, and presentation layers are placed on the clients. This is sometimes called two-tiered client/server computing.
  • A distributed dataand application client/server system is a solution in which: (1) the data and data manipulation layers are placed on their own server(s), (2) the application logic is placed on its own server, and (3) the presentation logic and presentation layers are placed on the clients.This is sometimes called three- or n-tieredclient/server computing. It requires design partitioning.

Partitioning is the art of determining how to best distribute or duplicate application components (DATA, PROCESS, and INTERFACE) across the network.

(From 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 11.)

client server solutions internet and intranet based architectures
Client/Server Solutions: Internet- and Intranet-based Architectures
  • A network computing system is a multi-tiered solution in which the presentation and presentation logic layers are implemented in client-side Web browsers using content downloaded from a Web server. The presentation logic layer then connects to the application logic layer that runs on the application server, which subsequently connects to the database servers on the backside of the system.The greatest potential of this approach is its applicability to redesign of traditional information systems to run on an intranet. An intranet is a secure network, usually corporate, that uses Internet technology to integrate desktop, work group, and enterprise computing into a cohesive framework.

(From 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 11.)

co operative computing
Co-operative computing
  • Advantages:
    • exploits the power and relative low cost of desktop computing technology.
    • increased software portability
    • reduction in the application backlog
    • allows processing to take place at the source of the data thus reducing network traffic and response times and increasing the capacity and effective throughput of the network.
    • facilitates the use of GUIs
    • encourages open systems as clients and servers are independent of hardware and software platforms.
co operative computing1
Co-operative computing
  • Disadvantages:
    • bottlenecks at the server if significant portion of the application resides there.
    • distributed applications are more complex thus increasing the cost of application development, maintenance and support in terms of the run-time environment and management of the distributed environment.
architecture components communication
Architecture Components:Communication
  • A communication system:
    • is a mechanism that allows distributed resources to exchange data and control information.
    • can be implemented as totally transparent or may be visible to the user.
    • requires physical connection between interacting nodes.
slide27

Communications: Definitions

  • A communication system is a collection of hardware and software that supports intersystem and interprocess communication between software components in distributed nodes.
  • A network provides a physical path between the nodes.
  • A link is the direct connection between two (or more) systems.
  • The name of an object indicates a system, process or a node.
  • An address indicates where the named object is.
  • A route tells how to get there.
architecture components data
Architecture Components:Data
  • Data architecture requires additional information about the essential data model:
    • volumes
    • locations
    • events
    • distribution
  • This additional information not only impacts the data but also the processing and the communication choices.
slide29

Data Architecture :Issues

  • For distributed data architecture the following issues need to be considered:
    • data ownership
    • data transfer speeds
    • network utilisation
    • query processing
    • catalogue management
    • update propagation
    • concurrency controls
    • recovery controls
  • Similar issues arise in other architectures
slide30

Data Architecture :Distributed Data Objectives

  • local autonomy
  • non reliance on a central site
  • continuous operations
  • location independence
  • fragmentation independence
  • replication independence
  • distributed query processing
  • distributed transaction processing
  • hardware independence
  • operating systems independence
  • network independence
  • DBMS independence

C. J. Date 1995

data architectures
Data architectures
  • Historically central control of data has been considered essential
  • Data is easier to manage as a shared resource: the only practical way used to be on a central computer
  • Client/server and network computing allow distribution of data without loss of control via advances in distributed relational database technology

(From 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 11.)

data architectures1
Data architectures

A relational database stores data in tabular form. Each file is implemented as a table. Each field is a column in the table. Each record is a row. Related records between two tables are implemented by intentionally duplicated columns in the two tables.

A distributed relational database distributes or duplicates tables to multiple database servers located in geographically important locations, e.g. different sales regions

A distributed relational database management system (distributed RDBMS) is a software program that controls access to and maintenance of stored data in the relational format. It provides for backup, recovery and security.

The processing of all commands executes on the database server, reducing data traffic on the network.

(From 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 11.)

types of data base distribution
Types of Data(base) Distribution

Most RDBMSs support two types of distributed data:

Data partitioning truly distributes rows and columns of tables to specific database servers with little or no duplication between servers.

  • Vertical partitioning assigns different columns to different servers.
  • Horizontal partitioning assigns different rows to different servers.

Data replication duplicates some or all tables (or parts of tables) on more than one database server. Database technology controls acces to, and manages consistecy of duplicated data across the servers.

(From 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 11.)

data architecture
Data architecture
  • The data architecture must specify the RDBMS technology and the partitioning or replication of data
  • It is selected based on the desired client/server or network computing model and the database technology needed to support that model
  • Many organisations have standardised on their PC RDBMS and their distributed, enterprise RDBMS, e.g. Microsoft Access and SQL Server
  • Technology decisions concerning data input and output technologies also need to be made

(From 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 11.)

advantages of distributed databases
Advantages of Distributed Databases
  • Increased system reliability due to redundancy
  • Local control of data … helps with improved data integrity and administration
  • Lower communication costs by reducing traffic
  • Faster response since most applications use data at a local site
disadvantages of distributed databases
Disadvantages of Distributed Databases
  • Software cost and complexity for a distributed environment
  • Data integrity …control problems with multiple and dispersed sites
  • Slow response if data and software not distributed properly
a method for system architecture design
A Method for System Architecture Design
  • Draw a physical DFD to represent the network architecture. Each physical process symbol will represent a client or server processor.
  • For each physical process on the above network architecture model, draw a physical DFD that shows the event processes that are assigned to (or duplicated on) that physical processor.
  • For appropriate processes on the above system DFDs, draw draw more detailed physical DFDs that factor the event into design units.
  • Draw physical, primitive DFDs for appropriate processes from step 3.

(From 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 11.)

a method for system architecture design design units
A Method for System Architecture Design: Design units

A design unit is a self-contained collection of processes, data stores, and data flows that share similar design characteristics.

A design unit serves as a subset of the total system whose inputs, outputs, files and databases, and programs can be designed, constructed, and tested as a self-contained unit.

Ultimately, design units must be integrated into a whole system.

(From 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 11.)

a method for system architecture design the network architecture dfd
A Method for System Architecture Design: The Network Architecture DFD

A network architecture is documented as a physical DFD that allocates processors (clients and servers) and possibly devices (machines and robots) across a network and establishes:

  • the connectivity between clients and servers
  • where users will interface with the processors

(From 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 11.)

slide40

Finalising Design Specifications

Need for systems to be developed more quickly today

The lines between analysis and design and design and implementation are blurring

Traditional approaches allowed for a break between design and implementation

Other approaches, such as CASE and prototyping, have caused overlap between the two phases

from Hoffer, J.A., et al. (2002). Modern Systems Analysis and Design,

(3rd edition) Addison-Wesley, Reading MA, USA, Chap 15.

the process of finalizing design specifications
The Process of Finalizing Design Specifications
  • Less costly to correct and detect errors during the design phase
  • Two sets of guidelines
    • Writing quality specification statements
    • The quality of the specifications themselves
  • Quality requirement statements
    • Correct
    • Feasible
    • Necessary
    • Prioritized
    • Unambiguous
    • Verifiable

from Hoffer, J.A., et al. (2002). Modern Systems Analysis and Design,

(3rd edition) Addison-Wesley, Reading MA, USA, Chap 15.

the process of finalizing design specifications1
The Process of Finalizing Design Specifications
  • Quality requirements
    • Completely described
    • Do not conflict with other requirements
    • Easily changed without adversely affecting other requirements
    • Traceable back to origin

from Hoffer, J.A., et al. (2002). Modern Systems Analysis and Design,

(3rd edition) Addison-Wesley, Reading MA, USA, Chap 15.

finalising design specifications
Finalising design specifications
  • Key deliverable:

A set of physical design specifications

  • Sample contents:
    • Overall system description
    • Interface requirements
    • System features
    • Non-functional requirements
    • Other requirements
    • Supporting diagrams and models

see Hoffer et al (2005) p 445

finalising design specifications1
Finalising design specifications

Overall system description:

  • Functions
  • Operating environment
  • Types of users
  • Constraints
  • Assumptions and dependencies

Interface requirements

  • User interfaces
  • Hardware interfaces
  • Software interfaces
  • Communication interfaces
finalising design specifications2
Finalising design specifications

System features

  • Feature 1 description….
  • Feature n description

Non-functional requirements

  • Performance
  • Safety
  • Security
  • Software quality
  • Business rules

Other requirements

Supporting diagrams and models

finalising design specifications3
Finalising design specifications

Representing design specifications:

  • Written document with diagrams and models – traditional approach uses structure charts
  • Computer-based requirements/CASE tool to input and manage specifications
  • Working prototype to capture specifications
  • Combinations of the above
finalising design specifications data design
Finalising design specifications: data design
  • Physical file and database design requires:
  • Normalised relations
  • Attribute definitions
  • Where and when data is entered, retrieved, updated and deleted
  • Response time and data integrity needs
  • Implementation technologies to be used
  • Design physical tables and file structures according to performance factors and constraints of the particular application
structure charts for process design
Structure charts for process design
  • Structure charts show the hierarchical structure of the software modules in a system
  • Relationships between the modules, including data and messages passed, are made clear
  • Structured design principles are followed to ensure well-designed system structure
physical process design
Physical process design
  • 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: correctness, completeness, maintainability, etc.
  • A structure chart represents the flow and processing of data as a system structure
structured design
Structured Design
  • Partition the system into "black boxes"
  • Organise the "black boxes" into hierarchies suitable for computer implementation
  • Use diagrams to make the system structure easy to understand
  • Use 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
structure charts
Structure Charts

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

MODULES

Each of these

modules is

coded

separately

GET VALID

TRANSACTION

MODULE: A named,

bounded, set of statements

to do a single task, having

an identifier by which it can

be referenced as a unit.

structure charts1
Structure charts

Start and end here

USE A HIERARCHY:

input

output

• Top members (managers) co-ordinate and control

• Subordinates process

• A manager should have no more than 7+2 immediate

subordinates reporting directly to it

deriving structure charts
Deriving structure charts
  • Each business process will generate its own structure chart, using a design strategy such as Transform 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).
transform analysis
Transform analysis

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 an example

1

Make A

2

check A

5

create X

6

Make Y

A

6

Put Y

Y

input 1

B

X

N

centraltransform

efferent leg

3

Make M

M

4

check M

input 2

Main

afferent legs

X

N

B

X

N

B

Get B

Get N

Create X

Put X

M

N

A

X

B

Y

M

A

Y

Get A

Make B

Get M

Make N

Make Y

Put Y

A

input1

input2

M

input1

input2

Make A

Get input2

Make M

Get input1

Transform analysis - an example
finalising design specifications4
Finalising design specifications

Prototyping

  • Construction of the model of a system
  • Allows developers and users to
    • Test aspects of the overall design
    • Check for functionality and usability
  • Iterative process
  • Two types
    • Evolutionary Prototyping
    • Throwaway Prototyping
finalising design specifications5
Finalising design specifications

Evolutionary Prototyping

  • Begin by modeling parts of the target system
  • If successful, evolve rest of the system from the prototype
  • Prototype becomes actual production system
  • Often, difficult parts of the system are prototyped first
  • Exception handling must be added to prototype

Throwaway Prototyping

  • Prototype is not preserved
  • Developed quickly to demonstrate unclear aspect of system design
  • Fast, easy to use development environment aids this approach
design features
Design features
  • 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)
user task design
User task design
  • 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, systems may be poorly accepted and some may not be used at all.
the human computer boundary
The human/computer 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.
humans vs computers
Humans vs Computers
  • 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
    • 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
task dimensions
Task dimensions

cycle time: short long

constraints: precise loose

constraining discretionary

routine non-routine

skill level: low high

skill count: few many

Specialisation: few tasks varied tasks

rational task design
Rational task design
  • 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 ~ 7plus or minus 2
  • Repetition
    • repeated tasks need a break - make use of closure points
  • All these are important ... BUT ...
what really happens
What really happens
  • 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.
poor task design
Poor task design
  • 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)
aims of task design
Aims of task design
  • 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
changing task structure
Changing task structure
  • 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
user task design1
User task design

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

references
References
  • HOFFER, J.A., GEORGE, J.F. and VALACICH (2005) Modern Systems Analysis and Design, (4th edition), Pearson Education Inc., Upper Saddle River, New Jersey, USA. Chapters 13, 14
  • WHITTEN, J.L., BENTLEY, L.D. and DITTMAN, K.C. (2001) 5th ed., Systems Analysis and Design Methods, Irwin/McGraw-HilI, New York, NY. Chapter 11