ch 12 - system implementation and maintenance

system implementation

• convert final physical system specifications into working and reliable software

coding deliverables

• code

• program documentation

testing deliverables

• test scenarios (test plan) and test data

• results of program and system testing

installation deliverables

• user guides

• user training plan

• installation and conversion plan

two audiences for final documentation:

• information systems personnel who will maintain the system throughout its productive life

• people who will use the system as part of their daily lives

user training

• application-specific

• general for operating system and off-the-shelf software

documentation

• system documentation

• user documentation

user training plan

• classes

• tutorials 

user training modules

• training materials

• computer-based training aids

user support plan

• help desk

• online help

• bulletin boards and other support mechanisms

table of contents of a master test plan

• introduction

• overall plan 

• testing requirements 

• procedure control 

• test-specific or component-specific test plans

introduction

• description of system to be tested 

• objectives of the test plan 

• method of testing 

• supporting documents

overall plan

• milestones, schedules, and locations

• test materials (test plans/cases/scenarios/log)

testing requirements

• hardware

• software

• personnel

procedure control

• test initiation

• test execution

• test failure

• access/change control

• document control

test-specific or component-specific test plans

• objectives

• software description

• method

• milestones, schedule, progression, and locations

• requirements

• criteria for passing tests 

• resulting test materials

• execution control

• attachments

software application testing 

• umbrella term that covers several types of tests

static testing

• the code being tested is not executed

• manual inspections

• automated checking

dynamic testing

• execution of the code

• manual walk-though and desk checking

• automated unit/integreation/system test

automated

• computer conducts the test

manual

•  people complete the test

seven types of testing

• inspections

• walk-throughs (code walk-throughs)

• desk checking

• unit testing

• integration testing

• system testing

• stub testing

inspections

• testing technique in which participants examine program code for predictable language-specific errors

walk-throughs (code walk-throughs)

• should be done frequently when pieces of work are reviewed and before formal testing

• an informal process

desk checking

• testing technique in which the program code is sequentially executed manually by the reviewer

unit testing

• process of testing each module alone in an attempt to discover any errors in its code

integration testing

• process of bringing together all of the modules that a program comprises for testing purposes

• modules are typically integrated in a top-down, incremental fashion

system testing

• bringing together of all of the programs that a system comprises for testing purposes

• programs are typically integrated in a top-down, incremental fashion

stub testing 

• technique used in testing modules, especially where modules are written and tested in a top-down fashion, where a few lines of code are used to substitute for subordinate modules

guidelines for conducting a code walk though

• have the review meeting chaired by the project manager or chief programmer, who is also responsible for scheduling the meeting, reserving a room, setting the agenda, inviting participants, and so on

• programmer presents their work to the reviewers. discussion should be general during the presentation

• following the general discussion, the programmer walks through the code in detail, focusing on the logic of the code rather than on specific test cases.

• reviewers ask to walk through specific test cases

• the chair resolves disagreements if the review team members cannot reach agreement among themselves and assigns duties, usually to the programmer, for making specific changes

• a second walk-through is then scheduled if needed

remember when testing information systems

• purpose of testing is to confirm that the system satisfies requirements

• testing must be planned

test case

• a specific scenario of transactions, queries, or navigation paths that represent a typical, critical, or abnormal use of the system

test case results

• should be repeatable

• need to determine if new software work with other existing software

testing harness

• automated testing environment used to review code for errors, standards violations, and other flaws

testing harness results

• greatly enhances the testing process 

  • can automatically expand the scope of the tests beyond the current development platform

acceptance testing

• actual users test a completed information system, the end result of which is the users’ acceptance of it

alpha testing

• user testing of a completed information system using simulated data

beta testing

• user testing of a completed information system using real data in the real user environment

tests performed during alpha testing

• recovery testing

• security testing

• stress testing 

• performance testing

recovery testing

• forces the software (or environment) to fail in order to verify that recovery is properly performed

security testing

• verifies that protection mechanisms built into the system will protect it from improper penetration 

stress testing

• tries to break the system

performance testing

• determines how the system performs in the range of possible environments in which it may be used

installation 

• organizational process of changing over from the current information system to a new one

four installation strategies

• direct installation

