Purpose This document defines the overall policy, principles, and requirements that govern the mybyu Portal.

Similar documents
Subject: University Information Technology Resource Security Policy: OUTDATED

Jenzabar EX 4.5. Getting Started Guide for Administrators and Users

Security Awareness, Training, And Education Plan

POLICIES AND PROCEDURES

Muskegon Community College Web Guidelines (Updated October 31, 2016)

Access to University Data Policy

UTAH VALLEY UNIVERSITY Policies and Procedures

Conflict of Interest Web System

Community Use Agreement

OUTDATED. Policy and Procedures 1-12 : University Institutional Data Management Policy

UNIVERSITY OF MASSACHUSETTS AMHERST INFORMATION SECURITY POLICY September 20, 2017

ASUW Communications Policy Created August 2013

Information Security Incident Response and Reporting

Policies & Regulations

Information Official District information as defined herein and/or by other Board policy.

UNIVERSITY OF MASSACHUSETTS AMHERST INFORMATION SECURITY POLICY October 25, 2017

BERKELEY COLLEGE Social Media Policy

Architecture and Standards Development Lifecycle

The Event Request form is located under the News & Events tab on the SABA website. 2

University of Hawaii Hosted Website Service

The Table Privacy Policy Last revised on August 22, 2012

Policy Document. PomSec-AllSitesBinder\Policy Docs, CompanyWide\Policy

CAMERON UNIVERSITY AggieAccess Channel Policy

MANUAL OF UNIVERSITY POLICIES PROCEDURES AND GUIDELINES. Applies to: faculty staff students student employees visitors contractors

DIGITAL COMMUNICATIONS GOVERNANCE

Data Governance Framework

Active Directory User Management System (ADUMS) Release User Guide

Acceptable Use Policy

UNIVERSITY OF NORTH FLORIDA. Institutional Review Board (IRB) Guide to IRBNet:

ELIZABETH CITY STATE UNIVERSITY Web Page Policy

IDAHO STATE UNIVERSITY POLICIES AND PROCEDURES (ISUPP) ITS Responsible Use of Telephone, Telecommunications, and Networking Resources ISUPP 2280

Privacy Policy I. COOKEVILLE COMMUNICATIONS PRIVACY POLICY II. GENERAL PRIVACY GUIDELINES

I. PURPOSE III. PROCEDURE

Electronic Memorandum of Agreement ( emoa ) FAQ

Handshake Guide For Supervisors

SECURITY PLAN CREATION GUIDE

NAU Affiliation Agreements

Working with Groups, Roles, and Users. Selectica, Inc. Selectica Contract Performance Management System

Employee Computer Usage Policies and Procedures

PROCESS FOR INITIAL CERTIFICATION OF CERTIFIED SCRUM TRAINER PROFESSIONALS WITH CERTIFICATION STANDARDS

Chapter 4 EDGE Approval Protocol for Auditors Version 3.0 June 2017

NZX Participant Compliance

CONSTRUCTION MANAGER CERTIFICATION INSTITUTE. Recertification Point Provider Guide

Oracle. Sales Cloud Using Partner Relationship Management for Partners. Release 13 (update 18B)

TITLE SOCIAL MEDIA AND COLLABORATION POLICY

Texas A&M University: Learning Management System General & Application Controls Review

UCSB IT Forum. April 15, 2014

Virginia State University Policies Manual. Title: Information Security Program Policy: 6110

LOYOLA UNIVERSITY MARYLAND. Policy and Guidelines for Messaging to Groups

Request For Proposal ONWAA Website & E-Learn Portal

Ferrous Metal Transfer Privacy Policy

Washington State Emergency Management Association (WSEMA) Olympia, WA

Green Star Volume Certification. Process Guide

FinFit will request and collect information in order to determine whether you qualify for FinFit Loans*.

IAM Project Overview & Milestones

Constitution Towson University Sport Clubs Organization Campus Recreation Services. Article I Name. Article II Membership

Drexel University. Page 1 of 48. Version November agf

NCURA 2011 Region IV Spring Meeting. Introduction to Electronic Document Routing

January Alberta Carbon Registries

WESTERN NEW ENGLAND UNIVERSITY DIGITAL GOVERNANCE & STANDARDS

University staff and student broadcast policy. Overview. Scope. Related Documents

What information is collected from you and how it is used

POLICY 8200 NETWORK SECURITY

IRBManager Quick Start Guide INITIAL APPLICATION - OVERVIEW

Web Hosting: Mason Home Page Server (Jiju) Service Level Agreement 2012

Exchange Network Schema Conformance Report Preparation and Review Process

