Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
2 SYSTEMS MODERNIZATION JUST PAST In this chapter we provide an assessment of the System Mociernization Plan (SMP) and its current status and examine the software engineering methods that were adopted by the Social Security Administration (SSA) as part of its modernization efforts. In addition to providing our assessment of the use and success of these methods within the agency, we also offer suggestions for their improvement anti identify promising new clevelopments. Systems modernization shouts! be viewed as a continuous process rather than a distinct program. In the 1960s the SSA was seen as a model of effective data processing, but for many years that follower! the SSA neglecter! its information systems infrastructure until it was near collapse. In 1982 drastic measures were required to restore the agency's systems and a comprehensive plan to accomplish this was undertaken with the approval of Congress. That plan was called the SMP. Today, 7 years after the SMP was initiated, the general structure of SSA's systems is derived from an architecture that was conceived and oriented toward conventional batch processing. An essential requirement for the SSA,s computer operations is the maintenance and protection of its database, which includes earnings and benefits information. Through its 25,500 computer terminals, the SSA has extended its remote job-entry operations and now supports on-line queries and claims entry. The agency plans to increase its on-line operation. In just the past 2 years the agency has gone from 4,000 terminals to 25,500. In addition, terminal inquiries resulting from the new teleservice center operations will further increase processing demands and stress the current network and host capacities. On-line transaction volumes are up from 1.5 million per day a year ago to 7 million per day now. These aggressive moves aimed at expanding and improving service to the SSA's clients require equally aggressive technology investments in data processing capacity and communications in order to ensure performance and maintain the stability of those systems. THE SYSTEMS MODERNIZATION PLAN The original plan, as conceived in 1982, consisted of three phases: survival, transition, and state of the art. The survival phase targeted and resolved the most critical problems that then confronted the agency. Following survival, a transition phase was entered that introduced long-range goals into the modernization projects and initiated systems redesign. Completion of these phases would then position the SSA to implement and maintain modern, efficient 13
14 information systems--a continuing phase referred to as state of the art. The SMP was further defined and broken down into six major programs: (1) institutionalize software engineering methods' (2) integrate the agency databases, (3) establish a data communications network, (4) increase data processing capacity, (5) improve the management of the SSA's computer operations, and (6) provide administrative and management information. Figure 2.1 was taken from the original SMP (U.S. Department of Health and Human Services, 1982) to illustrate how the SSA approached modernization, the relationship between the projects and phases, what was intended to be accomplished, and in what time frame. Prior Study In addition to the briefings and documents provided by the SSA, we also examined the reports of two earlier committees of the National Research Council that reviewed the SSA's data management system (National Research Council, 1978 and 1979~. For the period prior to these reports the agency had been criticized for its apparent inability to handle claims and payments. A planning effort initiated in June 1975 addressed those criticisms by proposing a transition from an antiquated tape-based processing system to one that used random access storage and a database system that was commercially available and vendor supported. Such programming systems and components would ensure that the functions performed by the SSA could migrate to newer systems, thus providing some protection from technical obsolescence. The envisioned improvements were aimed at the accuracy, promptness, reliability, and responsiveness of the SSA's service delivery system. The referenced reports thoroughly explored the architectural and planning aspects of that effort. The recommendations in these reports were satisfactorily addressed in the 1982 plan. The SSA has implemented a disk oriented random access database architecture and has adopted the controls and process steps needed to further enhance those systems. Modernization's Effects From a functional standpoint the SSA has been able to keep up with the expansion and growth in its client-based transaction volumes as a result of its automation steps. Through its modernization investments the SSA has also been able to improve operational efficiency and provide more responsive services to its customers during a period of significant downsizing. The following achievements, while not an exhaustive list, provide examples of the progress that has resulted from modernization: Retirement payment accuracy, in which fiscal year 1983 was 99.5 percent, by fiscal year 1988 had improved to 99.S percent--a 60 percent improvement in the error rate. Wage posting, which exhibited a 4-year backlog in 1982, has been brought up to date and is now accomplished within 5 months. Enforcement operations, which carried a 5-year backlog in 1982, have been brought up to date and are now current.
SURVIVAL SOFTWARE ENGINEERING DATA BASE INTEGRATION DATA COMMUNICATIONS UTILITY Software Improved and Under Control Tape Dependency Reduced Message Backlog Eliminated and Reliability Increased CAPACITY Equipment Expanded UPGRADE Reconfigured and Workload Capacity Requirements Met 18 Months 18 Months 15 TECHNICAL APPROACH TO MODERNIZATION TRANSITION STATE OF THE ART Software Salvaged New Benefit Payment and Redesigned System Implemented . r Master Files Data Base Management Converted to Disk Implemented . Equipment Upgrade and Local Intelligence Installed Data Communieations Utility Implemented 1 Advanced System Architecture Installed 24 Months / \ \ FIGURE 2.! Technical approach to modernization. Social Security Administration (1982) >
16 · Annual recomputations, which required a 48-month period to process in 1982, are now accomplished in 9 months. · Cost-of-living allowance calculations, which required 2 to 5 weeks to process in 1982, are now available in 36 hours. New or replacement social security cards, which took 6 weeks to issue in 1982, are now issued in 6 to 10 working days. . Over the period 1982 to 1988 the benefits of automation on the productivity of the agency were observed in a number of areas. While the regional workload increased 12.4 percent over the period, the agency was able to reduce the labor input by 20 percent, resulting in a 40 percent overall productivity improvement in regional operations. At the same time the automation investments have resulted in savings to the agency because of increased payment accuracy that reduces overpayments and underpayments. During the period 1985 to 1988, this resulted" in savings of $980 million. Total agency employment, which was the equivalent of 81,532 full-time employees in 1984, decreased to 66,000 at the end of fiscal year 1988. This downsizing was made possible as a result of the SSA's investments in information technology. The capital investment in millions of dollars made by the agency for information technology for the years 1982 through 1989 is shown in Table 2-1. Table 2-1 Capital Investment by Category and Year, 1982-1989 (in millions of dollars) Year 1982 1983' 1984 1985 1986 1987 1988 1989 Total Office Automation Operations Administrative ADP Equipment Voice Management and Data Telenhone Inf ormation Communications SMP n/a 10 [.1 8.5 n/a 93.3 ' ' 30.8 6.9 72.1 47.1 2.4 13.3 56.0 58.4 27.2 14.6 46.5 98.6 66.1 23.7 52.0 72.9 117.6 32.2 32.6 73.8 83.7 35.9 105.7 Total 112.6 124.1 126.1 130.1 186.9 214.7 256.2 225.3 1376.0 For recent years, we suggest that SSA combine its automation expenditures and other related internal and external costs and normalize these costs on a per transaction or per account basis. Parameters such as cost per transaction or cost per account are useful as one measure in evaluating automation investments made and intended. Such normalized costs also provide useful management information when compared to other organizations or trended in concert with service levels provided to SSA's customers.
17 The Crisis Survived In light of these and other data we have reviewed, the SSA did survive the crisis faced in 1982 by its information systems. This came about as a result of major efforts proposed and executed under the SMP and the associated management and fiscal investments in information systems made since 1982. The agency has successfully managed to move its main data bases off of hundreds of thousands of magnetic tapes and onto contemporary magnetic disks. This was a major information system transition and a significant achievement that now allows the agency to quickly access information and positions it for supporting on-line operations. Now, the agency must manage its next major transition from strictly paper-based processes at the district offices and batch computer operations to the use of on-line terminals--a significantly greater challenge. The Transition to On-line Services The transition phase was entered operationally with the introduction of the 1987 SMP (U.S Department of Health and Human Services, 1986~. The transition phase introduced automation and productivity tools to the tasks of the SSA's workers. Productivity measurement and advanced telecommunication technology have been introduced into the agency processes. Such capabilities provide for first point of contact data capture and help eliminate paper as the primary interface to the automation system. This phase is well under way and is critical to the ability of the SSA to establish a technology base for the development of intelligent systems that the SSA should plan to exploit over time and incorporate in its vision of the future. Effects of the transition phase are beginning to become evident from several perspectives. The agency's automation investments have grown substantially, but now new factors related to the increase in automation and the consequences of its interruption begin to come into focus. For example: . · Loss of the NCC will severely reduce the SSA's ability to provide expected services to clients. Only emergency services such as locally issued checks would be feasible. As dependence on automation increases, employees' knowledge of details is incorporated in computer programs and this reduces their ability to respond to client's manually. Thus, the SSA increasingly will become less able to revert to manual methods. · System stability and the ability to quickly restore service in the event of a failure has become critical. This implies the need for crisis planning, database support and operational support in the event of a disaster. · Wider access to proprietary information requires that protective steps be taken to prevent misuse or damage to data or violation of privacy. While we support the SSA's transition to on-line services, we believe that any organization having limited experience with true on-line operations tends to underestimate the resources
18 it will require. This suggests the advisability of introducing new services in a deliberate and measured manner that is supported by well-planned and approved steps to increase the agency's information systems infrastructure along with the development and training of its work force. For example, sufficient processing capacity needs to be assured before introducing a new on-line application or procedure. A management infrastructure must be in place that establishes and communicates quantitative service-level goals while ensuring that developments are geared toward those goals and the capacity to execute them is provided. However, such an approach does not always satisfy the timetable of a top management whose short tenure will tend to prioritize actions that show near-term results. Furthermore, on-line operations require more processing power and better backup and recovery services, and, unlike batch operations, peaks of demand cannot be smoothed out over long periods of time. Such peaks can cause terminal transactions to be queued, resulting in inefficiencies and dissatisfaction. State of the Art The unflagging advance of information technology constantly redefines the state of the art. In the context of the SSA,s SMP, this phase is one in which the agency is able to incrementally modernize its systems and avoid crisis situations. In this sense the state-of- the-art phase does not have a distinct conclusion. Its achievement may be always elusive and certainly defies verification. Just as the state-of-the-art phase was intended to represent the long-range goals of the SMP, the Agency Strategic Plan (ASP) constitutes SSA's current plans for the future and embodies long-range goals for the agency's modernization. The ASP, therefore, is the continuation of the SSA's technical modernization efforts, and its introduction marks the conclusion of the SMP. Status of the Systems Modernization Plan Since the SMP was initiated, the SSA has replaced an obsolete computer architecture, expanded its computer capacity eightfold, substituted on-line storage for magnetic tape, established a disciplined approach to software development and project management, centralized its master files and implemented database management, installed 25,500 computer terminals, acquired a data communications network, and modernized its claims processing system. We conclude that the major goals of the System Modernization Plan have been successfully achieved. By 1982 the SSA,s batch system environment was out of control and not able to handle its workload as backlogs grew and downtime averaged 11 percent. The potential for crisis was apparent. The agency underwent a recovery period from 1982 to 1987 in which it regained control of its batch processing environment and began to develop its real-time data access and management strategy. As a result of its recovery, the agency found that after 1987 it could
19 begin planning for its future rather than concentrating on day-to-day problems and survival. This period set the stage for the SSA,s first strategic plan. The ASP provided an opportunity for the agency to clarify how it intends to carry out its mission. In this new period of modernization guided by the ASP, the SSA's strategy calls for the agency to increase its real- time access and management of data, including real-time client query, real-time data entry, and some on-line application development and testing (e.g., enumeration). SOFTWARE ENGINEERING METHODS One of the major objectives of the SMP was to install modern software engineering methods at the SSA, and one of our tasks was to review the software engineering methods being used by the agency and assess their adequacy. To accomplish its objective for a modern software engineering environment, the SSA, during the past several years, has embraced a development methodology referred to as software engineering technology (SET). The SET (Social Security Administration, 1986) is defined as the process by which all new systems and software are developed and existing systems are maintained. This methodology appropriately begins at the planning stage of the development life cycle, continues with requirements definition and analysis, design, development, implementation, integration, testing, and finally operation and postimplementation support. The SET appropriately addresses the use of tools, configuration management, quality assurance, security, capacity planning, and management. Given a vision of how to operate the agency, an effective development method for large software efforts such as the processes that the SSA requires must include the following three basic interlinked elements: 1. A formal requirement, design, development, and implementation methodology that is well documented and enforced across the systems and software organizations. 2. A comprehensive set of tools, preferably embedded in an integrated environment, consistent with and supporting the methodology; to the extent possible, providing integrated automated support across the entire development cycle and subsequent life-cycle support. 3. Training, both in the form of initial staff training on the methodology and use of the tools and continued training of incumbent staff as the methodologies are refined and the tools enhanced and upgraded. All three of these elements need to be employed in harmony in order to achieve optimum software development results. In addition, inherent within the methodology and management infrastructure for software development, there must be (1) rigorous and effective project management techniques supported by comparably disciplined quality assurance and (2) configuration management backed by well-documented and enforced~policy, plans, and procedures. Quality assurance, program management, and configuration management elements must report above or separately from the organization responsible for software development, testing, and operation. In the following sections we address each of the five key aspects of an effective software engineering infrastructure from the perspective of the SSA's status and accomplishments to date. These are methodology, tools, training, project management, and quality assurance and configuration management.
20 Methodology Version 1.0 of the SET was completed in 1984. It was then substantially enhanced through the acquisition and incorporation of a structured system development methodology. A major upgrade to the SET (version 2.0) was released in 1986. After that there were several interim upgrades in 1987 and 1988. The latest version 3.0 of the SET, dated July 1989, was released in August 1989. The SET is quite comprehensive and documented in great detail in a six-volume manual (about 6,000 pages). In September 1987 a condensed version consisting of about 300 pages and called the Desk Top SET (Social Security Administration, 1987) was issued to provide a much needed overview of both the SET manual and the prescribed life- cycle development stages. The Desk Top SET also provides a quick reference and index to the information contained in the more comprehensive manual. The SSA's practices incorporate many principles considered requisite to successful system and software development, including direct participation of users throughout the development life cycle and system validation performed by the same staff that developed the requirements. The SET suffers from having the appearance of being a compendium of ~everv~hin~. relevant to software development in the SSA. ~ . ~ ~ ~ ~ ~ ~ . It includes structured methodologies popularized by Youroon and Jackson as well as nonprocedural methods. It also provides a detailed tutorial on flow chart techniques that really should have been superseded long-ago by the structured techniques and modern computer-aided software engineering (CASE) tools. In addition, multiple sections are devoted to many extremely low level utility routines that are characterized as tools but are a wide variety of material better suited to a policy and procedures manual. The SET should provide more guidance to direct the user toward a specific technique for particular applications or application types. For example, it should advise the user when to use Yourdon or Jackson or nonprocedural design. To improve its effectiveness, we suggest that the SET manual should focus on the appropriate and current methodologies and their supporting tools. Obsolete materials, procedures, and policy items must be removed or, if still necessary, transferred to other kinds of documents. A 50 or so page summary manual could overview the entire methodology and reference other stand-alone volumes for more details on the specifics of the recommended approach or technique. A comprehensive, full-life cycle example and several smaller examples should be included to illustrate the various processes and techniques. An improved tool kit must also be incorporated into the SET. Given that the present form of SET methodology has been in place for about 3 years, there is a definite need for the SSA to initiate a formal "metrics program" to collect productivity data on all system and software development projects. This will permit ongoing assessment of the effectiveness of new methodologies and tools as they are introduced; but even more importantly, it will provide the quantitative basis for making more accurate schedule and resource estimates of future development efforts. To be most meaningful, appropriate quantitative measures of productivity must be collected throughout the development process, preferably at the conclusion of each staled rather than being "retroestimated~ at the conclusion of the project. A designated group, not necessarily a new organizational component, within the SSA should have the responsibility for remaining current on modern system and software development tools, techniques and methodologies, and evaluating their suitability for the SSA environment. Such a group would also sponsor, perhaps in conjunction with the systems development organization, pilot applications of tools and methods that are most likely to ~ , ~ O
21 benefit the SSA. The group should focus on the development process rather than on products produced by the process. This group can also be the custodian and evaluation organization charged with administration of the Metrics program. discussed above. Finally' in the area of methodology we suggest that the SSA monitor the activities of the Software Engineering Institute at Carnegie Mellon University. Even though the focus of the institute is on assessing and improving software development practices for the U.S. Department of Defense, it is concerned with all of the above issues and has both government anti industrial sponsorship and support. Tools The SET manual has primarily identified a tool set of very modest capability. The many powerful CASE tools now beginning to appear on the market are not discussed in the manual. However, the SSA did have the foresight to begin~applying the problem statement lan£ua~e/Droblem statement analyzer (PSL/PSA) too} to the requirements analysis efforts in the mlO-lV6()s and has continued to use It tor sot tware Development et torts. The current proliferation of CASE tools, integrated development environments, and their expansion to highly desired full life-cycle coverage, which is expected to be mandatory for such tools in the future, means that the SSA must not only stay abreast of this dynamic area but must also aggressively incorporate any tools selected for new capability into an unimproved SETH but still constraining it to ~ manageable size. New tools can well be evaluated on small noncritical pilot applications initially, preferably by a team of developers enthusiastic about this type of technology. Short-term benefits will likely come from improved quality and uniformity of application programming. Productivity improvements will come in the longer term, initially in the maintenance areas and then in the development areas. In the next 5 years we anticipate significant improvements in the power and breadth of capability of the tools that become available in the commercial marketplace. Therefore, it would be a mistake for the SSA to ~freeze" on a too} such as PSL/PSA; there are already improved derivatives that can be used with minimum transitional difficulty. The SSA operates in the International Business Machines (IBM) database environment, which fortuitously is the target of the majority of todays tools, in that the too} Platform itself may be either an IBM mainframe or workstation. A comprehensive and integrated CASE tool set may not be available for several years. Even so, the SSA need not wait to take advantage of today's tools. The agency should expose its development organization to a variety of applicable tools so that it will have the experience to know what works and what does not in its environment using in-house methodology. In so doing the agency can gain the benefits from immediate usage and be in a position to quickly capitalize on the frights tool set when it emerges. The SSA should also examine the so-called reengineering tools that are beginning to appear. They are focused primarily on the life-cycle support phase. Fortuitously again, most of them work in the IBM database environment. Since 50 to 80 percent of the software life- cycle cost for a production system occurs during the operational/maintenance phase, the payoff for productivity enhancements in this portion of the life cycle is substantial, considering the millions of lines of code in existing applications. One example of a life- cycle-support too! is a Common Business Oriented Language Structuring Facility (COBOL SF) restructuring tool that is intended to increase the span of code that a programmer can
22 maintain by a factor of about two--a doubling of productivity. As different systems are processed through COBOL SF, a side benefit is that the COBOL II code produced appears very similar to the original, which allows programmers to be moved from one system to another with relative ease because little effort is required on their part to gain familiarity with the new system. In addition, COBOL II output of the COBOL SF system has the attributes of a well-structured program (e.g., single-entry/single-e~cit procedures, no GO-TO or external PERFORM statements). Furthermore, it is linear and extremely straightforward in its logical structure and executes with little or no performance penalty compared to the original difficult-to-maintain COBOL source code. This tool can also be effectively used as a standards checker. If a programmer's work is modified as a result of running it through COBOL SF, this is an indication that it has not been developed according to proper well-structured programming practices. We expect that well within the next decade such capabilities as outlined for COBOL SF will be incorporated into much more comprehensive integrated tool sets that will cover the development life cycle from requirements analysis through maintenance. Training Both training and subsequent retraining performed by the SSA for its systems staff are very comprehensive and consistent with the high level of training apparent across the entire SSA. New hires in the systems organization are given an 8-week training program that includes both formal classroom and hands-on activities, followed by an on-the-job component. A training profile for each individual is developed and maintained in the Employee Training History and the Systems Training Data System. Four levels of training are provided for software staff: core, foundation, advanced, and expert. Core training is further partitioned into one of the following areas: analysis/design, software support, operations, and hybrid (other). The SSA has clearly made a commitment to training and is willing to make the continuing training investment required to develop and maintain a first-class staff. Project Management An SSA development project is managed by a project manager who heads a small project management office (PMO). By the nature of its function, specific tasks follow a matrix approach in which the assignments are carried out in separate organizations by technical staff under the direction of a line supervisor. The evidence is that the PMO performs good and effective planning and tracking at the top (task) level of the project but that there is no detailed subtask management. The project manager and PMO focus tends to be almost exclusively short range. There is little detailed subtask management by the PMO. Since each task is usually composed of many dozens or even hundreds of subtasks, there is little visibility of the current status of the project at the lower subtask levels at the PMO level that depends on the line managers and supervisors to stay on top of the many tasks to be performed for their projects and the other projects competing for the same resources. However, line managers and supervisors have no formal task breakdown and tracking system at the detailed levels.
23 Wo suggest that thc SSA use work breakdown s1ructurcs to ald ln davoloplng sufFlclcntly granular task ststcmcats for closer monltorlog pr ststus. Otber 1echnlques thst tbe agency sbould consldcr laclude carocd value or tbe cost/scbedulc control system crlterls tc/scsc~ thst thc u.s. Dcp~rtmcat of Defcase {DOD) commonly uses to plan, mossure, and monitor Ds hl~h-rlsk projects.] Wc su~gest that u[~-cyclc cost estimates be produced pclor to projoct 1~111stlon as ~ basis for dcclslon making and thcrcofter bc rc~lnod as the development process proceeds. Bsscd on our obscrvatlons, the currcat process calb only for lacrcmenta1 estlmatos of each stop as thc full dovclopecat cycle proc@eds. Hanco, ~ appears that the projec1 ls completed before thc [ull cost ls vlslblc to declslon mskcr~ We recogolzc thst the precise cost cannot be known untH projec1 complctlon but sugg@st 1hat llfc-cycle cost estlmstes tha1 arc updated tbrougbout thc dcvolopecat process wlu sllow bcticr managomcat vlslblUty and control ^n cvaluatlon Of "fc-cyclc cost and sssoclstcd bcnoflts should bc the basis on ~blcb to autborlze, 1rack, and msnegc osch project Updstos to such cost-bcneflt analyses producod a1 1he end of cscb stago sad anslysls of varlanccs from tbe orlgloa1 assessmen1 sbould bc 1he basis of dcclsions 10 prococd to thc oc~t sto~c or to modify tbe plan. Even 1n tbe case ~bore s developmen1 ls ncccssltatod by lcglslated sctlon, cos1-offcctlvaness analyses can be belpful to select ~ good sltcrnatlve dpproacb and 10 casure 1ba1 requlrcments growtb does not peter tbc development pr~cs~ Ov"1~y Ass"~"ace "nd Co~figur"1~on hlen.gemen1 Ibc ~fc-cyclc development matbodology ceployed by tbe SSA descclbes 37 dlffercat products tbat arc producod by various organlzatlons durlug tbe development proces~ Ibese products consist of plans, analyses, requlrement~ speclflcatlons, report~ scbedules, sad otber defined document~ For this process tbe qual~y assurance (QA) foca1 polat ls tbe Offlce of Stratcglc Planalng and Integratlon. ^dbercace to Q^ standards ls rovlewcd by tbe orl~lasilog organlzatlon for eacb SE1 product a~d functlona1 qual~y and tecbolca1 qual~y are assessed by eacb orginlzatlon tbat receives an SE1 producL lbe SET msnua1 descclbes tbe functions sad rcsponslblutles of tbe Q^ elemcat for tbe various stages. Ibcrc ls s ~ldc varlatlon 1n the type of review required. In many lnsts~ccs tbe more tradldone1 assessment of adberence to standards and procedures ls requlrcd. In otber last"nccs tbe Q^ mlsslon as dcflned ln tbe SE1 manua1 calb for tbe evaluation or assessmcat of thc corrcctocs~ consistency, and complctcness of tbe producL Sucb evaluations requlrc senior c~perlcaced tecbalcal stsff and ln other orgsalza110ns arc typically done by s vcrlflcatlon and valldatlon (V&V) organlzailon rstber ths" tbe trsdldona1 QA group. lbe SS^ sbould modify tbe rcsponslblutles of ds QA func110n and sdopt ~ nc~ V&V func110n, cqulpplng lt wltb tbe appropclate cbsrter, 1001~ and organlzatlonsl 1ndependence from tbe development organlzatlon. It ~ common for a QA function to report to 1bc bighost level of s" organiZs110n. Strlklngly, we dld no1 find this 10 bc 1he csse st 1be SSA. Tho sblH1y of 1he SS^ 10 porform 1 Tbe DOD slso offers ~ comprebenslvc 6-monib 1~1~1ng program a1 1ts Project ^nagement Institutc Oocsted 81 Fort Belvoir, V1rg1~1~, ~bich tho SSA sbould consider using 10 gain tbe invaluable sad hard-won c~poricncc of 1he DOD; ~ appl1os dlrec11y 10 tho SSA system sad soft~sre developmcat.
24 ~ ~ ~ A , ~ _ ~ . Ha. _ , _ . . .. . . its mission in an effective and efficient manner is becoming increasingly dependent on access to adequate high-quality software, hardware, and training. Given that the SSA relies on its ELI [W~I~ bybL~mb [U accomp~lsn lIS mission, commissioner-level focus and backing are appropriate for enforcement of QA policy and standards within the agency. Configuration management (CM) and change control are appropriately focused and accomplished through two tiers of configuration control boards (CCBs). The higher-tier CCB operates at the deputy commissioner level and selects nrn~ect~ for review h~c'.A run O'7- OnA importance. Procedures call for further reviews at lower management levels with configuration management offices to support them. Requirements for an automated CM document tracking and control system have been developed but have not yet been implemented. Such a system can provide an effective means to track the documents placed under configuration control. Once the system is implemented, it should be expanded to automate document traceability from requirements, through design, and on to the implementation of software modules. This capability will help the SSA assess the effects of a change to its systems and should also help ensure that software changes are appropriately documented. The SSA should also place its test files, test databases, test scripts, and test results under change control and configuration management with the eventual objective of possibly automating the testing process. ~ _ ~ ~ . ~ , ~ ~ ~ _ ~ ~ ~ ~ ~ ~ _ ~ ~ ~ REFERENCES National Research Council. 1978. Review of a New Data Management System for the Social Security Administration. Washington, D.C.: National Academy Press. National Research Council. 1979. Second Review of a New Data Management System for the Social Security Administration. Washington, D.C.: National Academy Press. Social Securitv Arlminictr~tinn O~t~hPr 1OS2~ .~OtD~O If; D1~ ~ ~ 1 ~ ^~. ___ ~V. ~-V~~~rl ·O ~~v~c/ ~~~ ~ U~I~II rlun ... 1987. On-Line with the Future. ottlce or systems, Baltimore, Maryland. SSA Pub. No. 40-004. Social Security Administration. September 1987. Desk Top SET. Washington, D.C.: Office of Strategic Planning and Integration, Systems Engineering Staff. U.S. Department of Health and Human Services. February 1982. Systems Modernization Plan--From Survival to State of the Art. Washington, D.C.: Social Security Administration. U.S. Department of Health and Human Services. 1986. Software Engineering Technology (SET) Manual. SSA Pub. No. 41-006. Washington, D.C.: Social Security Administration, Office of Systems.
