KS ENR Functional Training Module 1:: Understanding KS Enrollment

Getting Started Presenter: Carol Bershad

... to the first of six (6) functional training modules on KS Enrollment For the most current information and details, please visit KS ENR Functional TrainingKS ENR Functional Training 3 Welcome . #ModuleOrientationFollow-up 1Understanding KS Enrollment10/19/1110/27/11 2Understanding the Enrollment Environment11/2/1111/10/11 3Understanding Course and Course Offerings11/30/1112/8/11 4Understanding Programs and Program Offerings12/14/11 Modules 1 4 Recap1/11/12 5Understanding Cross-Cutting Concepts1/25/122/2/12 6Understanding Academic Planning2/8/122/16/12

Overall Training Objective:: To equip participants with a solid understanding of the functional framework of the KS Enrollment Module and the associated business artifacts as they currently exist. Module 1 Objectives:: To provide a high-level overview of KS concepts and materials to facilitate self-study the KS Project and the associated modules the functional framework and scope of KS Enrollment key concepts associated with KS Enrollment service-oriented architecture and KS Services the structure and location of KS Enrollment business artifacts 4 Objectives and Expectations You are HERE We are HERE Where we all WANT TO BE Teaching you to fish Pulling you up

For agenda details, presenter contact information and supporting materials, please visit Understanding KS Enrollment Understanding KS Enrollment 5 Agenda and Presenters ItemDurationPresenterProject Role Getting Started30 minCarol BershadAnalysis Team, Lead Product Manager (Interim) KS Project Overview30 minDan McDevittProgram Director KS Enrollment Overview: Framework30 minCarol Bershad KS Curriculum Management Overview30 minDan SymondsAnalysis Team, SME BREAK15 min KS Enrollment (ENR) Overview: Content60 minSteve BarnhartAnalysis Team, SME KS Services Overview25 minCathy DewServices Team, Lead KS Enrollment Application Map Overview25 minKristina BatisteUX Team, Designer Wrapping UpCarol Bershad FacilitatorMike HuynhAnalysis Team, BA Logistics CoordinatorCheryl MedleyProject Management Coordinator Critical ObserverRuth SchleiferAnalysis Team, BA

Given size of attendance and amount of material to cover, there will be no interactive Q/A around content Instead, please: Limit questions/comments to logistics Post questions/comments regarding content here; these will form the basis for the Follow-up Session:: KS ENR Training, Module 1:: Questions/Issues KS ENR Training, Module 1:: Questions/Issues Remain on mute unless asking a question/making a comment Remain connected during the break Have patience with any technical issues we might experience! Take a deep breath . 6 Logistics and Ground Rules

KS Project Overview Presenter: Dan McDevitt

What is Kuali? Community-driven Software development projects Coordinated by the Kuali Foundation Resulting in freely- available, open source software products for higher education What is Kuali not? Kuali is not a vendor Implications Community directed and governed Greater control Support decoupled from code Few dollars spent on sales and marketing Requires involvement What is Kuali?

Open Source Software for Higher Education, by Higher Education Financial System (KFS) Research Administration- COEUS (KC) Student (KS) Open Library Environment (OLE) Business Continuity Planning (Kuali Ready) People Management for Enterprise (KPME) Mobility Rice (infrastructure/development tools) 9 What is Kuali?

A Next Generation Student System which is: Meeting requirements of the community Not just the requirements of one institution Being incrementally produced through a dedicated community of international higher education partners Delivering a rich user experience using a service-oriented architecture 10 What is Kuali Student?

Who is involved? The Kuali Student Community Founders = $~1 M/per year for 5 years Founders Naval Post Graduate School University of California, Berkeley University of Maryland, College Park University of Southern California University of Toronto University of Washington Partners Boston College Indiana University North-West University, South Africa University of Cambridge, United Kingdom

12 How are we organized? Current Structure High Level Program Director Dan McDevitt Kuali Student Board QA Manager Vacant Product Manager Carol Bershad Development Manager Rajiv Kaushik Services Team Cathy Dew - Lead Development Team Technical Architect Larry Symms Subject Matter Experts Business Analysts Test Engineers Configuration Management Team User Experience Team William Washington - Lead Functional Council Project Advisory Group

