1 / 28

Exploring Kuali Student Application Architecture

Learn about Kuali Student's functional sides, business domains, and application architecture goals. Discover the vision and objectives behind the "Next Generation Student System."

waylonr
Download Presentation

Exploring Kuali Student Application Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Overview of Kuali Student Application Architecture Rick Burnette (FSU) Gord Uyeda (UBC) Kuali Days :: Chicago May 13-14, 2008

  2. The Vision Can We Make Kuali Student a ”Next Generation Student System?”

  3. Vision Statement • support end users by anticipating their needs • support a widerange of learners and learning activities. • support a wide range of business processes • flexibility to make it easier to change business processes to meet institution needs • reduce time staff spend on routine tasks • allow for Extensibility for the future changes and growth

  4. Presentation Objectives Provide a summary of the Functional side of the Kuali Student • How we are structured • What the teams did • What the teams are currently working on • What’s next • How to get more info

  5. Tier 1 Business Domains • Person Identity • Learning Unit Management • Enrollment • Program Audit and Academic Evaluation • supports evaluation, status towards Learning Objectives • supports ongoing evaluation of academic progress • Person Identity • Learning Unit Management • Enrollment • manages Learner to LU relationships • manages Provider to LU relationships • manages Learning Results • Person Identity • Learning Unit Management • Enrollment • Program Audit and Academic Evaluation • Student Financials • Product pricing • assessment of additional Fees • determine Invoice and Payment plans • Payment processing • Person Identity • Learning Unit Management • manage catalog of Learning Experiences • manage creation, approval new LUs • manage evaluation, review of existing LUs • Person Identity • manage Person info • support Authorization, Authentication • manage Groups, Organizations • manage Contact info

  6. Tier 2 Business Domains • Admissions • Scheduling • Financial Aid • manage Awards, Financial Aid Resources • maintain student Characteristics and Needs • assign Awards to students • Admissions • Scheduling • manage LU “offerings” • schedule Resources • manage Calendars • Admissions • capture Application info • manage Evidence • automate process workflow • evaluate Learner’s qualifications

  7. other Business Domains Out of Scope • Learning Management System • Student Portfolio • Financial (FMIS) system • Campus Calendar • Facilities Management • Library • Parking • Recruitment • Event Management • Housing • Athletics • Alumni Development • Family Financial Planning • Elections • Student Life

  8. Collaboration Tools • Face-to-Face Workshops • Wiki, Googledocs • Skype + Breeze • IM and Googletalk • HD video conferencing bridge • Phone and email

  9. Application Architecture Phase

  10. Primary Goals &Agile SOAD Methodology Application Architecture Goals • Kuali Student • SOAD Methodology Domain Discovery Service Candidate Identification • document High Level Functionality • id Service Candidates • Domain Partitioning • define Release 1 Scope Service Modeling and Contract Design Service Modeling and Contract Design

  11. Application Architecture Signoff 3.8 partition Services Into Applications and Domains 3.2 create Business Process Model 3.6 map Institutional Requirements to Kuali Features 3.9 validate against Concierge Design Principles 3.7 identify Service Candidates 3.1 create Conceptual Object Model 3.3 gather Institutional Specific Requirements (institutional responsibility) 3.4 collect and document Use Cases 3.5 Identify Rules Test Cases 3.5 Identify Data Abstraction Test Cases 3.5 Identify Orchestration Test Cases User Signoff 1. Document High-level Business Requirements

  12. Design Workshops Document High-Level Requirements - Steps Institutional Interviews BAs SMEs

  13. High-Level Requirements Teams & Deliverables Functional Statements Object Model Swim Lane diagram Nov Aug Oct Sep Jul

  14. Application Architecture Signoff 3.8 partition Services Into Applications and Domains 3.2 create Business Process Model 3.6 map Institutional Requirements to Kuali Features 3.9 validate against Concierge Design Principles 3.7 identify Service Candidates 3.1 create Conceptual Object Model 3.3 gather Institutional Specific Requirements (institutional responsibility) 3.4 collect and document Use Cases 3.5 Identify Rules Test Cases 3.5 Identify Data Abstraction Test Cases 3.5 Identify Orchestration Test Cases User Signoff • Service Candidate Identification • Domain Partitioning

  15. … Domain Capabilities Service Candidates Service X-Refs diagram Teams, Steps and Deliverables Nov Dec Aug Oct Sep Jul

  16. 4. Define Release 1 Scope

  17. Service Modeling andContract Design

  18. Service Design Teams • Use Case Team • User Scenario Subject Matter Experts • Service/Case Analysts • Data Team • Data Structures and Service Message Structures • Services Team • Service Factoring + Service Stack Composition • Service Operations + Service Contracts

  19. Service Design Scope The current focus of the services teams is on: • Learning Unit Management • Person Identity • Person and Organization Management Services • Common Services • Rules • Workflow • Communication

  20. Service Design Deliverables By November, the services teams will: • Produce Service Definitions, Contracts and Message Structures for the defined services. • Produce a mature set of user scenarios, test use cases and reference implementation cases • Provide validation of released service iterations and modify services until finalized

  21. Next Steps starting November 2008

  22. Release 1 Development Beginning in November, the services teams and will support both Release 1 development and Release 2 Service Modeling and Contract Design Functional Team members (Use Case, Data and UX) will work with the technical teams on the development of the Release 1 application implementation

  23. Release 2 Service Design The bulk of the services teams will begin working on Service Modeling and Contract Design for Release 2. This work will likely be focused on designing services around the Enrollment Module.

  24. So What?

  25. What we Learned? • Collaboration Experience • Distance challenges • Inter-institutional interactions • Team dynamics • Flexibility of the Learning Unit Construct • The User Experience/Concierge Focus • We produced a new SOAD Model

  26. Questions?

  27. Need More Information? • Kuali Days Functional Presentations • Evolving a New Agile Service Oriented Analysis and Design (SOAD) Methodology (Tues 2:15 ) • KS Person Identity & Learning Unit Management Service Design (Tues 3:45) • Electronic Concierge (Tues 5:00) • Learning Unit Management II and other Topics(Wed 11:00) • KS User Interface (Wed 2:15) • Kuali Foundation(http://kuali.org/) • Kuali Student • https://test.kuali.org/confluence/display/KULSTU/Home

More Related