2013_CSS_Functional_Specification_Document.pdf

I T I N N O V A T I V E S O L U T I O N S C O R P .

4 R E S E A R C H P L A C E

S U I T E 2 4 0 R O C K V I L L E , M A R Y L A N D 2 0 8 5 0

Campus Safety and Security

2013 Functional Specification Document

Table of Contents

Table of Contents

List of Figures

List of Tables

1 System Overview

1.1 Purpose

1.2 Scope

1.3 Commonly Used Abbreviations

1.4 General Constraints

1.5 Assumptions and Dependencies

1.6 Software Compatibility

1.7 User Characteristics

2 CSS Database

2.1 Institution Universe Maintenance

2.2 Dynamic Display of Data Entry Screens

2.3 Data Storage System

3 System Design

3.1 Design Overview

3.2 Survey Screens and Navigation

3.3 Skip Patterns

3.4 Edits

4 Reporting and Utility Functions

4.1 Institutional-level User Tools

4.2 Administrative User Tools

Appendix A: Screen Test Handbook

A.1 Screen Test Introduction

A.2 Navigation

A.3 Walkthrough

A.4 Calculations Expanded

A.5 Edit Rules Expanded

A.6 Edit Examples

List of Figures

Figure 3-1: CSS Data Collection Environment Figure 3-2: Intelligent Screen Selection

Figure 3-3: Processing the Screen

Figure 4-1: Institution Status

Figure 4-2: Survey Status

Figure 4-3: Survey Status by Sector

Figure 4-4: Institution Reporting Status

Figure 4-5: Institution Status

Figure 4-6: Survey Status

Figure 4-7: Survey Status by Sector

Figure 4-8: Institution and Survey Status Summary

Figure 4-9: Registration Summary

Figure 4-10: Unregistered Users

Figure 4-11: Dynamic Report Figure 4-12: Batch Migration

Figure 4-13: Issue Tracker

Figure 4-14: Survey Log Report Figure A-1: Screen Test View

Figure A-2: Information Bar

Figure A-3: Screen Identification Example

Figure A-4: Users View

Figure A-5: Screen Test View

Figure A-6: Screen Cell Information Window

Figure A-7: Sum Calculations

Figure A-8: Calculation Formula

Figure A-9: Edit Rules Row

Figure A-10: Screen RSN 130

Figure A-11: Error Code 404

Figure A-12: Error Code 14

Figure A-13: Screen RSN 120

Figure A-14: Error Code 55

List of Tables

Table 1-1: Abbreviations

Table 1-2: Institutional-level User Example

Table 1-3: Administrative User Categories

Table 3-1: Matrix String Example

Table 3-2: Position of Digit Example

Table 4-1: Admin Maintenance Permissions

Table A-1: Operands

Table A-2: Frequently Used Deviations

1 System Overview

The U.S. Department of Education is committed to assisting schools in providing a safe environment, while keeping students and their families informed about campus security. To manage this process, the Campus Safety and Security (CSS) data collection software was developed. This web-based system is used to collect data related to criminal offenses and incidents reported by over 7,500 postsecondary institutions in the United States. The CSS Survey is conducted annually by the U.S. Department of Education’s Office of Postsecondary Education (OPE). The survey is mandated by the Jeanne Clery Disclosure of Campus Security Policy and Campus Crime Statistics Act, signed in 1990 and re-authorized by Congress with the 1998 amendment to the Higher Education Act of 1965 (HEA) to help potential college students and their families research criminal offenses on or near college campuses.

OPE collects crime statistics from all postsecondary institutions in the United States that receive Title IV funding via the CSS Survey website located at http://surveys.ope.ed.gov/security.

Data collected in this survey are disseminated by OPE and the U.S. Department of Education via the publically available Campus Safety and Security Data Analysis Cutting Tool located at http://ope.ed.gov/security.

1.1 Purpose

The purpose of this document is to describe the functional design and scope of the CSS data collection software; including, database design, database storage, survey screens, survey navigation, user types, skip patterns, edit failure, data locking, data migration, and reporting utilities.

1.2 Scope

The data collection software applied to the CSS Survey is based on the IPEDS Data Collection System (DCS). Similar to the IPEDS DCS, the CSS data collection software is designed to collect data from a select group of postsecondary institutions. In this case, the CSS Survey collects crime data from postsecondary institutions in the United States who receive Title IV funding.

http://surveys.ope.ed.gov/security http://ope.ed.gov/security

1.3 Commonly Used Abbreviations

Table 1-1: Abbreviations Abbreviation Meaning CSS Campus Safety and Security OPE Office of Postsecondary Education INOVAS IT Innovative Solutions, Corp.

IPEDS Integrated Postsecondary Education Data

System HEA Higher Education Act

1.4 General Constraints

The CSS data collection software is designed to support up to 1,000 simultaneous users during peak usage time.

1.5 Assumptions and Dependencies

All institutions must be approved and assigned a CSS Log In to access the system.

