General University


March 2/1996

Sirs:

The accompanying document describes the overall design of an on-line student registration system for General University. This design accommodates the specific modifications suggested by General University to our original proposal.

In particular, the system incorporates a graphical user interface, which will allow new users to rapidly adapt to the system. As well, multi-level access provides different sets of functions for different classes of users. This design allows for easy extension of the system to accommodate new functions and new classes of users.

The function of major modules are described, along with specifics of data types, how the modules will interact, and illustrations of screen images that users will view.

Sincerely,

Educational Systems Products, Inc.

Table of Contents

Introduction and System Overview

Educational Systems Products (ESP Inc.) is designing an on-line student registration system for General University. The major functions of this system are discussed in this document. Included are

Major Data Types

Users
All users are represented in the system by a single data structure, which includes a unique identification number, a password and a status code. This code will allow differentiation between classes of users and the features of the system that they may access. The current implementation sub-divides users into students and administrators, but the concept allows for easy expansion of the classes of users. User information also includes name, address and phone number.

Students additionally have recorded their faculty, the maximum course load they are allowed, a list and count of the courses they are registered in and a transcript of courses taken.

Courses
Courses are known by a unique code which concatenates an abbreviation of the course discipline (eg. MATH) and course number (eg. MATH271). For clarity the word department is used synonymously the word discipline. A course is unique but may have none or many lecture, lab and tutorial sections. Each of these sections is given a location, time and capacity. The lecture section also records the name of the lecturer.

An Entity Relationship Diagram (ERD) illustrates the relations between courses and students in the system. A data dictionary specifies the types of individual data items in the system.

System Information
The system must record the dates when the registration system can be accessed for enrollment (the add date), and the last date a student may withdraw from a course (the drop date.) For registering new students, the last identification number issued is also stored, so that these numbers remain unique.

System Modularity

The design is based on three sub-systems. The login sub-system blocks unqualified access to other sub-systems. Via a single menu, student users can see, modify and print their timetables, as well as change their passwords. Administrative users can access these functions plus a superset of capabilities which includes adding new students, changing the information recorded for a current student, deleting students, printing class lists, and modifying registration date information.

This document describes the functions of each subsystem. A pictorial overview is supplied as a structure chart.

User Interaction

What follows is a description of the system we will provide from a users perspective. Please use the screen snapshots as reference. Note that a "button" refers to a mouse operated button.

Welcome Screen



The welcome screen is displayed when the terminal is idle and is returned to whenever a user finishes a session. It's purpose is to welcome the user and provide two options. General University will customize this screen by placing a picture of the university and the university's logo or motto under the welcome message. No typing is required on this screen. The two options are: "Login" and "On-line Calendar". The online calendar option is part of the enhanced system and will not be implemented initially. If the user clicks on online calendar, the system will provide a message to this effect. In the future this option will provide general calender information. Clicking on "Login" will bring up the login window.

Login Screen



The purpose of this screen is to identify a user of the Student Registration System as a student or an administrator, and log them on if authorized. It is impossible for students get into the administration mode. Administrator identification numbers are confidential. Should any particularily malicious individual obtain an administrator's identification number, it would be impossible to guess their password. A guide for administrators to choose unguessable passwords will be provided.

After the user clicks on the "Login" button on the welcome screen, the login screen appears. Users will see two boxes on this screen that require him/her to type in his/her student identification number and password. There are three buttons on this screen: clear, ok and quit. These buttons can be presed by using the mouse or by using the tab key to select and the return key for the action. The clear button will clear both fields. The ok button is used to proceed after both fields are entered. Pressing return after entering a password has the same function as ok. The quit button returns the system to the welcome screen.

From the entered identification number the system distinguishes which mode it will be in: student mode or administrator mode. Upon entering a valid identification number, the system continues by requiring a password for entry into the system. The password is echoed to the screen as asterisks to confirm the keystrokes to the user. If the identification number given is that of an administrative user, the system will display the administrative main menu, otherwise the student registration main menu is displayed. If the user inputs an invalid password and/or identification number, an error message and a prompt for re-entry will be displayed.

Student Registration Main Menu



After the student has entered a valid identification number and password, the "Student Registration Main Menu" will be displayed on the screen. It is an interface which allows the user to have quick and easy access to specific sections of the Student Registration System.

In the upper left corner of the screen, the student can see an area which contains their personal information. It includes the student's name, identification number, address, faculty, major/minor, status (full-time or part-time) and year of program. This information serves to confirm to the user that their information is correct and up to date. The student is not given access to change any of this information directly.

Under the student information is another sub-window containing the student's personal timetable. This timetable displays all of the courses that the student is currently registered in. The courses are displayed in a time slot so with a quick visual inspection a student can check the days, start time, duration time and location of a specific course. The timetable is set up so that it displays the times in the left margin and the days of the week in the top margin. The timetable is scrollable both horizontally and vertically. Underneath the timetable are 3 buttons: "Drop a Course", "Change a Course" and "Print Timetable". These buttons allow the student to perform the respective operations. More information regarding these functions follows.

In the upper right corner important dates are displayed. Today's "Date", "Last day of Registration" and "Drop Date" serve to remind the student of registration deadlines. Students cannot change these dates.

Below these dates, there is a sub-window called "Course Listing". This sub-window basically allows the student to view all of the lectures, labs and tutorials for a course along with their times, section number, duration, days offered and location. The student would have to first click on the "Department" drop-down menu and pick the discipline of where the course belongs and then move along the the "Course" drop-down menu to specify a course to list. Under these drop-down menus there are 3 columns; one for all of the lecture sections, one for all laboratory sections and finally one for all tutorial sections.

There are three buttons and a status bar displayed at the bottom of the screen. The buttons are "Help", "Change Password" and "Quit". If student clicks the mouse on the "Help" button, a help menu will be displayed to provide help for the user. The user can scroll through the entire online help facility or get help on specific functions. "Change Password" lets the student change their password for access to the system. The button "Quit" will bring the student back to the "Welcome Screen".

The status bar called the "Context Sensitive Help" displays helpful messages for users. As the student moves the mouse around the screen a helpful message about the use of a button is displayed in this area.

Adding A Course

Adding a course using the ESP Student Registration system is a feature that enables the user to compose the course schedule that he/she desires. The easy to use interface allows smooth, quick and non-complicated interactions to minimize difficulties typically associated with other systems. The course listing contains three main sections: department, course and course sections.

