Software Design Document, Testing, Deployment and Configuration Management of the UUIS--a Team 2 COMP5541-W10 Project Approach

Figure 1.1 [7]:Three-tier architecture diagram

An Apache 2.2 server will parse through code written in PHP 5 to generate browser-readable output. In addition, it is responsible for ensuring that large datasets are properly truncated (as requested by the user, where applicable), and that controls for navigating through truncated datasets are SDD for UUIS TEAM 2 2010 provided. When truncation occurs, the presentation layer will display controls to display the data (1) immediately preceding the current records, (2) immediately following the current records, (3) at a given position by pagination, (4) the first set of records and/or (5) the last set of records.

The output from the UUIS will also contain Javascript code in order to perform client-side presentation of information, as well as allow preliminary validation of data entered by the user before it reaches the logic layer. All operations are hidden from the external viewer with a wrapper class.

The user-accessible functions are distributed across six functional modules. One such module groups together the miscellaneous functions accessible by all users (login, logout, submit requests, search, etc.). All university management operations are grouped into another functional module. A third module relates to asset-related operations, while a fourth interfaces with review options (audits and reports). There is a separate module for managing database errors, and the remaining module concerns privileged operations related to requests.

The functions accessible to all users are of necessity those where no background check of the user’s privilege is necessary, but merely require validation of the user’s identity. The functions are: (1) login, (2) logout, (3) change password, (4) view personal information, (5) submit requests, (6) SDD for UUIS TEAM 2 2010 view request status (for requests submitted by the user), (7) cancel a request (for requests submitted by the user) and (8) search.

Those related to University Management require differing levels of permissions. Provided that such users exist, all users are able to change the privileges of users of compatible affiliation but lesser permission level than themselves. L1 users (users with permission level 1, only higher in rank than L0 users) are allowed to enter new users into the database from a CSV (comma-separated values) file if the new records are of compatible affiliation (same department) and to manually initiate a database back-up. L2 users are able to create a new department and add a location to the database in addition to the functions available to L1 users (though the compatibility extends to all departments within the L2 user’s faculty). L3 users are able to perform the same functions as L2 and L1 users on a university-wide basis, as well as create new faculties.

Asset management includes the ability to view assets, add assets either in single item or in large quantities from CSV files, update asset information either for a single asset or for large numbers of assets and group assets. Each of these operations may be performed by L1 users for asset(s) within their department, by L2 users for asset(s) within their faculties or by L3 users for any asset(s) in the university.

There are two primary functions related to the review module:

generating reports or audit data. As with asset management, the review SDD for UUIS TEAM 2 2010 6 functions are limited by the user’s privileges, and the selection of options varies accordingly. Reports may be generated to compare data across various fields (such as the number of seats available vs. the maximum capacity of a room, or the number of desktop computers vs. the number of computer screens, or even simply a list of the users within a department).

Auditing relates to reviewing the transactions in the database that have occurred, such as tracing the user who has added an item, or who updated which field for an asset.

A user with sufficient privileges (L1, L2 or L3 users with system administrator privileges) is able to manage error reports. Options for doing so are: listing errors (possibly after inputting constraints in the form of a search), printing error messages and viewing/annotating specific error messages.

The sixth module concerns request management. All users are able to submit requests as well as view and cancel requests they have submitted themselves. All other request-related operations are handled by the -request management‖ module. Those operations include: viewing pending requests submitted by other users, approval/formalization of pending requests and rejection of requests. In all cases, us

…(Full text truncated)…