1.6 Software Compatibility

The CSS data collection software is designed to work with Internet Explorer, version 7; and Mozilla Firefox, version 2 or version 3.

1.7 User Characteristics

The system recognizes two types of users:

Institutional-level User. Responsible for submitting data. This includes Multi- Keyholders, Keyholders, and Proxy Users.

Administrative User. Responsible for managing the survey process. This includes Help Desk, Help Desk Managers, Education Department, and Super Administrators.

1.7.1 Institutional-level Users

Institutional-level Users can be single institution users, known as Keyholders; or multi-institution users, known as Multi-Keyholders. These two user types share the same general permission level; however, Multi-Keyholders have Keyholder access to several institutions. In addition, Multi-Keyholders have access to additional utilities for searching and viewing the status of all institutions under their auspices.

Both Multi-Keyholders and Keyholders can request access for up to six additional Institutional-level Users, known as Proxy Users. A Proxy User is created by a Multi-Keyholder or Keyholder and is assigned a separate User ID and password. A Proxy User may enter data; however, only Multi-Keyholders and Keyholders can lock the survey. When created by a Multi-Keyholder, the Proxy User is granted access to each of the institutions under the creator’s auspices; however, only a true Multi-Keyholder can access the additional utilities mentioned above.

NOTE: If the institution previously completed the survey, all Multi-Keyholder and Keyholder accounts remain active and can only be deactivated by an Administrative User. Whereas, a Proxy User account is only active for the single year in which it is created.

Table 1-2 outlines four User IDs, each denoted as a specific user type, and their access to three separate institutions.

Table 1-2: Institutional-level User Example

* User has the ability to lock the survey

User ID User Type Has access to:

Institution A Institution B Institution C

88G0311 Multi-Keyholder* Yes Yes Yes 88G0312 Proxy User (created by

88G0311) Yes Yes Yes

C97654321 Keyholder* No Yes No C97654322 Proxy User (created by

C97654321) No Yes No

1.7.2 Administrative Users

Administrative Users fall into one of four categories, as shown in Table 1-3:

Table 1-3: Administrative User Categories Help Desk Admin Group 1 A1 Help Desk Manager Admin Group 2 A2 Education Department Admin Group 3 A3 Super Administrator Admin Group 4 A4

A collection of reports and utility tools have been developed to assist Administrative Users during the CSS data collection process. Each Administrative User Category has access to a different set of Reports/Tools. For example, the Administrative User Category A3 can access the Issue Tracker; however, A1 and A2 do not have access to this tool.

NOTE: A detailed description of each report and utility, and its permission levels, is available in Section 4: Reporting and Utilities Functions.

2 CSS Database

2.1 Institution Universe Maintenance

Customized utilities are provided for simple and efficient maintenance of the respondent universe. Any changes to an institution’s status (e.g., closures, mergers, opening of a new branch, and so on) are recorded in the system, and the universe is then automatically updated to reflect and store these modifications.

2.2 Dynamic Display of Data Entry Screens

The CSS data collection software is designed to dynamically display data entry screens as they pertain to the responding institution. As such, each cell on the screen is represented as an individual record in the database. This record contains information which conveys to the program how the cell should be drawn on the screen—including any relevant formatting information. For data cells, the database also contains information on where to store the data entered by the user, and any edit checks that need to be performed when the data are saved. This approach has the following advantages:

The presentation is consistent. Since all of the screens are generated from the same database using the same program, they will always share a common look and feel.

Administrative Users can continually review the screens and corresponding edits while preparing for a new collection year. In addition, explanations and clarifications can be easily added to the screens before or after the collection is opened.

Depending on the unique characteristics of the responding institution, certain data elements may not be applicable. As each institution navigates through the survey, this approach allows the system to dynamically generate screens based on known institutional characteristics and the institution’s response to previous questions. For example, an institution completing the survey that does not offer on-campus housing would not be required to report data related to criminal offenses in on-campus student housing facilities. Therefore, once the institution selects “No” in response to this question, the system generates the appropriate follow-up screens, displaying only those data items that are applicable to the institution.

2.3 Data Storage System

At the heart of the collection software is its innovative method of storing data. One of the primary design goals of this system is to minimize and effectively eliminate deadlocks.

Microsoft SQL Server, similar to most other database engines, places a lock on data tables during the insert and update processes. This measure is essential to guaranteeing data integrity;

however, as the number of simultaneous users increases, the possibility of these users blocking each other from entering and saving data also increases.

A second design goal of this system is to be able to uniquely identify each data cell with a simple identifier that can then be indexed and referenced in edits, data migration, and other parts of the system, as needed. To achieve these goals, the CSS data collection software utilizes a data storage system which boasts the following properties:

Each screen saves data to a separate table in order to reduce the potential for deadlock.

