Systems Analysis and Design in a Changing World, Fourth Edition

1

• Systems Analysis and Design in a Changing World,
  Fourth Edition

2
Learning Objectives

• Prioritize the system requirements based on the
  desired scope and level of automation for the new
  system
• Describe the strategic decisions that integrate
  the application deployment environment and the
  design approach for the new system
• Determine alternative approaches for system
  implementation

3
Learning Objectives (continued)

• Evaluate and select an implementation approach
  based on the needs and resources of the
  organization
• Describe key elements of a request for proposal
  (RFP) and evaluate vendors proposals for
  outsourced alternatives
• Develop a professional presentation of findings
  to management

4
Overview

• Chapter explains last three activities of
  analysis
• Prioritize systems requirements
• Generate and evaluate alternatives
• Review recommendation with management
• Refocus project direction
• Transition from discovery and analysis to
  solutions and design
• Set direction for design and implementation of
  solution system

5
Project Management Perspective

• Project manager and senior technical members of
  project team work together
• Eight areas of project management

• Human resources
• Procurement
• Communications
• Risk

• Scope
• Time
• Cost
• Quality

6
Deciding on Scope and Level of Automation

• Scope determines which business functions will be
  included in system
• Level of automation is how much computer support
  exists for functions included in scope
• Scope creep
• Requests for addition of system functions after
  requirements have been defined and decision has
  been made
• control by formalizing the process to identify,
  categorize, and prioritize the functions that
  will be included within the new system so that
  everyone agrees to and signs off on system
  functions.
• Users typically request more business functions
  than budget allows
• Decide which functions are critical and must be
  included, and which can be deferred until later.
  One way to define the scope of a project is to
  list each requested function and rate its
  importance as mandatory, important, or
  desirable.

7
Determining the Level of Automation

• Automation describes the support the system will
  provide for each function. For most functions of
  an application system, at least three levels of
  automation can be defined
• Low level
• Functions automated for simple computer record
  keeping
• Medium level
• Midrange point that combines features from low
  and high alternatives
• High level
• System automates most processing of business
  functions
• It is more difficult for an analyst to define
  high-end automation than low-end automation

8
Prioritizing requirements

• The project manager precisely defines the
  functions that will be included in the project
  and sets a baseline, which he or she can use to
  control and direct the rest of the project.
• A firm list of functions that users and project
  staff have agreed to can control the scope of the
  project and keep it manageable.
• If no firm decisions are ever made about what
  should be in the new system, then it is almost
  impossible for the project manager to control the
  size of the project.

9
System development projects

• come in all sizes, complexities, and levels of
  formality.
• One effective technique for managing large or
  complex projects is to develop decision
  metricssystems to measure the alternatives and
  evaluate them based on their relative scores.
• Other projects that are smaller and less complex
  can use more informal techniques with fewer
  metrics

10
RMO Customer Support System Functions, Priority,
and Three Levels of Automation (Partial Figure
8-1)
11
Selecting Alternatives

• Entire group of alternatives is evaluated
  together to provide big picture view of
  proposed system
• Key criteria that are used
• Strategic plan
• Economic feasibility
• Obviously, the higher levels of automation will
  require substantially more funds to implement. It
  may not be possible to determine the exact cost
  of each function and level of automation
• Schedule and resource feasibility
• Technological feasibility
• Must also carefully consider whether the
  organization has in-house expertise to develop
  and implement the system.
• Operational, organizational, and cultural
  feasibility

12
What are the key criteria that are used to make
better long-term decisions for new systems?

• Strategic plan, economic feasibility, schedule
  and resource feasibility, technological
  feasibility, and operational, organizational, and
  cultural feasibility.

13
Defining the Application Deployment Environment

• The configuration of computer equipment,
  operating systems, and networks that will exist
  when the new application system is deployed.
• Configuration of
• Computer hardware
• System software
• Networks
• Development tools
• Existing environment generally considered and
  compared with proposed environment
• Application deployment environment is defined and
  well matched to application requirements.

14
Range of Application Types

• Stand-alone applications on mini- and personal
  computers
