technology operating guide tog - risd...technology operating guide – section 1 application systems...

Technology Operating Guide

TOG

R I C H A R D S O N I N D E P E N D E N T S C H O O L D I S T R I C T

2013 Table of Contents Technology Operating Guide (TOG)

Richardson ISD Technology Operating Guide Fall 2013

Section 1 ~ Application Systems Application Systems Development ............................................................................................................................. 1.1 Application Modification ........................................................................................................................................... 1.2 Application Systems Support ..................................................................................................................................... 1.3

Section 2 ~ Enterprise Applications/Oracle e-Business Suite Enterprise Software Maintenance ............................................................................................................................... 2.1 Oracle e-Business Suite Software Test Request (OEBSSTR) User Guidelines ......................................................... 2.2 Enterprise Applications System Performance ............................................................................................................ 2.3

Section 3 ~ Hardware Hardware Acquisition ................................................................................................................................................. 3.1 Hardware Maintenance ............................................................................................................................................... 3.2

Section 4 ~ PEIMS, Documenting and Coding Documenting and Coding Student Leavers ................................................................................................................ 4.1 PEIMS Procedures ...................................................................................................................................................... 4.2

Section 5 ~ Disaster Recovery, Network Support, Data Backup Data Retention and Backup ........................................................................................................................................ 5.1 Disaster Recovery ....................................................................................................................................................... 5.2 Email Server Support .................................................................................................................................................. 5.3 Emergency Response Testing ..................................................................................................................................... 5.4 File Structure and Maintenance .................................................................................................................................. 5.5 Modifications to Data Structure .................................................................................................................................. 5.6 Network Support......................................................................................................................................................... 5.7 Network Maintenance ................................................................................................................................................. 5.8 Network Modifications ............................................................................................................................................... 5.9

Section 6 ~ Security Environmental Security .............................................................................................................................................. 6.1 Logical Access Security ............................................................................................................................................. 6.2 Physical Access Security ............................................................................................................................................ 6.3 Virus Prevention Procedures ...................................................................................................................................... 6.4

Section 7 ~ Administrative Independent Audit ...................................................................................................................................................... 7.1 Outsourced Vendors ................................................................................................................................................... 7.2 Outsourced Vendor Service Levels ............................................................................................................................ 7.3 Software License Management ................................................................................................................................... 7.4 Strategic Technology Plan .......................................................................................................................................... 7.5 Technology Operations Training ................................................................................................................................ 7.6 User Education ........................................................................................................................................................... 7.7

Appendices Enrollment Verification ............................................................................................................................... Appendix A Intent to Withdraw ........................................................................................................................................Appendix B Withdrawal Questionnaire ............................................................................................................................Appendix C Leaver Reason Code Change Authorization Form ...................................................................................... Appendix D Secondary End of Year Checklist ................................................................................................................. Appendix E Secondary Fall PEIMS Checklist ................................................................................................................. Appendix F Elementary End of Year Checklist .............................................................................................................. Appendix G Elementary Fall PEIMS Checklist ............................................................................................................... Appendix H STR Screen Shots .......................................................................................................................................... Appendix I Netiquette ...................................................................................................................................................... Appendix J Archiving Outlook ....................................................................................................................................... Appendix K Glossary of Terms ........................................................................................................................................ Appendix L

Technology Operating Guide – Section 1 Application Systems Development, (p. 1 of 8)

Richardson ISD Technology Operating Guide 1.1.1 Fall 2013

Purpose and Scope

The purpose of this section is to detail the procedures for new application system and database development, and to ensure that new application systems that are acquired or developed, are appropriately implemented and function consistent with management’s intentions.

This section covers the process of new application system and database development.

Statements

It is the policy of RISD, in a manner consistent with management’s desires and expectations, that:

The Executive Director of Information Services (EDIS) and Deputy Superintendent (DS) shall approve all decisions to purchase or develop application systems in order to ensure that such purchases and developments are consistent with the organization system plans and strategies.

Under the supervision of the EDIS, the Information Services (IS) group is responsible for the new application systems development.

Systems development and maintenance projects shall be prioritized based upon organizational requirements, as well as frequently monitored to ensure successful completion. Without proper project planning and management, systems may be implemented that do not process reliably or meet user and organizational requirements.

The projects shall be developed in a separate development area and tested in the testing area before moving the application to the production area. Appropriate access restrictions shall be enforced in the Development, Testing and Production environments.

One of four industry standard system development life cycles shall be followed during all application development activities.

The Program/Project Manager (PM) shall ensure that all applications and data structures are designed to meet the strategic objectives of the organization.

The Executive Director of Instructional Technology (EDIT) is responsible for technology infrastructure; including raised floor space, physical and network assessments.

The impact of proposed hardware, application system, and system software changes shall be assessed and reviewed by the EDIT, or staff, before implementation into production in order to minimize disruptions to operations.

All the affected parties are to be notified in advance before implementing major application systems. Additionally, the implementation shall be scheduled so that the operations are least affected.

All the technical and user documents shall be appropriately created and maintained for all application systems.

The users shall be trained whenever new systems are implemented or when the old systems are modified.

Types of Projects

The projects undertaken by the IS department can be classified as Operational Projects or Capital Investment (bond) Projects:



• Operational Projects are those that are performed for the day-to-day operations, including application enhancements, “bug fixes,” change requests and reporting activities. The Budget Office allocates the required funds for Operational expenses. In a case where the budget exceeds the allocated funds, an additional request for funds is made with appropriate justification.

• Capital Investment (bond) Projects are those that require significant resources for implementation and are usually new development and large-scale upgrades. The required capital for this type of project is acquired through bond funds. Capital Investment Projects are financed through the funds from the bond issue; additional requirements for funds are approved based on new bond releases.

Planning and Budgeting

The planning and budgeting for operational activities for application systems development and maintenance shall be initiated in the early spring and completed before the end of the summer for the succeeding fiscal year (the new year starts on July 1st).

After the budget has been completed, the EDIS shall forward the budget to the DS for approval.

The DS shall review the budget and discuss with the EDIS the required changes and actions required, such as:

• Increasing/decreasing the cost

• Negotiating with vendors for competitive prices

• Rescheduling of the projects according to resource availability, etc.

The EDIS shall implement the required actions to meet the budget target set by the Budget Office.

After the Operational Budget is reviewed and approved by the DS, it shall be forwarded to the Budget Office. The Budget Office reviews the Operational Budget and either approves it or sends it back for justifications. If the budget cannot be met with the available resources, the EDIS shall work with the DS and provide the required justification for obtaining additional resources. The justifications shall be sent to the Budget Office and/or bond committee for additional resource requests (this process shall be performed iteratively until an agreement is reached).

The Budget Office sends the approved Operational Budget to the Superintendent’s Advisory Council (SAC) for approval and finally to the Board of Trustees for adoption of the budget.

Operational Budget

While preparing the Operational Budget, the following factors shall be considered:

• the salary for the technology personnel

• the cost of operations of the technology department

• license subscription or maintenance fee for software resources

• cost of implementation (e.g. consulting, customization, testing, training, etc.)

Capital Investment (bond) Budget

While preparing the Capital Investment (bond) Budget, the following factors shall be considered:



• Capital Investment Projects that are planned for next year

• Additional resources needed for current-year projects that are not yet complete, and continuing in the successive year

Operations Project Approval Procedure

Project Request

• The users shall request the new application system development services using the IS Service Request Form (available on the RISD intranet).

• The users shall enter in the details such as their name, phone number, email address, desired completion date, campus, category of service, category description, description of the service requested, list of all the persons in and out of RISD who would view the results or data, the name of the campus approver and the date of approval.

• This request is sent to the work order system, which notifies the appropriate PM through email that a request has been submitted.

Project Evaluation

• The EDIS shall enforce strict controls and ascertain that all the project requests are entered formally through the IS Service Request Form (available on the RISD intranet).

• The PM shall review the request to determine if the new application system development can be approved. The approval decision is based on the following criteria:

o Is the request realistic in terms of time and cost?

o Does the requester have the necessary permissions for obtaining the data/ service (prior approval or eligibility to request data or IS services)?

• The PM shall collaborate with the requester for additional information. If approved, the project can be assigned by the PM electronically via the work order system.

• The PM shall evaluate the service request to determine if it is a minor or major project. A project requiring less than 40 effort hours is classified as a minor project, and a project requiring more than 40 effort hours is classified as a major project. The PM can approve the minor projects through the work order system.

• For new and major project development, the PM will identify all the affected departments. The PM sends out an email to all the affected department heads with details about the project. Additionally, a project committee consisting of relevant personnel shall be formed. The chairperson will coordinate with the members of the committee and set up a schedule for the committee meeting. (The committee may meet more often during the initial phase and when problems are encountered. The frequency of meetings can be reduced when there are fewer issues.) The project committee shall approve the project plans, including major deliverables, timelines and tasks. The EDIS will review all project plans after initial scope is defined.

• The project committee and the PM shall consider the following factors when approving projects:

o whether the project meets the strategic goals of the organization

o impact of the proposed application on the organization



o impact of the proposed application during implementation on other systems

o impact of the project on the budget and other short- and long-term plans

• The PM shall prepare all the necessary approval forms and documents and maintain a separate binder (in electronic form or hard copy) for every major project, and provide for the EDIS to review.

In-House Development/Outsourcing Policies and Procedures

During the budgeting process, the EDIS and PM will determine the necessary skills required for meeting the project requirements for the forthcoming year. The EDIS and PM shall evaluate the outsourcing/in-house development options based on these requirements.

RISD uses contract personnel and outsourced service providers based on the project requirements. In most cases, contracted resources work directly under the supervision of the PM. Outsourced Projects will utilize at least one manager from RISD, along with the outsourced party, throughout the project.

Scheduling

As a general policy, the following factors are considered in determining the priority of the projects:

• the projects that have legal requirements to be fulfilled (e.g. reports to the government)

• the projects that can affect the operations adversely (e.g. failure of the paycheck printing process)

The EDIS can determine the project priority during the approval phase, and the priority levels can be changed according to the requirements to accommodate other projects.

Only the PM (the EDIS in the absence of the PM) or designee shall have the scheduling capabilities on the work order system.

IS Application System Implementation Procedures

Minor Project

• The PM shall assign the project to a developer or Database Administrator (DBA) for development and testing through the work order system.

Major Project

• The project committee, consisting of the users and technology personnel, shall assess the requirements.

• The project committee meeting shall be convened, and a chairperson selected (usually the PM chairs the committee).

o The project committee shall discuss and draft the requirements.

o The PM shall create new custom-designed forms for a listing of teams, project approval, testing, documentation of minutes of the meeting and maintaining them in the project binder.

• The committee chairperson or the PM shall propose a project plan to the committee. The committee shall analyze the proposed plan for feasibility (an informal cost benefit analysis).



If the project is feasible and approved by the committee, the PM shall assign the project to a lead developer and identify the project team.

• If the project is not feasible, then the following options shall be considered:

o Request additional funding: The additional request for funds shall be forwarded to the DS for consideration of other funding sources.

o Request more time for completion or request a reduction in scope: In the case of additional time requirements and reduction in scope, the EDIS shall advise the requester to resubmit the project request with necessary modifications.

o Decide that the project cannot be executed: If the project cannot be executed, the PM would announce the committee’s recommendation to all the affected parties, along with possible alternatives.

• The PM adjourns the project committee at project conclusion.

• The EDIS and PM will meet at project completion for post mortem.

Access Restrictions to the Development Environment

Access to information resources shall be restricted, based upon job responsibilities, to help enforce proper segregation of duties and reduce the risk of unauthorized systems access.

• Application developers shall generally be limited to accessing only the information specifically required to complete their assigned systems development projects.

• Computer operators normally shall be permitted to run production jobs.

• Access to production program libraries and data information shall be logged and periodically reviewed for appropriateness by the DBA. The DBA shall maintain a log of all the reviews and notify the EDIS in case of exceptions.

• Any direct access to production data or programs by application developers shall be logged by the DBA.

• The EDIS shall review the DBA log periodically to ascertain that appropriate access review has been performed and the exceptions have been notified.

Application Development

Requirement Analysis

• Minor Projects - The developer/development group shall interact with the project requester to assess the requirements. The requirements shall be documented in the work order system.

• Major Projects - The developer/development group shall interact with the project committee to assess the requirements. The requirements shall be formally documented and approved by the EDIS before beginning the next phase.

• The developer/development group is responsible for performing other activities as specified in the system development life cycle guide, according to the requirements of the project.

Design Phase

• The developer/development group is responsible for the design of the application.



• Major AND Minor Projects (other than data requests and minor modifications) - The design shall be reviewed by one other developer, PM or the EDIS. The design shall be well documented and maintained in the project binder.


Development Phase

• The developer/development group shall develop applications using design documents. Appropriate programming and documentation standards shall be followed.

• The developer/development group is responsible for performing other activities as specified in one of four system development life cycle guidelines, according to the requirements of the project.

Testing Phase

• Minor Projects - The developer/development group shall interact with the project requester to perform the testing process. The project requesters are responsible for providing the test data. For minor projects, users shall be required to sign a formal User Acceptance Form on the work order system via email.

• Major Projects - The developer/development group shall interact with the project committee to plan and perform the testing process. The project committee is responsible for providing the test data and test plans. The chairperson of the project committee shall coordinate the testing process.

• The EDIS, or PM, shall review the test plans to ascertain that the test data is representative and takes into consideration all the aspects such as capacity testing, interface testing and system testing.


User Acceptance Testing

• This is the responsibility of the project requester/project committee. Users shall perform testing before accepting or signing the User Acceptance Form on the work order system via email.

• Major Projects - The members of the requirements committee shall sign the User Acceptance Form for major projects.

• The User Acceptance Forms shall be maintained in the project binder (either electronically or hardcopy).

• After the user has accepted the project, the lead developer shall change the status of the project to “complete” in the work order system.

Implementation Phase

• The EDIS or the project committee shall coordinate with all the affected parties and decide upon a mutually agreed-upon time for implementing the new system in production.

• All the users shall be notified in advance about the migration to the new system.



• The time of implementation shall be coordinated with all affected parties, and the implementation shall be scheduled when there is the least disturbance to business operations, such as on weekends or during summer holidays, when activity is at its lowest.

• The EDIS shall coordinate with the DBA in order to ensure that backups have been completed before the implementation of the new system and data is recoverable.

• After the EDIS certifies that the software/system test has been performed, it goes to the person responsible for moving the application to the production environment.

• The implementer shall move the application into the production environment. The implementer changes status in the work order system to “installed”. Electronic notification and sign-off records are retained in the work order system.

• The PM is notified by the work order system via email that the status in the work order system has changed.

• The PM shall close the ticket in the work order system.

Design/Specification Standards

This is the responsibility of the developers. While developing new application systems, if changes or customizations are made to the 3rd party software, the changes are recorded in accordance with the recommendations from 3rd party vendor.

Programming Standards

The following programming standards are to be used in the Enterprise Application (e.g. EBS, SIMS, SAMS, etc.) environments:

• The developer-created objects start with “risd.”

• The developers include the name of the module in the name of any newly created objects.

The following programming standards are to be followed in the Century Star_Base™ environment:

• Developer-created objects start with “risd” when created and maintained in the RISDSIS schema.

• Developer-created objects in the STARS3, AHS, or OMNIBUS schemas shall end with the RISD customer id assigned by Century.

• The developers include the name of the module in the name of any newly created objects.

The DBAs or Application Administrator shall review all customizations for proper naming convention prior to moving them into production.

The DBAs or Application Administrator shall notify the EDIS if there are any violations in the above naming conventions. The EDIS will ensure that developers follow standards according to the naming conventions.

Documentation Standards

For the Oracle e-Business Suite™ (OEBS) environment, all the technical documentation shall be stored in the “OEBS” folder located on the “Sec Row” server. All the functional managers and



developers shall have access to this folder. The DBAs shall monitor the activities on this folder and ensure that the documents are not deleted without EDIS approval.

For the Century Star_Base™ environment, all the technical documentation shall be stored in the “Century” folder located on the “PDCMain” server. All the functional managers and developers shall have access to this folder. The DBAs shall monitor the activities on this folder and ensure that the documents are not deleted without EDIS approval.

The developers shall maintain appropriate documentation for application development activity.

For the OEBS environment, the developers shall complete the documentation and store them in the “OEBS” folder located on the “Sec Row” server.

For the Century Star_Base™ environment, the developers shall complete the documentation and store them in the “Century” folder located on the “PDCMain” server.

User Training

The training and support specialists coordinate the user training activities. The training and support specialists, PM, EDIS and functional managers determine the necessary training or the changes to the current training program.

For all major changes in business processes, the functional managers shall coordinate the training activities with training and support specialists.

For all minor changes in business processes, the functional managers shall communicate the change and required actions to be performed to relevant employees and monitor the change processes.

Vendor Management

RISD has maintenance contracts with almost all of its software vendors during the initial evaluation and purchase of new software; the maintenance contract options are also evaluated. The appropriate level of maintenance is selected based on the criticality of the application.

The EDIS maintains the contracts. Currently, the EDIS has the contract expiration schedule in the Outlook calendar, which automatically notifies of the expiration of the contracts. The EDIS renews the contract with the approval of the DS. A software contract log is maintained by EDIS.

A designated person from the General Counsel office initially evaluated the contracts. Contracts shall be evaluated each time a revision is made.

Contact Person: Executive Director of Information Services

Technology Operating Guide – Section 1 Application Modification, (p. 1 of 4)


Cross Reference: Application Systems Development

Purpose and Scope

The purpose of this section is to detail the procedures for modification to application systems and maintenance activities.

This section covers the process of modifications to application systems (including databases) and maintenance.

Statements


Formal vendor maintenance contracts shall be established for all purchased application system software after performing a cost benefit analysis.

Only the application vendors shall handle major modifications to the systems. For all minor modifications, the vendor-specified procedures are followed.

Management shall ensure that only the supported versions of the application or software are used and that new releases are implemented.

A common set of approved standards shall be followed in software development and maintenance activities.

All the documentation shall be kept current when the systems are modified.

System performance shall be monitored in order to ensure timely diagnosis of potential problems that affect service levels. If such indicators are appropriately identified and consistently monitored, management will be more alert to inefficiencies in the system’s performance that may require a response.

A complete backup of the system shall be taken before making any changes to the system.

Under the supervision of the Executive Director of Information Services (EDIS), the Information Services (IS) group is responsible for the following operations:

• New system development

• Application enhancements/“bug fixes”/change requests

• Reporting

All the other processes, such as project request, approval and scheduling, are the same as the Application Systems Development section of the TOG.

Maintenance Activities

The IS department performs two types of application system maintenance activities. They are:

• Application System Enhancement

• Bug fixes



Application System Maintenance Contracts

While making the software purchasing decision, management shall evaluate vendor maintenance contracts and establish a formal agreement with the vendors for application software maintenance.

Management shall analyze the service requirements and perform a cost/benefit analysis to select the contract terms.

The EDIS is responsible for maintaining and renewing the contracts. Also, the EDIS shall establish good vendor relationship.

Application System Enhancement

Management shall designate the Program/Project Manager (PM) to receive all the vendor communications regarding new releases of patches or enhancements. If possible, two or more persons shall be designated to receive vendor communications.

Determination of the Enhancements and Patches

• The designated PM shall also review the vendor maintenance websites for any communications regarding the enhancements and patches.

• If any relevant patches or enhancements are released, the PM or Database Administrator (DBA) shall notify the EDIS and functional management to determine if the patch or enhancement has to be applied.

Request for Installation of Enhancements and Patches

• The functional manager shall request the enhancement or patch application through the IS Service Request Form (located on the RISD intranet).

• The request shall be processed in the work order system as a project, and the EDIS shall assign a DBA to implement the project.

• The DBA or designated IS resource shall analyze the requirements for installing the patch and determine if any prerequisite patches are needed. The DBA shall record the requirements in the Software Test Request (STR) system.

Enhancement/Patch Testing

• The patches shall be applied first to the test environment for testing. The testing process shall be coordinated with the functional department.

• If the test is successful, the PM shall record the results in the STR system, changing the status to “testing complete.” An STR request is initiated after service request and change testing.

• The functional department shall perform the appropriate user acceptance testing and document user acceptance of the changes.

o The PM shall review the test results and approve the application of the patch or enhancements to the production system. The PM forwards results of testing to EDIS.

o The DBA will move the tested patches into production once all testing is complete. The DBA marks the STR as installed after moving the changes into production.



o If change is an enhancement, the application administrator will be notified after appropriate testing. The application administrator will install any enhancements/service packs.

o The PM and DBA shall ensure that a current backup has been completed and is readable.

o The DBA and PM shall coordinate the implementation program with all the affected parties and notify them in advance about the changes, as well as the implementation of changes.

o It shall be ensured that the changes are implemented so that normal operations are affected minimally.

Bug Fixes

• The functional users (financial, HR, payroll, purchasing) notify the IS personnel about bugs in the system via email.

• This request is entered into the work order system. Also, the work order system sends an automatic email notifying the IS Management (EDIS and PM) that a project request has been submitted.

• On receiving the notification email, the IS Management shall log on to the work order system and review the requests to determine if the bug fix project can be approved. The approval decision shall be based on the following criteria:

