Change Management Systems John G. Burch Fritz H. Grupe Payoff

Transcription

1 Change Management Systems John G. Burch Fritz H. Grupe Payoff One of the most vulnerable activities in terms of security and control of information systems (IS) is program change. During the change process, data security administrators and programmers must employ strict controls to ensure that program changes are properly requested, approved, assigned, coded, tested, documented, and released to production. A major resource to facilitate these controls is a change management system (CMS). This system involves initiation and review of a change request, approval and scheduling of the change, coordination of resources to effect the change, and implementation and follow-up review of the change. Although any IS resource (e.g., processors, disk drives, printers, systems software, networks, and environmental resources) is subject to a CMS, this article focuses on change management for applications programs, provides a general model of a CMS, describes the various functions within that system, and discusses the effective implementation of a CMS. Problems Addressed Security administrators and programmers who try to control, modify, or change applications programs without a well-planned, carefully administered system of change can encounter such difficulties as: Lack of an accurate program inventory. The IS department does not know precisely which programs have been approved for use or are actually in service, the location of these programs, and the programs that are scheduled for change. Incomplete history of program changes. There is no complete history of change requests, change authorizations, modified programs, or programmer change assignments. Lack of program change integrity. Some systems experience inadvertent program code overlays. This problem usually occurs when different programmers have uncontrolled access to production source code with no log-out, log-in, or tracking mechanisms in place. For example, one programmer accesses a copy of a program to make enhancements. At the same time, a second programmer, who has also accessed the same program, makes a quick bug fix and updates the production source code. The first programmer then completes the enhancements, places the program into production, and erases the bug fix and the production source code updates. Program abends. A programmer can spend hours reviewing the program listing to find out what went wrong with a program only to discover that the source code in place is not the original version that was used to create the current load module. The original source code could be in another programmer's private file, or it could be lost. Duplicated program modules. Often modules that perform standard processes are duplicated, rather than being developed once and then reused, wasting both personnel and commuting resources. Similarly, modules that are shared may be changed to accommodate one program, causing the disruption of another program's operation.

2 Unauthorized changes. For various reasons, users may make unauthorized changes to production programs. Such changes may be innocent, fraudulent, destructive, or the work of a midnight programmer (i.e., an employee who programs or makes changes to existing programs outside business hours). Lack of documentation and testing. The pressure to fix or modify a program may constrain effective program change documentation and may encourage use of a program that has not been adequately tested. Inability to back out of a change. If the revised code fails, the programmer may not be able to retrieve the earlier working version and reconstruction of the original file may be impossible. Lack of host compatibility. If software is designed for cross-platform utilization, inappropriate modules might be combined and delivered. How Software Configuration Management IS Changing Software Configuration Management originated on mainframe systems where, until recently, mission-critical applications were being developed. Change Management System (CMSs) have changed to meet new demands being placed on information system managers and developers alike. Although the basic tenets of Change management systems remain, they have been modified and expanded to meet the following demands: Much software development is no longer mainframe based. Client/server systems and standalone application development on personal computers and advanced workstations are common. A Change management systems must track systems on all of these platforms in a logical, unified way. Change management systems software products should be responsive to cross-platform and interplatform system development efforts. It should also support distributed workgroups on LANs. Software development is no longer restricted, as it once was, to third-generation Language or even to program versions. To be most useful, a Change management systems must accommodate such emerging technologies as Object-Oriented Programming in which repositories of objects may be stored in difficult-to-access libraries, Computer-Aided Software Engineering tools, text documents, spreadsheets, low-volatility data files, and graphic images and other large binary files. Programs have become more complex in terms of their components. A modern application is more than programming code. It may include modules in different languages, program-executable files, text files, graphic files, libraries of reusable code, and other supplementary modules. When new versions of an application are released, the system must be able to build a complete system regardless of the origin of its components, and the reconstruction of files means that all of the appropriate files must be identified and assembled. Many applications are being developed for a diversity of platforms. Consequently, multiple versions of the software must be processed in parallel development streams. A Change management systems therefore must go beyond serial version change monitoring to allow for version branching. Further, when changes made to one version are accepted, it may be desirable to integrate these changes with other versions. Crossversion merging is needed.