Set the vision & strategic direction for the project Hold regular (monthly) review meetings to monitor the progress of the project Champion the solution to be delivered by the project and support the project objectives within their university and across the community 13 Kuali Student Board

Ensure that Kuali Student meets the needs of the institution from a functional/ business requirements perspective Act as a communicator/ motivator/ marketer, communicating and promoting project objectives throughout their founding institution Provides direction for scope, plans and key deliverables that impact overall project direction 14 Kuali Student Functional Council

Kuali Student High-Level Timeline

Enrollment Development Strategy Phase 1: Core Slice Lay service foundation: define and exercise most alpha services Provides technical/service platform that parallel teams can build upon Provides an assemblence of a demonstrable product across core Enrollment functions Enables platform for transitioning to contribution/development model

Kuali Student Enrollment Development Strategy Course/ Program Offering People - Permissions Program Enrollment Course Assessment Course Registration Program Assessment Academic Record Degree Audit Breadth Depth PHASE 1 Foundation (core slice) For illustration only

Enrollment Development Strategy Phase 2: Transition to Parallel Teams Provides opportunity for optimizing resources through proximity, e.g., face to face, time zone, etc. Shift some leadership and accountability to institutions responsible for delivery Provides potential opportunity/avenue to attract additional Institutional investment/contributions

Kuali Student Enrollment Development Strategy Course/ Program Offering People - Permissions Program Enrollment Course Assessment Course Registration Program Assessment Academic Record Degree Audit Breadth Depth PHASE 1 Foundation (core slice) Team A Team B Team C Team D For illustration only

Organization Structure for Kuali Student Enrollment Parallel Development Kuali Student Senior Developers User Experience Architects Services Architects Scope Coordination Business Reqs Cross Inst Requirements Service Governance Adherence to Infrastructure Adherence to UX Model Code Reviews Adherence to Standards Meets Business Reqs Meets Technical Reqs Product Management KS Core Team QA Multiple Parallel Teams Multiple Parallel Teams Development Team User Experience Designer Team Lead Functional Expert(s) Multiple Parallel Teams Multiple Parallel Teams Multiple Parallel Teams Multiple Parallel Teams

21 High-level Timeline

KS Enrollment Overview: Process, Framework and Scope Presenter: Carol Bershad

The Big Bang In the beginning, there were five KS Releases R1: Curriculum Management R2: Enrollment and Program Audit R3: Admissions R4: Student Financials R5: Scheduling And then we actually started releasing . Release 1 of Release 1? Releases have been renamed to Modules, each of which will have multiple releases Delivered: Curriculum Management 1.1, 1.2 Planned: Enrollment Management 1.0, 2.0 however, on the wiki you may still see some dated references to R1 and R2, particularly R2 methodology 23 A Brief History of KS Requirements

The Uncertainty Principle R1 requirements were a bit of a Black Hole Collective Use Cases with no institutional traceability The Expanding Universe R2 Methodology had each institution providing their individual requirements for 30 different functional topics, aka melanges The group responsible for this work was the KS Business Requirements Team The Unification The KS Analysis Team (SMEs, BAs) was formed to create KS requirements from the institutional material 24 A Brief History of KS Requirements

25 A Brief History of KS Requirements Synthesis Cross-functional Analysis and Design Institutional Requirements 8 institutions x 30 melanges compilation of material across institutions and melanges into a single, consolidated inventory focused, in-depth interpretation of the materials and the desired functionality they represent Requirements Parallel Delivery 10 Functional Areas Analysis Team UXServices + + KS System RequirementsKS System Requirements include: Terminology Requirement Statements User Stories BPMs Rules Examples Data See for Appendix for TraceabilityAppendix

Offer Courses Register for Courses Grade Courses Enroll in Programs Assess Progress in Programs Explore Programs Plan Programs Offer Programs Setup the Environment Set up Users Student FacingInstitution Facing Manage Info and Preferences Holds Exemptions Academic Record Catalog KS ENR Functional Framework

