Principles of Information Systems

Transcription

1 Principles of Information Systems Session 08 Systems Investigation and Analysis

2 An Overview of Systems Development Today, users of informa0on systems are involved in their development Avoid costly failures of system development projects by understanding the process 2

3 Par8cipants in Systems Development Development team Determines objec0ves of the informa0on system Delivers system that meets objec0ves Stakeholders People who ul0mately benefit from project Users Managers Systems development specialists Systems analysts Programmers Support personnel 3

4 Par8cipants in Systems Development (con8nued) Figure 12.1: Role of the Systems Analyst

5 Ini8a8ng Systems Development Systems development ini0a0ves Arise from all levels of an organiza0on Can be planned or unplanned Number of reasons for ini0a0ng systems development projects Infrastructure protec0on, mergers, acquisi0ons, federal regula0ons, etc. 5

6 Ini8a8ng Systems Development (con8nued) Figure 12.2: Typical Reasons to Initiate a Systems Development Project

7 Informa8on Systems Planning and Aligning Corporate and IS Goals Informa8on systems planning: transla0ng strategic and organiza0onal goals into systems development ini0a0ves Aligning organiza0onal goals and IS goals Cri0cal for successful systems development effort Developing a compe00ve advantage Crea0ve analysis New approaches to exis0ng problems Cri0cal analysis Unbiased, careful ques0oning of rela0onship among system elements 7

8 Informa8on Systems Planning and Aligning Corporate and IS Goals (con8nued) Figure 12.3: Information Systems Planning 8

9 Informa8on Systems Planning and Aligning Corporate and IS Goals (con8nued) Figure 12.4: The Steps of IS Planning 9

10 Establishing Objec8ves for Systems Development Overall objec0ve of systems development: achieve business goals, not technical goals Mission- cri8cal systems: play pivotal role in organiza0on s con0nued opera0ons and goal amainment Goals defined for an organiza0on also define objec0ves Cri8cal success factors (CSFs): factors essen0al to success of a func0onal area of an organiza0on 10

11 Establishing Objec8ves for Systems Development (con8nued) Performance objec0ves Output quality or usefulness Output accuracy Output format quality or usefulness Speed at which output is produced Scalability of resul0ng system Risk of the system 11

12 Establishing Objec8ves for Systems Development (con8nued) Cost objec0ves Development costs Costs of uniqueness of system applica0on Fixed investments in hardware and related equipment Ongoing opera0ng costs 12

13 Systems Development Life Cycles Ac0vi0es associated with systems development life cycle (SDLC) are ongoing The later in the SDLC an error is detected, the more expensive it is to correct Previous phases must be reworked More people are affected 13

14 Systems Development Life Cycles (con8nued) Figure 12.5: Relationship Between Timing of Errors and Costs 14

15 Systems Development Life Cycles (con8nued) Common systems development life cycles Tradi0onal Prototyping Rapid applica0on development (RAD) End- user development 15

16 The Tradi8onal Systems Development Life Cycle Figure 12.6: The Traditional Systems Development Life Cycle

17 The Tradi8onal Systems Development Life Cycle (con8nued) Systems inves8ga8on: iden0fies problems and opportuni0es and considers them in light of business goals Systems analysis: studies exis0ng systems and work processes to iden0fy strengths, weaknesses, and opportuni0es for improvement Systems design: defines how the informa0on system will do what it must do to obtain the problem s solu0on 17

18 The Tradi8onal Systems Development Life Cycle (con8nued) Systems implementa8on: creates or acquires various system components detailed in systems design, assembles them, and places new or modified system into opera0on Systems maintenance and review: ensures the system operates as intended and modifies the system so that it con0nues to meet changing business needs 18

19 Prototyping An itera0ve approach Opera8onal prototype: func0oning prototype Accesses real data files, edits input data, makes necessary computa0ons and comparisons, and produces real output Nonopera8onal prototype: a mock- up, or model Includes output and input specifica0ons and formats 19

