WADHWA's Simplified Computer Series 193 SSS 3.1 INTRODUCTION - Software testing is basically the process of executing 4 program with the intention to detect errors in the code. — It is essentially required before launching of software project. — The main causes of errors are: e Not obtaining the right requirements. e Not getting the requirements right. e Not translating the requirement in an understandable manner, — According to IEEE testing is: “ The process of exercising or evaluating a system or system component by manual or automated means to © verify that it satisfies specified requirements or e identify differences between expected and actual results.” — Effective testing will contribute to: © Delivery of higher quality software product. © More satisfied users. e Lower maintenance cost. © More accurate & reliable results. — Testing is a complex process. Various techniques are available to detect and eliminate errors.Software Testing 194 To make the testing process simple, the testing activiti, are broken into smaller activities. Generally incrementa) testing is performed in which the system is broken into bsystems. These subsystems are tested separately before grating them to form the system for system testing, sul i The following rules are aid to effective and beneficia) software testing: e Always test according to specification. © Document the testing process, specify the tests ang record the results. e Always test positively, that the software does what it should, also test negatively, that it does not do what it should not. 8.2 OBJECTIVES OF SOFTWARE TESTING — First of all the objective of software testing should be clear. Testing is a process of executing a program with the intention of finding errors. — The objectives of software testing are:- e To systematically uncover different types of errors in minimum time and with a minimum amount of t effort. e To ensure that the software is reliable and working Bk as per the specifications. © To ensure that the software is according to the requirements of the users. | e To deliver high quality software product. e To review the requirement specification design.WADHWA' nee Simplified Computer Series 195 8.3 T PRINCIPLES — Before ; designing effecti i knoe effective test cases, a software engineer cater W the basic principles guiding software testing. of them are listed below: (1) Follow Customer requirements:- - & Raf 7 Loe = the objectives of software testing is to uncover errors hus testing must locate severe defects that can cause tie program to fail to meet its requirements. ) Pre Planning:- — Test planning can begin as soon as the requirement model is complete. tests should be planned and designed before the code been generated. pply the Pareto Principle:- The Pareto principle implies that 80% of all errors detected during testing will likely be traceable to 20% of all program components. So the aim is to isolate such suspected components and test them thoroughly. (4) Testing should be from sub-system to system:- — The first tests planned should focus on individual components. As testing progresses focus shifts to find errors in integrated or united components and then in the entire system. (5) Tester should be other than programmer: Testing should be done by those who are not directly linked to design.Software Testing 196 (6) Error at the earliest:- The later an error is detected, the costlier it become, Therefore the aim is to uncover the error as early a, possible. 8.4 WHITE BOX AND BLACK BOX TESTING TECHNIQUES The two basic approaches to testing are:- (i) White box testing. (ii) Black box testing. (i) White Box Testing:- It is also called Structural Testing, Glass-Box Testing, Open-Box Testing and Path-Oriented Testing. It is used to test the structure of a program. In this approach, the internal functioning of the product is tested. Each procedure is tested for its accuracy. Concerned with the ‘How’. The objective of white box testing is not to check all the different input or output conditions but the intent is to exercise the different programming structures and data structures used in the program. More precise. White box testing tests the following:-197 d Computer Series . ions Of the procedure ie. execute all loops at their tundaries and within their operational limits. Internal data structures i.e. exercise internal data Structures to ensure their validity. Decision points i.e. exercise all logical decisions on their true and false sides. guarantee that all independent ° Execution paths i.e. been exercised at least Paths within a module have once, — The aim of this testing is to achieve test cases that will force the complete coverage of different structures. On the er hand it is concerned with the implementation of the ware. asis path testing technique is used to perform white box testing. Basis Path Testing:- — Basis path testing technique was proposed by Tom McCabe. — These tests guarantee to execute every statement in the program at least one time during testing. - Basis path testing technique enables the designer for defining a basis set. Basis set is the set of all the execution path of a procedure. — Path testing techniques are mostly used at unit testing and module testing stages of the testing process. The starting point for path testing is a program flow graph. This is the skeletal model of all paths through the program,Software Testing 198 Flow Graphs:- = Flow graphs are used to: © Represent control flow in a program. © Help in the derivation of the basis set. © Represent any procedural design. — Various flow graph notations used for the representation of control flow are:- Until Sequence 6 >.0 if while — EX. 1000] are defined. Equivalence partitioning reduces the number of test cases needed as test cases for each input domain are developed.Software Testing 204 (b) Boundary Value Analysis :- — In boundary value analysis, rather than selecting an, element of an equivalence class, focus is on the selectio; . n of test cases at the boundaries values. — Boundary valucs include maximum, minimum, just inside/outside boundaries, typical values and error values, Boundary valuc test cases are also called extreme cases, — It has been observed that large number of errors tend to occur at boundaries of the input domain. - Boundary value analysis guidelines include:- e For input ranges bounded by x and y, test cases Should include values x and y and just above and just below x and y respectively. ¢ = If an input condition specifies a number of values, test cases should be developed to exercise the minimum and maximum numbers and values just above and below these limits. (c) Cause-effect Graphing Techniques:- — A weakness of equivalence class partitioning and boundary value analysis is that they do not consider combinations of input. — Cause-effect graphing is a technique that helps in selecting combinations of input conditions in a systematic manner so that number of test cases do not become large. — It provides a concise representation of logical conditions and corresponding actions. — This technique starts with identifying causes and effects of the system under testing.WADHWA's Simplified Computer Series 205 SS OO 0—oeuw——w_—=—=_=——' — A cause is a distinct input condition and an effect is a distinct output condition. — Each condition is represented by a node in the cause effect graph. — Causes and effects are represented as Boolean variables which have either true or false. — The symbols used for drawing cause-effect graph are shown below:- Identity (e) («) ~“ OO o ©) r>C) Ci And “ C=)Software Testing 206 a Cause-effect graphing technique has four steps:- © Causes and effects are listed for a module. © Acause-effect graph is developed. The graph is converted toa decision table. Decision table rules are converted to test cases, eg. The city in filed] must be ‘Rohtak’ or ‘Karnal’. The state in field2 must be ‘Haryana’, then the file updation is done. If the city in field1 is not ‘Rohtak’ or ‘Karnal’ message A is issued. If the state in field2 is not *Haryana’, message B is issued. The causes are: C, : city in field] is ‘Rohtak’. C2 : city in field] is ‘Karnal’ C; : state in field2 is ‘Haryana’. The effects are: e, : updation done. e, : message A is issued e3 : message B is issued The cause-effect graph is shown below:-ie 207 WADHWA&'s Simpli A's Simplified Computer Series nee following — The ¢ ‘ause effec ffect. graph technique has the advantages:- © Nu umber of test cases reduced. © High yield test cases. ° , Helps in understanding the functionality of the system. 8.5 SOFTWARE TESTING STRATEGIES oftware test case tegrates 5 f steps that nned series © n of software- pers and quality — Software testing strategies in! design techniques into a well pla results in the successful constructio! ovides a road map to software develo — Itp ganizations. assurance Or: neers and testing software engi manager, ftware testing. _— The project specialists develop a strategy for so: Any test strategy must provide: e Test planning, Test case design, ° and e Test execution e Evaluation. et of activities. These activities must be hat it must not a s ystematically so t d conducted s for rework. _ Testing is planned_an Jeave any scope s software testing st haracteristics © — Variou rategies have been proposed so f these software, testing far. Common ¢ strategies are:-Software Testing 208 Testing begins at the module level and then it work towards the integration of the entire system. ‘ For software robustness, different testing techniques are appropriate at different times. Testing is conducted by the developer of the software and for large projects by an independent testing team. Testing and debugging are different activities, Testing aims to find the errors. Debugging is the process of fixing these errors. In order to conduct a proper testing, the following order should be performed:- © Unit testing. e Integration testing. e System testing. Unit testing focuses on the testing of individual modules. After unit testing, modules are integrated. Errors often arise on integration. After integration testing, system tests are performed that focus on the overall system. Unit testing Sequence of tests | Integration testing System testingWADHWa~'s Simplified Computer Series 209 _ 86 UNIT TESTING y of Unit testing is the process of checking the functionalit the module. A module is the smallest unit of software Unit testing begins after the source code is developed and Verified for the correct syntax. ake the smallest unit The primary goal of unit testing is to t hether it works of testable software and to find out w exactly as expected. — Each unit is tested separately before these units are integrated together to build the overall system. ing design description as a guide, important control are tested to uncover errors within the boundary of ie module. The following are the tests that are performed during unit testing:- (a) Module interface test:- — In module interface test it is checked whether the information is properly flowing into the module and properly coming out of it under the specified operating conditions. | (b) Performance test:~ — It is designed to verify response time, execution time, throughput and traffic rates on data channels and communication links. (c) Local data structure test:- — Itis tested to check if the local data within module is stored properly or not.Software Testing 210 ————— (d) Boundary Conditions test:- — Boundary conditions are tested to ensure that the program is working properly at the boundary conditions. (e) Independent paths test:- — Independent paths are tested to check that they are executing their properly or not. () Error handling paths test:- — These are tested to check whether the errors handling paths are working properly or not. Module Module interface test Performance test Local data structure test Results -————> Test cases Boundary conditions test Independent paths test Error handling paths test Unit Testing Test cases should be designed to uncover errors due to: e Incorrect comparison of different data types. e Erroneous computations. e Incorrect comparison of variables. » © Improper conirel flow.“a WADHWA's Simplified Computer Series ail —— ¢ Improper loop termination. © Incorrect logical operators or precedence. e Improperly modified loop variables etc. Unit Testing Procedure:- — As cach module is tested individually in unit testing so there is need to obtain data from other module or pass data to other module. This is achieved by using stubs and drivers. The driver simulates a calling unit and the stub simulates a called unit. driver is a program that takes test case data to the module being tested. and passes it Stubs are also programs used to replace modules that are subordinate to the module being tested. Stub Test case | Driver | Test ,[ sue} — Module Stub vers and stubs to be written. This - Unit testing requires dri d if drivers and stubs are kept overhead can be reduce! cimnleSoftware Testing 212 8.7 INTEGRATION TESTING of unit testing is integration testing. In this — The next step A < ‘¢ combined into subsystems many unit tested modules ar which are then tested. ¢ of unit testing is to find out that each independent module is correctly implemented. But unit test does not guarantee that these modules will work fine jr these are integrated together as a whole system. For this reason integration testing must be performed. — The main purpos — Integration testing is a systematic technique that integrate the tested modules, find errors, remove them and check the program structure as specified by design. Following types of errors may arise during the integration of tested modules:- e Global data can create problems. © Data can be lost across an interface i.e. data coming out of a module is not going to the desired module. © Modules when combined do not produce the required major module. © One module can have an adverse affect on another. — Two basic types of integration are usually used:- (i) Top-down integration. (ii) Bottom up integration. (i) Top-down Integration:- fh that — Top-down integration is an incremental approac fl rate requires the highest-level modules be tested and integ) first.aa dd ae pi More other modules, replacing and providing new stubs as necessary. Continue the process until all modules have been integrated and tested - High level logic and data flow is tested early in the process and thus minimizes the need for drivers. y *¥ Advantages of Top-down Integration:- e Top-level interfaces are tested first. «© Supports both “breadth first” and “Depth first” approaches. © Top-level routines provide a natural test harness for lower-level routines. © One driver at the most is required. Disadvantages of Top-down Integration:-SE WADHWaA's Simplified Computer Series 213 Add ae One or more other modules, replacing and providing nw rt as necessary. Continue the process until all ules have been integrated and tested. - High level logic and data flow is tested early in the process and thus minimizes the need for drivers. Advantages of Top-down Integration:- © Top-level interfaces are tested first. © Supports both “breadth first” and “Depth first” approaches. e Top-level routines provide a natural test harness for lower-level routines. © = One driver at the most is required. Disadvantages of Top-down Integration:- © Delays verification of low-level modules.Software Testing 214 eee * Not enough data in the stubs to feed back ty y, calling module. © Provides poor support for early release of limiteg Sunctionality. © = Need for stubs complicates test management. (ii) Bottom up Integration:- — The bottom up integration approach requires the lowest. level modules be tested and integrated first using a driver, — Add one or more additional modules, replacing drivers with modules only when all modules they call have been integrated. Continue the process until all modules have been integrated and tested. Advantages of Bottom up Integration:- ° Stubs are not required as developing and testing Starts with the actual modules.WADHWA's Simplified Computer Series 215 Allows early verification of low-level modules. Disadvantages of Bottom up Integration:- . I i Need for drivers complicates test management. * Provides poor support for early release of limited functionality. . Delays verification of high level behavior. 8.8 VALIDATION TESTING The assembled package after integration testing undergoes validation testing. This testing ensures that software function according to the customer’s expectations. _ Expectations are the software requirement specifications While analyzing the requirement specifications, validation criteria is also set and hence that forms the basis of validation testing. Thus validation succeeds when sofiware functions in exact manner as expected by the customer. For validation testing, a scries of black-box tests are conducted to verify the conformity with requirements. The test plan and a test procedure is defined to check the errors. In validation testing, plan and procedures ensure that: © All functional requirements are fulfilled. e All the required characteristics are achieved. © Documentation is done correctly.Software Testing 216 — The validation tests may result in one of the following tw. possible conditions:- (i) The software performance is accepted. ist is created. To resolve deficiencies (ii) A deficiency | ‘omer can be made. some negotiation with the cust — Configuration review is important in validation process. [t ensures that all elements of the software configuration have been properly developed. The configuration review is also called an audit. 8.9 SYSTEM TESTING System testing implies testing of the entire software. The goal of system testing is to see if the software meets its requirements. System testing includes a series of different tests to fully exercise the computer-based system. — Each test has a different purpose and the series of tests verify that all system elements are properly integrated and are performing the allocated functions. — System testing involves the following types of testing:- (i) Recovery testing (ii) Security testing (iii) Stress testing (i) Recovery Testing:- — Recovery testing is designed to examine how easily and completely the system can recover a system failure.WADHWA's Simplified Computer Series 217 Series Many com resume Seatherenn systems recover from faults and . ation within a pre-speci . . 8 “spec e or a system may be fault tolerant pre-specified time o Recovery testi ; c Overy testing forces the software to fail in a variety of Ways and verifies that 5 i : s that system recovery is properly performed. , , A_ system with quick recovering capability and with minimum human intervention is desirable. In case, the recovery requires human intervention, the mean time to repair is evaluated to determine whether it is within acceptable limits. case, the recovery is automated then re-initialization echanisms and data recovery are evaluated for rectness. ii) Security testing:- Security testing tests or verifies the: © Protection mechanism built into a system to determine that the system is protected from unauthorized personnel. . Other systems cannot gain access to the system and information within it. (iii) Stress Testing:- Stress testing test the system performance in abnormal situations. — Stress testing executes a system in a manner that demands resources in abnormal quantities. edSoftware Testing 21a ee, c.g (i) Input data rate may be increased in magnitude te determine how input functions will respond (ii) Test cases that may cause thrashing in a Virtual operating system may be designed (iii) Test cases involving excessive searching/hunting of data on disk. Test cases involving increased input data rate may be designed to determine how input function respond. 8.10 REGRESSION TESTING This type of testing is used during the maintenance of the software. When one or more modules are added to the existing system or some of the modules are deleted from the existing system, regression testing is needed to make sure that the modified software works properly. Regression testing may be conducted manually by reexecuting a subset of all test cases or by using automated tools. In highly modular software with well designed interfaces, regression testing can be limited to the module which has been changed and its interfaces. Regression test contains different classes of test cases. These are:- = Tests that will exercise all software functions. © Additional tests for software functions that are affected by the change. e = Tests for the functions that have been changed.Wapnwa ¢ Simplified Computer ries 219 itn SL ALPHA AND BETA TESTING The customer will use the developed software. How the customer uses the software, it is difficult for a software developer to foresee. Instructions given with the software may be misinterpreted by the user. =~ When software of acceptance tests built, for one customer, a seri are conducted to enable the customer to validate all requirements. Acceptance testing is performed using real data of the customer to demonstrate that software is working satisfactorily. Customer rather than developer conducts acceptance testing. Testing here focuses on the external behavior of the system. Infact, acceptance testing can be conducted over a period of weeks to uncover cumulative errors that might degrade the system over time. — When a system is to be marketed as a software product for many customers, it is practically not possible to perform acceptance testing with each onc. For this, most software developers use a process called alpha and beta testing to uncover the errors that the end user may find. — Acceptance testing is also sometimes known as alpha testing. — Alpha testing is conducted by the customer at the developer’s site. The developed software is used in a natural setting with the developer. The developer records errors and usage problems. — The alpha testing process continues until the system developer and the customer agrees that the developed software is an acceptable implementation of the system requirements. Alpha tests are conducted in a controlled environment.Software Testing 220 ———— SSS — Beta testing involves delivering the system to a number of customers who agree to use that system. The beta test is thus conducted at one or more customer sites by the end users of the software. Since the developer of the software is not present at the site of customers therefore the beta test is a live application of the software in an environment that can not be controlled by the developer. Customers record the problems that are encountered and report problems to the system developer at regular intervals. This exposes the product to real use and detects errors that may not have been anticipated by the system developer. The software developer makes modifications and releases the developed software either for further beta testing or to the entire customer base.Sofware maintenance is the term that is commonly used © refer to the modifications that are made to software system after its release. It is a software engineering activity that occurs following delivery of a software Product to the customer. It plays an important part in the system development. jaintenance occurs after ° The product is delivered at user’s site, ¢ Installed and e Itis in operational state. — Thus any work done to change the software after it is in operation is said to be maintenance. — Software maintenance covers a wide range of activities which includes correcting coding and design errors, updating documentation and upgrading user support. — According to IEEE “ IEEE standard for software maintenance” “ Software maintenance is modification of a software product after delivery to correct faults, to improve performance or other attributes or to adapt the product to a modified environment.” — According to Stephen, “ Software maintenance is a detailed activity that include e Error detection and corrections, e Enhancements of capabilities,= i 22 Software Maintenance 6 eS Sams") © Deletion of obsolete capabilities and © Optimization.” — Software maintenance is an important activity in es of a software product. The total cost of maintenance aoe is much higher than the development cost of eae tware Usually it consumes about 40-70% of the cost of the entire life cycle. To know the factors that affect such costs, it js customary to divide software maintenance into three categories: corrective, adaptive and perfective maintenance, — Thus maintenance activities involve: ° Understanding the existing software. © Making enhancements to software products. ° Understanding the effect of change. Adapting products to new environments. Making the changes to both code and documents. © Correcting problems. © Testing the new Parts & © Retesting the old Parts that were not changed. — Inorder to make the maintainer job easier, it is necessary to Prepare some supporting documents during software development. 9.2 AIMS OF SOFTWARE MAINTENANCE Aims of software maintenance are:_ To maintain the value/quality Of software Overtime. To enhanc. € the softwa, Sunctional capabilities. r€ product by Providing newWap HWaA's Simplified Computer Series 227 * To ensure the optimum a ments for wu i i ptimum availability of equipments fc Production and to to obtain a: "7 ; the i possi return on investment. ee eee ° To adapt ae he ae to cope with changes in the different ees involves moving the software to es, ify it Protocol etc. » modify it to accommodate new ° = Modificatioi mand rev i Gres. revalidation of software to correct © Upgrading th he aan stent IS performance characteristics of 4 © To upgrade th je software in icipatic problems. oft anticipation of future . 7 . To improve user displays and modes of interaction. . To ensure the safety of personnel using facilities. .3 TYPES OF SOFTWARE MAINTENANCE Three major types of software maintenance are:- (i) Corrective Maintenance i) Adaptive Maintenance (iii) _Perfective Maintenance (i) Corrective Maintenance:- Corrective maintenance refers to modifications initiated by defects in the software products. ality assurance acti Il uncover defect: changes the software to corr’ vities, it is possible s in the software. Even with the best qu ect the that the customer wi Corrective maintenance defects.Software Maintenance 228 —e—e—e—e—e————e————ee SSS» — This the main aim of corrective maintenance 18 to Correct any remaining errors in the software product. - A problem can result from specification errors, design errors, logic errors, coding errors, testing errors etc. — Defects are also caused by data processing errors and system performance errors. — Incase of system failure, various steps are taken to restore operation of the software system. — According to K. Bennett, maintenance personnel sometimes resort to emergency fixes known as patching to reduce pressure from the management. ut it creates various problems like — Patching may be simple bi lexity and unforeseen tipple increased program comp! effects. le effects mean that a change in a part of ffect other programs in an uncontrollable s to complete mess up in the logic of the — Unforeseen ripp the program may a! manner which lead system. The reason is shortage of time to carry out an “impact analysis” before a corrective change. Corrective maintenance accounts for about 20 percent of maintenance costs. (ii) Adaptive Maintenance:- — Adaptive maintenance means modifying the software product to react to changes in the outside environment in which the system operates. — The term environment refers to the totality of all condit and influences that act from outside upon the software. ions ilADHWwAS Simplified Computer Series 229 e Porti tor eX ample Porting to a Rew com psiness rules, government pt ile & Policies Operating system, According to R. Brooks, a this environment will re of the software. chan, tire a comer’ Whole oF part of @ . Orresponding Modification Adaptive maintenance is general client but it is imposed by the out lly not Tequested by the side environment. For example if the government increa system of Payroll will have to undergo adage cao Thus, adaptive maintenance j involves adjusti | to accommodate changes in t! ijusting the software the environment. _ Adaptive maintenance accounts for about 20 maintenance costs. percent of (iii) Perfective Maintenance:- Perfective maintenance means improving: e. Efficiency e Performance e. Maintainability e Effectiveness F of the software product. & - Enhancements are often considered part of perfective maintenance. the users ~ When the software becomes operations nich it experiment with new cases beyond the scope was initially designed.Software Maintenance 239 = For example some users are not satisfied with the GUT o¢ the software product so changes can be incorporated », make it more attractive and effective = This type of maintenance is not compulsory but changes in the system are done just for perfection. — The request to perform perfective maintenance may come directly from the software engincer to improve the software according to the market or they may come from the customer to meet the new requirements. Thus, perfective maintenance involves changing the software to improve its qualities. These changes are due to the need to modify the functions offered by the application, add new functions, improve the performance of the application, make it easier to use etc. Perfective maintenance accounts for about 50 percent of maintenance costs. 9.4 MAINTAINABILITY — One of the important objectives of the development project is to produce software that is easy to maintain. — Maintainability can be defined as the ease with which software can be: e Understood ¢ Corrected if an error occurs © Adjusted if its environment changes ¢ Enhanced as per customer’s demand or modification in requirements.WADHWA's Simplified Computer Ser eres 231 — There is Ss no v hence indir Way to Measure maintainability directly and irect measures are used. nability directly ant a sed — There Many activities performed during software develo pment to ent hance the mai of soft C Some of them are: aintainability of software (1) Analysis Activities:- — In this phase analyst deals with: e Customer requirements © Constraints e Feasibility of the product. a ing analysis standards and guidelines for the project are 1p which specify: © The quality assurance procedures 10 ensure development of. high quality documents e Estimate the resources needed to perform maintenance activities. (2) Standards and Guidelines:- of software different types, — To enhance the maintainability be developed like: of standards and guidelines can Standard formats. for requirement documents. e Standard. formats, for design specifications e The test plan e The principles of operations e User man ual/guidelines etc.The clarity modification ° Ease ° Modularity et (4) Implementation activities: nd single exit coding constructs jentation of constructs coding styles encapsulation techniques on resources such as table size ete © Proper margins ©) Supporting Documents:- 95 MAINTENANCE TASK ANCE TASKS — Ip onder to accomp! ftware maint Organization is be defined. — Tasks for softwar request for maintenanceSoftware Maintenance 232 (3) Design activities:- During architectural phase the most important activity fig der the following bas: (4) Implementation activ enhancing maintainability is ¢ to cons design criteria © The clarity © Ease of modification © Modularity etc. While implementing, again the main objective is to produce software that is easy to understand and modify. Such case can be achieved by the use of : Single entry and single exit coding constructs Standard indentation of constructs Straightforward coding styles Data encapsulation techniques Proper margins on resources such as table size etc. (5) Supporting Documents:- In order to ease maintenance activities supporting documents should also be prepared during the software development phase such as the maintenance guide and test description etc. 9.5 MAINTENANCE TASKS In order to accomplish software maintenance, an organization is established and evaluation procedures must be defined. Tasks for software maintenance begin long before the request for maintenance is made.233 le modific ation to se incluc Jation — The technic. ue echnical tasks for maintenanc a re design, unit and integration testin’ reviewing ete. g. valic aintenance es am ning nally generat asis for planr ied h ft T he software developer norm a bi nes, form (MRF) which is used as € maintenance task. The maintenance can be of the following types~ © Corrective Maintenance Adaptive Maintenance Perfective Maintenance Preventive Maintenance osis and correction © — The process of making diagn errors is called corrective maintenance. f one OF of error is tive maintenance, the severity m supervisor ror exists, the syste! lyze the problem. © the activities that modify with a changing correct valuated. If severe © assigns personnel to anal ance refers t — Adaptive mainten: software to properly interface environment. the adaptations are evaluated ance, nance action. For adaptive mainten ue for mainte! and put ina priority que’ ance refers to the success of software for d general enhancements. riority of enhancement required work is Perfective mainten: new capabilities an _ For perfective maintenance, the p requests js established and the planned/scheduled. s for preventive changed for future reliability and ¢ owing techniques may be employed:- — Activities maintenance are needed when software iS nhancements. For this foll= Software Maintenance 234 i) Rev not ; : (i) everse Engincering:- It is a process of extract architectural and procedural design information 4.8 an existing program, “om prog (ii) Re-engineering:- It not only recovers design informat; from existing software but also uses this information 0 alter or improve the existing system. The final task in the maintenance flow is a review. review is made to revalidate all elements of the software configuration and ensure the fulfillment of MRF. 9.6 MAINTENANCE SIDE EFFECTS — During the process of software maintenance some error o; undesirable behaviour may occur as a_ result of modification. So the term ‘Maintenance side effects: implies such error. — Three major categories of side effects are:- @ Coding Side Effects. (ii) Data Side Effects. (iii) Documentation Side Effects. (i) Coding Side Effects:- — A change in a single statement may sometimes lead to problems e.g. replacement of ‘a,’ with ‘a.’ — Some of the following modifications may introduce error:- e Deletion or change of a subprogram. © Deletion or modification of a statement label. e Deletion of an identifier. © Modification of logical operators. © Translation of design changes into major code changes. e° Changes to logical tests of boundary conditions etc.WADHWA's Simplified Computer Series 235 Many of these errors can be detected and remedied during Tegression testing. (ii) Data Side Effects:- Due to modification to individual elements of a data Structure, the software design may not fit the data and error can occur. e following changes in data may result in side effects:- Redefining local and global constants. Increase or decrease in the size of an array or a higher order data structure. Reinitialization of control flags or pointers etc. Data side effects can be limited by thorough design documentation that provides a cross reference to associate data elements, records, files etc. with software modules. (ii) Documentation Side Effects:- Documentation side effects occur when changes to source code are not reflected in the design documentation or user’s manuals. Changes in the order or format of interactive input. New undocumented error messages, outdated tables of contents etc. can causg confusion and dissatisfaction to the user. Documentation side effects can be reduced if entire configuration is reviewed prior to re-release of the software.