3. Course Offering 4. Course Registration 5. Course Assessment 7. Program Enrollment 9. Academic Planning 6. Program Offering 1. Setup 2. People and Permissions Student FacingInstitution Facing 2. People and Permissions X-cutting 10. Academic Record Curriculum Management 8. Program Assessment UW My Plan KS Financials KS ENR:: 10 Functional Areas

28 KS Enrollment Scope 2. People and Permissions 1. Set Up 3. Course Offering 4. Course Registration 5. Course Assessment 6. Program Offering 7. Program Enrollment 8. Program Assessment 9. Academic Planning 10. Academic Record Institution FacingStudent Facing ENR 1.0 ENR 2.0 and beyond KS ENR Scope (WIP) E1 Deliver the Basics E2 and Beyond Deliver the Vision

Come meet Curriculum Management Presenter: Dan Symonds

3. Course Offering 4. Course Registration 5. Course Assessment 7. Program Enrollment 9. Academic Planning 6. Program Offering 1. Setup 2. People and Permissions Student FacingInstitution Facing 2. People and Permissions 10. Academic Record Curriculum Management 8. Program Assessment

Provide a conceptual understanding of the Curriculum Management module Focus on Course and Program Focus on CM concepts important to understanding Enrollment Functionality 31 Objectives

Concept representing any component of learning completed as part of the student learning experience Represent the core products of the institution Can be highly regimented and coordinated or flexible and loosely coupled activities Flexible enough to support a wide diversity of learning experiences 32 What is a Learning Unit

Courses Programs Projects Thesis Research, Dissertation Research, Independent Projects, Performance Projects Experiential Learning Internships, Externships, Cooperative Work Study, Practica, Life Experience Examinations and Competencies Comprehensive or Qualifying Exams, Competency Exams, Music Juries, Doctoral Dissertation Defense 33 Types of Learning Units

Controls the creation and management of an institutions inventory of learning experiences (LUs) Viewing, creating, modifying, retiring curricula Development and approval of curricula through collaboration and workflow Enables curriculum managers to understand the relationships/dependencies between curricula 34 Curriculum Management

Canonical LU Catalog Course 2012-2013 Undergraduate Catalog ENGL206: Shakespeare Shakespeare's poems, history plays, comedies, and tragedies as investigations into language use, governance, sexuality, ethics, and mortality Learning Unit Instance (LUI) Course Offering Spring 2012 Schedule of Classes ENGL206: Shakespeare 0101 G. Passannante Lec TuTh 11:00am-11:50am (JMZ 0220) Dis F 10:00am-10:50am (TWS 0234) 0102 G. Passanante Lec MW 10:00am-10:50am (JMZ 0220) Dis F 1:00pm-1:50pm (TWS 0234) 35 Key Concepts: Canonical vs. Instance LUs

Credit Courses Non-Credit Courses Special Topics Courses Various Topics Courses Modular Courses Sequence Courses 36 Types of Courses

Cross Listing Same course published and offered using multiple course reference numbers from different departments SOCY325/WMST325 Sociology of Gender Joint Offering Two or more courses that may meet with one another with the same meeting location, day/time, and instructor when deployed Learning objectives for each course may differ Generally occurs when the courses cover a common subject area RUSS409V Russian Language Study: Verbal Aspects RUSS618V Linguistic Analysis of Russian: Verbal Aspects 37 Course Concepts

Activities Courses offerings consist of one or many activities Lecture, Lab, Discussion/Recitation, Seminar, etc Formats Allowable combinations of activities Can support one or multiple combinations for a single course Highly Configurable Constraints between activities and formats vary amongst institutions 38 Course Activities and Formats

One or more courses (or course sets) used in the creation of a rule statement Used in the context of LU rules Course Rules examples Prerequisites, Corequisites, Student Eligibilities Program Rules Completion, Satisfactory/Benchmark, Entrance Dynamic Course Sets Named Course Sets A set of courses which is reused across multiple rule statements Able to be managed outside of the individual rule statement for which it is used 39 Course Sets

