Appendices

Last updated September 27, 2014.

APPENDIX A. Kuali OLE staff contributions

Last updated September 27, 2014.

OLE Partner Resource Requirements

These are the MINIMUM required resources for each partner.

(Contribution includes meetings, travel, decision making)

  • OLE Board Voting Member: 1 one-hour meeting per month; 2 one-day face-to-face meetings per year
  • OLE Functional Council Voting Member: 2 two-hour meetings per month
    • Ad-hoc Workgroup Activities: 4 two-day face-to-face meetings per year
  • OLE Technical Council Voting Member: 1 one-hour meeting per month
    • Ad-hoc Workgroup Activities: 2 two-day face-to-face meetings per year

(Contribution includes meetings, travel, workgroups, decision making)

  • Subject Matter Expert Deliver Module 10%
  • Subject Matter Expert Describe Module 10%
  • Subject Matter Select & Acquire Module 10%
  • Technical Matter Expert System Integration & Infrastructure 10%

(Contribution includes meetings, travel, script writing, test execution)

  • Deliver Module Tester 15%
  • Describe Module Tester 15%
  • Select & Acquire Module Tester 15%
  • System Integration & Infrastructure Tester 15%

These are the CRITICAL resources required for each module and may be in addition to, or a part of, the above MINIMUM required resources.

(Coordination of meetings, spec writing leadership and delivery, JIRA management)

  • Module Lead Subject Matter Expert 30%
  • Module Business Analyst 50%

(Coordination of meetings, test script writing, testing execution, JIRA management)

  • Module Testing Coordinator 25%

APPENDIX B. Training Plan

Last updated September 27, 2014.

General Overview

When transitioning from Horizon/Millennium to OLE, most of the Library’s departments will need to determine what staff training will be needed in order for staff to continue to perform their primary responsibilities without undue interruption.

Note: While the Library may have multiple departments performing the same general function(s), e.g., we have four cataloging departments in D’Angelo Law Library, East Asia, Regenstein Library and Maps, the ultimate goal is to have ONE training class (or series of classes if needed) that meet the needs of ALL departments performing the same function, e.g., one “Introduction to Cataloging on OLE”, not four.

All Library staff members will need to learn basic features of OLE in order to perform any function now done in Horizon or Millennium, e.g., how to login; searching the Library’s database of bibliographic, holdings and item-level data; navigating from one type of record to another; recognizing common characteristics of screen layouts; permissions; etc.

In addition to this “basic training” (which becomes the foundation on which topic-specific training can be developed), Library staff will need to learn to use OLE to perform tasks specific to their responsibilities, e.g., create an order, loan a book to a patron, create metadata for a new title, receive a serial issue, etc. In addition to learning the functional “mechanics” of OLE, supervisors must also determine if their current basic polices/procedures (based on Horizon and/or Millennium) will also need to be altered. The “mechanics” plus the “policies/procedures” result in “workflows”, which may be defined as both:

  1. A sequence of steps to perform a standard task, some of which are done by operating a portion of the ILS
    1. Example: when Cataloging needs to create a new bibliographic record, an operator imports to OLE a record created in OCLC Connexion.
    2. Example: when Acquisitions must order a title, an operator creates a Requisition and then approves it to create a Purchase Order.
    3. Example: when a patron presents an item to borrow at a Circulation Desk, the operator scans the patron’s barcode from the ID and then scans the item’s barcode.
    4. Example: a Serials Receiving operator locates the correct record for a serial title and records receipt of a specific issue.
  2. Policies/procedures guiding decisions that must be made when performing any step in a sequence
    1. Example: a Cataloging operator must know when NOT to create a new bibliographic record, e.g., when the item in hand is an additional copy.
    2. Example: an Acquisitions operator should be able to determine when a pre-order search is or is not necessary.
    3. Example: when a patron is blocked from borrowing an item, the Circulation operator without override capability must be able to either explain the situation to the patron OR refer the patron to the appropriate staff person. The Circulation operator with override capability must know when it is appropriate to exercise that function.
    4. Example: the Serials Receiving operator must know what to do when the serial issue in hand has already been received.

Note: A “step” as used above can be defined very broadly (e.g., “create a Purchase Order), and when that it is the case, there may be a set of “sub-steps” that in turn could be a combination of “mechanics” (e.g., “select a Vendor from the list”), some of which in turn may require a policy/procedure decision (e.g., “always order from Vendor X unless told otherwise”). You might also argue that making a “policy/procedure”-based decision is, in itself, a “step”. The division of the two may be artificial in practice, but the distinction can often be helpful when trying to determine training content for learning a new system or for defining a logical structure for a training class.