• Online interactive applications
• Distributed applications
• Web-based applications

15
Hardware, System Software, and Networks

• Computers range from handheld to super computers
• Operating systems range from Windows to Unix
• Database management systems range from Oracle to
  SQL Server to IBM DB2
• Software components and standards range from Java
  2 Enterprise (J2EE) to Microsoft .NET
• Web servers range from IIS to Apache

16
Deployment Environment Characteristics to Consider

• Compatibility with system requirements
• Compatibility among hardware and system software
• Required interfaces to external systems
• Conformity with IT strategic plan and
  architecture plans
• Cost and schedule

17
The Analyst

• Must define an application deployment environment
  that enables the application to meet stated
  requirements, fits within the organizations IT
  plans, and can be acquired and configured within
  acceptable limits of budget and schedule.

18
Development Tools

• Development environment programming languages,
  CASE tools, and other software used to develop
  application software
• Java and Visual Studio .NET are examples
• Application deployment environment decisions
  limit development tool choices
• Operating system environment
• Database management system (DBMS)
• Distributed software standard

19
Application Deployment environment

• The application deployment environment choices,
  particularly the operating system, DBMS, and
  distributed software standard, tend to limit
  development tool choices.
• Usually, companies have a preferred language for
  system development, and their analysts are
  familiar with its features.
• As technology changes, newer languages frequently
  provide additional capabilities, and the
  preferred language may change over time.
• An analyst should consider the deployment and
  development environments together when
  determining their fit to a particular
  application.

20
What is meant by the application deployment
environment?

• By application deployment environment, we mean
  the configuration of computer equipment,
  operating systems, and networks that will exist
  when the new application system is deployed.

21
Which characteristics are analysts concerned with
when choosing or defining the deployment
environment?

• Compatibility with system requirements
• Compatibility among hardware and system software
• Required interfaces to external systems
• Conformity with the IT strategic plan and
  architecture plans
• Cost and schedule

22
What is meant by the application development
environment?

• The application development environment consists
  of the programming language(s), CASE
  (computer-assisted software engineering) tool(s),
  and other software used to develop application
  software

23
Existing Processing Environment at RMO (Figure
8-3)
24
Processing Environment Alternatives (Figure 8-4)
25
Strategic Directions for RMO Processing
Environment (Figure 8-5)
26
Choosing Implementation Alternatives

• Variations on obtaining system
• Facilities management outsource all IS support
• an organizations strategic decision to move all
  data processing and information technology
  development and support to an outside vendor
• Packaged software, turnkey system, ERP system
• those software systems that are purchased to
  support a particular application.
• Turnkey -outside company provides a complete
  solution, including hardware and software, and
  the organization only needs to turn it on
• ERP -support all the operational functions of the
  entire organization
• Custom-built software systems
• advantage of custom development is that an
  organization purchases a tremendous amount of
  experience and expertise to build a new system
• In-house development
• main problems is that special technical expertise
  beyond an employees experience may be required
  for a portion of the project.
• Selection dimensions
• Buy vs. build
• In-house vs. outsource

27
Implementation Alternatives (Figure 8-6)
28
Selecting an Implementation Alternative

• Identifying criteria for selection
• Comparisons can be difficult
• Different proposed systems have strengths in
  different areas
• Three major areas to consider
• General requirements
• Technical requirements
• Functional requirements

29
General requirements include considerations that
are important but not directly associated with
the computer system itself.

• Performance record of the provider
• Level of technical support from the provider
• Availability of experienced staff
• Development cost
• Expected value of benefits
• Length of time (schedule) until deployment
• Impact on internal resources
• Requirements for internal expertise
• Organizational impacts (retraining, skill levels)
• Expected cost of data conversion
• Warranties and support services (from outside
  vendors)

30
Partial Matrix of General Requirements, Weights,
and Scores for Alternatives (Figure 8-7)
31
Technical requirements include the following
criteria

• Robustness (does not crash)
• Programming errors (calculates correctly)
• Quality of code (maintainability)
• Documentation (user and system, online and
  written)
• Ease of installation
• Flexibility (the software makes it easy to adjust
  to new functionality and new environments)