Getting Started:
As technology advances it is sometimes assumed that even the most complicated Graphical User Interface is one that anyone can easily learn. This assumption however, is not the case. In order to accommodate this reality, we have incorporated a 'grayed out' system that helps to guide the user through sequential steps in order to completely fulfill the requirements of adding a particular course.

To fulfill these requirements, the system will allow access to only the appropriate information that need be supplied. For example, by 'graying out' all of the areas in the course listings box except the department section, the user can see that they must enter a department to move onto the next section; Courses. When a department is chosen, the selection is displayed in the 'Department' window and the 'Courses' window becomes active (un-grayed). Now the user selects the course related to the department, where this too is followed by the selection being displayed in the window. The remaining boxes, specifically lectures, labs, and tutorials are activated for inputs. For a more detailed description, read below.

Department
The Department button, located at the top left of the course listing, is the first step in adding a course. It contains a listing of all of the types of courses offered at General University. Clicking on the department button results in a drop down list. The listing contains, in alphabetic order, each department that is offering courses. Located to the right of the drop down listing is a scroll bar that gives the user access to other departments that could not fit in the window. By clicking on the arrows, located on top and bottom of the scroll bar, the listing will scroll up or down respectively through the listing. After locating the department of choice, one click over the selection will highlight it and a double click will select it. Once selected, the drop down menu will disappear and the selection will occupy the department window of the course listings area.

Course
The next required step in adding a course is choosing a course from the course listing. Clicking on the course button results in a drop down list of all of the courses, and associated course information, offered in the previously selected department. The courses are listed by an abbreviated name and a course number as described in Gen U's yearly calendar, for example: CPSC451. As in the Department section described earlier, there is a scroll bar located to the right of the listings; allowing the user to scroll through the available courses if necessary. Selecting a course is also done by moving the mouse to it, clicking once to highlight the selection and or double clicking over it to select.

Lectures, Labs, and Tutorials
Choosing a lecture, lab, or tutorial associated with the previously described department and course selection is accomplished within the course listing in the same way as selecting a course. The area is configured with the applicable section information only after the previously described department and course selections are made. As before the list has a scroll bar to the right to view all of the sections offered and the associated description ie. lecture, lab, or tutorial number, time offered, days offered, location, and status of availability denoted by 'Available' or 'Full'. The lectures, labs, and tutorials that are NOT indicated as full are the only ones the user will be able to select. As before a selection is made by clicking once to highlight and double clicking to select. When all of the associated sections (labs, lectures, and or tutorials) are selected the "Add Course" button will become active allowing the user to make the addition to their schedule.

Add Course Button
The Add Course button, located at the bottom of the window, ensures that the user has selected his/her course and associated labs and or tutorials. Upon selecting the appropriate sections, as described above, the Add Course button is activated. When the Add Course button is selected by a single click over it, the user is informed that the selection has been added to their schedule. The Add Course button is linked to the system database where the new course will be added to the user's record of current classes.

Dropping A Course

Dropping a course is a common practice among students today in order for them to customize their schedules. The ESP student registration system is designed for quick processing and maximum time efficiency to minimize a students time spent registering for classes.

As described earlier, the timetable area where the student's current courses are listed is to the left side of the screen. A course is dropped by clicking once to highlight it within this area and then clicking the "Drop a Course" button.

Upon selecting drop a course, the user is prompted, by means of a pop up window in the center of the screen, to confirm that the selected course is to be dropped. This is to eliminate mistakes on the users behalf, and to provide a way out before actual removal. This prompt is answered with a yes/no selection. Single clicking on 'Yes' results in the user being informed of the action and the menu is returned to the foreground. The course dropped will no longer appear in the timetable window. Single clicking on 'No' results in cancellation of the dropping process. There will be no changes to the users timetable and the main menu is returned to the foreground.

To Change a Course

From the main menu, the user can also modify a course. Modifying a course is necessary when the student is already registered in a course but wish to change to a different lecture and/or lab and/or tutorial. The modifying of a course function can be implemented both on the student's system and on the administrator's system. However, the administrator's system is not restricted by the limited space of a course section. That is, the administrator can modify a course for the student even if that lecture/lab/tutorial is already full.

The course to be modified must first be highlighted in the timetable area by moving the mouse to where the course is in the timetable and clicking on it. If the student accidentally clicked the course by mistake or now wishes to change the course they want to modify, he/she can just click on another course. After a course has been selected, the student can then press the "Change a Course" button to make the changes.

Once the "Change a Course" button has been pressed, the course listing (located below the Course listings box) will display all of the selected course's available lectures, labs and tutorials along with their times and associated information. All of the sections that conflict with the student's schedule, or are full, will be grayed out (or have a "FULL" status beside it -- the administrator can still select these). The student's current sections will be highlighted. The student now can look at all of the other available lecture sections, laboratory sections, and tutorial sections and decide which to modify to best suit their schedule.

The student can now make the changes by clicking on the lecture, lab, or tutorial they wish to switch to. When a section is clicked on, it becomes highlighted to show that it has been selected. After that, the student can press the button "Change A Course" at the bottom of the timetable so the system can process the request. The system then displays an "Are You Sure" dialog box. The student must press on the "Yes" button or the "No" button. If "Yes" is clicked then the system continues with the processing. If "No" is clicked, the system stops processing and returns to the foreground.

After the "Yes" is clicked, if the request is successful, the system will automatically update the new sections on the timetable and display a success message in the status line at bottom of screen. A course conflict is not possible because the system will not allow a student to choose a course that is in conflict with their present schedule. A selection may be unsuccessful if the course happens to become full in the time it takes for the student to view and then select a new section. The system will then display a dialog box with the following error message: - "Modification unsuccessful. Lecture section is full." ("Lecture" may be replaced by "Lab" or "Tutorial") Administrators may enroll a student in a full section ,in that case the system will display: - "Modification successful. Warning -- Lecture section is full." ("Lecture" may be replaced by "Lab" or "Tutorial") Users must press the "OK" button at the bottom of this dialog box in order return control back to the main menu. The user can try other sections and press the "Change A Course" button again.

List Available Courses

This feature is accessible to the user at all times because the course listing window is always displayed on the main menu, to the right of the timetable window.

Selecting a course to display
To select a department, the user clicks on the department button and a list is displayed. The user can then select from among the available departments listed as described earlier in the add a course segment. The list is in alphabetical order. A typical list that the user might see is: 

          
          Engineering
          General Studies
          Management
          Mathematics
          Social Science
          Science
