system implementation, maintenance and review

8/8/2019 SYSTEM IMPLEMENTATION, MAINTENANCE AND REVIEW

1/38


2/38

SYSTEMIMPLEMENTATION,MAINTETNACE AND

REVIEW

INSTALLATIONAND

IMPLEMENTATIONTESTING TRAINING DOCUMENTATION

FILECONVERSION

ANDCHANGEOVER

SYSTEMMAINTENANCE

SYSTEMPERFORMANCE

POSTIMPLEMENTATION

REVIEWWHAT CAN GO

WRONG


3/38

Select location / siteStep 1

Choose and order hardwareStep 2Design and write software or purchase off the shelf Step 3

Program testingStep 4

Staff trainingStep 5

Produce user documentationStep 6

Produce systems documentationStep 7File conversionStep 8

Testing (including user acceptance testing)Step 9

System changeover (and further testing and training required)Step 10


4/38

Pearson Education Limited, 2004 4

Process of running the database system withthe intent of finding errors.

Use carefully planned test strategies and realisticdata.Testing cannot show absence of faults; it can showonly that software faults are present.

Demonstrates that database and applicationprograms appear to be working according torequirements.


5/38

Testers usually try to "break the system" byentering data that may cause the system to

malfunction or return incorrect information.

For example, a tester may put in a city in a

search engine designed to only accept states,to see how the system will respond to theincorrect input.


6/38

Testing system logicUse of flowcharts and structured diagrams to test the logicdevised by the system analyst

Pr og ra m testingInvolves processing test through all programsFully documented to use if modifications are required

Cover the following areas:Input validity checksProgram logic functioningInterfaces with related modules / systems

Output format and validity


7/38

Types of Pr og ra mTestingU nit testing

Functional and reliability testing in an Engineering environment. Producingtests for the behavior of components of a product to ensure their correctbehavior prior to system integration.The primary goal of unit testing is to take the smallest piece of testablesoftware in the application, isolate it from the remainder of the code, anddetermine whether it behaves exactly as you expect. Each unit is testedseparately before integrating them into modules to test the interfacesbetween modules. Unit testing has proven its value in that a large

percentage of defects are identified during its use.U nit integ ra tion testingTesting in which modules are combined and tested as a group. Modules aretypically code modules, individual applications, client and serverapplications on a network, etc. Integration Testing follows unit testing andprecedes system testing, that is, It occurs after unit testing and before

system testing


8/38

S ystem testingTesting conducted on a complete, integrated system toevaluate the system's compliance with its specifiedrequirements. Wider focus than program testing. Systemtesting falls within the scope of black box testing, and assuch, should require no knowledge of the inner design of the code or logic.

Input documentation and practicalities of inputFlexibility to allow amendmentsAbility to produce timely informationAbility to cope with peak system requirementsViability of operating procedures

Occurs both before and after implementation


9/38


10/38

Performance testingPerformance testing can be applied to understand your application orWWW site's scalability, or to benchmark the performance in an

environment of third party products such as servers and middlewarefor potential purchase. This sort of testing is particularly useful toidentify performance bottlenecks in high use applications.Performance testing generally involves an automated test suite as thisallows easy simulation of a variety of normal, peak, and exceptionalload conditions.Evaluate compliance of a system or component with specifiedperformance requirements


11/38

U sab ility testingTechnique used to evaluate a product by testing it on users. This can be seen as anirreplaceable usability practice, since it gives direct input on how real users use thesystem. Establishment of users satisfaction.

The aim is to observe people using the product to discover errors and areas of improvement. Usability testing generally involves measuring how well test subjectsrespond in four areas: efficiency, accuracy, recall, and emotional response. The resultsof the first test can be treated as a baseline or control measurement; all subsequenttests can then be compared to the baseline to indicate improvement.

P erformance -- How much time, and how many steps, are required for people to complete basictasks? (For example, find something to buy, create a new account, and order the item.)A ccuracy -- How many mistakes did people make? (And were they fatal or recoverable with theright information?)R ecall -- How much does the person remember afterwards or after periods of non - use?E motional response -- How does the person feel about the tasks completed? Is the personconfident, stressed?Would the user recommend this system to a friend?


12/38

Au tom a ted Testing toolsProgram testing and fault detection can be aided significantly by testing toolsand debuggers. Testing/debug tools include features such as:Program monitors, permitting full or partial monitoring of program codeincluding:

Instruction set simulator, permitting complete instruction level monitoring and tracefacilitiesProgram animation, permitting step - by- step execution and conditional breakpoint atsource level or in machine codeCode coverage reports

Formatted dump or symbolic debugging, tools allowing inspection of program

variables on error or at chosen pointsAutomated functional GUI testing tools are used to repeat system - level teststhrough the GUIBenchmarks, allowing run - time performance comparisons to be madePerformance analysis (or profiling tools) that can help to highlight hot spotsand resource usage


