Skip to end of metadata
Go to start of metadata

As of April 4, 2013

Legend: Done(tick) /Green is on Track(plus) /Yellow is At Risk(warning) /Red is Off Track(minus)


Overall At Risk: (plus) trending vertical

Major Milestones

  • Milestone 1 (tick) , Thin Slice of KS integration and KS technology stack
    • Completed April 16, 2012
      • Use of KRAD, KIM and KSA services
      • Kuali Rice 2.x framework
      • End-to-end in technology stack
  • Milestone 2 (tick) , Transaction view of student receivables
    • Completed April 16, 2012
      • Strategic functional milestone
      • Unfiltered transaction view and account summary
      • Originally projected for 4Q 2012
  • Milestone 3 (tick) , Account Aging and Delinquency
    • Completed October 15, 2012
      • Strategic functional milestone
      • Originally projected for 4Q 2012
  • Milestone 4 (tick) , Integration with KFS
    • Originally projected for 3Q 2012, Completed January 23, 2013
      • KFS integration testing with UMD completed
      • Integration demonstrated to KS technical team and UMD Bursar representatives 1/23/13
  • Milestone 5 (plus) , Fee Management (Assessment)
    • Anticipated on schedule and originally projected by June 1, 2013
  • Milestone 6 (plus) , 3rd Party Billing and Processing
    • Anticipated on schedule and originally projected by June 1, 2013


  • Recent demonstration: April 4-5 USC Bursar and IT representatives
  • Recent demonstration: March 4 KS PAG
  • Recent demonstration: February 18-19 UMD Bursar; March (anticipated) USC Bursar
  • Recent demonstration: January 23, 2013 KS technical team and UMD Bursar representatives

Key Current Topics, Issues and Risks

  • (warning)   The KSA development team is current engaged in a KRAD development sprint to complete the Phase 1 UI which is behind schedule.
    • February Update: A lot of progress has been made and the majority of the complex screens have been developed.
    • (minus) March Update: Testing of the more complex UI recently complete has identified significant performance concerns.  The UX team has engaged with the KRAD user group to escalate the issues and to identify and possible work around.  This will also be discussed at the Community Workshop in April.
  • KSA representatives will met with the KS UX team at the Community Workshop in April for a UX alignment review between KSA and KS.
  • KSA has engaged with KS QA leads to confirm alignment in philosophies.
    • Essential processes are similar although KSA is not currently automating the functional testing.
  • (tick) The KSA team met with the KS technical team at UMD for a review of services and analysis of technical alignment with the Kuali stack.

Phase 1 Progress Metrics



Original Time Estimate

76 weeks



Time Elapsed

73 weeks



Expected Percent Complete




Actual Percent Complete


Phase 2 Progress Metrics



Original Time Estimate

40 weeks



Time Elapsed

24 weeks



Expected Percent Complete




Actual Percent Complete


Release Schedule

  • Phase 1 Founders Release: Development completion scheduled for April 16, 2013
  • Phase 2 Founders Release (Project Completion): Development completion scheduled for June 27, 2013

Overview Completion Dates (plus)

Overall On Schedule Trending Flat