A department must be selected by the user before selecting the course. If the user tried to select a course before a department was selected, an error message would be displayed. After a department is selected, a course can be chosen using the same procedure as picking a department. Note that all departments and courses offered by Gen U are displayed, but those that are seen as a conflict to the user's current course schedule are grayed out on the list. This prevents the user from selecting that particular course or department because it conflicts with the user's schedule. If the user tries to select a grayed out item, a dialogue box will appear to tell the user that the department or the course will conflict with his/her current schedule. If a course listing currently exists, that is, the user has already inquired about a course, and the user wants to list information for another course, then the user simply re-selects the course and/or department desired. When department and courses are selected, the selection is displayed on top of the pull down menu.

The section listing
Once the department and a course have been chosen, the list of sections will immediately show the available sections offered for that particular course. There is a listing of lecture sections, laboratory sections, and tutorial sections. When the list of a section is too long to be displayed in the window, the user can scroll up and down the list using the scroll bar. All sections offered by General University are listed, however, if a particular section is determined to conflict with the user's current timetable, then it is grayed out to denote that it is unavailable.

Contents of the section listing
In each section listing (lecture, labs, and tutorials), the start time, duration, location, section number, and days that the sections are offered are displayed. A typical listing of the lecture sections: 

     Lecture   	Start       Duration	Location    Days
     section   	time       (minutes)

     Lec01       12:00       120 	SB105	    MW
     Lec02       08:00	      50	ST111	    MWF
     Lec03       13:00	      50	ST110	    MWF
Similarly, a typical list of the laboratory sections:


     Lab   	Start       Duration	Location    Days
     section   	time       (minutes)

     Lab01       12:00        50 	SB112	    MW
     Lab02       08:00	      50	ST96	    MWF
     Lab03       13:00	      50	ST10	    MWF
The tutorial listing:

	
     Tutorial  	Start       Duration	Location    Days
     section   	time       (minutes)

     Tut01       12:00        50 	MS115	    MW
     Tut02       08:00	      50	ST10	    MWF
     Tut03       13:00	      50	ST05	    MWF

Printing A Timetable

Both students and administrators can print a timetable. This is done by putting the mouse on the print timetable button located directly beneath the student timetable area and then clicking the mouse button once. The system will verify that there is an attached printer and notify the user if the print request was successful or not. Note that an administrator must call up a student record first and then request the printout while a student already has their record loaded and only need to click on Print Time Table. An error occurs here if there is no printer detected or an administrator attempts to print a timetable before they select a student.

Change Password Screen



To change their password a user clicks on Change Password from the main menu. This causes the creation of a Change Password window in the center of the screen. User is prompted to enter their old password, a new password and to verify their old password. They must then click on okay for the system to accept or cancel to abort the request. If the change is successful a confirmation window relays that information to the user. User must click cancel and this window and the Change Password window will disappear. Note that passwords are not echoed on the screen, for security reasons.



The password change may be unsuccessful because the old password the user typed in did not match the password on file or their new password did not verify. In either case the user is informed by a error window and they must click cancel to make this box disappear. They are then back at the Change Password window where they can try again.



Administrative Menu Screen

This menu is displayed if the user enters an identification number and password that are recognized as an administrative user.



In the upper left corner of the screen, specific student information is displayed. The information includes student identification number, student name, address, faculty, major, minor, status and program year.

Beside this sub-window are four buttons that allow the administrator to "Add", "Delete", "Modify" and "Find" a student. After the administrator clicks on the "Add" they can then enter information. Similarly, "Delete" and "Modify" allow the administrator to remove or change student information. "Find" allows a user to search for a specific student by entering the student's identification number.

Below the "Student Information" is the student's timetable. It is identical to the time table displayed in student mode. Again, there are three buttons at the bottom of the timetable: "Drop a Course", "Change a Course" and "Print Time Table". The administrator can use these functions just as the student can use them.

Below the date box is the "Course Listing" sub-window. The administrator uses this window in the same manner as the student's system, with one additional function. The administrator may print a class list by clicking on the "Print Class List" button.

At the bottom of the screen, the user can click on the "Help" button to access the help menu. The administrator can then scroll through the entire help text or call up help on specific functions.

The "Change password" button allows the user change their password. The "Quit" button ends a user's session and then returns to the "Login Screen".

The status bar called "Context Sensitive Help" displays helpful messages for users. As the administrator moves the mouse around the screen a helpful message about the use of the button they are on is displayed in this area.

Modify Add/Drop Date

In the upper right corner of the screen, there is a data box containing the "Date", "Last day of Registration", and "Drop Date". The dates are all in long form (ie. January 29, 1996). The administrator can change these dates by clicking on the screen and typing in the new dates and then clicking on the "Accept Dates" button. The system will then check this new information against the current date, and each other ( ie. the Add date cannot be past the Drop date). If the date is in a valid format and conforms to the predefined criteria the system displays a confirmation box and the new date is displayed in the date field and the database stores the new date. Erroneous dates will cause an error box to appear with the nature of the error; this box will not disappear until the user acknowledges it by clicking on cancel in the error box. After the error has been acknowledged the user is returned to the date input field.

Student Information Functions

Add Student
To add a new student to the database the administrator simply clicks on the student information fields and enters data as appropriate. Once the administrator has entered all of the information, clicking on Add Student validates the information and if accepted generates an identification number and a password for the student. This is displayed to the administrator in a separate window and they must click ok in this window to make it disappear. In this function the administrator may not enter an identification number since the system will generate one automatically, but they may enter information in any of the other fields, in any order. The fields Faculty, Major, Minor, Status and Program Year allow default values. For example, it may be desirable to have Status default to 'full time' and program year to 1 for newly registered students.

A possible error is not enough fields entered and the system will create an error box denoting the missed field to the user. After the user clicks cancel to confirm that they have read the error message they are returned to the Student Information data entry screen with all of the information that they have entered so far still there and from there they can correct the error and continue.

Delete Student
There are three sequences that a user may execute to delete a student from the database. One way is to click on Delete Student when the student information area is blank. This will cause the Find Student window to appear and prompt the user for a student identification number. The user enters it and clicks select to accept. The record for that student is then displayed on screen in the Student Information area and the user is asked if they are really sure that they want to delete this record. The user may cancel or confirm at this point. A second way is for the user to click on Find Student and retrieve the student record, then click on Delete Student to remove this record. In the third scenario the record is already present and the user only need click on Delete Student. A successful deletion will clear all of the fields in the Student Information area and notify the user that the student has been deleleted from the database.