13/38

Strategy details of the testTechnical testSTRATEGY APPROACH

WhatWhenUnder which environment

TEST PLAN

The logic and reasoningTEST DESIGN

Detailed proceduresConsistent testing at different time periodPER OR ING TESTS

Documentation of the results and how to be doneRecord of errorsCorrection of errors procedure

DOCU ENTATION

Re- testing procedureRe- testing of all modules and all aspects of the softwareRE-TESTING


14/38

Poor testing process (Bad test plan, Testers are not well trained)

Inadequate time to test the project

Future requirements not anticipated

Inadequate test data (positive and negative data)

Software changes inadequately tested


15/38


16/38


17/38

Senior managementMiddle managementOperators

TRAINING METHODSIndividualClassroomComputer basedCase studiesSoftware reference material


18/38


19/38

Wide range of technical and non technicalbooks

Technical manualInstallation stepsHardware specificationsFlow chartsData dictionary, etc

User manualSystems set upSecurity proceduresSystem messagesControl procedures


20/38


21/38

Converting existing files into suitable format forthe new system. Create new files conform to thenew system

Existing data filesManual files (input data)Existing computer files (either through automation or coding)Existing data incomplete

Controls of changes (accuracy of new files)One to oneSample checkingBuil tin validationControl total and reconciliation


22/38

Completeness of dataRemoval of redundant data

Check originalfiles

Input forms = data entry screenTranscribe ontoinput forms

Key in data

Validation of data and verificationbuilt in in the systemVerify data

Standing records for a startingpointPrint reports

Establish

controlstotal

Controlstotal

Controlstotal

check

check


23/38

After satisfactory testing, changeover shall takeplaceFour approaches

Direct changeoverOld system completely replaced

Parallel runningOld and new system run in parallel within a definite delay

Pilot operationOne department run the two system in parallel on a pilotbasis. If satisfied, whole changeover

Phased or staged changeoverSection of the system for a direct changeover over phases


24/38

ME THOD ADVANA TGE S DISADVAN TA GE S

Direct changeover Quick at minimal costMinimises workload

RiskyPossible disruptions of operationsFailure - costly

Parallel running Safe, built in safetyWay to verify results of changes

Costly and Time consumingAdditional work load

Pilot operations ess risky than direct changeover

ess costly than complete parallelrunning

ong time to achieve total

changeess safe than parallel running

Phased changeover ess risky than single directchangeoverProblems in one section does notaffect others

ong time to changeUnpractical - Interfacesbetween parts of system -


25/38


26/38

Features of maintenanceFlexibility and adaptability

Types of maintenanceCorrective

Reaction to system failure

PerfectiveProcess of making the software perfect

AdaptiveTake account of changing environment


27/38

27

ErrorsChanges in requirementsPoor documentation

Maintenance is only for a period of timewhereby redevelopment will benecessary due to various newrequirements and changes inenvironment


28/38


29/38

INDIRECT MEASURESSignificant task relevance (observe the results of

system use, earlier or late)Willingness to pay

Pay as you satisfy

System logsUser information satisfaction

A survey of users on several criteria

Adequacy of documentation


30/38

Performance reviews vary from organisation toorganisation. The main issues however would be :

Growth rateClerical manpowerIdentification of delaysEfficiency of security proceduresCheck of error ratesUse of output for good purposeOperational running costs


31/38

COMPUTER SYSTEMS EFFICIENCY AUDITSOutput from a computer system

More outputs with same input (e.g more transaction, oreManagement info, availability of the system to more users)Elimination of Output of little value

Frequency of reports, and its distribution and bulkinessBetter timing of outputs and timely accessibility tomanagementReasons that restricts better output (access to informationthat needs a database or network, method of data processingused that is batch or real time or type of equipment used thatis stand alone pc or client /server system)


32/38

Cost benefit analysisBased on clear objectives and factors

Efficiency and effectivenessOutput greater than inputProductivity improvement

Accuracy of dataMeasurement of achievement of objectivesMetrics


33/38

Quantified measurement to measure performanceResponse time, no of transactions process per minute, no of bugsper hundred lines of codes, no of system crashes per week

Three methods usedHardware monitors

Measurement of electrical signal in selected circuits, idle andlevel of activity

Software monitors

Programs that interrupt the application in use and record dataabout it

System logsJ ob start and finish, Variations in job running, Down time


34/38


35/38


36/38


37/38

Conflicting demandsTime, cost, quality, resources

Appointment of project managersGood manager but good specialist

Other factorsUnrealistic deadlineNon - existent planning (fail to plan is plan to fail)Poor time table and resourcingInexistence controlChanging requirements


38/38

Definite objectivesApprove projects

Recommend projectsEstablishing priority projectsEstablish company guidelines

Coordination and controlEvaluationSystem review after implementation

system implementation, maintenance and review

Documents