Presentation is loading. Please wait.

Presentation is loading. Please wait.

KS ENR Functional Training Module 2:: Understanding the Enrollment Environment.

Similar presentations

Presentation on theme: "KS ENR Functional Training Module 2:: Understanding the Enrollment Environment."— Presentation transcript:

1 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 EnvironmentModule 2 - Understanding the Enrollment Environment 2 Topics and Presenters ItemPresenterProject Role Welcome and ContextCarol BershadAnalysis Team, Lead Product Manager (Interim) People and Permissions: Concepts and Terminology Services Steve Barnhart Ruth Schleifer Cathy Dew Analysis Team, SME Analysis Team, BA Services Team, Lead Setup (Time): Academic Years/Terms Wireframes Concepts and Terminology Services Kristina Batiste Steve Barnhart Cathy Dew UX Team, Designer Analysis Team, SME Services Team, Lead Setup (Environment): Registration Environment, Holds, Exemptions Wireframes Concepts and Terminology Services Kristina Batiste Steve Barnhart Cathy Dew UX Team, Designer Analysis Team, SME Services Team, Lead KS Enrollment Application MapKristina BatisteUX Team, Designer Supporting MaterialsCarol Bershad FacilitatorMike HuynhAnalysis Team, BA Logistics CoordinatorCheryl MedleyProject Mgmt Coordinator Critical ObserverDan SymondsAnalysis Team, SME

3 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 KS Financials KS ENR:: 10 Functional Areas

4  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”

5  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?

6 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 7 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 8 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.) 9 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 10 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 11 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 12 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” …. 13 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.) 14 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 15 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 16 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 17 People and Permissions: PERMISSIONS

18  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

19  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)

20  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

21 KS ENR Functional Area: Setup (Time): Academic Years, Terms and Milestones

22 22 Academic Years and Terms Sitemap

23 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 24 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 25 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 26 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 27 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” 28 Setup (Time): Academic Years and Terms

29 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.

30 From ATP to Academic Calendar (cont.)

31  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 Service Probably more than you wanted to know…

32 KS ENR Functional Area: Setup (Environment): Registration Environment, Holds and Exemptions 32

33  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

34  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

35  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 36 Hold Setup Sitemap

37 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 38 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. 39 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 40 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 41 Setup (Environment): Registration Environment, Holds and Exemptions

42  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

43 Hold Service (WIP)

44 Exemption Service (WIP)

45 Population Sandbox

46  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/IssuesKS ENR Training, Module 2:: Questions/Issues  Module 2:: Evaluation  Please complete short survey::KS ENR Training, Module 2 EvaluationKS 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 47 Next Steps

Download ppt "KS ENR Functional Training Module 2:: Understanding the Enrollment Environment."

Similar presentations

Ads by Google