Norfolk Public Schools is a predominantly inner-city school system serving the city of Norfolk, Virginia. With an average per-year population of 36,000, the district's data processing (DP) department discovered early on a need for computers to manage recordkeeping. Historically, we have had success with developing most of our applications in-house. We find that our in-house systems tend to be easier to manage and tailor to our administration's constantly changing requirements than generic, pre-packaged information systems (SISs). Thus as new needs arose over the years, our DP staff developed new systems to meet them. By 1986 though, our relatively small programming staff--six including a hands-on manager--was no longer able to keep up with the demand for new applications. At this time, we began to explore new software as a means for improving the productivity of the programming staff. By investing in state-of-the-art programming tools we hoped to decrease both the development times for new systems and the maintenance time for system modifications. The SIS Project Initially, one analyst conducted a comprehensive requirements study to determine the needs of our users and the shortcomings of current systems. This analyst spent his first few months interviewing administrators, secretaries and clerical staff, and observing the functions of the recordkeeping personnel at the schools. The study indicated that most of our top-level administrators were relatively satisfied with their ability to get timely reports. Other administrators though, especially those at the schoolhouse level, were less satisfied with DP's turn-around time for reports and system enhancements. While the study documented numerous new requirements and a few serious limitations with the old systems, our problems boiled down to two major concerns: * First, we had a data accuracy problem. Since our systems had been developed over time as separate, distinct entities, we had some data redundancy in various files. For example, the data element student name was kept in several different files, and one file often did not match another. * Second, our users, especially at the school-building level, needed more timely access to data. Apparently, the backlog of requests at DP had created an undocumented priority system that resulted in requests from top-level administrators being moved ahead of those from other users. Of the two concerns, we felt that the latter was the more serious. Obviously, we were failing in our effort to provide timely information to a large segment of our users. In several cases the analyst noted that DP had not been able to respond to information requests until after the need for the report had passed! Additionally, we knew that the data availability problem contributed to the data accuracy problem. As a centralized DP shop we were totally dependent on the schools to provide us with accurate data. Yet since these very users were the ones benefiting the least from our systems, the incentive for them to go out of their way to collect and record data was diminished. By the completion of the requirements study we knew that we needed new software tools that would help us deliver information to our users more quickly and accurately. It was decided that a relational database management system (RDBMS), well accepted as an excellent tool for both managing data and easily extracting information, should be at the heart of the new system. We also added a requirement for a fourth-generation language (4GL), which we intended to use to code the new system and as an ad-hoc inquiry tool for simple reports needed by both the DP staff and our sophisticated users. Subsequently, we purchased the following software: * SQL/DS, an RDBMS which runs under the VSE and VM operating systems; * Cross System Product (CSP), a 4GL; and * Query Management Facility (QMF), the query manager for the SQL/DS package. …