PeopleSoft Finance Access and Security Audit

RMU-IT-SEC-01 Acceptable Use Policy

DOE Intranet Quick Reference Getting Started

Student Union Social Programming Board Constitution

REGULATION BOARD OF EDUCATION FRANKLIN BOROUGH

Access Control Policy

SLAS Special Interest Group Charter Application

ISO STANDARD IMPLEMENTATION AND TECHNOLOGY CONSOLIDATION

Marshall University Information Technology Council. Procedure ITP-16 IT INFRASTRUCTURE AUTHORIZATION PROCEDURE

Missouri Housing Development Commission Certified Property Management Agent Program

Acceptable Use Policy (AUP)

Service Description: Software Support

Effective: 12/31/17 Last Revised: 8/28/17. Responsible University Administrator: Vice Chancellor for Information Services & CIO

Visual Studio Subscriptions Administration Guide

Video Services Forum Rules of Procedure

ASP Professional Standards and Certification Program for Strategic Planning and Strategic Management ASP CERTIFICATION

PCORI Online: Awardee User Guide Research Awards

01.0 Policy Responsibilities and Oversight

PeopleAdmin 7 User s Guide. Applicant Tracking System - Faculty Positions -

NYISO Member Community Reference Guide

TABLE OF CONTENTS. WELCOME TO mycsa... LOGGING IN... FORGOT PASSWORD... FIRST TIME REGISTRATION... ACCESS TYPE... GETTING STARTED...

Online CDC service. HowTo guide for certifying organisations

Virginia Commonwealth University School of Medicine Information Security Standard

Northern Virginia Community College Social Media Guidelines

WIT Diverse Campus Services Ltd. Data Protection Policy

Change Healthcare CLAIMS Provider Information Form *This form is to ensure accuracy in updating the appropriate account

OIX DDP. Open-IX Document Development Process draft July 2017

University of Wisconsin-Madison Policy and Procedure

Grade Change Workflow

Primavera Portfolio Management 9.1 Bridge for Microsoft Office Project Server 2007 Users Guide

Kuali Coeus Implementation: IRB Progress Report. October 7, 2013

Release Notes

Development Officer Refresher Training

Payment Card Industry (PCI) 3-D Secure (PCI 3DS) Qualification Requirements for 3DS Assessors

Transcription:

mybyu Portal Policy 1.0 Status Draft Approval Date Pending Next Review Date 9/--/2010 Owner CIO Purpose This document defines the overall policy, principles, and requirements that govern the mybyu Portal. Policy To encourage and enable broad participation in creating and making available useful content and services for the University community through the enterprise Portal (mybyu), portal users, portal content creators, and portal providers are expected to comply with the requirements regarding portal development, portal content, portlet publication, portal administration, and portal support and operations (see www.xxxx for requirements and related procedures). In general, the following principles guide the specific requirements: Any member of the BYU community and authorized third-parties may develop content for the portal. No portlet may be published in mybyu without the endorsement of a university sponsor. Contributors to, and users of, the portal are expected to comply with University policies concerning computer and electronic resources and with the Honor Code. Prioritization for the creation and enhancement of portlets will occur through the annual resource planning process if ITD funding is requested, or will occur at the departmental/unit level if locally funded. Unsupported portlets will be made available to users. The CIO reserves the right to remove any content without notice. The Office of Information Technology will make available resources and tools to enable any member of the BYU community to create content for the portal. Change Log Date Revision Author Description

Number 1.0 9/15/2010 Christine Tolman

mybyu Administration Requirements 1.0 Status Draft Approval Date Pending Next Review Date 9/--/10 Owner Portal Service Team (PST) Purpose The objective of this document is to define the requirements associated with the administration of the core components of mybyu. Scope This requirements document will focus on administration of the central uportal application, portlet and tab library, and the gallery of mybyu themes. Compliance Plan The Portal Service Team (PST) will meet periodically to a. Review compliance with these requirements and make adjustments as necessary. b. Identify and update the approved list of administrators for mybyu. Context 1. The mybyu portal is built on uportal technology. By default, an admin account is created and placed in a group called Portal Administrators group. 2. uportal supports the concepts of user groups for rights and privileges.