Most importantly, OLE offers features not present in Horizon or Millennium. In addition, there may be certain features that we have in our older systems, but that will not be in OLE 1.5 (some of which are deferred to OLE 2.0). So, effective OLE training will require coverage of new policies/procedures along with the “mechanics” of the features. Some of these are: 

  1. OLE permits us to link one item record to multiple bibliographic records. This will mean changes in how the Library handles analyzed series because we will no longer create “dummy” items for the analyzed title record. This also affects the treatment of “bound with” items.
  2. OLE provides two types of holdings records: “holdings” (or “instance”) for titles in a physical format (print, microform, DVD, etc.) and “eholdings” (or “einstance”) for virtual titles. Rules for when to use one or the other will need to be defined.
  3. OLE allows for acquisitions to be integrated with the other functions. Workflows currently designed to use Horizon and Millennium will need to be changed and these should be reflected in training.
  4. OLE has a circulation feature that alerts an operator to count the number of pieces in a single barcoded item during the Return process whenever the piece count is greater than “1”. The Library does not currently enter Piece counts into its item records. If it decides to do so, this should obviously be incorporated into training for anyone who creates/updates OLE item records and for those who process Returns. If the feature is not to be used until a later date, the training may decide to cover this feature only in passing.
  5. OLE allows for four different types of requests (recalls, holds, paging, copying) along with the ability to allow some patrons to have requested items physically delivered to them (as opposed to having items placed on hold and picked up at Circulation Desks). How or if the Library will use these must be decided along with how a staff operator can place or fulfill these requests using OLE. OLE circulation operators should also be acquainted with how patrons will place their requests using VuFind.
  6. While serials receiving will be part of OLE 1.5, the ability to claim individual serial issues will not arrive until OLE 2.0. Instructions on an interim solution/workaround may or may not need to be part of the initial training; if not, then follow-up training will be required. [This assumes staff who receive serials also claim missing issues; in fact, there may be staff who ONLY claim missing serials in which case it, of course, makes sense to have separate training for them.] 

Note: The above list may not be complete. Each functional area will need to identify those OLE features/functions we intend to implement now (and those we will implement later) for which there are no existing counterparts in Horizon or Millennium.

Those developing training should obviously seek guidance from supervisors or other decision makers about how their respective departments intend to use (or not) these new features.

As a resource, class developers may find existing OLE documentation to be useful. The draft material (eventually to be finalized) for 1.5 can be found at:  http://site.kuali.org/ole/1.5.0-M2-SNAPSHOT/reference/html/Index.html.

Training Principals

The ILS Migration Steering Committee (IMSC) has four Working Groups (Cataloging, Acquisitions, Serials Receiving, and Circulation) with a designated Lead (Janet Fox, Head, Data Management Services, Scott Perry, Head, Collections Support, Julie Stauffer, Head of Law Acquisitions & Electronic Resources, and David Larsen, Head of Access Services & Assessment, respectively). Each Group has a membership of key staff (as named by the Leads) that are identifying gaps in OLE functionality, testing  functions by performing daily work in the local test environment, and are obviously key resources for developing the training in the four areas. 

Working Group Leads have the general responsibility for making sure that appropriate training – combining both OLE mechanics and the policies/procedures of the Library – is developed for the four major areas. [ILS takes responsibility for development of the “basics” class.] Leads should decide who attends the “train the trainer” sessions (see below for details), and they identify who will develop content and who will deliver the training (these could all be the same people or could be different people as decided by the Working Groups).

Note: All Leads and many in the Working Groups were involved in the development of Corinthian training. Any training material developed for that effort (and still extant) may prove to be useful with, of course, appropriate updating and changes.

Stuart Miller, Library Systems Analyst in ILS, and Jane Ciacci, Staff and Organization Development Librarian in Library Human Resources, are resources for anyone developing training. 