Possible errors are an invalid student number or a nonexistent student number in the Find Student function. The system error message is specific and it will not disappear until the user clicks cancel to acknowledge the message.

Modify Student
As in Delete Student there are three ways to modify a student's information. Starting from a blank student information screen the user might first use the Find Student function to recall a student's record. Then the user is free to edit all of the fields of the record except the identification number. When finished making changes the user clicks on Modify to accept and if accepted the system updates the student's record in the database and notifies the user that the update was successful. The second way is to click on Modify Student with a blank information record; this will automatically call up the Find Student function and then the user can select the student via identification number and edit their record. Finally, the third way is to already have the student's record on screen, edit it and click on Modify Student to accept. Errors will occur here if the administrator attempts to blank out a student's name or address. In these cases the modification would not be accepted and the user would be returned to the student record so that they may correct their error(s) and try again.

Find Student
Administrators may spend much of their time retrieving, validating, and changing student information. For these reasons the Find Student function is a useful feature of any student registration system. The user clicks on Find Student and a window is created requesting a student identification number be entered. The user then enters a number and clicks Select to retrieve the student's record or they may cancel. The Find Student window will then disappear. It is possible to enter incorrect or nonexistent student numbers here. The system will inform the user as to which type of error was made and return to the identification number prompt to allow the user to re-enter. If the student's identification number is found the Find Student window disappears and the student record is displayed in the student information area of the screen.



Course Listing/Print Class List
To print a class list, a course must be selected. To do this the administrator clicks on Department in the Course Listing area of the window and selects a department. After choosing a department the user clicks on Course and selects a course in the same manner. When a course has been selected all of the lectures, labs and tutorial sections for that course appear in three columns. The user then selects the component that they wish to print a list for by moving the mouse to that section and clicking to highlight. Now the user can click on Print Class List and a listing for the highlighted component will be printed. The system confirms that there is an attached printer and if so notifies the users that the list is queued successfully. If no printer is found the user is notified and asked to confirm the cancellation of their print request. It is possible for a user to request a class list without having selected a course component, in that case an error window will appear to inform the user and they will be allowed to retry after canceling the error window.

Administrator Access to:
Add Course, Drop Course, Change Course, Print Timetable
The Administrator can manipulate a student's schedule by first using Find Student to call up the student's record and then all of the functions -- Add Course, Drop Course, Change Course, Print Timetable -- that are available to the student can be used. Alternatively the administrator can click on any one of Add Course, Drop Course, Change Course or Print Timetable first (when there is no student record present) and then automatically the Find Student window is created.

Help screens

What follows is our initial content for help screens. This material is subject to revision and refinement pending final delivery.

Printing a timetable

Students
Click on the 'Print Time Table' button located directly beneath the Student Time Table.

Administrators
Make sure that you have a student's record on screen first. If not, then click on the 'Find Student' button. Enter the student's identification number at the prompt. Click 'Select' to accept. Student's record appears on screen. Click on the 'Print Time Table' button located directly beneath the Student Time Table.

Help on adding a student

How to add a student
Click on the 'Add Student' button located to the right of the Student Information area. Enter the new student's data in the appropriate fields. Click on 'ok' to add the student to the database. A new window will appear with the student's password and identification number, make a note of this information and then click on 'ok' to make this box disappear.

Possible errors
Not enough information entered
Click on 'Quit' in the error box to make it disappear. Enter the missing data in the student information area. Click on 'ok' when done.

Incorrect information
If a student has been successfully added to the database but one or more of the fields is incorrect then click on 'Modify Student' located below the 'Add Student' button to the right of the Student Information area. Edit the erroneous fields. Click 'ok' to accept the changes.

Help on deleting a student

How to delete a student
Click on the 'Delete Student' button to the right of the Student Information area. If the student's record is not already on screen you will be prompted for a student identification number. Enter the number and then click on 'Select' to accept. The student record will then appear on screen. The 'Are you sure?' dialog box will prompt you for a 'Yes' or 'No' to delete this student. Click on 'Yes' to delete the student and 'No' to abort the action.

Possible errors
Student not on file
Click on 'Quit' to make the error box disappear. Check that you have the correct identification number. Re-enter the identification number at the prompt. Click 'ok' to accept.

Invalid identification number
Click on 'Quit' to make the error box disappear. Check that you have the identification number in the correct format. Enter the corrected identification number at the prompt. Click 'ok' to accept. The student record will appear on screen.

Help on modifying a student

How to modify a student
Click on the 'Modify Student' button to the right of the Student Information area. If you do not have a student record on screen you will be prompted to enter an identification number. Click on 'Select' to retrieve the student's record. Enter new information in the Student Information area fields. Click 'ok' to accept changes.

Possible errors
Not enough information entered
Click on 'Quit' to make the error box disappear. Check that you have entered a student name. Enter the missing data in the Student Information fields. Click 'ok' when done.

Student not on file
Click on 'Quit' to make the error box disappear. Check that you have the correct identification number. Reenter the identification number at the prompt. Click 'ok' to accept. Make modifications to the student record. Click on 'ok' to accept these changes.

Invalid identification number
Click on 'Quit' to make the error box disappear. Check that you have the identification number in the correct format. Enter the corrected identification number at the prompt. Click 'ok' to accept. Modify the student fields and then click on 'ok' to accept these modifications.

Help on finding a student

How to find a student
Click on the 'Find Student' button located to the right of the Student Information area. Enter in the student's identification number at the prompt. Click on 'Select' to accept. The student's record will appear in the Student Information and Student Time Table areas.

Possible errors
Student not on file
Click on 'Quit' to make the error box disappear. Check that you have the correct identification number. Reenter the identification number at the prompt. Click 'ok' to accept.

Invalid identification number
Click on 'Quit' to make the error box disappear. Check that you have the identification number in the correct format. Enter the corrected identification number at the prompt. Click 'ok' to accept.

Help on course listing/print class list

