1. Clarke, R. J (2001) L951-04: 1 Critical Issues in Information Systems BUSS 951 Lecture 4 Design 1: Technical and Methodological Aspects

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

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

4. Clarke, R. J (2001) L951-04: 4 Agenda (1) Organisational Metaphors Machines Organisms Specific Organisational Theories Complex Organisations Network Organisations Population Ecology Models

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

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

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

8. Clarke, R. J (2001) L951-04: 8 What is a Life Cycle? (3) Needs served planning, organising staffing, coordinating budgeting, and directing software development activities

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

10. 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 specific therefore, prescriptive models are dominant

11. 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 models evolutionary models

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

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

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

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

16. Clarke, R. J (2001) L951-04: 16 SDLC Construction Analysis Design Initiation Maintenance & Evaluation Operation & Acceptance

17. Clarke, R. J (2001) L951-04: 17 SDLC B-Model Construction Analysis Design AnalysisDesign Initiation Construction Operation Acceptance Evaluation Initiation Maintenance Cycle Development Path

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

19. Clarke, R. J (2001) L951-04: 19 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

20. Clarke, R. J (2001) L951-04: 20 Problems with SDLC Document 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

21. Clarke, R. J (2001) L951-04: 21 Problems with SDLC Some 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

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

23. Clarke, R. J (2001) L951-04: 23 Problems with SDLC Users 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

24. Clarke, R. J (2001) L951-04: 24 Problems with SDLC Users 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

25. Clarke, R. J (2001) L951-04: 25 Problems with SDLC Users 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

26. Clarke, R. J (2001) L951-04: 26 Increasing Uncertainty User 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 LevelsSystems Increasing Uncertainty in System Requirements Strategic Management Tactical Management Operational Management Business Operations

27. Clarke, R. J (2001) L951-04: 27 Prototyping: Rapid & Evolutionary

28. Clarke, R. J (2001) L951-04: 28 Types of Prototyping Rapid 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)

29. Clarke, R. J (2001) L951-04: 29 RPLC Develop Prototype Test Prototype Amend Prototype Investigation ConstructionAnalysisDesign Maintenance & Evaluation Operation & Acceptance

30. Clarke, R. J (2001) L951-04: 30 EDLC Develop Prototype Test Prototype Amend Prototype

31. Clarke, R. J (2001) L951-04: 31 Problems with Prototyping inappropriate, incomplete, and inadequate analysis and design unrealistic performance expectations poorly controlled projects reluctance to discard prototype models problems with users

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

33. Clarke, R. J (2001) L951-04: 33 Experimental Life Cycles: Spiral & Curriculum

34. Clarke, R. J (2001) L951-04: 34 SLC Spiral Life Cycle Investigation Construction Analysis Design Maintenance & Evaluation Operation & Acceptance

35. Clarke, R. J (2001) L951-04: 35 CLC Curriculum Life Cycle Deconstruction IndependentConstruction JointConstruction SocialSetting

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

37. Clarke, R. J (2001) L951-04: 37 Life Cycles & Methodologies Methodologies Life Cycle Use prescriptive life cycles to explain and compare between real methodologies

38. 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 Jenkins Systemscraft (Crinnion) Rapid Prototyping Softwright Systems JAD

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

40. Clarke, R. J (2001) L951-04: 40 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

41. Clarke, R. J (2001) L951-04: 41 Adaptive Methodology delete (jettison) unneeded methods addition of needed methods Controls Analysis Technique (CAT) Quality Control Method(s)

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

43. Clarke, R. J (2001) L951-04: 43 Scalable Methodologies Systemscraft is a scalable methodology Scalability is a kind of adaptability centres on the deletion (jettisoning) or addition of methods

44. Clarke, R. J (2001) L951-04: 44 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

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

46. Clarke, R. J (2001) L951-04: 46 Design Problems cannot 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

47. Clarke, R. J (2001) L951-04: 47 Design Problems cannot 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

48. Clarke, R. J (2001) L951-04: 48 Design Problems require 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/

49. Clarke, R. J (2001) L951-04: 49 Design Problems require 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

50. Clarke, R. J (2001) L951-04: 50 Design Problems organised 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

51. Clarke, R. J (2001) L951-04: 51 Design Problems organised hierarchically (2)... no objective, logical way of finding the right level on which to tackle problems decisions involve pragmatics, power, resources etc./

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

53. Clarke, R. J (2001) L951-04: 53 Design Process (1) the process is endless there is no infallibly correct process involves finding as well as solving problems

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

55. Clarke, R. J (2001) L951-04: 55 Systems Design as a Social Activity

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

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

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

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

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

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