principles of information systems -...
TRANSCRIPT
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
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
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.
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
8
Figure 12.3: Information Systems Planning
Informa8on Systems Planning and Aligning Corporate and IS Goals (con8nued)
9
Informa8on Systems Planning and Aligning Corporate and IS Goals (con8nued)
Figure 12.4: The Steps of IS Planning
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
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
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
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
14
Systems Development Life Cycles (con8nued)
Figure 12.5: Relationship Between Timing of Errors and Costs
15
Systems Development Life Cycles (con8nued)
• Common systems development life cycles – Tradi0onal – Prototyping – Rapid applica0on development (RAD) – End-‐user development
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
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
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
Prototyping (con8nued)
Figure 12.7: Prototyping
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
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
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
Outsourcing and On-‐Demand Compu8ng
• Reduces costs • Obtains state-‐of-‐the-‐art technology • Eliminates staffing and personnel problems • Increases technological flexibility
25
Outsourcing and On-‐Demand Compu8ng (con8nued)
Table 12.4: When to Use Outsourcing for Systems Development
26
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
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
Degree of Change (con8nued)
Figure 12.10: The degree of change can greatly affect the probability of a project’s success
29
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
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
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
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
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
Object-‐Oriented Systems Development (con8nued)
• OOSD tasks (con0nued) – Design system – Program or modify modules – User evalua0on – Periodic review and modifica0on
35
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
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
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
Par8cipants in Systems Inves8ga8on (con8nued)
Figure 12.12: The Systems Investigation Team
39
Feasibility Analysis
Figure 12.13: Technical, Economic, Legal, Operational, and Schedule Feasibility
40
Object-‐Oriented Systems Inves8ga8on
• Key objects can be iden0fied during systems inves0ga0on
• Use case diagram – Represents system objects (actors) and use cases (events)
41
Object-‐Oriented Systems Inves8ga8on (con8nued)
Figure 12.14: Use Case Diagram for a Kayak Rental Application
42
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
The Systems Inves8ga8on Report (con8nued)
Figure 12.15: A Typical Table of Contents for a Systems Investigation Report
44
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
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
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
Data Collec8on
• Iden0fying sources of data – Internal sources – External sources
• Collec0ng data – Interviews – Direct observa0on – Ques0onnaires
48
Data Collec8on (con8nued)
Figure 12.16: Internal and External Sources of Data for Systems Analysis
49
Data Collec8on (con8nued)
Figure 12.17: The Steps in Data Collection
50
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
Data Analysis (con8nued)
Figure 12.19: A Telephone Order Process Application Flowchart
52
Data Analysis (con8nued)
Figure 12.20: A Grid Chart
53
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
Requirements Analysis (con8nued)
Figure 12.21: Converting Organizational Goals into Systems Requirements
55
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
Object-‐Oriented Systems Analysis (con8nued)
Figure 12.23: Generalization/Specialization Hierarchy Diagram for Single and Tandem Kayak Classes
57
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
The Systems Analysis Report (con8nued)
Figure 12.24: A Typical Table of Contents for a Report on an Existing System
59