Whitten−Bentley: Systems Analysis and Design Methods, Seventh

Transcription

Whitten−Bentley: Systems
Analysis and Design
Methods, Seventh Edition
IV. Beyond Systems
Analysis and Design
© The McGraw−Hill
Companies, 2007
20. Systems Operations and
Support
Strategic Enterprise Plan
Strategic Information Systems Plan
Goal:
Improve Business
PROCESSES
Goal:
Improve Business
KNOWLEDGE
Goal:
Improve Business
COMMUNICATIONS
SYSTEM
OWNERS
SYSTEM
OWNERS
SYSTEM USERS
LOGICAL
PROCESS
MODELS
LOGICAL
INTERFACE
MODELS
SYSTEM PROPOSAL
(or
REQUEST FOR SYSTEM PROPOSALS)
ARCHITECTURAL MODEL
BUSINESS PROCESS
DESIGN
PHYSICAL
DATABASE
DESIGN
SPECIFICATIONS
PHYSICAL
SOFTWARE DESIGN
SPECIFICATIONS
COMMERCIAL
SOFTWARE
PACKAGES
O P E R AT I O N A L S Y S T E M
Constraint:
APPROVED
DATABASE
TECHNOLOGIES
USER
INTERFACE
SOLUTIONS
SYSTEM
INTERFACE
SOLUTIONS
P O S T- A U D I T R E V I E W
Constraint:
APPROVED
PROCESS
TECHNOLOGIES
Constraint:
APPROVED
INTERFACE
TECHNOLOGIES
Constraint: APPROVED NETWORK TECHNOLOGIES
Strategic Enterprise Information Technology Architecture
INSTALLATION
& DELIVERY
CUSTOM-BUILT
APPLICATION
SOFTWARE
MIDDLEWARE
MIDDLEWARE
T R A I N I N G M AT E R I A L S
CONSTRUCTION
& TESTING
FUNCTIONAL SYSTEM
DATABASE
SOLUTION
PHYSICAL
USER & SYSTEM
INTERFACE
DESIGN
SPECIFICATIONS
PHYSICAL
DESIGN
SYSTEM DESIGNERS
DESIGN PROTOTYPES
SYSTEM BUILDERS
SYSTEMS ANALYSTS
LOGICAL
DATA
MODELS
FEASIBILITY ANALYSIS and RISK MANAGEMENT
and
BUSINESS & SYSTEM
INTERFACE
REQUIREMENTS
DECISION
ANALYSIS
PROJECT MANAGERS
BUSINESS
PROCESS
REQUIREMENTS
LOGICAL
DESIGN
BUSINESS
DATA
REQUIREMENTS
REQUIREMENTS
ANALYSIS
B U S I N E S S R E Q U I R E M E N T S S TAT E M E N T
PROJECT and PROCESS MANAGEMENT
SYSTEM IMPROVEMENT OBJECTIVES (using the PIECES framework)
PROBLEM
ANALYSIS
COMMUNICATIONS
SCOPE
&
VISION
FUNCTIONAL
SCOPE
&
VISION
INFORMATION
SCOPE
&
VISION
SCOPE
DEFINITION
S TAT E M E N T O F W O R K
P R O B L E M S TAT E M E N T ( u s i n g t h e P I E C E S f r a m e w o r k )
Analysis and Design
IV. Beyond Systems
Analysis and Design
Support
20
Companies, 2007
Systems Operations and
Support
Chapter Preview and Objectives
Once a system has been implemented, it enters operations and support. Systems operation
is the ongoing function in which the system operates until it is replaced. Systems support
involves servicing, maintaining, and improving a functional information system through
its lifetime. Systems operation and support occur in parallel. In this chapter, you will
learn more about systems operation and support. In particular, it is useful to understand
the different types of systems support provided for a production system. You will know
that you understand the process of systems support when you can:
❚ Define systems operations and support.
❚ Describe the relative roles of a repository, program library, and database in systems
operations and support.
❚ Differentiate between maintenance, recovery, technical support, and enhancement as
system support activities.
❚ Describe the tasks required to maintain programs in response to bugs.
❚ Describe the role of benchmarking in system maintenance.
❚ Describe the systems analyst’s role in system recovery.
❚ Describe forms of technical support provided by a systems analyst for the user
community.
❚ Describe the tasks that should be and may be performed in system enhancement and the
relationship between the enhancement and the original systems development process.
❚ Describe the role of reengineering in system enhancement. Describe three types of
reengineering.
Although some of the techniques of systems support are introduced in this chapter, the
chapter does not teach these techniques. This chapter teaches only the process of systems
support as it relates to the development processes you have been studying throughout this
book.
Analysis and Design
702
Part Four
IV. Beyond Systems
Analysis and Design
Support
Companies, 2007
Beyond Systems Analysis and Design
Introduction
It has been one week since SoundStage converted to the new Member Services system. Bob Martinez has been working on a few minor program bugs. As each bug has
cropped up, Bob has worked with the users to validate and document the problem.
He then passed that information to the programmers, who fixed the problem, tested
the revised program, and documented their changes. Finally Bob updated the version
control system with information about the fix.
All in all the conversion has gone very well, and Bob was starting to think he
was seeing the last of the Member Services system. Then his boss, Sandra, came to
him with a list of additional requirements. Most of them were lower-priority use
cases that had been intentionally left out of the first iteration. Others were requests
that came up during the analysis, design, and implementation phases. There were
even requests suggested by users now that they are actually working the system. So
Bob is starting back in the requirements analysis phase for iteration two. But now
that he is hearing from users how helpful the new system is, Bob is excited to make
it even better.
The Context of Systems Operation and Support
Systems support was introduced in Chapter 3. Systems support is the ongoing technical support for users, as well as the maintenance required to fix any errors, omissions, or new requirements that may arise. Before an information system can be
supported, it must first be in operation. Systems operation is the day-to-day, week-toweek, month-to-month, and year-to-year execution of an information system’s businesses processes and application programs. An operational system (not to be
confused with an operating system) is frequently called a production system. Systems
operation and support are often ignored in systems analysis and design textbooks.
Young analysts are often surprised to learn that half of their duties (or more) are
associated with supporting production systems.
In the chapter home page, you can see that systems operation and support use all
the information system building blocks since the information system is operational.
All the system knowledge and working components of the system are important to its
ongoing operation and support. This is reinforced in Figure 20-1, which demonstrates
that systems operations and support often require developers to revisit the activities,
and hence the building blocks, that were developed during systems analysis, design,
construction, and implementation.
Figure 20-2 illustrates systems development, systems operations, and systems
support as separate processes. Until this chapter, the entire book has focused on systems development. Systems development responds to problems, opportunities, and
directives by developing improved business solutions. To repeat: that process has
been the focus of this book. During systems development, we accumulated considerable system knowledge and constructed programs and databases.The figure illustrates
these three data stores:
• The repository is a data store(s) of accumulated system knowledge—system
models, detailed specifications, and any other documentation that has been
accumulated during the system’s development. This knowledge is reusable
and critical to the production system’s ongoing support. The repository is
implemented with various automated tools, and it is often centralized as an
enterprise business and IT resource.
• The program library is a data store of all application programs. The source
code for these programs must be maintained for the life of the system. Almost
always, the software-based librarian will control access (via check-in and
Operational
System
Post-audit
Review
8
Functional
System
Training
Materials
INSTALLATION
&
DELIVERY
Statement
of Work
SYSTEM OWNERS AND USERS
Design
Prototypes
Redesigned
Business
Processes
Documentation
PHYSICAL
DESIGN
&
INTEGRATION
6
Documentation
Documentation
PROBLEM
ANALYSIS
2
System
Proposal
Application
Architecture
Documentation
5
DECISION
ANALYSIS
Documentation
Documentation
3
REQUIREMENTS
ANALYSIS
System
Improvement
Objectives
Logical
Design
LOGICAL
DESIGN
4
Business
Requirements
Statement
Support
Physical
Design Specifications
CONSTRUCTION
&
TESTING
7
Scope & Vision
Documentation
Documentation
SCOPE
DEFINITION
1
Problem
Statement
START:
Problems, Opportunities,
Directives, Constraints,
and Vision
IV. Beyond Systems
Analysis and Design
F I G U R E 2 0 - 1 The Context of Systems Operation and Support
SYSTEM
OPERATION
&
MAINTENANCE
Life Cycle Stage
FINISH:
Working
Business
Solution
BUSINESS COMMUNITY
Analysis and Design
Companies, 2007
703
Analysis and Design
704
Part Four
IV. Beyond Systems
Analysis and Design
Companies, 2007
Support
FIGURE 20-2
THE BUSINESS COMMUNITY
System
Development,
Operations, and
Support Functions
Problems,
Opportunities,
and Directives
1-7
Systems
Development
Improved
Business
Solution
System
Knowledge
Metadata
and Data
Application
Software
Enterprise
Repository
Program
Library
System
Knowledge
Application
Software
(existing & revised)
Business
Data
Program
to Be
Executed
8B as needed
Data
Access &
Updates
Operational
System
8A ongoing
Updated Operational System
Systems
Support
Systems
Operation
Technical
Feedback
Updated
Business
Solution
Problem,
Opportunity,
or Directive
Problem,
Opportunity,
or Directive
User Feedback
TECHNICAL SUPPORT
THE USER COMMUNITY
THE USER COMMUNITY
Business
Solution
SYSTEM MANAGERS AND SUPPORT STAFF
checkout) to the stored programs as well as track changes and maintain several previous versions of the programs in case a problem in a new version
forces a temporary use of a prior version. Examples of such software configuration tools are Serena’s ChangeMan Professional, IBM’s CAA Source Code
Manager, and Microsoft’s Visual SourceSafe.
• The business data includes all the actual business data created and maintained by the production application programs. This includes conventional
files, relational databases, data warehouses, and any object databases. This
data is under the administrative control of the data administrator, who is
charged with backup, recovery, security, performance, and the like.
Unlike systems analysis, design, and implementation, systems support cannot sensibly be decomposed into actual phases that a support project must perform. Rather,
systems support consists of four ongoing activities. Each activity is a type of support
project that is triggered by a particular problem, event, or opportunity encountered
with the implemented system.
Figure 20-3 is an activity diagram that illustrates the four types of support
activities:
• Program maintenance—Unfortunately, most systems suffer from software
defects, or bugs—errors that slipped through the testing of software.
Analysis and Design
IV. Beyond Systems
Analysis and Design
Companies, 2007
Support
Systems Operations and Support
BUSINESS
COMMUNITY
Systems Support
Activities
8.1
8.2
System
Recovery
Corrected
Programs
Restored
Program
System
Knowledge
Enterprise
Repository
Restored
Data
Program
Library
Business
Data
Revised or
Restructured Programs
System
Knowledge
Restructured
Database
System Knowledge
THE BUSINESS COMMUNITY
8.3
Technical
Support
Operational
Problem
Operational
Solution
705
FIGURE 20-3
System
Failure
Bug
Program
Maintenance
Chapter Twenty
New
Business
Requirement
New
Business
Problem
8.4
System
Enhancement
Design Flaw
or Requirement
TECHNICAL COMMUNITY
New Technology
Directive
IT STAFF
• System recovery—From time to time, a system failure may result in a program “crash” and/or loss of data. Human error or a hardware or software
failure may have caused this. The systems analyst or technical support specialists may then be called on to recover the system—that is, to restore a system’s files and databases and to restart the system.
• Technical support—Regardless of how well the users have been trained and
how good the end-user documentation is, users will eventually require additional assistance—unanticipated situations arise, new users are added, and so
forth.
• System enhancement—New requirements may include new business problems, new business requirements, new technical problems, or new technology requirements.
This chapter examines each of these support activities in various levels of detail, but it abandons the approach used in previous systems analysis, design, and implementation overview chapters. Not all activities will be decomposed into tasks
because some of these activities are fairly routine. Also, in some cases, an activity
will involve returning to the system development activities that were discussed in
earlier chapters.
Analysis and Design
706
Part Four
IV. Beyond Systems
Analysis and Design
Support
Companies, 2007
System Maintenance
Regardless of how well designed, constructed, and tested a system or application may
be, errors or bugs will inevitably occur. Bugs can be caused by any of the following:
•
•
•
•
•
Poorly validated requirements.
Poorly communicated requirements.
Misinterpreted requirements.
Incorrectly implemented requirements or designs.
Simple misuse of the programs.
The fundamental objectives of system maintenance are:
• To make predictable changes to existing programs to correct errors that were
made during systems design or implementation.
• To preserve those aspects of the programs that were correct and to avoid the
possibility that “fixes” to programs cause other aspects of those programs to
behave differently.
• To avoid, as much as possible, degradation of system performance. Poor system maintenance can gradually erode system throughput and response time.
• To complete the task as quickly as possible without sacrificing quality and
reliability. Few operational information systems can afford to be down for any
extended period. Even a few hours can cost millions of dollars.
To achieve these objectives, you need an appropriate understanding of the programs you are fixing and of the applications in which those programs participate.
Lack of this understanding is often the downfall of systems maintenance!
How does system maintenance map to your information system building blocks?
• KNOWLEDGE/DATA—System maintenance may improve input data editing or
correct a structural problem in the database.
• PROCESSES—Most system maintenance is program maintenance.
• COMMUNICATION—System maintenance may involve correcting problems
related to how the application interfaces with the users or another system.
Figure 20-4 illustrates typical system maintenance tasks. Let’s examine these tasks.
> Task 8.1.1—Validate the Problem
System maintenance miniprojects are triggered by the identification of the problem,
usually called a bug. Most such bugs are identified by users when they discover some
aspect of the system that does not appear to be working as it should. The first task of
the systems analyst or programmer is to validate the problem.
Working with the users, the team should attempt to validate the problem by reproducing it. If the problem cannot be reproduced, the project should be suspended until
the problem recurs and the user can explain the circumstances under which it occurred. The “as is” program is executed, as closely as possible approximating the circumstances and the data that were present when the problem was first encountered. In
most cases, the user who encountered the problem should be the one who re-creates it.
One possible output is an unsubstantiated bug. In this scenario, the user (even
with help from the analyst) could not re-create the error. To maintain a productive relationship with the user, the analyst should never make the user feel that it was his or
her fault. Instead, the analyst should respect the possibility that the bug is still real and
that it will eventually be validated. Should the error recur, the user should be coached
to immediately document the exact sequence of events in detail or to call the analyst.
Most importantly, the user should be instructed not to perform any subsequent
action, if possible, that may prevent the error from being validated.
Analysis and Design
IV. Beyond Systems
Analysis and Design
Companies, 2007
Support
BUSINESS
COMMUNITY
System Maintenance
Tasks
Corrective
Instructions
8.1.2
Unsubstantiated Bug
Validate
the
Problem
Copy of Program with Substantiated Bug
Benchmark
Program
System
Knowledge
Test Data Set
and
Benchmarks
"As-Is"
Program
Program
Library
Enterprise
Repository
Bug-Fix
Requirements
Test
Database
System
Knowledge
8.1.3
Study and
Debug the
Program
(problem fixed)
Test
Data
Outcomes
Copy
of
Problem
Program
Corrected
Version
of
Program
707
FIGURE 20-4
Bug
8.1.1
Chapter Twenty
Benchmark
Data
8.1.4
Candidate
Release
Test
the
Program
Failed
Candidate
New Version of the Production Program
In some cases the analyst confirms the error but recognizes it as a simple misuse
or mistaken use of the program. In such cases, the appropriate output is corrective
instructions to the user.
The third possibility is that the bug is real.The analyst should do two things. First,
the context of the bug should be examined by studying all relevant documentation
(system knowledge) in the repository. In other words, don’t try to fix what you don’t
understand. Second, all subsequent maintenance should be performed on a copy of
the program. The original program remains in the program library and can be
used in production systems until it is fixed.
> Task 8.1.2—Benchmark Program
Given a copy of the program with a substantiated bug, the analyst should benchmark
the program. System maintenance can result in unpredictable and undesirable side
effects that impact the program’s or application’s overall functionality and performance. In other words, the solution can cause unexpected side effects. For this reason, before any changes are made to programs, the programs should be executed and
tested to establish a baseline against which the modified programs and applications
can later be measured.
Analysis and Design
708
Part Four
IV. Beyond Systems
Analysis and Design
Support
Companies, 2007
This task can be performed by the systems analyst and/or programmer. Users
should also participate to ensure the test is conducted under circumstances that
simulate as closely as possible a normal working environment.
Test cases can be defined in either of two ways. First, past test data may exist in
the repository as a form of system knowledge. If so, that data should be reexecuted to
establish or verify the benchmark. Usually, the test data should also be analyzed for
completeness and, if necessary, revised. New test scenarios may have been identified
since the system went into operation. Any revised test data should be recorded in the
repository for subsequent maintenance projects.
Alternatively, test data can be automatically captured using a software-testing tool.
As users enter test data, that data is recorded in a special type of repository as a test
script. Later the analyst and user can document each test case in the same repository.
Ultimately, the test script is executed against the program to test that the program executes properly and also to measure the program’s response time and/or throughput.
As shown in Figure 20-4, the test data and benchmarks are stored in a test database
(not the production database) for the next task.
The analyst or programmer needs to have good testing skills (usually taught in
programming courses) and may require training in test tools. Neither is explicitly
taught in this textbook.
> Task 8.1.3—Study and Debug the Program
The primary task in system maintenance is to make the required changes to the programs.This task, performed by the application programmer, is not dissimilar from that
described in the previous chapter on systems implementation. Essentially, the programmer responds to “bug-fix” requirements that establish the expectation for fixing
the problem. The programmer debugs (edits) a copy of the problem program.
Changes are not made to the production program. The result is a corrected version of
the program. This is a candidate release, meaning a candidate to become the next
production version of the program.
Usually, the original programmer is not making these changes. In fact, several programmers may have written parts of any given program that is now being debugged.
Those programmers may no longer be available for clarification. Even if they are available, their memory of the application may not be sufficient or accurate. For this reason, the effective maintenance programmer requires system knowledge. Ideally, this
knowledge comes from the repository, but that assumes that the knowledge has been
properly maintained throughout the system’s lifetime. Too often this is not true, especially for older systems. The programmer may need to seek out this knowledge or, in
some cases, reconstruct the knowledge through analysis of the program.
Application and program knowledge usually comes from studying the source
code. Program understanding can take considerable time. This activity is slowed by
some combination of the following limitations:
• Poor program structure—examples include COBOL programs written with
nonstructured techniques and Visual Basic or C programs written with
nonobject-oriented techniques.
• Unstructured logic (from pre–structured era coding styles).
• Prior maintenance (quick fixes and poorly designed extensions).
• Dead code (instructions that cannot be reached or executed—often leftovers
from prior testing and debugging).
• Poor or inadequate documentation.
The purpose of application understanding is to see the big picture—that is, how
the programs fit into the total application and how they interact with other programs.
The purpose of program understanding is to gain insight into how the program works
and doesn’t work. You need to understand the fields (variables) and where and how
they are used, and you need to determine the potential impact of changes throughout
Analysis and Design
IV. Beyond Systems
Analysis and Design
Support
Companies, 2007
Chapter Twenty
709
the program. Program understanding can also lead to better estimates of the time and
resources that will be required to fix the errors.
> Task 8.1.4—Test the Program
There is a big difference between editing a new program and editing an existing program. As the designer and creator of a new program, you are probably intimately familiar with the structure and logic of the program. By contrast, as the editor of the
existing program, you are not nearly as familiar (or current) with that program.
Changes that you make may have an undesirable ripple effect through other parts of
the program or, worse still, other programs in the application and information system.
A candidate release of the program must be tested before it can be placed into
operation as the next new version of the production program. The following tests are
essential or recommended:
• Unit testing (essential) ensures that the stand-alone program fixes the bug
without undesirable side effects to the program. The test data and current
performance that you recovered, created, edited, or generated when the
programs were benchmarked are used here.
• System testing (essential) ensures that the entire application, of which the
modified program was a part, still works. Again, the test data and current
performance are used here.
• Regression testing (recommended) extrapolates the impact of the changes
on program and application throughput and response time from the beforeand-after results using the test data and current performance.
Failed candidates are returned for additional debugging. Successful candidates are released for production. Older versions of the program are retained in the program library
for version control. Version control is a process whereby a librarian (usually softwarebased) keeps track of changes made to programs.This allows recovery of prior versions
of the programs if new versions cause unexpected problems. In other words, version
control allows users to return to a previously accepted version of the system.
The high cost of system maintenance is largely due to failure to update system
knowledge (in the repository) and program source code documentation (in the program library). Application documentation is usually the responsibility of the systems
analyst who supports the application. Program documentation is usually the responsibility of the programmer who made the program changes.
System Recovery
From time to time a system failure is inevitable. It generally results in an aborted, or
“hung,” program (also called an ABEND or “crash”) and may be accompanied by loss
of transactions or stored business data. The systems analyst often fixes the system or
acts as intermediary between the users and those who can fix the system.This section
summarizes the analyst’s role in system recovery.
System recovery activities can be summarized as follows:
1. In many cases the analyst can sit at the user’s terminal and recover the system. It
may be something as simple as pressing a specific key or rebooting the user’s
personal computer. The systems analyst may need to provide users with corrective
instructions to prevent the crash from recurring. In some cases the analyst may
arrange to observe the user during the next use of the program or application.
2. In some cases the analyst must contact systems operations personnel to correct
the problem. This is commonly required when servers are involved. An appropriate
network administrator, database administrator, or Webmaster usually oversees
such servers.
version control the tracking of changes made to a
program.
Analysis and Design
710
Part Four
IV. Beyond Systems
Analysis and Design
Support
Companies, 2007
3. In some cases the analyst may have to call data administration to recover lost or
corrupted data files or databases. In the recovery of business data, it is not only
the database that must be restored.
a. Any transactions that occurred between the last backup and the database’s
recovery must be reprocessed. This is sometimes called a roll forward.
b. If the crash occurred during a transaction, and that transaction was partially
completed, then any transactional updates to the database that occurred before the crash must be undone before reprocessing the complete transaction.
This is sometimes called a roll back.
Database management systems and transaction monitors provide facilities for
transaction roll forward and roll back. These data backup and recovery
techniques are beyond the scope of this book and are deferred to database
courses and textbooks.
4. In some cases the analyst may have to call network administration to fix a local,
wide, or internetworking problem. Network professionals can usually log out an
account and reinitialize programs.
5. In some cases the analyst may have to call technicians or vendor service representatives to fix hardware problems.
6. In some cases the analyst will discover that a possible software bug caused the
crash. The analyst attempts to quickly isolate the bug and trap it (automatically or
by coaching users to manually avoid it) so that it can’t cause another crash. Bugs
are then handled as described in the previous section of this chapter.
Technical Support
Another relatively routine ongoing activity of systems support is technical support.
No matter how well users have been trained or how well documentation has been
written, users will require additional assistance. The systems analyst is generally on
call to assist users with the day-to-day use of specific applications. In mission-critical
applications, the analyst must be on call day and night.
The most typical tasks include:
•
•
•
•
•
Routinely observing the use of the system.
Conducting user-satisfaction surveys and meetings.
Changing business procedures for clarification (written and in the repository).
Providing additional training as necessary.
Logging enhancement ideas and requests in the repository.
System Enhancement
Adapting an existing system to new requirements is the norm for all information systems.
Business is change! The pace of change in today’s economy is accelerated, and rapid response is the expectation. System enhancement requires that the systems analyst evaluate a new requirement to either effect change or direct the change request through an
appropriate subset of the original systems development process. In some cases, the analyst may need to recover the system’s existing physical structure as a preface to directing
the change through systems redevelopment. In this section we will examine two types
of adaptive maintenance—system enhancement and systems reengineering.
System enhancement is an adaptive process. Most such enhancement is in response to one of the following events, as shown in Figure 20-5:
• New business problems—A new or anticipated business problem will make a
portion of the current system unusable or ineffective.
• New business requirements—A new business requirement (e.g., new report,
transaction, policy, or event) is needed to sustain the value of the current
system.
Analysis and Design
IV. Beyond Systems
Analysis and Design
Companies, 2007
Support
BUSINESS
COMMUNITY
business
problem
New Business Problem
New Business
Requirement
business
requirement
New Technology
Requirement
8.4.1
Approved
Change
Request
Analyze
Enhancement
Request
Quick Fix
Requirement
System
Knowledge
(including
change
management)
technology
requirement
8.4.2
Make
the
Quick
Fix
Updated
System
Knowledge
Enterprise
Repository
Simple, New
Program
design
requirement
Test
Data
Program
Library
Mini
Problem
Analysis
GO TO
Mini
Requirements
Analysis
GO TO
Mini
Decision
Analysis
GO TO
Mini
System
Design
Business
Database
Exisiting and/or Restructured
Programs
8.4.3
Updated
System
Knowledge
Recover
Existing
Physical
System
711
GO TO
New Design Requirement
Chapter Twenty
Updated and/or
Restructured
Database
• New technology requirements—A decision to consider or use a new technology (e.g., new software or version, or different type of hardware) in an existing system needs to be made.
• New design requirements—An element of the existing system needs to be
redesigned against the same business requirements (e.g., add new database
tables or fields, add or change to a new user interface).
Systems enhancement is reactive in nature—fix it when it breaks or when users or
managers request change. System enhancement extends the useful life of an existing
system by adapting it to inevitable change. This objective can be linked to your information system building blocks as follows:
• KNOWLEDGE/DATA—Many system enhancements are requests for new information (reports or screens) that can be derived from existing stored data. But
some data enhancements call for the restructuring of stored data.
• PROCESSES—Most system enhancements require the modification of existing
programs or the creation of new programs to extend the overall application
system. But some enhancement requests can be accomplished through careful redesign of existing business processes.
• COMMUNICATION—Many enhancements require modifications to how the users
interface with the system and how the system interfaces with other systems.
Figure 20-5 expands on the activities of system enhancement. In this section, we
briefly describe each activity, participants and roles, inputs and outputs, and techniques.
FIGURE 20-5
System
Enhancement Tasks
Analysis and Design
712
Part Four
IV. Beyond Systems
Analysis and Design
Support
Companies, 2007
> Task 8.4.1—Analyze Enhancement Request
This activity determines the appropriate course of action for achieving a system enhancement requirement. The initial task is to analyze the request against all other outstanding change requests to determine priority. The system knowledge in the
repository is invaluable here, especially if it is current. At a minimum, the importance
of the requirement must be assessed against the time and cost of a solution.
Requests for change almost always outnumber resources needed to facilitate
change. Change management systems formally capture all change requests in the
repository so that change can be prioritized. Changes may be batched so that they can
be implemented at optimal times.
If immediate change is needed, the approved change request(s) must be directed
to solutions according to the type(s) of change required:
• New business problems must be directed to a downsized version of the
problem analysis phase. From there, the enhancement will be directed
through appropriately downsized versions of requirements analysis, decision
analysis, design, construction, and implementation.
• New business requirements must be directed to downsized requirements
analysis, decision analysis, design, construction, and implementation.
• New technical requirements must usually be directed to a decision analysis
before design, construction, and implementation. The decision analysis determines if the proposed technology will be feasible in the new system. This is
exceedingly important because radical technical change may be costly and
complex.
• New design requirements must obviously be directed to design, construction,
and implementation.
To prioritize and plan enhancement projects, the systems analyst should be skilled in
project management (Chapter 4) and feasibility techniques (Chapter 11).
> Task 8.4.2—Make the Quick Fix
Some system enhancements can be accomplished quickly by writing new simple programs or making very simple changes to existing programs. Simple programs and
changes are those that can be made without restructuring stored data (changing the
database structure), without updating stored data, and without inputting new data
(for purposes of storing that data). In other words, these programs generate new
(or revise existing) reports and outputs. New program requirements represent many
of today’s enhancement requests.
NOTE: It is our belief that any new program requirements that exceed our definition of simple should be treated as new business requirements and subjected
to systems analysis and design to more fully consider implications within the
complete application system’s structure.
Most such programs can be easily written with 4GLs or report-writing tools such
as SAS, Brio, or Crystal Reports. With these tools, programs can be completed within
hours. Since they generally do not enter or update data stores, testing requirements
are not nearly as stringent.
The quick fix might also be as simple as changing business processes so that they
can work with existing information system processes. For example, the analyst may
suggest ways in which existing reports can be manually adapted to support different
needs.
In Figure 20-5, we see that quick fix requirements are identified and studied. The
analysts or programmers use existing business data as test data to write simple, new
programs that may or may not be added to the program library. Of course, updated
system knowledge should be added to the repository.
Analysis and Design
IV. Beyond Systems
Analysis and Design
Support
Companies, 2007
Chapter Twenty
713
> Task 8.4.3—Recover Existing Physical System
Sometimes the repository does contain up-to-date or accurate system knowledge. But
documentation is frequently out of date. And in some cases, systems were developed
without rigorous development processes or enforced documentation standards. In
still other cases, systems were purchased; purchased systems are notorious for poor
and inadequate documentation. In all of these instances, the analyst may be asked to
recover the existing physical structure of a system as a preface to subsequent system
enhancement. In some cases, reengineering technology exists to physically restructure and improve system components without altering their functionality. Let’s briefly
examine some recovery and restructuring possibilities.
Database Recovery and Restructuring Sometimes systems analysts help in the
reengineering of files and databases. Many of today’s data stores are still implemented
with traditional file structures (such as VSAM) or early database structures (such as hierarchical IMS structures). Today’s database technology of choice is SQL-based relational databases. Tomorrow, object database technology may present yet another
paradigm shift. A more common requirement is the changing of versions in an
existing database structure (such as Oracle 9i to Oracle 10g).
A migrating of data structures from one data storage technology or version to another is a major endeavor, filled with opportunities to corrupt essential, existing business data and programs. Thus, reengineering file and database structures has become
an important task.
Database reengineering is usually covered more extensively in data and database
management courses and textbooks; however, a brief explanation is in order here.The
key player in database restructuring is the database administrator. The systems analyst
plays a role because of the potential impact on existing applications. Network analysts
may also be involved if databases are (to be) distributed across computer networks.
All databases store metadata about their structure. This metadata can be read and
transformed into a physical data model. This data model can be stored in the repository (as system knowledge) to assist analysts in the redesign or use of the database.
In some cases, an updated and/or restructured database can be generated, but great
care must be taken because many programs use the existing database structure. While
database technology theoretically separates data structure from program structure,
significant restructuring of databases can still cripple programs.
If the database requires such restructuring, it might be better to identify the
change in the repository as another new design requirement that should be directed
through an appropriate system redevelopment to determine and react to the impact
the new structure may have on existing programs.
Program Analysis, Recovery, and Restructuring Many businesses are questioning the return on investment in corrective and adaptive maintenance of software. If
complex and high-cost software can be identified, it might be reengineered to reduce
complexity and maintenance costs. One possibility is to analyze program library and
maintenance costs. This task almost always requires software capable of performing
the analysis.
Software tools such as ASG’s ASG-Recap measure your software library using a variety of widely accepted software metrics. Software metrics are mathematically
proven measurements of software quality and productivity. Examples of software
metrics applicable to maintenance include:
• Control flow knots—the number of times logic paths cross one another.
Ideally, a program should have zero control flow knots. (We have seen knot
counts in the thousands on some older, poorly structured programs.)
• Cycle complexity—the number of unique paths through a program. Ideally,
the fewer, the better.
software metrics mathematically proven measurements of software quality and
developer productivity.
Analysis and Design
714
Part Four
IV. Beyond Systems
Analysis and Design
Support
Companies, 2007
Software metrics, in combination with cost accounting (on maintenance efforts), can
help identify the programs that would benefit from restructuring.
The input to program analysis is existing programs in the program library. The
software may generate restructured programs or merely add system knowledge
about the programs to be used later for either restructuring or enhancement. Program analysis was a critical first step in solving the year 2000 software problem.
Businesses had to analyze programs to determine where dates were used and what
impact changes might have as the programs were enhanced to accommodate the
millennium rollover.
Program recovery is similar to program analysis. Existing program code is read
from the library. It is then transformed into some sort of physical model appropriate
to the software. For example, many CASE tools can reverse engineer a COBOL
program into a structure chart for that program or reverse engineer a Visual Basic
program into an object model. These models are added to the repository as new
system knowledge to assist with enhancement of the system.
Be very careful not to misuse recovery technology. With purchased software applications, the software license usually prohibits reverse engineering. At best, reverse
engineering of purchased software may be unethical. In the worst case, reverse engineering of such software may be illegal and a violation of copyright law and trade
secrets.
Finally, some reengineering tools actually support the restructuring of programs.
There are three distinct types of program restructuring:
• Code reorganization restructures the modular organization and/or logic of
the program. Logic may be restructured to eliminate control flow knots and
reduce cycle complexity.
• Code conversion translates the code from one language to another. Typically,
this translation is from one language version to another. There is a debate on
the usefulness of translators between different languages. If the languages are
sufficiently different, the translation may be very difficult. If the translation is
easy, the question is, “Why change?”
• Code slicing is the most intriguing program-reengineering option. Many programs contain components that could be factored out as subprograms. If
factored out, they would be easier to maintain. More importantly, if factored
out, they would be reusable. Code slicing cuts out a piece of a program to
create a separate program or subprogram. This may sound easy, but it is not!
Consider your average COBOL program. The code you want to slice out may
be located in many paragraphs and have dependent logic in many other paragraphs. Furthermore, you would have to simultaneously slice out a subset of
the data division for the new program or subprogram.
The candidate program for restructuring is copied from the program library. It is
reengineered using one or more of the preceding methods, it is thoroughly tested (as
described earlier in the chapter), and the reengineered program is returned to the
program library where it is available for production. Any new data, process, and/or
network models are updated in the repository.
System Obsolescence
At some point, it will not be cost-effective to support and maintain an information system. All systems degrade over time. And when support and maintenance become costineffective, a new systems development project must be started to replace the system.
At this time we come full circle to Chapters 3–19 of this book.
Analysis and Design
IV. Beyond Systems
Analysis and Design
Companies, 2007
Support
Learning Roadmap
This chapter provided a detailed overview of the systems support phase of systems
development.You learned about the different types of systems support: maintenance,
enhancement, reengineering, and design recovery.
If you have been covering the chapters in order, you are now prepared to do systems development. Otherwise, you may wish to return to previous chapters to learn
more about the tools and techniques used in systems development. Completion of
this book does not guarantee your future success in systems development. Systems
development approaches, tools, and techniques continue to evolve. Thus, your learning will be an ongoing process.
Chapter Review
1. Systems support is the ongoing maintenance of
a system after it has been placed into operation.
This includes program maintenance and system
improvements.
2. Systems support involves solving different types of
problems. There are several types of systems support: system maintenance, system recovery, end-user
assistance, system enhancement, and reengineering.
3. Regardless of how well designed, constructed, and
tested a system or application may be, errors or
bugs will occur. The corrective action that must be
taken is called system maintenance.
4. From time to time a system failure is inevitable. It
generally results in an aborted, or “hung,” program
(also called an ABEND or crash) and possible loss
of data. The systems analyst often fixes the system
or acts as intermediary between the users and
those who can fix the system; this is referred to as
system recovery.
5. Another relatively routine ongoing activity of
systems support is end-user assistance. No matter
how well users have been trained or how well
documentation has been written, users will require
additional assistance. The systems analyst is generally on call to assist users with the day-to-day
use of specific applications. In mission-critical
applications, the analyst must be on call day
and night.
6. Most adaptive maintenance is in response to new
business problems, new information requirements,
or new ideas for enhancement. It is reactive in
nature—fix it when it breaks or when users make
a request. We call this system enhancement. The
objective of system enhancement is to modify or
expand the application system in response to
constantly changing requirements. Another type of
reactive maintenance deals with changing technology. Information system staffs have become increasingly reluctant to wait until systems break.
Instead, they choose to analyze their program libraries to determine which applications and programs are costing the most to maintain or which
ones are the most difficult to maintain. These systems might be adapted to reduce the costs of
maintenance. The preceding examples of adaptive
maintenance are classified as reengineering.
1
2
1. What is system support?
2. What are the three areas of systems development
knowledge suggested in the textbook that are important to system support?
Review Questions
3. What are the four major support activities suggested in the textbook?
4. Why is system maintenance necessary?
5. What are the tasks needed for system maintenance?
715
Analysis and Design
716
Part Four
IV. Beyond Systems
Analysis and Design
Support
Companies, 2007
6. What does the term unsubstantiated bug mean?
What should analysts do when an unsubstantiated
bug is found?
7. What should analysts do when they have validated that there are bugs in the program?
8. How are test scripts used in the benchmarking of
the program?
9. Why is relying on system knowledge important in
debugging of the program?
10. Why is the cost of system maintenance high?
11. What are some of the tasks suggested in technical
support?
12. Why will system enhancement occur?
13. What are the tasks needed to conduct system
enhancement?
14. Why is it necessary to recover the existing physical system in system enhancement?
15. What are the reengineering tools suggested in the
textbook?
Problems and Exercises
1. Your company has grown rapidly in the past several years, and its organizational structure has
lagged behind. The CIO has asked you to reorganize the systems operation and support section of
the IT shop. As you are reorganizing it, what are
the four major support activities you need to be
aware of, and what is a critical requirement for
each of these activities regarding the staff who
will be performing them?
2. What are control flow knots, and why should
they be avoided?
3. Answer true or false to the following
statements:
a. Microsoft’s SourceSafe is an example of a
software-based librarian.
b. In a typical IT shop, analysts spend at most
about 20 percent of their time on systems
operation and support.
c. A simple program change is one that does not
require a change to the database schema or to
the data itself.
d. IT shops no longer need technical IT staff
who have expertise in VSAM or IMS because
these file and database structures are almost
never found in organizations anymore.
e. The repository is where archival data generated by the application program is stored.
4. All systems eventually grow old and become
obsolete. What is the rule of thumb as to when a
system should be replaced?
5. Match the terms in the first column with the definitions or examples in the second column:
1. Version control
2. Program library
A. Code translation to
higher version or different language
B. Software quality and
developer productivity
measurements
3. Control flow
knots
C. Baseline against which
modified program can
be measured
4. Cycle complexity D. Application source
code data store
5. Roll forward
E. Unique path count in a
program
6. Code slicing
F. Intersecting logic path
count
7. Code
G. Program change
reorganization
tracking, usually
software based
8. Code conversion H. Transaction reprocessing as part of recovery
process
9. VIA/Recap
I. Transaction removal as
part of recovery
process
10. Benchmark the
J. Repository for test
program
data and test
instructions
11. Roll back
K. Code removal to
create new program or
subprogram
12. Test script
L. Software metric tool
13. Software metrics M. Restructuring of
program’s logic or
modular organization
6. One of the common support activities occurs
when a software manufacturer, such as Oracle or
Microsoft, releases an updated version of one of
their software packages. Often the effort to upgrade is significant, while the changes to the software appear minor. This raises the question, why
upgrade? Please discuss.
7. Fill in the blanks.
a. There is usually __________ staff to handle all
the __________ requests that are submitted;
therefore, they must be __________.
Analysis and Design
IV. Beyond Systems
Analysis and Design
Companies, 2007
Support
b. If a program contains excessive cycle
__________ or an excessive number of
__________, a program __________ technique
called code __________ can be used.
c. To __________ programs would benefit from
__________, reengineering, or __________,
software __________ can be used together
with __________ techniques.
d. The __________ is responsible for __________
data __________ and maintained by the
production application programs.
8. “Quick fixes” can be a very effective way to make
simple changes to a system with a minimum
amount of time and cost. On the other hand,
what is the danger or downside of quick fixes?
9. Explain the concept of adaptive maintenance.
10. Congratulations—you’ve reached the final chapter in the textbook. Now it is time to reflect on
the chapters that you read. Part One covered the
context of a systems development project. Reread
the introduction at the beginning of Part One regarding the objectives for that part; then for each
chapter in Part One, list at least one thing that
stuck with you. For example, did Chapter 1 help
you to focus on the big picture, and was the
Chapter Twenty
717
concept of information system building blocks,
presented in Chapter 2, something that helped
you throughout the textbook and that could be a
useful tool in your professional career?
11. In Part Two, you covered a wide range of systems
analysis methods in seven chapters. Again, reread
the introduction at the beginning of Part Two;
then list what resonated the most for you in each
chapter on systems analysis methods.
12. Please do the same for Part Three as in the preceding two parts.
13. Part Four of the textbook takes you into the final
phase of the project, then into ongoing operations
and support. Follow the same process as for the
preceding parts, but in addition, please take a moment and think about the entire textbook. Where
do you feel it is of the greatest value to you in
your studies and professional career, and where
do you think it can be strengthened? Also, for how
long do you think books on systems analysis and
systems design principles and methods can be
used before they need to be updated or become
obsolete? What are the implications of this for
your career as a systems analyst or designer?
Projects and Research
1. Requests from users for system enhancements or
changes are one of the more challenging aspects of
systems support, as described in the textbook. Research this issue on the Web, and discuss it with
several IT support staff in local organizations. Find
out how their organization approaches it. Then:
a. Write a set of procedures or instructions for
your organization to use regarding submitting
system enhancement change requests. The procedures should include criteria for determining
whether a simple, or “quick fix,” program
change is appropriate, and the guidelines and
processes to be followed when the enhancement doesn’t fall under the “quick fix” category.
Note: The procedures should be written for the
nontechnical business user and should include
a sample change request form.
b. “Pilot” the instructions and form with your
fellow students and/or co-workers. Have them
evaluate and critique the instructions and form.
c. Use their feedback to refine your instructions
and form. Report the process until there are no
further suggestions for improvement.
d. How many iterations did you go through?
2. At the time that most projects are initiated, an estimate is made of the expected life span of the new
system as a part of a cost-benefit evaluation. However, on an anecdotal basis, it appears that most systems remain in production far longer than their
original planned life span. Research this topic on the
Web and/or in your school library. In addition, conduct an informal survey of system administrators in
several local public and private sector agencies.
a. Describe the articles that you found and their
viewpoints on this subject.
b. Describe the informal survey you conducted,
including the nature of organizations that were
included in the survey and the types of systems
they use.
c. What was the average difference you found, if
any, between expected life span and actual life
span of systems?
d. To what do you attribute the tendency to keep
systems in production beyond their expected
life span?
e. What was the oldest system you found still in
production? (It is not uncommon to find systems dating back to the 1970s, depending upon
Analysis and Design
718
Part Four
IV. Beyond Systems
Analysis and Design
Support
Companies, 2007
the nature of the organization. Finding a system
originally implemented in the 1960s would be
rare, although some are known to still exist!)
3. The objective of software metrics is to provide a
mathematically valid method for measuring software quality and productivity. Research articles on
the Web and/or in your school library regarding
software metrics, as well as the Web sites of some
manufacturers of software metrics tools. If they
offer any free trial copies, download them and try
them out. In addition, ask the IT staff in several
local organizations if they use software metrics
tools, and, if so, which one and what their opinion
is of it.
a. Describe the research that you conducted.
b. What are some of the different schools of
thought and/or controversies regarding the use
of software metrics tools?
c. What were the responses from IT staff? Do they
use software metric tools? If they do, what are
the ones they use and/or prefer? What are the
different uses for which the tools are employed? If the IT staff doesn’t use software metrics tools, what are the reasons why not?
d. On the basis of your research and perhaps
hands-on experience, compare and contrast the
different software metrics tools that are available. Which one(s) did you prefer and why?
e. Overall, do you consider the benefits of software metrics tools to be sufficient to justify
their cost of purchase and their learning curve?
4. Systems operations and support generally consume an enormous amount of the resources available in the typical IT shop of an organization.
Many CIOs are avidly interested in systems support
software that may reduce the amount of human effort required. Research the Web and trade journals
for information on some of the newly emerging
applications, not discussed in the textbook, that
are or soon will be available.
a. Describe the research you conducted.
b. What are some of the new types of systems
support applications that you found?
c. Compare and contrast their features.
d. If you were the systems support manager in
your organization and you could choose only
one of these applications, which one would you
choose? Or would you choose any? Explain
your answer.
5. Technical support to users is one of the cornerstones of systems support which can consume a
tremendous amount of time and staff resources.
Research this topic in trade journals and in forums
on the Web. Interview support staff in the IT
shops of several local organizations regarding the
issues they face in providing support. In addition,
interview some users in the same organizations regarding their perspective on technical support.
a. Describe the research you conducted.
b. What was the range of responses you received
regarding technical support?
c. Did the IT staff in the different organizations
have the same issues in common?
d. What about the IT staff and the users—what
perspectives did they have in common, and
where did they differ?
e. Using your research, write a one-page bulleted
list of guidelines for providing technical support.
6. Have computers become sophisticated enough to
be powerful extensions of how humans think and
communicate? Or do computers and humans capture and process data and transform it into information in fundamentally different ways? Explain
your answer.
Minicases
1. Create a final exam for this class. Post an electronic copy to the class Web site, as well as a hard
copy to your professor. Include solutions to the
questions, per your professor’s direction.
2. Compile the work you have done throughout this
class for the department of the government that
you chose. Create two deliverables: one for your
contact at the department, and one for your professor. The deliverable to your professor will include ALL of the work you have done: interviews,
research, diagrams, testing and design reports and
counter reports, business discussion, manual, and
final prototype on CD. The deliverable for your
contact in the government will include: diagrams,
business discussion, manual, and final prototype
on CD. Remember, the manual will be bound separately for both deliverables.
3. Create a portfolio of the work you have done in
this class. Include major deliverables that showcase your capabilities as a systems analyst and
designer, any letters of team recognition for good
teamwork from your group, a description of the
Analysis and Design
IV. Beyond Systems
Analysis and Design
Companies, 2007
Support
topics you covered in class, and the like. Make
sure that this portfolio has a professional appearance and is bound. This is for you to keep as you
job-search.
4. Follow up with the contact at the government
department. Did they have any questions? Any
Chapter Twenty
719
comments on your work? Does the prototype do
everything they wanted and needed? Does it work
on their network correctly and without problems?
Was the manual clear and easy to follow? Consider
this your final system acceptance.
Team and Individual Exercises
1. Individual: If you are graduating, write a “thank
you” letter to the professor, teacher, secretary, librarian, or whoever has helped you, influenced
you, or otherwise had the largest positive impact
on you in your college career.
2. Individual: Whether you are job-hunting or not,
make a list of people and ask them if they would
be willing to act as a reference when you jobhunt. Remember, you will want to have workrelated references, school-related references, and
character references!
3. Individual: Blank exercise. You make it up, you
do it. Have fun, be creative, and look outside the
norm.
Suggested Readings
Arnold, Robert. Software Reengineering. Los Alamitos, CA:
IEEE Computer Society Press, 1993. This is a reference
book and research compilation on the subject of business
process, database, and software reengineering.
Hammer, M., and J. Champy. Reengineering the Corporation.
New York: Harper Business, 1993. Mike Hammer is widely
regarded as the father of business process reengineering.
Martin, E. W.; D. W. DeHayes; J. A. Hoffer; and W. C. Perkins.
Managing Information Technology: What Managers
Need to Know. New York: Macmillan, 1994.

Whitten−Bentley: Systems Analysis and Design Methods, Seventh

Transcription

Similar documents

Cavalia inc. 5100, rue Hutchison, suite 300 Montréal (Québec) H2V

Technologies Inc.. Our company is focused in providing HR services

On this date in history: Aug. 13 MEET THE TEAM

Red Bee Media Limited

Portfolio and Research Management Team FRANKLIN TEMPLETON

April 20, 1995 - The Repository

Ch. 5: Trawling for Reqs.

Accounting Placement 2016

Document 6576461

PPT - Service Leadership Education