20 Prototyping (con8nued) Figure 12.7: Prototyping

21 Prototyping (con8nued) Figure 12.8: Refining During Prototyping

22 Rapid Applica8on Development, Agile Development, Joint Applica8on Development, and Other Systems Development Approaches Rapid applica8on development (RAD): employs tools, techniques, and methodologies designed to speed applica0on development Makes extensive use of joint applica0on development (JAD) for data collec0on and requirements analysis JAD owen uses GSS sowware Best suited for DSSs and MISs; less well suited for TPSs 22

23 Rapid Applica8on Development, Agile Development, Joint Applica8on Development, and Other Systems Development Approaches Approaches that allow systems to change as they are developed Agile development: frequent face- to- face mee0ngs with developers and users to refine and test system Extreme programming (XP): pairs of programmers design, test, and code system itera0vely 23

24 The End- User Systems Development Life Cycle End- user systems development: primary effort is undertaken by a combina0on of business managers and users Can be structured as complementary to, rather than in conflict with, exis0ng and emerging informa0on systems 24

25 Outsourcing and On- Demand Compu8ng Reduces costs Obtains state- of- the- art technology Eliminates staffing and personnel problems Increases technological flexibility 25

26 Outsourcing and On- Demand Compu8ng (con8nued) Table 12.4: When to Use Outsourcing for Systems Development 26

27 Factors Affec8ng Systems Development Success Successful systems development: delivers a system that meets user and organiza0onal needs on 0me and within budget Factors Involvement of users and stakeholders Top management support Degree of change Quality of project planning Use of project management and CASE tools Object- oriented systems development 27

28 Degree of Change Con0nuous improvement projects High degree of success Rela0vely modest benefits Reengineering projects High degree of risk High poten0al for major business benefits Managing change Ability to recognize and deal with exis0ng or poten0al problems 28

29 Degree of Change (con8nued) Figure 12.10: The degree of change can greatly affect the probability of a project s success 29

30 Quality and Standards Quality of project planning Bigger the project, the more likely that poor planning will lead to significant problems Trade- off of schedule and cost versus quality ISO 9001 standards Organiza0onal experience with systems development process Capability Maturity Model (CMM) 30

31 Use of Project Management Tools Project schedule: detailed descrip0on of what is to be done Project milestone: cri0cal date for comple0on of a major part of the project Project deadline: date that the en0re project is to be completed and opera0onal Cri8cal path: ac0vi0es that, if delayed, would delay the en0re project 31

