Chapter 8

Systems Analysis and Design

Reasons for Systems change:

 Changes in user or business needs.
 Technological changes
 Improved business process
 Competitive advantage
 Productivity gains
 Growth
 Downsizing

Systems Development Life Cycle

 A logical sequence of activities to identify new systems need and develop these
systems to support those needs.
 A model for reducing risk through careful planning, execution, control, and
documentation of key activities.

Approaches in Systems Development:

 Traditional
 Prototyping
 RAD
 Outsourcing

Steps in the Traditional SDLC

 Systems Analysis
 Do initial investigation
 Do system survey
 Do feasibility study
 Determine information needs and system requirements
 Deliver system requirement
 Conceptual Design
 Identify and evaluate design alternatives
 Develop design specifications
 Deliver conceptual design requirements
 Physical Design
 Design output
 Design database
 Design input
 Develop programs
 Develop procedures
 Design controls
 Deliver developed system
  Implementation and Conversion
 Develop implementation and conversion plan
 Install hardware and software
 Train personnel
 Test the system
 Complete documentation
 Convert from old to new system
 Deliver operational system
 Operation and Maintenance
 Fine-tune and do implementation review
 Operate system
 Modify system
 Do ongoing maintenance
 Deliver improved system

People involved in Systems Development

» Management
» Role:
» Providing support and encouragement for development
projects
» Aligning information systems with corporate strategies
» Establishing system goals and objectives
» Determine information requirements for departmental
projects
» Assist systems analysts with project cost and estimations
» Assign key staff members to development projects
» Allocate funds to support systems development and
operation

» Accountants
» Role:
» Determine their information needs and system requirements
and communicate them to system developers
» May be members of the project development team
» Play an active role in designing system controls

» IS steering committee
» Role:
» Set policies that govern the IS
» Often consists of high-level management people, i.e.
controller, systems and user management
» Ensures top-management participation, guidance and
control
» Facilitates coordination and integration of IS activities
 » Project development team
» Role:
» Plan each project
» Consists of team specialists, managers, accountants,
auditors, and users that guides its development
» Monitor project to ensure timely and cost-effective
completion
» Make sure proper consideration is given to human element
» Systems analysts and programmers
» Role:
» Study existing systems
» Design new systems
» Prepare specifications that are used by programmers
» Ensure that the system meets user needs
» Write computer programs
» Modify and maintain existing computer programs
» External Players
» Who are they?
» Customers
» Vendors
» Auditors
» Government agencies

Why is planning an important steps in systems development?

 Consistency - Planning enables the system’s goals and objectives to

correspond to the organization’s overall strategic plan.
 Efficiency - Systems are more efficient, subsystems are coordinated, and there
is a sound basis for selecting new applications for development.
 Cutting Edge - The company remains abreast of the ever-present changes in
IT.
 Lower Cost - Duplication, wasted efforts, and cost and time overruns are
avoided. The system is less costly and easier to maintain.
 Adaptability - Management is better prepared for future resource needs, and
employees are better prepared for the changes that will occur.

Types of SD plan:

1. Project Development Plan – is the basic building block of information

systems.
» Cost benefit analysis
» Developmental and operational requirements, i.e. human resource,
hardware, software, financial
 » Schedule of activities required to develop and operate the new
application

2. Master Plan – is a long range plan of systems development. This is a

document:
» that specifies what the system will consist of;
» How the system will be developed;
» Who will develop the system;
» How the needed resources be acquired;
» Where the system is headed.
» Status of projects in process
» Priority plan

3. Feasibility Analysis
» Systems analysis is the first step in the systems development life
cycle (SDLC).
» A feasibility study is prepared during systems analysis and updated
as necessary during the remaining steps in the SDLC.
» The steering committee uses the study to decide whether to
terminate a project, proceed unconditionally, or proceed
conditionally.
1. Aspects of FS
 Technical Feasibility – can the planned system be
developed and implemented using existing
technology?
 Operational Feasibility – does the organization have
access to people who can design, implement, and
operate the proposed system? Can people use the
system and will they use it?
 Legal feasibility – does the system comply with all
applicable laws and statutes, administrative agency
regulations, and the company’s contractual
obligation?
 Scheduling feasibility – can the system be developed
and implemented in the time allotted? If not, it will
have to be modified, postponed, or replaced by an
alternative selection.
 Economic Feasibility – will the system benefits justify
the time, money, and other resources required in
implementing it? Economic feasibility is the most
important and frequently analyzed of the five aspects.