To print a class list: - Choose a department in the Course Listing section by clicking "Department" and selecting the department name. The selected department name will then appear on the department line. - Then choose a course from that department in the same manner under "Course". - All lectures, labs, and tutorials for the course will now appear under their appropriate boxes. - Select the desired components you wish to print by clicking on them so that they become highlighted. For example, to print out the class list for a lecture, only the lecture name needs to be highlighted; to print out the lab or tutorial for a particular lecture, you must first select the lecture then highlight a lab or tutorial. - After the desired components have been selected click on "Print Class List" to print. - If there is any troubles, you will be informed in the context-sensitive dialogue box.

Help on modifying add/drop date

- To change the add or drop date, you must make the changes directly in the boxes containing the dates located in the upper right hand corner of the screen. The dates are in long form (ie. January 29, 1996), any changes must also be in this format. - Start by moving the cursor to the date you want to change, then you can either select the whole field by clicking on the date once and typing the new date in or you may double click on a certain area on the date field to display a cursor in the field and making the minor changes in the date. - After you have made the changes to the dates, press the "Accept Dates" button. A confirmation dialogue box will appear if the date is acceptable and in the correct format, click "OK" to accept. An Erroneous dialogue box will appear if the new date is in a wrong format or misspelled or is invalid (ie. the drop date is earlier than the add date), you must click on "Cancel" in the dialogue box to acknowledge the error and try again.

Implementation Plan

In this section we will discuss how ESP will implement our product, the registration system for General University. General University wanted a graphical user interface that would be easy for their students to understand and use. This is what we will supply to them. We will use three levels of programming to do so.

First we will talk about the type of system required to run the registration system. A UNIX based machine, such as a SUN workstation, is necessary since the registration system will be an xwindows application. This type of machine will be required for all registration locations. More information regarding the necessary hardware will be made available to you in the near future.

As was mentioned before, three levels of programming will be needed for this product. The main level is C code. Almost everything will be written in C. We also need a database to store student information and course information. This is solved by using C calls to Sybase, a database system. General University also desired a graphical user interface. Since this is cumbersome and tedious in C we have decided to use Tcl/Tk to implement this. Calls from C to link it all together. With this type of implementation, we will be able to provide this product as desired by General University.

PseudoCode

The following section contains the pseudocode of all of the major classes of functions needed for our project. These are broken down into two sections, Student Functions and Administrative Functions. Student functions are used by students and administration alike where Administrative Functions are used strictly by the administration.

Login System

Structure Chart and DFD
Login
Procedure LOGIN

	display Login Window
	if "CLEAR" button clicked then {
		clear "ID" and "Password" edit boxes
	}
	if "OK" button clicked then {
		search user database for user's ID#
		if ID# is not found then {
			clear "ID" and "Password" edit boxes
			display error window with "User not found"
			start Procedure LOGIN again
		} else {
			if password is correct {
				hide Login Window
				if user status = ADMIN then {
					display Main Admin Window
				} else {
					display Main Student Window
			} else {
				clear "ID" and "Password" edit boxes
				display error window with "Incorrect password"
				start Procedure LOGIN again
			}
		}
	}
