Critical issues in information systems
This presentation is the property of its rightful owner.
Sponsored Links
1 / 61

Critical Issues in Information Systems PowerPoint PPT Presentation


  • 70 Views
  • Uploaded on
  • Presentation posted in: General

Critical Issues in Information Systems. BUSS 951. Lecture 4 Design 1: Technical and Methodological Aspects. Notices (1) General. Make sure you have a copy of the BUSS951 Subject Outline

Download Presentation

Critical Issues in Information Systems

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


Critical issues in information systems

Critical Issues in Information Systems

BUSS 951

Lecture 4

Design 1: Technical and Methodological Aspects


Notices 1 general

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


Notices 2 readings for week 4

Notices (2)Readings for Week 4

  • 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


Agenda 1

Agenda (1)

  • Organisational Metaphors

    • Machines

    • Organisms

  • Specific Organisational Theories

    • Complex Organisations

    • Network Organisations

    • Population Ecology Models


Life cycles

Life Cycles


What is a life cycle 1

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)


What is a life cycle 2

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


What is a life cycle 3 needs served

What is a Life Cycle? (3)Needs served

  • planning, organising

  • staffing, coordinating

  • budgeting, and

  • directing software development activities


What is a life cycle 4 prescriptive life cycles

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


What is a life cycle 5 descriptive life cycles

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 specific

  • therefore, prescriptive models are dominant


Life cycles system change 1 two distinct views

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 models

    • evolutionary models


Life cycles system change 2 evolutionistic models

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


Life cycles systems change 3 evolutionary models

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


How many life cycles 1

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)


Critical issues in information systems

SDLC


Critical issues in information systems

SDLC

Initiation

Analysis

Maintenance &

Evaluation

Operation &

Acceptance

Design

Construction


Sdlc b model

Analysis

Design

Design

Construction

Initiation

Initiation

SDLCB-Model

Development Path

Construction

Acceptance

Maintenance Cycle

Operation

Design

Evaluation

Initiation

Analysis


Benefits of sdlc 1 some advantages

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


Benefits of sdlc 2

Benefits of SDLC (2)

  • fits in with structured techniques

    • structured 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


Problems with sdlc document driven development

Problems with SDLCDocument Driven Development

  • SDLC is document driven

  • each 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


Problems with sdlc some flaws

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


Problems with sdlc some flaws1

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


Problems with sdlc users

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


Problems with sdlc users1

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


Problems with sdlc users2

Problems with SDLCUsers

  • traditional pre-specification methods often don’t help in many user-oriented applications

    • decision support systems

    • data base applications

  • particularly when requirements and decision processes are unclear


Increasing uncertainty user requirements

Increasing UncertaintyUser Requirements

Levels

Systems

Strategic

Management

  • Management Information Systems

  • Executive Information Systems

  • Decision Support Systems

  • Information Reporting Systems

  • Operations Information Systems

  • Office Automation Systems

  • Transaction Processing Systems

  • Process Control Systems

Tactical

Management

Operational

Management

Business

Operations

Increasing Uncertainty

in System Requirements


Prototyping rapid evolutionary

Prototyping: Rapid & Evolutionary


Types of prototyping rapid versus evolutionary

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)


Critical issues in information systems

Develop

Prototype

Analysis

Test

Prototype

Design

Amend

Prototype

Construction

RPLC

Investigation

Maintenance &

Evaluation

Operation &

Acceptance


Critical issues in information systems

Develop

Prototype

Test

Prototype

Amend

Prototype

EDLC


Problems with prototyping

Problems with Prototyping

  • inappropriate, incomplete, and inadequate analysis and design

  • unrealistic performance expectations

  • poorly controlled projects

  • reluctance to discard prototype models

  • problems with users


Problems with prototyping1

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


Experimental life cycles spiral curriculum

Experimental Life Cycles: Spiral & Curriculum


Slc spiral life cycle

Design

Construction

SLCSpiral Life Cycle

Investigation

Maintenance &

Evaluation

Analysis

Operation &

Acceptance


Clc curriculum life cycle

CLCCurriculum Life Cycle

Deconstruction

Joint

Construction

Social

Setting

Independent

Construction


Methodologies

Methodologies


Life cycles methodologies

Life Cycle

Methodologies

Life Cycles & Methodologies

Use prescriptive life cycles to explain

and compare between real methodologies


Classes of methodology

Classes of Methodology

Data-oriented

IE (Martin & Finkelstein)

JSD (Jackson)

Process-oriented

STRADIS (Gane and Sarson)

SSADM (Learmonth & Burchett)

Rapid Prototyping

Softwright Systems

JAD

Human-centred

ISAC (Lundberg)

ETHICS (Mumford)

SSM (Checkland)

Evolutionary Prototyping

Milton Jenkins

Systemscraft (Crinnion)


What are methodologies

What are Methodologies?

  • Any methodology must support two components:

    • toolsand 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


Adaptive methodology

Adaptive Methodology

  • can tailor to the client organisation

  • can tailor to the IT developers

  • can tailor to the individual project

  • this feature is called adaptiveness


Adaptive methodology1

Adaptive Methodology

  • delete (jettison) unneeded methods

  • addition of needed methods

    • Controls Analysis Technique (CAT)

    • Quality Control Method(s)


Adaptive methodology2

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


Scalable methodologies

Scalable Methodologies

  • Systemscraft is a scalable methodology

  • Scalability is a kind of adaptability

  • centres on the deletion (jettisoning) or addition of methods


Scalable methodologies1

Scalable Methodologies

  • depends on the size and complexity of development projects

    • but might need other methods to cope with aspects of complex projects

    • or to enforce rigour on large projects


Designing systems

Designing Systems


Design problems cannot be completely stated 1

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


Design problems cannot be completely stated 2

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


Design problems require subjective interpretation 1

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/


Design problems require subjective interpretation 2

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


Design problems organised heirarchically 1

Design Problemsorganised heirarchically (1)...

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

  • eg/ building a tourist resort

    • waste water- a problem for plumbers

    • a problem for tourist organisations

    • a problem for environmentalists

    • a problem for government policy makers


Design problems organised hierarchically 2

Design Problemsorganised hierarchically (2)...

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

  • decisions involve pragmatics, power, resources etc./


Design problems and solutions

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


Design process 1

Design Process (1)

  • the process is endless

  • there is no infallibly correct process

  • involves finding as well as solving problems


Design process 2

Design Process (2)

  • inevitably involved subjective judgement

  • design is prescriptive; science is descriptive

  • designers work in the context of a need for action


Systems design as a social activity

Systems Design as a Social Activity


Systems design as social activity 1

Systems Design as Social Activity (1)

  • social processes are always at workduring the analysis, design, development and implementation of systems

  • all these activities take place in organisational and institutional settings


Systems design as social activity 2

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


Systems design as social activity 3

Systems Design as Social Activity (3)

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

  • communication processesand social interactions within the developer community are of great importance


Systems design as social activity 4

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


Systems design as social activity 5

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


Summary

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!


  • Login