o Is the request realistic in terms of time and cost?

o Does the requester have the necessary permissions for obtaining the data/service?

• IS Management shall collaborate with the requester for additional information, if needed. The project shall be scheduled by IS Management electronically via the work order system.

• IS Management evaluates the project request to determine if it is a minor or major project. A project requiring less than 40 hours a week is classified as minor, and a project requiring more than 40 hours a week is classified as major.

• For a major bug fix project, IS Management shall identify all the affected departments. The EDIS shall send out a notification to all the department heads with the details about the project.

• The project scheduling and implementation procedures are the same as the Application System Development section of the TOG.

Change Control Process: (refer also to the Application Systems Support section of the TOG)

Performance Parameters

• EDIS shall determine the key application performance parameters that are to be monitored and ensure that appropriate tools are installed to detect abnormal performance. Automatic messaging tools shall be installed to notify at least two persons (the application system administrator and the EDIS). Appropriate escalation procedures shall be followed. The EDIS shall maintain the record of system listing, identified parameters, the employees who receive the alerts and appropriate escalation procedures.

Performance Monitoring



• The application system administrator shall monitor the parameters on a regular basis and maintain a log to record abnormal performance, such as trends and abnormal fluctuations. The application system administrator shall also notify the EDIS whenever abnormal situations are encountered.

Performance Log Monitoring

• The EDIS shall review the appropriate performance log and implement countermeasures.


Technology Operating Guide – Section 1 Application Systems Support, (p. 1 of 2)


Purpose and Scope

The purpose of this section is to ensure that users receive appropriate support so that application systems function as intended.

This section is effective for RISD Technology operations.

Statements


The Information Services (IS) organization includes a Help Desk function that acts on user queries regarding systems. Problems are recorded in a problem log. The Executive Director of Information Services (EDIS) monitors the log to ensure a timely resolution of all such user queries.

The EDIS is responsible for Enterprise Application support.

There are formal agreement(s) to obtain application or technical support from outside contractors and/or software vendors to ensure availability of such support.

Support requests are summarized and reported regularly to management.

Management monitors the nature and frequency of support requests to determine whether user training, support resources and/or documentation shall be improved.

Current user documentation for application systems is readily available to users.

Management monitors problem statistics and trends to identify and eliminate root causes of recurring problems.

Work Orders

When users request a change to an application program, whether it be via the intranet (IS Service Request Form) or phone call, it will be entered in the work order system.

1. The work order will be forwarded to the EDIS via an email notification.

2. The EDIS or Project/Program Manager (PM) will review the work order.

3. Based on the requirements, the EDIS or PM will assign the work order to a particular analyst through the work order system.

4. The analyst will receive the work order via an email message.

5. The analyst will make changes (as needed) based on the work order details.

6. The analyst who made the changes will perform system testing. The tasks of making changes and testing the changes shall be segregated when staffing permits. Responsibilities and roles shall be designed with consideration to appropriate segregation of duties. No one individual, when staffing permits, shall control all key aspects of a transaction or event. All affected parties shall be made aware that they have some responsibility for internal controls and security. Consequently, regular “campaigns” shall be organized and undertaken, at least annually, to increase awareness and discipline.

Technology Operating Guide – Section 1 Application Systems Support, (p. 2 of 2)


7. The user will be notified that the changes have been made via email or phone conversation. Communication shall be standardized via email, rather than telephone communication, in order to allow an audit trail to exist in support of all actions within the process.

8. An analyst will develop test scenarios with the user to ensure that all functionality requested is delivered.

9. The user will test the changes. Test performance shall be documented to ensure that testing was actually performed and that test results were as intended.

10. When the user is satisfied with the changes, the analyst closes the work order.

When the work order is complete, the analyst initiates the Software Test Request (STR) process.

If a work order is kept open past its due date, the EDIS and the assigned analyst will continue to receive email notifications that the work order has not been resolved.


Technology Operating Guide – Section 2 Enterprise Software Maintenance, (p. 1 of 2)


Purpose and Scope

The purpose of this section is to ensure that system software is appropriately acquired and implemented, and that it functions consistent with management’s intentions. Additionally, the purpose is to ensure that modifications to system software are implemented timely and are consistent with management’s intentions.

Statements

For the purpose of this section, “Management” is defined as being the Executive Director of Information Services (EDIS), Executive Director of Instructional Technology (EDIT), Executive Director of Student Information and Reporting (EDSIR), and Project/Program Manager (PM).


Requests for modifications to system software, including upgrades and fixes released by vendors, are approved by Management and implemented if consistent with the plans of Information Services (IS) and with Management’s intentions.

The EDIS is responsible for approving patches/upgrades. The EDIT is responsible for network infrastructure and communication links. The PM is responsible for testing and implementation of patches/upgrades.

The EDIS and PM review system performance reports, monitor that adequate action is taken upon identification of inefficient performance, and formulate and implement solutions.

The EDIS and PM monitor projects to ensure they meet the objectives specified, are completed on budget, and meet the time requirements, with respect to the implementation of modifications to application systems, data structures, and systems software.

The EDIT, or staff, monitors the existing, network and communications software to ensure system availability.

Enterprise Applications Software Implementation

New system software will first be tested in a test environment before migrating to the production environment.

• This testing will involve implementing the new software on test machines for a period of time determined by the PM.

• The network administrators and functional employees shall validate the integrity and accuracy of the new or modified system software, as applicable.

• The EDIS authorizes the move of tested system software to the production environment after it has been tested and accepted by the user. This move to production shall be documented so that all changes, irrespective of their origin, are implemented using change management process. Also, this process shall be documented to prevent changes from being deployed in production without the appropriate approvals.

Technology Operating Guide – Section 2 Enterprise Software Maintenance, (p. 2 of 2)


System Software Maintenance

Policy of Notification - If the software vendors have a policy of notification of upgrades and fixes through email, RISD shall designate the appropriate person to receive the email. At least two persons shall be designated to receive the emails, including the EDIS and/or EDSIR.

No Policy of Notification - If vendor notification is not available, the PM or EDSIR or designee will check for vendor updates or patches once a month. The PM or EDSIR or designee will notify the EDIS of any applicable patches that should be installed on the Enterprise Application.

Review of Fixes - The PM or EDIS will review the fixes for prerequisite and post requisite fixes, or upgrades.

Upgrade/patch Testing - The PM or EDSIR shall then perform testing of the upgrade or patch. There shall be a log with approval of all testing on upgrades/patches so that accountability is maintained on all changes. Moreover, RISD management shall ensure that an independent party tests changes in accordance with an impact and resource assessment in a separate test environment.

Upgrade/patch Approval - All patches and upgrades shall be approved by the EDIS before being implemented into production. This approval shall be included in the change management process. Additionally, the change process shall ensure that, whenever system changes are implemented, the associated documentation (e.g., authorization/approval log) and procedures are updated accordingly.

Escalation Procedures for Critical Updates/Patches

If patches/upgrades are deemed critical by the EDIS, EDSIR or PM, the patches/upgrades will be tested in the test environment. The emergency changes shall be recorded and authorized by IS management prior to implementation.

• The EDIS shall email the steering committee detailing the need to expedite a particular patch/upgrade. NOTE: Emails are indefinitely logged by the EDIS in an archive folder, as well as being backed up to a network server (which is backed up regularly).

• If the steering committee does not respond within one hour, the EDIS shall communicate directly with the Deputy Superintendent (DS) for approval. This approval shall be logged for audit purposes.

• The EDIS shall ensure that an email notification is sent to all users regarding system downtime.

• The patch/upgrade will then be applied to the production system. A log of applied patches shall be retained for periodic reference and/or review.


Technology Operating Guide – Section 2 OEBSSTR User Guidelines, (p. 1 of 16)


Purpose and Scope

The Oracle e-Business Suite™ (OEBS) Software Test Request (STR) (also referred to as OEBSSTR) is an automated method to track changes made to the OEBS Software environment. Change management is extremely important since the OEBS environment is rather complex. Requests are always submitted by a member of the Information Services (IS) staff whether the source requesting the change is an end user, a Functional Area administrator, or a separate IS Service Request Form (via the RISD intranet). The OEBSSTR and IS Service Request forms were created with an application called Remedy. Once a request is created, Remedy then notifies all appropriate approvers of the request via email using embedded workflow. As approvals are granted (via email and Remedy client) the request moves through the process ultimately being implemented and then marked with a status of complete

The purpose of this section is to provide detailed instructions for submitting, reviewing, approving, and completing an OEBSSTR for both the IS Staff and Functional Area administrators.

Statements


The Executive Director of Information Services (EDIS) is responsible for approving patches/upgrades. The Executive Director of Instructional Technology (EDIT) is responsible for network infrastructure and communication links. The Program/Project Manager (PM) is responsible for testing and implementation of patches/upgrades.

OEBS Software Test Request (OEBSSTR)

An OEBSSTR is submitted by a member of the IS Staff documenting the change request. This form includes all fields that are listed on its paper counterpart. Among the fields containing pertinent information are: a justification for the change, the functional areas that will be affected by the change, an attachment table for any Excel, Word, text, or bitmap images that further define the change, the test area to be used for the change, references to any other applications or documentation (Remedy or Oracle), diary fields to list any impact to hardware, software, custom environments, and notification/communication plans. There is a separate tab area defined for the approval process.

Once a new request has been submitted, two emails will be sent out to all the Functional Area administrators who will be affected by the requested change. The first email contains all of the request specifics and is for information purposes. The second is a customized email form than can be used to submit either an approval or rejection of the requested change.

When the request is approved via email by the Functional Area administrators, the OEBS manager is notified to approve the request. His approval of the request will in turn notify the IS Director. Once that approval is granted, notification will then go to the person responsible for implementing the change.

Once the change has been put into production, the implementer will update the status of the request and add any relevant comments to the work log. The OEBS manager is the final step in the process, reviewing the request and marking it complete. Time sensitive escalations are in place to ensure that no request is forgotten.



Creating or Updating an OEBSSTR – IS Staff Functions

This section covers the following typical data entry scenarios: 1) creating a new request; 2) querying a request; and 3) updating a request.

Creating a New Request

To create a new request, start the Remedy client if installed on your desktop or launch a web browser. If you have no attachments for the new request, you can use the following web address: http://risdreacts:8080/arsys/home.

Login with your user id and password. Remember that Remedy is case sensitive so check that caps lock button! A list of forms that are available to your level of permissions will be displayed (see picture below). Click the EBS Software Test Requests button in the list.



Step 1. Click on the New Request button in the upper left corner of the window. This will open a submit window of the form. Note that it says Current Mode: NEW in the left corner and that there is a button labeled Save in the left corner. If you see the word Search anywhere at the top of the form, you have inadvertently opened a search window. Notice that there are four tabs on the form: Request Info, System Performance, Approver Info, and Notification.



Step 2. Fill in all of the visible fields on the Request Info tab as completely as possible. The format for the Desired Completion Date field is mm/dd/yy. Be sure to select those functional areas that will be affected by the request.

Step 3. To add an attachment to the request click the Add button on the attachment table. A window will appear (see picture at right).

Step 4. Click on the Browse button and navigate to the path of the file you wish to attach. Highlight it by single clicking and then click the Open button (see picture below). When the dialog box closes and your file shows on the attachment table, you have successfully attached a document to the request.

NOTE: If using the desktop Remedy client, the steps are the same except that to start the process you right click with your mouse anywhere within the attachment table.



Step 5. If all of the needed information has been entered into the Request Info tab, click on the tab header labeled System Performance. The layout of the form will change (see picture below).

Step 6. Enter all necessary information into the fields, paying close attention to select the appropriate areas when there is an impact to a configuration that has been customized. At this point, there is no need to add or change information into the Approver Info tab as all the fields have been set to default values.



Step 7. Click on the tab labeled Notification to complete the remaining necessary information. The layout of the form will change (see picture below). Define what the communication plan is, the method that will be used, then list the name of the person responsible.

Step 8. At this point if you wish to send a courtesy email to someone outside of the approvers and implementers (perhaps someone else in the functional area). Type that person’s last name in the Enter Notification Last Name field and press the Enter key. Be sure that you capitalize the first letter remembering that Remedy is case sensitive. You will likely see a pop up list with all of the RISD employees matching the name you typed. Select the appropriate person, click Okay, and his/her email address will be added to the Names – Send Notification field. You may then add additional last names to continue the process.



Step 9. Enter the courtesy message that you wish to send in the Notify Message field. A pop up window will advise you that your courtesy message will be sent when you save the new request. At this point, you have entered all the necessary information to submit the New Software Test Request. After clicking on the Save button in the upper left corner of the screen a dialog box will appear (see picture at right).

Step 10. Click Okay to close the box and the automatic notifications will be sent via email.

Step 11. You can now log out of any Remedy windows or your web browser if you are finished.



Querying a Request

Login to Remedy. Click on EBS Software Test Request button to select it from the list of forms.

Click on the New Search button. This will open a search window (see picture below).

Notice the form title says “Search” in the upper left corner and there is a “Search” button in upper left corner. There is also a button called “Advanced”. Clicking this button will display a formula bar where SQL style search criteria can be entered. Further details about the advanced option are covered in the “Query Examples” section of this user guide.

A simple search can be made using the Query by Example method. This is done by entering specific information into the fields of the search form. For example, if you know the request number, enter it into



the Entry-Id field. Click the Search button and the request will then be displayed in a “Modify” form where it can be updated.

Selecting the Human Resources radio button and clicking the Search button will return a list of all requests where the functional area affected is Human Resources. The first request in the list will be highlighted and displayed in the “Modify” form. Selecting a different request from the list will cause it to be displayed in the “Modify” form (see picture below).

If you have tried different criteria and are only getting a pop up box that says “no records match,” you need to select Clear All from the list. It may be that a hidden field has inadvertently been auto-populated with data and is preventing your search from being successful. Also double check that you have used the proper case in text fields.

Updating a Request

After locating the request that you wish to modify, update the fields you wish to make changes to. Most commonly this will be a status change or an update to the Approver Comments/Work Log. (Managers would update the status of a request. Implementers would update a request status to installed and enter comments into the Work Log.)

After you have made your updates, you’ll notice that the Save button becomes visible. Clicking on the Save button will push all updates to the database. If you go to another ticket before saving your changes, you will be prompted by a pop up dialog box.

Completing/Rejecting an OEBSSTR – Manager Functions

Only a manager may mark a request completed or rejected. If the Functional Area administrator has rejected a request, the manager may also reject it. A manager may also reject a request that has been



approved by a Functional Area admin. This can occur if a change request is desired but cannot be implemented because of technical limitations or because the request violates policy.

Once the status of a request is changed to Rejected, a notification email goes out to all Functional Area administrators affected, the request submitter, and the IS Director. Reviving a request from rejected status can only be done by the Remedy Administrator.

When a request has been marked Installed, a notification is sent to the manager who then reviews the request to ensure all areas of concern have been addressed. He will then mark it completed and again, notification will go to the Functional Area administrators affected as well as the request submitter.

Approve/Reject an OEBSSTR – Functional Area Administrators

When an OEBSSTR has been created, immediate notification is sent via email to the functional areas impacted by the change request. The Functional Area administrators will receive two emails. The first email contains all of the request specifics and is for information purposes. The second is a customized email form than can be used to submit either an approval or rejection of the requested change.

Step 1. To send the approval or rejection, click the Reply button in your mail program. You need to be sure that the option to mark your comments with your name is turned off. When this option is enabled, it will print your name [doe, john] before entering the text you typed (see picture on next page). Remedy will try to process this extra information and since Remedy doesn’t recognize it as valid data, the approval or rejection will fail to update the request. (Directions are provided at the end of this section for disabling the “Mark My Comments” option.)