Each individual data cell is assigned a unique number called a Field ID. Typically, specific fields within a table in the database must be identified by storing both the table and column name in the data dictionary. Given the complexity and magnitude of the data collected through this system, this could result in a very long identifying string. The solution, in this case, is a customized numbering system which assigns every cell a unique number. This number is then used on the screens, in edits, and to specify the mapping used for data migration.

Every data cell keyed by this unique number (the Field ID) is then stored in a database table which specifies the expected data type, its storage location within the database, the calculation formula (when applicable), and the null field action.

3 System Design

3.1 Design Overview

The CSS data collection software is designed in C#/ASP .Net and Microsoft SQL Server. The required environment includes a web server (with access for Institutional-level and Administrative Users) and a database server. See Figure 3-1 for a complete layout of the CSS data collection environment.

Figure 3-1: CSS Data Collection Environment

3.2 Survey Screens and Navigation

This section outlines the CSS data collection software for Institutional-level and Administrative Users.

3.2.1 Institutional-level Users

This section applies to Institutional-level Users, as outlined in Section 1.7: User Characteristics.

All users must complete the following screens when they log in to the system for the first time:

Registration. During each collection period, each Institutional-level User is required to complete/update the Registration screen with contact information for the individual using that particular User ID and password, as follows:

o Multi-Keyholder. If the user previously participated in a CSS data collection, most of the information will be pre-filled. The Multi-Keyholder is required to review the pre-filled information, re-enter the e-mail address provided, and confirm that all of the information is current and correct. Once the information is confirmed, the system will automatically update the user’s registration information for all institutions under their auspices.

o Keyholder. If the user previously participated in a CSS data collection, most of the user information will be pre-filled. The Keyholder is required to review the pre-filled information, re-enter the e-mail address provided, and confirm that all of the information is current and correct.

o Proxy User. Even if the user previously participated in a CSS data collection, a Proxy User account is only active for the single year in which it is created. As such, the Proxy User must enter information for each of the required fields indicated with an asterisk.

Institution/Campus Identification. During each collection period, the institution is required to complete/update the Identification screen with general information about the institution/campus, the Chief Administrative Officer, the Campus Safety Officer, and the Campus Fire Safety Officer for each of the institution’s campuses. If the institution previously participated in a CSS data collection, most of the information will be pre-filled.

NOTE: A majority of the information can be updated by the Institutional-level User; however, only Administrative Users can update an institution’s name and the designated main campus (when applicable).

After initial login and registration, Multi-Keyholders (and any Multi-Keyholder created Proxy Users) are directed to the Institutions screen each time they log in to the system. This screen contains the list of institutions that they are primarily responsible for, along with general information about each institution (e.g., Unit ID, OPE ID, Location, State, and Sector). Users can sort the list in ascending or descending order by column, and select an Institution name to continue to the Survey Navigation/Status screen for that particular institution.

For Keyholders (and any Keyholder created Proxy Users), after initial log in and registration, the Survey Navigation/Status screen is displayed each time they log into the system.

The Survey Navigation/Status screen essentially serves as the survey “hub” of the CSS data collection software for Institutional-level Users. It indicates how far the institution has progressed in its completion of the CSS Survey, what steps need to be completed next, and provides links to the various survey screens. In addition, the Institution Name, Unit ID, and Main Campus Name/Identification Number are shown in the top left-hand corner of the screen. Where applicable, a drop down menu is available to navigate between campuses.

From this screen, users can use the Navigation Menu to update their Registration or Institution/Campus Identification information, and complete the following tasks:

Screening Questions. The institution must answer all applicable screening questions for each of its campuses. The answers provided will determine which sections of the survey must be completed by the institution for each of its campuses.

Enter Data. Based on the institution's response to the screening questions, the survey sections applicable to the selected institution/campus are made available. During the collection period, the Institutional-level User can click on a section title at any time to enter data.

Where applicable, Institutional-level Users can use the provided links in the top right-hand corner of the screen to complete the following tasks:

Add Users/Passwords. After completing the Registration screen, Multi-Keyholders and Keyholders can establish Proxy Users at any time by requesting up to six additional User IDs and Passwords. As noted previously in this document, while Proxy Users may enter data on behalf of the institution, only the Multi-Keyholder or Keyholder has the ability to lock the survey upon completion.

NOTE: The Add Users/Passwords option is not available to Proxy Users.

Campus List. This option allows users to view a list of the institution’s campuses;

including, the Campus Name, the designated Main Campus, Location, Status (ACT Code), and the current completion status of the Identification screen for the related campus.

In addition, the Options at this point in the survey section is displayed to assist users in identifying the next steps in the survey completion process for the selected institution/campus.

The actual steps available, and instructions displayed, are based on the institution’s current survey status, as outlined below.

For each task listed in the Navigation Menu (above), a corresponding Survey Status is displayed.

This includes the following:

Not Updated. The institution may be required to complete this section of the survey;

however, the section has not yet been opened.

Updated. The institution is required to complete this section of the survey, and a response to at least one question has been saved.