32 Use of Project Management Tools (con8nued) Program Evalua8on and Review Technique (PERT): formalized approach for developing a project schedule Gan[ chart: graphical tool used for planning, monitoring, and coordina0ng projects 32

33 Use of Computer- Aided So\ware Engineering (CASE) Tools Tools that automate many tasks required in a systems development effort and encourage adherence to SDLC Upper- CASE tools Inves0ga0on, analysis, and design phases Lower- CASE tools Implementa0on phase 33

34 Object- Oriented Systems Development Object- oriented systems development (OOSD): combines logic of systems development life cycle with power of object- oriented modeling and programming OOSD tasks Iden0fy poten0al problems and opportuni0es that would be appropriate for OO approach Define user requirements 34

35 Object- Oriented Systems Development (con8nued) OOSD tasks (con0nued) Design system Program or modify modules User evalua0on Periodic review and modifica0on 35

36 Systems Inves8ga8on What primary problems might a new or enhanced system solve? What opportuni0es might a new or enhanced system provide? What new hardware, sowware, databases, telecommunica0ons, personnel, or procedures will improve an exis0ng system or are required in a new system? What are the poten0al costs (variable and fixed)? What are the associated risks? 36

37 Ini8a8ng Systems Inves8ga8on Systems request form: submimed by someone who wants IS department to ini0ate systems inves0ga0on Problems in or opportuni0es for system Objec0ves of systems inves0ga0on Overview of proposed system Expected costs and benefits of proposed system 37

38 Par8cipants in Systems Inves8ga8on Members of development team change from phase to phase Systems inves0ga0on team Upper- and middle- level managers, a project manager, IS personnel, users, and stakeholders 38

39 Par8cipants in Systems Inves8ga8on (con8nued) Figure 12.12: The Systems Investigation Team 39

40 Feasibility Analysis Figure 12.13: Technical, Economic, Legal, Operational, and Schedule Feasibility 40

41 Object- Oriented Systems Inves8ga8on Key objects can be iden0fied during systems inves0ga0on Use case diagram Represents system objects (actors) and use cases (events) 41

42 Object- Oriented Systems Inves8ga8on (con8nued) Figure 12.14: Use Case Diagram for a Kayak Rental Application 42

43 The Systems Inves8ga8on Report Summarizes results of systems inves0ga0on Summarizes the process of feasibility analysis Recommends a course of ac0on Con0nue on into systems analysis Modify the project in some manner Drop the project Reviewed by steering commimee 43

44 The Systems Inves8ga8on Report (con8nued) Figure 12.15: A Typical Table of Contents for a Systems Investigation Report 44

45 Systems Analysis Overall emphasis of analysis Gathering data on exis0ng system Determining requirements for new system Considering alterna0ves Inves0ga0ng feasibility of solu0ons Primary outcome of systems analysis Priori0zed list of systems requirements 45

46 General Considera8ons Steps of a formalized analysis procedure Assembling par0cipants for systems analysis Collec0ng data and requirements Analyzing data and requirements Preparing a report on exis0ng system, new system requirements, and project priori0es 46

47 Par8cipants in Systems Analysis Includes members of the original inves0ga0on team Systems analysis team develops: List of objec0ves and ac0vi0es Schedule Deadlines Statement of resources required Major milestones 47

48 Data Collec8on Iden0fying sources of data Internal sources External sources Collec0ng data Interviews Direct observa0on Ques0onnaires 48

49 Data Collec8on (con8nued) Figure 12.16: Internal and External Sources of Data for Systems Analysis 49

50 Data Collec8on (con8nued) Figure 12.17: The Steps in Data Collection 50

51 Data Analysis Data modeling En0ty- rela0onship (ER) diagrams Ac0vity modeling Data- flow diagram (DFD) Symbols: data- flow line, process, en0ty, data store Applica0on flowcharts Grid charts CASE tools 51

52 Data Analysis (con8nued) Figure 12.19: A Telephone Order Process Application Flowchart 52

53 Data Analysis (con8nued) Figure 12.20: A Grid Chart 53

54 Requirements Analysis Determina0on of user, stakeholder, and organiza0onal needs Techniques Asking directly Cri0cal success factors (CSFs) IS plan: generates strategic planning documents Screen and report layout Requirements analysis tools 54

55 Requirements Analysis (con8nued) Figure 12.21: Converting Organizational Goals into Systems Requirements 55

56 Object- Oriented Systems Analysis Iden0fy problems or poten0al opportuni0es Iden0fy key par0cipants and collect data Analyze with object- oriented diagrams instead of data- flow diagrams and flowcharts Organize classes and subclasses in a generaliza0on/specializa0on hierarchy diagram 56

57 Object- Oriented Systems Analysis (con8nued) Figure 12.23: Generalization/Specialization Hierarchy Diagram for Single and Tandem Kayak Classes 57

58 The Systems Analysis Report Strengths and weaknesses of exis0ng system from a stakeholder s perspec0ve User/stakeholder requirements for new system (also called func%onal requirements) Organiza0onal requirements for new system Descrip0on of what new informa0on system should do to solve the problem 58

59 The Systems Analysis Report (con8nued) Figure 12.24: A Typical Table of Contents for a Report on an Existing System 59