Developing OLE Training: Major Tasks

  1. Have key staff from the Working Groups attend the “train the trainer” session on April 9th. Appendix 1 contains the outline of this course, the purpose of which is to acquaint attendees with basic principles of designing training for an adult/professional audience.
  2. On April 11th (after the first “train the trainer” session), ILS will run-through the content of its “Introduction to OLE Basics” so Working Group members developing other OLE training classes will have a sense of what they need NOT cover in any detail. The “basics” class is a prerequisite for all other OLE training. [Note: With a few notable exceptions (e.g., use of “pop-ups”), this “basics” class and all other classes should assume that library staff are already familiar with Internet browsers. If anyone believes a staff member needs browser training, the Library has Firefox for Dummies available online; if staff are unfamiliar with the “Dummies” series, the word is meant to be humorous, not insulting, and titles in this series are very good for explaining the basics.]
  3. Between April 11th and May 22nd, develop training sessions (using skills/directions/suggestions from the April 9th training) for each functional area, including (but not necessarily limited to) determination of the following:
    1. Identify overall content to be covered and intended audience(s). [Note: As part of audience determination, each Working Group needs to consider whether student or part-time employees should be trained along with full-time staff OR whether it would be best to develop specially focused training for part-timers. This will of course depend upon the functional area and the extent to which part-timers have distinctly different work assignments from full-timers.]
    2. Determine if multiple audiences require multiple classes, e.g., a class “Introduction to Basic OLE Acquisitions” for all with another class “Introduction to Advanced OLE Acquisitions” for a smaller audience OR (depending on amount of material) “Introduction to OLE Acquisitions” covering everything in one class of n hours, first half for all, second half for selected staff. [Note: For staff not in one of the four areas: Acquisitions has assumed responsibility for determining the training needs of bibliographers; Stuart Miller has contacted Amy Mantrone, Head Binding and Shelf Preparation, about training needs for shelf prep staff. If there are other staff that may not “fit” into one of the four functional areas, send this information to Stuart Miller.]
    3. Identify content/length of each class along with mode of instruction (e.g., lecture/demo, hands-on, etc.). [Note: All classes should include a brief mention of how to obtain support/get answers about OLE when the Library moves into production; ILS will provide all trainers with this information.]
    4. Compile a list of which individuals (from any department) must attend which class. These lists should eventually be checked against the registration lists so that we are sure ALL affected staff take the training prior to moving OLE into production. Please make sure to consult with the appropriate managers or supervisors in ALL departments in ALL libraries when compiling these lists.
    5. Identify tasks to be done in OLE by only a few staff (e.g., updating foreign currency exchange rates; printing spine labels; etc.), make a list of points to be covered, and make arrangements to provide this training outside of a classroom setting, making sure to include ALL affected staff; share this info with the other Working Groups.
    6. Prepare any materials, e.g., PowerPoint, “cheat sheets”, handouts, documentation, etc.
    7. Decide on how many sessions of each class and what days in June 2014. The lists compiled as part of “d” (above) will help determine how many sessions will be required.
    8. As soon as possible, book a room for each class/each session; the Crerar training rooms (one seats 20, one seats 10) are being held open for any OLE hands-on training. Contact the Public Services Assistant at Crerar Library. Any other room, follow booking normal procedures. [If you book a room such as JRL A-11, you will need to contact Building Services about room set-up.]
    9. Decide on who will present the training.
    10. As practical/possible, arrange for a rehearsal of each class with an audience of the Working Groups members to give feedback.
    11. Submit registration information for each class to Jane Ciacci (see Appendix 2 for a format to follow) as soon as you have all the necessary details. Make your description of the intended audience as clear and as exact as possible. Please do this ASAP and certainly no later than May 9th. Earlier is better.
  4. Attend a “train the trainer” follow-up session in May (date TBD) to present and discuss work-to-date, get fine-tuning advice, ask questions, etc.

Post-Implementation Training

After OLE has been in production for approximately a month, ILS – in conjunction with the IMSC Working Group Leads – will schedule sessions for each of the four functional areas. Leads will use these sessions for any follow-up training that may be required. The sessions will also provide staff with an opportunity to ask questions, verify facts, suggest needed enhancements, etc. [Note: This is a supplement to the expected trouble-shooting/follow-up activities that we anticipate during the first month of OLE production that will be handled as needs arise.]

Schedule (to be expanded)

April 9: Train the trainer session

April 11: Attend Introduction to OLE Basics preview (for those developing other OLE training)

April 11-May 22: Develop training content

April 11-May 22: Submit training registration information to Jane Ciacci for posting to all staff

May [TBD]: Train the trainer follow-up session

May 22-May 30: Introduction to OLE Basics (5 sessions)

