Embed Size (px)
Citation preview
KS ENR Functional Training Module 2:: Understanding the
Enrollment Environment
2
For agenda details, presenter contact information and supporting materials, please visit Module 2 - Understanding the Enrollment Environment
Topics and Presenters
Item Presenter Project Role
Welcome and Context Carol Bershad Analysis Team, Lead Product Manager (Interim)
People and Permissions: • Concepts and Terminology• Services
Steve BarnhartRuth SchleiferCathy Dew
Analysis Team, SME Analysis Team, BAServices Team, Lead
Setup (Time): Academic Years/Terms• Wireframes• Concepts and Terminology• Services
Kristina BatisteSteve BarnhartCathy Dew
UX Team, DesignerAnalysis Team, SME Services Team, Lead
Setup (Environment): Registration Environment, Holds, Exemptions• Wireframes• Concepts and Terminology• Services
Kristina BatisteSteve BarnhartCathy Dew
UX Team, DesignerAnalysis Team, SME Services Team, Lead
KS Enrollment Application Map Kristina Batiste UX Team, Designer
Supporting Materials Carol Bershad
Facilitator Mike Huynh Analysis Team, BA
Logistics Coordinator Cheryl Medley Project Mgmt Coordinator
Critical Observer Dan Symonds Analysis Team, SME
3. Course Offering
4. Course Registration
5. Course Assessment
7. Program Enrollment
9. Academic Planning
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
KS Financials
KS ENR:: 10 Functional Areas
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 2 Objectives:: To provide a more in-depth understanding of the following functional areas of KS ENR, including key concepts and terminology and the status of all related analysis and design artifacts (i.e., requirements, service contracts an wireframes) “Setup”
Managing academic years and terms Managing the registration environment Managing the Holds Inventory Managing the Exemptions Inventory
“People and Permissions” Managing People Managing Permissions
4
Objectives and Expectations
You are HERE
We are HERE
Where we all WANT TO BE
“Teaching you to fish”
“Pulling you up”
The term MANAGE is generally used as shorthand to refer to: Your basic CRUD operations (Create, Read, Update, Delete) Plus other context-dependent functionality (e.g., Search,
Group, Relate).
But (and there is always a ‘but;’ oh, were you expecting a different image?) ….
in some instances, CREATE is called out separately from MANAGE In those instances, the scope and complexity of the initial
create process is such that it warrants separate consideration (e.g., "Create Course Offerings").
In cases where it doesn't, the term 'Manage' is assumed to include 'Create' (e.g., "Manage Academic Calendars")
5
Psst… What the heck does “manage” mean?
KS ENR Functional Area:People and Permissions
7
People can be thought of as things (“objects”), actors (“roles”), or both (the ugly intersection) Things (“Objects”): What do we need to know about them? What can be done TO them?
People as Objects drives Attributes Actors (“Roles”): What can THEY do? People as Roles Drives Permissions
People as OBJECTS Kuali Identity Management (KIM) terminology is “entities” Examples of People as Objects:
An admitted Student An Instructor teaching specific course offerings An Advisor assigned to specific programs or students
KS ENR is primarily concerned with the “Student Object” KS ENR is the system of record for the “Student as a Thing” For others, it is mainly concerned with other “People as Actors”
Interfacing with internal and external systems Instructors, Advisors accessed from institutional HR and Identity Management systems Students from internal or external Admissions systems
People as Objects may be directly assigned to organizations
People and Permissions: PEOPLE
8
Creating and Managing People as OBJECTS – Students Creation of initial student population will be via data interface from
institutions’ existing student information systems As the majority of students on an ongoing basis originate in an
admissions process, their creation will also be accomplished through a data interface to institutional admissions systems
Certain graduate professional schools may use common outside services (LSDAS, AMCAS) for admissions the interfaces for which may be opportunities institutional contributions back to KS
KS will allow the creation of individual student records by authorized users to accommodate those students who do not participate in an admissions process
People and Permissions: PEOPLE
9
Creating and Managing People as OBJECTS – Students
Data elements include: Names (legal, nick-names, maiden, married, professional, etc.) Demographic (birthdate, birthplace gender history, ethnicities, First
Nation status) Contact information (physical addresses, email addresses, telephone
numbers, social media) Citizenship information (countries of citizenship, immigration and
visa status) Residency information Identifiers (university ID number, net ID’s, SSN, Social Insurance
Number, SEVIS number, etc.)
People and Permissions: PEOPLE
10
Creating and Managing People as OBJECTS – Students
Initial development will concentrate on the administrative ability to manage information about students
Later development will provide students with self-service functions to manage their personal information Institutions will be able to identify which data elements students will
be able to maintain themselves
People and Permissions: PEOPLE
11
Creating and Managing People as OBJECTS – Instructors Interfaces from institutional HR systems to KIM will provide the
majority of the pool of Instructors Interfaces from institutional identity management systems to KIM
will provide information on Instructors who are not university employees (some adjuncts, visiting professors, etc.)
Long-term desire is to maintain qualifications of Instructors such as certifications, areas of special knowledge, preferred subject areas, in order to make assignments to course offerings
Will require additional information be maintained in KS which KIM does not accommodate
People and Permissions: PEOPLE
12
Creating and Managing People as OBJECTS – Administrators May be “central” or “departmental” Interfaces from institutional HR systems to KIM will provide the pool
of administrators Interfaces from institutional identity management systems to KIM
will provide information on Administrators who are not university employees (ROTC staff)
Will require additional information be maintained in KS which KIM does not accommodate
Next, we will consider People as Actors, i.e., Permissions
People and Permissions: PEOPLE
13
People as Actors KIM terminology is “principles” Active within KS, they can do things Associated with organizations Actors have roles
Their roles may be derived by their being objects This is the potentially “ugly intersection” ….
People and Permissions: PERMISSIONS
I’m “acting”
14
Permissions In the KS business world, “Permissions” is used interchangeably with the
term “Authorization” to refer to the ability to access to specific functionality in KS; examples include: “can Enter Grades,” “can schedule Classes”
In the KIM world, “Permissions” represent more fine grained actions that have very specific constraints. Some examples would be: "canSave", “can Edit” that are scoped by NameSpace.
Roles In the KS business world, “roles” is a collection of Authorizations In the KIM world, “roles: refers very specifically to a collection of
Permissions May be defined specifically based on organizations, or more globally Allows shorthand granting of groups of authorizations to like
individuals (Advisors, Instructors, Schedulers, etc.)
People and Permissions: PERMISSIONS
15
Person Types A fundamental relationship between an individual and the institution
Determines the minimum data required to create such a person record Constrains which authorizations may be granted Provides context for the individual’s interaction with KS Individuals may have multiple concurrent person types (graduate
students may also be instructors of record, staff employees may be pursuing degrees, etc.)
We’ve not settled on whether the concept of a “primary” person type will be necessary
People and Permissions: PERMISSIONS
16
Qualifiers An attribute of an individual which constrains one or more particular
authorizations May be derived from other data
Example: A faculty member may have the authorization to enter grades; this authorization may be constrained by the qualifier of the course offerings for which she is the instructor of record
Example: A departmental administrator may have the authorization to schedule classes; this authorization may be constrained by the qualifier of which department he is in
People and Permissions: PERMISSIONS
17
Delegating Authority The granting of one or more specific authorizations, including
qualifiers, of one user, by that user, to another user for a specific period of time Professor Smith will be a attending a seminar in Europe during the
registration period for Fall 2012; he delegates his authority to waive prerequisites for his courses to Professor Jones during that period, but delegates his authority to allow non-business majors into his classes during the same period to his departmental administrator, Carol Craig
All transactions will reflect the identity of the person actually performing the transaction, rather than the identity of the individual who delegated the authority to that person
People and Permissions: PERMISSIONS
General strategy is to leverage RICE modules as much as possible in KS Enrollment KRAD (UI platform)
Focus of RICE development for 2.0 and 2.1
KIM (Person Identity, Permissions) Strategy for gaps Strategy for authorization
KRMS (Rules) How this maps to concept of a Process Service Collaboration with Coeus Strategy for performance
KOM (Organization) Explore KS Org contract + MSU implementation
Further out KEN (Notification) KEW (Workflow)
KS Strategy for RICE Modules
The current KIM identity service also combines together distinct concepts :: The creation and management of People (e.g., students, parents, instructors,
advisors) Identity management for security purposes (user login and access rights)
In ENR, this will be greatly enhanced :: Update methods on biographic and demographic data Complex Matching Logic University ID assignment Identification and merging of duplicates Batch syncing of large numbers of people from other sources (e.g., Admissions,
HR) Person-to-Person relations Configurable control over access to sensitive data Alignment with PESC
KIM People (who need people)
Roles Department Curriculum
Coordinator
Roles assigned to Members with Qualifiers DCC is assigned to John the Dept
Admin for English and History
Role Types Check that input qualifiers
match the role's qualifiers Generate derived roles
memberships based on other data in the system
Permissions courseService.createCourse courseService.deleteCourse
Role Template Course Service Permissions
Role Permission Mapping Department Curriculum
Coordinator courseService.createCourse courseService.getCourse courseService.updateCourse
KIM Permissions
KS ENR Functional Area:Setup (Time): Academic Years, Terms and Milestones
22
Academic Years and Terms Sitemap
23
Academic Years and Terms Prototype
Administrative user will fill in details about a future term, including Registration Period, Holidays, and Start and End dates.
24
Managing Academic Years Inherits holidays and instructional days from calendar year KS allows for multiple academic years at a single institution
Regular undergraduate and graduate programs may have an academic year from late-August to mid-August
The School of Medicine’s academic year may be from July to June
Establishes basic dates into which Terms must fall Will benefit financial aid module in later development
Setup (Time): Academic Years and Terms
25
Managing Terms Terms are components of academic years Terms inherit holidays and days of instruction Term beginning and ending dates may not violate those of the
academic year to which they belong Terms may contain other terms nested underneath them (sub-terms)
The Summer Semester may be comprised of the First Summer Short Term, the Second Summer Short Term, and the Summer Long Term
Setup (Time): Academic Years and Terms
26
Managing Academic Milestones Most common milestones are term-based Such milestones include, but are not limited to:
Registration periods Class add period Class drop period
• Without academic record• With academic record
Program enrollment deadline Mid-term grading period Final grading period Withdrawal deadline Census date
Setup (Time): Academic Years and Terms
27
Managing Academic Milestones Institutions may establish milestones discretely or relatively
Discrete: Last day to add classes for Fall 2012 is September 7, 2012 Relative: Last day to add classes for Fall 2012 is 21 days after the first
day of classes
Academic milestones are not inherited from term to sub-term
Setup (Time): Academic Years and Terms
28
Setting up Environment
Global and term-specific registration rules Maximum/Minimum units/credits per term Do waitlists count toward maximum credits per term Mandatory advisement requirements Time conflict parameters
Overlaps of more than x minutes constitute a time conflict
Course registration fill percentages or minimum registration counts Minimum number of students which must register for a course offering
for it to “go” Minimum percentage of seats which must be filled for a course offering
for it to “go”
Setup (Time): Academic Years and Terms
From ATP to Academic Calendar
While this service is very powerful and very flexible, it is also somewhat confusing and cumbersome from an
application development perspective.
Terms are managed independently of Academic Calendars
Nesting of Terms is performed through their own service operations, a Term can be "included" inside another Term to represent nesting
A Campus Calendar has separate service operations to allow for the reuse across multiple Academic Calendars
Holidays and Key Dates do not have states Milestones (Registration Dates, Key Dates and Holidays)
derive state from the associated Campus Calendar or Term
Academic Calendar and Terms have two states :: draft and official
Registration Date Group provides easy access to a set of well-known Key Dates associated with a Term
The Academic Calendar ServiceProbably more than you wanted to know…
KS ENR Functional Area:Setup (Environment): Registration Environment, Holds
and Exemptions
32
Registration Priority Establishing registration periods
When are registration “tools” available to student?• “Tools” include visionary schedule builder
Defined by beginning and ending days
May assign specific periods to specific populations
Multiple periods need to be supported
Establishing registration windows Defined by a specific beginning time and ending time on a specific
date
May be done for resource or pedagogical reasons
Enables the assignment of specific students to specific “appointment” times based on rules
33
Setup (Environment): Registration Environment, Holds and Exemptions
Schedule validity criteria Performed after all changes to student’s schedule have been
processed
Examples include: Maximum credit hours (do waitlist credits count toward limit)
Course schedule time conflicts/overlaps
Student athlete requirements
International student requirements
Financial aid eligibility
Full-time/part-time status
Travel time between classes
34
Setup (Environment): Registration Environment, Holds and Exemptions
Understanding Blocks The system “blocks” an action based on a real-time evaluation
of a student’s record based on rules associated with the transaction
Examples include: The system will block a student from registering for a juniors-only
course if the student is a sophomore
The system will block a student from registering for Calculus II if the student has not successfully completed Calculus I
The block will no longer occur if the student’s record is updated in such a way that the conditions of the block are met, or if the student receives an exemption
35
Setup (Environment): Registration Environment, Holds and Exemptions
36
Hold Setup Sitemap
37
Hold Setup Prototype
Administrative user will set up the structure of the hold.
Applying it to students is a separate feature.
38
Managing Hold Inventory A hold is 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.) A Bursar hold may prevent registration, the production of an official
transcript, and the issuance of a diploma, but not the production of an unofficial transcript
An academic integrity hold may prevent the student from dropping classes, but not the production of any form of transcript
Setup (Environment): Registration Environment, Holds and Exemptions
39
Managing Hold Inventory A central administrator would be responsible for maintaining the
inventory/catalog of holds, who can administer them (placing and removing), what activities/functions are impacted by the hold, specific information about the hold, what office to contact about the hold, etc.
Administration of the placement and removal of holds would be role and qualifier based.
Setup (Environment): Registration Environment, Holds and Exemptions
40
Managing Exemption Inventory Persisting, time-based grant of an exception to a given policy which
usually invalidates some form of block May be initiated by students, instructors, or advisors Examples include:
Requisite waivers• Pre-, Co-, and Anti-
Program-based restrictions• Credential (Baccalaureate, Masters, PhD, MBA, DDS, etc.)• School, major, minor
Year/Class level restrictions• Juniors, Year 3 students only
Degree audit requirements• Course substitutions• Waiver of requirement
Understanding the Enrollment Environment Holds and Exemptions
41
Managing Exemption Inventory
For each type of exemption, define the following Who can initiate Time period of exemption Required data for complete exemption request Potential outcomes Qualified workflow
May have specific routing based on organization; the School of Engineering may have a three-step process including the instructor, the department chair, and the student affairs dean, while the School of Fine Arts may only require the approval of the instructor
Setup (Environment): Registration Environment, Holds and Exemptions
Hold The Hold Service answers the question, "Is this person on hold?"
The Hold Service manages various Holds on a Person Financial hold for student registration
Medical hold for student registration
Holds may be "hard" or "soft"
Exemption The Exemption Service defines exceptions to rules and restrictions
used throughout Kuali Student
Exemptions are always granted to People
The exemption process begins with an Exemption Request Student couldn’t do something, such as register for a course
Exemptions are valid based on effective dates or number of time(s) they can be used
Registration Setup Services
Hold Service (WIP)
Exemption Service (WIP)
Population Sandbox
Process Service Surface control points to an admin per process
Interconnecting semantics around what is being checked directly with the concept such as Holds
Set of ordered instructions, applied to a population, and the specification of what to do if the check fails
Check also gives us a place to align/apply an Exemption, if the check can be exempted
NEXT STEPS :: Figure out boundaries with Rules (KRMS)
Processes Sandbox
47
Module 2:: Follow-up Date: November 2, 2011
Time: 12pm – 2pm ET | 9am – 11am PT
Post questions/issues: KS ENR Training, Module 2:: Questions/Issues
Module 2:: Evaluation Please complete short survey::KS ENR Training, Module 2 Evaluation
Module 3:: Understanding Course and Course Offerings Date: November 30, 2011
Time: 12pm – 4pm ET | 9am – 1pm PT
Functional Areas
3. Course Offering
4. Course Registration
5. Course Assessment
Next Steps
