ccsb223/sad/chapter141 chapter 14 implementing and maintaining the system

CCSB223/SAD/CHAPTER14 1

Chapter 14

Implementing and

Maintaining the System


Learning 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


Learning Objectives Understand the various types of

user and system documentation Understand the activities and

constraints associated with the systems maintenance phase of the SDLC


What 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


System Implementation Application testing and user

acceptance User training and final

documentation System installation and conversion


Application Testing Testing categories

Code inspection Structured walk-through Desk check Module testing


Manual Test Automated Test

Static

Inspection

Syntax Check

Dynamic

Walk-through Desk Check

Unit Test

Integration Test System Test

Table 14-1. Classification of Software Tests


Code 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


C++ Inspection Checklist 1 VARIABLE DECLARATIONS 1.1 Arrays 1.1.1 Is an array dimensioned to a hard-coded constant?

int intarray[13]; should be

int intarray[TOT_MONTHS+1]; 1.1.2 Is the array dimensioned to the total number of items?

char entry[TOTAL_ENTRIES]; should be

char entry[LAST_ENTRY+1]; The first example is extremely error-prone and often gives rise to off-by-one errors in the code. The preferred (second) method permits the writer to use the LAST_ENTRY identifier to refer to the last item in the array. Instances which require a buffer of a certain size are rarely rendered invalid by this practice, which results in the buffer being one element bigger than absolutely necessary. 1.2 Constants 1.2.1 Does the value of the variable never change?

int months_in_year = 12; should be

const unsigned months_in_year = 12; 1.2.2 Are constants declared with the preprocessor #define mechanism?

#define MAX_FILES 20 should be

const unsigned MAX_FILES = 20;

Figure 14-1. Excerpt From a Formal Code Inspection Checklist for C++


Structured Walkthrough To test whether the code actually

performs the functions intended by the designer

Close examination of the embedded logic in the code


Desk 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


Module 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


Stub 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


Figure 14-2. Stub Testing Using a Top-Down Approach


Integration 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


Integration Testing Integration strategies

All at once (big-bang) Top-down Bottom-up Critical piece first


Figure 14-3. Combined Module and Integration Testing Strategy


System Testing Focus on the behavior of the entire

system The goal is to have no errors or

anomalies remaining Build-and-smoke test


User 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 developer’s

site Beta Test (validation test)

Conducted by the end users at their own site


User 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


Table 14-2. The 16 Commandments of User Acceptance Testing


Installing the System Tasks:

System conversion Final documentation End user training


System 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


System 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


System Conversion Pilot Conversion

Allows for the conversion to the new system, using either direct or parallel method, at a single location


System 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


Figure 14-4. Comparison of System Conversion Strategies


Table 14-3. General Documentation Deliverable Guidelines for SDLC


Figure 14-5. Example of an On-line Help System


User 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)


User Documentation Topics and functions

Procedure General reference Tutorial


Figure 14-6. Example of a Context-Sensitive Help System


System 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


User 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


User 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


Post-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


Figure 14-7. Relative Distribution of Costs Across SDLC Activities

Maintenance61%

Programming26%

Analysis/Design

6%

Implementation7%


System Maintenance Change requests

Identifying and implementing changes to the system that add or enhance functionality

Change control steering committee


1.0 SCI Identification This section identifies the software change initiative (SCI) for which a change has been requested. 1.1 Name, identification and description of SCI(s) The name, version/control numbers of the SCI is specified, including page numbers if a document is involved. A brief description is provided. 1.2 Requester The name of the person requesting the change 1.3 Contact information How to contact the requester. 1.4 Date, location, and time When and where the change was requested 2.0 Description of the change This section presents a brief description of the requested change 2.1 Description This section presents a detailed description of the circumstances that precipitated the change request and the request desired. 2.2.1 Underlying circumstances Background information regarding the request. 2.2.2 Examples Supporting information, e.g., printouts containing an error in a report or an incorrect screen image 2.2.3 The change A detailed discussion of the change requested.

Figure 14-8. Sample Content for a Software Change Request


System 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


System 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 system’s useful life


System 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


System 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


System 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)


System 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 -


Chapter 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.


Chapter 14

End of Chapter

ccsb223/sad/chapter141 chapter 14 implementing and maintaining the system

Documents

system slide

module slide

conversion slide

sdlc slide

c slide

approach slide

new application slide

smoke test slide