The development of information systems is made up of a number of sequential steps which often is iteratively refined. At the front-end of the process, the systems requirement needs to be determined. Thus, the initial step is to analyze the problem and determine a s far as possible the requirement of the software to be developed. The requirement is a snap-shot in time of what is needed of the information system to be developed. The requirement is a description of what the end-user perceive as their needs and is often harvested from a multitude of sources. It covers each source usually in an uneven manner; it will describe some aspects in very general terms while in others, it will be rather specific. Not all requirements can be identified readily at the start of a software development project. Often major requirements are identified during the development process.
The Requirement Definition or System Analysis is an evaluation and identification of the information to be retrieved from the system, the required input to the system, the association of events within the system and the input-output stream transformation that defines the system. Requirement Definition must not encroach on the design process, that is, in deriving the requirements, it must not make assumptions about the system to be developed. But, the system design will deduce these from the specifications which is obtained from the requirements.
The next step then is to take the inconsistent, incomplete and ambiguous requirements and convert them into precise and accurate Systems Specifications. The specifications defines what is required of the software and what constraints are placed on the s oftware system to be developed. The derivation of the specification is a continuous process and will proceed throughtout the development process.
The System Design process then takes the specifications and through representations, designs or structures the target software to satisfy the specifications. The last stage of the development of the software is Program Design and Coding, where the design structures are transformed to program structures and coded into software.
The case study scenario that is chosen is one that is practical and from real-life. The scenario chosen is the development of an information system for the Campus Safety Department of a university in the USA.
The Campus Safety Department of a university has the responsibility to keep the peace and maintain a safe environment for all personnel on the university campus. The department has always maintained records of all activities at the university. The existing data collection system at the Campus Safety Department is mainly manual. Recently, a regulation was enforced by the United States government giving access rights to all students and potential students the statistics of criminal activities that occurred on any campus in the land. Thus, now there is an impetus to utilize a better data collection system.
The Campus Safety department maintains a record of all on-campus personnel and their vehicles, and also off-campus personnel and their vehicles who uses the campus. Using Structured Systems Analysis (SSA), the functional requirements (or structured requirements) can be defined as: to maintain records of departmental employees, to monitor and control traffic violations, to monitor and control criminal incidents, and to record and monitor other incidents. The department keeps a record of its departmental employees. This department is entrusted with the responsibilities to monitor and control traffic violations such as:
There is a problem at the Campus Safety Department. The problem definition is that "the existing data collection system at the Campus Safety Department is tedious, requires much human effort and takes a considerable amount of time to process." A computerized user friendly information system is required to improve productivity and work efficiency. This information system must be user friendly and should encompass all data entry, report generation, administration, maintenance, and utility features that support the system. It should also be simple enough for the users to use and to maintain, yet provide all the features required for the day-to-day operations. The best application software that should be developed is a Database Management System (DMS).
The available hardware at the Campus Safety Department is an IBM compatible personal computer with a 640 X 480 resolution monitor running on a 486 microprocessor with 4 megabytes of RAM and a Hewlett-Packard Deskjet printer. The available licensed softw are are Microsoft Windows version 3.1 and Borland's Paradox version 4.5 for Windows. The personnel at the Campus Safety Department are familiar with the basic operations of Paradox. Thus, without incurring extra costs and effort, and because of the users' familiarity, the best application software that can be used is Paradox version 4.5 for Windows.
The systems requirement is the currently available hardware and software at the Campus Safety Department. No additional resources should be required to run the information system that is to be developed.
From SSA, the general systems specifications and design can be derived. Different problems will require different approaches, and some problems may justify a combination of different software design methods. This information system, based on a database model, is developed based on a combination of software design methods.
The nature of the database at the Campus Safety Department requires that certain software functions be developed or coded. These software functions define the design specifications that are needed to provide capabilities for:
The interface between the levels is by means of menus with click-on pushbuttons. See the User's Manual (Appendix 3) for more more details. Each pushbutton is embedded with ObjectPAL program codes that leads to the next level menu or until a dialog box is displayed which will request for some action.
The system design began from the system decomposition. The modules as depicted on the design tree diagram in Figure 4 is used in the systems design stage. Each module is a table or a group of linked tables. Thus, the system data structure can now be m odelled as a database. The entities, relationships and attributes of each table is utilized to model the database. The systems design is based on the Entity-Relationship model of the database to be created. From the design tree, menus are created for ea ch level. The transition from one level to the next is activated by push-buttons which are embedded by ObjectPAL program codes. This program coding is based on Object Oriented Design and programming. Each level also have an "Return" push-button that will allow the user to return to the preceding level menu or an "Exit" push-button in the case of the main menu which will allow the user to terminate the program. There are other features that need to be considered as well.
The system input is designed mainly for the keyboard or bar code scanners. This will allow for future implementation of bar code scanners if there is a need.
The input or data entry process is mainly through screens that are designed called forms. Each form corresponds to a table, in general. But in the case of the "Vehicle Registration and Violation Data Entry" form, it corresponds to five tables linked to gether through the ID number. Each field in the data entry form has data integrity built-in. The transition between levels or menus can be made through screens designed called menus. Menus consist of a few push-buttons embedded with ObjectPAL codes whi ch allow the user go to the next level (push-buttons labeled in black) or to the preceding level (push-buttons labeled in red) depending on the push-button that is activated. Another kind of screen design is the dialog box. The dialog box is used to pro mpt the user for action such as printing to a printer or to the screen. The radio buttons in dialog boxes are embedded with ObjectPAL codes. More details can also be found in the Us er's Manual in Appendix 3.
Even though the top level design is done using structured design, this information system is basically a database management system. From the top level decomposition, tables are created to capture all the data. The tables created are :
The data dictionary for all the tables can be found in Appendix 3. Each level is structured as a cluster of modules. The user interface design capability of Paradox (the form or menu design) is used to link the modules together as a branch (as seen on the design tree) to each menu. The progam codes are hidden (information hiding) in the graphical user interfaces (pushbuttons, radio buttons or check marks) and when activated will allow the user to move vertically between levels. The design of this info rmation system involves the use of three design methods--the Structured Analysis and Design (using the Design Tree Diagram), the Data Structure Oriented Design (using Entity-Relationship modelling) and the use of Object Oriented Design (using Object Desig n and ObjectPAL programming). The main data entry form is the "Vehicle Registration and Violation Form" which is made up of tables linked together. See Figure 5.
The data in the information system are confidential. Therefore, system integrity cannot be compromised. Security controls are required to control access to the tables. For this information system, there is a master password where access is given to al l the tables. This is mainly for the database administrator so that data can be entered and reports generated. There are also user passwords where users are allowed access to tables that they use. The security control also prevent unauthorized access f rom external database software such as the Paradox package. The database administrator has full supervisory rights to grant users right of access to any table in the information system.
When queries are run, a result table is created based on the query. Reports are generated from these result tables. The system output or reports can be directed to the screen or to the printer. This is done through selecting the appropriate choice in t he dialog boxes. The report design screens and the actual reports generated can be seen in Appendix 3.
The test plan consists of modular testing and took place throughout the information system development phases. Each module is tested beginning from the top level. Unit testing includes testing each data entry field for data integrity. Unit testing was also done to ensure that the correct error message or message is display. All the menu pushbuttons and dialog box radio buttons were also tested to verify that the correct level or menu is displayed. When all the unit testing for a menu, that is a cluster of modules, is completed, integration testing is done. Integration testing begins next with a top-down structured approach. Modules are tested to ensure that they are able to interface and if they are interfacing correctly. On completion of the integration testing, the complete information system package underwent an alpha test in the laboratory. After satisfactory quality assurance is done, the information system package is loaded at Campus Safety for a beta test. There were no bugs found at the beta test.
When there were no bugs found, the Campus Safety Information System was implemented. The information system was designed to be independent of external support as all the required utilities are available within the package.