• parallel installation

• single-location installation

• phased installation

direct installation 

• changing over from the old information system to a new one (turning off old system + new one is on)

parallel installation

• running the old information system and the new one at the same time until management decides the old system can be turned off

single-location installation

• trying out a new information system at one site and using the experience to decide if and how the new system should be deployed throughout the organization

phased installation

• changing from the old information system to the new one incrementally, starting with one or a few functional components and then gradually extending the installation to cover the whole new system

 conversion of data

• must be error fre

• combined with new data and loaded into files

• may require current systems to be shut down

• involves getting people to change the way they work

system documentation 

• detailed information about a system’s design specifications, its internal workings, and its functionality

user documentation

• written or other visual information about an application system, how it works, and how to use it

support 

• providing ongoing educational and problem- solving assistance to information system users

in- house developed systems

• support materials and jobs will have to be prepared or designed as part of the implementation process

purpose

• critical for the success of an information system

potential training topics include:

• use of the system

• general computer concepts

• information system concepts 

• organizational concepts 

• system management

• system installation

training methods types

• resident expert

• traditional instructor-led classroom training

• e-learning/distance learning

• blended learning

• software help components

• external sources (vendors)

vendors 

• have automated support to users in order to cut costs

ways vendors have automated support:

• forums offered over the Internet

• voice-response systems (user navigates option menus)

• vendor knowledge bases

help desk 

• single point of contact for all user inquiries and problems about a particular information system or for all users in a particular department (non automated)

implementation effort sometimes fails because:

• employees don’t use the new system 

• employee dissatisfaction with new system

important factors to implement success

• commitment to the project

• commitment to change (willingness)

• meeting user expectations

factors that influence the extent to which a system is used

• user’s personal stake

• system characteristics

• user demographics

• organizational support

• performance

• satisfaction

cybersecurity issues

• increasingly important issue for organizations and their management

malicious software (malware)

• trojan horses, worms, viruses, and other kinds

internal actors and business partners

• responsible for one-fifth of reported data breaches

weakest link

• the user!

• failure to use (or secure) passwords

best defensive technology in the world cannot overcome

• human laziness and negligence

categories of the bug tracking form

• bug number (simple incremental number)

• test case ID that generated the bug

• is the bug replicable?

• effects

• description

• resolution

• resolution data

• comments

closing down the project

• evaluate team members

• conduct post-project reviews with management and customers

• close out customer contract

maintenance

• changes made to a system to fix or enhance its functionality

corrective maintenance

• changes made to a system to repair flaws in its design, coding, or implementation

adaptive maintenance

• changes made to a system to evolve its functionality to changing business needs or technologies

perfective maintenance

• changes made to a system to add new features or to improve performance

preventative maintenance

• changes made to a system to avoid possible future problems

many organizations 

• allocate 90% of information systems budget to maintenance

• have accumulatedold legacy systems that require way more maintenance

high costs associated with maintenance

• must understand the factors influencing the maintainability of systems

maintainability 

• ease with which software can be understood, corrected, adapted, and enhanced

factors influencing maintainability

• latent defects

• number of system customers

• quality of system documentation

• maintenance personnel

• tools

• well-structured programs

latent defects

• unknown errors after installation

number of system customers

• the greater the number the greater the maintenance costs

quality of system documentation

• lack of makes maintenance difficult

maintenance personnel

• high quality programmers required for maintenance

tools

• automated documentation and code tools 

well-structured programs

• are easier to understand and fix

measuring maintenance effectiveness factors

• number of failures 

• time between each failure

• type of failure

mean time between failures (MTBF)

• measurement of error occurrences that can be tracked over time to indicate the quality of a system

configuration management 

• process of ensuring that only authorized changes are made to the system

baseline modules 

• software modules that have been tested, documented, and approved to be included in the most recently created version of a system

system librarian

• person responsible for controlling the checking out and checking in of baseline modules when a system is being developed or maintained

build routines

• guidelines that list the instructions to construct an executable system from the baseline source code

special software systems

• being created to manage system configuration

• controls access to modules in the system library

• each time a module is checked out or in, this activity is recorded after being authorized by the librarian

low maintainability

• uncontrollable maintenance expenses