Step 2. Reply to the approval message. It is important that you enter the values requested within the email. Instructions can be found after the pound symbol (#).

Step 3. Enter your Remedy login id and password. Remedy is case sensitive and all user id’s and passwords should be lower case. If you need to have a password reset, contact the Remedy Administrator.

Step 4. Enter the status you wish to grant the request – 1 is Approval, 0 is Rejection.

Step 5. Enter any comments you have. These will be copied into the Request ticket. After you send the email back to the Remedy server, it will respond and tell you a new entry has been created. The number of this entry WILL NOT match the original request number. This is okay. All approval/rejection records are stored as child records to the master request form.

If you receive an email back from the Remedy server stating that there was an error, please double check your data entry and try again. If problems still persist, contact the Remedy Administrator.

If you send the wrong status, resend your entry with the corrected status. Remedy will update the request and remove the record with the older timestamp.



Disabling the “Mark My Comments” Option

Step 1. To disable this option, select Tools from the Menu Bar at the top of your mail program (see picture below).

Step 2. Click on Options.

Step 3. In the dialog box that pops open, click the Email Options (see picture below).



Step 4. In the dialog box that appears (see picture below), uncheck the box where it says “Mark my comments with:” Now click on the Okay button and this dialog box will close returning you to the first box. Click the Okay button again and you will be returned to the mail program. Once this is taken care of, you can continue the process to Approve/Reject an OEBSSTR.



Query Examples

The following are examples of common queries that may be useful. Please note the caveats listed for syntax when using the Advanced Query Formula bar.

Search by Status

This query will return all requests that are in installed, completed, or rejected status.

Step 1. You can use the Query by Example method if you want to look at requests with only a certain status, but what if you want to see all requests that are marked installed, completed, and rejected? You’ll need to use the Advanced Query Formula bar. Click on Advanced search in the menu bar of the search form and the advanced search formula bar will appear at the bottom.

Step 2. All radio button fields within Remedy have their value stored numerically. For example, with the status field, 0=New, 1=Area Approval in Progress, 2=Mgr Approved, 3=Installed, 4=Completed, 5=Rejected. Clicking on the field label will put the field name in the formula bar (click on the word Status in the form). You can also click on the fields button and select the status field from the list.

Step 3. Select the greater than symbol.

Step 4. Enter the number 2 to complete the formula. Of course, you could also enter ‘Status’ >= 3 if you would prefer. Here is what the formula looks like (see field at the bottom of the picture):



Search by Date

This query will return all requests created after 04/21/03 midnight and before 04/25/03.

Step 1. To search for requests within a given date range you must use the Advanced Query Formula bar. Click on the Advanced button in the upper right corner of the screen.

Step 2. Click on the Request Info tab on the search form, and in the lower left corner is the create date field. Click on the field label and you’ll see it added into the query bar.

Step 3. Next select an arithmetic operator (>, <, =, etc). To enter the date, you must enclose it in double quotes. See the following example:



Search Limitations and Help Documents

There are limitations as to what fields can be used in a search form.

• Searches cannot be performed on diary fields.

• Searches cannot be performed on the attachment table or the display table containing the child approval records.

• Remember that when doing a Query by Example on text fields the database is case sensitive.

• Search times can be reduced by avoiding the use of the != (not equal to) qualifier.

For other tips and tricks, click on the Help pull down menu on the tool bar. Selecting the Contents and Index menu item will launch a separate web browser window displaying a very useful help guide as is shown here:


Technology Operating Guide – Section 2 Enterprise Applications System Performance, (p. 1 of 1)


Purpose and Scope

The purpose of this section is to ensure that all production programs are executed timely and to normal completion.

Statements


The Executive Director of Information Services (EDIS) is responsible for monitoring Information Services (IS) operations within the Enterprise Application environments

Processing is monitored by management to ensure successful and timely completion, including a review and resolution of any exceptions.

Exceptions to normal processing are logged, reviewed by management and promptly resolved.

Batch and online processing procedures are defined to ensure that jobs and/or transactions are processed to normal completion or are recovered and reprocessed.

Operations Monitoring and Correction

The EDIS or a designee will use monitoring software to monitor the performance of the Enterprise Application systems. RISD management controls shall guarantee that sufficient chronological information is being stored in operations logs to enable the reconstruction, review and examination of the time sequences of processing and the other activities surrounding or supporting processing.

If a program, run by a user, is found to be slowing processing and accessibility of other users of the system, the EDIS will notify the user via email or phone call of the particular problem that the program is causing on the system (system slowdown, etc.). These communications shall be stored for at least three months for management’s periodic review.

The Database Administrator (DBA) will shut down the program in order to improve system performance and reliability.

If a user continually experiences problems while running specific programs, a software request for correction will be logged with the application vendor and the user will be given a time when their process can be run without impeding the workflow of others.

Only programs that have been approved by the EDIS will be run on the RISD enterprise application servers. Only the EDIS or staff can run programs or load scripts to be run on the enterprise application servers.


Technology Operating Guide – Section 3 Hardware Acquisition, (p. 1 of 2)


Cross Reference: Hardware Request Form (RISD Intranet)

Purpose and Scope

The purpose of this section is to ensure that acquired hardware is consistent with management’s intentions and also that hardware is implemented and functions consistent with management’s intentions.

This section details each phase of the methodology used to purchase hardware and is effective for RISD Technology operations.

Statements


The Executive Director of Instructional Technology (EDIT) is responsible for managing the bond purchasing process from initiation to completion.

The Bond Program Committee is responsible for the approval of all bond expenditures.

Management approves the acquisition of computer hardware in order to ensure that such purchases and developments are consistent with the organization’s system plans and strategies.

Projects are prioritized and assigned to ensure that limited information resources are utilized properly and support the corporate business objectives.

A formal methodology or process is used to guide the acquisition, development, or maintenance of hardware, application systems, network and communication software, and systems software.

Replacement parts and/or service are readily available for computer hardware used.

Hardware Purchases – not using bond money

A requester will fill out a Hardware Request Form (on the RISD intranet), obtaining the required signature approvals.

One of the following methods of purchasing will be used (the method used will depend on the scope of requirements):

• Compliance Bidder - When prequalified vendors, which are approved by the Purchasing Department, are used for a purchase. Three quotes are required.

• TCPN (Texas Cooperative Purchasing Network) - One quote is required. Bids are already in place for RISD to utilize within this network.

• Texas GCS QISV (Qualified IT Vendor) - Normally requires a minimum of three quotes from the QISV vendor network unless otherwise approved by the Director of Purchasing.

• RFP/RFI - Used for major projects (e.g. WAN replacement). There is no minimum number of bids. The best offer that satisfies requirements is typically used.

• Sole Source - When only one vendor is able to satisfy a requirement.

Technology Operating Guide – Section 3 Hardware Acquisition, (p. 2 of 2)


Hardware Purchases – using bond money

Bond Purchases - This includes purchases involving cyclical refresh items that were originally purchased utilizing the bond process or new requests for purchases or services (i.e. Compaq agreement). All purchase documents, sign-offs, approvals and forms shall be stored in a central location so that accessibility to all necessary information is efficient and effective. A person shall be designated the “record keeper” of all Technology (i.e. technology division) purchases.

If it is desirable to acquire products or professional services through bond funding, the item(s) will be presented to the Bond Planning Committee for consideration.

A Bond Acquisition Sheet (“blue sheet”) shall be filled out by the Program Contact (person requesting the purchase of goods or services).

A Requisition Request Form (“yellow sheet”) should also be completed, including detailed technical descriptions of the expenditure items within the bond proposal. This is the Purchase Order request form for Technology. The person making the request shall fill out this form. Additionally, this form will be used by Technology for all operating and bond purchase requests.

Bond Acquisition Sheet Approvals (i.e. signatures)

• The Director of Purchasing

• The Bond Program Financial Management

• If applicable, Facility Services, Legal, Technology and non-Technology personnel will sign the sheet (approvals are dependent on the types of goods or services being purchased)

• The EDIT will provide the final approval

NOTE: All bond expenditures must be signed off and approved by the bond committee.

Testing New Hardware

Before the hardware is purchased, testing plans shall be established so that implementation of the hardware is as efficient as possible. Hardware selection criteria shall be based on the functional specifications for the new or modified system and shall identify mandatory and optional requirements. Procedures shall be in place to assess new hardware for any impact on the performance of the overall system.

Contact Person: Executive Director of Instructional Technology

Technology Operating Guide – Section 3 Hardware Maintenance, (p. 1 of 2)


Purpose and Scope

The purpose of this section is to ensure that computer hardware is maintainable and supportable, and that modifications are implemented timely.


Statements


RISD has formal agreements to obtain application or technical support from outside contractors and/or software vendors to ensure availability of such support. Management monitors compliance with these agreements.

The Network Services Manager is responsible for maintenance of hardware as well as accuracy of this section of the Technology Operating Guide (TOG).

Replacement parts and/or service are readily available for computer hardware used by the organization.

Computer hardware includes self-diagnostic routines capable of alerting management or the appropriate vendor to potential problems or malfunctioning parts.

Current documentation for computer hardware is available and used during installation and maintenance of the hardware.

Maintenance/Support

Hardware maintenance and support is outsourced to M&A Technology, Inc. The contract is a five-year purchase agreement that is renewable annually.

Performance metrics will be maintained on remedial maintenance activity and will be reported monthly to the Executive Director of Instructional Technology (EDIT) by M&A Technology, Inc. The reports shall be adequately analyzed and acted upon.

Hardware Tracking/Relocation

Computer hardware will be tracked by the EDIT using the tag number on the hardware and the associated data from the Remedy system.

Furthermore, a form shall be required and communicated by the user community in order to move hardware from one location to another. Users shall be constantly reminded that hardware cannot be relocated without proper approval.

Personnel in the Fixed Assets department will document the information regarding physical hardware deployment in the Remedy database.

Hardware Inventory/Acquisition

Procedures shall be in place to ensure that only authorized and identifiable configuration items are recorded in inventory upon acquisition.

Technology Operating Guide – Section 3 Hardware Maintenance, (p. 2 of 2)


These procedures shall also provide for the authorized disposal and consequential sale of configuration items.

Moreover, procedures shall be in place to keep track of changes to the configuration (e.g. new item, status change from development to prototype). Logging and control shall be an integral part of the configuration recording system, including reviews of changed records.

Technology Help Desk

RISD Network Services Group (NSG) will hold bimonthly meetings to discuss the performance of the Help Desk function. Quarterly meetings including the EDIT, Help Desk management and the M&A Technology, Inc. support representative(s) will be held.

Trends and performance analyses are discussed in these meetings. The following metrics will be discussed:

• Call Volume

• Average Call Duration

• Call Abandonment

• Call Answered by Each Operator

• Average Duration of Call for Each Operator

The EDIT will maintain the records for the performance metrics for monitoring purposes.

Performance of the Help Desk shall be compared to best practices on a periodic basis and adjusted as appropriate.


Technology Operating Guide – Section 4 Documenting and Coding Student Leavers, (p. 1 of 6)


Cross Reference: FEA (LOCAL), FD (LOCAL), PEIMS Data Standards, Student Attendance Accounting Handbook (SAAH)

Purpose and Scope

The purpose of this section is to provide guidance and direction to District personnel charged with the maintenance and accuracy of student records for purposes of identifying leavers: dropouts, graduates and movers.

Terms

PEIMS (Public Education Information Management System) - maintains, through regular, periodic data submissions, a repository of student information used in determining school district accountability and funding.

Leavers - Students in grades 7 – 12 who were served during the prior school year and who have not enrolled in the current school year. Leavers include graduates, dropouts, and movers.

Dropout - A student with a leaver code that is PEIMS reportable as a 98.

Mover - A student who has been identified as having enrolled in another Texas Public School District via the PET system or other district approved means.

Graduate - A student who has met the course requirements for graduation and has successfully completed all parts of the required Texas state assessments.

Under reported – Students who were reported as served in the prior school year but are not included in the Fall PEIMS submission either as a currently active student or as a leaver.

PID (Person Identification Database) - System used by the Texas Education Agency (TEA) to manage and store identifying data on individuals who are reported to TEA. These individuals include: students and staff who are reported through the Public Education Information Management System (PEIMS) and recipients of high school equivalency credentials [based on the General Educational Development (GED) tests].

PET (PID Enrollment Tracking) – The PET Submission is a report of student enrollment information for the current school year.

Membership Reconciliation Process – Student membership from the teacher’s roster is to be reconciled to the attendance accounting records at the end of the first and fourth 6-week reporting periods. The reconciliation is to verify that all students are reported on attendance records and that “no show” students have been purged from the attendance accounting system (SAAH).

EDIT+ - Is a web-based software application which offers an interface for districts to transfer PEIMS data files to TEA, validate the data, and then generate reports.

Statements


Leaver reasons are determined by the campus 98 Principal responsible for accurate leaver data reporting for their campus in the PEIMS fall submission.

The Counselor is responsible for verifying the completeness and accuracy of graduate leaver records for their campus. This includes, but is not limited to, proper coding of graduate related fields that are



included on the 203 record and the accuracy and completeness of student cumulative records. Counselors are responsible for meeting with the Certificate of Completion (COC) students during the school start window to discuss Texas state assessment tutoring programs.

The Campus Student Data Specialist (SDS) is responsible for the accurate recording, maintenance, security, storage, and archiving of student records.

The Student Information Services Specialists:

• assists in locating movers on PET, dually enrolled students and PID corrections; and

• works under the Student Information Program Specialist to support and assist the Campus SDS in understanding the rules governing the accurate recording, maintenance, security, storage, and archiving of student records.

The Student PEIMS Coordinator:

• is responsible for relaying important PEIMS updates to all;

• coordinates the search for all 98s using all the reports, available in EDIT +, PET and the PET online system to assist in leaver tracking;

• coordinates PEIMS data review with data owners to ensure that PEIMS leaver data is complete and accurate.

The Executive Director of Student Information and Reporting (EDSIR) is responsible for developing and administering procedures that optimize the quality and integrity of data including the creation and administration of the automation of applications and reports used to enhance and support the leaver process.

The Executive Director of Curriculum and Instruction:

• ensures that the procedures outlined for the campuses are followed;

• gathers leaver data from the campuses;

• ensures processing, verifying and documenting accuracy of the gathered information; and

• ensures that data is forwarded to Student PEIMS Coordinator for PEIMS submissions.

Student Services:

• is responsible for assisting the 98 Principal in locating students who fail to attend; and

• filing necessary legal actions as required.

The Executive Director of Accountability and Continuous Improvement (ACI) is responsible for predicting completion rates and communicating changes to the accountability system that affect the leaver process.

The Executive Director of Curriculum and Instruction ensures that campus processing of leaver data complies with Appendix D of the reporting year’s PEIMS Data Standards.

The Executive Director of Curriculum and Instruction, the Student Information Services Specialists, the Student Information Program Specialist and the Student PEIMS Coordinator:

• support the efforts of the campuses and assist, as needed, with the selection of proper coding of various leaver situations;



• will be thoroughly familiar with both Appendix D of the reporting year’s PEIMS Data Standards governing leaver coding and the district/state standards governing acceptable supporting documentation; and

• assist and monitor the campus personnel involved in leaver coding.

Both the Student Information Services Specialists and the Student Information Program Specialist withdraw students only when the home campus cannot and only after written instruction from the home campus.

Leaver Reason Assignment and Data Entry

The Withdrawal Form must be signed and dated by the parent/guardian or adult student and a campus administrator.

The system data entry of the leaver reason is done by the Student Information Services Specialists and the Student Information Program Specialist at the request of the campus.

Students are withdrawn centrally at the request of the campus SDS. Leaver reasons are determined by the campus 98 Principal.

Any leaver reason code change made after the initial leaver reason assignment must be made using the Leaver Tracking Form (see TOG Appendix D).

All supporting documentation must be submitted with the Leaver Tracking Form.

Leaver reason changes made using the Leaver Tracking Form is reviewed and approved by the Executive Director of Curriculum and instruction.

Leaver reason changes will not be made without a completed Leaver Tracking Form and the supporting documentation.

All Leaver Tracking Forms must be signed by the campus 98 Principal.

All documentation must support the leaver code. Documentation requirements can be found in Appendix D of the reporting year’s PEIMS Data Standards.

The Student Information Services Specialists or Student Information Program Specialist makes changes to the student information management systems software as noted above.

The local codes used by the District that are changed by the Student Information Services Specialists or Student Information Program Specialist are:

Local Leaver Code

PEIMS Use Description

Leaver Type

41 98 Withdrawn to another RISD campus Dropout 42 98 Withdrawn to district AEP Dropout 43 98 Release from district AEP Dropout 44 98 Withdrawn from district AEP, but not released Dropout 45 98 Withdrawn to JJAEP Dropout

CE Not reported on the 100, 101, or

Confirmed enrollment in another Texas Public school has certified that the student has

Mover



203 enrolled on their campus. GED 98 Student has received a GED by Aug 31 Dropout COC 98 Certificate of Completion Dropout

CSS 98 Came to campus during the school start window ‐ used for COC students only

Dropout

PT Not reported on the 100, 101, or

203

Student has been located on the PET system as having been enrolled elsewhere after leaver RISD

Mover

TX Not reported on the 100, 101, or

203 TREx Request with date of entry Mover

The year-end process requested by the Student PEIMS Coordinator automatically codes all non-retained 12th graders as graduates and sets the withdrawal date to June 30th of the current calendar year in the Student Information System.

Under no circumstance will Student Information and Reporting change a leaver code from one value to another in the Student Information System without a written request from the campus.

Monitoring 98s

Beginning in February, Student Information and Reporting provides the Executive Directors of Curriculum and Instruction a listing of the current year 98s. This is a list of students who have left the district and are currently assigned a leaver reason equivalent to being considered a dropout. This report is produced monthly until the end of the year to assist in locating the whereabouts of these students.

Beginning the first week of school, all no-shows are to be identified and withdrawn in the Student Information System by the 3rd day of school.

• Student Information and Reporting assists the campuses with student listings to help identify no shows.

• Student with no schedules

• Student with excessive absences

• Student with no grades (end of six week)

The 98 Principal works with the Campus SDS to certify the list and make corrections to student records.

Every week during the school start window 98s lists will be regenerated and provided to the Executive Directors of Curriculum and Instruction and 203 records (including movers) will be provided to the Executive Director of ACI.

The Executive Director of ACI will produce a completion rate prediction weekly during the school start window using the most recent 203 record provided.



The 3rd week of school the Membership Reconciliation Process must be conducted to identify any additional no-shows. This process is repeated the last week of the 1st six weeks and 4th six weeks reporting period.

Monitoring Seniors

At the end of the school year a 12th grade student will be in one of 3 groups:

• Retained - Not enough credits to graduate.

• Certificate of Completion - Student has completed the credits required for graduation but the student has failed to pass one or more sections of the Exit Level assessments.

• Graduate - Student has completed the required course work and has successfully completed Exit Level assessments. This includes mid-term graduates.

Beginning May, Student Information and Reporting will provide lead counselors with a list of mid-term graduates and currently active 12th grades students.

The Campus Counselor verifies reports, makes corrections to senior data, and works with the Campus SDS to resolve any coding issues regarding, retention code, diploma type, certificate of completion date, and graduation date.

The Campus SDS will send all leaver code changes to the Student Information Specialists.

Prior to departing for the summer, the Director of Guidance and Counseling will obtain signatures of approval from the lead counselors once all corrections to the end of the year senior list have been made.

Review of PEIMS Edits and Quality Assurance Reports

The Student PEIMS Coordinator reviews all PEIMS errors concerning the 203 record and contacts campuses for corrections. Common errors will be identified and addressed during training sessions.

The Student PEIMS Coordinator reviews the list of under and over-reported leavers when available and makes corrections when necessary.

Errors that cannot be corrected are annotated with the reason the correction cannot be made.

All remarks are maintained for audit purposes.

The Campus SDS reviews and submits documentation for PID error corrections to be made by the Student Information Services Specialists.

The Student Information Services Specialists corrects the PID errors.

Any PID error that can be cleared online will be forwarded to the Student Information Program Specialist.

Any PID error that cannot be cleared by the Student Information Program Specialist online is documented and submitted to the TEA for manual intervention.

Updates, Training and PEIMS review

The Student PEIMS Coordinator will update the Executive Director of Student Information and Reporting and the Student Information Program Specialist on any PEIMS reporting requirement changes as soon as the information becomes available.



Training will be provided by the Student Information & Reporting Department on PEIMS reporting changes as necessary to all Campus SDS staff.

The Executive Directors of Curriculum and Instruction, Student Information and Reporting, and ACI will meet to discuss updates to the PEIMS leaver process bi-annually.

The Executive Directors of Curriculum and Instruction will train the 98 Principals on the Fall PEIMS updates regarding the leaver process.

After the Fall PEIMS submission, the Student PEIMS Coordinator will provide the data to all key personnel for review and acceptance.

Any corrections identified during the Fall PEIMS submission review should be reported to the Student PEIMS Coordinator. Prior to the resubmission, the identified issues will be addressed by the Student PEIMS Coordinator.

Storage of Records

In order to meet audit requirements, records will be stored in a manner that assures they are readily accessible, but within Family Education Rights & Privacy Act (FERPA) requirements.

The Student PEIMS Coordinator will adhere to the documentation standards put forth in the Student Attendance Accounting Handbook (SAAH) and PEIMS Data Standards.

PEIMS records will be retained and subsequently destroyed in accordance with State requirements.

PEIMS records, including leaver documentation, will be maintained for a period of at least five (5) years.

Contact Person: Executive Director of Student Information and Reporting

Technology Operating Guide – Section 4 PEIMS Procedures, (p. 1 of 2)


Cross Reference: TEA PEIMS Data Standards; TEA Student Attendance Accounting Handbook (SAAH); Performance Based Monitoring & Assessment System (PBMAS) Manual

Terms

PEIMS – Public Education Information Management System

PET – PID Enrollment Tracking

PID – Personal Identification Database

SDS – Student Data Specialist

TREx – Texas Record Exchange

SIS – Student Information System

Public Education Information Management System (PEIMS)

PEIMS reporting is not optional, it is mandated by TEA.

• PEIMS reporting encompasses: PEIMS submissions (including PID), PET data submissions, and TREx inquiries.

• Queries are run weekly by the Office of Student Information & Reporting to help validate/verify individual campus data accuracy.

• The Office of Student Information & Reporting will require that each campus review and verify a checklist of requirements for PEIMS submissions 1 and 3. Each item on the checklist should be initialed by the person responsible for the corresponding data. The checklist (list of persons who initialed the items) and the campus’ signature page (signed by the SDS and Principal) will be returned by the deadline given.

• It is imperative that what is entered in the SIS matches the records stored on the campus.

• Paper records must be stored on the campuses per the Records Storage requirements from Records Management.

PEIMS/PID

There are 3 PEIMS submissions of student data for a school year.

• Submission 1 represents the state of the district as of the Fall Snapshot date and includes students’ enrollment status as well as leavers and graduates.

• Submission 3 includes yearlong student attendance, course completions for grades 1 - 12, and disciplinary actions. All students with at least one day of attendance are reported.

• Submission 4 includes all students served in the Extended Service Year program, and Bilingual/ESL Summer School.

PET data submissions are made each week

• PET data submissions report student enrollment/withdrawal dates

Technology Operating Guide – Section 4 PEIMS Procedures, (p. 2 of 2)


• PET data submissions are required each week a district is in session based on the local instructional calendar.

• Student data must be entered by the campuses in a timely manner.

TREx (Texas Records Exchange)

• All campuses are required to use TREx to request/send student records from/to other Texas Public Schools (including Charter schools)

• Some private schools in Texas also use TREx

• Some colleges and universities in Texas will accept student transcripts via TREx

• The Office of Student Information & Reporting will provide training for Campus SDSs who use the TREx system.

Documents and Training

Staff development sessions for SDS and campus attendance personnel will be conducted each year by the Office of Student Information & Reporting. These sessions will cover TEA and RISD guidelines and policy, as well as system entry of accurate data recording and reporting. A packet of information, including the specific codes to be used for that school year, will be obtained by each campus’ SDS and/or attendance personnel at these sessions. Each identified SDS/attendance personnel will acknowledge receipt of the packet by signature. Additional meetings for updates will be held as needed during the school year.

Contact Person: SI&R/Student PEIMS Coordinator

Technology Operating Guide – Section 5 Data Retention and Backup, (p. 1 of 3)


Cross Reference: RISD Data Retention Schedule

Purpose and Scope

The purpose of this section is to provide the guideline governing the retention of RISD electronic data related to e-mail and other electronic data storage, the maximum amount of server storage permitted, and the method and timing for the backup of data.

This guideline is designed to ensure that RISD computing resource media space is available at all times while complying with the retention requirements set forth by the State of Texas. Space limits are thus set for RISD applications data and individual email accounts, and time limits are established on how long data may reside on the network server.

Statements


The Enterprise Backup Administrator (EBA), under the direction of the Executive Director of Instructional Technology (EDIT), is responsible for backup and retention of hard disks of all systems.

The Database Administrator (DBA) is responsible for backup of the Oracle e-Business Suite™ (OEBS) system.

State of Texas Mandates

The State of Texas mandates the requirements for retention of certain types of data. For example, the rules governing record retention for public school districts generally come from three sources:

• The Texas Public Information Act

• The Texas Library Commissions Schedule

• RISD’s Records Retention Schedule

The Texas State Library and Archives Commission require that academic records for grades 9-12, graduates and non-graduates, be maintained permanently. Academic records for grades K-8 must be maintained for 7 years after the date of withdrawal. “Withdrawal” means the date the student left the district or the date the student completed the grade level.

District Records

RISD maintains business and financial records for seven years. The RISD business offices maintain paper records to this standard. The data associated with individual e-mail accounts are considered RISD records and available to the public in accordance with the Texas Public Information Act.

The District’s Records Control schedule will be maintained prior to the deletion of any District record. For purposes of these guidelines, all references to a year mean a calendar year. After one calendar year, RISD data records not governed by the rules of the State of Texas or the RISD Record and Retention Schedule on file with the Texas Library Commission will be subject to archiving.

Prior to the removal of data records, permanent records defined by rules of the state of Texas will be archived and stored in accordance with the Texas policy. Data records defined by RISD Record Retention Schedule will be archived and stored in accordance with RISD guideline.

The guideline regarding e-mail and general data storage are described below.



E-Mail and General Storage Age Limit

• Personal e-mail, e-mail that is not in connection with the transaction of official business and data records will be archived by the individual if the individual wishes to retain the e-mail. The RISD e-mail administrator will delete e-mail that is older than 60 days.

• E-mail that is in connection with the transaction of official business and older than 60 will be archived in accordance with the procedures outlined in the “Procedures for Autoarchiving and Archiving Outlook (Static Profiles Only) and Procedures for Archiving Outlook (Roaming Profiles Only).” These e-mails will be retained by the owner of the e-mail in accordance with the guidelines above.

• General purpose data stored on RISD file servers in the SWAP will be deleted annually after the end of the school year. Personnel storing data on these servers must archive in accordance with the guidelines above. The archiving must be done prior to the annual summer break.

• Files not related to the daily operation or book keeping of district business will not be stored on the enterprise storage systems.

E-Mail and General Storage Space Allocation

• E-Mail storage will be limited to 300 Megabytes (MB) per person and enforced by a system quota.

• Facility general storage allocations include shared Swap (SWAP) space, staff user home directory allocation and Department (DEPT). Minimum allocations are as follows:

o Elementary 10 Gigabytes (GB)

o Secondary, 25 GB

o Administration, 70 GB

o DEPT – Determined by Departmental need

o Student storage allocations is as follows:

General Students 20 MB per person

Notification

• Facilities, whose data storage utilization reaches allocated space will be notified by e-mail. The notification will be sent to the campus principal and will include the following information for users considered to be in the top 10:

o User name

o File Type

o Space used

o Date of notification

Failure to Comply – General Data Storage

• In the event facility storage has reached capacity and notice has been sent to the facility principal but no action is taken by facility personnel to clear excess files from storage within 24 hours, designated technology personnel will search for and remove files which do not appear to be part of the districts daily operation or book keeping.



Recycling of Data Storage

• Data archived in RISD storage facilities containing information from RISD servers will not exceed 90 days. At that time the archived data will be recycled.

Backup Schedule

• The following table will be used for all network attached servers on the RISD intranet.

Device Type Backup Type Frequency

File Servers Incremental Weekdays

Exchange Server Full 3 Times / Week

OEBS Oracle Environment Full Daily

OEBS Oracle Archive Logs Full Daily

OEBS Unix File System Backup Full Monthly

OEBS Unix File System Backup Incremental Daily

Media Manager Responsibilities

• Ensure backups are performed per the schedule provided for each type of device.

• The media manager will document the information archived and sign and date the daily archive log. The Director of Network Technology will inspect these logs monthly.

Proxy Server Logs

• Proxy server log files are kept on disk for 72 hours. These files are not archived to media.

Contact Person: Executive Director of Information Services or Director of Technology Support Services

Technology Operating Guide – Section 5 Disaster Recovery, (p. 1 of 4)


0BPurpose and Scope

The purpose of this section is to ensure that, in the event of a disaster, essential business processes and Information Services (IS) can be recoverable.

This section is for Technology support operations.

1BStatements


An enterprise-wide disaster recovery plan has been prepared and approved by management, based on a business impact assessment. The plan is tested and updated to reflect the results of such tests.

A Data Backup Policy has been prepared and approved by management to ensure that:

• Automated data retention tools have been implemented to manage the backup and retention data plan and schedule.

• All media are stored in a secured, environmentally controlled location.

• Ongoing readability of backup and retained data is tested periodically through restoration or other methods.

• Management periodically reviews completion of backups to ensure consistency with backup and retention plans and schedules.

The Executive Director of Information Services (EDIS), Executive Director of Instructional Technology (EDIT) and the Director of Network Services (DONS) are responsible for the Disaster Recovery Plan.

The Enterprise Backup Administrator (EBA) is responsible for the backup of critical hard disks.

Database Administrators (DBA) are responsible for the backup of the mission critical applications storage devices including, but not limited to OEBS, Star_Base™, Kronos, Sub Finder, Remedy, and TMA.

2BDisaster Recovery Plan Creation/Maintenance

Personnel that shall be involved in the creation of the plan include representatives from all critical departments or areas of RISD Technology and Maintenance and Operations (M&O). The team shall include at least one representative of management, computing, security and building maintenance.

Performed by: DONS, EDIS, EDIT and other designated personnel

Frequency: ongoing maintenance of the plan is required

The steps below should be followed to update a plan.

• UActivation Authority U – This involves personnel who are given authority to activate the plan.

• UTask Organization U – The plan must spell out the titles and functions of each team member involved in the disaster recovery process. The individuals who will compose the team(s) shall be identified by title or position, as well as name. In a small business or department with only a handful of employees, the entire staff may become the Disaster Recovery Team, with one person designated to lead the recovery effort. The person named Recovery Director or



Coordinator must be given the necessary authority to act quickly and effectively during a salvage operation.

• UInformation Distribution ProceduresU – The plan must include specific methods for contacting team members and alternates, vendors, support agencies, suppliers, consultants and all those with whom special disaster contracts and agreements are in effect.

• USpecific Disaster ReactionsU – The plan must provide for both major and minor disasters and must address both individual and communitywide disasters, such as tornadoes and general flooding. The plan shall also give a definition in terms of business interruption as to what constitutes a disaster, thus automatically triggering the activation of the Disaster Recovery Plan.

• UTraining of EmployeesU – The recovery plan must also provide for both initial and ongoing employee training. Skills are needed in both the reconstruction and salvage phases of the recovery process. Initial training can be accomplished through professional seminars, special in-house educational programs, the wise use of consultants and vendors, and individual study, which would be tailored to the needs of RISD Technology.

• UPriorities for the Restoration of Essential FunctionsU – RISD’s Disaster Recovery Plan must define not only which functions are vital but also the order in which functions are to be restored. This is especially critical in the vital, complex computing functions where accounts receivable, payroll and accounts payable have fluctuating priorities throughout the month.

• UOngoing Review and Revision(s) of the Plan U – This involves periodic meetings with all personnel that are involved with the execution of the plan in the event of a disaster.

The EBA shall perform regular testing of backups at periodic intervals to ensure that actual recovery is achievable in the event that backup must be used to restore a system. Results of this test shall be retained for audit purposes.

Performed by: EBA

Frequency: at least monthly

3BData Backup Procedures

RISD Instructional Technology (IT) management shall establish housekeeping procedures designed to protect media library contents. Standards shall be defined for the identification of media and the control of their storage to support accountability. Responsibilities for media library management shall be assigned to specific members of the IT function.

Performed by: EBA

Frequency: based on the backup schedule established by management

• Two groups perform backups for RISD - Information Services (IS) for mission critical applications as defined above and Program Management for other systems. The EBA for IS shall be responsible for the backup procedures in these areas.

• Data shall be backed up incrementally, utilizing deduplication every night. An up-to-date media schedule shall be maintained that includes a listing of computers that are backed up and the time and date the backup is performed in order to better manage the backup process.

• RISD has an agreement with the City of Richardson for off-site storage of backup media at the Disaster Recovery facility.



UInformation Services Backup Procedures

• The IS department will back up the Production environment of the mission critical systems. The other environments, including test, can be restored from the Production environment.

• The production server’s data shall be backed up incrementally, utilizing deduplication every night. The backup is automated using a scheduler. The scripts create an online backup, which is, in turn, backed up by the enterprise backup system onto backup media. Additionally, the training and development servers will be periodically refreshed with production server data. Documented procedures surrounding the refresh of these servers from their respective production server shall be established. A log of refreshes shall be established, including personnel sign-off, time and date.

UBackup Monitoring

• The EBA and DBAs will receive an automatic email message from the enterprise backup system in the event of a backup failure. If the backup fails, the EBA and DBAs closely monitor the backup process the next day to see if the backup is able to be completed. The monitoring performed after a backup fails shall be recorded in a log so that all backup failures can be reviewed by management when needed.

• The EBA, as per the instructions from the DBAs, will perform the backup scheduling. The instructions will be issued through email. After the completion of the job, the EBA will inform the EDIS about completion of the changes.

UNetwork Services Group (NSG) Backup Procedures

• The backup procedures for the NSG department will be performed by the EBA and include all non-OEBS systems. An enterprise backup system will be used to perform the backups.

• RISD utilizes disk media for backing up the administrative and school servers. Data will be backed up incrementally utilizing deduplication every night.

• Usability of backups is regularly verified.

• The EBA will install the enterprise backup agent software using the administrator account and password as needed on production servers.

• The EBA will review the reports to determine any backup failures. The reports are not archived for any particular amount of time.

• In case of a failed volume backup, the EBA will work with the system administrator to identify the source of the backup failure and take corrective action.

• The EBA maintains all the reports either electronically or manually, for management’s periodic reference or review.

URestoration Procedures

• A user requests a restoration from backups via the Help Desk.

• The Help Desk forwards the request to the EBA.

• EBA locates, restores, and notifies user.

• RISD management shall implement a proper strategy for backup and restoration to ensure that it includes a review of business requirements, as well as the development,



implementation, testing and documentation of the recovery plan. Procedures shall be set up to ensure that backups are satisfying the above-mentioned requirements.

• The DONS or EBA will communicate, via email, the necessary changes to be made to backup parameters.

• The EBA will make the changes on the enterprise backup system.

• After the changes are made, the EBA will notify the DONS of the completion of the change. This communication shall be in an auditable format (via email or hardcopy communication).

Contact Person: Executive Director of Information Services or Director of Network Services

Technology Operating Guide – Section 5 Email Server Support, (p. 1 of 1)


Cross Reference: Responsible Use Guidelines (RISD Intranet, “Documents”)

Purpose and Scope

The purpose of this section is to ensure that email systems are adequately managed and maintained.

Statements

Email is maintained consistent with appropriate standards, guidelines and practices.

All users must sign an agreement, acknowledging they have read and agree to the Responsible Use Guidelines (RUG). The RUG is provided annually to all employees in the Employee Handbook and is available on the RISD Intranet under “Documents”.

Monthly Exchange Server Cleanup

A monthly cleanup of the Exchange server is performed by the Exchange system in an automated routine.

• Monthly, the Senior Network Engineer (SNE) reviews mailbox sizes of users.

o This weekly review shall be logged and reviewed periodically by the Executive Director of Instructional Technology (EDIT).

Disabling Email Accounts

Email accounts are disabled when HR communicates terminations.

• A determination of time shall be made as to how long accounts are able to be active without activity before disabling the account.

Contact Person: Director of Technology Support Services

Technology Operating Guide – Section 5 Emergency Response Testing, (p. 1 of 1)


Purpose and Scope

The purpose of this section is to ensure that emergency response functionality is available to all schools in the district.


Statements


Tests of emergency response capabilities at all schools occur bi-annually.

Logs of all tests are kept by the Executive Director of Instructional Technology (EDIT).

The EDIT is responsible for ensuring the tests are performed at all schools by the Technician.

Testing Emergency Response Functionality

An assigned technician will contact 911 centers and request permission to test 911 services. Given approval, the technician will coordinate a call from each facility to the 911 center. The assigned staff member will test emergency response functionality by dialing 911. When the 911 operator answers the call, the technician will provide his/her name, state that they are testing emergency response functionality and verify campus address information.

If the emergency response functionality fails, the technician will immediately open a trouble ticket with the RISD Help Desk.

This testing procedure will occur bi-annually for each campus.

Testing Logs

A log of activity will be generated. The date each campus is tested will be noted as well as the signature of the technician performing the testing. Logs will be forwarded to the EDIT by the close of business of the Monday following the week tested.

EDIT will maintain all logs of completed testing for one year.


Technology Operating Guide – Section 5 File Structure and Maintenance, (p. 1 of 2)


Purpose and Scope

This section outlines the Technology file server's file structure, how it is maintained, and the file types that are permitted/not permitted.

Directories

\SWAP directory

\SWAP is accessible to all users within the server's defined campus or users from other campuses as deemed necessary. All data in the \SWAP directory will be considered expendable and will be deleted at a predetermined age. Example: any document in \SWAP will be deleted annually.

\DEPT directories

All limited access directories created for departmental use under \DEPT will have the following:

• An assigned quota based on the departments needs.

• An assigned individual that is responsible for the data contained within the directory and its sub directories. Responsibilities include:

o Monitor the use of the department’s file storage for outdated, non-permitted, and irrelevant files that should be removed.

o Determine the need for and make requests (as needed) for quota extensions.

o Determine who should have assigned rights to the departmental data.

o Review bi-annual reports (provided by the technology department) detailing file access rights and the use of their assigned quota.

Reports are to be signed-off on and returned to the technology department.

Reports will contain information such as total file space used (by file type and/or subdirectory), identified aging or non-permitted files, and who has access to the data.

o Serve as the recipient of the report (outlined above) in the event the departmental data has reached the quota limit.

Home directories

The campus principal or designee will maintain similar responsibilities (see those listed above) for monitoring the user home directories.

• The campus principal or designee will not have file access to individual home directories.

• Reports, similar to those outlined for the business file system, will help the principal identify users with excessive storage, aging files, or non-permitted files in user home directories.

Non-Permitted File Types

File types that are not permitted on the general file system include:

• multimedia files of any kind including pictures, audio, video;

• disk images (e.g. .ISO files);

Technology Operating Guide – Section 5 File Structure and Maintenance, (p. 2 of 2)


• ghost files “Client images”;

• applications and/or installation source files;

• drivers;

• PST (email archive) files; and/or

• personal files (i.e. files unrelated to conducting RISD business).

Non-permitted files found on the file system are subject to deletion as needed with notice to the owner (if owner can be identified).

Exceptions to the non-permitted files can be made as needed for files that have a direct relationship to business. For example: Maintenance & Operations (M&O) uses photos as snapshots of ongoing construction projects.

Multiple copies of the same data are not permitted.


Technology Operating Guide – Section 5 Modifications to Data Structure, (p. 1 of 5)


Cross Reference: Application Systems Development (TOG), Application Modification (TOG), OEBSSTR User Guidelines (TOG)

Purpose and Scope

The purpose of this section is to detail the procedures for modification of the existing data structure.

This section covers the process of application system development.

Statements

For the purpose of this section, “Management” is defined as a group comprised of the Executive Director of Instructional Technology (EDIT), Executive Director of Information Services (EDIS), and the Director of Technology Support Services.


Management shall ensure that the changes to the data structure, including upgrades and fixes released by vendors, are approved by management before implementation and are consistent with information system plans and management intentions.

Management shall review system performance reports and monitor that adequate action is taken upon identification of inefficient performance.

Management shall monitor the entire data structure modification project and ensure that the project is completed within budget.

Modifications to the data structure shall be tested in a separate test environment. Testing shall be in accordance with test plans that include, as appropriate, interface, parallel, capacity and user acceptance testing.

Management shall ensure that all affected parties are contacted and that the actual implementation time is adhered to so that implementations cause the least disruption to normal operations. Additionally, all affected parties shall be notified in advance before implementing the modified data structure.

Before implementing the changed data structure, management shall ensure that the original environment is recoverable.

The data dictionary has to be updated whenever the data structure is modified.

Current documentation for the database and the database management software shall be easily available and used when installing and maintaining the database and/or application systems that use the database.

The Database Administrator (DBA) is responsible for alert monitoring on the application server.

The Executive Director of Information Services (EDIS) is responsible for overall database implementation.

Data Structure Modification Methods

The data structure can be modified by two methods:

• Applying vendor-supplied fixes, patches and upgrades (preferred)

• Manual modification



Management Approval

Data Structure Change Request: The requester shall request the modifications to the data structure through the IS Service Request form (available on the RISD Intranet).

Management Approval Process: This is performed by the EDIS (for minor projects) or the project committee (for major projects). The management approval, scheduling and implementation process for data structure modifications is similar to the Application Systems Development section of the TOG.

User Approval Process: This is performed by users after requesting a change through the Software Test Request (STR) or change management process established for the application.

Database Performance Monitoring

Setting Up Performance Monitoring Tools

• Management shall identify the critical servers that house the important databases and threshold parameters that are to be monitored and document them. Management shall ensure that the performance monitoring tools are configured to send out alerts when the system performance exceeds the threshold limits.

• The monitoring tools shall be configured to send the alerts to more than one person, typically to the DBA and via email to the EDIS and/or Project Manager (PM). The EDIS/PM shall follow up on the alerts and maintain a log of all actions taken. Management shall ensure that the settings are implemented correctly, review the settings periodically and maintain a log of all reviews.

Performance Monitoring/Responding to Alerts

• Upon receiving the alerts, the DBA shall log on to the server, analyze the problem, and try to resolve the problem. If the DBA is unable to access the server, the appropriate substitute or backup person and EDIS/PM shall be notified of the alert.

• The DBA shall notify the EDIS/PM about the problem and record the issue in the Performance Monitoring Log. The DBA normally shall adhere to the following steps:

o Check whether the server is running and has not shut down automatically

o Check the server parameters

o Check whether any hardware or network problems are encountered

o Coordinate with network services and hardware support to resolve the problem

• The DBA shall observe the system on a regular basis to monitor the system parameters and analyze the trends to note the patterns, such as shifts, fluctuations or timing of events. Any deviation observed shall be noted in the performance monitoring log, and the DBA shall notify the supervisors.

• When the problem is solved, the DBA shall analyze the cause, record the alerts in the log and notify the EDIS/ PM about the resolution. If any major action is necessary, the DBA shall coordinate with the EDIS and PM for approval and guidance.

• RISD shall record abnormal events in a performance-monitoring log.



Escalation Procedures

• The EDIS and PM shall review alert messages on a daily basis and determine whether any alert has not been resolved. The EDIS/PM shall coordinate with the DBA to ascertain that the problem has been resolved. RISD management shall implement a formal escalation procedure with appropriate time intervals for each escalation step.

Performance Analysis

• The EDIS, PM and DBA shall meet to analyze the performance-monitoring log every year to determine the root cause of frequently recurring or important problems. The changes to the data structure, hardware and software, or network infrastructure shall be considered. The remedial actions for the problems shall be considered and incorporated as a project in the current or succeeding year.

Modifications to Data Structure (Upgrades and Fixes)

Identification of Upgrades and Fixes

• The DBA and application system administrators shall proactively access the vendor support website to determine if any new patches or updates have been released.

• If the software vendors have a policy of notification of upgrades and fixes through email, RISD shall designate the appropriate person to receive the email. At least two persons shall be designated to receive the emails, including the EDIS and/or PM. An independent mailbox, monitored by the DBA, should be set up to receive all vendor notifications. When staffing changes occur, a new DBA should take ownership of the mailbox.

• If the DBA or application system administrators feel that any relevant upgrades or fixes might be needed, they shall notify the PM or EDIS through email or in person with a description of the upgrade and the business reason for applying the update. The PM or EDIS will notify the functional manager of relevant upgrades or fixes.

Selection of Upgrades and Fixes

• This is performed by the DBA (Principal Oracle Administrator and Application Administrators) and functional managers. The functional managers and the Oracle system administrators shall analyze the available upgrades and fixes, and make a request through the change management procedures established for the application to install to a test instance of the application.

Approval for Upgrades and Fixes

• All the upgrade and patch installations shall be approved by the PM (for minor projects) and/or the EDIS (for major projects). The PM shall assign the installation project to DBA. When the DBA are assigned to a project, the work order system automatically sends an email with the project number to the DBA, informing them that they have been assigned to the project.

Requirement Analysis for Upgrades and Fixes

• When the DBA receive the email notification, they shall log on to the work order system and analyze the requirements of the project. The DBA shall perform a review of the requirements with the EDIS, if necessary. The EDIS and DBA shall coordinate with the users to determine any additional requirements, such as prerequisite patches or any other installations needed.



Testing

• After obtaining all the requirements, such as any other prerequisite patches or fixes, the project shall be tested in a separate test environment. After the completion of the test, an IS staff member creates an STR for the DBA. A DBA shall set the project status to “complete” and log the test results in the work order system to notify the EDIS of the test results.

• If the test results are unsatisfactory, the PM and/or EDIS shall explain the reason to the user and suggest other available alternatives, and the EDIS shall close the project.

• Testing shall be performed in collaboration with the users. Users are responsible for providing the functional resources and test data. Management shall review all the test plans and ascertain that they include all aspects of testing, such as parallel testing, unit testing, system testing, capacity testing and representative test data.

• For the larger projects, the project committee or the functional managers shall sign the custom-made User Acceptance Form created by the EDIS. The EDIS shall maintain the User Acceptance Form in the project binder for major projects.

Implementation

• The EDIS or PM shall approve the project if the test results are satisfactory, either through email or the work order system.

• The EDIS shall coordinate with all the affected parties and determine the implementation schedule. The implementation shall be scheduled so that it causes the least disturbance to normal business operations. All the affected parties shall be provided with sufficient notice about the implementation and any possible system downtime. Unless the implementation is deemed an emergency, notification will be no less than five days prior to implementing the change.

• The EDIS and/or PM shall send an email request to the DBA to install the upgrade or the fix to the production environment.

• DBA shall ensure that the most current backup was completed successfully before installing the upgrades and patches. The EDIS and/or PM shall ascertain that the backup is complete and readable.

Installation or Upgrades and Fixes to the Production Environment

• After completion of the move request, the DBA shall change the status to “installed.” The work order system automatically sends an email notifying the user and the EDIS that the project has been completed and the system is in production.

• The DBA shall keep a log of all the upgrades and fixes that are applied to the production environment.

• Upon receiving the completion notification in the work order system, the EDIS shall change the status of the project to “close” in the work order system.

Documentation

• When the fixes or patches are installed, they automatically update the relevant documentation that is built into the system. For application of a system that does not have the built-in documentation, the DBA shall update the documentation manually.



• Management shall ensure that the data structures are updated when changes are made and that a log of all changed data structures is maintained as a part of the documentation.

• All necessary documentation shall be made available to the DBA and developers as a physical copy or maintained in a shared drive for reference.

Project Management

The PM shall monitor the progress of the project by reviewing the daily status of all “open” or “in progress” projects. The PM shall take necessary actions to manage the project within the budget and available resources. The PM shall notify the EDIS if any significant issues are encountered.

Manual Modifications to the Data Structure

RISD does not perform manual modifications to the data structure for the applications for which a vendor maintenance agreement has been established. Vendor services are to be sought according to the agreement for such modifications (such as Oracle’s e-Business Suite™).

The manual modifications to the data structure that are the outcome of application system design and modifications shall be approved by management and implemented according to the policies and procedures for new application system development and modification to application systems. Please refer to the Application Systems Development and Application Modification sections of the TOG.


Technology Operating Guide – Section 5 Network Support, (p. 1 of 4)


Cross Reference: Hardware Acquisition (TOG), Hardware Maintenance (TOG)

Purpose and Scope

The purpose of this section is to detail the procedures for implementing a new network infrastructure.

Statements

For the purpose of this section, “Management” is defined as a group comprised of the Executive Director of Instructional Technology (EDIT), Executive Director of Information Services (EDIS), and the Director of Network Services.


Management shall approve acquisition of network and communications software and systems in order to ensure that such purchases and developments are consistent with the organization’s system plans and strategies, and the prescribed ordering procedures shall be followed.

Projects shall be prioritized and assigned to ensure that limited resources are utilized properly and support the corporate business objectives.

Network and communication software and hardware are initially installed and evaluated in a test environment using appropriate test plans before implementation.

While making changes to the system, all affected parties shall be contacted, and the timing of such modifications shall be coordinated with them to ensure minimum impact on other processing activities.

The documentation and topology diagrams for the network systems shall be kept current and be easily accessible to users.

An impact analysis shall be performed to assess the effect of new systems or proposed changes.

The EDIT is responsible for the overall network infrastructure.

The Director of Network Services (DONS) is responsible for the operations of the Network Services group.

Capital Investment (bond) Projects

The projects undertaken by the Network Services group are classified as Capital Investment (bond) Projects. These are projects that require significant resources for implementation and are usually new development and large-scale upgrades and maintenance activities. The required resources for this type of project are acquired through bond releases.

Budgeting

The DONS will prepare the budget, taking into consideration the following factors:

• Cost of training

• Cost of maintenance contracts

• Cost of software and hardware needed



The budgeting activity is to be initiated in early spring, and the budget estimates shall be forwarded to the EDIT. The EDIT will review the budget and suggest modifications. Also, the EDIT would include the Network Services group’s budget in the overall master budget.

New Project Request

The Technology Bond Manager would email the DONS for quotes regarding the requirements of the new projects that have been planned under bond funding.

The DONS shall request quotes from the vendors (state-authorized) or estimate the funds required for the new project, and forward them back to the technology bond manager and the EDIT.

The Technology Bond Manager shall work with the EDIT for approval of the project through issuance of bonds. Please refer to the Hardware Acquisition and Hardware Maintenance sections of the TOG.

If the project is approved, the EDIT would place the orders, and the purchasing department would purchase the required products.

Network Device Inventory

The inventory of the Network Services department includes internetworking and communications devices, such as routers, hubs and switches, phones along with connectors, such as cables and wires.

The hardware equipment required by the Network Services group is maintained at two places:

• The warehouse

• Network device pool at the Annex building

In order to maintain an efficient service, the network device pool is maintained at the Annex building so that the employees have easy access to the inventory database, and faster service is provided. The Senior Network Engineer (SNE) maintains inventory for the network device pool at the Annex building.

After the project has been approved and a purchase order has been issued for the required devices, the employees can use the devices from the network device pool and refurbish the pool once the actual device is delivered.

Inventory Receiving Function

• The incoming new network device from the suppliers can be delivered to the warehouse or the Annex building (network device pool), according to the request from the DONS, or to the warehouse located on Security Row.

• For the devices that are supplied to the warehouse, warehouse personnel shall tag the goods with an asset tag and record them in the Remedy system.

• The devices delivered to the Annex building (network device pool) shall be tagged by the DONS or SNE. These tags are recorded in a spreadsheet that feeds the hardware inventory module of the work order system. Reconciliations shall be conducted between the spreadsheet records and the Remedy records at least once a year. Only the SNE is authorized to make changes to this asset tag spreadsheet.

• The network devices will be kept in a locked room, and only the technicians in the Network Services group shall have access to this network device pool.



Project Management

The Network Services group manages two types of projects:

• New projects

• Maintenance projects

The DONS will schedule the technicians on the available projects according to the structured rule-based policy.

Analysis and Design

The Network Services group would analyze and design the architecture and send it to the EDIT for approval. If the necessary technical expertise is not available, outside professional help shall be sought.

Testing

The Network Services technicians shall test the new design or equipment in an environment that is separate from the main Network Services. If possible, the Network Services group shall implement a pilot project on a smaller scale before adopting the implementation for the entire network.

Before implementing any changes to the network, the Network Services group will provide at least one week of advance notice to the users about changes and any associated disruptions that may be caused. A policy shall be established outlining acceptable timelines of implementation.

The need for communications with the other groups, such as Help Desk, Telecom and Technical Support, are to be reported to the EDIT. Additionally, the EDIT shall coordinate the communication among different groups under Technology Program Management.

Outsourcing

When the required skills are not available internally, the services are contracted to outsourced vendors. The EDIT is responsible for maintaining the contracts and Service Level Agreements (SLA), and evaluating the vendors.

Security

Physical Security: The network devices shall be installed in a physically secure area, such as a lockable closet or closed room. The Network Services Manager shall evaluate the physical security of the network components pool.

Managing Network Parameters: The network device parameters (IP address, passwords, etc.) are maintained on a spreadsheet by the SNE. Only the SNE is authorized to make changes to the spreadsheet. Furthermore, when a new device is added, all the details are to be added to this spreadsheet; when the devices are taken out of service, they are removed from the spreadsheet. There shall be consistency regarding this procedure in order to ensure that network parameters that are on file are reliable and accurate.

Documentation: The Network Services Manager will maintain all design and topology documents. These documents shall be kept current and easily accessible to all technicians.



Firewalls and Network Logical Access Security: The firewall and other network security tools will be properly configured and regularly monitored to detect intrusion. The SNE shall maintain the list of all network security configurations. Management shall implement procedures to monitor the logs and tools regularly to detect any possible intrusion.

Encryption: Management shall implement appropriate encryption standards to ensure secure data transfer across the entire network.


Technology Operating Guide – Section 5 Network Maintenance, (p. 1 of 2)


Purpose and Scope

The purpose of this section is to detail the procedures for network support services.

Statements

For the purpose of this section, “Management” is defined as a group comprised of the Executive Director of Instructional Technology (EDIT), Executive Director of Information Services (EDIS), and the Director of Network Services.


Management should establish formal agreements to obtain application or technical support from outside contractors and/or software vendors to ensure availability of such support. Management monitors compliance with these agreements.

All modifications should be tested in a test environment before actual implementation.

All modifications and implementation of new systems and changes should be coordinated with the affected parties, sufficient advance notice should be provided, and Implementation should be carried out so that it causes the least disruption to normal operations.

Management should review system performance reports and monitor that adequate action is taken upon identification of inefficient performance and that the solutions are implemented.

Implementation should be performed in a manner that allows the original environment to be restored, if necessary.


The Director of Network Services (DONS) is responsible for the operations of the Network Services group.

Problem Notification

The Network Services group is notified about the problems in the network through: 1) Help Desk; and 2) “Management Station”—Network management software.