Change Password
Procedure CHANGE_PASSWORD 
	{
	display Change Password Window
	if "CANCEL" button clicked then {
		hide Change Password window and exit from this function
	}
	if "OK" button clicked then {
		search user database for student (by ID#)
		if student's old password entered is incorrect then {
			display error window with "Incorrect old password"
				and clear all of the password edit boxes
		}
		if the two new passwords entered do not match then {
			display error window with "New Passwords don't match"
				and clear the new password edit boxes
		} else {
			store the new password for the user into the database
			hide Change Password Window
		}
	}

Student System

Structure Chart
Add Course
DFD 
Procedure ADD_COURSE
	{
	display Add/Modify_Course Window
	if "CANCEL" button clicked then {
		hide Add/Modify_Course Window
		exit add_course
	}
	if "CLEAR" button clicked then {
		clear each of the following edit boxes: - DEPARTMENT,
			COURSE, LECTURE, LAB, TUTORIAL
	}
	if "OK" button clicked then {
		if there is missing info then {
			display error window with "Incorrect course selection"
				and some suggestions for the user
		} else {
			display "Course Added" response Window with course
				information as a confirmation
			search user database for student (by ID#)
			add course to student's list of courses
				- update schedule & course information sub-
					windows on the main screen
				- if count(courses) > 2 then change student
					status to FULL TIME
			hide Add/Modify_Course Window
		}
	}
Modify Course
DFD 
Procedure MODIFY_COURSE
	{
	display Add/Modify_Course Window
		- display present choices made my student in the following
			edit boxes: - DEPARTMENT, COURSE, LECTURE, LAB,
			TUTORIAL
        if "CANCEL" button clicked then {
                hide Add/Modify_Course Window
                exit modify_course
        }
        if "CLEAR" button clicked then {
                clear each of the following edit boxes: - DEPARTMENT,
                        COURSE, LECTURE, LAB, TUTORIAL
        }
        if "OK" button clicked then {
                if there is missing info then {
                        display error window with "Incorrect course selection"
                                and some suggestions for the user
                } else {
                        display "Course Modified" response Window with course
                                information as a confirmation
                        search user database for student (by ID#)               
                        change course in student's list of courses
                                - update schedule & course information sub-
                                        windows on the main screen
                                - if count(courses) > 2 then change student
                                        status to FULL TIME
				- if count(courses) < 3 then change student
					status to PART TIME
                        hide Add/Modify_Course Window
                }
        }
Delete Course
DFD 
Procedure DELETE_COURSE
	{
	search user database for student (by ID#)
	display R_U_Sure window
	if "NO" button clicked then {
		hide R_U_Sure window
	} else {
		delete course with corresponding lec#, lab#, tut# from the
			student's record
		update database
		hide R_U_Sure_window
		if count(courses) < 3 then change student status to PART TIME
	}
Print Timetable
DFD 
Procedure PRINT_TIMETABLE
	{
	search user database for student (by ID#)
	/* The following will format the student's record into a
		timetable-style format for GUIs and Text-based output */
	Direct the following output to the printer
	for every hour (ie. 0800, 0900, 1000, etc) {
		for every day (ie. M, T, W, R, F) {
			Check course schedule to see if anything in that
				time slot
			If yes, then print that course in that position
				on the chart
		} /* Continue moving horizontally */
	} 
	Turn off the redirection of the output to the printer
View Timetable
Procedure VIEW_TIMETABLE 
	{
	search user database for student (by ID#)
	for every hour (ie. 0800, 0900, 1000, etc) {
		for every day (ie. M, T, W, R, F) {
			Check course schedule to see if anything in that
				time slot
			If yes, then print that course in that position
				on the chart
		} /* Continue moving horizontally */
	}
List Courses
Procedure LIST_COURSES 
	{
	display List Courses Window (if not already up)
	if Department entered into the Drop Down list box then {
		search course database (by department selected)
		display all possible info of matches in the list box
	}
	if "CLOSE" button clicked then {
		hide List Courses Window
	}

Administration System

Structure Chart
Add Student
DFD 
Procedure ADD_STUDENT
	{
	- Clear all student info fields
	- Show "O.K." and "Cancel" buttons bellow student information
	- Make student info editable
	- Gray out all other options

	If "Cancel"
		{
		- Make student info uneditable
		- Hide "O.K." and "Cancel" buttons
		- Ungrey other options
		- Exit
		}

	If "O.K."
		{
		If Some info is missing
			{	
			- Prompt user
			}
		Else
			{
			- Store student info in user database
			- Generate password and I.D. number
			- Prompt user with password and I.D. number
			}

		- Hide "O.K." and "Cancel" buttons
		- Make student info fields uneditable
		- Ungrey other options
		}
	}
Modify Student
DFD 
Procedure MODIFY_STUDENT

	{
	- Show "O.K." and "Cancel" buttons bellow student info
	- Make student info editable
	- Grey out all other options

	If "Cancel"
		{
		- Make student info uneditable
		- Hide "O.K." and "Cancel" buttons
		- Ungrey other options
		- Exit

	If "O.K."
		{ 
		If Some info is missing
			{
			- Prompt user
			}
		
		Else 
			{
			- Store student info in user database
			- Prompt user with confirmation
			}
		}

	- Hide "O.K." and "Cancel" buttons
	- Make student info fields uneditable
	- Ungrey other options
	}
Find Student
Procedure FIND_STUDENT
	{
	- Show Id_Search window

	If "Cancel"
		{
		- Hide window
		- Exit
		}
	
	Else "O.K."
		{
		- Search user database for I.D. number

			If I.D. not found
				{
				- Prompt user
				}
			
			Else
				{
				- Move students records into student info and
				  course schedule
				}
		- Hide window
		}
	}
Delete Student
DFD 
Procedure DELETE_STUDENT
	{
	- Show R_U_Sure window with deleting student I.D. number
	
	If "No"
		{
		- Hide window
		- Exit
		}

	Else "Yes"
		{
		- Delete student record from user database
		}	
	 
	- Hide Window
	}
Modify Drop Date
Procedure MODIFY_DROP_DATE

	{
	- Make Drop_Date editable

	If "Return"
		{
		
		If Format incorrect
			{
			- Prompt user
			- Make drop date uneditable
			- Exit
			}
		
		Else
			{
			- Change Drop_Date to New Drop_Date
			- Make Drop_Date uneditable
			}
		}

	}
Modify Add Date
Procedure MODIFY_ADD_DATE

	{
	- Make Add_Date editable

	If "Return"
		{
		
		If Format incorrect
			{
			- Prompt user
			- Make Add date uneditable
			- Exit
			}
		
		Else
			{
			- Change Add_Date to New Add_Date
			- Make Add_Date uneditable
			}
		}

	}
Print Class List
DFD 
Procedure PRINT_CLASS_LIST
	{
	- Show Class_List window
	
	If "Cancel"
		{
		- Hide window
		- Exit
		}
	
	If "O.K." 
		{
		
		If Information is incorrect
			{
			- Prompt user
			}
		
		Else
			{
			- Search user database in Student_Courses with
			  Course_Name and Section
			- Print all matches
			}
		}

	- Hide window
	}

System Testing

Testing Team

Testing of all aspects of the project will be accomplished by a Quality Assurance (QA) team made up of several of the members of the supplier group. The QA team will be led by a manager who will oversee all aspects of the project's testing. This person will keep track of all of the testing's progress and personnel. This person will also keep track of the various states of bugs found in the code, from their initial discovery to their final removal. He or she will also act as a go between between the QA team personnel and the project's coders.

Individual members of the QA team will be responsible for the design of various tests that will check the code and the actual implementation of these tests on the code. They will report bugs and their severity to the QA team manager and they will work together with the coders to assure the final removal of the bug, making certain that fixes do not have any adverse affects on the remainder of the program.

Testing Plan

The objective of any test plan is clear. To minimize the occurrence of bugs in the final product delivered to the customer. It is through the testing procedures outlined in the test plan that we will bring about this ellimination of bugs. By the use of thorough testing procedures, and the correct types and amount of testing, the occurrence of bugs will be minimized. The tests and testing procedures outlined below are designed to indicate where bugs are in the code, and they will suggest methods of correction, and prove that a correction of a bug has been made.

Several different areas of the test plan will help to minimize the occurrence of bugs in the final product. The implementation of a very thorough bug tracking system will have the direct effect that all found bugs are properly noted. As a programming team we will know what needs to be corrected, and where to concentrate testing to ensure that these changes in the code have been effective. The testing schedule as implemented is thought to be essential to the maintenance of schedules associated with the project, and should result in the product being delivered on time, with a minimum of bugs in it. Finally, the testing methods used in each area of the project are chosen in order to find as many bugs as possible, with as efficient a way of finding the bugs as possible.

The success criteria will no doubt differ for each module and component of the project, as follows:

Success Criteria for Testing

The criteria of success for functional testing will include whether the function coexists well with the other functions in its module. It will also include whether the function performs the tasks it was designed to do correctly. Functions that do not meet these two criteria will need to be redesigned by the programming team. These success criteria are similar for the unit testing stage, in that the entire module will be tested for these two qualifications.

The criteria of success for integration testing is quite critical. A module may be perfect in every regard with respect to unit testing, but if that module does not fit into the greater scheme of the program, or it does not co-exist well with other modules calling it, the module is essentially useless to the program. The success criteria for integration testing is that the module(s) must function seamlessly with the modules into which it is being integrated. Anything less will have a disastrous effect on the project as a whole.

The criteria of success for performance testing is that module(s) perform in a time that is deemed acceptable to the final user of the product. For example, if a search function took exponential time, the entire program and any modules requiring this function would suffer severely in performance. If exponential time is the best possible for a given function, then it will considered successful at this level. If however, a functions performance can be improved to polynomial time, it will cause a drastic improvement in the functions speed. This performance level will be aimed at by the programmers. Programming time will need to be considered for the performance testing however. If it is determined that a method could be made more efficient to save a small amount of time for the end user, but these changes would add a layer of complexity to the program, and/or would require a great deal of programmer time, these changes may or may not be made. Instead, they will each be accessed on a case by case basis by the programmers.

The criteria for success of acceptance testing is that the module performs correctly all of the conceivable trials and tasks as set out by the customers. If the entire testing procedure did not cause an error to be found up until this point, the error must be inherent to the understanding of the requirements between the customer and supplier. Changed requirements by the customer at this stage of the project should not be corrected and should not be considered a failure of the acceptance tests. These changed requirements should be addressed in a later revision of the project.

Bug Tracking System

A robust bug tracking system will be implemented by the Quality Assurance (QA) team. As bugs are found, each bug will be assigned a unique ID number, which will be used to direct all further references to the bug. Each bug will also be assigned a severity level, based on how severe the bug is perceived to be.

The severity of the bug will be classified on one of four levels, namely A, B, C, and D. Level A bugs roughly correspond to the most severe, disastrous bugs. These bugs are ones that crash the program, hang the operating system, or cause data loss to the user. Level B bugs and level C bugs are not as bad as those in level A, in that they do not cause the program to crash, or cause data loss to the user, but that they indicate some key feature of the program is not working correctly or not working as expected. The key distinction between level B and level C bugs comes in whether or not a work around to the bug can be created that will cause the function to behave as expected. Level B bugs have no such work arounds, while level C bugs have the possibly of a work around. Lastly, there are the level D bugs. These bugs are cosmetic and rather minor to the functioning of the program. They may be as simple as a spelling mistake, or an incorrectly located pop-up menu.

Each bug will also come with a full text description of it. This report will be comprised of several key descriptive areas including:

  1. Who first found the bug.
  2. The date the bug was discovered.
  3. The version of the program in which the bug was discovered.
  4. The area of the program in which the bug was discovered.
  5. What exactly the bug is.
  6. The circumstances that brought about the bug.
  7. The hardware on which the program was being run.
  8. The operating system being used at the time.
  9. The windowing software being used at the time.

Finally, each bug will be given a status. This status field will have five possible choices, namely: NEW, CONFIRMED, FIXING, FIXED, and CLEARED. All bugs will be initially assigned the NEW designation. This will signal to the programmers that this is an entirely new bug. Once the bug has proven to be reproducible by the programmers, it will be assigned the CONFIRMED designation. When a person has been assigned to and is commencing to fix the bug, the bug will receive the FIXING designation. When the bug has been corrected by the programmer, it will receive the FIXED designation. Finally, when the bug has be confirmed to be removed by the quality assurance team, it will be given the CLEARED designation, indicating that it is no longer a bug is the program, in this revision at least.

All bugs will then be transferred to the programming team. Bugs will usually be assigned to the programmer(s) responsible for that particular module of the overall program in which the bug was found, but where severe bugs exist, or bugs that transcend the boundaries between modules are found, several programmer may be assigned to the correction of each bug.

Important Tests and Testing Dates

Initial unit testing of code will take place by the programmers as they are developing the code. When they are satisfied that a module or function is operating correctly they will pass it on to the testers to do their testing. It is important that at least one programmer of the code for the module or function discusses it with the tester prior to testing in order to minimize confusion. The programmer may also be helpful in suggesting areas in which the coding is weak, and hence where more testing should be done.

The first area of testing will be the user interface. While none of the internal code of the program may be working yet, the interface so far developed can be tested for its usability. While the interface of the project has been developed and spelled out in full as above in the document, there will most likely be difficulties that will arise and its implementation. It will be important that the testing team thinks as a user is this stage of the testing, judging all aspects of the interface from the user's point of view. In performing this stage of the testing adequately, we will hopefully end up with an interface that is very usable to the Gen U community.

Testing will then move on to testing of the basic functionality of the code and the software as the various components are implemented. By testing that all of the basic functions of the code work as specified in the functional specification, we can make sure that all aspects fit with the user's expectations of the project.

When the various engines of the projects i.e. the database engine are implemented, testing on them will begin to make sure that they work correctly and perform their basic functions well as required.

When all aspects of the project have been implemented the Alpha Testing stage of the testing will begin. This stage will begin to move beyond the basic functionality testing above, and will move into the whole software project testing. Errors in how the various aspects of the project and the various engines of the code work together will be tested and hopefully no bugs will be found. Bugs that are found will be corrected to the best of our abilities. Further testing of the bug fixes will report whether bugs have been corrected, and/or whether more bugs have been introduced. By the following of the Test Plan, which has yet to be developed, the QA team will perform testing of the software, moving on to later and later testing stages until finally the software is in a deliverable form.

The following dates are subject to change as deemed necessary by the QA team. Nevertheless, the final delivery date is firm and as such, the project must be delivered on time. Testing that takes longer amounts of time in one area will have to be balanced out by testing by that takes shorter amounts of time in another area, or the delivery date will be missed.

March 6, 1996 Testing of the program interface to begin. Ken, Bryan and Sung.

March 10, 1996 Walkthrough testing of the interface to be completed at this time. Does the interface fit with the descriptions given of it in the overall design document? Do the various buttons and menus send the user to the correct place as specified? In addition, are there any user interaction problems with the interface apparent at this stage of the programming that are necessary to correct? This testing will be completed when all user interaction problems have been corrected, and all menus and buttons function as specified in the overall design document. Some testing of the interface by the customer group may be done at this time at their discretion. Ken, Bryan, and Sung.

March 10, 1996 Functional testing of the add course database function to be completed. Are courses added to the database correctly? Completed when courses are added without problem. Hugh.

March 10, 1996 Functional testing of the modify course database function to be completed. Can courses already in the database be modified correctly, as specified in the overall design document? Completed when courses are modifiable without difficulty, as specified in the overall design document. Doug K.

March 10, 1996 Functional testing of the delete course database function to be completed. Can courses already in the database be deleted correctly, as specified in the overall design document? Completed when courses can be deleted without difficulty. Mike.

March 10, 1996 Functional testing of the add student database function to be completed. Can students be added to the database correctly? Completed when students can be added without problem, as specified in the overall design document. Colin.

March 10, 1996 Functional testing of the modify student database function to be completed. Can students already in the database be modified correctly, as specified in the overall design document? Completed when students are modifiable without difficulty, as specified in the overall design document. Pat.

March 10, 1996 Functional testing and performance testing of the find student database function to be completed. Can students already known to be in the database be found correctly, as specified in the overall design document? A large, prepared database of students will be used to determine the typical performance for the search. Success when students in the database can be found in a reasonable time, linear with the number of students in the database. Joe

March 11, 1996 Performance testing of all previously tested modules and functions to be completed. Performance will be tested and whether the performance is acceptable or not will be reviewed with the testers and the programmers on a case by case basis. Assigned to persons as above.

March 13, 1996 Functional testing of the login function. Do correct student id and respective passwords allow the user to enter the system? Are incorrect student ids and/or passwords denied access to the system? Is the password echoed as asterisks correctly? Does this function correctly interface with the database? Completed when the function allows authorized users to enter the system and does not allow unauthorized users access. Howell.

March 14, 1996 Basic integration testing of the database engine with the various database functions to be completed at this time. Basic input/output testing of the database engine of the program to be commenced at this time. These tests should include random addition, modification, and deletion of both student information and course information, and examining what the result is on the various databases inherent to the program. Massive, repeating scripts to test for the limits of the database size, and what is necessary to cause it to crash. Completed when integration of all of the database functions is complete. Douglas T., Barb, and Mike.

March 17, 1996 Basic input/output testing of the database engine to be completed, as above. Douglas T., Barb, and Mike.

March 17, 1996 Functional testing of the print timetable function to be completed. Do the courses a student is registered in appear on the timetable without errors? Does the correct student information appear on the timetable? Do the courses appear under the correct times and days of the week? Completed when a correctly formatted time table, with all required information will print for all students. Colin.

March 17, 1996 Functional testing of the print class list function to be completed. Do all of the students registered in a class appear on the printout? Completed when a correctly formatted class list, including all of the students in a given class, appears at the printer, without errors. Pat.

March 19, 1996 Integration testing of the print class list and the print timetable function into the database engine. Do the two functions still work correctly within the added complexity of the database engine code? Completed when the two functions perform as specified in the overall design document. Colin, Pat, Douglas T. and Doug K.

March 21, 1996 Primary testing of the integration of the interface and the database engine to be completed. Ken, Sung, Hugh, Barb, Douglas T., and Mike.

March 28, 1996 Testing of the integration of the interface, database engine, print timetable, print class list, and the login screen to be completed. Completed when all functions work as designed in the overall design document and when interface manipulation by the user causes the desired changes to occur in the database component of the program. Whole group.

March 30, 1996 Performance testing of the project to be completed. Completed when desired actions are completed in time limits set out by customer group. Whole Group.

April 3, 1996 Acceptance testing of the program to be completed. Success if the program meets the qualifications as set out by the customer group in their original functional specification. Whole Group.

April 3, 1996 Alpha testing of the whole program to be completed, including the repair of all found bugs in the testing procedure. Additional testing should focus on performance testing of the program for maximum speed benefits. Some testing of the functionality interface and the program as a whole by the customer group may be done at this time. Completed when the program is no longer easily improved, and where bugs are not apparent. Whole group.

Reporting Procedures

All testers will submit a bug report upon encountering any bug at any stage of the project. The initial severity of the bug will be determined by the person submitting the bug report, as following the various qualifications as listed under the Bug Tracking System heading. All other information as required in the Bug Report, again as listed under the Bug Tracking System heading, will be completed and submitted to the Bug Manager.

In addition, at the completion of each testing stage for their area of the project, the person(s) responsible for the testing will submit a report outlying the results of their testing to the QA team. This report will include but not be limited to, where applicable:

If testing cannot be completed by the given date, a report should be submitted as above, including why testing could not be completed on time. Testing must be completed as soon as possible, so that delays do not occur to subsequent areas of the project. Therefore, additional person(s) to test and fix bugs will be assigned by the QA team to complete testing as soon as possible, and minimize delays.

The QA team and the programmers will go over these reports and note where further testing of the code and fixes in the code are required. They will work to ensure that the testing procedure used have not missed any key areas of the program or of a particular function. They will also work to ensure problematic areas of the code are well covered to ensure fewer errors in these critical areas. Additional resources may be devoted by the QA team to the repair or further testing of certain modules as they feel is required.

Bug Correction

Whenever possible, the person uncovering the bug (this will usually be the person performing the testing for a given module or function) will work with the programmers to correct the bug. Once a bug has been deemed to have been corrected by the programmer, the tester will then check to ensure that the bug has been corrected. Testing will then begin again from scratch to make certain that the bug(s) have been both removed, and have not caused other bugs to surface. If other bugs are found to surface, this procedure will begin anew.

While it would be best to correct all bugs perfectly, situations will no doubt arise which will be difficult to correct. Where a level C bug which has an easily implemented work around is available, this work around route may be taken to minimize time and maximize efficiency of the programmers. Level A and B bugs on the other hand, must be fixed correctly and properly without work arounds, owing to their importance to the overall program, and their severe effects to the user. While level D bugs are minor, these must also be corrected to the best of our abilities. While these are only cosmetic to the program as a whole, the appearance of the program to the end user is very important. An end user may never come across a level C bug in their uses, but they will readily notice these small cosmetic errors inherent in the level D bugs. As a result, we will pursue the correction of all level D bugs.

Component Integration Plan

Integration of separately tested modules into a working system involves:

Although each module has been unit tested, testing after integration must include tests of:

Testing Summary

It is recognized by the QA team that no matter how thorough our testing procedures are, how lucky the testers are, or how perfect the programmers are, bugs will nonetheless still arise in the final shipping version of the product. While all bugs are important, through the testing procedures, the likelihood that these new bugs are of the disastrous type discussed above will be minute. As a result, these bugs can dealt with in minor fixes to be included in subsequent revisions.

Summary

The shift to the GUI based system has been completed and now all project members are working towards that as their final goal. As you can see above, mock-ups of the typical interface have been created. While these will more than likely resemble the final working version of the interface, it is important to note that these are just mock-ups, and that the final version of the interface may differ slightly in appearance, if not in functionality.

The relationship between the various menus and dialog boxes has also been spelled out above through the means of various DFDs and pseudo code. This should serve as a guide to what the typical inputs should be, and the various outputs that the program will produce.

In general, ESP Inc. looks forward to the implementation of this project.

Glossary

For additional information on terms and data types, please see our glossary.

To see the User Manual for the system, please click here.