Requirements 1. The Portal Service team-- a. Approves additional admin accounts, or user accounts with administrative privileges. b. Identifies groups and which users will be members of each group (using the Group Reference Object). 2. Production Services-- a. Creates and administers user groups for uportal under the direction of the Portal Administrator. b. Retains the admin password to the production instance of the mybyu portal by default c. At the request of the Portal Administrator and with the approval of the CIO or his designee, deletes, or removes portlets, themes, or tabs, that are deemed inappropriate, perform poorly, or that are not in compliance with other mybyu policies. d. Backs up and, in the event of a system failure or outage, restores core features and configuration data as well as user settings and customized layout settings e. Has rights (and knowledge) necessary to initiate start, stop, and re-start batch processes for the production instance of mybyu. 3. uportal Administrators a. May act as a user proxy to access, customize or administer individual accounts in response to a user request for support. b. Have the ability to modify both the Groups Manager as well as the Portlet Manager. c. Can access other administrative portal user interfaces. 4. Changes to the production instance of mybyu (including upgrades to the uportal infrastructure and JSR 168 portlets) require a. An approved change order. b. Successful outcomes when tested for performance and compliance in development and stage environments.

Change log Number Date Revision Author Description 1.0 5/18/10 Troy Martin Initial draft submitted for review. 1.0 6/23/10 Peter Sentz Updates in collaboration with Troy Martin and Dan Clegg 1.0 7/28/10 Christine Tolman 1.0 9/18/10 Christine Tolman Updates in response to feedback from CIO and PST

mybyu Content Requirements 1.0 Status Draft Approval Date Pending Next Review Date 9/--/2010 Owner CIO Purpose This document defines what content is considered acceptable for inclusion on the mybyu Portal. Scope This set of requirements specifically addresses content requirements for portlets, tabs, and themes. Compliance Plan 1. The Portal Governance Advisory Board (PGAB) will meet periodically to review compliance to the statements associated with this policy and recommend changes to the CIO. 2. Before a portlet, gadget, tab or theme is released for production in mybyu, the Chair of PGAB will review all portlets, tabs, and themes for appropriateness of content as defined in this document. Requirements Portlets, tabs, or themes may not include, or display content that includes the following: 1. Any violation of the BYU Honor Code. 2. Any violation of the University s Computer and Electronic Communications General Use Policy 3. Copyright Violations: Web pages must be free from copyright violations. You are responsible to verify permission for any copied materials. 4. Invasions of personal privacy. 5. Collection of personal information, including credit cards and user credentials. 6. Portlets that include social security numbers must have all but the last four digits masked (see SDK for details). 7. Impersonations of third parties, including other Universities, businesses, or organizations. 8. Promotions that contain hate, violence, discrimination.

9. Illegal Content Ensure that all links, applications, digital content agreements are complied with the original provider. Icons, pictures, and other elements that can be used by more than one person exist in a shared domain in a gallery or as part of the templates. Unless specifically exempted, any materials submitted for use in this way will become college domain and will be available in this directory. 10. Political Affiliation: The essential function for the university requires strict institutional neutrality, integrity, and independence regarding political activities. 11. All content must be Family Safe, no pornography, or obscene content will be allowed. 12. Content that interferes with normal operation and functions of the mybyu Homepage. 13. Advertising for off-campus products or services (advertising for BYU programs, events or sales is allowable). 14. Any other content deemed inappropriate for the BYU community. The content of portlets, tabs, and themes is expected to: 1. Be useful (meet the needs of students, faculty, and/or staff) 2. Improve access to information and services. 3. Be graphically pleasing and appropriately represent BYU standards and values. 4. Support the mission of the University. Change Log Number Date Revision Author Description 1.0 5/18/10 Troy Martin Initial Draft submitted for review 1.1 6/23/10 Peter Sentz Updates in collaboration with Troy Martin and Dan Clegg 1.2 7/28/10 Christine Tolman 1.3 9/17/10 Christine Tolman Updates in response to feedback from CIO and PST

mybyu Development Requirements 1.0 Status Draft Approval Date Pending Next Review Date 9/--/2010 Owner Portal Service Team (PST) Purpose This document defines the requirements for creating content (portlets, tabs and themes) for the mybyu portal. Scope This policy applies to anyone who creates mybyu portlets, tabs and themes for publication in the mybyu portal. Compliance Plan At the time a portlet, tab, or theme is submitted for publication, the mybyu Portal Administrator will review all new and changed portlets, tabs, and theme submissions to ensure that they meet the development requirements as defined. Requirements Who can develop content for mybyu: 1. Portlets, tabs and themes may be developed by any member of the BYU community (students, faculty, or staff) and authorized third-parties. 2. Employees developing content using University resources or on University time are required to have received approval from their line manager. 3. Anyone planning to develop content for publication in mybyu must agree to the Terms of Use published in the SDK and presented at the time content is submitted for publication.