In both cases, the DONS (apart from technicians) receives either an automatic email or text message about the problem.

Help Desk

The users call the Help Desk to report problems with computer equipment. The Help Desk documents the user problem. Then, the Help Desk personnel analyze the problem, and if it is a network-related problem, they assign it to the network group. In addition, the DONS is notified via an automatic email about the service request through the Remedy system.

Management Workstation

For network monitoring, RISD uses a management workstation. The management workstation detects the faults in the networks and is set to automatically text/email the appropriate technician.

Technology Operating Guide – Section 5 Network Maintenance, (p. 2 of 2)


Only the Senior Network Engineer (SNE) and the DONS should have privileges to change the settings of the management workstation.

Management shall establish formal problem escalation procedures, as well as root cause analysis procedures.

Network Maintenance

• The Network Services group will maintain warranty agreements for the equipment during the initial bulk purchasing. If any equipment is to be brought as a replacement, the equipment is aligned to match other equipment in that lot or network.

• The DONS will maintain the service and warranty contracts. The service contracts are renewed when the vendors approach RISD for renewal. A tracking process shall be followed for warranty contract agreements.

• The Network Services group is involved in preventive maintenance activities, such as monitoring the life of Uninterruptable Power Supply (UPS) systems and changing the batteries when they are needed. The preventive maintenance activities receive last priority and are generally scheduled during summer.