A prescribed group of learning units that lead to a recognized body of knowledge Can consist of courses, activities, competencies, learning objectives, requirements, other programs End result may be an acknowledged level of accomplishment or a credential 40 What is a program? Oh yes, the lower case p in program is quite intentional

Baccalaureate, Masters, Doctoral, Professional (J.D., M.D, etc) General Education/Core Major Discipline (Academic Programs) Specializations/Concentrations Minors Variety of Certificates Discipline-related honors programs Living/Learning Programs Module Courses/Course Clusters (crossover) 41 Types of programs Is that lower case p still bothering you? Better not be

42 Program Logical Model

Functionality well exposed in certain types of programs Entrepreneurial programs (Executive MBA Programs) Progress in program a factor of the program, not the student Not exposed as well in traditional programs Traditional undergraduate programs (Sociology) Progress in program a factor of the student, not the program More conceptual analysis 43 Challenge: Canonical Program vs. Program Offering

KS Enrollment Overview Presenter: Steve Barnhart

Objectives 1. To provide a high-level understanding of the functional areas of the Kuali Student Enrollment module 2. To provide an understanding of how KS Enrollment builds off of KS Curriculum Management 3. To lay the ground work for more detailed discussions in future KS training modules, deep dives 45 KS Enrollment Overview - Introduction

Academic Years and Terms Establish calendars Holidays Instructional days Establish academic year(s) Establish terms and sub-terms Define milestones Registration periods Add periods Drop periods Grade submission periods Final examination schedule Census date 47 1. Set Up (Time)

Course Registration Environment Global registration rules Maximum/Minimum units/credits per term Mandatory advisement requirements Establish registration appointment times for term Assign registration appointment times to populations of students Hold and Exemption Types 48 1. Setup (Environment)

People as actors Associate people with organizations Defining role-based authorizations Delegate authorizations Interface with HR systems Interface with other external systems Third party access and permissions People as objects Interfaces with internal and external systems PESC alignment 49 2. People and Permissions

3. Course Offering 4. Course Registration 5. Course Assessment 7. Program Enrollment 9. Academic Planning 6. Program Offering 1. Setup 2. People and Permissions Student FacingInstitution Facing 2. People and Permissions X-cutting 10. Academic Record Curriculum Management 8. Program Assessment UW My Plan KS Financials

Canonical Course Approved at the curriculum level One or more formats, each with one or more activities (lecture, lab, etc.) Course Offering Specific instance of a canonical course within a valid term Scheduled at the activity level (lecture, lab, discussion, etc.) Creation can occur through rollover or one-off Instructor assignment 51 3. Course Offering

Course Offerings (cont.) Room and time assignments via interface with institutional scheduling systems (R25, Ad Astra, etc.) Additional registration eligibility restrictions, beyond canonical definitions Seat pool definitions to further restrict registration by population Waitlist definitions Course or section-level Refine course or activity specific fees 52 3. Course Offerings

Registration eligibility validation Term specific requirements Annual and term-based acknowledgements Appointment times Holds Schedule builder Integration with learning plan Integration with degree audit Registration cart Groups of drop and add transactions 53 4. Course Registration

Course-specific registration eligibility validation Class/Year levels Majors Minors Requisites (pre-, co- and anti-) Waitlists Student schedule validation for special populations Student athletes International students Veterans Tuition and fee calculation* *Sigma Student Financials Project 54 4. Course Registration (cont.)

Midterm and final grade submission Change of grade processing GPA calculation rules Term GPA Cumulative GPA Program GPA Grade distribution reporting (mean, median, mode) 55 5. Course Assessment

Canonical Programs Approved at curriculum level Never directly associated to students For all types of programs (credential, major, minor) Program Offering Specific instance of a canonical program for a term period Multiple program offerings for each canonical program Most undergraduate programs will be on-going Lock-step programs may have a program offering for each cohort 57 6. Program Offerings