Not Applicable. The institution is not required to complete this section of the survey.

Read Only. Data are displayed, but cannot be modified or deleted. Typically, this designates a survey “summary” screen.

After the user completes the Screening Questions screen and at least one section of the survey, one or more of the following options will appear in the Review and Submit menu:

Review Caveat/Campus Description. If data are entered in one or more caveat boxes within the survey and/or in the campus description box on the Identification screen, the user must click the Review Caveat/Campus Description link, confirm that the data entered are ready for submission to the public website, and then click Update and/or Confirm. Once this step is complete, the status of this option will change from Not confirmed to Confirmed.

Review Intentional Fires. If data are entered in the “Cause of Fire” column for one or more intentional fires on the Fire by On-campus Student Housing Facility screen(s), the user must click the Review Intentional Fires link, confirm that the data entered are ready for submission to the public website, and then click Update and/or Confirm. Once this step is complete, the status of this option will change from Not confirmed to Confirmed.

Check for Errors. After entering data, the user must click Check for Errors, correct any errors that exist, and continue to resolve all data issues until the survey is clean.

Lock. Once all errors are resolved, the Multi-Keyholder or Keyholder can lock the survey. The survey must be locked before the CSS data collection period closes. Once the survey is locked, an Administrative User must grant access, or Unlock, the survey for the Institutional-level User should they need to make any additional changes or modifications to the data reported.

In addition, the “AM I DONE? Click here for answer” link is available. At any time, users can click this link to verify that they have completed all required reporting items, and that the survey is locked for their institution and each of its campuses, if applicable. If the institution is reporting for multiple campuses, the response will not report “Yes” until the surveys for each campus are locked.

The Print/Get PDF menu at the bottom of the screen allows Institutional-level users to open a read-only version of their current year Institution Information (e.g., completed Registration and Institution/Campus Identification screens) and Crime Data (includes any crime data entered for the institution in the current CSS survey). In addition, this menu includes any fire data entered for the specific institution in the current and two most recent prior year CSS Surveys. The screens available vary per institution and are broken into sections; such as, 2010 Fire Data, 2011 Fire Data, 2012 Fire Data, and Fire Data Summary. For each option, users can print or generate a PDF file for the specified portions of the selected institution’s survey.

When applicable, the Survey Navigation/Status screen also provides information for each campus linked to the institution. This Campus Summary includes the Campus Name, Status (ACT Code), current completion status of the Identification screen, and the Survey Status for each campus linked to the institution.

3.2.2 Administrative Users

This section applies to Administrative Users, as outlined in Section 1.7: User Characteristics.

For Administrative Users, the Search Institution screen will appear when they log into the system. Administrators can submit a search to find existing institutions in the CSS universe based on one or more of the following criteria:

OPE ID. Searches for an institution based on a specified Office of Postsecondary Education ID.

NOTE: Users can search for institutions based on a partial OPE ID (a minimum of one number is required).

Unit ID. Searches for an institution based on a specified Unit ID.

Institution Name. Searches for institutions with all or part of the specified search criteria in their name. For example, a search for the keyword “park” will return search results for both “Park University” and “University of Maryland – College Park”.

Act Code. Searches for institutions by institutional status (e.g., Active, New, Restore, Closed, and so on).

NOTE: Users can select multiple criteria from the menu by holding down the Ctrl Key or Shift Key when making their selection(s).

Survey Status. Searches for institutions by Survey Status. This criterion is typically used in combination with other search criteria. For example, users can select “Complete” in combination with the Sector “Public, 4-year or above” to find Sector 1 institutions that have locked their survey.

NOTE: Users can select multiple criteria from the menu by holding down the Ctrl Key or Shift Key when making their selection(s).

Survey Update Date. Searches for institutions based on the date the institution’s survey data were last updated (in MM/DD/YYYY format).

Migration Status. Searches for institutions by Migration Status. This criterion is typically used in combination with other search criteria. For example, users can select “Migrated” in combination with the Sector “Public, 4-year or above” to find Sector 1 institutions where the migration process is complete.

NOTE: Users can select multiple criteria by selecting more than one checkbox when making their selections.

Migration Update Date: Searches for institutions based on the date the Migration Status last changed (in MM/DD/YYYY format).

User Last Name. Searches for institutions using the Multi-Keyholder or Keyholder’s last name.

NOTE: Users can search for institutions based on a partial last name (a minimum of one letter is required).

User Telephone. Searches for institutions using the Multi-Keyholder or Keyholder’s 10 digit telephone number without dashes.

NOTE: Users can search for institutions based on a partial telephone number (a minimum of one number is required).

User Email. Searches for institutions using the Multi-Keyholder or Keyholder’s e-mail address.

NOTE: Users can search for institutions based on a partial e-mail address (a minimum of one number, letter, or special character is required).

User Type. Includes the option to search for institutions that have only Multi- Keyholders as their Institutional-Level Users.