Behavioral Aspects of change:

• Individuals participating in systems development are agents of change

• They are continually confronted by people’s reaction and resistance to change.
• Behavioral aspects of change are crucial because the system will fail without the
support of the people it serves.

Why behavioral problems occur?

• Personal characteristics and background

• The younger and more highly educated people are more likely to accept
change
• “Techie” people are less likely to oppose change.
• Manner in which change is introduced
• Resistance is often a reaction to the methods of instituting change rather
than to change itself
• Rationale use to sell the system to top management may not be
appropriate to lower-level employees.
• The elimination of menial tasks and the ability to advance and grow are
often more important to users than are increasing profits and reducing
costs.
• Experience with prior changes
• Employees who had a bad experience with prior changes are more reluctant
to cooperate when future changes occur.
• Communication
• Employees are unlikely to support a change unless the reasons behind it are
explained.
• Disruptive Nature of the change process
• Requests for information and interviews are distracting and place additional
burdens on people. These disturbances can create negative feelings toward
the change.
• Biases and natural resistance to change
• People with emotional attachments to their duties or coworkers may not want
to change if those elements are affected
• Fear
• Many people fear the unknown and the uncertainty accompanying change.
They also fear losing their jobs, losing respects or status, failure, technology,
and automation

How do people resist change?

Aggression
• Behavior that is usually intended to destroy, cripple, or weaken the system’s
effectiveness.
• It may take the form of increased error rates, disruptions, or deliberate sabotage.
Projection
• Involves blaming the new system for any and every unpleasant occurrence.
• In essence, the system becomes the scapegoat for all real and imagined
problems and errors.
• If these criticisms are not controlled or answered, the integrity of the system can
be damaged or destroyed.

Avoidance
• Dealing with problem through avoidance is a common human trait.
• One way for employees to deal with a new IS is to avoid using it in the hope that
the system can be ignored or that it will eventually go away.

What to do prevent those behaviors?

Meet user’s need.

• It is essential that the form, content, and volume of system output be designed to
satisfy user needs.

Keep communication lines open

• Open communications help prevent damaging and inaccurate rumors and
misunderstandings.
• Employees should be told who they can contact if they have questions or
concerns

Maintain a safe and open atmosphere

• It is vital that everyone affected by systems development has an attitude of trust
and cooperation.
• If the employees become hostile, it will be difficult to change their attitude or to
implement the system successfully.

Obtain management support

• When possible, somebody from the top, who can provide resources for the
system and motivate others to assist and cooperate with systems development,
should be appointed.

Allay fears
• The organization should provide assurances that no major job losses or
responsibility shifts will occur.
• These can be achieved through relocation, attrition, and early retirement.
• If employees are terminated, severance pay and outplacement services should
be provided.
Solicit user participation
• Direct and indirect users of the system should participate in its development by
providing data, making suggestions, and helping make decisions.
• Participation is ego enhancing, challenging, and intrinsically satisfying.
• Users who participate in the SD are more knowledgeable, better trained, and
more committed to using the system.

Provide honest feedback

• To avoid misunderstanding, users should be told which suggestions are being
used and how, which suggestions are not being used and why, and which ones
will be incorporated at a later date.

Make sure users understand the system

• Effective use or support cannot be obtained if users are confused about or do not
understand the system
• Generally, those who have a working knowledge of computers often
underestimate user training needs.

Humanize the system

• System acceptance is unlikely if individuals believe the computer is controlling
them or has usurped their positions

Describe new challenges and opportunities

• System developers should emphasize important and challenging tasks that can
be performed with the new system.
• It should also emphasize that the system may provide greater job satisfaction
and increased opportunities.

Reexamine performance evaluation

• User’s performance standards and criteria should be reevaluated to ensure that
they are satisfactory in view of changes brought on by the new system.

Test the systems integrity

• The system should be properly tested prior to implementation to minimize initial
bad impressions.

Avoid emotionalism
• When logic vies with emotion, it rarely stands a chance
• Emotional issues related to change should be allowed to cool, handled in non-
confrontational manner or sidestepped.

Present the system in the proper context

• Users are vitally interested in how system changes affect them personally.
• Relevant explanations should be presented that address their concerns, rather
than the concern of managers or developers.
Control the user’s expectations
• Be realistic when describing the merits of the system.

Keep the system simple

• Avoid complex systems that cause radical changes.
• Make the change seem as simple as possible by conforming to existing
organizational procedures.