Open/unrestricted programs No admissions criteria No capacity limitations 1 st -come, 1 st -served programs No admissions criteria Capacity limitations Restrictive programs Admissions Criteria No capacity limitations Selective/competitive programs Admissions Criteria Capacity limitations 58 7. Program Enrollment

Application process Review eligibility Complete application Attach any required documents Route through any approval process Notify applicant Termination Program withdrawal Stop-outs Disqualifications 59 7. Program Enrollment (cont.)

Assessment of Satisfactory Progress Requirements Learning results calculated/consumed Term GPAs Cumulative GPAs Units/Credits completed Terms/Years completed Milestone achievement Potential actions Probation Dismissal Applied at various levels Institutional College Program 60 8. Program Assessment

Assessment of Completion Requirements Short Term :: integrate with 3 rd party Long Term :: build KS module Assessment of Graduation Clearance Requirements Identifying candidates Accepting applications Clearing required steps Posting degree Notifying candidates 61 8. Program Assessment (cont.)

3. Course Offering 4. Course Registration 5. Course Assessment 7. Program Enrollment 9. Academic Planning 6. Program Offering 1. Setup 2. People and Permissions Student FacingInstitution Facing 2. People and Permissions 10. Academic Record Curriculum Management 8. Program Assessment UW My Plan

Learning Plans Development of sample learning plans for specific programs Coordination of LP between student and academic advisor Integration of LP with :: Term schedule of classes Registration Schedule Builder Academic record (grades) Degree audit system (program requirements) 63 9. Academic Planning

UW MyPlan Funded by student technology fee to improve student academic planning and advisement Learning Plan Lite Allows students to identify and select courses to meet their program goals Learning Plans will integrate with UWs existing systems Schedule of classes Degree audit system Based on KS technology stack (as possible) To be contributed back to KS 64 9. Academic Planning

3. Course Offering 4. Course Registration 5. Course Assessment 7. Program Enrollment 9. Academic Planning 6. Program Offering 1. Setup 2. People and Permissions Student FacingInstitution Facing 2. People and Permissions X-cutting: Holds X-cutting: Exemptions 10. Academic Record Curriculum Management 8. Program Assessment UW My Plan

A virtual collection of things related to a students learning experience at an institution At a minimum, it is the data needed to produce a transcript Data includes Program information Graded courses by term Grades received Unit/credit totals GPA calculations PESC aligned 66 10. Academic Record

Data (continued) Degrees awarded Transfer course work and evaluation Term and graduation honors 67 10. Academic Record (cont.)

Holds Associated to a student For a given time period May be a date range, or term specific Usually originates from another system Housing, health services, parking, etc. May prevent a variety of activities Registration, dropping classes, adding classes, obtaining a transcript, etc. Must be removed or overridden 68 Cross-cutting Concepts

Blocks Real-time evaluations of student attributes which determine limitations on actions Requisite checking, course registration restrictions, etc. Change if the students attributes change May be exempted 69 Cross-cutting Concepts (cont.)

Exemptions Persisting, time-based grant of an exemption to a given policy which usually invalidates some form of block May be initiated by students, instructors or advisors Request process with workflow dependent on specific type of exemption requested Examples Prerequisite Program level restrictions Year/Class level restrictions Degree audit requirements 70 Cross-cutting Concepts (cont.)

KS Services Overview Presenter: Cathy Dew

What is SOA? Set of principles and methodologies for designing and developing software in the form of interoperable services Well-defined business functionalities that are built as software components (discrete pieces of code and/or data structures) that can be reused for different purposes Why SOA? Development advantages :: software reuse, productivity increases, increased agility Strategy advantages :: better alignment with the business Service Oriented Architecture

Contract Definition Operations (functions) Message Structures (data objects and parameters) Contract Implementation Code to implement the contract that can then be used by the Application Layer to deliver features Advantages Provide a stable but abstract layer between the Application (screen flow and UI) and Data Persistence (underlying database) Contracts should change much less than the impl or the UI Allow the implementations and UI to evolve independently What are Service Contracts?

