critical issues in information systems
Download
Skip this Video
Download Presentation
Critical Issues in Information Systems

Loading in 2 Seconds...

play fullscreen
1 / 61

Critical Issues in Information Systems - PowerPoint PPT Presentation


  • 95 Views
  • Uploaded on

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

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 ' Critical Issues in Information Systems' - gene


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
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)
slide16
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

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)
slide29

Develop

Prototype

Analysis

Test

Prototype

Design

Amend

Prototype

Construction

RPLC

Investigation

Maintenance &

Evaluation

Operation &

Acceptance

slide30

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

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
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 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!
ad