June: Deliver OLE training

Outline for April 9th “train the trainer” session

Last updated September 27, 2014.

Session Objectives:

Participants will be able to:

  1. Identify training outcomes and link to learner motivation
  2. Support learners before, during and after training
  3. Create effective learning objectives to drive training design
  4. Identify and utilize principles of effective training design for adult learners and learning styles

Pre-Work: Complete Learning Styles Assessment

Participant Materials: Designing Engaging Software Training (ASTD 16 pgs, $20/per participant)

Agenda Section/Sequence

Learning Objective

Learning Style

  • Auditory
  • Kinesthetic
  • Visual
  • Combo

Format

  • Instructor Lecture
  • Instructor Demo
  • Read/review material or job aid
  • Participant Demo
  • Pairs instruct/drive
  • Case Study
  • Application Project
  • Quiz

Time

Elapsed

Welcome

Session Purpose & Agenda

1

Combo

Instructor welcomes/introduces self

Purpose/Agenda/Ground rules/Parking Lot

Participants identify elements of effective or ineffective training, based on their experience.

Participants work in small groups to identify the stakeholder benefits of ILS software implementation.

:35

:35

Setting the Stage for Effective Training

Identify Training Outcomes (Skills/behaviors used)

Create Effective Learning Objectives

Plan for Support

1,2,3

 Combo

In ILS module teams, participants complete Tool:
Analyzing Audience Needs and Motivations Planning Tool

Lecture/discuss: Qualities of Effective Learning Objectives

Application: In ILS Module team create learning objectives

Lecture/Discussion: What activities and which roles have most impact on training application?

Application: Participants identify activities/planning elements to consider in design, delivery and post training to ensure transfer of training.

Job Aid:
Effective Pre/Post Training Support

:50

1:25

Break

Participants identify Learning Style (if not completed)

:10

1:35

Learning Styles, Learning Design and Interactivity

1,2,4

Combo

Lecture/discuss: Principles of Adult Learning

Discuss:  Impact of Learning Styles and Adult Learning Principles on training design

Video: Mel Silberman on Interactivity in Adult Learning Design

Discuss: Interactivity in Technical Training design

Methods for Technical Training Interactivity

Study/Teach Activity:  Use Training Resource Guides/Books, each of three teams becomes “expert” on methods for creating:  Case Studies, Partner Activities and Job Aids.

Job Aid/Tools:
Training Design Template & Training Design Competencies checklist

:60

2:35

Documentation/ Support Material Design

2,4

Combo

Lecture/discussion: What makes support/documentation effective?

Review UChicago examples (Gems, Time)

Explore with group:

  • Training environment
  • Availability of documentation (cloud based?)
  • Kuali resources

:30

3:05

Action Planning & Close

1,2,3

Combo

Review/Identify participant questions/concerns & possible methods to address (i.e. follow-up by Library trainees/Kuali Subject Matter Experts (SMEs), build into Facilitating Effective Training session.)

Discussion: What barriers do you anticipate? How can you use knowledge and tools from today to reduce their impact or eliminate?

Review Bibliography/Resources

Close: Motivation/call to action

Quiz: Knowledge Check

Session Evaluation

:20

3:25

Sample Registration Information

Last updated September 27, 2014.

Note: “Introduction to OLE Basics” is the prerequisite for any other OLE training class.

Course Information:
Introduction to OLE Basics

Who Should Attend?
All Library Staff Currently Using Any Features/Functions of Horizon or III Millennium

What Will This Cover?
During this two-hour lecture/demonstration, you will learn how to access and navigate around Kuali OLE, the Library’s new integrated library system to be implemented this July. You will be introduced to design features common to all of OLE’s functional components. Some specific topics include:

  • Opening OLE with your login/password using the Internet browser of your choice
  • Using browser tabs to navigate and help with workflows
  • Perform searches for basic records
  • Display records from search result
  • Be introduced to standard navigation features
  • Perform basic create/edit functions for commonly-used records
  • Features/functions common to basic records
  • Where Horizon data is found in OLE

The two-hour time frame allows ample time for a question-and-answer period. The session may end early if there are few questions.

Is There a Prerequisite?
There is no prerequisite.
Note: This class is a prerequisite for additional classes that cover OLE acquisitions, cataloging, circulation and serials receiving to be held in June 2014. Watch email for registration announcements.

Registration
Registration is required; select one session. There is a maximum of 50 attendees per session, so sign up now for your preferred day/time.

