1. Kuali Student Overview February 2011

2.  What is Kuali Student?  Product Vision  Who is Kuali Student?  When is Kuali Student being delivered?  How is Kuali Student being delivered?  Addendum: History of KS Business Requirements Topics

3. What is Kuali Student? Dan McDevitt | Indiana University

4. 4 Kuali  Kuali: noun (derived from Malay term); kitchen wok- humble utensil which plays the most important role in a successful kitchen; used for frying, steaming, braising, blanching and many more Oriental and Asian cooking techniques and styles. Representing versatility and flexibility of restaurant menu to suit all tastes.

5. What is Kuali Student? Kuali Student is a NEXT GENERATION STUDENT SYSTEM which is …….... HAPPENING! …….being incrementally produced through a dedicated community of international higher education partners …..meeting requirements of the community (not just the requirements of a single institution) ……flexible to changing business processes …… delivering a rich user experience …… modular and scalable

6. What is Kuali Student?

7. More information about KS Modules http://kuali.org/ks/modules What is Kuali Student

8. Product Vision Dan McDevitt | Indiana University

9. 9 The Student Service System vision 1. Student centric: anticipate needs, present choices, reduce task time, and help students achieve goals 2. Support a wide range of learners, learning activities, and institutions 3. Support a wide range of business processes 4. Provide high quality, scalable support, for users and processes 5. Complement and enhance human interactions a compelling new vision - not an existing system redeveloped using new technology

10. 10 Results from Mellon feasibility study  Add functionality to existing systems  functionality was lost when ERPs were installed  opportunities to re-use some existing functionality  Replace old technology  don’t want to install a monolithic ERP system  Get off the ERP upgrade path  improvements don’t always reflect cost and effort  Future path for home-built systems  hard for a single institution to sustain a complete system deliver a next generation “service” system

11. Why Now?  Many student systems don’t meet current needs  Vendor solutions may not be the answer  Development of in-house systems is challenging  Increasingly complex technology requires specialist resources  Competing for scarce IT resources in a constrained market  User requirements and expectations increasing rapidly  Budgets and funding are constrained  Collaboration and open source systems development works  We can build systems that do more for users

12.  New high level entities  Use of workflow and rules engines  Easy to configure to support new rules and processes  Modular, loosely coupled, standards based architecture  Simple, appropriate access to data and information  Support for internationalization 12 Elements of a highly effective system

13. 13 Entity models that allow flexibility  persons  time  learning units  course; single lecture in a course; 15 minute student presentation in a course  participation in community service  any activity that the student wants to include on a formal or co-curricular transcript  a “learning unit number” is like a SKU...  learning results, learning plans, learning resources don’t restrict what people and institutions can do

14. 14 Work flow and rules engines  processes are represented using workflow, not coded into the system  rules are represented in rules engines, making them easier to review and change  ownership of processes and rules moves closer to the positions and units responsible  workflow and rules engine technology is reusable and scalable process change is easier

15. 15 Support for Local Business Processes  Business processes evolve to meet unique institutional requirements, reflecting the role, student body, and academic mission  Different types of institution and different units in institutions need to do things very differently  Existing practices are often “best practices” for the institution using them  Existing systems often incorporate someone else’s “best practices” system fits many different units and institutions

16. 16 Easy to Change Business Processes  Rules engines for internal process logic  Workflow for end-to-end business processes  processes can cross systems  Encourage and support innovation and change  It’s OK to customize..... your practices, not someone else’s “best practices”

17. 17 Modular, Standards Based  Different institutions can build applications that will work together  Applications can use different technologies  Applications can be integrated with existing systems  Open source and commercial applications can be combined  A critical mass of applications will deliver a next generation system deploy what you need, when you need it

18. 18 Appropriate Access to Information  Student and other administrative systems contain a wealth of useful information  This information is often hard to access, and is often not used when it should be  All users and systems should have appropriate access to the information they need  Service oriented design, delegation of authority, and rules for access to information, will allow us to give appropriate access to all users and systems we can make better use of what we know