Address. Searches for institutions with all or part of the specified search criteria in the address provided for the institution during registration. For example, a search for the keyword “first” will return search results for both “200 First St.” and “4500 First Park Ave”.

NOTE: Users can search for institutions based on a partial address (a minimum of one number or letter is required).

City. Searches for institutions with all or part of the specified search criteria in the city provided for the institution during registration. For example, a search for the keyword “rock” will return search results for both “Little Rock” and “Rockville”.

NOTE: Users can search for institutions based on a partial city name (a minimum of one letter is required).

State. Searches for institutions using the state provided for the institution during registration.

NOTE: Users can select multiple criteria from the menu by holding down the Ctrl Key or Shift Key when making their selection(s).

Sector. Searches for institutions based on a specified institutional sector (e.g., Public, 4-year or above, Private nonprofit, 2-year, and so on).

NOTE: Users can select multiple criteria from the menu by holding down the Ctrl Key or Shift Key when making their selection(s).

Once the user clicks Submit, the Search Results screen is displayed. It includes the Institution Name with the Sector in parenthesis, Unit ID, OPE ID, Location, Status (ACT Code), Survey Status, Migration Status, and User (e.g., Keyholder’s) name, Telephone number, and E-mail address for all matching institutions. Administrative Users can select an institution from the list of search results. Once an institution is selected, the Institution screen appears and includes the Institution Name, Unit ID, Location, Status (ACT Code), OPE ID, Campus name, Campus Location, and the current completion status of the Identification screen for the related institution/campus at the top of the screen.

In addition, Administrative Users have access to the following within the CSS data collection software for the selected institution/campus:

Campus Maintenance. Administrative Users can select this link to view/edit the campus identification information submitted during registration, update the designated main campus, activate/inactivate an existing campus, or add a new campus.

View Call Logs. Administrative Users can select this link to access the OPE Help Desk application and search for open or completed Help Desk communications related to the selected institution.

View/Edit Identification. Administrative Users can view/edit the information submitted on the Institution/Campus Identification screen during registration.

View/Edit Universal Characteristics. Administrative Users can view/edit the institution’s universal OPE characteristics; such as, OPE ID, ACT Code, and whether or not the institution has a Parent/Child relationship.

NOTE: Administrative Users can also select the Restore Institution link from the top right hand corner of the Search Institutions screen to locate a closed institution and update their status (ACT Code) to “restore”.

View/Edit Keyholder Registration. Administrative Users can view/edit the information submitted for the Keyholder during registration.

View/Edit Coordination Tree. Administrative Users can view/edit Institutional-level Users’ permission settings, and/or switch primary responsibility for an institution from a Keyholder to a Multi-Keyholder, or vice versa.

View/Edit Users. Administrative Users can view/edit Institutional-level Users’ account information.

For institutions with more than one location, Administrative Users can navigate between each of the institution’s campuses (if applicable) using the drop down menu provided. When a new campus is selected, the Campus name, Campus Location, current completion status of the Identification screen, View/Edit Identification, View/Edit Coordination Tree, View/Edit Users, and the Survey menu (below) options are updated to show the relevant information for the selected campus.

The Institution screen also includes the Survey menu. This menu is organized into columns and includes additional options to assist Administrative Users throughout the survey review process.

The survey Name is listed in the first row along with the Survey Status, as follows:

Registration. The institution’s Keyholder has not updated the Registration screen; e.g., the institution has not yet accessed the survey.

Identification. The institution’s Keyholder has accessed the system and updated the Registration screen, but the Identification screen has not been updated.

Screening Questions. The institution’s Keyholder has updated the Registration screen and the Identification screen, but the Screening Questions screen has not been updated.

No Data. Each of the pre-survey screens (listed above) has been updated, but no survey data (e.g., crime or fire data) have been recorded.

Has Data. Contains some survey data.

Has Errors. Check for Errors reported errors in the survey data that must be corrected.

Clean. Check for Errors reported no errors.

Complete. The Multi-Keyholder or Keyholder has locked the survey.

Once the survey Has Data, the lock status is shown adjacent to the Survey Status (e.g., 0/1 locks or 1/1 locks). Please note, once all applicable locks have been applied, the survey is ready for migration.

Next, the Migration Status is listed, as follows:

None. The survey has not been locked.

Ready for review. The Multi-Keyholder or Keyholder has locked the survey.

Reviewed. The selected institution’s explanations and edit entries have been reviewed by an administrator.

Follow Up. The review process has been placed on hold by an administrator for additional follow up with the institution.

Accepted. All reported data have been accepted as final by an administrator.

Migrated. All reported data have been migrated by an administrator.

The following options are organized into their relevant columns and only available when applicable to the institution’s current survey status:

Compliance. Displays a Yes/No indicator of whether or not the institution is listed on the Non-Compliance List. Administrative Users can select Edit Compliance to update the institution/campus’ compliance status, as needed. This tool is located in the Compliance column.