Note:
• Observing these guidelines is both time-consuming and expensive.
• As a result, workers tend to skip the more difficult steps to speed up systems
development and installation.
• However, the problems caused by not following these guidelines are usually
more expensive and time-consuming to fix than preventing behavioral problems.

SYSTEMS ANALYSIS
• When a new or improved system is needed, a written request for systems
development is prepared.
• The request describes the current system’s problems, the reason for the change,
and the proposed system’s goals and objectives, and the anticipated benefits
and costs.
• The project development team conducts the analysis.

 Initial Investigation:
• Conducted to screen projects
• The person conducting should:
• Gain a clear picture of the problem or need (new or improved system is
not always the solution to the problem)
• Determine the project’s viability and expected costs and payoffs
• Evaluate the projects scope and nature of the IS. (new or improved
system is not the solution to organizational problem)
• Recommend whether the development project should be initiated as
proposed, modified or abandoned
• If a project is approved, a proposal to conduct systems analysis is prepared
• It is assigned a priority and added to the master plan.
• As the investigation progresses, the proposal will be modified as more
information becomes available.
 Proposal to Conduct Systems Systems Survey Report Systems Analysis Report
Analysis

• Executive Summary • Executive Summary • Executive Summary

• System Problems and • Systems Goals and Objectives • Systems Goals and
Opportunities • System Problems and Opportunities Objectives
• Goals and Objectives of • Current Systems Operations • System Problems and
the Proposed System • Policies, procedures and Opportunities
• Project Scope practices affecting the • Project Scope
• Anticipated Costs and systems • Relationship of project
Benefits • System design and to overall strategic
• Participants in the operations Information Systems
Development Project • System users and their Plan
• Proposed Systems responsibilities • Current Systems
Development Tasks and • Systems outputs, inputs, and Operations
Work Plan data storage • User Requirements
• Recommendations • Systems controls • Feasibility Analysis
• Systems strengths, • Systems Constraints
weaknesses and constraints • Recommendation for
• Costs to operate the system New System
• User requirements identified • Etc. etc, etc,
during survey

Objectives of the System Survey

• Gain a thorough understanding of company operations, (policies, and

procedures; data and information flow; IS strength and weaknesses; available
hardware and software)
• Make a preliminary assessments of current and future processing needs, and
determine the extent and nature of the needs
• Develop working relationships with users and build support for the IS
• Collect data that identify user needs, conduct a feasibility analysis, and make
recommendations to management.

Data Gathering Techniques:

• Interview
• Questionnaires
• Observation
• Systems Documentation

Documenting:
• The information gathered during the analysis phase must be documented
• This documentation will be used throughout the system development project
• Documentation includes:
• Questionnaire copies
• Interview notes
• Memos
• Document copies

Modeling:
• Another way of documenting a system is to model it
 • Physical models illustrate how a system functions (flow of documents, computer
processes, people involved, equipment used, and other physical elements of the
systems)
• Logical models illustrate what is being done regardless of how it is done

The system survey phase will culminate with a SYSTEM SURVEY REPORT

Proposal to Conduct Systems Systems Survey Report Systems Analysis Report

Analysis

• Executive Summary • Executive Summary • Executive Summary

• System Problems and • Systems Goals and Objectives • Systems Goals and
Opportunities • System Problems and Opportunities Objectives
• Goals and Objectives of • Current Systems Operations • System Problems and
the Proposed System • Policies, procedures and Opportunities
• Project Scope practices affecting the • Project Scope
• Anticipated Costs and systems • Relationship of project
Benefits • System design and to overall strategic
• Participants in the operations Information Systems
Development Project • System users and their Plan
• Proposed Systems responsibilities • Current Systems
Development Tasks and • Systems outputs, inputs, and Operations
Work Plan data storage • User Requirements
• Recommendations • Systems controls • Feasibility Analysis
• Systems strengths, • Systems Constraints
weaknesses and constraints • Recommendation for
• Costs to operate the system New System
• User requirements identified • Etc. etc, etc,
during survey