3 CMS software has become a commodity. Many Change management systems packages are sold at prices that are closer to those for personal computer products than for mainframe products. Often, Change management systems software is being integrated with other forms of software development tools, such as distribution management software to track who is using which version, defect management software to track what changes have to be made to which versions, and construction management software to assist in the automated reconstruction of complex applications in matched build sets. The process of testing and promotion of software in some companies has moved to multiple levels of approval. The Change management systems software should accommodate all required levels. Just as most applications are being written for newer, Graphical User Interface environments, so, too, has Change management systems software been moved into these environments. Change management systems software must be Graphical User Interface based, not just capable of tracking graphical user interface applications. ISO 9001 Standard for CMS "...mechanism for identifying, controlling and tracking the versions of each software item. In many cases earlier versions still in use must also be maintained and controlled. The system should: a) Identify uniquely the versions of each software item. b) Identify the versions of each software item which together constitute a specific version of a complete product. c) Control simultaneousy updating of a given software item by more than one person. d) Provide coordination for the updating of multiple products in one or more locations as required. e) Identify and track all actions and changes resulting from a change request, from initiation through release." Change Management System Control Objectives Ensuring the completeness and accuracy of data has always been a security administrator's primary objective. This objective should also include the control and integrity of the programs that process the data. In-house or vendor-supplied programs are vital assets. If an enterprise loses these resources, not only has it lost assets, it has lost its means of conducting business. An effective Change Management System is an essential resource for protecting both data and programs. Security administrators using a Change management systems must verify that the program changes are authorized, that only the authorized changes are made, and that unauthorized changes are detected or prevented. CMS standards have been recommended in the The Institute of Electrical and Electronics Engineers Standard , the Software Engineering Institute Standard SEI-92-TR-8, and the International Standards Organization Standard IS The International Standards Organization standard is typical of the three when it identifies the objectives of a Change management systems, as shown in Exhibit 1. Security administrators are also responsible for effective and efficient IS operations. A Change management systems centralizes and simplifies control of programs, and reduces storage requirements by using compression techniques and dynamic organization of files.

4 For efficiency in the use of secondary storage, base source code and changes (deltas) are saved, not complete copies. Two forms of change storage are in use: forward delta storage and reverse delta storage. In forward delta storage systems, a full base-level version is maintained and only changes (i.e., deletions, changes, additions) to the base version are stored for subsequent-level changes. To assemble the current version, the system begins with the last complete version and overlays the changes made since then. In a reverse delta storage system, a full copy of the most current version is stored, and previous versions are recreated by retrieving the changes needed to return to the earlier version. This feature allows multiple versions to be stored online without requiring extensive resources. Security Controls Provided by a Cms A comprehensive Change Management System provides the following controls: It ensures that new programs are developed following standard methods and that these programs contain current, clear, and comprehensive documentation. It prevents unauthorized access and changes to programs. It requires all new programs and program changes to be tested and documented before the software is put into production. It ensures that only authorized and fully tested programs are used in production. It ensures that the evolutionary changes in software are fully traceable. It provides status, progress, and exceptions reports to management, including design review minutes, test logs and records, and fault reports. It limits access to the Change management systems or to selected functions of the Change Management System. It locks files that are being revised. Change Management System Model A Change Management System is a set of manual or automated procedures that enforce secure, reviewable controls over program changes. A Change management systems restricts access to production source and object code, reduces the possibility that errors and design defects will be introduced into production, prevents the existence of multiple versions of source and object code programs in the Production Master File, improves quality and reliability of programs, increases security and control of program development and the change process, and enhances programmer productivity. A general model of a Change management systems is provided in Exhibit 2. The following sections describe the various components of an effective Change Management System.