Impersonate Locking User. Administrative Users can complete sections within the Survey to mock the permissions of the Multi-Keyholder or the Keyholder. When available, this tool is located in the Option column.

View Data by Screen. Administrative Users can view the reported data as entered on each screen throughout the survey; however, the user is not able to change survey responses. When available, this option is located in the View Data column.

View Crime Data. Administrative Users can view, print, or generate a PDF file of the crime data survey forms; however, the user is not able to change survey responses. When available, this option is located in the View Data column.

NOTE: This option does not include fire data. The user must select the View Fire Data option (outlined below) to view data from the current and prior year Fires - On-campus Student Housing Facilities screen(s), and the Fires-Summary screen.

View Fire Data. Administrative Users can view, print, or generate a PDF file of the reported fire data as it appears within the survey for the current and up to two prior year Fires - On-campus Student Housing Facilities screen(s), and the Fires-Summary screen. Similar to the View Data by Screen and the View Crime Data options, the user is not able to change survey responses. When available, this option is located in the View Data column.

View Error Report. Administrative Users can view all errors detected in the reported data, their severity, status, and any explanations provided by the institution in response to the flagged data items. In addition, Administrative Users have the option to Override errors, as necessary. When available, this option is located in the View Report column.

View Override. Administrative Users can view a list of any errors detected in the reported data that were overridden by an Administrative User. When available, this option is located in the View Report column.

Survey Log. Administrative Users can view a log of all Survey Status and Migration Status updates. The log includes the Logged Date and Last Update ID to indicate which user performed each action. When available, this option is located in the Log column.

View Screen History. Administrative Users can view a log of all Survey Screen updates.

The log includes the Campus ID, the applicable Screen name, the User Name (with User ID), and the logged Date and Time (e.g., the date/time of the system change). This option is located in the Log column.

Make Not Applicable. Administrative Users can select this option to make the CSS survey not applicable for the selected institution. This option is located in the Change Status column.

Additional menu options also become available once the survey is locked. This includes:

Impersonate View Only User. Administrative Users can view sections within the Survey to mock the permissions of the Institutional-level User, but are not able to change data. When available, this tool is located in the Option column.

View Caveat. Administrative Users can view/modify the data as it appears within the Review Caveat/Campus Description option on the Survey Navigation/Status screen.

When available, this option is located in the View Report column.

View Intentional Fires. Administrative Users can view/modify the data as it appears within the Review Intentional Fires option on the Survey Navigation/Status screen.

When available, this option is located in the View Report column.

Unlock Survey. Administrative Users can unlock the current survey for the selected institution. The “unlock” feature allows a user to make additional, perhaps unexpected, changes to the data entered. For example, during the review process, several spelling errors are reported by the administrator reviewing the data. The Administrative User unlocks the survey, allowing the Institutional-level User to correct the errors. When available, this option is located in the Change Status column.

Unlock Campuses. If the institution has several campuses, Administrative Users can unlock the current survey for one or more campuses. When available, this option is located in the Change Status column.

Additional reviews are also in place to automatically check for any inconsistencies in survey data that require further human investigation. Once the survey is locked, administrators can begin the migration (or “review”) process in preparation for data dissemination. The following additional utilities are provided in the Migration column of the Survey menu for this purpose:

Review/View Review. Opens the Quality Control Report. This report includes a list of edits that required the selected institution and/or campus to enter an explanation.

Administrative Users can use the Quality Control Report to review the selected institution’s and/or campus’ explanations, and edit entries as necessary.

Put Under Follow Up or Put All Under Follow Up. Places the review process on hold for the selected institution/campus or for the selected institution and all of its related campuses (when applicable). For example, during the review process, an Administrative User (Help Desk) determines that the information provided for an Explanation Edit may be unacceptable. The Administrative User marks the survey as in “Follow Up”; therefore, informing other administrators of the issue. The Administrative User can now contact the institution for more information and determine if the explanation is acceptable. Once complete, the administrator must select Return to Review or Return All to Review to continue.

Accept Data. Once the review process is complete, Administrative Users must select this option to accept all reported data as final.

Migrate. Once all of the above actions are complete, Administrative Users can Migrate the survey data.

In addition, the Review menu includes a “Review Checklist” for Administrative Users (primarily Help Desk and Help Desk Managers) to make notes throughout the survey review process.

For institutions with more than one location, a Campus Summary section is provided which displays the Campus Name, Status (ACT Code), current completion status of the Identification screen, and the Survey Status and Migration Status for each campus linked to the institution. For the administrator’s convenience, the Campus Maintenance link is also available here (in addition to its location at the top of the screen).

3.3 Skip Patterns

A complex algorithm, known as a matrix string, is used to dynamically manage work flow. This algorithm determines which screens are displayed, and which questions may be “skipped” (or marked as complete) based on responses to previous questions in the current survey, prior year data reporting, and/or information collected through registration. For example, an institution’s response to Question A may determine if Question B appears in the survey.