R1.1 had concept of "Entity" services and "Business" services With ENR, we have implemented a classification system Supports striated governance to support various development and delivery efforts Class I Single focus, self-contained = atomic May or may not be "business-speak, e.g., LU, LO, LRC, Comment and Document Tightly governed by Service Team Class II Composed services, refer to more than one Class I service Business speak, understood (and validated) by BAs and SMEs, e.g., Course, Program, Course Offering and Course Registration Expect changes by Parallel Teams, with rigorous review Service Classification

Class III KS Contributions Not part of KS proper but may become so Current projects include UW MyPlan and Sigmas Student Financials Class IV RICE services, not part of KS but part of Kuali, e.g., KEW interfaces, KIM interfaces, KRMS, KRAD Governance controlled by Kuali Working Groups Expect to augment RICE development with KS resources Service Classification (cont.)

Services Design Process INPUTPROCESSOUTPUT Candidate Services (See Service Index)Service Index Review high-level business artifacts Group into areas for use cases BUSINESS ANALYSIS High-level Features Business Requirements Terminology User Stories BPM Rule Candidates Data WIKI Artifacts (See Service Description Repository)Service Description Repository For each Service (Class I and II) Diagram logical entities Explore service layering Define functions & data bits Develop Formal Contracts Code Artifacts (See KS 1.3 Branch)KS 1.3 Branch Refine Formal Contracts ALL Artifacts (release process) DEVELOPMENT Application Analysis & Design Core Slice Released Service Contracts

Wiki Artifacts Narrative description and assumptions highlighting key concepts Entity diagram and service layering (Class I to Class II) Type / State configuration Code Artifacts Interface(s) for service contract and message structures DTO beans for message structures implementing their interfaces Generated WSDL, JAXWS package (if required) Constants file for our types and states Dictionary XML (stub to start with) Mock impl(s) Service Contract Artifacts

From Curriculum Management Example :: Class II and Class I

As we move into Enrollment Example :: Class II and Class I Academic Calendar (ACAL) Academic Time Period (ATP)

You are here: KS Enrollment Application Map Overview Presenter: Kristina Batiste

What is the application map? Why do we need one? How can we use it? Where can we find it? 81 Answers to all your questions.

Story Arc Swimlanes beginning-to-end stories that combine high level features/functional areas into UX-friendly groupings Skeleton Sitemap interactive, early stage sitemap for ENR. See what you can do, where you can do it Functionality Table Collected functionality (found on map) made scan-able 82 What is it?

Orientation when approaching design: Guide thinking about where features live Help build screenflows Suggest ways of accessing functionality in more than one location By keeping the big picture in mind, we can avoid: designing bits and pieces of KS in isolation proliferation of hub screens that could be effectively combined or eliminated building the online equivalent of the Winchester Mystery HouseWinchester Mystery House 83 How to use it:

It was developed both as a means of thinking about and processing the ENR space, and of helping UX quickly pick up and understand ENR functionality and features. Gives an overview of how features interact/intersect Illustrates who does what, how often Shows where users go to start tasks. (Note that this is a 'skeleton map' and will be fleshed out and likely change during parallel development. What, you didnt think it was done, did you?) 84 Why do we need it? Because UX designers pictures.

Here. 85 Where to find it:

Wrapping Up Presenter: Carol Bershad

Module 1:: Follow-up Date:October 27, 2011 Time: 12pm 2pm ET | 9am 11am PT Post questions/issues: KS ENR Training, Module 1:: Questions/Issues KS ENR Training, Module 1:: Questions/Issues Module 1:: Evaluation Please complete short survey:: KS ENR Training - Module 1 EvaluationKS ENR Training - Module 1 Evaluation Module 2:: Understanding the Enrollment Environment Date: October 27, 2011 Time: 12pm 4pm ET | 9am 1pm PT Functional Areas 1. Set Up 2. People and Permissions 87 Next Steps

Appendix: Traceability

89 Requirement Statement Traceability Example: KS System Requirements - Course OfferingKS System Requirements - Course Offering

90 Requirement Statement Traceability

Documents

KS ENR Functional Training Module 1:: Understanding KS Enrollment