5 A Change Management system Model The Librarian Function Facility The Librarian Function Facility is at the heart of the Change management systems. It is similar to any computer librarian function, serving security administrators, managers, and programmers equally. The librarian function facility (LFF) is a software package that centralizes, tracks, controls, and automates changes to programs against an approved Work Order. It also controls the implementation of newly developed or acquired programs. If a program that is already in production has to be changed, or if a new program is to be placed into production, it is logged out to the Test Master File. No changes are allowed in theproduction master file (PMF). Exhibit 3 shows this program promotion and release hierarchy. Program Promotion and Release Hierarchy The librarian function facility (LFF) controls the linkage between source and object code and automatically loads modules online for execution, thereby ensuring synchronization of the two codes. Comprehensive management reports and audit trails are available through screen display and hardcopy, for history, status, tracking, and performance information. All master file are backed up by the Librarian Function Facility to safeguard the system from disasters. Programmers have online access to the Change management systems to augment change productivity. Access privileges for programmers are controlled by passwords or biometric control devices. The Work Order A work order activates Change management systems activities. A typical work order form is shown in Exhibit 4. Sampe Work Order Form The work order should provide a clear description of the work requested. Programmers making change requests should enter their name, title, and the date of the request. A unique number should identify each Work Order. Priority indicates how quickly work should begin. Three examples of priority are: Emergency. Work for this priority begins immediately. Emergency priority usually means that the system has stopped operating. Urgent. Work for this priority interrupts the schedule and begins on the next available daily schedule. Urgent priority typically means that an existing problem might stop operations in the very near future. Routine. Work for this priority is placed on the next available weekly schedule. Routine priority typically means that a defective condition has been identified but will not stop operations or cause damage if corrected during the next one to four weeks.

6 The Quality Assurance Master File A Change management systems does not ensure high-quality programs; independent testing does. Quality assurance is never a substitute for quality control. Quality control is an error-prevention testing technique exercised while the program is in the test master file. Quality assurance is an error-removal technique that is employed in the quality assurance master file. Both processes help to ensure that only high-quality programs are promoted and released to the production master file (PMF). Where appropriate to organizational procedures, the system life cycle supported by the Change management systems should monitor changes in design, module testing, integration testing, quality assurance, alpha and beta testing, and promotion/release. A Change management systems may employ an independent quality assurance group. This group is independent of the maintenance programmer and reviews and tests programs before they are promoted and released to production. In addition to performing an array of tests, a chief function of this group is to conduct source code walkthroughs. In a source code walkthrough, the quality assurance group reviews the program code to verify that it matches change requests, design specifications, and standards. To discover coding errors or malfunctions, the group simulates how such code will be processed by the computer. A source code walkthrough is an important quality improvement technique and is an imperative step before promoting and releasing programs to production. The Production Master File Once a program enters the production master file (PMF), it is locked into production status and cannot be changed. With proper authorization, a program can be copied and logged into the test master file with a new name, and the copied version can be changed. This protective feature ensures that production programs will not be inadvertently changed. When management no longer wants a particular program in the production master file (PMF), the status is changed from enable to disable. This change in status does not delete the program from the production master file (PMF), but flags it for deletion. Only authorized managers, possibly requiring dual or triple authorization, can delete the disabled production program from theproduction master file (PMF). This feature supports program control, continuity, and housekeeping. The Backup Master File In the event that any master files is destroyed, the Change management systems permits IS personnel to recover from a Backup Master File any files or specific modules that may have been lost. A copy of the Backup Master File is usually maintained locally and another copy is stored off site in a secure location. Management Reports and Audit Trails The Change Management System reporting features help managers to develop an optimizedchange Management System and assist auditors in attesting to the integrity of the Change management systems. Both goals are discussed in the following sections. Optimized CMS An optimized Change management systems minimizes the sum of two costs: program change cost (i.e., change effort), including labor, material, and computer time; and operation cost due to downtime, inefficiency, or production of incorrect results. Exhibit 6 shows the relationship between change effort and operation cost.

7 Optimized CMS As change effort increases, operation cost decreases until the lowest combined cost is achieved. At this point, the goal of an optimized Change management systems has been accomplished. Change effort required beyond this point increases total cost and converts the Change management systems from a necessary, optimizing function to a necessary evil. To achieve an optimized Change management systems, the security administrator must receive such reports as: Comprehensive cost analyses. Number and types of program failures. Profiles of programmer performance. Types of changes made per program, language, and programmer. Average number of changes made per program, language, and programmer. Profiles of users making change requests and typical programs encountered. Average turnaround time per Work Order and calculations of mean time to change. Audit Trail and Source Code Comparison Audit trails are tracking mechanisms that can help security administrators ensure program change accountability. Tracking information in a Change management systems includes: History of all work order activity (e.g., the date of the work order, the programmer assignment, the changes made, and the date closed). History of log-ins and log-outs by programmers. History of program deletions. In addition to audit trails that track the disposition of work order, authorizations, and change activity, another powerful review information tool is a source code comparison, which compares the production source code in the Production Master File with copies of the authorized versions held by the auditor. The only differences between the two programs being compared should be authorized changes made to the production program since the last audit. Therefore, a source code comparison is extremely effective in identifying unauthorized changes made to programs. The source code comparison process is presented in Exhibit 7.