Testing

• All the modifications to the network shall be tested in a test environment or implemented as a small test drive before actual implementation. The DONS shall review and approve all the test results and implementation.

• The DONS shall contact all the affected parties and coordinate the changes so that the least disturbance is caused to normal business operations.

Emergency Services

• Any emergency services (such as “core” network failures) during the normal working hours of the Help Desk are forwarded by Help Desk personnel to the DONS via the Remedy system or through telephone call. The DONS will reassign the schedule of the technicians to deal with the emergency.


Technology Operating Guide – Section 5 Network Modifications, (p. 1 of 2)


Purpose and Scope

The purpose of this section is to detail the procedures for requesting infrastructure modifications and support services.

Statements



Management should establish formal agreements to obtain technical support from outside contractors and/or software vendors to ensure availability of such support. Management monitors compliance with these agreements.

All modifications and implementation of new systems and changes should be coordinated with the affected parties, sufficient advance notice should be provided, and Implementation should be carried out so that it causes the least disruption to normal operations.

Management should review system performance reports and monitor that adequate action is taken upon identification of inefficient performance and that the solutions are implemented.

Implementation should be performed in a manner that allows the original environment to be restored, if necessary.


The Network Services Manager is responsible for the operations of the Network Services group.

Requesting Network Modification

Fill out and attach the Data and Projector Network Modification Request Form (on the intranet under computer and technology related “Forms”). Have the form signed and dated by the RISD campus principal or director level and above (if the request is for funding by Technology, approval by the EDIT is required). On a copy of the building fire drill plan, note where you wish the modifications to take place.

Submit the request form and a copy of the fire drill plan to the RISD Network Project Manager.

The Planning Process

The RISD Network Project Manager will determine if the request meets the RISD network standards for the requested connections. If the requested connections are outside of RISD standard guidelines, the campus must provide the funds for the connections. Requests for nonstandard connections must have the area assistant superintendent’s approval and signature.

A copy of the cost estimate and an RISD Inter-Department Funds Transfer Form will be sent to the requester.

Technology Operating Guide – Section 5 Network Modifications, (p. 2 of 2)


The Acceptance Process

The principal or department head must fill out the RISD Inter-Department Funds Transfer Form, then sign and date both it and the cost estimate and work authorization forms.

Return the completed forms to the RISD Network Project Manager.

The Implementation Process

The RISD Network Project Manager will schedule the work and notify the school principal or department head of the dates the work will be started and completed.

The RISD Network Project Manager will follow up to ensure that the work was done to the satisfaction of the school principal or department head.


Technology Operating Guide – Section 6 Environmental Security, (p. 1 of 3)


Purpose and Scope

The purpose of this section is to detail the procedures for environmental security over information services and assets.

Statements


Management shall periodically monitor the effectiveness of the environmental control mechanisms and assess the business impact of potential threats to physical information resources.

Management shall implement adequate hazard detection and prevention mechanisms to protect the data processing environment from damages.

Environmental conditions of the data center (e.g., temperature, humidity) shall be monitored and regulated.

The physical location and design of the computing facilities shall limit its vulnerability to environmental threats (e.g., wind, water, fire).

The Executive Director of Instructional Technology (EDIT) is responsible for the overall security against environmental threats.

Planning and Monitoring of Environmental Controls

The nature and extent of countermeasures shall be based on management’s periodic assessment of the business impact of any potential threat. Such assessment shall consider:

• the likelihood of a particular threat occurring

• the criticality of the information resources that would be affected by a particular threat

• the operating losses incurred as a result of a processing interruption

• the likely cost to recover if a threat did occur

Management shall consider implementing controls including, but not limited to:

• Power Controls:

o Uninterruptable power supply (UPS)

o Generator for UPS

o Proper electrical grounding

o Electrical surge protectors

o Emergency off switch

• Temperature Controls:

o Humidity monitors

o Separate air conditioning system strictly for use by the computer room

• Fire Protection Controls:



o Manual fire alarms

o Smoke detectors

o Water sprinklers

o Hand-held fire extinguishers

o Dry pipe systems

o Fire suppression systems

o Fireproof walls, floors and ceilings surrounding the computer room

o Dust-limiting ceiling panels and floor tiles

o Anti-static flooring

o Fire-resistant office materials

o Regular inspection of facilities by the local fire department

• Location Controls:

o Computer rooms in locations that reduce risk from automobile traffic, visitor entrances and other public interference

o Computer rooms located above the basement level, thus reducing flood risk

o Computer rooms located to limit damage from broken water pipes or electrical wiring

o Data centers located away from significant road, railway and air traffic; high-crime areas; or volatile materials

o Other policies, procedures, standards and guidance

o Emergency evacuation plans documented and tested for environmental controls

o Establishment of a disaster recovery plan that addresses environmental hazards in sufficient detail and includes any applicable testing and off-site recovery

o Minimal use of items that collect dust, such as drapes and carpets

Installation of Environmental Hazard Detection and Prevention Devices

Maintenance and Operations (M&O) shall install environmental hazard detection and prevention devices, such as smoke detectors, fire alarms and sprinkler systems.

Also, the employees shall be cross-trained adequately in the use of such devices. The devices shall be easily accessible if needed.

M&O shall ensure that the settings are appropriate on all automatic mechanisms to effectively regulate the environmental conditions of the processing environment.

Equipment Maintenance

M&O shall maintain formal equipment maintenance, such as the schedule of testing for sprinklers, fire extinguishing equipment and power generators. M&O shall ensure that the maintenance schedule for all environmental controls is followed in a timely manner.



Physical Location and Design of the Facility

The EDIT and M&O shall be aware of the physical location of the facilities, as well as the design, so that it minimizes the potential threat of environmental hazards, such as floods, tornados, chemical spills and terrorist attacks.


Technology Operating Guide – Section 6 Logical Access Security, (p. 1 of 6)



Purpose and Scope

The purpose of this section is to detail the procedures for logical access and environmental security of information systems.

Statements



Management shall restrict access to information resources (e.g., programs, data, networks) to enforce desired segregation of duties, facilitate online approvals, etc. Logical security tools and techniques shall be used to define such access restrictions, including how and to whom RISD will limit the ability to view, use or modify significant information resources.

Responsibilities related to information security administration are defined and assigned.

The supervisors, along with the specification of access privileges, shall authorize all user accounts. Only authorized persons shall create user accounts.

The EDIT is responsible for the overall logical security of the network and other applications, while the EDIS is responsible for the overall logical access security of Oracle e-Business Suite™ (OEBS), KRONOS, and Remedy System.

Establishing Appropriate Logical Security Policies and Procedures

Responsibility: Management

Management shall determine the desired level of logical access security. Management is responsible for updating policies and procedures. Additionally, management shall consider the changes in the past year (or after the last meeting) and evaluate the necessary security requirements in light of those changes.

The policies and procedures documents and other referencing documents shall be updated and approved for usage by management. Also, management shall communicate the changes and provide the latest version of the policies and procedures to the appropriate staff.

Security Management


Management shall clearly assign the responsibilities for security administration of various systems.

Management shall review responsibilities whenever there are significant changes to systems or staffing. The following responsibilities have been established for security administration:

• Operational responsibilities:

o Oracle System Security – EDIS

o Oracle Application Security – EDIS



o Network Security – Senior Network Engineer (SNE)

o Non-OEBS Systems – Director of Technology Support Services

User ID Policy

User IDs and Passwords

• To implement the need-to-know process, RISD insists that each person accessing multiuser information systems has a unique user ID. These user IDs must then be employed to restrict system privileges based on job duties, project responsibilities and other business activities. Each worker is personally responsible for his or her user ID and password.

Unique User IDs

• Each user will be assigned his or her own unique user ID. An individual uses the same user ID if he or she transfers through RISD. User IDs/logons are linked to specific people and are not associated with computer terminals, departments or job titles. Also, the user ID will be permanently decommissioned when a user leaves RISD. Additionally, user IDs and related passwords must not be shared with any other individual. Anonymous user IDs (such as “guest”) are not allowed, unless approved in advance by the EDIT.

Generic User IDs

• User IDs that are defined with a generic name (i.e., based on a specific system utility, service, application, process or job function) shall also be specific to a particular individual to ensure accountability for each user ID. A procedure shall be established to track and review group logins.

Passwords

• The following standards shall be followed in the assignment and usage of logon IDs and passwords:

o For the user ID, the first initial, middle initial and last name is used as the standard format. In the event of a duplicate, the first name will be extended until the duplication is resolved.

o The passwords must comprise a combination of uppercase and lowercase letters, numbers and special characters. Password audits of all systems should occur on a regular basis (quarterly).

o Passwords shall be at least six characters long.

• The password policy followed for the OEBS environment is as follows:

o Passwords must be a minimum of eight characters and a maximum of 160 characters.

o Any combination of alphanumeric characters must be used, and the password shall not be easily guessable.

o The user must reset the password on his or her first login.

o Passwords expire in 30 days for back-office staff.

o Passwords expire in 90 days for all non-back-office personnel (principals, etc.).

o A password may be used only once.



o An account lockout value is set at three unsuccessful attempts. If an account is locked out, the user must call the OEBS help line to have the account reactivated.

o If the user forgets the password, he/she calls the Help Desk. The application administrator resets the password and gives a new password to the user over the phone. Once logged on, the user must reset his or her password again.

User Account Creation – Non-OEBS Accounts

Computer Access Request

Responsibility: All users

• Before requesting system access, a user must read and agree to the Responsible Use Guidelines (RUG). The RUG is provided annually to all employees in the Employee Handbook and is available on the RISD Intranet under “Documents”.

• Upon confirming that the user has read and agreed to the RUG, the supervisor will authorize the System Access Request Form (available on the RISD Intranet under “Forms”) and forward it to the SNE. The Help Desk is responsible for creating the accounts for teachers and other school staff.

User account Creation for Non-OEBS systems

• SNE

• School Network Administrator

• Help Desk

User Account Creation for all RISD Students, Part-Time Employees and Temporary Employees

Responsibility: SNE

• The SNE will create the user account from scratch for all RISD students, based on the list from the Student Information System. Moreover, all student accounts shall be deleted and created at the beginning of each school year.

School User Account Administration

Responsibility: School-Level Administrator

• At all schools, rights are assigned to employees who, apart from their regular duties, administer the student user ID accounts. At the school level, the administrators will assign accounts to the students who have changed schools, as well as password administration.

User Account Creation by Help Desk

Responsibility: Help Desk

• The Help Desk is responsible for creating teacher and other staff accounts, terminations and changes.

User Account Creation – OEBS Accounts

Performing Operational-Level Security Functions




• The logical security for the Oracle system is maintained by the principal Oracle DBA

• The DBA is responsible for all operating system-level security and operations, such as backup and maintenance activities to the Oracle system.

• The application security administrator is responsible for adding and removing users, assigning responsibilities to the users, and executing and reviewing the security-related reports in Oracle. The application security administrator is solely responsible for the maintenance of user accounts and assigning responsibilities within Oracle.

• The following groups have access to the Oracle system:

o Principals

o Assistant Principals

o Managers

o Executive Assistants

o Staff belonging to functional departments, such as Finance, Payroll and Purchasing

• The users access the system through web browser using a unique user ID and password.

Requesting OEBS System Access

Responsibility: Functional Managers

• The functional managers shall request application administrators through the OEBS Access Form (located on the RISD Intranet under the “OEBS” – formerly “ERP” -- section) to grant access to users who work for them. Escalated access privileges must be approved by the functional area manager.

Granting Access Privilege


• Functional managers are responsible for assigning access privileges for users who work under them.

• Access shall be logged so that management may monitor approvals of access to users regularly.

Changes/Termination of Access Privileges

• Involuntary Terminations


o When functional users are terminated or transferred, it is the responsibility of the functional manager to track the functional users’ access privileges in order to get their access revoked, with the help of the application security administrator.

o When personnel are terminated, the Oracle HR application provides the managers with a checklist of items to be recovered. Access privileges shall also be tracked in the same manner.

• Planned Terminations

Responsibility: Application Security Administrator