APPENDIX C. Basecamp project snapshot April 2014

Last updated September 27, 2014.

OLE Data Migrations and Integrations

Milestones

  • Acq Fit Gap analysis #1: Wed, Jan 1
  • Deliver Fit Gap analysis #2: Wed, Jan 1
  • Cataloging Fit Gap analysis #1: Wed, Jan 1
  • Full db and Fit Gap analysis by all modules: Fri, Apr 4
  • Monthly review of Decision to go for July 1: Wed, Feb 12
  • Performance test passed Dale Arntson: Fri, Apr 25
  • Training plan in place: Fri, Mar 28
  • Full VuFind running against full OLE db: Fri, Apr 25
  • Full test db with all integrations: Mon, Jun 2
  • Full VuFind db with incremental updates: Fri, Apr 25
  • GO LIVE: Tue, Jul 1

VuFind for OLE

  • Test 1.5 exports Frances McNamara: Fri, Apr 11
  • Test Villanova's OLE Connector: Fri, Apr 25
  • Test VuFind setup: Fri, Apr 18
  • VuFind My Account: Fri, Apr 25
  • Plan for switch of production VuFind: Fri, Apr 25
  • Test full db with incremental updates: Fri, Apr 25
  • Go live: Tue, Jul 1

Authentication and authorizations

  • Convene group on AuthZ/AuthN Tod Olson: Fri, Apr 11
  • Set up permissions in OLE Maura Byrne: Fri, Apr 18
  • Logons for non-university folks
  • Atlas ARES integration access issues
  • ITS security review

Describe Data conversions

  • Bib/Holding/Item Hzn conversion fixes for review
  • Bib Unicode conversion fixes for review Frances McNamara: Fri, Apr 11
  • Einstance conversion REVISIONS Frances McNamara: Mon, Feb 17
  • Serials Receiving conversion REVIEW Frances McNamara: Fri, Apr 11
  • Analytics and Bound with Conversions Frances McNamara: Fri, Apr 25
  • Linked Bibs Conversion Frances McNamara: Fri, Apr 25

Describe Integrations

  • Authorities workaround for 1.5 Frances McNamara: Fri, Apr 11
  • Spine Label Printing: Fri, Apr 4
  • Bindery Slip printing: Fri, Apr 18
  • Serial Label printing: Fri, Apr 18
  • Donor processing (in 1.5) Frances McNamara: Fri, Apr 18
  • Cataloging reports Frances McNamara: Fri, May 2
  • OCLC monthly processing Frances McNamara: Fri, Apr 25
  • Hathi monthly processing Frances McNamara: Fri, Apr 25
  • Other MS Access reports including SCRC Frances McNamara: Fri, May 23
  • New Acq List from VuFind Maura Byrne: Fri, May 16

Deliver Data Conversions

  • KRMS rules REVIEW Cheryl Malmborg: Fri, Apr 11
  • CKO's, Requests, Blocks: Fri, Apr 11
  • Saving any old data not moved to OLE: Fri, Jun 27
  • Fines and Fees conversion Cheryl Malmborg: Fri, Apr 18

Deliver Integrations

  • ARES integrations Cheryl Malmborg: Fri, Apr 25
  • Dematic integration (requires 1.5) Cheryl Malmborg: Fri, Apr 25
  • Circ Reports: Fri, Apr 25
  • Google Book Processing: Fri, Apr 25
  • Privileges lockers, visitors, etc.: Fri, Apr 25
  • Cash Drawer workaround: Fri, Apr 25
  • Registrar Blocks with David Larsen: Fri, May 9
  • Other MS Access dbs of staff: Fri, May 30
  • Lost/Missing processing Cheryl Malmborg: Fri, Aug 29

Select & Acquire

  • Specifications for data conversions
  • Vendor data conversion jemiller@uchicago.edu: Fri, Apr 18
  • Orders/Standing orders data conversion: Fri, Apr 11
  • Test III Firm orders conversion: Fri, Apr 11
  • Old financial data: Fri, Dec 5