8 Flowchart of Source Code Comparison Effective Implementation of a Cms To effectively implement a Change Management System in any organization, senior management and the security administrator must introduce the concept to all users, examine the feasibility of the changeover, choose a project leader, identify and resolve key issues, evaluate the current procedures, establish parameters, select an appropriate Change management systems, and convert to the new system. An examination of these eight steps is provided in the following sections. Introduction of the CMS Concept Key personnel directly involved with the design, coding, test, and maintenance of production programs should be made aware by the security administrator and senior management of the concepts and goals of a Change management systems. Ultimately, these users, programmers, and designers will be responsible for the operation and administration of the Change Management System. The fears and concerns of the programming staff must be addressed by management because the Change management systems may impinge on the staff's perceptions of autonomy and self-worth and certainly will impose a structure that many programmers will find objectionable. Evaluation of the Feasibility of Implementing a CMS An evaluation by the security administrator and senior management of the feasibility of implementing a Change management systems must include consideration of: Technical factors. A vendor-supplied Change Management System is not necessarily compatible with all computing platforms. Economic factors. The cost of converting to a Change management systems can be as much as$100,000. Operational factors. Personnel must be trained to maintain and operatechange management systems. Schedule factors. Conversion to a Change management systems must be based on a well-planned and workable schedule. These factors are integral to a well-planned conversion to a Change management systems and must be investigated thoroughly by the security administrator and senior management. Selection of CMS Project Leader The development and implementation of a Change management systems is similar to any systems project and requires that senior management select a project leader and team members. The project leader should be skilled in systems programming to be able to resolve low-level programming problems related to the system installation, the creation of skeletonjob Control Language code, and the resolution of compilation problems. The project leader will also be responsible for ensuring the involvement of affected personnel, the implementation of plans and schedules, and the decisions and actions taken in regard to the project. Identification and Resolution of Key Issues

9 A complete understanding of the operation of the Change management systems should be established by the project leader and team. Any problems, inconsistencies, barriers, and issues should be resolved by all the involved parties. Among the decisions to be made will be: The number of master production file libraries. The number of staging libraries between submission and release to production. The number of program versions to be retained. The requirements for documentation. The authorizations to allow programs to move between libraries. The evaluation process to review all change requests and status reports. The authorization of personnel to log in and log out of each library. The acceptable standards for testing and documentation. The number, type, and content of management-oriented status reports, change-control logs, and change schedules. Evaluation of Current Procedures This step provides managers an opportunity to examine the current procedures and weed out deficiencies. By thoroughly inspecting what does or does not work, managers can establish standard systems development methodologies, implement Computer-Aided Software Engineering techniques, set documentation standards, institute naming conventions, enact coding and testing procedures, and ensure sound review and approval processes. Establishment of Parameters The Change management systems project leader and team should compile an inventory of programs (either in development or in production), decide which of these must be converted to the Change management systems, and establish a timetable for this conversion. At this time, specific personnel responsibilities should be assigned and authorization privileges established. Selection of a CMS The choice of a Change management systems by senior management should be based on the Change Management System team research and findings. It should be consistent with the IS organization and the methods of change management established in the previous steps. Although an IS shop can build its own Change management systems, most IS managers will choose one of the commercial Change management systems vendors because a commercial Change management systems is generally more sophisticated than one developed in-house, and has been tested and validated by many users. Also, in a commercial Change Management System most change management methods are standardized and relatively easy to learn. A partial listing of vendors of commercialchange management systems products is shown in Exhibit 8.