Portlet, Tab and Theme Requirements: 1. Portlets, tabs, and themes must be developed following the standards described in the latest version of the Portal Software Developer s Kit (SDK). See www.xxxx for details. a. The following patterns for creating portlets are encouraged: i. XML Web Service ii. Proxy Portlet iii. RSS iv. Deep Linking v. Image b. SQL is discouraged c. Java Applets and JSR-168 portlets require prior approval (see www.xxx) for details. 2. At the present time, developers wishing to develop JSR-168 portlets may do so only-- a. As part of a planned and funded project done in collaboration with OIT b. As part of a departmental project, sponsored by their line management i. After being certified by the Office of Information Technology as JSR-168 developers. Contact for more information. ii. Collaborating with OIT Portal engineers for testing and publishing (deploying) portlets. Prepared for testing and publication in collaboration with OIT (Contact for more information) iii. After agreeing to provide or pay for the full monitoring and support of each JSR- 168 Portlet 1. May contract with OIT to provide these services 2. A service level agreement would be established 3. Portlets may only use web services that are in the University s Web Services Registry unless an exception has been approved by the CIO or the web service is an approved 3 rd party web service (e.g. Amazon s EC2). a. To assure compliance with data sharing agreements b. To assure high quality portlets 4. Portlets, tabs, and themes must meet the mybyu Content Policy. Change log Number Date Revision Author Description 1.0 5/18/10 Troy Martin Initial draft submitted for review. 1.1 6/23/10 Peter Sentz Updates in collaboration with Troy Martin and Dan Clegg 1.2 7/28/10 Christine Tolman Revision following review by PST

1.3 9/17/10 Christine Tolman Updates in response to feedback from CIO and PST

mybyu Portlet Publication Requirements 1.0 Status Draft Approval Date Pending Next Review Date 9/_/10 Owner CIO Purpose The objective of this document is to define the policies associated with the publication of portlets in mybyu. Scope This requirement will focus on publication of portlets in mybyu, the enterprise portal. Compliance Plan 1. The Portal Service Team (PST) will meet periodically to review compliance to the statements associated with this policy and recommend changes to the CIO. 2. Portlets published in mybyu will comply with established processes for production systems. Policy Statements The following statements are associated with this policy: 1. Before any portlet can be considered for publication, it must be registered and submitted for testing in mybyu (see www. xxx). a. Portlet authors are expected to have evaluated the functionality and performance of their portlet prior to submission for testing. b. A checklist identifying portlet elements to be tested is included in the SDK (see www.xxx) 2. Following a successful test, a portlet must be submitted for publication (see www. XXX) 3. A portlet author must agree to the BYU Portal Terms of Use before a portlet can be published in mybyu (see www.xxx and included in the online Submit for Publication form.)

4. Every portlet published in mybyu must be reviewed by a University sponsor (see Portlet Sponsor requirements below) who endorses the portlet for publication after verifying that the proposed portlet-- a. Is consistent with relevant policies and programs managed by the sponsor. b. Does not contain inappropriate content. 5. Portlet Sponsor Requirements a. A portlet sponsor must be a full-time employee of the University and must be either a i. Data steward, or a ii. Dean, Director, or Vice-President b. There are two types of portlet sponsors: i. A vested sponsor a person who provides the financial resources for developing the portlet, initiates the creation of the portlet, guides the development of the portlet, and arranges for its long term support. ii. Designated sponsor the person whose role is limited to validating that a proposed portlet does not conflict with programs or policies for which they are responsible. 6. In the event the University sponsor does not support the publication of a proposed portlet, the sponsor must a. Provide a written notification of rejection to the CIO or his designee b. Include specific reasons for the rejection and c. Where appropriate, describe changes the portlet submitter could make that would make it possible for the sponsor to endorse the portlet 7. Any portlet not endorsed for publication by a University sponsor, may be escalated to the ITPC for consideration at the discretion of the Information Technology VP/CIO. 8. Portlet Naming a. Portlets are identified by title and name i. Title is the name that appears in the portlet banner ii. Name is the name that appears in the portlet gallery b. When naming a portlet (giving it a title or name) portlet authors are to observe the following conventions: i. Use short, user-oriented terms (25 character titles; 30 character names) ii. When starting the title with my 1. Use lower case m and y 2. Followed by no space (e.g. mybenefits) iii. Otherwise, start with a capital letter iv. Capitalize only the first letter of every word v. Avoid the use of organization names vi. Do not use acronyms vii. Do not add the word Service or Portlet at the end viii. Do not contain a version number ix. Do not use underscores