o The application security administrator receives a list of terminations every month and revokes the access privileges of all nonfunctional users based on this list. This function shall be integrated with the above steps to eliminate the gap/lead time.

Privileged User Access

Responsibility: Functional Managers and the EDIS

• For a higher-level privileged user access, such as super user access, the functional managers shall request the application security administrator in person or through email to grant access to designated employees. Access should be requested through the OEBS Access Form (located on the RISD Intranet under the “OEBS” – formerly “ERP” -- section), which will be retained for audit purposes.

• The functional managers and OEBS Program Manager shall meet and review user access privileges to ascertain that there is appropriate segregation of duty and that access requirements are required for present duties.

• The application administrator will provide a report to the EDIS that documents all users with super user access semi-annually. The EDIS will present that report to functional area management for review/approval and technology management for review.

OEBS System Security Administration

• Oracle System Security Settings

Responsibility: Principal Oracle DBA for Oracle and the Application Engineer

o The Oracle system security settings shall be set as described in the Database Management Guide or the Oracle Standards Guide, which can be found on Metalink. Any changes to the settings that are different from the Database Management Guide shall be logged and approved by EDIS. The Database Management Guide shall be modified to reflect the changes.

• Review of Oracle Security Settings

Responsibility: OEBS Program Manager

o The OEBS Program Manager shall review the database settings and ascertain that the settings match the Database Management Guide. The OEBS Program Manager shall maintain a log for review.

• Links With External Environment

o Management of Interface Links

Responsibility: Application Engineer

Oracle OEBS systems are integrated with other systems, both within and outside RISD. The application engineer is responsible for maintaining a log of all available links, as well as the security of the links.

o Security of Interface Links

Responsibility: Application Engineer

The application engineer is responsible for monitoring activity and transactions across the links. Any abnormal transactions or activity shall be logged and reported to the EDIS.



o Security of Interface Programs


The functional managers shall ensure that the appropriate level of security is established over the data transfer programs. The following measures shall be adopted:

• Restrict the user access to the programs that are used in data transfers

• Provide passwords and keys to only select persons who perform the jobs

• Review the activity of the personnel operating the data programs

• Review the logs periodically

• Perform additional controls, such as checking or confirming the batch totals, and confirming process completion

o Periodic Review of Interfaces

Management shall review the interfaces periodically. Policies and procedures shall be established to review the Application Programming Interface (API) with the OEBS system.

Network Security

• RISD shall install and maintain appropriate logical security prevention tools, such as a firewall or other appropriate security measures.

• The advisory engineer or other designated person shall monitor the logs and traffic on the network, log the monitoring activity and alert the EDIT in case of any serious security issues.


Technology Operating Guide – Section 6 Physical Access Security, (p. 1 of 3)


Purpose

The purpose of this section is to detail the procedures for physical access security over information systems and assets.

Statements


Physical access to the computer room building and immediate surroundings of computer equipment shall be monitored and restricted to individuals who require such access to perform their job responsibilities. Management approval shall be obtained before access is granted. Log of authorized personnel able to access computer rooms shall be retained.

A physical access control mechanism shall be used to restrict and record access to protected areas, and authority to change physical access control mechanisms shall be limited to appropriate personnel.

The Executive Director of Instructional Technology (EDIT) is responsible for the computing environment physical security.

Physical Access Restrictions to the Facilities

All the RISD facilities have nightly security patrol from 4 p.m. to 7 a.m.

Physical access is restricted by the use of traditional keys and electronic keycard access systems.

Designated persons lock the doors of the facilities after the business hours and open the facility doors in the morning.

Nonduplicatable “Arrow” keys are used for all the facilities.

RISD has a badge ID system for all employees. The badge has the photo identification with a name and the department in which the employee works. All the employees are required to wear their badges during their presence in the RISD facilities.

Badge ID System and Keycard System

The keycard system is implemented through the Andover Security System on a Windows NT platform.

The computing facility and sensitive areas shall be restricted through the keycard access system at selected facilities.

Keycard Request

Performed by: Executive Assistant to Executive Director/Principal

The requests for keycards will be made through email by the Executive Assistants of the Executive Directors or Principals to the Heating, Ventilation, & Air Conditioning (HVAC) Supervisor, who is also in charge of the keycard system.



Issuing Keycards

Performed by: HVAC Supervisor

The HVAC Supervisor will deliver the card personally to the requesting Executive Assistant after noting and logging the card number. After receiving the keycards, the users shall sign the Keycard Access Form, which is forwarded to the HVAC supervisor.

The HVAC supervisor will enter the information about the user and keycard number into the keycard system and maintain the forms for permanently.

Access Verification

RISD shall review physical access privileges of employees. The HVAC Supervisor shall forward a list of keycard holders to all the Executive Assistants once a year to review the access requirements for employees in their departments. If a response is not obtained from the Executive Assistants within 14 days, the HVAC Supervisor will delete the keycard holders who have not accessed the facility in the past year.

Employee Termination

Performed by: Supervisor of the employee

When employees are terminated, the employees’ departments are responsible for collecting the keycards and returning them to the HVAC Supervisor. Management shall ensure that the keycards are collected from the employees and returned to the HVAC Supervisor for timely revocation of access privileges. Access should be revoked upon the date of termination, whether or not the keycard is returned.

Keycard Access for Contract Employees

Performed by: Executive Assistant to Executive Director/Principal

Keycard access for contract employees shall be requested in the same manner as regular employees. If the contract employees need access to the facilities during off-time hours, they are required to call security services. The security staff will enter the building with the contract employee to disable the alarm system. Similarly, the contract employees will call security before leaving to reset the alarm.

Lost Keycard

If a keycard is lost, the user must send a request to the Executive Assistant of his or her department for a replacement card. The Executive Assistant shall send an email requesting a replacement card to the HVAC supervisor. The HVAC supervisor shall change the card number in the system and deliver the cards to the Executive Assistant. The users shall sign the Keycard Access Form with the new card number.

Computer Room Security

The Network Services Group (NSG) area shall be restricted to only the NSG employees through keycard access. The computer room, which is located in the NSG area at the Annex building, houses all the servers and shall be restricted to only selected employees through keycard access. The EDIT



shall tightly control the access to the computer room. Review of the access to the Annex building will occur on a regular basis.

The visitors entering the NSG area shall be required to sign in on the visitor log and shall always be escorted by an employee.


Technology Operating Guide – Section 6 Virus Prevention Procedures, (p. 1 of 2)



Purpose and Scope The purpose of this section is to detail the procedures for protecting information systems from software virus attacks, and cover the virus protection processes.

Statements It is the policy of RISD, in a manner consistent with management’s desires and expectations, that:

All software and data shall be checked for viruses before implementation in the Production environment.

Antivirus software shall be loaded on all RISD Windows-based computers connected to RISD’s network. Antivirus software should be loaded on non-Windows computers if a licensed solution is available for that operating system.

Programs and data on the network shall be scanned regularly; the Network Security Manager shall notify the Director of Network Technology (DNT) and Executive Director of Instructional Technology (EDIT) if any programs or data reveal virus activity or infections.

The antivirus software shall be configured to update the signature files at least once per day.

• RISD staff should verify that vendors or other visitors who wish to connect computers to RISD’s network for business purposes have current antivirus software installed.

The EDIT is responsible for the overall virus protection activities.

The Network Security Manager is responsible for monitoring the antivirus logs and configuring the systems.

Testing New Software and Data before Installation The Executive Director of Information Services (EDIS), EDIT, and/or DNT shall assign the testing of new software and data to the computer system specialists. The specialists shall ensure that the software and data (where applicable) is free from viruses before approving the implementation of the new software/data in the Production environment.

Testing and Implementation Process

• The computer system specialists shall install the new software and data in the test environment or in a separate small prototype environment and monitor the performance. The computer system specialists shall ascertain that the new software and data are performing as intended.

• The computer system specialists shall include the new software and data as part of the standard image on computers, if appropriate.

• A log shall be maintained of all the new software and data tested, along with the details such as the date of testing and implementation, the person responsible for each activity and management approval for each stage.

Security Awareness The EDIT shall ensure that all users are aware of the antivirus policies and procedures of RISD via distribution or posting the policy.

Technology Operating Guide – Section 6 Virus Prevention Procedures, (p. 2 of 2)


All users must sign an agreement, acknowledging they have read and agree to the Responsible Use Guidelines (RUG). The RUG is provided annually to all employees in the Employee Handbook and is available on the RISD Intranet under “Documents”.

Antivirus Software Installation The district’s approved and licensed antivirus software will be installed on all networked, RISD-owned computers on which it will run. Additionally, management will ensure that the antivirus software is accommodated as part of the base image for all computers or installed on all the computers using remote deployment tools. Moreover, the EDIT shall ensure compliance with these procedures.

Antivirus Software Configuration and Monitoring

• The Network Security Manager shall set the configuration parameters for antivirus software; coordinate with the EDIT; and determine the appropriate settings, such as the signature update schedule and scanning schedule. All settings shall be documented, along with the detailed log of changes.

• The antivirus software shall be set to update the signature files at least once per day.

• The Network Security Manager shall also monitor the antivirus logs at regular intervals and maintain a log of all the observations (within an antivirus software monitoring log). The Network Security Manager shall notify the DNT and EDIT if there is any virus activity revealed in the logs.

• Software will be installed in such a way that a password is required to uninstall the software from any computer. The password will be held by the Network Security Manager.

• Anti-virus software will be installed on the email gateways to monitor for incoming viruses.

Web Security Internet browsers should be configured to use anti-phishing and other available web security tools.

RISD will periodically evaluate the necessity and practicality of installing a web security solution separate from the existing content-filtering solution.

Remediation If a user receives an alert that his/her computer has been infected with a virus or other malware that cannot be cleaned or quarantined, he/she should contact the Help Desk at the earliest opportunity for assistance in cleaning the computer.

Antivirus Policy Evaluation RISD shall establish a security committee consisting of the EDIS, EDIT, and other key personnel to formally evaluate and approve the antivirus software and policy. The committee shall meet as necessary to review the adequacy of the current antivirus software policies and procedures.

Contact Person: Network Security Manager

Technology Operating Guide – Section 7 Independent Audit, (p. 1 of 1)


Purpose and Scope

This section describes the procedures RISD will use to gain assurance that Instructional Technology (IT) functions are occurring as intended.

Statements

It is the plan of RISD Technology, in a manner consistent with management’s desires and expectations, that the Technology functions of RISD will be audited annually to ensure that the Technology operations are occurring as intended by management.

The district will hire an external audit firm on an annual basis. External auditors will be paid from the Finance Department budget and will not be included in the Technology budget.

The Executive Director of Information Services (EDIS) and Executive Director of Instructional Technology (EDIT) will work with the audit firm to document and resolve any areas of inefficiency in the Technology area.

The Technology audit firm will present a report annually to the Board of Trustees documenting areas of improvement or areas that are not completed to the expectations of management.

The EDIS is responsible for all operations relating to the Oracle e-Business Suite™ (OEBS) system.

The EDIT is responsible for all operations relating to all other systems.

The Assistant Superintendent of Finance is responsible for obtaining third-party auditing services.


Technology Operating Guide – Section 7 Outsourced Vendors, (p. 1 of 2)


Purpose and Scope

The purpose of this section is to ensure that the selection of outsourced vendors is consistent with management’s intentions.


Statements



Formal selection criteria are developed to control the outsourced vendor selection process. Management monitors compliance with this policy.

Management approves the selection of outsourced vendors.

Service-level metrics are defined and agreed to by the affected parties.

Criteria to be used to evaluate and select outsourced vendors are agreed to by the affected parties.

The EDIT is responsible for managing the relationship with M&A Technologies, Inc. for hardware support and all software vendors, excluding the OEBS system.

The EDIS is responsible for managing the relationship with software vendors as related to the OEBS system

Relationship with Outsourced Vendors

The EDIT is responsible for managing the outsourced relationship with M&A Technologies, Inc. EDIT is responsible for all relationships with vendors of desktop productivity tools.

The EDIS is responsible for managing all relationships for enterprise application software products.

RISD management shall make certain that appropriate procedures are in place to ensure that vendor relationships are being managed according to management’s intentions, and that policies and procedures are being followed.

Maintenance of Vendor Contracts

When a new contract with a vendor for hardware, network infrastructure or desktop productivity tools is in the approval process, the EDIT shall review/modify the maintenance section of the contract. This process shall be documented so that modifications to the contracts/agreements are auditable. The EDIS shall review/modify all vendor contracts relating to enterprise software.

• Specific items include ownership of the software, confidentiality of the data in the system, state and federal guidelines, and liabilities within the agreement.

• Where necessary, the Legal department will be involved in this process, depending on the system and agreement(s).

• The EDIT shall review/modify and sign all maintenance agreements.

Technology Operating Guide – Section 7 Outsourced Vendors, (p. 2 of 2)


RISD management shall implement a process to ensure good working relationships with third-party personnel. Such a process shall provide that both parties agree to acceptance criteria, handling of changes, problems, user roles, facilities, tools, software, standards and procedures.

RISD Technology management shall undertake the necessary actions to establish and maintain adequate coordination, communication and liaison structure between the IT function and outsourced vendors.


Technology Operating Guide – Section 7 Outsourced Vendor Service Levels, (p. 1 of 1)


Purpose and Scope

The purpose of this section is to ensure that outsourced vendors’ service levels meet or exceed management’s expectations.

This section is effective for the RISD Technology operations.

Statements



Management monitors information system service levels and initiates corrective action if performance does not meet expected service levels.

Service level metrics are defined and agreed to by the affected parties.

Service Level Agreements (SLA)

An SLA exists for hardware support services that have been outsourced to M&A Technology, Inc.

• A meeting will be planned quarterly with M&A Technology, Inc. to review performance metrics.

• Additionally, a bi-weekly meeting will be held with M&A Technology, Inc. to evaluate the vendor performance.

A contract is in place with Texas Archives for off-site storage of backup tapes.

All SLAs shall provide a mechanism for measuring performance against the SLA and reporting those results to management of the client entity. Failure to monitor the level of service provided and to take appropriate action may result in control deficiencies and/or inefficient or ineffective operations.


Technology Operating Guide – Section 7 Software License Management, (p. 1 of 2)



Purpose and Scope

The purpose of this section is to detail the procedures for software license management.

Statements


Software loaded on all computers shall be compared to an inventory of licensed software on an annual basis. If unlicensed or unauthorized software is found, licenses shall be obtained, or the software shall be removed. Records of the software audit shall be retained.

Purchasing and installation of new software shall be validated before acquisition for compliance with organizational license requirements.

Management shall communicate all license policy changes to the users and coordinate the implementation process with the users.

The Executive Director of Information Services (EDIS) is responsible for the overall software license management for the Enterprise Applications.

The Executive Director of Instructional Technology (EDIT) is responsible for the overall software license management for all other systems not managed by the EDIS.

Licensed Software

Licensed software consists of Enterprise Applications and the software specified by Instructional Technology (IT) that is part of the Golden Drive images. (Note: The Golden Drive is the basic drive image that RISD maintains for installation on all computers. This image has all the basic application and utility software for user machines.)

The Information Services (IS) department is maintaining the licenses for Enterprise Applications. Instructional Technology (IT) and the Network Services Group (NSG) maintain the licenses for Golden Drive software.

As a general policy, RISD buys the most cost effective license for all of software.

Responsible Use Guidelines (RUG)

The Responsible Use Guidelines (RUG) for computers is available on the RISD intranet to all users. The RUG explains the acceptable usage terms and the penalties for violation. This also includes the license violation terms, and the policies and procedures to request new software and additional licenses.

All users must sign an agreement, acknowledging they have read and agree to the Responsible Use Guidelines (RUG).

The RUG is provided annually to all employees in the Employee Handbook and is available on the RISD Intranet under “Documents”.

The RUG is provided annually to students and parents in the Student/Parent Guidebook and is also available on the RISD Internet as part of the Student/Parent Guidebook.

Technology Operating Guide – Section 7 Software License Management, (p. 2 of 2)


Software License Maintenance

The EDIS is responsible for maintaining the license and other vendor agreements for the Enterprise Applications. The EDIS records all the expiration dates in the calendar as reminders and tracks the license expiry dates and renewals. Management shall ensure that the critical dates are not missed.

When changes to the software license agreements are made, the EDIT/EDIS shall coordinate with all the affected parties and ascertain that the changes are in line with the organizational strategic goals.

Purchase of New Software License

The request for new software shall be made by filling out and submitting the Software Request Form, which is available on the RISD intranet. The EDIT shall approve the request if sufficient funds are available in the budget, and the request meets the strategic goals and objectives of the organization.

The EDIT shall assign appropriate personnel to test and install the software.

Software Inventory and Compliance

Software-inventorying tools such as System Center Configuration Manager (SCCM) are being used by management to monitor license compliance on user computers.

Also, SCCM is used for Help Desk support to assist users in troubleshooting issues.

License monitoring reports provided by SCCM should be conducted on a monthly basis and retained for no longer than 24 months to ensure compliance with all software licenses.


Technology Operating Guide – Section 7 Strategic Technology Plan, (p. 1 of 1)


Purpose and Scope

The purpose of this section is to ensure that the technology services, strategies, plans and budgets are consistent with the entity’s business and strategic goals.

This section is effective for the RISD Technology Division.

Statements


The Deputy Superintendent (DS) is responsible for the Strategic Technology Plan (STP) of RISD, while the Executive Director of Instructional Technology (EDIT) is responsible for the STP as it relates to computer and networked systems and as it relates to Instructional Technology (IT). The Executive Director of Information Services (EDIS) is responsible for the STP as it relates to the Enterprise Applications.

The Technology Advisory Committee (TAC) is responsible for ongoing recommendations and standards of the technology infrastructure of RISD.

TAC Meeting

RISD shall hold TAC meetings during the normal school year.

• The TAC is responsible for recommending standards, measurements and action plans to reflect long-term technology plans (three-year plan). Also, this document includes an Infrastructure Assessment, which outlines network, voice and video infrastructures in RISD.

• Review of the STP will be conducted on an annual basis.

Long-Term Planning

RISD technology management and business process owners shall ensure that a long-term strategic plan for the next three years is kept current and available for stakeholders’ review and consideration.

Communication of Technology Plans

The STP is made available to stakeholders at all times.


Technology Operating Guide – Section 7 Technology Operations Training, (p. 1 of 2)


Purpose and Scope

The purpose of this section is to ensure that personnel within the computer processing environment receive appropriate training.

Statements

It is the plan of RISD Technology departments, in a manner consistent with management’s desires and expectations, that:

System implementation procedures include training users on the appropriate use of new or substantially modified systems. Management monitors compliance with these procedures. As new employees are hired and as employees transfer within RISD, they receive formal training on relevant application systems.

Current user documentation for application systems is readily available to users.

Support requests are summarized and reported regularly to management. Also, management monitors the nature and frequency of support requests to determine whether user training, support resources and/or documentation shall be improved.

The Executive Director of Information Services (EDIS) is responsible for training of the Information Technology (IT) personnel, while the Executive Director of Instructional Technology (EDIT) is responsible for training of the Network Services Group (NSG) personnel

Training for the Information Services Group

Personnel will request training from the EDIS, based on their specific needs.

The EDIS will recommend training for OEBS users using the Oracle website, which suggests skill sets for specific positions.

The skills of the current staff will be compared to the recommendations from Oracle. This comparison shall be documented so that inquiring personnel understand the reasoning behind training allocations.

The EDIS will allocate training to personnel using the comparison above.

Training for NSG

Annually, each manager within the group will determine a budgeted amount needed for training for specific personnel.

The budget will be sent to the EDIT for approval.

Training may come from different sources: Hewlett-Packard (HP), Global Knowledge, Education Service Center (ESC) or other specific vendor training programs. Management shall ensure that employees are provided with orientation upon hiring and with ongoing training to maintain their knowledge, skills, abilities and security awareness to the level required to perform effectively. Education and training programs conducted to effectively raise the technical and management skill levels of personnel shall be reviewed regularly.

Personnel shall be evaluated annually. This process is initiated by filling out Human Resources (HR) evaluation forms (see HR for forms). RISD Technology management shall implement an employee

Technology Operating Guide – Section 7 Technology Operations Training, (p. 2 of 2)


performance evaluation process that is designed to help employees understand the connection between their performance and the organization’s success. An evaluation shall be performed against established standards and specific job responsibilities on a regular basis. Additionally, employees shall receive counseling on performance and conduct, when appropriate.

At evaluation time, HR will send the forms mentioned above to all departments.


Technology Operating Guide – Section 7 User Education, (p. 1 of 1)


Cross Reference: Responsible Use Guidelines (RISD Intranet, “Documents”), Netiquette (TOG), Archiving Outlook (TOG)

Purpose and Scope

The purpose of this section is to detail the procedures for educating users on responsible use of the District’s electronic assets.

Statements

For the purpose of this section, the term “User” is defined as all students, employees and member of the community which use the RISD intranet.


RISD shall provide educational or instructional material documentation for end users.

Where appropriate, vendor provided materials can be utilized.


The Executive Director of Information Services (EDIS) is responsible for the creation of user education materials and documents pertaining to enterprise software.

The Executive Director of Instructional Technology (EDIT) is responsible for the creation of user education materials and documents.