• Structure (maintainable, easy to understand)
• User friendliness (natural and intuitive use)
• Performance (response time)
• Scalability (ability to handle large volumes)
• Compatibility with operating environment
  (hardware, operating systems)

32
Each alternative can then be evaluated with a raw
score based on how well it meets the criteria.

• Three-point scale could be
• Fully Satisfy (2)
• Partially Satisfy (1)
• Not Satisfy (0)
• A six-point scale could represent these ratings
• Superior (5)
• Excellent (4)
• Good (3)
• Fair (2)
• Poor (1)
• Disqualify (0)
• To calculate a weighted score in each criterion
  for each alternative, staff would multiply the
  raw score by the weighting factor. An overall
  score, which is the sum of the individual
  criteria scores, determines a ranking among the
  various alternatives for this category.

33
Partial Matrix of Functional Requirements,
Weights, and Scores for Alternatives (Figure 8-8)
34
Partial Matrix of Technical Requirements,
Weights, and Scores for Alternatives (Figure 8-9)
35
Making the Selection

• First, rate each alternative with raw score
• Weighted scores are then tabulated and compared
  to make a choice
• RMO decided on in-house development for most CSS
  development to keep expertise within RMO
• RMO wants to hire some new technical specialists
• RMO feasibility review showed no serious problems
  after specialists are added

36
What is facilities management?

• Facilities management is an organizations
  strategic decision to move all data processing
  and information technology development and
  support to an outside vendor.

37
What is a turnkey system?

• A turnkey system is one in which an outside
  company provides a complete solution, including
  hardware and software, and the organization only
  needs to turn it on. In most cases, the outside
  vendor specializes in a particular industry and
  application software for that industry.

38
Contracting with Vendors

• Generate request for proposal (RFP)
• Formal document sent to vendors if in-house
  development is not selected
• States requirements and solicits proposed
  solutions
• Considered a competitive contract offer
• Bid on supplying hardware, software, and/or
  support services

39
Sample RFP Table of Contents (Figure 8-10)

• I. Introduction and Background
• II. Overview of Need
• III. Description of Technical Requirements
• IV. Description of Functional Requirements

40
Sample RFP Table of Contents (continued)
V. Description of General Requirements VI.
Requested Provider and Project Information VII.
Details for Submitting Proposal IV. Evaluation
Criteria and Process
41
Sample RFP Table of Contents (continued)
42
Benchmarking and Choosing a Vendor

• Observe in use or install trial version
• Benchmark evaluate the system against a
  standard
• Visit another company using a particular system
• Develop a contract
• Fixed-dollar risk is on vendor
• Cost-plus-percentage risk is on purchaser
• Cost-plus-fixed-fee risk is shared by both

43
What is a request for proposal (RFP)?

• A request for proposal is a formal document sent
  to vendors to request that they bid on the
  development of a new system. The RFP contains
  details on the system requirements.

44
Define benchmark

• A benchmark is a performance evaluation of
  application software (or test programs) using
  actual hardware and systems software under
  realistic processing conditions.

45
Presenting Results and Making Decisions

• Compile and organize documentation
• Present alternatives and critical issues in
  easy-to-understand but complete manner
• Final choice generally made by executive steering
  committee
• Format of documentation and presentation style
  varies with organization

46
Summary

• These activities are primarily project manager
  responsibilities with support from project team
• Focus of project changes from discovering
  requirements to developing solution system
• Prioritize requirements based on scope and level
  of automation
• Scope of new system determines functions it will
  support
• Level of automation is a measure of how automated
  the selected functions will be

47
Summary (continued)

• Application deployment environment
• Computer hardware, systems software, and networks
  in which new system will operate
• Determines constraints imposed on system
  development alternatives
• Analyst must define environment to match
• Application requirements
• Organizations strategic application plans
• Organizations technology architecture plans

48
Summary (continued)

• Determine what alternatives are possible for
  developing solution
• Implementation alternatives include
• Building system in-house
• Buying packaged or turnkey solution
• Contracting with developer to build system
  (outsource)
• Develop recommendations and present to management
  to make funding decisions