10 A Partial Listing of Commercial CMS Vendors Burton Systems Software Computer Associates International, Inc. Intersolv, Inc. Legent Corp. Mortice Kerns Systems Optima Corp. Softool Corp. Burton Systems Software Computer Associates International, Inc. Intersolv, Inc. Legent Corp. Mortice Kerns Systems Optima Corp. Softool Corp. Conversion to the CMS The schedule for conversion should allow enough time for all management systems and callable modules to be entered in the Change management systems. Managers may choose to subdivide their systems into several major functional categories and this will take extra time. It is important that all appropriate personnel receive sufficient training in implementing, using, and managing the system before the conversion process starts. Before selecting a conversion technique, the Change management systems project team should examine each method for advantages or drawbacks. The four conversion techniques (shown in Exhibit 9) are: Direct conversion. This is the implementation of the new Change management systems and the immediate termination of the old system. This approach should be chosen when the old system is judged to have no value and the new system is either very small or simple. The primary advantage of this technique is that it is relatively inexpensive; the primary disadvantage is that it involves a high risk of failure. When direct conversion is chosen, the testing methods and quality assurance activities discussed earlier become vital. Parallel conversion. This approach enables both old and new systems to operate simultaneously for a period of time. The advantage of this technique is that it provides a high degree of protection to the organization from a failure in the new system. The disadvantages are the costs associated with duplicating facilities and personnel to maintain dual systems. Phase-in conversion. In this process, the Change management systems is implemented over a period of time, gradually replacing the old methods. It avoids the risk of direct conversion and provides ample time for users to assimilate the changes. Pilot conversion. With this conversion approach, one or two programs are chosen for implementation to test the Change management systems. Before the entire system is converted to the new Change management systems, it must prove worthwhile. In addition to serving as a test, the pilot Change management systems can be used to train users throughout the organization before the Change management systems is fully implemented. Conversion Techniques Both phase-in and pilot conversion approaches have the advantages of building confidence and experience for the users and credibility for the Change management systems. They also provide an opportunity to correct deficiencies before further

11 conversion. The disadvantage in either of these two conversion processes is the extended length of time for implementation. The project team should keep in mind that no matter which conversion approach is used direct, parallel, phase-in, or pilot programs are first placed in the Test Master File, then promoted and released to the Quality Assurance Master File, and, finally, promoted and released to the Production Master File. Timing is also an important conversion consideration. For example, the best time to convert accounting programs to a Change management systems is immediately after yearend closing. Recommended Course of Action A Change Management System is a system that centralizes, controls, tracks, and simplifies the development and maintenance of commuting resources. Implementation of a Change management systems, despite its cost and organizational demands, delivers such benefits as: More effective and efficient management of IS resources. Better audit trails. Clearer separation of responsibilities. Avoidance of loss of changes. Improvement in programmer productivity. Synchronization of source and object code. Ability to back out of changes if necessary. Enforcement of quality assurancestandards. Improvement in auditing, security, and control. Upgraded management reporting and review. Better priority setting. A Change management systems can be of considerable value to the security administrator, whose tasks are generally expected to include such activities as: Reviewing controls. Assisting in the development of controls. Testing compliance with controls. Evaluating systems performance. The decision to acquire a Change management systems must be unequivocal. A lack of support for all aspects of the conversion to this system may leave its implementation vulnerable to sabotage.

12 Bibliography Intersolv. Choosing a Software Configuration Management Tool for Client/Server Development. Rockville MD: Intersolv Corp., Marek, B. Librarian Change Control Facility: Source Management for the 1990s and Beyond. Phoenix: Computer Associates International, Inc., March Mortice Kern Systems, Inc. White Paper on ISO Waterloo, Ontario: Mortice Kern Systems, Author Biographies John G. Burch John G. Burch, PhD, is professor of accounting and computer information systems at the University of Nevada, Reno. He is the author of Systems Analysis, Design and Implementation, Boyd & Fraser, Boston, 1992, and is the coauthor of Information Systems: Theory & Practice, John Wiley, New York, Fritz H. Grupe Fritz H. Grupe, EdD, is assistant professor of computer information systems at the University of Nevada, Reno. His research interests are in expert systems, geographic information systems, and computer center management.

13

14

15

16

17

18

19