Clarke, R. J (2001) L951-04: 1

Critical Issues in Information Systems

BUSS 951

Lecture 4Design 1: Technical and Methodological Aspects

Clarke, R. J (2001) L951-04: 2

Notices (1)General

Make sure you have a copy of the BUSS951 Subject Outline

BUSS951 is supported by a website (available from Tomorrow), where you can find out the latest Notices and get Lecture Notes, Tutorial Sheets, Assignments etc

www.uow.edu.au/~rclarke/buss951/buss951.htm Pick up assignment 1 now! Note there has been a change in the Lecture

schedule we will move lectures 8->4 and 9->5

Clarke, R. J (2001) L951-04: 3

Notices (2)Readings for Week 4

1. Watson, Rainer and Koh (1991) “Executive Information Systems: A Framework for Development and a Survey of Current Practices”

We use this paper as an example of applying the kind of analysis needed for your assignment

Clarke, R. J (2001) L951-04: 4

Agenda (1)

Organisational MetaphorsMachinesOrganisms

Specific Organisational TheoriesComplex OrganisationsNetwork OrganisationsPopulation Ecology Models

Clarke, R. J (2001) L951-04: 5

Life Cycles

Clarke, R. J (2001) L951-04: 6

What is a Life Cycle? (1) Life Cycles are generalisations of the

steps or phases leading to the development of an IS

emerged from fields of evolutionary biology and cybernetics

models of software evolution date back to the earliest projects developing large software systems (circa 1956)

Clarke, R. J (2001) L951-04: 7

What is a Life Cycle? (2)

provide an abstract scheme accounting for the ‘natural’ or engineered development of systems

simplify the actual steps or development work practices found in real methodologies

Clarke, R. J (2001) L951-04: 8

What is a Life Cycle? (3)Needs served

planning, organisingstaffing, coordinatingbudgeting, and directing software development

activities

Clarke, R. J (2001) L951-04: 9

What is a Life Cycle? (4)Prescriptive Life-cycles

describe how systems should be developed (generally as a set of steps)

easier to describe, however many software development details are ignored

Clarke, R. J (2001) L951-04: 10

What is a Life-Cycle? (5)Descriptive Life Cycles

characterise how systems are actually developed

much less common; more difficult to describe because data must be collected throughout systems life

system specifictherefore, prescriptive models are

dominant

Clarke, R. J (2001) L951-04: 11

Life Cycles & System Change (1)Two distinct views

life cycles suggest ways in which a system changes or evolves over time

two distinct views on systems change:evolutionist modelsevolutionary models

Clarke, R. J (2001) L951-04: 12

Life Cycles & System Change (2)Evolutionistic Models

describe system change as progress through a series of stages eventually leading to some final stage

useful as organising frameworks for managing development effort

poor predictors of why certain changes are made to a system & why systems evolve in specific ways

Clarke, R. J (2001) L951-04: 13

Life Cycles & Systems Change (3)Evolutionary Models

focus attention to the mechanisms and processes that change systems

less concerned with stages of development and more with the technological mechanisms and organisational processes that change systems over space and time

Clarke, R. J (2001) L951-04: 14

How many Life-Cycles? (1)

Very much smaller number of life cycles than actual methodologies

In rank order of popularity:SDLC (Systems Development Life Cycle)RPLC (Rapid Protoyping Life Cycle)EDLC (Evolutionary Development Life Cycle)Others (Whirling, Curriculum)

Clarke, R. J (2001) L951-04: 15

SDLC

Clarke, R. J (2001) L951-04: 16

SDLC

Construction

Analysis

Design

Initiation

Maintenance &Evaluation

Operation &Acceptance

Clarke, R. J (2001) L951-04: 17

SDLCB-Model

Construction

Analysis

Design

Analysis

DesignDesign

InitiationInitiation

Construction

Operation

Acceptance

Evaluation

Initiation

Maintenance Cycle

Development Path

Clarke, R. J (2001) L951-04: 18

Benefits of SDLC (1)Some Advantages

traditional SDLC has brought a much-needed discipline to systems development

much better to use SDLC than not to use any approach!

can be used to create successful systems

Clarke, R. J (2001) L951-04: 19

Benefits of SDLC (2)

fits in with structured techniquesstructured programming: use of

restricted control structures: sequence, selection, repetition

structured design: cohesion- one & only one function- and coupling- minimal dependency of modules