The third phase of systems analysis is the Feasibility Study (discussed in the types of
plan.

The fourth phase of systems analysis is Information Needs and Systems Requirements.
• Once the project is deemed feasible, the company identifies the information
needs of users and documents systems requirements.

Systems Objectives and Constraints:

• Most organizations use the Systems approach in determining information needs

and systems requirements

• In this approach, problems and alternatives are viewed from the standpoint of the
entire organization, rather than from any single department or interest group

• Systems objectives allows analysts and users to focus on those elements most
vital to the ISs success

• However, it is difficult for a system to satisfy every objective.

• The system then should strike a balance between these objectives.

• Example: the objective of economy and reliability

 • Organizational constraints make it impossible to develop all parts of a new IS
simultaneously.

• The system is divided into smaller subsystems, or modules, that are analyzed,
developed and installed independently.

• When changes are made to the system, only the affected module needs to be
changed.

• A system’s success often depends on the project team’s ability to cope with
these constraints.

• Examples of constraints”
• Government agency requirements
• Management policies and guidelines
• Lack of sufficiently qualified staff
• Capabilities and attitudes of system users
• Available technology
• Limited financial resources
• Strategies for Determining Systems Requirements:
• Ask users what they need
• Analyze existing systems
• Examine existing system use
• Create a prototype

Proposal to Conduct Systems Systems Survey Report Systems Analysis Report

Analysis

• Executive Summary • Executive Summary • Executive Summary

• System Problems and • Systems Goals and Objectives • Systems Goals and
Opportunities • System Problems and Opportunities Objectives
• Goals and Objectives of • Current Systems Operations • System Problems and
the Proposed System • Policies, procedures and Opportunities
• Project Scope practices affecting the • Project Scope
• Anticipated Costs and systems • Relationship of project
Benefits • System design and to overall strategic
• Participants in the operations Information Systems
Development Project • System users and their Plan
• Proposed Systems responsibilities • Current Systems
Development Tasks and • Systems outputs, inputs, and Operations
Work Plan data storage • User Requirements
• Recommendations • Systems controls • Feasibility Analysis
• Systems strengths, • Systems Constraints
weaknesses and constraints • Recommendation for
• Costs to operate the system New System
• User requirements identified • Etc. etc, etc,
during survey

The final output of Systems Analysis is the Systems Analysis Report.

CONCEPTUAL DESIGN (2ND Step in SDLC)

• In the conceptual systems design phase, a general framework is developed for

implementing user requirements and solving problems identified in the analysis
phase.

• What are the three steps in conceptual design?

• Evaluate design alternatives

• Prepare design specifications

• Prepare conceptual systems design report

• Evaluate design alternatives:

• The design team should identify and evaluate design alternatives using
the following criteria:
• How well it meets organizational and system objectives
• How well it meets users’ needs
• Whether it is economically feasible
• Its advantages and disadvantages

• Prepare Design Specifications:

• Once a design alternative has been selected, the team develops the
conceptual design specifications for the following elements
• Output
• Data Storage
• Input
• Processing Procedures and Operations
• Prepare Conceptual Design Report

• At the end of the conceptual design, a conceptual systems design report is

developed and submitted.
• To guide physical systems design activities
• To communicate how management and user information need will
be met
• To help assess systems’ feasibility

PHYSICAL DESIGN (3rD Step in SDLC)

 • Physical design translates the broad, user-oriented IS requirements of
conceptual design into detailed specifications that are used to code and test the
computer program

Output Design:
• The objective of output design is to determine the characteristics of reports,
documents, and screen displays.
• Output fits into one of four categories
– Scheduled reports
– Special-purpose analysis
– Triggered exception reports
– Demand reports
• Outputs Categories
– Scheduled reports
• Prespecified content and format
• Prepared on a regular basis
• Ex: monthly performance reports; weekly sales analyses
– Special-purpose analysis
• No prespecified content or format
• Prepared in response to a management request to evaluate an
issue
• Ex; which of the three new products would provide a highest profit.
– Triggered exception reports
• Have a pre specified content and format
• Prepared in response to abnormal conditions.
• Ex; excessive absenteeism, inventory shortages
– Demand reports
• Have a pre-specified content and format
• Prepared only on request

• File/ database design:

– File and database design considerations
– Medium of storage
– Organization and Access
– Processing mode
– Maintenance
– Size and Activity Level
• Input Design:
– When evaluating input design, the design team must identify the different
types of data input and optimal input method.
– Types of data input
• Forms
• Computer Screen
• Program Design:
– Program design is one of the most time-consuming activities in the entire
SDLC.
– Programs should be subdivided into small, well-defined modules to reduce
complexity.
– This is referred to as structured programming
– Modules should interact with a control module rather than with each other.
• Procedures design should answer the who, what, where, and how questions
related to all IS activities.
– What should procedures cover?
• input preparation
• transaction processing
• error detection and corrections
• control
• reconciliation of balances
• database access
• output preparation and distribution
• computer operator instructions
• Control design:
– What are some control design considerations?
• validity
• authorization
• accuracy
• access
• numerical control
• audit trail
• At the end of the physical design phase the team prepares a physical systems
design report. This report becomes the basis for management’s decision
whether to proceed to the implementation phase.

SYSTEMS IMPLEMENTATION (4TH Step in SDLC)

• Systems implementation is the process of installing hardware and software and

getting the IS up and running.
Implementation planning:
• An implementation plan consists of implementation tasks, expected completion
dates, cost estimates, and the person or persons responsible for each task.
• Planning should include adjustments to the company’s organizational structure.
(Creation of new departments, elimination of existing ones or downsizing)

Prepare site; install and test hardware:

• A PC requires little site preparation.
• A large system may require extensive changes, such as additional electrical
outlets, data communication facilities, air-conditioning, etc.
• Site preparation is a lengthy process and should begin well in advance of the
installation date.

Select and train personnel:

• Employees can be hired from outside the company or transferred internally.
• Hiring from within the company is less costly, more effective alternative because
employees already understand the firm’s business and operations.
• Aside from hardware and software, effective IS training should include
employees’ orientation to new policies and operations.
• Training should occur before systems testing and conversion.
Complete documentation:
• Three types of documentation must be prepared for new systems.
1. Development documentation.
• Describes the IS.
• Includes system descriptions; copies of output, input, file and
database layouts, program flowcharts, test results, and user
acceptance form.
2. Operations documentation. Includes operating schedules, files and
databases accessed, equipment, security, and file retention requirements.
3. User documentation. Teaches the users to operate the systems. Includes
procedures manual and training materials.

Test system:
• Inadequate testing may result to failure.
• Documents and reports, user input, operating and control procedures, processing
procedures, and computer programs should all be given a trial run in a realistic
circumstances;
• Capacity limits, backup, and recovery procedures should also be tested.
• There are three common forms of testing.
• Walk-through. A step-by-step review of procedures or program logic.
• Processing of test transactions. Testing that determines if a program
operates as designed. Valid and erroneous data are processed to
determine if transactions are handled properly and errors are detected and
dealt with appropriately.
• Acceptance tests. Use copies of real transaction and file records rather
than hypothetical ones.

• Systems Conversion is the process of changing from the old IS to the new.
• Many elements must be converted:
• Hardware
• Software
• Data files
• Procedures

• There are four conversion approaches.

1. Direct conversion
• Immediately terminates the old IS when the new one is introduced.
• Appropriate when the old IS has no value to the new.
• Inexpensive, but provides no backup
• Must be carefully developed and tested because it carries a high
risk of failure.
2. Parallel conversion
• Operates the old and the new systems simultaneously for a period
of time.
• After the new system has proves itself, the old system is
discontinued.
 • Parallel processing protects companies from errors.
• Costly and stressful to the employees because they need to
process each transaction twice.
3. Phase-in conversion
• Gradually replaces elements of the old systems with the new one.
• The gradual changes mean that data processing resources can be
acquired over time.
• The disadvantage is the cost of creating a temporary interface
between the old and the new system.
4. Pilot conversion
• Implements the system in just one part of the organization, say in
one location/branch.
• When the system is proven, it is then implemented to the remaining
locations.
• The conversion can be any of the first three approaches.
• Disadvantage: long conversion time because it has to be proven
first in one location before it can be implemented to others.
• Temporary interfaces are maintained between the old and the new
systems.

• Data conversion:
• Data files may need to be modified in three ways:
• Files may be moved to a different storage, i.e. from tapes to disks.
• Data content may be changed, i.e. fields and records may be
added or deleted.
• File or database format may be changed

OPERATION AND MAINTENANCE (5TH Step in SDLC)

• The final step in the SDLC is to operate and maintain the new system.
• A post-implementation review should be conducted on a newly installed system.
• What are some questions to answer during the post-implementation review?
– Does the system produce accurate and complete data?
– Is the system safeguarded against unintentional errors, fraud, and
unauthorized intrusion?
– Is the system documentation complete and accurate?

Why Systems Projects Fails?

• Poorly specified systems requirements
– communication problems
– time pressures
• Ineffective development techniques
– paper, pencils, templates, erasers instead of software tools, such as
CASE
• Lack of user involvement in systems development
Deliver the System: The Role of the Accountants
• Most system failures are due to poor design and improper implementation.
• Accountants should provide their expertise to help avoid inadequate systems by:
– providing technical expertise for financial reporting requirements
– specifying documentation standards for auditing purposes
– verifying control adequacy in accordance with SAS 78

PROTOTYPING

• Prototyping is the process of building a model of a system.

• In IS, prototypes are employed to help system designers build an information
system that is easy to manipulate for end users.
• Prototyping is an iterative process that is part of the analysis phase of the
systems development life cycle.
• During requirement analysis, the systems analysts conduct interviews and collect
documentation related to the proposed systems.
• Prototyping helps the analysts develop an initial set of system requirements.
• It also helps analysts by converting basic specifications into tangible but limited
working model of the desired information system.
• The user feedback gained from developing a physical system that the users can
touch and see facilitates an evaluative response that the analyst can employ to
modify existing requirements as well as developing new ones.

Advantages Disadvantages

Reduces development time Can lead to insufficient analysis

Reduces development costs Users expect the performance of the

ultimate system to be the same as the
prototype
Requires user involvement Developers can become too attached to
their prototypes

Developers receive quantifiable user Can cause systems to be left unfinished

feedback and/or implemented before they are
ready
Facilitates implementation since users know Sometimes lead to incomplete
what to expect documentation

Results in higher user satisfaction If sophisticated software prototypes are

employed (CASE) the time saving
benefit of prototyping can be lost.
RAD – Rapid Application Development

• RAD is a popular software development methodology employing various tools

and techniques to quickly produce minimally-coded software applications.
• RAD’s essence is prototyping - creating predefined components, structures and
methods to quickly develop software models.
• RAD’s working software prototypes lack full-scale functionality.
• They are used primarily for demonstration and requirement gathering, which
helps end users envision entire solution stacks.
• RAD contains built-in and customizable data, processes and organizational
models.
• Thus, it employs a model-driven and object-oriented approach to developing
complete solutions.

OUTSOURCING

• Outsourcing is an allocation of specific business processes to a specialist

external service provider.
• Most of the times an organization cannot handle all aspects of a business
process internally.
• Additionally some processes are temporary and the organization does not intend
to hire in-house professionals to perform the tasks.

Advantages:
• Swiftness and Expertise: tasks can be completed faster and with better quality
output
• Concentrating on core process rather than the supporting ones:
organization has more time to strengthen their core business process
• Risk-sharing: Outsourcing certain components of your business process helps
the organization to shift certain responsibilities to the outsourced vendor.
• Reduced Operational and Recruitment costs: Outsourcing eludes the need to
hire individuals in-house; hence recruitment and operational costs can be
minimized to a great extent.

Disadvantages:
• Risk of exposing confidential data: When an organization outsources HR,
Payroll and Recruitment services, it involves a risk if exposing confidential
company information to a third-party
• Synchronizing the deliverables: In case you do not choose a right partner for
outsourcing, some of the common problem areas include stretched delivery time
frames, sub-standard quality output and inappropriate categorization of
responsibilities.
• Hidden costs: Although outsourcing most of the times is cost-effective at times
the hidden costs involved in signing a contract while signing a contract across
international boundaries may pose a serious threat
 • Lack of customer focus: An outsourced vendor may be catering to the
expertise-needs of multiple organizations at a time. In such situations vendors
may lack complete focus on your organization’s tasks

COMMERCIAL PACKAGES

• Four factors have stimulated the growth of commercial software:

– relatively low cost
– prevalence of industry-specific vendors
– growing demand by small businesses
– trend toward downsizing and distributed data processing

Trends in Commercial Packages:

• Turnkey systems - completely finished and tested systems ready for
implementation
• Backbone systems - provide a basic system structure on which to build.
• Vendor-supported systems - customized and maintained by a vendor for a
customer
• ERP systems - difficult to classify since they have characteristic of all of the
above.

Pros and Cons of Commercial Packages

• Advantages:
– decreased implementation time
– decreased cost
– reduced probability of program errors
• Disadvantages:
– dependent on the vendor for maintenance
– less flexibility in system
– greater difficulty in modifying the system as needs change over time

Four Steps in Choosing a Commercial Package

1. Analyze needs and develop detailed specifications of the system
requirements.
2. Send out the request for proposals to all prospective vendors to serve as a
comparative basis for initial screening.
3. Gather the facts about each vendor’s system using multiple sources and
techniques.
4. Analyze the findings and make a final selection.