Educational Materials

The EDIT or EDIS, or delegated staff members, shall create user educational materials for RISD systems. This material will be provided in either hard copy or posted electronically for all users.

The educational materials will be limited to appropriate use for RISD systems as determined by either the EDIT or EDIS.

Responsible Use Guidelines (RUG)


The RUG is provided annually to all employees in the Employee Handbook and is available on the RISD Intranet under “Documents”. The RUG is provided annually to students and parents in the Student/Parent Guidebook and is also available on the RISD Internet as part of the Student/Parent Guidebook.

Access to RISD systems will be denied for users who do not read and agree to the RUG.

RUG agreements will be maintained in Human Resource personnel files.


TOG Appendix A

Enrollment Verification Fall 2013/ TOG App A

ENROLLMENT VERIFICATION

YOUR SCHOOL NAME:

ATTENTION: ADMINISTRATOR / REGISTRAR / DATA CLERK DATE:

SCHOOL NAME: SCHOOL DISTRICT:

PHONE: FAX:

Please verify if the following student has enrolled at your campus during the current school year.

STUDENT NAME: DOB: GRADE:

PEIMS ID:

PEIMS ID (if different from our records):

Yes, this student is currently enrolled at our school.

(Entry Date)

Yes, this student was enrolled at our school.

(Entry Date)

(Withdrawal Date)

No, this student has not enrolled at our school during the current school year.

SIGNATURE TITLE DATE

Please fax this Enrollment Verification to

Thank you for your assistance. If you have questions, please call me at

TOG Appendix B

Instructions: Include form in end-of-year information packet. Maintain copy of filled out and signed form in student folder for audit purposes.

Intent to Withdraw Fall 2013/TOG App B

INTENT TO WITHDRAW FORM

Student Information:

First: Mid: Last:

Local ID: PEIMS ID:

Next Year Grade: Next Year Location:

Name of School/District Transferring to: Parent/Guardian Information:

Name: Relationship:

Summer Address:

Phone: Other adults with knowledge concerning the student:

Name: Phone:

Name: Phone:

Name: Phone:

We will be moving over the summer and my student will not return to _______________ campus for the next school year.

Person withdrawing student (print) Relationship

Signature Date

TOG Appendix C

Withdrawal Questionnaire Fall 2013/TOG App C

PARENT/GUARDIAN WITHDRAWAL QUESTIONNAIRE School Date Student Name Student ID Grade Date of Birth Person Withdrawing Student (Printed) Relationship to Student REASON FOR WITHDRAWAL: The student is moving to another district or attending a private school.

District: School:

Address: Phone Number:

Planned Start Date: The student is moving to another RISD school attendance area.

RISD School: Planned Start Date:

The student is attending a Charter School.

Charter School: Address:

Phone Number: Orientation Date:

Start Date: The student is attending Christa McAuliffe Learning Center / JJAEP

Intake Date: Start Date:

The student is incarcerated.

Incarceration Date: City/County:

Parent/Guardian Name

Parent/Guardian Current Address Parent/Guardian New Address

City City

State Zip State Zip

Phone Number Phone Number

RICHARDSON INDEPENDENT SCHOOL DISTRICT

Unlock Potential • Provide Opportunities • Enable Dreams

TOG Appendix D

Leaver Reason Code Change Authorization Form Updated August 2013/TOG App D

Leaver Reason Code Change Authorization Form Student Information

Campus #: �� Campus Name: ��

Last Name: �� First Name: ��Middle Name: ��

Local ID: �� PEIMS ID: �� Grade: ��

NEW Leaver code assignment

Circle only one.

01 Graduated From A Campus In This District Or Charter 82 Enroll In School Outside Texas

03 Died 83 Withdrawn By District Because Not Entitled To Enrollment

16 Return To Home Country 85 Graduated Outside Texas Before Entering A Texas Public School-Entered A Texas Public School-Left Again

24 College, Pursue Associate’s or Bachelor’s Degree 86 GED Outside Texas

60 Home Schooling 87 Enroll In University High School Diploma Program

66 Removed-Child Protective Services 88 Court-ordered to a GED program, has not earned a GED

78 Expelled For Offense Under TEC §37.007, Cannot Return 89 Incarcerated in state jail or federal penitentiary as an adult

81 Enrolled in TX Private School 90 Graduated from another state under provisions of the Interstate Compact on Educational Opportunity for Military Children

TX TREX Records Request with date of enrollment CE Confirmed enrollment with date of enrollment

Notes

Document all phone calls, address of current campus and phone number, last known address of student or contact and their relationship to the student on the reverse side.

Refer to PEIMS Data Standards Addendum D and Addendum H for additional information including the documentation requirements needed for the code circled above.

If the student’s latest withdrawal reason is a PT on the PCC screen, there is no reason to complete this form and send in for processing.

Leaver Code Change Authorized by

By signing this form, you confirm that the appropriate leaver code has been assigned and all necessary documentation needed to support the code has been obtained and is attached.

Leaver Principal: Date: Central Office Use Only: WD: Cohort:

Date Received: Code Changed: Initials:

New leaver code assignment

RICHARDSON INDEPENDENT SCHOOL DISTRICT

Unlock Potential • Provide Opportunities • Enable Dreams

TOG Appendix D

Leaver Reason Code Change Authorization Form Updated August 2013/TOG App D

Documentation of Phone Call/Letter/Meeting

Contact Name: Title/Relationship:

Date: Phone/Address:

Student's School Destination:

Name of School

School Address City/State (Type of School)

Date Student Began Instruction:

(Attach supporting documentation and/or record conversation in space provided below.)

Name of Campus Person Date of Contact

TOG Appendix E

Secondary End of Year Checklist Page 1 of 4 Revised July 2013/TOG App E

Secondary End of Year Checklist To be completed between now and the last day of school

Initial Below All half day students (scheduled for more than 120 minutes, but less than 240 minutes of instruction each day)

are coded as ADA code 2 in the SIS. All full day students (scheduled for 240 or more minutes of instruction each day) are coded as ADA code 1 in the

SIS. Any student taking 1 or 2 courses (less than 120 minutes of instruction per day) has been reported to Student

Information and Reporting and is coded as ADA of 0 (enrolled not in membership). All non-resident students (those living outside the district boundaries) have a “Non Resident Student Application”

on file and have been reported to Student Services. Each school should have a log for this group of students. All students have a PEIMS ID#. All Texas Unique ID issues have been corrected. All immigrant students have been coded as such in the SIS, with the immigrant date entered in “Date Entered

US Schools”, “Immigrant Status Date”, and “Academic Yrs PK-12” fields. Any migrant students (indicated on the Home Language Survey) have been reported to the Newcomer Center. All students, not meeting promotion requirements, have been coded as retained in the SIS(must be done by

must be done by the mid-June-date provided by Student Information and Reporting). Any student, whose parents/guardians have indicated he/she is homeless, has been referred to the district’s

homeless coordinator. Each student who was in attendance during the current school year has a completed and signed enrollment

card. Each student who was in attendance for the current school year has a signed Directory Information (FERPA)

form. All Residency/Guardianship affidavits have been renewed (where applicable) entered in the SIS, and filed in the

student’s cumulative folder. All enrollment cards for the next school year have been checked against the information in the SIS and updated,

with parent/guardian names, addresses, phone numbers, etc. – if valid for current year. Address Audit has been run and all Relation Resides (priority 1) Contact addresses have been updated. Education Records All students have cumulative folders with typed or legible handwritten labels on the tabs that include the

student’s legal name, ID #, and birth date. Transcripts (AAR) for all students are up to date. A copy of the current school year’s enrollment card (front and back) has been placed in the student’s cumulative

folder. All current school year’s report cards have been placed in the student’s (active as well as withdrawn) cumulative

folders. The current school year’s Report Card CD has been stored in the building. Others on your campus know where

this disk is stored. Electronic grade books for all teachers for the current school year have been stored in the building for 5 years. All cumulative folders have been/will be moved to the appropriate grade level drawers for next year after the

school year has ended. No copies of birth certificates, or their equivalents, or copies of social security cards were disposed of from the

graduate cumulative folders. All leaver folders contain documentation to support the withdrawal code assigned. All absences have been entered/resolved in the SIS. All absence excuse notes/attendance records not requested by Records Management, have been resolved in the

SIS and stored on your campus for an additional 5 years. Attendance records, requested by Records Management, are organized as directed by Records Management and

transported to the designated location. All current school year Directory Information (FERPA) forms have been are organized as directed by Records

Management, and transported to the designated location.

TOG Appendix E


One copy of a student’s withdrawal form is in the cumulative folder and one copy is attached to the back of the enrollment card sent to Records Management. Each withdrawal form is completely filled out, including the withdrawal date, reason, and appropriate signatures.

Identified withdrawn student’s cumulative folders are purged as directed by Records Management and transported to the designated location.

Current year enrollment cards are organized as directed by Records Management, and transported to the designated location. Headers on these enrollment cards are accurately and completely filled in.

Purged materials have been disposed of in an appropriate manner – by shredding them with an electric shredder, paper cutter, or scissors; or by sending them for destruction.

All vital documentation, such as class lists, class counts, late entries, withdrawals, etc. for the school year are organized in a notebook or file folder and stored in a convenient place on your campus. Others on your campus know where these records are stored.

High Schools have been provided with lists of current 8th grade students who may require a new transfer or residency or guardianship affidavit, before beginning the new school year as 9th graders.

All 9th grade student records have been transported to the appropriate next year campus as requested. Emergency Cards for the next school year have been ordered. Other end of year requirements have been completed – as sent to you by email or interoffice memo (attach

copy of email/memo and initial). Next Year Prep All enrollment cards for the next school year have been signed by the parent/guardian and are accompanied by

a new Proof of Residency. Be sure to call or send out reminders to those who are lacking – and document your follow-ups.

Lists of students who require privacy, ethnicity and/or race updates for the next school year, have been generated and stored for correction after mass break.

All retentions have been verified in the SIS. All certificates of completion have been sent to the Student Information Specialist to be withdrawn in the SIS. ESL All ESL students are coded correctly in the SIS. ESL teachers have submitted all ESL additions, changes,

and/or dismissals to the Newcomer Center for coding. There are no students coded as ESL that have been dismissed. All current ESL students have been coded as ESL in the SIS.

All ESL students are coded with a language other than English as their home language in the SIS. There are no students coded bilingual in the SIS. All students coded LEP only (not receiving services/parental denials) in the ESL field have supporting

documentation in their cumulative folders of the parent’s refusal of ESL services. (These students should not be coded as being served in the SIS).

Special Ed All Special Ed students are coded correctly. Special Education teachers have submitted special education

additions, changes, and/or dismissals to the appropriate Special Ed central office. All Special Ed students have the correct instructional setting, disabilities, and services in the SIS. Principal All discipline data has been entered for the year, and error reports have been corrected. Nurses All immunizations have been entered for the year, and error reports have been corrected.

TOG Appendix E


Sign-off Legend

Initials Name Position

Please initial and return all of these pages with the End of Year Checklist Sign-off Sheet to your campus’s appropriate Student Information Specialist in Student Information and Reporting no later than the following Friday after the week the school year has ended.

TOG Appendix E


Secondary End of Year Checklist - Sign Off Sheet

(Please initial each statement to indicate compliance.)

I have reviewed and complied with all applicable items stated on the End of Year Checklist provided by Student Information and Reporting.

The information entered into the SIS and the information organized in the students’ cumulative folders is correct, according to the best of my knowledge.

All pertinent student records have been transported to Records Management and to the appropriate next year campus.

All other records which are to remain at the local campus are properly stored, including teacher grade/attendance books and absence notes.

Important information such as advisor lists, class lists, enrollment counts, entry and withdrawal lists, etc. have been organized in a file folder or notebook, and are easily accessible for future reference at the local campus.

School Date

Signature of Principal Signature of Student Data Specialist

Thank you for your hard work! Please sign and return this page with the completed checklist to your campus's appropriate Student Information Specialist in Student Information and Reporting no later than the following Friday after the week the school year has ended.

TOG Appendix F

Secondary Fall PEIMS Checklist Page 1 of 2 Revised July 2013/TOG App F

Secondary Fall PEIMS Checklist THINGS TO VERIFY BEFORE THE LAST FRIDAY IN OCTOBER - PEIMS “AS OF” DATE

DEADLINE FOR YOUR ACTIONS – ONE WEEK Initial Below Verify you have a Directory Information (FERPA), an enrollment card, cumulative folder, and enrollment

documentation on all students. Verify that all immigrant students have been coded as such in SIS, with the immigrant date entered in “Date

Entered US Schools”, “Immigrant Status Date”, and “Academic Yrs PK-12” fields. Verify that the country of birth has been entered in the SIS for all students (including those born in the

United States or its territories). Verify that home language has been entered for all students in the SIS. Verify transfer codes and dates have been entered for all current intra-district transfer students on your

campus. Verify transfers have been expired for students whose transfers are no longer current. This includes all

types of transfers: temporary non-resident transfers, and school to school transfers. Verify that all non-resident students (those living outside the district boundaries) have a “Non Resident

Student Application” on file and have been reported to Student Services. Each school should have a log for this group of students.

Verify that all Residency/Guardianship affidavits have been renewed (where applicable) entered in the SIS, and filed in the student’s cumulative folder.

Verify that all students are in the correct grade level. Contact Student Information and Reporting if grade level needs to be corrected.

Verify that all no shows have been withdrawn. Verify that all summer graduates and prior year graduates have been coded. Verify that Student Information and Reporting has been notified of all half-day students (students with at

least 120 minutes but with fewer than 240 minutes of actual instruction) so their ADA code may be adjusted.

Verify that Student Information and Reporting has been notified of all students being served less than 120 minutes so their ADA code can be adjusted.

Verify all student demographic information is correct, according to the newest enrollment card and emergency card, including privacy and ethnicity/race and with whom a student lives. ONLY the student’s legal name from the birth certificate or other acceptable legal document may be entered.

Verify all students have ethnicity/race coded in the SIS. Verify that all students have a PEIMS ID#. Verify that all Texas Unique ID issues have been corrected. Verify that any student, whose parents/guardians have indicated he/she is homeless, has been referred to

the district’s homeless coordinator. Verify that any migrant students (indicated on the Home Language Survey) have been reported to the

Newcomer Center. Verify you have an enrollment card, cumulative folder, and enrollment documentation on all Service Plan

(served by special ed only) students. Copies of enrollment cards (with the headers filled completely in) must be sent to your campuses’ appropriate Student Information Specialist in Student Information and Reporting for all service plan returning students. Copies of enrollment documentation must be sent along with the enrollment cards for all new service plan students.

Verify that there are no students coded bilingual in the SIS. Verify that all ESL students are coded correctly in the SIS. ESL teachers have submitted all ESL additions,

changes, and/or dismissals to the Newcomer Center for coding. There are no students coded as ESL that have been dismissed. All current ESL students have been coded as ESL in the SIS.

Verify that all ESL students are coded with a language other than English as their home language in the SIS. Verify that all Special Ed students are coded correctly. Special Education teachers have submitted special

education additions, changes, and/or dismissals to the appropriate Special Ed central office. Verify that all immunizations have been entered for the year, and error reports have been corrected.

TOG Appendix F

Secondary Fall PEIMS Checklist Page 2 of 2 Revised July 2013/TOG App F

Sign-off Legend


(Attach extra sheet for additional initials/sign-offs.)

Secondary Fall PEIMS Submission Checklist Sign Off Sheet


I have reviewed and complied with all applicable items stated on the Fall PEIMS Submission Checklist provided by Student Information and Reporting.

The information entered into the computer and the information organized in the students’ cumulative files is correct according to the best of my knowledge.

School Date


Please initial, sign, and return all of these pages (one copy per campus) to the appropriate Student Information Specialist in the Student Information and Reporting department at the PDC-A after the last Friday in October but no later than the Friday of the following week.

TOG Appendix G

Elementary End of Year Checklist Page 1 of 4 Revised July 2013/TOG App G

Elementary End of Year Checklist To be completed between now and the last day of school

Initial Below All half day students are coded as ADA code 2 in the SIS (Student Information System) (EE and PK). All full day students are coded as ADA code 1 in the SIS (Grades K - 6). Any student taking 1 or 2 courses (less than 120 minutes of instruction per day) has been reported to Student

Information and Reporting and is coded as ADA of 0 (enrolled not in membership). All students have a PEIMS ID#. All Texas Unique ID issues have been corrected No Pre-K student turned five years old on or before September 1. No Kindergarten student was younger than 5 on or after September 1. All Pre-K students (currently active or withdrawn) have been coded with PK eligibility reason (income

documentation approved by Newcomer Center on file). All Pre-K students that do not have their enrollment cards for the next school year are withdrawn. All students, not meeting promotion requirements, have been coded as retained in the SIS (must be done by the

mid-June-date provided by Student Information and Reporting). All immigrant students have been coded as such in the SIS, with the immigrant date entered in “Date Entered

Country” and “Immigrant Status Date” fields. Any migrant students (indicated on the Home Language Survey) have been reported to the Newcomer Center. Any student, whose parents/guardians have indicated he/she is homeless, has been referred to the district’s

homeless coordinator. Each student who was in attendance for the current school year has a completed and signed enrollment card. Each student who was in attendance for the current school year has a Directory Information (FERPA) form. All residency/guardianship affidavits have been renewed (where applicable) entered in the SIS, and filed in the

student’s cumulative folder. All enrollment cards for next school year have been checked against the information in the SIS and updated,

with parent/guardian names, addresses, phone numbers, etc. – if valid for current year. Address Audit has been run and all Relation Resides (priority 1) Contact addresses have been updated. Education Records All students have cumulative folders with typed or legible handwritten labels on the tabs, which include the

student’s legal name, ID#, and birth date. All cumulative cards are COMPLETE and up to date (be sure all entry and withdrawal dates are updated and

correct). A copy of the current school year’s enrollment card (front and back) has been placed in the student’s cumulative

folder. All current school year’s report cards/progress reports have been placed in the students’ (active as well as

withdrawn) cumulative folders. The current school year’s Report Card CD has been stored in the building. Verify that other staff on your campus

know where this disk is stored. Electronic grade books for all teachers have been stored in the building for 5 years, including the current school

year. All cumulative folders have been/will be moved to the appropriate grade level drawers for next year after the

school year has ended. Standardized test labels have been affixed to the cumulative cards. All absences have been entered/resolved in the SIS. All absence attendance records not requested by Records Management, have been resolved in the SIS and

stored on your campus for an additional 5 years. All absence excuse notes not requested by Records Management have been resolved in the SIS and stored on

your campus for an additional 5 years. Attendance records, requested by Records Management, are organized as directed by Records Management and

transported to the designated location. All current school year Directory Information (FERPA) forms have been are organized as directed by Records

TOG Appendix G


Management, and transported to the designated location. One copy of a student’s withdrawal form is in the cumulative folder and one copy is attached to the back of the

enrollment card sent to Records Management. Each withdrawal form is completely filled out, including the withdrawal date, reason, and appropriate signatures.

Identified withdrawn student cumulative folders are purged as directed by Records Management and transported to the designated location.

The current school year enrollment cards are organized as directed by Records Management, and transported to the Records Management. Headers on these enrollment cards are accurately and completely filled in.

Purged materials have been disposed of in an appropriate manner – by shredding them with an electric shredder, paper cutter, or scissors; or by sending them for destruction.

All vital documentation, such as class lists, class counts, late entries, withdrawals, etc. for the school year are organized in a notebook or file folder and stored in a convenient place on your campus. Others on your campus know where these records are stored.

Junior High(s) have been provided with lists of current 6th grade students who may require a new transfer, or residency or guardianship affidavit before beginning the new school year as 7th graders.

All 6th grade student records have been transported to the appropriate next year campus as requested. Emergency cards for the next school year have been ordered. All current students’ for next year’s enrollment have been documented in NET (new students for next year have

been documented separately). Other end of year requirements have been completed – as sent to you by email or interoffice memo (attach

copy of email/memo and initial). Next Year Prep All enrollment cards for next year have been signed by the parent/guardian and are accompanied by a new

Proof of Residency. (A child may not be posted on a class list in August, unless he/she has a new Proof of Residency. Be sure to call or send out reminders to those who are lacking – and document your follow-ups.)

Lists of students who require privacy, ethnicity and/or race updates for the next school year, have been generated and stored for correction after mass break.

ESL All ESL students are coded correctly in the SIS. ESL teachers have submitted all ESL additions, changes,

and/or dismissals to the Newcomer Center for coding. There are no students coded as ESL that have been dismissed. All current ESL students have been coded as ESL in the SIS.

All ESL students are coded with a language other than English as their home language in the SIS. All bilingual students are coded correctly in the the SIS, and with the correct home language (not English).

Bilingual teachers have submitted all bilingual additions, changes, and/or dismissals to the Newcomer Center for coding. (There must be no students coded as bilingual in non-bilingual schools).

All students coded LEP only (not receiving services/parental denials) in the ESL field have supporting documentation in their cumulative folders of the parent’s refusal of ESL services. (These students should not be coded as being served in the SIS).

Special Ed All Special Ed students are coded correctly. Special Ed teachers have submitted special education additions,

