CSC 376PROJECT DEFINITION Spring, 1990
Mr. Weisert Handout #4
PROJECT: University Information System
CLIENT/USER ORGANIZATION: The University of Southern Wilmette
BACKGROUND:
Until recently USW had no central responsibility for information systems. The few existing computer applications had been developed at different times by different unskilled people with inadequate funding.
PROBLEMS/OPPORTUNITIES:
USW now suffers from:
widespread dissatisfaction among faculty and administration with existing application systems that are perceived as hard to use, inflexible, unreliable, and mutually incompatible,
frustration with the lack of support for numerous other essential functions for which no current system exists,
frequent costly or embarrassing errors in registration, billing, and other functions visible to students or outsiders.
SCOPE:
This project is to investigate the feasibility of eliminating or minimizing the above problems by building a suitable, integrated information system supporting the administrative functions within USW through the 1990's. Assuming such a system is feasible, the project will proceed to specify (and eventually implement) it.
A.The existing systems include:
- Student registration
- Student records
- Course / faculty scheduling
B. Additional functions needed soon are:
- Departmental curriculum planning
- Student program planning
- Course materials development and maintenance
- Course records/grading
- Course catalog preparation and printing
- Faculty skills inventory
- Faculty information exchange
- Equipment/resource inventory
- Alumni records
C. Other functions eventually desired include the usual accounting and financial systems.
D. Excluded from the current assignment are the following systems, to be provided by outside service organizations:
- Payroll
- Physical plant operation and maintenance
CSC 376 Project Definition 2
CLASS NOTES ON THE PROBLEM DEFINITION:
1. The previous page is a terse summary of a potentially huge problem. Such a brief problem statement is the typical result of a "Project Initiation" phase, and serves to get a project formally established and pointed in the right direction. In terms of our life-cycle model, therefore, we're ready to begin phase 2, the "Business System Requirements" phase.
2. Clearly, the scope is much too large to be handled in a 10-week course. You'll need to partition the desired "integrated information system" into well-defined subsystems that can be specified, developed, and operated independently. Then you can choose a manageable subset of those subsystems to be specified in full detail.
3. To save time we won't really investigate "feasibility" in depth. Let's just assume that our subsystems can be rationally justified by quantifying the costs and benefits and then deriving from them a favorable return on investment figure.
4. Before partitioning a large integrated system, it's helpful to see what the whole system will look like, especially the interfaces among the various subsystems and the contents of shared data bases. This gives us confidence that the various independently developed subsystems can eventually fit together smoothly. One possible approach is to collect the business system requirements (phase 2) for the whole system, then partition the result, and finally prepare the detailed functional specifications (phase 3) only for the selected subsystems.
5. Since USW is a fictitious organization, you won't be able to interview real users, to examine existing systems, or to observe people performing their job functions. Instead, you can interview the instructor, who can play the role of some kinds of users within the university. In addition, any project team members who have experience with similar systems may be able to play various user roles. Depending on the direction your project takes, other sources of information may be available. As a last resort, you'll have to make some common-sense guesses about what such users would tell you about their needs.