x. Do not use an existing portlet name or title; the portlet name and title must be unique 9. Portlet Lifecycle a. Every portlet submitted for publication must identify i. A date for publication ii. A date for expiration (if applicable) b. Production Services will configure the portlet accordingly. 10. Portlet Support. a. Portlets submitted for publication must include a description, with appropriate documentation, of the support that will be provided to end users of the portlet; No Support is an option. (See mybyu Support and Operations Policy for details.) b. For cost-tracking purposes, every portlet must be assigned to an OIT parent product or service; non-supported is a valid option. c. A sponsor may adopt an unsupported portlet and assume responsibility for enhancements and support i. In response to an invitation by the Portal Administrator or ii. At their own request. 11. No portlet may be published in mybyu without the express approval of the CIO or his designee. Change log Number Date Revision Author Description 1.0 8/18/10 Christine Tolman Draft submitted for review 1.1 9/17/10 Christine Tolman Updates in response to feedback from CIO and PST

mybyu Support and Operations Requirements 1.0 Status Draft Approval Date Pending Next Review Date 9/--/2010 Owner Portal Service Team (PST) Purpose Define the requirements for the operations and support of the University portal, mybyu, and its content (portlets, tabs, and themes). Scope These requirements apply to the operation and support of mybyu and its content (portlets, tabs, and themes). Compliance Plan The CIO or his designee, upon the recommendation of the Portal Administrator, must give final approval before any additions, or changes, to mybyu or its content (portlets, tabs, and themes) can be released in the production version of the portal, made available to campus, and where applicable, supported by OIT. Requirements Portlets 1. Each published portlet must have been endorsed by a University sponsor (see mybyu Publication Policy for Portlet Sponsor requirements.) 2. Portlets submitted for publication must include a description, with appropriate documentation, of the support that will be provided to end users of the portlet. Support must be provided at one of the following levels: a. Full Support (see www.xxx for details). i. May be provided by the vested sponsor or by OIT(as a contracted service) ii. Required of any JSR-168 portlets

b. Limited support (information about who to contact if there are problems with the portlet with minimal resources committed to resolve problems and answer questions). c. No Support. When this option is selected, i. The portlet will be designated as Unsupported in portlet information ii. The portlet may be withdrawn from production at the discretion of the Portal Administrator. iii. Users of Unsupported portlets will be advised: No support is available for this portlet; use at your own risk! 3. For cost-tracking purposes, every portlet must be assigned to an OIT parent product or service that is an-- a. Existing OIT Product or Service b. New OIT Product or Service c. Unsupported/Non-OIT Product or Service Tabs Every Tab accepted for inclusion in the Portal Gallery must have a University sponsor who assumes responsibility for-- a. Defining the Tab content with related configuration requirements b. Approving proposed changes to Tab content c. Submitting requests for updates to the Tab content and related configuration requirements to the Portal Administrator

Themes 1. The CIO or his designee approves all Themes included in the Portal Gallery. 2. OIT assumes all support and operational responsibilities for all Themes included in the Portal Gallery. ing Requirements for Portlets, Tabs, and Themes: 1. Only one version of a portlet or tab may be in production at any time. 2. Portlet authors wishing to add, or change a portlet, follow the same process as that outlined for a new portlet. 3. All changes to production portlets, tabs, and themes will go through a standard change process a. To ensure that the portlet, tab, or theme is properly documented, certified, and registered. b. Change requests for portlets will be prioritized by the Portal Administrator based on i. Amount of usage and visibility to campus ii. The urgency of the requesting portlet developer (their business needs) Portlet Deprecation/Removal: 1. The Portal Administrator reserves the right to remove or disable any content because of poor performance, inappropriate content, or any other justifiable reason. a. The CIO or his designee must approve the deprecation of a portlet. b. The Portal Administrator is responsible for providing the CIO or his designee with information describing the expected impact resulting from the deprecation/removal of content or a portlet. c. The Portal Administrator is responsible for notifying the portlet developer and sponsor and providing the reasons for the action taken. 2. Vested sponsors assume responsibility for announcing retirement of content when it becomes unneeded or obsolete. Change Log Number Date Revision Author Description 1.0 5/10/10 Troy Martin Initial draft submitted for review. 1.1 5/14/10 Dan Clegg Revised policy content. 1.2 5/19/10 Dan Clegg Organized by support/operation area or task. 1.3 6/22/10 Dan Clegg Final revision, submitted for review.

1.4 6/23/10 Peter Sentz Merged changes into the publishing policies 1.5 8/31/10 Chris Tolman Revisions to simplify and align with other policy documents 1.6 9/17/10 Christine Tolman Updates in response to feedback from CIO and PST