changes, and/or dismissals to the appropriate Special Ed central office. All Special Ed students have the correct instructional setting, disabilities, and services in the SIS. Principal All discipline data has been entered for the year, and error reports have been corrected. Nurses All immunizations have been entered for the year, and error reports have been corrected.

TOG Appendix G


Sign-off Legend


(Attach extra sheet for additional initials/sign-offs.) Please initial and return all of these pages with the End of Year Checklist Sign off Sheet to your campus's appropriate Student Information Specialist in Student Information and Reporting no later than the following Friday after the week the school year has ended.

TOG Appendix G


Elementary End of Year Checklist Sign Off Sheet


I have reviewed and complied with all applicable items stated on the End of Year Checklist provided by Student Information and Reporting.

The information entered into the SIS and the information organized in the students’ cumulative folder is correct, according to the best of my knowledge.

All pertinent student records have been transported to Records Management and to the appropriate next year campus.

All other records which are to remain at the local campus are properly stored, including teacher grade/attendance books and absence notes.

Important information such as advisor lists, class lists, enrollment counts, entry and withdrawal lists, etc. have been organized in a file folder or notebook, and are easily accessible for future reference at the local campus.

School Date



TOG Appendix H

Elementary Fall PEIMS Checklist Page 1 of 3 Revised July 2013/TOG App H

Elementary Fall PEIMS Checklist THINGS TO VERIFY BEFORE LAST FRIDAY IN OCTOBER - PEIMS “AS OF” DATE

DEADLINE FOR YOUR ACTIONS – ONE WEEK Initial Below

Verify you have a Directory Information (FERPA), an enrollment card, cumulative folder, and enrollment

documentation on all students. Verify that all Pre-K students (currently active or withdrawn) have been coded with PK eligibility reason

(income documentation approved by Newcomer Center on file). For schools with Pre-K programs: Verify that none of your Pre-K students turned 5 years old on or before

September 1. Verify that no kindergarten student was younger than 5 on or after September 1. Verify that all immigrant students have been coded as such in the SIS, with the immigrant date entered

in “Date Entered US Schools”, “Immigrant Status Date”, and “Academic Yrs PK-12” fields. Verify that country of birth has been entered for all students in the SIS. Verify that home language has been entered for all students in the SIS. Verify that all intra-district transfer codes and dates have been entered for all current transfer students

on your campus. (Transfers within district) Verify that all intra-district transfers have been expired for students whose transfers are no longer

current. (Transfers within district) Verify that all inter-district students have an approved transfer from the office of the elementary

executive directors to be enrolled on your campus. (Transfers from out of district) Verify that all residency/guardianship affidavits have been renewed (where applicable) entered in the

SIS, and filed in the student’s cumulative folder. Verify gifted and talented students in the SIS with your REACH list. If your list generated from the SIS

does not match the list you have of REACH kids sent from the office of Advanced Studies, please resolve the discrepancies right away (contact the Advanced Studies Executive Assistant), so that corrections are made in the SIS.

Verify that all students are in the correct grade level in the SIS. Contact Student Information and Reporting to change grade levels that are incorrect.

Verify that all no shows have been withdrawn. Verify that Student Information and Reporting (your campuses’ Student Information Specialist) has been

notified regarding any student who is served in more than one half-day program (EE, PPCD and PK) for corrected ADA coding.

Verify all student demographic information is correct in the SIS, according to the newest enrollment card and emergency card, including privacy and whom a student lives with. ONLY the student’s legal name from the birth certificate or other acceptable legal document may be entered in the SIS.

Verify that all students in your building have ethnicity/race coded in the SIS. Verify that all students have a PEIMS ID#. Verify that all Texas Unique ID issues have been corrected. Verify that any migrant students (indicated on the home language survey) have been reported to the

Newcomer Center. Verify all Service Plan (Special Status - served by special ed only) students have an enrollment card,

cumulative folder and enrollment documentation on file. Copies of enrollment cards (with the headers filled completely in) have been sent to your campuses’ Student Information Specialist for all service plan returning students. Copies of enrollment documentation must be sent along with the enrollment cards for all new service plan students.

Verify that any student, whose parents/guardians have indicated he/she is homeless, has been referred to the district’s homeless coordinator.

Verify that all ESL and bilingual students have a home language other than English entered in the SIS. Verify that ESL/Bil staff has verified there is written documentation in ELL students’ cumulative folders

that the parents gave permission for them to participate in ESL. Verify that all ESL students are coded correctly in the SIS. ESL teachers have submitted all ESL

additions, changes, and/or dismissals to the Newcomer Center for coding. There are no students coded

TOG Appendix H


as ESL that have been dismissed. All current ESL students have been coded as ESL in the SIS. Verify that all bilingual students are coded correctly in the SIS, and with the correct home language (not

English). Bilingual teachers have submitted all bilingual additions, changes, and/or dismissals to the Newcomer Center for coding. (There must be no students coded as bilingual in non-bilingual schools).

Verify that all students coded ELL only (not receiving services/parental denials) in the ESL field have supporting documentation in their cumulative folders of the parent’s refusal of ESL services. (Any student not receiving services cannot be coded as being served).

Verify that all Special Ed students are coded correctly. Special Ed teachers have submitted special education additions, changes, and/or dismissals to the appropriate Special Ed central office.

Verify that all immunizations have been entered for the year, and error reports have been corrected.

TOG Appendix H


Sign-off Legend



Elementary Fall PEIMS Submission Checklist Sign Off Sheet


I have reviewed and complied with all applicable items stated on the Fall PEIMS Submission Checklist provided by Student Information & Reporting.

The information entered in the SIS and the information organized in the students’ cumulative folders is correct according to the best of my knowledge.

School Date



TOG Appendix H


Elementary Fall PEIMS Checklist THINGS TO VERIFY BEFORE LAST FRIDAY IN OCTOBER - PEIMS “AS OF” DATE

DEADLINE FOR YOUR ACTIONS – ONE WEEK Initial Below

Verify you have a Directory Information (FERPA), an enrollment card, cumulative folder, and enrollment

documentation on all students. Verify that all Pre-K students (currently active or withdrawn) have been coded with PK eligibility reason

(income documentation approved by Newcomer Center on file). For schools with Pre-K programs: Verify that none of your Pre-K students turned 5 years old on or before

September 1. Verify that no kindergarten student was younger than 5 on or after September 1. Verify that all immigrant students have been coded as such in the SIS, with the immigrant date entered

in “Date Entered US Schools”, “Immigrant Status Date”, and “Academic Yrs PK-12” fields. Verify that country of birth has been entered for all students in the SIS. Verify that home language has been entered for all students in the SIS. Verify that all intra-district transfer codes and dates have been entered for all current transfer students

on your campus. (Transfers within district) Verify that all intra-district transfers have been expired for students whose transfers are no longer

current. (Transfers within district) Verify that all inter-district students have an approved transfer from the office of the elementary

executive directors to be enrolled on your campus. (Transfers from out of district) Verify that all residency/guardianship affidavits have been renewed (where applicable) entered in the

SIS, and filed in the student’s cumulative folder. Verify gifted and talented students in the SIS with your REACH list. If your list generated from the SIS

does not match the list you have of REACH kids sent from the office of Advanced Studies, please resolve the discrepancies right away (contact the Advanced Studies Executive Assistant), so that corrections are made in the SIS.

Verify that all students are in the correct grade level in the SIS. Contact Student Information and Reporting to change grade levels that are incorrect.

Verify that all no shows have been withdrawn. Verify that Student Information and Reporting (your campuses’ Student Information Specialist) has been

notified regarding any student who is served in more than one half-day program (EE, PPCD and PK) for corrected ADA coding.

Verify all student demographic information is correct in the SIS, according to the newest enrollment card and emergency card, including privacy and whom a student lives with. ONLY the student’s legal name from the birth certificate or other acceptable legal document may be entered in the SIS.

Verify that all students in your building have ethnicity/race coded in the SIS. Verify that all students have a PEIMS ID#. Verify that all Texas Unique ID issues have been corrected. Verify that any migrant students (indicated on the home language survey) have been reported to the

Newcomer Center. Verify all Service Plan (Special Status - served by special ed only) students have an enrollment card,

cumulative folder and enrollment documentation on file. Copies of enrollment cards (with the headers filled completely in) have been sent to your campuses’ Student Information Specialist for all service plan returning students. Copies of enrollment documentation must be sent along with the enrollment cards for all new service plan students.

Verify that any student, whose parents/guardians have indicated he/she is homeless, has been referred to the district’s homeless coordinator.

Verify that all ESL and bilingual students have a home language other than English entered in the SIS. Verify that ESL/Bil staff has verified there is written documentation in ELL students’ cumulative folders

that the parents gave permission for them to participate in ESL. Verify that all ESL students are coded correctly in the SIS. ESL teachers have submitted all ESL

additions, changes, and/or dismissals to the Newcomer Center for coding. There are no students coded

TOG Appendix H


as ESL that have been dismissed. All current ESL students have been coded as ESL in the SIS. Verify that all bilingual students are coded correctly in the SIS, and with the correct home language (not

English). Bilingual teachers have submitted all bilingual additions, changes, and/or dismissals to the Newcomer Center for coding. (There must be no students coded as bilingual in non-bilingual schools).

Verify that all students coded ELL only (not receiving services/parental denials) in the ESL field have supporting documentation in their cumulative folders of the parent’s refusal of ESL services. (Any student not receiving services cannot be coded as being served).

Verify that all Special Ed students are coded correctly. Special Ed teachers have submitted special education additions, changes, and/or dismissals to the appropriate Special Ed central office.

Verify that all immunizations have been entered for the year, and error reports have been corrected.

TOG Appendix H


Sign-off Legend



Elementary Fall PEIMS Submission Checklist Sign Off Sheet


I have reviewed and complied with all applicable items stated on the Fall PEIMS Submission Checklist provided by Student Information & Reporting.

The information entered in the SIS and the information organized in the students’ cumulative folders is correct according to the best of my knowledge.

School Date



TOG Appendix I

STR Screen Shots Fall 2013/TOG App I

STR Screen Shot – Request View

TOG Appendix I


STR Screen Shot – System Performance View

TOG Appendix I


STR Screen Shot – Approver Info View

TOG Appendix I


STR Screen Shot – Notification View

TOG Appendix J

Netiquette Fall 2013/TOG App J

Netiquette Guidelines Guidelines for Responsible Use of RISD Electronic Mail (email)

The RISD employee is expected to abide by the generally accepted rules of network etiquette, also called netiquette. These guidelines include, but are not limited to the following:

Be Polite and Professional

• Remember that all your communication with your RISD email account represents the district and your conduct online should reflect a professional manner.

• Make sure you answer emails in a timely fashion.

Don't Forward Junk or Spam

• Don’t abuse the use of mass mailings and the contact groups set up in Outlook. Only send a message to groups or mailing lists if each person on the group needs to see the message. Otherwise, choose the recipients individually.

• Political or personal lobbying is not allowed. • Delete unwanted email messages and empty your deleted items on a regular basis.

Be Informed about Privacy and Security Issues

• Protect personal information, yours and others, especially that of your students. • Do not share your email account of password with others. • Don’t attempt to read, delete, modify or copy the email of others.

Content and Formatting

• Keep messages short and to the point. • Use the “Reply All” button sparingly and only when everyone on the initial email needs to see your

response. • Put something in the subject line of your email before sending it. • Forwarding emails is a great way of sharing idea, but make sure the original idea of the message is

not hidden or buried under a lot of other email headings. Delete the long list of other users that this message might have been forwarded to.

• Don’t forward hoaxes or urban legends. • Writing a message in all caps is the same as if you were shouting at the recipient. • Use spell check before sending your message to catch any spelling or grammar mistakes.

No Guarantees of Privacy

• Be advised that email is not guaranteed to be private and is backed up regularly. Even your deleted messages can still be accessed from backups.

• Network administrators have access to all email. • Messages indicative of illegal activities may be reported.

All email can be subpoenaed or requested through open records.

The RISD email system is a part of a worldwide communications network. Electronic problems and heavy email traffic anywhere in the world can affect our local service including slow response times and network outages. Adhering to these guidelines will help assure that RISD gets maximum efficiency from our email and Internet Systems.

Contact the Help Desk for assistance with email issues.

TOG Appendix K

Archiving Outlook Page 1 of 9 Revised July 2013/TOG App K

Archiving Email - Outlook 2010

Archiving email moves your email from the district email server to another data storage location you choose. The advantages to archiving include:

1. Increase space. Archiving increases the space on the district server allowing for better service.

2. Control deletion of your emails. Archiving puts you in control of your email so it cannot be deleted until you choose to delete it. If you do not archive your email, it may be deleted by the district email administrator according to district guidelines.

Caution:

• If you archive to a data storage location and that location becomes inaccessible (for example, you lose or damage a CD containing archives or if your hard-drive containing archives crashes), you will be unable to read your archived email.

• If you archive your email to a portable device, you will want to ensure it is secure. • If you forget where you archived your email, you may be unable to read your archived email.

We address these cautions below, and give you recommendations.

In this document we discuss:

1. Setting up archiving for the first time.

2. Adding email to your archive.

3. Reading archived email.

TOG Appendix K


Setting up archiving for the first time

While there are several ways to set up archiving, the following recommendations are based on experience.

1. In Outlook, click on the Home tab, then go to the New Items drop-down arrow and click on it. Choose More Items, and then click on Outlook Data File.

TOG Appendix K


2. The Create or Open Outlook Data File window opens. In this window, you can make the following changes, if you wish:

a. Choose a file name. In our example, we named the Outlook Data File “HelpDesk Archived Email 2014”.

b. Change the saving location of the Outlook Data File. You can change the location where the Outlook Data File will be saved. In our example, we left it in the default location (in My Documents, in a folder called Outlook Files).

After you have completed any changes, click OK.

Note: There is an option to add a password. Be very cautious. If you set up a password and later forget it, you will be unable to open your archived email. The Help Desk will be unable to assist you if you create an optional password that later does not work.

TOG Appendix K


3. In Outlook you will now see your archive data folder with the name you gave it.

At this point you have an email archive location, but it is empty. Important points to remember:

• In our example, we created the archive file to be located in the My Documents folder on the computer. While we will view the contents of “HelpDesk Archived Email 2014” from within the Outlook program, the archived email is actually stored in an Outlook Data File (pst) named “HelpDesk Archived Email 2014”.

• Do not open a pst file by clicking on it. Open it within Outlook.

• Remember where your pst file is stored (you made this decision in Step 2). We recommend storing it in the default location (My Documents), but you may choose another location. If the folder is not seen in Outlook for some reason, you will need to know where the pst file is located in order to reconnect. In our example, the archived email is stored on the computer, therefore: 1. You will not be able to view it on another computer unless you copy the pst file over to

the other computer. 2. If your computer crashes or is stolen, you will lose your archived email. Please

remember to back up!

TOG Appendix K


Adding email to your archive

1. Open Outlook. When working with archived email, you view and make changes from within Outlook.

2. Make sure you see the archive folder in Outlook. If you do not: a. Click on File, go to Open, and click on Open Outlook Data File. b. Navigate to your archive file and double-click on it.

If you have already set up your archive folder, skip ahead to Steps #3 and #4. If you have not already set up your archive folder, the instructions below will assist you to set up and organize your archive folder just the way you want it. This only has to be done once, and you can make changes later if you want. Each person will have their own preferences. For example, here are some options:

• For ease of use, you could set up your archive folder with the same structure as your Outlook Mailbox. Therefore, you would want subfolders named “Inbox”, “Sent” and “Deleted”.

• You may want to use subfolders to further organize your archived email. Thus, you could create subfolders for certain timeframes, certain projects, or for email from specific persons.

See the example below for a set-up that uses several of these options. This is too complicated for most people, but it shows you the possibilities.

TOG Appendix K


Here’s how you can create the subfolders you want for your archives: a. Right click on the main archive folder to see a menu like this:

Click on New Folder.

b. Name the new folder. In the example, we named the new folder “Inbox”. Since we began the process by right clicking on the main archive folder (named “HelpDesk Archived Email 2014”), the new folder “Inbox” will be created as a subfolder of "HelpDesk Archived Email 2014".

Click on OK.

TOG Appendix K


c. The archive folder now looks like this, showing the addition of “Inbox”:

Continue creating subfolders until you have the setup you want. You can always add more subfolders later by following these instructions. Note: if you want to create a subfolder under a subfolder, then you should begin by right clicking on the subfolder. For example, to create a subfolder called “Accounting” under the subfolder “Budget Emails”, begin by right clicking on “Budget Emails”.

3. Your next step will depend on what you want to archive. For example, let’s say you want to archive certain emails you have recently sent.

a. Open up your Sent Items. b. Find the sent items you want to archive and highlight them.

To highlight several at once: 1) either hold down the Ctrl key while you click on your choices; or 2) click the top item, hold down the Shift key and click the bottom item to highlight all in between.

TOG Appendix K


4. Right click on the highlighted message(s), and choose Move.

5. Find your archive folder (and subfolder), and click to highlight the subfolder to where you wish to move your Sent items. In our example we have chosen to move three items to the subfolder named “Sent” under “HelpDesk Archived Email 2014". This moving process can also be accomplished by dragging and dropping or by copying or cutting and then pasting.

6. Continue this process for Inbox or Deleted or any other email you may wish to archive.

TOG Appendix K


Reading archived email.

Reading archived email is like reading any other email, but remember the following: 1. You must read archived email from within the Outlook program. Your first step is to open

Outlook. 2. Make sure you see the archive folder in Outlook. If you do not:

a. Click on File, go to Open, and click on Open Outlook Data File. b. Navigate to your archive file and double-click on it.

3. You will not be able to read your archived email if the place where you stored it is not available. For example, if you stored your archives on a flash drive or CD, then the flash drive or CD must be in/connected to the computer you are using. If you stored your archived email in My Documents on another computer, then you must read the archived email on that computer (or have a copy of the pst file and map to it).

Conclusion: Like most data storage tasks, archiving takes a little work to set up at first. Once set up, it is easy to do. If you want to ensure that your email will not be deleted from your mailbox by the system administrator, archiving is a must. We recommend archiving once a month. Finally, consider the cautions we mentioned at the beginning:

1. If you archive to a data storage location and that location becomes inaccessible (for example, you lose or damage a CD containing archives or if your hard-drive containing archives crashes), you will be unable to read your archived email.

2. If you archive your email to a portable device, you will want to ensure it is secure. 3. If you forget where you archived your email, you may be unable to read your archived email.

The solution to each of these potential problems: 1. Back up your archive file (pst). 2. If you put your archives on a portable device, keep the portable device secure. 3. Write down the location of your pst file if you think you might forget.

TOG Appendix L

Glossary of Terms Fall 2013/TOG App L

Glossary of Terms

AAR – Academic Achievement Record

ACI – Accountability and Continuous Improvement department

API – Application Programming Interface

COC – Certification of Completion

DBA – Database Administrator

DNT – Director of Network Technology

DONS – Director of Network Services

DS – Deputy Superintendent

EBA – Enterprise Backup Administrator

EDIS – Executive Director of Information Services

EDIT – Executive Director of Instructional Technology

EDIT+ ‐ A web‐based software application which offers an interface for districts to transfer PEIMS data files to TEA, validate the data, then generate reports.

EDSIR – Executive Director of Student Information and Reporting

ESC – Education Service Center (e.g. Region 10)

FERPA – Family Education Rights & Privacy Act

GED Tests – General Educational Development tests

HR – Human Resources

HVAC – Heating, Ventilation, & Air Conditioning

IT – Instructional Technology

IS – Information Services

M&O – Maintenance & Operations

NSG – Network Services Group

OEBS – Oracle e‐Business Suite™

OEBSSTR – Oracle e‐Business Suite™ Software Test Request

PBMAS – Performance‐Based Monitoring & Assessment System

PDC – Professional Development Center (located 701 W. Beltline Road in Richardson)

PEIMS – Public Education Information Management System

PET – PID Enrollment Tracking. The PET submission is a report of student enrollment information for the current school year.

PID – Person Identification Database. The system used by the TEA to manage and store identifying data on individuals who are reported to TEA. These individuals include: students and staff who are reported through the PEIMS and recipients of high school equivalency credentials [based on the GED tests].

PM – Program/Project Manager

RFP – Request for Proposal

RIMS – Richardson Instructional Management System

RISD – Richardson Independent School District

RUG – Responsible Use Guidelines. The RUG is provided annually within the Employee Handbook to all RISD employees. The RUG is

TOG Appendix L

Glossary of Terms Fall 2013/TOG App L

also available on the RISD Intranet under “Documents”.

SAAH – Student Attendance Accounting Handbook

SAC – Superintendent’s Advisory Council

SDS – Student Data Specialist

SIS – Student Information System

SLA – Service Level Agreement

SNE – Senior Network Engineer

SMOL – Student Management On‐Line

STEM – Science‐Technology‐Engineering‐Math program at Berkner High School

STP – Strategic Technology Plan

STR ‐ Software Test Request

TAC – Technology Advisory Committee

TAKS – Texas Assessment of Knowledge and Skills

TEA – Texas Education Agency

TOG – Technology Operating Guide

TREx – Texas Record Exchange

UPS – Uninterruptable Power Supply