19. 19 Internationalization  Current systems often make it difficult to support other languages, currencies, etc.  Kuali Student architecture will allow it to be used in other countries, using other languages and currencies  The use of high level entities, workflow, and rules Engines will make it possible to use Kuali Student to support other educational systems

20. Who is Kuali Student? Dan McDevitt | Indiana University

21. 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 Kuali Student Community Founders = $~1 M/per year for 5 years….

22.  Align with the vision of Kuali Student  Contribute at least $1,000,000 per year, in cash and/or staff resources, for the 5 year period of July 2007 – June 2012.  Adhere to the governance structure, decision-making processes, and project management disciplines, including the service oriented analysis methodology as laid out in the Program Charter.  Commit to run most or all modules of the core product in production.  Designate senior representatives for the Program Board that will direct program resources.  Use the Educational Community License for all work products created by the core members.  Be an active advocate for the Program, including executive level communications to the community.  Develop appropriate local expertise in Service Oriented Architecture. Founder Commitment

23.  Align with the vision of Kuali Student  Allocate resources, in the form of cash and/or staff, toward the development of Kuali Student. The development resources may be allocated to core system scope undertaken by the Founders or may be allocated to modules complementary to the core system scope.  May commit to implementing one or more Kuali Student modules (core or non-core) in production.  Participate on either the Technical or Functional Steering Committees – attending scheduled meetings.  Participate in workshops to ensure the Kuali Student System meets the needs of the broadest possible community  Use the Educational Community License for all work products  Act as an advocate for the Program. Partner Commitment

24. 24 Benefits of Community source  Created specifically for higher education  Shared resources spread the cost of development  Continuous upgrades and enhancements contributed by the community lower the cost of software maintenance and enhancement  Flexible architecture allows implementers to use any combination of Kuali Student modules, vendor supplied components and home grown modules.

25.  Educational Community License – ECL V2.0  Kuali Student will be built entirely on an open source software stack compatible with the outbound Educational Community License (ECL).  Kuali Student will adhere to the Kuali Foundation’s IP management policies for inbound licensing and assessment of 3rd-party licenses Licensing

26. When is Kuali Student Delivering? Carol Bershad | University of Washington

27. KS Product Roadmap

29. KS Curriculum Management What is this module? Curriculum Management provides the ability to propose, create, modify and retire learning experiences that are part of an institution's sanctioned curriculum. What features does it have? Courses and Program Robust proposal process Administrative CRUD screens Analysis of dependencies across the curriculum What is its status? DELIVERED Version 1.1 March 2011 Version 1.2 November 2011 Now in the “hands” of the Community

30.  Implementations  Ongoing support and enhancements KS Curriculum Management InstitutionCurrent Status Boston CollegePlanning and proof of concept North-West UniversityIn Progress UC BerkeleyIn Progress University of MarylandIn Progress University of WashingtonIn Progress (data migration) QUESTIONS Questions addressed to Project and Community ks.info@kuali.org ks.collab@kuali.org QUESTIONS Questions addressed to Project and Community ks.info@kuali.org ks.collab@kuali.org DEFECTS Defects submitted and tracked in JIRA https://jira.kuali.org/bro wse/KSLAB DEFECTS Defects submitted and tracked in JIRA https://jira.kuali.org/bro wse/KSLAB ENHANCEMENTS Enhancements are managed via the KS Contribution Model ENHANCEMENTS Enhancements are managed via the KS Contribution Model

31. KS Enrollment What is this module? KS Enrollment manages the enrollment lifecycle of students once admitted to the institution What features does it have? Course Registration Course Assessment Program Enrollment Program Assessment … and many more (stay tuned)! What is its status? IN DEVELOPMENT … by the KS Project Team

32. 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 Academic Record KS Enrollment: Framework KS Curriculum Management UW My Plan KS Accounts 3.Course Offering 4.Course Registration 6.Program Offering 9.Academic Planning 7.Program Enrollment 1. Setup 2.People and Permissions 8.Program Assessment 5.Course Assessment 10.Academic Record KS Scheduling KS Program Audit

33. 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 33 KS Enrollment : Roadmap ENR 1.0 ENR 2.0 and beyond Full Feature Set Basic Feature Set ENR 2.0 and Beyond ENR 1.0