structured analysis: Yourdon and DeMarco, Gane and Sarson- data flow (which is actually process oriented view

Clarke, R. J (2001) L951-04: 20

Problems with SDLCDocument Driven Development

SDLC is document driveneach stage usually has a specific

deliverable (often a document) used at a subsequent stage

reflected in the Computer Aided Software Engineering tools (CASE) used to support SDLC

Clarke, R. J (2001) L951-04: 21

Problems with SDLCSome Flaws...

implementation begins after requirments and design documents have been completed

if the system specification is complete and the design is of high quality, implementation will probably be straight forward

Clarke, R. J (2001) L951-04: 22

Problems with SDLC...Some Flaws

however, system design is often flawed

important design decisions must be made during implementation

specification and design errors not identified during implementation are built into the system

Clarke, R. J (2001) L951-04: 23

Problems with SDLCUsers

pre-specifying user requirements prior to development of IS is difficult

traditional deliverables are poor communication tools

users often do not know what they want until they can see a working model

Clarke, R. J (2001) L951-04: 24

Problems with SDLCUsers

user involvement in the requirements definition and reviews of overall system design do not guarantee user satisfaction

users are often disappointed with the completed system

Clarke, R. J (2001) L951-04: 25

Problems with SDLCUsers

traditional pre-specification methods often don’t help in many user-oriented applicationsdecision support systemsdata base applications

particularly when requirements and decision processes are unclear

Clarke, R. J (2001) L951-04: 26

Increasing UncertaintyUser Requirements

Management Information Systems•Executive Information Systems•Decision Support Systems•Information Reporting Systems

Operations Information Systems•Office Automation Systems•Transaction Processing Systems•Process Control Systems

Levels Systems

Increasing Uncertaintyin System Requirements

Strategic Management

Tactical Management

Operational Management

Business Operations

Clarke, R. J (2001) L951-04: 27

Prototyping: Rapid & Evolutionary

Clarke, R. J (2001) L951-04: 28

Types of PrototypingRapid versus Evolutionary

prototype is discarded as a new production system is constructed using another language (Rapid Prototyping or Type II)

the basis for full-scale development of the production system (Evolutionary Prototyping or Type 1)

Clarke, R. J (2001) L951-04: 29

RPLC

DevelopPrototype

TestPrototype

AmendPrototype

Investigation

Construction

Analysis

Design

Maintenance &Evaluation

Operation &Acceptance

Clarke, R. J (2001) L951-04: 30

EDLC

DevelopPrototype

TestPrototype

AmendPrototype

Clarke, R. J (2001) L951-04: 31

Problems with Prototyping

inappropriate, incomplete, and inadequate analysis and design

unrealistic performance expectationspoorly controlled projectsreluctance to discard prototype

modelsproblems with users

Clarke, R. J (2001) L951-04: 32

Problems with Prototyping

does not necessarily improve productivity in all phases

can involve risks but these can be avoided if careful planning and project management are used

Clarke, R. J (2001) L951-04: 33

Experimental Life Cycles: Spiral & Curriculum

Clarke, R. J (2001) L951-04: 34

SLCSpiral Life Cycle

Investigation

Construction

Analysis

Design

Maintenance &Evaluation

Operation &Acceptance

Clarke, R. J (2001) L951-04: 35

CLCCurriculum Life Cycle

DeconstructionDeconstruction

IndependentIndependentConstructionConstruction

JointJointConstructionConstructionSocialSocial

SettingSetting

Clarke, R. J (2001) L951-04: 36

Methodologies

Clarke, R. J (2001) L951-04: 37

Life Cycles & Methodologies

Methodologies

Life Cycle

Use prescriptive life cycles to explain and compare between real methodologies

Clarke, R. J (2001) L951-04: 38

Classes of Methodology

Process-oriented

STRADIS (Gane and Sarson)SSADM (Learmonth & Burchett)

Human-centred

ISAC (Lundberg)ETHICS (Mumford)SSM (Checkland)

Data-oriented

IE (Martin & Finkelstein)JSD (Jackson)

Evolutionary Prototyping

Milton JenkinsSystemscraft (Crinnion)

Rapid Prototyping

Softwright SystemsJAD

Clarke, R. J (2001) L951-04: 39

What are Methodologies?

Any methodology must support two components:tools and methods for recording &

analysing the existing system, new users requirements, specifying the format of the new system

an overall framework, indicating which tools are to be used at which stages in the development process

Clarke, R. J (2001) L951-04: 40

Adaptive Methodology

can tailor to the client organisationcan tailor to the IT developerscan tailor to the individual projectthis feature is called adaptiveness

Clarke, R. J (2001) L951-04: 41

Adaptive Methodology

delete (jettison) unneeded methodsaddition of needed methods

Controls Analysis Technique (CAT)Quality Control Method(s)

Clarke, R. J (2001) L951-04: 42

Adaptive Methodology

exchange semantically similar techniques changing deMarco DFDs for Gane & Sarson

DFDs

exchange functionally similar techniques Chen ERDs for Merise ERDs Hawryskiewicsz NFs for Finklestein BNFs

Clarke, R. J (2001) L951-04: 43

Scalable Methodologies

Systemscraft is a scalable methodology

Scalability is a kind of adaptabilitycentres on the deletion (jettisoning)

or addition of methods

Clarke, R. J (2001) L951-04: 44

Scalable Methodologies

depends on the size and complexity of development projectsbut might need other methods to cope

with aspects of complex projectsor to enforce rigour on large projects

Clarke, R. J (2001) L951-04: 45

Designing Systems

Clarke, R. J (2001) L951-04: 46

Design Problemscannot be completely stated (1)...

never know when all aspects of the problem emerged- some may never be fully uncovered

generated by groups with different involvements

some problems only emerge when attempts are made to generate solutions

Clarke, R. J (2001) L951-04: 47

Design Problemscannot be completely stated (2)...

full of uncertainties both in terms of objectives, priorities

objectives, priorities likely to change during the process

shouldn’t expect static, complete formulation of design problems

problems-solutions in tension

Clarke, R. J (2001) L951-04: 48

Design Problemsrequire subjective interpretation (1)...

designers likely to devise different solutions, perceive problems differently

understanding problems depends to an extent on our ideas for solving

managers see problems as management problems etc/

Clarke, R. J (2001) L951-04: 49

Design Problemsrequire subjective interpretation (2)...

difficulties with measurement in design

problems are inevitably value-laden, therefore solutions are based on subjective perception

don’t expect entirely objective formulations of design problems

Clarke, R. J (2001) L951-04: 50

Design Problemsorganised heirarchically (1)...

design problems can often be viewed as symptoms of other ‘higher-level’ problems

eg/ building a tourist resortwaste water- a problem for plumbersa problem for tourist organisationsa problem for environmentalistsa problem for government policy makers

Clarke, R. J (2001) L951-04: 51

Design Problemsorganised hierarchically (2)...

no objective, logical way of finding the right level on which to tackle problems

decisions involve pragmatics, power, resources etc./

Clarke, R. J (2001) L951-04: 52

Design Problems and Solutions

Problems can’t be comprehensively stated require subjective interpretation tend to be hierarchically organised

Solutions inexhaustible number of different solutions no optimal solutions to design problems

Clarke, R. J (2001) L951-04: 53

Design Process (1)

the process is endlessthere is no infallibly correct processinvolves finding as well as solving

problems

Clarke, R. J (2001) L951-04: 54

Design Process (2)

inevitably involved subjective judgement

design is prescriptive; science is descriptive

designers work in the context of a need for action

Clarke, R. J (2001) L951-04: 55

Systems Design as a Social Activity

Clarke, R. J (2001) L951-04: 56

Systems Design as Social Activity (1)

social processes are always at work during the analysis, design, development and implementation of systems

all these activities take place in organisational and institutional settings

Clarke, R. J (2001) L951-04: 57

Systems Design as Social Activity (2)

need to ‘locate’ social processes and human interactions within historical and organisational contexts

some justification is required for this approach...

Clarke, R. J (2001) L951-04: 58

Systems Design as Social Activity (3)

systems development, implementation and maintenance is highly dependent on the skills of large numbers of IT professionals

communication processes and social interactions within the developer community are of great importance

Clarke, R. J (2001) L951-04: 59

Systems Design as Social Activity (4)

changes in systems development practices, whether related to technology or organisational issues, are always driven and mediated by social factors

eg./ shift from ad-hoc methods to SDLC, shift from C to C++ are all socially motivated

Clarke, R. J (2001) L951-04: 60

Systems Design as Social Activity (5)

systems development is a complex bridging process linking areas of specialized and diverse expertise; the domain of the IT professional and the domain of the user

systems development concerns itself with IT innovation, application and diffusion- all social

Clarke, R. J (2001) L951-04: 61

Summary

we will see in coming weeks that not only is systems development not a science, but...

if we theorise the social aspects of systems development and use, we can use this to create systems

knowing about the social world is enough to create CBIS!