Fundamentals of Information Systems Fourth Edition

1
Fundamentals of Information SystemsFourth Edition

• Chapter 8
• Systems Development

Includes Some content from AK ITEC 2010 F 2006
2
Principles and Learning Objectives

• Page 339
• Review Principles as an overview of chapter.
• Pay attention to acronyms !

LEARN THE SDLC You will need it for the rest
of your life AND it WILL be on the exam !!!
3
Why Learn About Systems Development?

• Important to learn how to
• Initiate systems development process
• Analyze your needs with help of IS personnel
• Learn how a project can be
• Planned
• Aligned with corporate goals
• Rapidly developed

See page 340
4
Participants in Systems Development

• Development team consists of the following
• Project managers coordinate system development
  effort
• Stakeholders directly or indirectly benefit from
  the project
• Users interact with the system regularly
• Systems analysts analyze and design business
  systems
• Programmers modify or develop programs to
  satisfy user requirements
• Various support personnel specialists, vendors

P 341
5
Information Systems Planning and Aligning
Corporate and IS Goals

• Information systems planning translating
  strategic and organizational goals into systems
  development initiatives
• Aligning organizational goals and IS goals is
  critical for any successful systems development
  effort
• Determining whether organizational and IS goals
  are aligned can be difficult

6
Information Systems Planning and Aligning
Corporate and IS Goals (continued)
Figure 8.2 Information Systems Planning
7
Systems Development Life Cycles

• The systems development process is also called a
  systems development life cycle (SDLC)
• Common SDLCs
• Traditional systems development life cycle
• Prototyping
• Rapid application development (RAD)
• End-user development

This classification is inconsistent with that
used for ITEC 2010.
8
The Traditional Systems Development Life Cycle
LEARN !!
Figure 8.3 The Traditional Systems Development
Life Cycle
9
The Traditional Systems Development Life Cycle
(continued)

• Systems investigation problems and opportunities
  are identified and considered in light of the
  goals of the business
• Systems analysis study of existing systems and
  work processes to identify strengths, weaknesses,
  and opportunities for improvement
• Systems design answers the question How will
  the information system do what it must do to
  obtain the problem solution?

10
The Traditional Systems Development Life Cycle
(continued)

• Systems implementation creation or acquisition
  of various system components detailed in the
  systems design, assembling them, and placing the
  new or modified system into operation
• Systems maintenance and review ensures the
  system operates as intended and modifies the
  system so that it continues to meet changing
  business needs

11
Prototyping

• An iterative approach to systems development

Some other references consider prototyping as
part of different phases (analysis,
implementation) of the SDLC.
Figure 8.4 Prototyping
12
Rapid Application Development, Agile Development,
Joint Application Development, and Other Systems
Development Approaches

• Rapid application development (RAD)
• Systems development approach that employs tools,
  techniques, and methodologies designed to speed
  application development
• Some iterative development approaches allow the
  system to change as it is being developed
• Agile development frequent face-to-face meetings
  between systems developers and users
• XP programming pairs of programmers work
  together to develop robust systems quickly

13
Rapid Application Development, Agile Development,
Joint Application Development, and Other Systems
Development Approaches (continued)

• Pages 346 347 Read carefully three times.
  Learn RAD JAD acronyms.
• Study Extreme Programming, GSSs.

14
The End-User Systems Development Life Cycle

• End-user systems development any systems
  development project in which the primary effort
  is undertaken by a combination of business
  managers and users
• End-user-developed systems can be structured as
  complementary to, rather than in conflict with,
  existing and emerging information systems

15
Outsourcing and On Demand Computing

• An outside consulting firm or computer company
  that specializes in systems development can take
  over some or all of the development and
  operations activities
• Reasons for using outsourcing and on demand
  computing
• Reducing costs, obtaining state-of-the-art
  technology, eliminating staffing and personnel
  problems, and increasing technological
  flexibility

16
Use of Computer-Aided Software Engineering (CASE)
Tools

• Computer-aided software engineering (CASE) tools
  that automate many of the tasks required in a
  systems development effort and encourage
  adherence to the SDLC
• Instill a high degree of rigor and
  standardization to the entire systems development
  process
• Upper-CASE tools focus on investigation,
  analysis, and design
• Lower-CASE tools focus on implementation

17
Object-Oriented Systems Development

• Object-oriented systems development (OOSD)
  approach to systems development that combines the
  logic of the systems development life cycle with
  the power of object-oriented modeling and
  programming

18
Systems Investigation

• What primary problems might a new or enhanced
  system solve?
• What opportunities might a new or enhanced system
  provide?
• What new hardware, software, databases,
  telecommunications, personnel, or procedures will
  improve an existing system or are required in a
  new system?
• What are the potential costs (variable and
  fixed)?
• What are the associated risks?

P 350
19
Initiating Systems Investigation

• Systems request form document filled out by
  someone who wants the IS department to initiate
  systems investigation
• Helps rationalize and prioritize the activities
  of the IS department
• Includes the following information
• Problems in and opportunities for system
• Objectives in investigation
• Overview, costs, and benefits of proposed system

20
Feasibility Analysis

• Technical feasibility hardware, software, and
  other system components
• Economic feasibility predicted benefits vs. cost
  and time
• Legal feasibility limitations of laws and
  regulations on project
• Operational feasibility logistical and
  motivational considerations
• Schedule feasibility completion of project in
  reasonable amount of time

21
Object-Oriented Systems Investigation

• Key objects can be identified during systems
  investigation
• Use case diagram
• Part of the Unified Modeling Language (UML) used
  in object-oriented systems development
• Actors represent persons interacting with system
• Use cases represent system activity in response
  to an event.

