Systems Analysis & Design Sixth Edition Chapter 9

advertisement
Systems Analysis & Design
Sixth Edition
Chapter 9
Phase Description
● Systems Implementation is the fourth of
five phases in the systems development
life cycle (SDLC)
● Includes application development,
testing, documentation, training, data
conversion, system changeover, and
post-implementation evaluation of the
results
2
Chapter Objectives
● Explain the importance of software quality
assurance and software engineering
● Describe the application development process
● Draw a structure chart showing top-down
design, modular design, cohesion, and coupling
● Explain the coding process and how code is
generated
● Explain unit testing, integration testing, and
system testing
3
Chapter Objectives
● Differentiate between program, system,
operations, and user documentation
● List the main steps in system installation
and evaluation
● Develop an overall training plan with
specific objectives for each group of
participants, compare in-house and
outside training providers, and describe
effective training techniques
4
Chapter Objectives
● Describe the data conversion process
● Identify and describe changeover
methods
● Explain post-implementation evaluation
● Describe the final report to management
5
Introduction
● The system design specification serves as a
blueprint for constructing the new system
● The initial task is application development
● Before a changeover can occur, the system
must be tested and documented carefully,
users must be trained, and existing data must
be converted
● A formal evaluation of the results takes place
as part of a final report to management
6
Software Quality Assurance
● Quality assurance
● Software Engineering
–
–
–
–
–
Software Engineering Institute (SEI)
Capability Maturity Model (CMM)
Capability Maturity Model Integration (CMMI)
Process improvement
CMMI tracks an organization's processes, using
five maturity layers
7
Software Quality Assurance
● International Organization for
Standardization (ISO)
– Many firms seek assurance that software
systems will meet rigid quality standards
– In 1991, ISO established a set of guidelines
called ISO 9000-3
– ISO requires a specific development plan,
which outlines a step-by-step process for
transforming user requirements into a finished
product
8
Overview of Application Development
● Application development
● Objective is to translate the logical
design into program and code modules
that will function properly
● Creation of the System Design
– The tasks involved in system design produced
an overall design and a plan for physical
implementation
9
Overview of Application Development
● Application
Development Steps
– Module
– Start by reviewing
documentation from
prior SDLC phases and
creating a set of
program designs
– After the design is
created, coding can
begin
10
Overview of Application Development
● Project Management
– Even a modest-sized project might have
hundreds or even thousands of modules
– Important to set realistic schedules, meet project
deadlines, control costs, and maintain quality
– Should use project management tools and
techniques
11
Structured Application Development
●
●
●
●
Top-down approach
Partitioning
Modular design
Must proceed carefully, with constant
input from programmers and IT
management to achieve a sound, wellintegrated structure
● Must ensure that integration capability
is built into each design and thoroughly
tested
12
Structured Application Development
● Structure Charts
– Structure charts show the program modules and
the relationships among them
– Control module
– Subordinate modules
13
Structured Application Development
● Structure Charts
– Module
• Library module
– Data Couple
– Control Couple
• Flag
• A module uses a flag to signal a specific condition or
action to another module
14
Structured Application Development
● Structure Charts
– Condition
• A condition line indicates that a control module
determines which subordinate modules will be
invoked, depending on a specific condition
– Loop
• A loop indicates that one or more modules are
repeated
15
Structured Application Development
● Cohesion and Coupling
– If you need to make a module more cohesive,
you can split it into separate units, each of
which performs a single function
– Loosely coupled
– Tightly coupled
– Status flag
16
Structured Application Development
● Structure Chart Examples
17
Structured Application Development
● Drawing a Structure Chart
–
–
–
–
Step 1: Review the DFDs
Step 2: Identify Modules and Relationships
Step 3: Add Couples, Loops, and Conditions
Step 4: Analyze the Structure Chart and the
Data Dictionary
18
Structured Application Development
● Other Structured Development Tools
– Program Flowcharts
– Pseudocode
19
Object-Oriented Application
Development
● Object-Oriented Application
Development Compared to Structured
Development
– When implementing an object-oriented design,
relationships between objects already exist
– The application's structure is represented by the
object model itself
– Attributes
– Methods
20
Object-Oriented Application
Development
● Implementation of Object-Oriented
Design
– Programmer makes necessary revisions and
updates to class diagrams, sequence diagrams,
state transition diagrams, and activity diagrams
– Main objective is to translate object methods into
program code modules and determine what
event or message will trigger the execution of
each module
21
Coding
● Coding
● Programming Environments
– Each IT department has its own programming
environment and standards
– Integrated development environments (IDEs)
● Generating Code
– Can generate editable program code directly
from macros, keystrokes, or mouse actions
22
Testing the System
● After coding, a programmer must test
each program to make sure that it
functions correctly
● Syntax errors
● Desk checking
– Logic errors
● Structured walkthrough, or code review
● Design walkthrough
23
Testing the System
● Unit Testing
– Test data
– Programmers must test programs that
interact with other programs and files
individually
– Stub testing
– Regardless of who creates the test plan, the
project manager or a designated analyst also
reviews the final test results
24
Testing the System
● Integration Testing
– Integration testing, or link testing
– Testing the programs independently does not
guarantee that the data passed between them is
correct
– A testing sequence should not move to the
integration stage unless it has performed
properly in all unit tests
25
Testing the System
● System Testing
– Major objectives:
• Perform a final test of all programs
• Verify that the system will handle all input data
properly, both valid and invalid
• Ensure that the IT staff has the documentation
and instructions needed to operate the system
properly and that backup and restart capabilities
of the system are adequate
26
Testing the System
● System Testing
– Major objectives:
• Demonstrate that users can interact with the system
successfully
• Verify that all system components are integrated
properly and that actual processing situations will be
handled correctly
• Confirm that the information system can handle
predicted volumes of data in a timely and efficient
manner
27
Testing the System
● System Testing
– Acceptance tests
– You should regard thorough testing as a costeffective means of providing a quality product
– If conflicting views exist, management will
decide whether or not to install the system after
a full discussion of the options
28
Documentation
●
●
●
●
●
Documentation
Program Documentation
System Documentation
Operations Documentation
User Documentation
– Online documentation
29
Management Approval
● After system testing is complete, you
present the results to management
● If system testing produced no technical,
economical, or operational problems,
management determines a schedule for
system installation and evaluation
30
System Installation and Evaluation
● Remaining steps in systems
implementation:
– Prepare a separate operational and test
environment
– Provide training for users, managers, and IT
staff
– Perform data conversion and system
changeover
– Carry out post-implementation evaluation of
the system
– Present a final report to management
31
Operational and Test Environments
● The environment for the actual system
operation is called the operational
environment or production environment
● The environment that analysts and
programmers use to develop and
maintain programs is called the test
environment
● A separate test environment is necessary
to maintain system security and integrity
and protect the operational environment
32
Operational and Test Environments
33
Training
● Training Plan
– The first step is to identify who should receive
training and what training is needed
– The three main groups for training are users,
managers, and IT staff
– You must determine how the company will
provide training
34
Training
● Vendor Training
– If the system includes the purchase of
software or hardware, then vendor-supplied
training is one of the features you should
include in the RFPs (requests for proposal)
and RFQs (requests for quotation) that you
send to potential vendors
– Often gives the best return on your training
dollars
35
Training
● Outside Training Resources
– Many training consultants, institutes, and firms
are available that provide either standardized or
customized training packages
– You can contact a training provider and obtain
references from clients
– Center for the Application of Information
Technologies (CAIT)
36
Training
● In-House Training
– The IT staff and user departments often share
responsibility
– When developing a training program, you
should keep the following guidelines in mind:
• Train people in groups, with separate training
programs for distinct groups
• Select the most effective place to conduct the training
• Provide for learning by hearing, seeing, and doing
• Prepare effective training materials, including
interactive tutorials
• Tutorial
37
Training
● In-House Training
– When developing a training program, you should
keep the following guidelines in mind:
• Rely on previous trainees
• Train-the-trainer strategy
– When Training is complete, many organizations
conduct a full-scale test, or simulation
38
Data Conversion
● Data Conversion Strategies
– The old system might be capable of exporting
data in an acceptable format for the new
system or in a standard format such as ASCII or
ODBC
– If a standard format is not available, you must
develop a program to extract the data and
convert it
– Often requires additional data items, which
might require manual entry
39
Data Conversion
● Data Conversion Security and Controls
– You must ensure that all system control
measures are in place and operational to protect
data from unauthorized access and to help
prevent erroneous input
– Some errors will occur
– It is essential that the new system be loaded
with accurate, error-free data
40
System Changeover
● Direct Cutover
– Involves more risk than other changeover
methods
– Companies often choose the direct cutover
method for implementing commercial software
packages
– Cyclical information systems usually are
converted using the direct cutover method at
the beginning of a quarter, calendar year, or
fiscal year
41
System Changeover
● Parallel Operation
– Easier to verify that the new system is working
properly under parallel operation than under
direct cutover
– Running both systems might place a burden
on the operating environment and cause
processing delay
– Is not practical if the old and new systems are
incompatible technically
– Also is inappropriate when the two systems
perform different functions
42
System Changeover
● Pilot Operation
– The group that uses the new system first is
called the pilot site
– The old system continues to operate for the
entire organization
– After the system proves successful at the pilot
site, it is implemented in the rest of the
organization, usually using the direct cutover
method
– Is a combination of parallel operation and
direct cutover methods
43
System Changeover
● Phased Operation
– You give a part of the system to all users
– The risk of errors or failures is limited to the
implemented module only
– Is less expensive than full parallel operation
– Is not possible, however, if the system cannot
be separated easily into logical modules or
segments
44
Post-Implementation Tasks
● Post-Implementation Evaluation
– Includes feedback for the following areas:
• Accuracy, completeness, and timeliness of information
system output
• User satisfaction
• System reliability and maintainability
• Adequacy of system controls and security measures
• Hardware efficiency and platform performance
45
Post-Implementation Tasks
● Post-Implementation Evaluation
– Includes feedback for the following areas:
•
•
•
•
•
Effectiveness of database implementation
Performance of the IT team
Completeness and quality of documentation
Quality and effectiveness of training
Accuracy of cost-benefit estimates and development
schedules
46
Post-Implementation Tasks
● Post-Implementation Evaluation
– When evaluating a system, you should:
• Interview members of management and key users
• Observe users and computer operations personnel
actually working with the new information system
• Read all documentation and training materials
• Examine all source documents, output reports, and
screen displays
• Use questionnaires to gather information and opinions
form a large number of users
• Analyze maintenance and help desk logs
47
Post-Implementation Tasks
● Post-Implementation Evaluation
– Users can forget details of the developmental
effort if too much time elapses
– Pressure to finish the project sooner usually
results in an earlier evaluation in order to
allow the IT department to move on to other
tasks
– Ideally, conducting a post-implementation
evaluation should be standard practice for all
information systems projects
48
Post-Implementation Tasks
● Final Report to Management
– Your report should include the following:
• Final versions of all system documentation
• Planned modifications and enhancements to the
system that have been identified
• Recap of all systems development costs and
schedules
• A comparison of actual costs and schedules to the
original estimates
• Post-implementation evaluation, if it has been
performed
– Marks the end of systems development work
49
Chapter Summary
● Develop a training program
● Data conversion often is necessary
when installing a new information
system
● System changeover is the process of
putting the new system into operation
● A post-implementation evaluation
assesses and reports on the quality of
the new system and the work done by
the project team
50
Chapter Summary
● The final report to management includes
the final system documentation,
describes any future system
enhancements that already have been
identified, and details the project costs
● Chapter 9 complete
51
Download