Select & Acquire Integrations

  • 1.5 MARC 9xx processing/Preprocessor MARC/EDI: Fri, Apr 18
  • Evouchers: Fri, Apr 25
  • Patron request workflow for acq Frances McNamara: Fri, Apr 25
  • Filters Identify and provide replacements meet with acq supervisors Frances McNamara: Fri, Apr 25
  • Order/invoice/approval import profiles for vendors: Fri, May 9
  • Acq reports: Fri, May 9
  • Other MS Access/ III reports by staff: Fri, May 30
  • Annual Stewardship report (test in 1.5) Frances McNamara: Fri, Apr 11
  • Test 1.5 Milestone 1 order and invoice loads Frances McNamara: Fri, Apr 18
  • Web form PO requests create reqs in OLE: Fri, May 9

APPENDIX D. Questions from Technical Architecture Review Committee

Last updated September 27, 2014.

1. Functional purpose

  1. What is the functional purpose to be served by this design?
  2. Is this one element of a suite that together achieves the purpose?
  3. Are there particular use cases that especially shape the design? Please describe them.
  4. What are the overall system availability and time to recover requirements?
  5. What's the expected life cycle for the system to be built?
  6. Does this replace something else?
  7. Does it overlap with something else?

2. Data management, data security, and data retention

  1. What data must be provided from systems external to this design?
  2. What data will be provided by this system to systems external to it?
  3. By what technical means will data move into and out of the system?
  4. How sensitive is any of this data? Is any subject to specific compliance requirements?
  5. How will data be protected, both at rest and in transit?
  6. Are there specific retention requirements for any of the data produced by this design?
  7. Are the stewards of this data involved in the design process?
  8. Has a data usage agreement been prepared?
  9. If the data is going to be used outside the US borders, are there any restrictions, laws, policies, or practice that should be considered?

3. Users and access management

  1. Who are the intended users of this system? Are they all UChicago people (including UC Medical Center)?
  2. Will any VIPs be among the users? Senior faculty?
  3. What credentials will be used? How will non-UChicago people access the system?
  4. What authentication technology will be used, and how will the system be protected by it?
  5. Are there different roles (sets of access privileges) that a user may have with this system? How will those be managed?
  6. Will you use shibboleth?
  7. Will you use Grouper?
  8. Are there requirements for user audit (a record of who took which management action when) or point-in-time audit (what did things look like at a given time in the past)?

4. Client environment

  1. What technologies will users use to interact with the system?
  2. What platforms (desktop, laptop, mobile) are to be supported?
  3. Must client software be distributed and maintained in this design?
  4. What requirements must the client environment meet?
  5. How will security of the client software be validated?
  6. Are there any export laws or sourcing requirements for technology that is being considered for use outside the US?

5. Hosting requirements

  1. Servers & storage
    1. What set of servers with what operating systems are needed by the design?
    2. Will all servers be virtual? (And if a vendor supplied system, does the vendor support the system in a virtualized environment?)
    3. What are the storage, backup, and restoration requirements and how will those be met?
    4. Capacity planning and modeling? What’s the test plan to validate the ability to meet the required capacity?
    5. Performance goals?
  2. Databases
    1. What database technologies and versions will be used in the design?
    2. How many databases will be used, with what operational requirements (size, auditing, redundancy, etc.) etc.)?
    3. What is the average number of concurrent users?
    4. Are there any character set requirements?
    5. Is access to the database server required?
    6. What are the availability requirements?
    7. What is the maintenance window?
    8. Are there database options required as part of the install?
    9. What are the backup retention requirements?
    10. Will the database contain sensitive data?
  3. Platforms & Middleware
    1. What middleware technologies will be used in the design, e.g., application servers, .NET, web servers, integration brokers, ESBs, web services, etc.?
    2. Will this system be hosted on an existing in-house platform such as K-split?
    3. Does the design include or depend on Application Service Providers, SaaS, IaaS, PaaS, or any other sort of services operated externally to UChicago? Please describe.
    4. If not covered above, please describe how this system will leverage any existing infrastructure services operated by IT Services. Also, please identify any infrastructure service needs of the design that are not met by current ITS operated infrastructure services.

6. Network requirements

  1. Performance and functional requirements
    1. What will be the footprint on the network, i.e., number of physical ports, interface type and speed?
    2. What are the estimated bandwidth, latency, and jitter requirements?
    3. What load balancing requirements are there?
    4. Is a proxy of any sort (OSI layer 3 and upwards) needed (e.g.? E.G.: VPN, ssh bastion, port forwarding, HTTP proxy or reverse proxy)?
    5. Is the physical architecture documented?
  2. Firewall requirements
    1. What set of ports will provide user access (use placeholder IP addresses if they are not already assigned)?
    2. What set of ports will provide administrative access?
    3. What set of ports will provide access to back-end services such as storage, database servers, system monitoring, system management, syslog server, etc.?
    4. Who, either specifically or by role, will be authoritative for identifying the users permitted through firewalls to access user-facing ports?

