..
RISK AND CONTROL OF THE SOFTWARE MAINTENANCE PROCESS
By Frederick G•llego1, CISA, CDE U.S. G•n•r•I Accounting Office
The increased demand for new or improved com Quality. Thus, measures should be established to aid puter information systems application has created in determining which category of changes are likely a number of problems for the DP professional, the to degrade software quality, especially impact to the users. an~ management. Staff and budget con straints limit the ability of DP managers to respond FIGURE A to this demand. Antiquated or poorly designed sys tems have created severe maintenance and perfor THE SOFTWARE mance problems. leaving little time to develop new MAINTENANCE PROCESS applications or improve existing systems. Thus, the 1. Determination of need for change risk and control of maintaining the software is an 2. Submission of change request important goal, an institutional goal toward which 3. Requirements analysis all must work. 4. ApprovaJ/rejection of change In response to this goal, the National Bureau of request Standards issued its Federal Information Process 5. Scheduling of task ing Standards Publi~~tion Number 106, entitled 6. Design analysis Guideline on Software Maintenance. The Guideline 7. Design review provides general guidance for managing software 8. Code changes and debugging maintenance. It does a,, excellent job of com 9. Review of proposed code changes municating that improvements in the area of soft 10. Testing ware maintenance will come primarily as a result of 11. Update documentation the software maintenance policies, standards, 12. Standards audit procedures, and techniQues instituted and enfo.-ced 13. User acceptance by management. 14. Postinstallation review of changes Controlling the software maintenance process is and their impact on the system an institutional goal, which management, users, and 15. Completion of task DP professionals must collaboratively work toward. Controls involve how well they work together in per user. The primary purpose of change control is to forming the software maintenance process illustrat assure the continued smooth functioning of the ed in Figure A. application and its orderly evolution. Examples of Everything that is done to software affects its such controls are described in Figure B. 12 •Quality Data Processing • The in herent ri sks of software maintenance are FIGURE B man y. If organizat ions do not properly manage and a5sess the process from an institutional standpoint. CONTROLLING SOFTWARE sy stems may evolve to a state where the organ iza· MAINTE+4ANCE t1on ·s abil ity to meet the information demands of its 1. Rev iew and evaluate all requests for users and decision making will in fact affect its changes. profitability. The risks are having systems oevelop -Require formal (written) requests characteristics such as those shown in Figure C. for all changes. The greater the number of characteristics found in -Review all change requests. a system, the greater the potential for disaster and -Analyze and evaluate the type and need for redesign. frequency of change requests. -Consider the degree to wh ich a FIGURE C change is needed and its anticipated use. All changes should CHARACTERISTICS OF SYSTEMS be fully justified. WITH HIGH RISK -Evaluate changes to ensure that AND ARE CANDIDATES they are not incompatible with the FOR REDESIGN original system design and intent. 1. Frequent system failures No change should be implemented 2. Code over 7 years old without careful consideration of its 3. Overly complex program structure ramifications. and logic flow -Emphasize the need to determine 4. Code written for previous whether the proposed change will generation hardware enhance or degrade the system. 5. Running in emulation mode -Approve changes only if the 6. Very large modules or unit benefits outweigh the costs. subroutines 2. Plan for and schedule maintenance. 7. Excessive resource requirements -Assign a priority to each change 8. Hard-coded parameters which are request . subject to change -Schedule each approved change 9. Difficulty in keeping maintainers request. 10. Seriously deficient documentation -Adhere to the schedule. 11 . Missing or incomplete design -Plan for preventive maintenance. specifications 3. Restrict code changes to the approved work. Software maintenance is an institutional issue 4. Enforce documentation and coding which all participants must work towards in standards through reviews and achieving controllable systems in these times of audits. dynamic technological change. It is a goal which can be reached if supported by all concerned.
January 1987 • 13