In the proposal, USAC required that interested cities:

1.

2.

3.

4.

Form a consortium of organizations which would bring together the various fields of knowledge required to design and develop the system. (USAC suggested a city, a computer software company, and a university as the basic organizations.)

Build upon the existing municipal operations so that the resulting system would be truly operationally based and economically justified.

Design the system for a single municipal jurisdiction, while striving for a high degree of transferability of system components to other municipalities or regional environments.

Document the processes and products of the system to assist in the evaluation of the project and to promote systems transferability among municipalities without extensive additional efforts.

Interested cities were also required: (1) to provide reasonable assurance of having significant portions of the system operational at the end of the three-year period; (2) to develop a plan which encouraged continuation of the system after project completion; and (3) to participate in information exchanges with other projects and with USAC.

1.3 The Charlotte Project

Responding to the USAC request, the City of Charlotte formed a Consortium with System Development Corporation (SDC) and the University of North Carolina (UNC) and proposed to develop within the City a comprehensive or integrated municipal information system (IMIS).

Seventy-nine cities competed for the USAC contracts. Charlotte and Wichita Falls, Texas were successful in bidding for the total integrated information systems contracts; Dayton, Ohio; Reading, Pennsylvania; St. Paul Minnesota; and Long Beach, California were awarded subsystem contracts for the Public Finance, Physical and Economic Development, Human Resource Development, and Public Safety subsystems, respectively.

The City of Charlotte contract with HUD was negotiated in March, 1970, and provided for three years of supported research and development effort. This contract is being renegotiated to extend through June, 1975.

3.

SYSTEM BUILDING METHODOLOGY AND ORGANIZATION

3.1

Basic Philosophy

The basic philosophy of the Charlotte Consortium's approach to building an IMIS is embodied in three major considerations:

the mutual concern of USAC and Charlotte for transferability;

the mutual concern that the system designed and developed be truly integrated; and

a concern for developing a modular approach that addresses the problem of automating municipal operations and integrating them into an existing system.

These three considerations and their specific effects on the Charlotte Consortium's approach are discussed in the following paragraphs.

3.1.1 Transferability

One of USAC's primary concerns is the transferability of the products of USAC project cities to non-USAC cities. It is the purpose of the USAC program not only to test the validity of operations-based Integrated Municipal Information Systems, but to determine the means by which other cities can implement these systems within the framework of their financial resources and their politica! and administrative environments.

The modular approach to system construction, proposed in the USAC RFP and adopted by the Charlotte Consortium, is illustrated in Figure 1. Using such an approach, the "total" system is addressed during the Analysis and Conceptualization tasks and subdivided into modules for the remaining project tasks.

The modular approach to system building raises several questions specific to transferability. Those addressed by the Charlotte Consortium include the following:

Which of the project task products will be most useful to non-USAC cities in determining their interest and capabilities with regard to an Integrated Municipal Information System?

To what degree will cities be interested in the products of the tasks completed prior to those considered most significant?

To what degree will cities have to adapt the products of the USAC cities to their own environments?

After serious consideration, the staff of the Charlotte Consortium concluded that the documents that would initially be of most interest to non-USAC cities would be design documents. Although there would probably be some use of analysis and conceptualization products, the actual decision to move in the direction of an operations-based IMIS would be made on the basis of either seeing or reading about operational elements (modules) of an IMIS. These operational elements are best described by the design documents. This conclusion led the Charlotte Consortium to place a major emphasis on the content, structure and format of Module Design Specifications, the key documents of Charlotte's design task.

Several other factors influenced the Charlotte Consortium's effort to make these Module Design Specifications a key contributor towards transferability. First is the important difference between operations-based integrated systems and the more traditional "job" or "application" oriented approach. In the job oriented approach, the major interaction in determining the growth and direction of EDP in a municipality is between the EDP manager or his programming staff and the individual users within a municipal department. In operations-based integrated systems, however, more users become involved and departmental lines are crossed. Public administrators, therefore, including city and county managers, department heads and the managers of major municipal functions, become the key decision-makers with regard to the direction and expansion of integrated municipal information systems. USAC documents must, therefore, be addressed to people with Functional and/or public administration backgrounds, as well as to the EDP manager and mis staff. This conclusion led to the first defined requirement of the design task:

The Module Design Specifications must contain a general description of how information system technology is used to carry out specific municipal responsibilities. Portions of the document must be at a level of detail and in a format which enables the non-technician to evaluate the applicability of the design to his own particular environment.

second factor is the diversity of hardware and software systems that are commercially vailable and are selected by American municipalities. The Charlotte Consortium believed hat if the design documents were restricted to a single hardware and software onfiguration, the efforts required of a potential transferee without the same configuration ould discourage transferability. Thus, the Charlotte Consortium defined its second quirement of the design task:

The Module Design Specification's description of performance requirements should be basically independent of computer programming techniques and the central computer facility equipment configuration in order to ease adaptation of the design to the configuration of the transferee.

There are, however, limits to the degree that a design document can be kept separate from a specific configuration. The Charlotte Consortium's Module Design Specification does reflect the City of Charlotte's computer system configuration in two areas. First, the majority of the designs are, because of the nature of the USAC program and the Charlotte approach, highly oriented to on-line interactive data processing. Thus, the designs are more transferable to municipalities that have or contemplate having communications oriented systems. Second, the Module Design Specifications reflect the City of Charlotte's selection of terminals. In a communications oriented system most of the interaction between the system and the user is through terminals. The Module Design Specifications indicate the detailed layout of all input and output terminal displays. Since different manufacturers terminals have different characteristics in terms of the size of the scope and available characters, the Consortium decided that the display formats should reflect the terminal or terminals selected to support the module. Primarily, UNIVAC terminals are used. However, adaptation of the formats from UNIVAC terminals to other terminals should not present a significant problem for potential transfer cities. Third, direct computer program transferability will depend greatly on two rather unlikely conditions: one, that the computer system configurations of potential transfer cities will, in general, be like that of Charlotte's; and two, that potential transfer cities could accept the operational designs, which were supported by the computer programs, with no change. For this reason the Charlotte Consortium concluded that direct computer program transfer would be improbable and municipalities interested in transfer would therefore benefit more from the products of design than from the products of development. Transferability would be facilitated through a clear, explicit understanding of Charlotte's design so that either new supporting computer programs could be written or Charlotte's original computer program set modified intelligently. Accordingly, a third requirement for the design task was established.

The Module Design Specifications should be sufficiently comprehensive and detailed so that computer program logic and code could be developed from the document itself without significant interaction between the development staff and the design staff.

The Charlotte Consortium believed that the above requirement would enable a transferee to adapt the designed procedures to its own environment and to then develop computer programs compatible with its own hardware and software configuration.

3.1.2 Integration

USAC and the City of Charlotte are concerned that the system developed within the USAC program in Charlotte be an integrated system. The Charlotte Consortium considers integration from two points: first, in terms of the embedding of information system technology into daily municipal operations; second, in terms of the application of information system technology to accommodate the informational relationships between