7. Monitoring, metrics, and logging

  1. What metrics are needed for capacity planning, diagnostic, availability, and usage tracking needs?
  2. How will the system be monitored or instrumented to produce those metrics?
  3. What Key Performance Indicators are defined for the system, i.e., targets for performance, availability, etc.?
  4. What is the expected load in terms of concurrent users, transaction volume, etc.?
  5. What are the issues that will need ongoing governance to address, and what are the KPIs and metrics needed to enable those decision processes?
  6. What monitoring is needed to ensure the security and integrity of the system?

8. Reporting

  1. Are there particular reporting requirements?
  2. Does the design include appropriate integration with ITS operated business intelligence or reporting services?
  3. Have data confidentiality, classification, and sensitivity been considered in the reporting requirements?
  4. What type of authorization will be used to insure that data confidentiality is preserved where needed?

9. Workflow

  1. What workflow requirements are implemented by the design, and how?
  2. Are there business process implications that will be impacted by the technology, and vice versa?
  3. Is a new workflow engine being added where an existing one might be utilized?

10. Other dependencies and integrations

  1. What co-requisites or dependencies are integral to the design that have not been mentioned above? E.g., email, VoIP, SharePoint, webshare, IM, etc.
  2. Do you have the necessary documents, tools, and skills to do the integrations required?
  3. Have you discussed the integration requirements with other units to insure resource availability to do the necessary integrations?

11. Application development

  1. How is the system produced and maintained? Are we adequately staffed for that?
  2. How does this application's architecture relate to that of other applications we maintain?

12. Vendor support & viability

  1. How well does the vendor support this product or service?
  2. How viable is this vendor?
  3. How does this vendor align with ITS strategic vendor management?

13. Compliance

  1. How have you addressed accessibility and Section 508 compliance?
  2. Is there any PII (Personally Identifying Information) transmitted, processed, or stored in this system? Same question for ePHI (electronic Personal Health Information).
  3. Same question for payment card data or other personal financial account information.
  4. Are children under the age of 13 going to access this system?
  5. Will students use this? Is this application going to depend upon information about students in any way?

14. Mobile Technology

  1. Will authentication and authorization be required for the application?
  2. Are there privacy terms required for the application?
  3. Is this interface already usable on a small screen device (do not consider tablet devices)? If not sure, contact User Experience Consultant, Web Services.
  4. Is there already an app developed? If so, then complete the “Mobile App Disclosure Form” at: https://nsitwebservices.wufoo.com/forms/mobile-app-disclosure-form-for-v...
  5. If the current web interface isn't optimized for the web, then determine if there is a significant set of use cases which would compel us to optimize the interface for mobile.
    1. Would someone use this site while not at their desk to get work done? If yes, go to B.
    2. Would someone return to this site on an almost daily basis? If yes, go to C.
    3. What are the 3 things people use the site most for? Can those be fit onto a small screen?
  6. Compliance with the Mobile Security Guidelines at: https://mobile.uchicago.edu/page/security-guidelines

APPENDIX E: OLE Contribution Requirements

Last updated September 27, 2014.

Tested and formalized by Atlanta Kuali Community Workshop, April 2014

Adam Constabaris, NCSU +1
Dale Arntson, Chicago +1
John Pillans, IU +1
Grover McKenzie, Penn +1
Michelle Suranofsky, Lehigh +1
Jeff Fleming, Duke +1
David Lacy, Villanova +1
Shian Chang, UM +1

The JIRAs to be used for “testing” this process will be identified and added to this section.

These are the deliverables required for a source code contribution to the OLE codebase.

Any contribution to the OLE project must go through the standard approval process through the OLE Functional Council and scheduled for a release, regardless of issue type and managed through the OLE Project Manager.

  • Enhancement Process
  • Design Review
  • Code Review
  • Documentation
  • Unit Tests
  • Bug Fix Process
  • Code Review
  • Unit Tests (as needed)
  • Documentation (as needed)
  • Documentation
  • Documentation files or patch files for DocBook
  • Conversion to DocBook format is requested
  • Considerations for Contribution Review