This method expedites the surveying process, and ensures faster, more accurate data entry.

Figure 3-2 shows how the CSS data collection software uses the matrix string to make intelligent screen selections based on the institution’s responses.

Figure 3-2: Intelligent Screen Selection

3.3.1. Matrix String Example

This section highlights a sample matrix string and outlines the individual digits used to populate that string. In the examples below, each number represents the position of the corresponding digit in the matrix string, e.g., “1” is the first digit in the matrix string, “2” is the second digit, and so on.

NOTE: Please understand the matrix strings presented in Table 3-1 and 3-2 are only examples and do not apply to the CSS data collection software. Examples 1, 2, and 3 have been included in this document to outline how a matrix string works.

Example 1: The following numbers in Table 3-1 represent digits in the matrix string specific to an institution’s characteristics:

Table 3-1: Matrix String Example Position of Digit Institutional Characteristic

1 School Type 2 Has Branch Campuses 3 Reports Comprehensive Fee 4 In Universe 5 Degree Granting 6 IC level (Award Levels Offered) 7 Control (Private or Public) 8 CALSYS (Academic or Program

Reporter)

Example 2: Table 3-2 outlines the possible values, Private or Public, for Digit 7: Control from Example 1.

Table 3-2: Position of Digit Example Possible Values Meaning of the Value

0 Private 1 Public

Example 3: Institution A is assigned the following Matrix String: 310112111110011110

What does this mean? Institution A is “Public”; therefore, it will only be required to answer questions applicable to public institutions.

3.4 Edits

Edit checks are performed automatically based on predefined rules stored in the database tables.

The grammar of these rules is designed to account for 90 percent of the complexity of the edits.

This allows the system to perform the edits quickly and accurately, while keeping the engine that runs them at a manageable data processing level. The remaining ten percent is managed through the use of specialized stored procedures written in the MS SQL Server database. This principle has proven to be the single most important factor in providing users with a reasonable response time when saving data entry screens.

Edits in the CSS Survey have three severity levels:

Fatal. This type of error will ultimately prevent the institution from locking the survey (which is a compliance criterion). If a data cell is flagged with a fatal error, the user must change the value of the cell (or, in some cases, other cells within the survey) to rectify the problem. However, special cases may exist where an institution does not always fit the presumed model. For this reason, the system contains a built-in utility which allows an Administrative User (i.e. Help Desk Manager (A2), Education Department (A3), or Super Administrator (A4)) to override fatal errors, when necessary.

In addition, the following fatal errors prevent the user from continuing to the next screen:

o Critical. Critical values impact the skip pattern and determine which screens are required for the institution. As a result, input is required in all critical value fields. This type of error occurs when an element that affects the screen flow is missing, or has a value inconsistent with the user’s response to other questions. The program cannot continue if it does not know which survey element to display next; therefore the data are not saved, and the user’s response must be modified before proceeding.

o Data Type. Data type errors check all input values against the data types as they are defined in the data dictionary (e.g., numeric, alphanumeric, and so

on) to verify that all entered data are the appropriate data type to save within that field in the database. For example, the user cannot enter a character in a field specified as numeric. In this case, the database will not allow the data of the wrong type to be saved and the user’s response must be modified before proceeding.

Explanation. This type of error is less severe than a fatal error. If a data cell is flagged with an explanation error it can be resolved through the user’s entry of a meaningful reason for the identified discrepancy in the provided text box.

Explanation errors require a great deal of work on the part of the Help Desk. The reasons provided by the institution must be reviewed, and unacceptable responses require a telephone call to the institution. For this reason, the system contains several built-in utilities to help validate submitted responses For example, a list of obvious and unacceptable answers has been compiled and is updated each year. These responses are automatically rejected by the system upon entry. In addition, several utilities are available to enable Administrative Users to generate a list of all explanation edits and responses for a specified institution, or group of institutions, for centralized review.

Confirmation. This type of error occurs if the value entered in a cell is unusual enough to raise questions, but not enough to require an explanation. In this case, the user is simply asked to click a button and confirm that the data entered are correct.

In addition to severity level, there are also four types of edit locations which tell the program when to execute the edit:

Screen. All of the information needed to execute this type of edit is available on the screen where the edit is performed. Since the value(s) in question are not affected by information entered on other screens, these edits are performed immediately when the data on each screen are saved.

Prior Year. These edits are executed similarly to screen edits; however, they must be differentiated within the system because of their dependency on prior year data values. Like screen edits, these edits are performed immediately when the data on each screen are saved.

Global. Typically, these edits include comparison and calculation edits that span multiple screens and data elements. Since the value(s) in question may be affected by information entered on other screens, these edits are performed upon completion of the survey when the user clicks Check for Errors to finalize their entries.