Completed Notable Tasks

  • March 2013 (as of 4/4/2013)
    • Actively engaged with KS team to synchronize the Fee Management touch points
    • All wireframes for phase 1 are completed
    • Significant progress with outstanding UI development in active sprint
    • Payment Application module now in testing
  • February 2013 (as of 3/7/2013)
    • Completed a UX review and began onsite user testing with stakeholders
      • UMD completed early this month, USC scheduled for first week of April
    • Continued major focus on UI development
      • Making use of nice KRAD features such as subcollections within collections and lightboxes
    • Great progress with the Payment Application rules engine using a DSL (Domain Specific Language) for end users
      • Currently under internal testing with USC production rules
      • Builds upon the proof of concept developed for KD's and is the foundation for the more complex Fee Assessment requirements (phase 2)
    • Several conversations with the KS team regarding holds and ATP (time).  Design for this in KSA is complete and in development
    • Project update and live KSA presentation to the PAG 3/4/13
  • January 2013 (as of 2/4/13)
    • Payment Bill and Third Party design completed pending review
    • UI for General Ledger (supporting KFS integration) designed and implemented, minor bug review taking place
    • Transaction Type UI significant progress, however sprint ongoing
      • KSA makes extensive use of KS 'Type' service
    • Completed integration of KS ATP (academic time period) service into KSA
    • Several reporting methods implemented including Aged Balance & 1098T
  • December 2012 (as of 1/11/13)
    • KSA was upgraded to Kuali Rice 2.2.0 release and KSA Maven dependencies were changed
    • Integrated Kuali Student’s ATP (time) service in KSA
      • Heavily used in Fee Management module
    • Refactored Rules Service and its Drools implementation
      • Creating a new database schema for storing rules and modifying the Drools persistence layer
    • TransactionExportService and TransactionExportController classes used for General Ledger and KFS integration were completed
    • Internal QA of general ledger completed (KFS XML file generation)
      • Efforts ongoing to complete stakeholder testing
    • Process design for Third party billing 90% complete
    • Process design for payment billing 90% complete
    • Multiple working sessions with KS services team members (Tom and Norm) to confirm migration of KS services in KSA (ATP, holds, possibly organization)
    • UI working in-person meeting held with KS team (William Washington) to review KRAD capabilities and gap analysis for KSA requirements
    • 8300 Reporting (cash payments over $10k) process 90% complete, includes export
  • November 2012 (as of 12/10)
    • Development for integration with KFS and generation of transactions is complete
      • KSA has reached out to stakeholders to initiate test plan with desire to complete by 12/31.
    • The following development is now complete for KFS integration needs and for testing:
      • Refund Service
      • Account import
      • Account export
      • Transaction import for UI controller
      • Transaction utility for filtering and allocations
      • General ledger service for preparing and summarizing transactions
    • 3rd party (milestone 6) design now 65% complete
    • UI development of Transaction types underway
      • Anticipate significant additional development for remaining UI in phase 1 over the next month.
  • October 2012 (as of 10/3)
    • Completed a KRAD analysis and effort to support 2 levels of navigation between views and pages
    • Incorporated search controls and a KSA logo into the application header (KRAD)
    • Modified KRAD templates to position the UIF elements (including breadcrumbs) according to the wireframes
  • September 2012 (as of 9/11)
    • KFS output designed, under validation and development began (3Q 2012 deliverable)
      • Sprints established to meet milestone
    • Proof of concept for Fee Management (2Q, 2013 deliverable) designed
      • Includes Classes, data model and import schema
    • Payment Application conceptual design complete
    • KSA trunk upgraded to Rice 2.2.0-M3 release
  • August 2012
    • Now able to process & import online and volume transactions / document to KSA ledger and create receipts / results
    • Worked out the major contours of payment application and general ledger transaction production (but not interaction, KFS)
    • Designed a number of standard reporting formats (1098T being one of them- strategic)
    • Designed a number of transfer methods to transfer charges to other accounts, which will be fundamental to sponsor billing, etc. Includes write offs, etc.
    • Implementing refund services development 50% complete
    • Payment billing (phase II requirement) design underway
      • This is a trigger for a general ledger review
  • July 2012
    • Interaction with KS-KFS Team Delayed and Off-Schedule
    • Demonstrable Aging of Accounts
    • Account Delinquency
    • Collection Management
    • Dynamic Transaction Views
    • Integrating Rules Management System with KSA
  • June 2012
    • Audit for KSA Lifecycle Supported
    • Transaction Service and XML Load Supported
    • Aging of Accounts Service 70% Complete
    • Utilize KSB Scheduler Factory & rules to initiate transaction input service to age accounts in volume
    • Initiated Contact with Stakeholders to Stage QA Receivable Management Content to KSA Database
      • (First development interaction with stakeholders)
      • UMD fully engaged
    • Refund Management Design Near Completion
    • Personal Preferences Design Under Review
    • Access Authorization for User Ability to Apply Certain Transactions Completed
  • May 2012
    • Interface with KIM Complete
  • April 2012
    • Major Milestone (1) Completion Announcement
    • Thin Slide of KS Interaction and Kuali Technical Stack
    • Major Milestone (2) Completion Announcement
    • Transaction view of Student Receivables
  • March 2012
    • Published KSA-PB (Payment Billing)/TP (Third Party)/CM (Collections Management) requirements on Wiki
    • Published KSA-RM UX Personae on Wiki
    • Published designed KSA-RM use cases, data representation and ER diagrams
    • Published KSA-RM UX Wireframes
    • Stakeholder review/approval period started
    • KS-Community comment period ended for KSA-FM
    • KSA-FM rules design sign-off (epic dev - phase 2)

Detailed Status

Phase 1 (plus)

Overall: Trending Vertical

Overview: Phase 1 includes Receivables Management and Core Accounting

Objective: This module handles the core requirements of accounts receivable, including handling accounts, charges, payments, deferments, etc.  Almost every other module in the system interacts with Accounts Receivable and core accounting functions.  The module includes, but is not limited to the following functions:

  • account management
  • refund management
  • reporting and reconciliation
  • bill production
  • transaction creation
  • cashiering
  • general ledger interaction
  • payment type tracking
  • charge type tracking
  • payment application
  • auditing
  • policy enforcements
  • payment acceptance
  • memo functionality
  • bad debt and collections
  • regulatory tracking
  • holds

Upcoming Milestones

  • All Phase 1 milestones have been completed.

Risks (in order of priority)

  • none

Phase 2 (plus)

Overall On Schedule Trending Flat

Overview: Phase 2 includes Payment and Billing and Collection Management, Fee Management and Third Party

Objective: The fee assessment module will be able to calculate all fees and charges for a student given their demographic data, the course load, and other applicable variables. The necessary student data will need to be accessible to this module either via an integration to the school’s student system or an ESB request to the school’s student system or over the KSB.  This will be a rules driven process that will be able to handle extremely sophisticated billing algorithms. The charges can then be posted to the account, or provided to another service (for example, in KE, a student could theoretically present their list of classes, and find out how much it would cost, and create several what-if scenarios.)

Third Party Accounts is otherwise known as sponsorship accounts. This is a module that provides a standard way to deal with an often ad hoc accounting practice, where third-party sponsors agree to pay for some portion of a student account. Most often, this is an employer offering some form of tuition benefit. Third-party access to bills and information is handled very differently to student access. This module will allow that customization, as well as handle the transfer of funds from a third-party payment to the student’s account. It will also handle the reversal of funds if a sponsor does not pay the bill or a student's participation requirements change. The module will include the following:

  • third party sponsor and student accounts
  • transfer of fee from the student(s) account to the third party sponsor account
  • generations of third-party billing
  • third-party payments
  • third-party account aging
  • third-party sponsor self-service/access (phase 3)

Upcoming Milestones

  • Fee Management (Assessment) (2Q, 2013)
  • Third Party (2Q, 2013)

Risks (in order of priority)

  • none 
  • No labels