Functional

  • Are the functional requirements and acceptance criteria documented somewhere so we know how it’s supposed to work?
  • What are the known issues gaps, bugs, etc.?
  • Does the contributor have a Roadmap for delivered functionality?
  • Is the intention for this to be maintained as core OLE?
  • How will the contributors be involved? Consider continuing interest, maintenance, expectations and desires.

Technical

  • Is the architecture documented?
  • What technologies are being used (KIM, KNS, KRAD, other libraries, and why?)
  • What automated tests are there? Any gaps in testing? Will manual testing be required?
  • What access would we have to the original team for questions?
  • Is the contributing team available to make updates as needed from code review?
  • Can the documentation be delivered in DocBook format?

The Contribution Process

1) Contribution Proposal

  • The first step in contributing to OLE is to create an issue in JIRA per the following guidelines. If an existing JIRA exists in the OLE Project queue these can be linked. The contribution will remain in OLE Feedback Queue until the contribution is adopted for integration to OLE.
  • Enhancements should be added to OLE Feedback Queue.
  • Attach all requirements or design documents to the JIRA.
  • Bug fixes should be added to the OLE Feedback Queue.
  • If possible, add a patch file to the JIRA.
  • If a Kuali partner institution is interested in contributing a large number of bug fixes, then contact the OLE Project Manager to see if we can arrange an easier way to get your fixes directly into the codebase.
  • Code Share (these are items that someone has developed and would like to make available to the community but not in the baseline code)
    • not a free-for-all (will require some sort of stewardship)
    • may be in language not suitable for inclusion in OLE core
    • may be a “hit and run” contribution (contributor will not be around to handle questions/enhancements)
    • may have a license/license requirements incompatible with ECL 2.0
    • may be useful but have incomplete/fuzzy requirements and acceptance criteria
    • there is a space in Kuali Github for contributions like this for some projects.
    • should involve documentation of criteria for these contributions (contact info, baseline requirements, etc.) 

2) Project Review

  • Review planned 3rd party licenses to ensure compatibility with ECL 2.0
  • See Kuali Foundation 3rd Party Licenses page
  • Enhancements are reviewed by the SME group of the appropriate module:
  • SME group reviews the new contributions.
  • New contributions are escalated by the SME group to the Functional and/or Technical Council for scoping or further analysis.
  • Development Managers review for integration to source code.
  • Bug fixes are reviewed by the QA Manager/Lead SME for placement.
  • Development Managers review the bug fixes for integration to source code.
  • Once an OLE Feedback Queue JIRA has been accepted as functionally to be included in a version of OLE, it is moved to the OLE Queue (Main) for work.

3) Contribution Development & Code Review

  • Ideally, the contribution development and code review process will be an iterative process to help ensure that the contribution can easily be incorporated into the core code.
  • Determine if the code is developed on a branch of the core OLE code.
  • Contributors develop the code.
  • Once code is complete, an OLE Development Manager will coordinate a code review.
  • If the enhancement involved DB changes, changes will be reviewed for compliance in a similar nature to the Kuali Rice Database Change and Migration Policy.
  • QA Lead will conduct a code review of the tests and ensure that your code is in compliance in a similar nature to the Kuali Rice Unit Testing and Build Policy.
  • Documentation Lead will conduct a review of the documentation to ensure documentation is complete in a similar nature to the Kuali Rice Documentation Policy.
  • Creating regression/functional acceptance tests is strongly encouraged and communication with the OLE QA team should be well under way. Contributions should be regression tested using the OLE QA suite.
  • We recommend that your code change has been exercised in an OLE testing environment.
  • There will probably be some changes recommended during the reviews before the contribution can be accepted. Any objections that come up during the review process must be resolved.
  • Will need to develop a style/conventions guide similar to/derived from the OLE Kuali Coding Conventions and Java Style Guidelines
  • The Code Steward is the role in the project which has the authority to review and accept the code. If a dispute arises, the Technical Council will vote.

4) Contribution Final Acceptance

  • Code (including tests) are merged back into the core OLE code.
  • Documentation is incorporated into core documentation code.

Checking In Contributions

  • Any time you check in code to the OLE project, you must specify the *associated JIRA key (e.g. OLE-XXX)* for the corresponding work that the check-in is related to in addition to a normal svn check-in comment.

Tips on How to Develop a Contribution Properly

Other Ways to Contribute

  • Code contributions are not the only things we might seek from project members or outside organizations, documentation and testing should also be accepted.