See Sys Anal des pg 221.
22
Object-Oriented Systems Investigation (continued)
Figure 8.8 Use Case Diagram for a Kayak Rental
Application
23
The Systems Investigation Report

• Systems investigation report
• Summary of the results of the systems
  investigation and the process of feasibility
  analysis
• Recommendation of a course of action
• Continue systems analysis
• Modify the project
• Abandon the project
• Reviewed by steering committee of senior
  management and users

24
Systems Analysis

• Answers the question What must the information
  system do to solve the problem?
• Overall emphasis of systems analysis is
• Gathering data on the existing system
• Determining the requirements for the new system
• Considering alternatives within these constraints
• Investigating the feasibility of the solutions
• Primary outcome prioritized list of systems
  requirements

25
Data Collection

• Identifying sources of data
• Internal sources
• External sources
• Collecting data
• Interviews structured and unstructured
• Direct observation
• Questionnaires structured or unstructured
• Used when data sources are spread over a wide
  geographic area

26
Data Analysis

• Data analysis
• Manipulation of collected data so that systems
  development team can use the data
• Data modeling
• Entity-relationship (ER) diagrams objects,
  attributes, and associations
• Activity modeling
• Data-flow diagrams (DFDs) objects, associations,
  and activities

27
Data Analysis (continued)
Figure 8.12 Data and Activity Modeling (b) A
data-flow diagram
28
Data Flow Diagrams (DFDs)

• Graphical system model that shows all main
  requirements for an IS in one diagram or set of
  diagrams
• Inputs/outputs,
• Processes,
• Data storage.
• Easy to read and understand with minimal
  training. Ref San Diego Periodicals.

Slide from ITEC 2010
29
Data Flow Diagram Symbols(Figure 6-3)
Learn !
Slide from ITEC 2010
30
Data Analysis (continued)
Figure 8.12 Data and Activity Modeling (a) An
entity-relationship diagram
31
Data Analysis (continued)
Figure 8.12 Data and Activity Modeling (c) A
semantic description of the business process
32
Customers, Orders, and Order Items
Slide from ITEC 2010
33
ERD with Many-to-Many Relationships
Slide from ITEC 2010
34
Many-to-Many Relationship Converted to
Associative Entity to Store Grade Attribute
Slide from ITEC 2010
35
Requirements Analysis

• Determines user, stakeholder, and organizational
  needs through the following techniques
• Asking directly best for stable systems
• Critical success factors asks for critical
  factors in interviewees area
• IS plan translates strategic plan into
  initiatives
• Requirements analysis tools CASE tools

36
Requirements Analysis (continued)
Figure 8.13 Converting Organizational Goals into
Systems Requirements
37
Object-Oriented Systems Analysis

• Identifying problems or potential opportunities
• Identifying key participants and collecting data
• Uses classes and generalization/specialization
  hierarchies instead of data-flow diagrams and
  flowcharts

Be able to recognize a class diagram box.
38
Object-Oriented Systems Analysis (continued)
Figure 8.14 Generalization/Specialization
Hierarchy Diagram for Single and Tandem Kayak
Classes
39
The Systems Analysis Report

• Systems analysis report should cover
• Strengths and weaknesses of the existing system
  from a stakeholders perspective
• User/stakeholder requirements for the new system
  (also called the functional requirements)
• Organizational requirements for the new system
• Description of what the new information system
  should do to solve the problem

40
Systems Design

• Answers the question How will the information
  system solve a problem?
• Has two dimensions logical and physical
• Logical design description of the functional
  requirements of a system
• Physical design specification of the
  characteristics of the system components
  necessary to put the logical design into action

41
Object-Oriented Design

• Design key objects and classes of objects in the
  new or updated system
• Consideration of the problem domain, the
  operating environment, and the user interface
• Consideration of the sequence of events that must
  happen for the system to function correctly
• Scenario sequence of events
• Can be diagrammed in a sequence diagram

42
Object-Oriented Design (continued)
Figure 8.16 A Sequence Diagram to Add a New
KayakItem Scenario
43
Generating Systems Design Alternatives

• Request for proposal (RFP) document that
  specifies in detail required resources such as
  hardware and software
• Financial options
• Purchasing
• Leasing
• Renting

44
Systems Implementation
Page 364
Figure 8.19 Typical Steps in Systems
Implementation
45
Acquiring Hardware from an IS Vendor

• IS vendor company that offers hardware,
  software, telecommunications systems, databases,
  IS personnel, and/or other computer-related
  resources
• Buying computer hardware
• Leasing computer hardware
• Renting computer hardware
• Pay-as-you-go, on-demand, or utility
  computing

46
Data Preparation

• Also called data conversion
• Ensures all files and databases are ready to be
  used with new computer software and systems

47
Testing

• Unit testing testing of individual programs
• System testing testing the entire system of
  programs
• Volume testing testing the application with a
  large amount of data
• Integration testing testing all related systems
  together
• Acceptance testing conducting any tests required
  by the user

48
Start-Up

• Process of making the final tested information
  system fully operational
• Approaches
• Direct conversion (plunge, direct cutover)
  stopping the old system and starting the new one
  on a given date
• Phase-in approach (piecemeal) slowly replacing
  old system components with new system components
• Pilot start-up run new system with one group of
  users
• Parallel start-up running old and new systems
  together for a period of time

49
User Acceptance

• User acceptance document formal agreement signed
  by the user that states that a phase of the
  installation or the complete system is approved
• Legal document that removes or reduces IS
  vendors liability

50
Systems Review

• Process of analyzing systems to make sure that
  they are operating as intended
• Often compares the performance and benefits of
  the system as it was designed with the actual
  performance and benefits of the system in
  operation
• Event-driven review triggered by a problem or
  opportunity such as an error, a corporate merger,
  or a new market for products
• Time-driven review performed after a specified
  amount of time