Both. Like global edits, these edits involve data from more than one part of the survey, and are typically subject to complex calculations. However, they are classified as type “Both” in cases where it is important to provide the user with immediate feedback upon saving a screen. As such, they are executed at both the screen and global levels. In order to achieve this quickly and efficiently, all necessary data from the related screens are included as “hidden fields” on the screen where the edit is performed. As a precaution, the system also executes these edits at the global level to ensure that no changes were made to the related data after the screen was saved.

Edits are generally created by adding “rules” to the database. This allows the development team to quickly and easily add new edits, and implement changes to existing edits. It also enables Administrative Users to view the full list of edits performed within the CSS Survey. A number of dynamic utilities are provided for viewing and/or managing the edits in the CSS Survey. For example, administrators can use the Edit Error Messages HTML utility to view all, or a subset, of edits within the system (by error type, error code id, severity, and/or override options). Using this tool, both the error message text and the edit characteristics can be modified, as needed. In addition, the system’s Screen Test tool gives Administrative Users a behind-the-scenes view of the survey screens. Due to the complex nature of this tool, a detailed description, navigation instructions, and specific examples are available in Appendix A: Screen Test Handbook.

Each edit rule is made up of the following:

Field ID. Each cell on the screen is assigned a unique number called a Field ID. The system uses this number to locate the cell and gather information for edits. Each time a screen is saved; the system generates a list of all Field IDs and then queries the edit rules table. The system completes this process to identify rules attached to those Field IDs. The strength of this method lies in the fact that when a data element is not required from an institution, the edit is not executed.

Sequence Number. This number is applicable when more than one edit is associated with a particular field.

Error Code. This is a unique identifier assigned to the error message displayed when the edit is triggered. Error messages are stored in a separate table, allowing use of the same error code for multiple edits.

Left Value. This value represents the left side of a comparison. This can be a constant, a data field, or a formula.

Comparison Operators. These represent the operand in a comparison (e.g., =, >, >=, <, <=, between, etc.).

Right Value 1/Right Value 2. These are the amount(s) compared with the left value in a comparison. (NOTE: Right Value 2 is used only for range checks.)

Condition. In a number of circumstances, data are compared differently based on the value of the field or the type of institution responding. In these cases, several edits may be implemented, and the system will determine which one to execute based on the specified condition.

Approximately 10 percent of the edits in the CSS Survey are too complicated to express in rules.

In these cases, the edits are instead created through stored procedures in SQL.

At the conclusion of the data entry process, when the Institutional-level User clicks on the Check for Errors option to finalize their entries, all edits are executed using a “technology external assembly” first introduced by Microsoft in 2005 with MS SQL Server 2005. At this time, the system queries several data tables to perform the required edits. Instead of cluttering the network by bringing the data from the database machine to the web server machine, the required edit checks are performed using programs that inhabit the same machine—with all calculations and comparisons executed as a native process to MS SQL Server. Once this process is complete, all of the resulting errors are stored in a single database table. This allows the system to respond to the web server machine with just one simple indicator—has errors or has no errors—upon completion.

This process is illustrated in Figure 3-3 below, which shows how a screen is processed when the user completes the required fields and saves the screen.

Figure 3-3: Processing the Screen

4 Reporting and Utility Functions

4.1 Institutional-level User Tools

Institutional-level Users can click on Forms for Printing/Reports in the main toolbar to access the following utilities.

The following sections apply to Institutional-level Users, as outlined in Section 1.7: User Characteristics.

4.1.1 Printable Read-Only Survey Form

Users can select View Form within this menu option to open a blank, read-only, and printable version of the survey screens. Many users prefer to print the survey, fill the numbers in on paper, and then enter this data into the system. Specifically, this utility opens a blank version of the survey screens that does not include any data entered for the specific institution.

NOTE: This tool is available to both Institutional-level and Administrative Users.

4.1.2 Survey Forms (Data)

Users can select View Form within this menu option to open a read-only, printable version of the specified section of the institution’s data. Specifically, this utility opens a version of the survey screens that includes any data entered for the specific institution. The survey screens available vary per institution and are broken into sections; such as, Institution Information, Crime Data, 2010 Fire Data, 2011 Fire Data, 2012 Fire Data, and Fire Data Summary. In addition, users have the option to print the forms or generate a PDF file.

4.1.3 Survey Status Summary

This option allows Multi-Keyholders to quickly view information related to all institutions within their auspices, including:

Institution Status. Lists the number of institutions within the Multi-Keyholder’s auspices broken down by Status (ACT Code). The following ACT Codes are available, and when applicable, appear in individual rows: Active, New, Restore, Closed, Merged, Non-Title IV, Administration Unit, Current Year (CY) No Data, Child Institution, and Online-only. In addition, Total (all Active) – which is the sum of the Active, New, and Restore statuses – and Total (grand total) are always displayed.

Figure 4-1: Institution Status

This feature allows Multi-Keyholders to quickly assess the total number of institutions under their auspices, as well as the number that are expected to complete the survey; e.g., Total (all Active), as demonstrated in the example above.

Survey Status. Indicates the number of institutions currently at each stage (Registration,…