Title: Implementing and Maintaining the System
1Chapter 14
- Implementing and Maintaining the System
2Learning Objectives
- Understand the activities associated with the
system implementation phase of the SDLC - Understand the range of appropriate test
procedures for a given application - Identify and select the most suitable conversion
strategy for a new application
3Learning Objectives
- Understand the various types of user and system
documentation - Understand the activities and constraints
associated with the systems maintenance phase of
the SDLC
4What is System Implementation?
- Activities that ensure the new system is fully
functional and operational - Activities that turn over control of the new
system to the end users
5System Implementation
- Application testing and user acceptance
- User training and final documentation
- System installation and conversion
6Application Testing
- Testing categories
- Code inspection
- Structured walk-through
- Desk check
- Module testing
7Table 14-1. Classification of Software Tests
8Code Inspection
- Inspect the actual code for the occurrence of
certain types of programming errors - Focus on errors that may not be syntactically or
grammatically incorrect but may cause the logic
of the code to fail
9Figure 14-1. Excerpt From a Formal Code
Inspection Checklist for C
10Structured Walkthrough
- To test whether the code actually performs the
functions intended by the designer - Close examination of the embedded logic in the
code
11Desk Check
- Focuses on the actual execution of the code
- One or more programmers who are not responsible
for the actual writing of the codes work through
a hard copy of source code
12Module Testing
- Also referred to as Unit Test
- Focuses on ascertaining the successful execution
of each application module prior to integrating
it with other tested modules - One of the primary black-box testing methods
- Test Driver is written to facilitate the test
13Stub Testing
- Top-down testing scenario
- The highest-level control module is tested first
- The lower-level modules are simulated by a
program stub designed to simply accept control
from a high-level module and return it back to
that module
14Figure 14-2. Stub Testing Using a Top-Down
Approach
15Integration Testing
- Focus on testing the behavior of an entire group
of modules to identify errors that either were
not, or could not be detected at the unit level
16Integration Testing
- Integration strategies
- All at once (big-bang)
- Top-down
- Bottom-up
- Critical piece first
17Figure 14-3. Combined Module and Integration
Testing Strategy
18System Testing
- Focus on the behavior of the entire system
- The goal is to have no errors or anomalies
remaining - Build-and-smoke test
19User Acceptance Test
- User verifies that the delivered and installed
product is ready to be put into production use - Alpha Test (verification test)
- Done by the client at the developers site
- Beta Test (validation test)
- Conducted by the end users at their own site
20User Acceptance Test
- Script
- Designed to verify that the major functions are
properly operating in their most common mode - A testing script is hierarchically organized by
subsystem and function
21Table 14-2. The 16 Commandments of User
Acceptance Testing
22Installing the System
- Tasks
- System conversion
- Final documentation
- End user training
23System Conversion
- Direct conversion
- The old system is simply turned off, and the new
system is turned on in its place - Should be considered only in extreme
circumstances where no other conversion strategy
is viable - Also referred to as slam dunk or cold-turkey
strategy
24System Conversion
- Parallel Conversion
- The old and new systems are run simultaneously
until the end users are fully satisfied that the
new system is functioning correctly and the old
system is no longer necessary
25System Conversion
- Pilot Conversion
- Allows for the conversion to the new system,
using either direct or parallel method, at a
single location
26System Conversion
- Phased Conversion
- Allows for the new system to be brought on-line
as a series of functional components that are
logically ordered so as to minimize disruption to
the end users and the flow of business
27Figure 14-4. Comparison of System Conversion
Strategies
28Table 14-3. General Documentation Deliverable
Guidelines for SDLC
29Figure 14-5. Example of an On-line Help System
30User Documentation
- To provide the end users with a detailed and
highly organized description of how to interact
with the system - On-line documentation (context-sensitive help)
31User Documentation
- Topics and functions
- Procedure
- General reference
- Tutorial
32Figure 14-6. Example of a Context-Sensitive Help
System
33System Documentation
- Describe the design specification, the internals
of the system, the as-built program code, and the
functionality of all modules - To assist and support personnel responsible for
maintaining the final system
34User Training and Support
- User training design and content
- One-size-fits-all training program is not a
desirable structure for training - Users need to be trained on how to use the system
to perform their respective jobs
35User Training and Support
- User training methods and delivery
- Traditional classroom
- One-on-one training
- Self-paced or computer-based training
- Training schedule must be closely linked to the
conversion strategy
36Post-Implementation Activities
- To correct errors or faults in the system
- Provide changes to affect performance improvement
- Adapt the system to changes in the operating
environment
37Figure 14-7. Relative Distribution of Costs
Across SDLC Activities
38System Maintenance
- Change requests
- Identifying and implementing changes to the
system that add or enhance functionality - Change control steering committee
39Figure 14-8. Sample Content for a Software
Change Request
40System Maintenance
- Corrective Maintenance
- Fix bugs and logical errors not detected during
the implementation testing period - Adaptive Maintenance
- Modifying existing functions or adding new
functionality to accommodate changes in the
operating environment
41System Maintenance
- Perfective Maintenance
- Changes made to an existing system to improve the
performance of a function or interface - Preventive Maintenance
- Activities intended to reduce the chances of a
system failure or extend the capacity of a
current systems useful life
42System Maintenance
- Preventive maintenance activities
- Hardware maintenance to keep electromechanical
equipment operating correctly - Replacement of hardware components to keep the
equipment up to current specifications - Updating of system software
- Testing and analysis of system reports
- Maintenance of system documentation
43System Maintenance
- System Maintenance Costs
- There is a direct link between the cost of
absolute availability and the cost of downtime - Maintenance can account for a significant portion
of the total IS budget
44System Maintenance
- Cost Estimation of Downtime
- Productivity loss
- Downtime that has a negative impact on individual
or workgroup productivity - Productivity Loss ( of Affected Users) x
(Percentage Effect on Productivity / 100) x
(Average Burdened Salary per Hour) x (Hours of
Downtime)
45System Maintenance
- Cost Estimation of Downtime
- Business loss
- Downtime that affects transactions or result in
customer losses - Business Loss
- ( of Affected Users) x (Percentage Effect on
Productivity / 100) x (Average Profit per
Employee Hour) x (Hours of Downtime) - Or
- ( of Transactions per Hour) x (Percentage of
Affected Transactions / 100) x (Average Profit
per Transaction) x (Hours of Downtime) - - End -
46Chapter Summary
- When you first experience the world of SAD, the
details of the methodology in place may differ
from what you learned from this text. - The underlying concepts, principles, and
objectives will most certainly be consistent with
what you have learned, and you will be able to
adapt easily to the new environment.
47Chapter 14