Implementing and Maintaining the System - PowerPoint PPT Presentation

1 / 47
About This Presentation
Title:

Implementing and Maintaining the System

Description:

... From a Formal Code Inspection Checklist for C . CCSB223/SAD/CHAPTER14 ... Integration ... Figure 14-8. Sample Content for a Software Change Request. CCSB223/SAD ... – PowerPoint PPT presentation

Number of Views:22
Avg rating:3.0/5.0
Slides: 48
Provided by: McGrawHill267
Category:

less

Transcript and Presenter's Notes

Title: Implementing and Maintaining the System


1
Chapter 14
  • Implementing and Maintaining the System

2
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

3
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

4
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

5
System Implementation
  • Application testing and user acceptance
  • User training and final documentation
  • System installation and conversion

6
Application Testing
  • Testing categories
  • Code inspection
  • Structured walk-through
  • Desk check
  • Module testing

7
Table 14-1. Classification of Software Tests
8
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

9
Figure 14-1. Excerpt From a Formal Code
Inspection Checklist for C
10
Structured Walkthrough
  • To test whether the code actually performs the
    functions intended by the designer
  • Close examination of the embedded logic in the
    code

11
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

12
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

13
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

14
Figure 14-2. Stub Testing Using a Top-Down
Approach
15
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

16
Integration Testing
  • Integration strategies
  • All at once (big-bang)
  • Top-down
  • Bottom-up
  • Critical piece first

17
Figure 14-3. Combined Module and Integration
Testing Strategy
18
System Testing
  • Focus on the behavior of the entire system
  • The goal is to have no errors or anomalies
    remaining
  • Build-and-smoke test

19
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 developers site
  • Beta Test (validation test)
  • Conducted by the end users at their own site

20
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

21
Table 14-2. The 16 Commandments of User
Acceptance Testing
22
Installing the System
  • Tasks
  • System conversion
  • Final documentation
  • End user training

23
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

24
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

25
System Conversion
  • Pilot Conversion
  • Allows for the conversion to the new system,
    using either direct or parallel method, at a
    single location

26
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

27
Figure 14-4. Comparison of System Conversion
Strategies
28
Table 14-3. General Documentation Deliverable
Guidelines for SDLC
29
Figure 14-5. Example of an On-line Help System
30
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)

31
User Documentation
  • Topics and functions
  • Procedure
  • General reference
  • Tutorial

32
Figure 14-6. Example of a Context-Sensitive Help
System
33
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

34
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

35
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

36
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

37
Figure 14-7. Relative Distribution of Costs
Across SDLC Activities
38
System Maintenance
  • Change requests
  • Identifying and implementing changes to the
    system that add or enhance functionality
  • Change control steering committee

39
Figure 14-8. Sample Content for a Software
Change Request
40
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

41
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 systems useful life

42
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

43
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

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

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

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

47
Chapter 14
  • End of Chapter
Write a Comment
User Comments (0)
About PowerShow.com