34. UW MyPlan What is UW MyPlan? UW MyPlan is an academic planning tool that makes it easier for students to navigate the UW’s curricular offerings and achieve their academic goals. What features does it have? View enrollment history Explore curricular offerings Perform program audit Project academic plan Share with advisor What is its status? IN DEVELOPMENT … as a Contribution

35. KS Accounts What is this module? The Accounts module supports the pricing, sale and purchase of both internal and external products (e.g. courses and programs) and services (e.g. athletics and library fees) What features does it have? Assess tuition and fees Access to financial planning tools Invoice customer Settle bill Maintain customer account Process refunds What is its status? IN DEVELOPMENT … as a Contribution

36.  The first vendor-contributed project designed as a core KS module  Sigma Systems based in Denver, CO  Forty years of experience in US higher education  ProSAM, flagship financial aid package  Sponsoring institutions are University of Maryland and University of Southern California  Planned KSA submodules:  KSA – Receivables Management  KSA – Fee Management  KSA –Third Party  KSA – Collections Management  Submodules identified but not included:  KSA – Scholarship Management  KSA – Aid Management KS Accounts

37. How We Are Doing It

38. 38 Product Development vs. Implementation  The scope of the Kuali Student Program does NOT include the Founder implementations  Student Systems will have a parallel implementation project with its own project charter and implementation team.  Kuali Student will need to be “configured” to meet the needs of institutions  Student Systems will also be maintaining the current SIS until full implementation and transition to Kuali Student  The implementation team will work in parallel to the Kuali Student Product Development team and will benefit from close coordination.  Kuali Student will need to provide product support to the implementation team after each release.

39. 39 Specific Objectives  To develop a next generation Student Service System architecture that follows the principles of Service- Orientation, implemented using Web Services.  To develop the Service Contract specifications for the services required to implement the Student Service System. This will enable development work to be completed by a large community, not just the originating Founders.  To develop, and release for implementation, a software product consisting of a set of Services that have been defined to be the core functions of a next generation Student Service System - Kuali Student.  To define and publish standards for development that can be used by other members of the community to develop Services that are not within the scope of the core product.

40. 40 Specific Objectives  To ensure the core Services of Kuali Student are successfully implemented by the Founding Institutions.  To promote the adoption and implementation of Kuali Student by a wide variety of educational institutions – within North America and internationally.  To build a community of interest that will sustain future maintenance, enhancement and development of the product.  To define product development and support processes that will be used to assist the community to implement the software and to provide operational support for the product.  To continue to evolve the technology and architecture of Kuali Student over time to keep up with new industry standards, tool releases and trends.

41. Development Philosophy Embrace Iterative development  A Module has 2 or more Releases  Each Release is broken down into short Milestones  Every Milestone delivers code which goes through QA  Milestone code is available to KS community

42. These principles guide the full lifecycle of the project. 1. SOA methodology 2. Rice as the middleware platform 3. Web services 4. Standards based 5. Separate governance process for service contracts 6. Abstraction of business process and business rules 7. Abstraction of presentation layer 8. Abstraction of the data layer 9. System will be built entirely on an open source software stack 10. Infrastructure will be composed of existing open source products 11. Java as the language of choice Guiding Principles

43. Truly a next generation Student System  Infrastructure: Relies on a modern infrastructure developed in the Cloud  Separation of UI and Services enables institutions to  Develop their own UIs  Integrate with current systems on campus SOA Implications

44. Truly a next generation Student System  Services are designed to accommodate future changes to business processes.  Front end can change every few years but Service Contracts are more stable over time  Loose coupling between modules helps institutions  Roll out modules over time  Minimize impact of changes from one module to another SOA Implications

45. Addendum: History of KS Business Requirements

46.  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” 46 A Brief History of KS Requirements

47.  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 47 A Brief History of KS Requirements

48. 48 Analysis and Design Synthesis Analysis and Design Institutional Requirements 8 institutions x 30 “melanges” Requirements 10 Functional Areas Analysis Team UX SVCS + + Creation Review Analysis Team Business Requirements Team Parallel Delivery