sigma systems, inc. - immagic.com · paul heald, sigma systems inc. page 11 the need for self...

Sigma Systems, Inc.

Technical Brief

Self Service and ProSAM:UC Berkeley’s Experience with MyFinAid and Kuali

Paul Heald

October 11, 2010Sigma Systems, Inc.

Self Service and ProSAM

UC Berkeley’s Experience with MyFinAid and Kuali

Paul Heald

Sigma Systems, Inc.

An electronic copy of this document can be downloaded from

http://www.sigmasys.com/opendocs/myfinaid.pdf


Page 2 Paul Heald. Sigma Systems, Inc.

ExecutiveSummary

Students arriving on college campuses have ever greater expectations for the IT infrastructure that will

support them during their time at the college. The current generation has a high expectation of 24/7

access to information and services, and the ability to perform many, if not all, of their administrative

tasks through a web browser.

The Berkeley MyFinAid was a project undertaken by the Financial Aid and Scholarship Office (FASO) of

UC Berkeley in conjunction with Sigma Systems, Inc. as part of their migration from the Sigma’s legacy

SAM system to the current generation ProSAM system. Its aim was not only to provide another method

of access to financial aid information to students, but also to automate several of the processes that a

student might have to go through in order to receive the correct financial aid award package.

The system went live on March 25 of 2010, and within the first hour, over 600 students had logged on to

the system. On average, the system deals with 3,000 requests from students every day. This freed staff

in the student aid office to deal with those more complicated cases that require human intervention.

As a member of the Kuali Foundation, UC Berkeley is interested in furthering the use of Kuali resources.

As such, from the beginning, the MyFinAid project was designed to be easily converted to a Kuali‐

complaint application in the future.

There a large number of Kuali features and resources that can be used in the future to improve not only

the MyFinAid product, but access to financial aid resources in general in the future. The Kuali Project is

aligned with UC Berkeley’s strategic focus on a service‐oriented architecture [SOA].


Paul Heald, Sigma Systems Inc. Page 3

Acknowledgements

This document builds on the materials produced by the Financial Aid and Scholarships Office [FASO] of

UC Berkeley in the creation of their MyFinAid solution. It draws heavily on resources provided by UC

Berkeley, and on materials drawn from the Kuali Foundation.

The MyFinAid project was a project of UC Berkeley, with technical assistance from Sigma Systems, Inc.

This document was produced by Sigma Systems, Inc. with collaboration from UC Berkeley.

All non‐Sigma materials used in this document are believed to be open source or public domain. Please

contact us if this is not the case.

Sigma Systems, Inc.



TableofContents

Executive Summary ....................................................................................................................................... 2

Acknowledgements ....................................................................................................................................... 3

Table of Contents .......................................................................................................................................... 4

Preface .......................................................................................................................................................... 6

Intended Audience ........................................................................................................................................ 8

Purpose of Document ................................................................................................................................... 9

Revision History ............................................................................................................................................ 9

Document Scope ......................................................................................................................................... 10

The Need for Self Service ............................................................................................................................ 11

The Move to ProSAM and the birth of the MyFinAid Project ..................................................................... 15

Designing with the Users in Mind ............................................................................................................... 16

Vendor Collaboration .................................................................................................................................. 18

Functional Requirements ............................................................................................................................ 20

1. User Roles and Authentication ....................................................................................................... 20

2. Logon and Logoff Processing .......................................................................................................... 20

3. General User Actions ...................................................................................................................... 20

4. General Functionality ...................................................................................................................... 21

Non‐Functional Requirements .................................................................................................................... 22

1. Operational ..................................................................................................................................... 22

2. Performance ................................................................................................................................... 22

3. Security ........................................................................................................................................... 22

4. Cultural, Political and legal .............................................................................................................. 22

5. Usability, look and feel, HCI ............................................................................................................ 22

6. Scalability and Maintainability ........................................................................................................ 23

Basic Functionality of System ..................................................................................................................... 24

Basic Use Case Diagrams ............................................................................................................................. 25

Textual Use Cases ....................................................................................................................................... 27

Authorizations by User ................................................................................................................................ 68

Basic Model of Communication of the MyFinAid Implementation ............................................................ 70



Screen Flow ................................................................................................................................................. 71

Screen Shots of Implementation ................................................................................................................ 72

About Kuali .................................................................................................................................................. 79

Towards a Kuali‐Complaint Model .............................................................................................................. 80

Consumption of Kuali Resources ................................................................................................................ 82

Consuming Rice ....................................................................................................................................... 82

The Kuali Enterprise Service Bus (KSB) ................................................................................................... 82

Kuali Identity Management (KIM) ........................................................................................................... 84

Kuali Enterprise Workflow (KEW) ........................................................................................................... 84

Consuming the Kuali Financial System (KFS) .......................................................................................... 84

Consuming Kuali Student (KS) ................................................................................................................. 84

Other Benefits of Using the Kuali Framework ........................................................................................ 85

Conclusions ................................................................................................................................................. 86

Acronyms and Abbreviations Used in this Document ................................................................................ 87

Appendix A: Budget Codes and Categories for my Net Cost Screen and Annual Budget Screen ............... 90

Appendix B: Data Descriptions for My Net Cost Screen ............................................................................. 96

Appendix C: Calculation of Need‐Based Availability ................................................................................... 98

Appendix D: Work‐Study Maximum Conversion Calculations .................................................................... 99

Appendix E: Types of Self Reported Resources ........................................................................................ 100

Appendix F: Project Charter for the SAM to ProSAM Conversion ............................................................ 101

Selected Bibliography ............................................................................................................................... 112



Preface

In just under a year, The University of California Berkeley’s Financial Aid and Scholarships Office and

Information Services and Technologies Department made a bold decision to implement student Web

access to their financial aid data. Student‐initiated transactions could, like other financial systems,

trigger further processing immediately and display the results.

Student self service had two objectives. First to gain the efficiencies of student self service at a time of

increasing and late U.S. Department of Education regulation and guidance and new and more complex

federal aid programs. This myFinAid system was also consistent with student expectations to use the

Web rather than telephone calls or visits to the Financial Aid Office.

This paper documents the design of the resulting myFinAid system. It is written with the content,

format, and methodologies used now for current designs of complex information systems and

consistent with the Kuali vision. It does not include a story of the work of the many dedicated staff who

successfully created and implemented MyFinAid in such a short time.

The Berkeley Financial Aid and Scholarship Office had made such a bold and equally successful decision

before. The Financial Aid Office staff and new Director Richard Black made a decision to move from a

paper‐file folder based system to electronic records. Using an extension to Sigma System’s SAM’s

Application Track Module, the goal was to reduce the clerical effort of handling vast amounts of paper

documents. This improvement gave financial‐aid counselors the opportunity to better serve students.

Berkeley’s successful implementation redefined how financial aid would be administered. In the

myFinAid project Berkeley has again led in the effective use of information technology to improve

financial aid.

In March 2006 the University of British Columbia hosted a training seminar on Service‐Oriented

Architecture or SOA. The goal was more effective and lower cost software. The seminar, led by Thomas

Earl, author of “Service‐Oriented Architecture: Concepts, Technology, and Design,” included universities

that later became the core of Kuali Student. Some participants subsequently prototyped the Meteor

network using Web Services standards as described in the seminar. This early vision was part of the

input to the later U.S. Department of Education’s Modernization program. MyFinAid is consistent with

that vision and subsequent Kuali Student software development efforts. And the implementation is also



consistent with the Department’s plans for on‐line institutional Web Services expected to begin in 2012

or 2013.

Financial aid officers can learn from the “business processes” and system operations sections how

MyFinAid works. Information technologists can read about the technology choices and details of the

system design.

Hopefully this document contributes to the dialogue about the use of information technology to

improve university administrative services as well as describing the achievement it represents.

James Farmer

Chairman, Sigma Systems, Inc.

Washington DC



IntendedAudience

This document is intended for use by both business and technical users. A limited amount of the

technical implementation data has been included in this document to provide guidance to IT

departments who are interested in building similar functionality to the MyFinAid project.

We hope that through this collaboration, other institutions can follow the lessons learned by UC

Berkeley, and develop similar and extended functionality to self‐service portals.

We also hope to encourage the development of Kuali‐complaint materials, which will utilize and

showcase the power of this remarkable platform.

This document was produced for the Kuali Days 2010 Conference.



PurposeofDocument

This document has two purposes. Firstly, it shows a successful implementation of a student self‐service

portal that was created by the University of California at Berkeley, leveraging the power of Sigma

System’s ProSAM application used by the financial aid office. While this implementation is Berkeley

specific, there is a great deal of information in the implementation that would be useful to any other

college who would like to implement such a service on their own campus.

The second purpose of this document is to highlight some of the challenges that the current architecture

of college‐based enterprise systems pose for such integration, and how the framework being assembled

by the Kuali project will help to foster better integration between such systems in the future. Therefore

this document is both a practical guide to implementing a student self‐service portal, and also theoretic

in its approach to the use of the technologies that will be provided by the Kuali project.

RevisionHistory

Number State of document and major revisions Author Date

V0.1 Initial documentation Paul Heald 9/21/2010

V0.2 Secondary revisions Paul Heald 10/18/2010

V0.3 SME Review Rachelle Feldman 10/19/2010

V0.4 Administrative revision Paul Heald 10/26/2010

V0.8 Final review revision Paul Heald 11/1/2010

V0.9 Review Andy Sprague 11/2/2010

V1.0 Document Release Paul Heald 11/3/2010



DocumentScope

The MyFinAid project has been an outstanding success. This document has two major aims. Firstly it is a

reference for those who might be considering embarking on such a project, as an example of what is

possible in the realm of student self‐service applications. Secondly, it aims to examine future

applications to such devices under the framework that will be provided by the Kuali initiative. Although

the MyFinAid application is not a Kuali‐compliant application at this time, it was designed with this

future functionality in mind. It is Java‐based and is built upon the Google Web Toolkit framework [GWT].

The latter half of this document details potential Kuali‐complaint functionality. Specific references to

application programming interfaces within the Kuali framework (rather than the technologies

themselves) are outside of the scope of this document.



TheNeedforSelfService

The MyFinAid project was an offshoot of Berkeley’s decision to change from the mainframe based SAM

system to the Window’s based ProSAM system. As part of the move, Berkeley decided to implement an

enhanced web portal so that students would be able to more readily access their financial aid

information.

As noted in the 2007 Berkeley report, Information Technology at UC Berkeley: The Student Experience,

the student body at Berkeley1 “Most incoming students arrive at Berkeley with their own laptops and

cell phones… They use … regularly use Google and Wikipedia for reference... The majority visit YouTube

and make use of the Internet for shopping and gaming”2 – that is to say, they are typical members of the

“Net Generation”3, and as such have many different needs and expectations as compared to the

students who came before them.”4 The results of the study were that the university as a whole needed

to close the gap between the students’ experience of IT at Berkeley and their consumption of it. In

particular, there was a need to focus on making services available at any time, and anywhere. The report

also recommended expanding the use of CalNET5 as the single sign‐on provider for access to the

university information systems. The report also acknowledged that not all students are early adopters of

technology, or indeed technophiles. For this reason, the MyFinAid project is an addition to the services

offered by the FASO, rather than a replacement.

The As‐Is system provides a model where the financial aid office has to be the gateway between all

student, parent and other staff requests. By limiting SAM usage to this small group of staff, students are

given little opportunity to take ownership of their financial aid application and related decisions, as they

always have to go through a broker to access these services. In its most basic form, the existing system

can be modeled thus:

1 The official name of the campus is the University of California at Berkeley. The campus will be referred to as Berkeley throughout this document. 2 Blaine 3 Tapscott 4 Blaine 5 CalNET is the cross‐campus single sign on provider based on the JA‐SIG CAS service.



Simplified As‐Is Use Case Diagram

Having the FASO be the interface point between all financial aid consumers is an imperfect solution,

especially with a population that is used to self‐service, and 24/7 access to their information. The move

towards student self service was to allow students and certain other third parties to access their

financial aid information. Although limited self‐service functions were available in the past, they were

essentially a “view” model for the student, with limited availability to accept certain awards. All

communication was done via batch scripts, therefore all communication was essentially one way.

Changes made by the student were not visible until the next day after the batch processes had

completed.

The new self‐service model adds on to the current functionality by providing a portal for accessing and

updating certain financial aid information online. The high‐level use‐case diagram for the to‐be system is

as follows. It should be noticed that the new use cases do not prevent people from using the FASO as a

intermediary, however, it allows for students and third parties to gain access to a certain amount of self‐



service material. As a general rule, third parties can only view certain areas of the information, and are

in read‐only mode. That is to say that they cannot edit information (there are small exceptions, but this

is the general rule). Students also have access to much of their information, but will also have the ability

to edit certain information, as well as accept or decline loans. Many of these processes will trigger

automatic functionality within SAM, giving automated, real‐time responses to the student as they use

the system. The integration and exchange system [IES] of ProSAM allows for real‐time communication

between the portal and ProSAM, removing the need for the batch processing of the previous system.

The model also provides for members of the FASO to be able to view the MyFinAid process as if they

were another users, allowing for better customer service should a user have a problem. The ability to

view the same screens as the user allows for easier communication between the FASO and the user, and

will improve customer service and satisfaction.

By providing students and third parties with the ability to take control of the more routine facets of their

financial aid arrangements, the FASO is freed to deal with more complicated cases that require more

knowledge and skills.

These very general requirements are further explained in the system requirements section of this

document.



Simplified To‐Be Use Case Diagram



TheMovetoProSAMandthebirthoftheMyFinAidProject

The MyFinAid project was brought about through the choice of the FASO to move from the SAM to the

ProSAM system. The project charter for this move is documented in appendix F.

The move to ProSAM provided the input for an updated and improved self‐service module to be built

alongside the product. While financial aid self service had been available before ProSAM was installed,

the old solution was missing some key functionality6 that the department was starting to feel would be

necessary. In addition to adding this key functionality, the IES of ProSAM would allow the self‐service

module to communicate with the ProSAM application in real time via XML messages. This functionality

alone would allow near‐instant feedback to the student when they reported changes in their status, as

well as allow a student to input new information, and have it instantly available to the financial aid and

scholarship office.

Some of the new functionality that was desired by the FASO was as follows:

• The ability to update key information, such as planned enrollment, housing types, other family

members in college, etc.

• Provide access to a number of online forms.

• Facility to designate access to records in compliance with FERPA

• Ability to convert work‐study to loans or vice versa

• Ability to accept and reduce loans

• Improved messaging functionality

• Ability for FASO to control administrative options (such as screen locks, active years, work‐study

maximums, verbiage, calendar functions, etc. (Previously under the control of the IT

department)

• Report outside aid

6 The original system allowed the user to view and accept their financial aid package, as well as update their graduation date.



DesigningwiththeUsersinMind

Under the old self‐service module, students were not only presented with a very limited number of

options, but their path through those options was prescribed by the system. A user would arrive in the

application after logon, and would be led through a series of screens, many of which would request

information of the user. When surveyed, users and potential users pointed not only to limited

functionality, but also the number of screens they would have to go through to make simple changes.

Due to the batch processing of the system, no changes could be reported to the user until the following

day, and after a student had made a change, they couldn’t use the system again until the batch process

had completed. In other cases, certain information could be entered by the student, and the

information was simply forwarded to a person in the FASO, who would then have to re‐enter the

information into the system.

Understanding this problem, the design team looked at additional functionality, and worked closely with

Sigma to ensure that the functionality was either available, or could be built into the product. The many

processes of financial aid were broken into discrete steps, and a concierge‐like interface was planned

from the start, allowing the user to log in to the system, and be presented with an overview of their

financial aid, coupled with easy‐to‐recognize flags indicating areas that would need attention. The user

would be able to go directly to any area that they wished to look at, and could navigate the application

in any order they saw fit.

Using knowledge gleaned from the student survey of information systems, the designers were acutely

aware of the different the expectations of incoming students, even compare to only a few years before.

The MyFinAid team set out to create a product that would match their users’ expectations in terms of

always on, integrated online processing. Where this expectation could not be matched, they ensured

that the system would, at the very least, warn a user when an action could not complete as expected.

Understanding that incoming students expect information that is presented to them online to be up to

date, the MyFinAid application could no longer rely on batch data transfers. Information presented by

the application had to be pulled in real time from the database, and changes made by the user had to be

immediately included in any new financial calculations. A tight collaborative effort between Sigma and

Berkeley ensued to develop additional functionality to make the experience as seamless as possible for

the users.



Throughout the design process, expected users of the system were presented with screens, verbiage,

and examples of the system, and were asked if the screens met their needs, and what their expectations

were if they were to use parts of the system. Areas of weakness were identified and corrected, and

where current systems could not meet the expectations of the users, warning messages were clearly

identified. An example of this is when the student decided to declare that they would be living off

campus in the following semester, there was an expectation that the system would also inform the

housing office of this chance, which is not currently possible in this revision (but might be in the future,

especially with a more tightly integrated Kuali‐based system).

With constant revisions to the application, and by paying very close attention to the expected users of

the system, the MyFinAid designers were able to create an application that met many more of the needs

and expectations of the incoming Berkeley students.



VendorCollaboration

MyFinAid depends on a module of ProSAM called the IXS, or Integration and eXchange Service. This

module can take information from multiple sources and pass it through to the main SAM application.

When designing the MyFinAid application, UC Berkeley wanted to push forward the capabilities of web

self‐service.

In order to implement this functionality, the capabilities of the IXS had to be increased. UC Berkeley and

Sigma worked together to create a framework that would enable the MyFinAid application.

Use Cases were developed by UC Berkeley and reviewed and agreed by Sigma Systems. The channel of

communication between the MyFinAid program and ProSAM would be XML‐based documents. Once the

new functionality was agreed upon, Sigma Systems expanded the functionality of the IXS to meet the

needs of Berkeley, by providing additional content and creating a triggered event manager, allowing, for

example, a student to be repackaged “on the fly” if incoming data supported such an action. In total, 22

new elements were added to the XML in addition to the automatic triggering agents. These additions

are now available to all users of ProSAM.



This freed the developers at UC Berkeley to concentrate on their specific needs, such as institutional

security, development of the user interface, and ensuring that the system met their user’s needs.

This type of relationship is already very well established between Sigma and its clients, and will become

ever more the norm as the Kuali model becomes more established in the world of higher education.

Neither Sigma nor UC Berkeley could have produced this result on their own. Only by working

collaboratively, with a common goal in mind, was such a product possible.



FunctionalRequirements

1. UserRolesandAuthentication1.1 The system will have the following user roles. Administrator, Student, Staff [FAO], Staff [Non‐

FAO], delegates.

1.2 All users other than delegates have institutional identifiers, and will be able to authenticate via

CalNet authorization.

1.3 Users with more than one role will be able to choose their role upon authentication.

1.4 FASO will be able to view system from the vantage point of another user.

1.5 Delegate accounts and authentication procedures will be established within the application

[based on the UCLS/U. Michigan model]

2. LogonandLogoffProcessing2.1 Student: Full Functionality; some screens different based on graduate/ undergraduate student

status.

2.2 Delegate [Third Party/Parent]: Selected read‐only screens as authorized by the student plus

ability to fill in PLUS loan application data

2.3 Non‐FAO Staff: Selected read‐only screens, very similar to the delegate version, SID displayed

2.4 FAO Staff: Read‐only versions of all the student and parent screens plus SID displayed

2.5 Administrator: Includes ability to update text and tables and “act as” students for testing.

2.6 After log‐off, the system will return the user to the portal splash page.

3. GeneralUserActions3.1 Accept Terms and conditions

3.2 Authorize Third Party release of Information (FERPA)

3.3 If no aid awards exist, view messages as to why (No Offer Screen)

3.4 View My Net Cost – Snapshot of Budget, Gift Aid, and Self‐Help

3.5 View Award Details – Accept Loans and View all Awards

3.6 View Awards by Term

3.7 View Annual Budget and Budget by Term

3.8 Convert Need‐Based Loan to Work‐Study

3.9 Convert Work‐Study to Loans



3.10 Request Cancellation or Reduction of Paid Direct Loans less than 110 days old

3.11 Request Cancellation/Reduction of previously accepted unpaid loans

3.12 Manage Loans: View Dates of Master Promissory Note [MPN], Entrance, and Exit

Interview data and cumulative borrowing in each Federal Loan Program

3.13 View award payments and/or diagnostics explaining why awards have not paid

3.14 Report expected aid from outside resources

3.15 View missing Tracking documents (with links to download forms/instructions)

3.16 View messages

3.17 Update My Information: Report changes in Expected Graduation, Planned Enrollment,

Housing (Budget)Type, Change Third Party Authorizations, or request Cancellation of Aid

3.18 Link to Summer Aid Estimator/ View and Accept Summer Aid Offer

3.19 View Estimate of Effect of Withdrawal on Financial Aid Awards

3.20 Fill in a limited number of forms and push the data from the forms to ProSAM

4. GeneralFunctionality4.1 Rolling forward from implementation in the 2010‐11, all the active aid years in ProSAM should

be available either interactively or read‐only through web self‐service. Financial Aid and

Scholarship Office [FASO] should be able to control updatable vs. read‐only status for each

screen? For Missing Documents and View Messages, show the number of items in parentheses

in the left navigation bar.

4.2 Administrative staff will be able to enable, disable and make read‐only, screens as necessary



Non‐FunctionalRequirements

1. Operational1.1 System must be able to handle requests from all students at Berkeley who have filed a FAFSA.

1.2 System will accept up to 600 concurrent users.

1.3 System will reduce complexity of the financial aid system, improving maintainability.

1.4 Reduce costs via cheaper server‐based architecture.

2. Performance2.1 System will be able to return information to students within 10 seconds, not including time required

to trigger remote procedure calls and network latency.

2.2 System will be AJAX based to reduce the need for page reloads.

3. Security3.1 System will enforce security policies in accordance with Berkeley security.

3.2 Campus‐wide authentication system will be used for all members of the Berkeley community.

4. Cultural,Politicalandlegal4.1 System will ensure FERPA compliance relating to its own operations.

4.2 Project will remain complaint with the IT strategic plan for enhancing student experience.

5. Usability,lookandfeel,HCI5.1 Text, menu items, responses, email addresses and most content will be drawn from an

administratively editable database.

5.2 System will follow look and feel of existing student web‐portal designs.

5.3 System will follow current web‐standards, employing AJAX techniques to reduce the need for page

reloads.

5.4 System will employ techniques to allow the user to follow their own path through the application.

5.5 System will follow concierge style, bringing the user’s attention to pertinent information and areas

that need to be looked at.



6. ScalabilityandMaintainability6.1 System will be built using technologies that will assist with operating within a Kuali‐complaint

environment.

6.2 System will be complaint with Student Service 2012 goals for a hybrid technical environment

including open‐source student systems developed through the Kuali consortium and proprietary

systems.

6.3 System will be built using open standards where they exist, and will be able to adopt open standards

once they become available.



BasicFunctionalityofSystem

The following use cases document the functionality of the system. The written use‐case cards document

more specifically the Berkeley implementation of the process. While much of the information is

generally relevant, many of the calculations depend on Berkeley‐specific user codes and business logic.

These have been included in the documentation by way of example as to how Berkeley solved these

specific problems. An implementation in another institution would likely require modification to some of

the underlying logic to more accurately reflect the business processes of that institution.



BasicUseCaseDiagrams

Basic Use Case Diagram



Basic Use Case Diagram



TextualUseCases

The following use case cards are used to show the types of functions available through the portal and

some of the implementation of the system. As parts of this document were written after the MyFinAid

project was designed, there is a greater level of implementation information in these use case cards that

one would normally expect at this stage of the system design. It has been included as an aid to other

designers who are interested in how the Berkeley team solved certain problems.



Name Logon ID 1

PrimaryActor(s)

User (any)

ShortDescription

User logs on to the system.

EventTrigger

User visits the appropriate logon portal.

Flow

1. User is prompted for credentials.

2. Credentials are authenticated (this may be via campus‐wide single sign on, or, in case of

delegates, via internal credential system.

3. Role is received from authentication system.

4. Authentication token is passed to system.

5. Control is passed to home screen cascade routine (ID 2)

Sub‐flow(s)

5.1 If more than one role is returned, user is prompted to select from their available list of roles.

AlternateFlow

2.1 Credentials are invalid. User is returned to 1.



Name Home Screen Cascade ID 2

PrimaryActor(s)

User (any)

ShortDescription

Correct home screen is chosen.

EventTrigger

Authentication is passed.

Flow

1. Appropriate Home Screen is selected according to logic table 1

Sub‐flow(s)

AlternateFlow



1 2 3 4

Awards >$0 Exist N Y Y Y

FAFSA filed ‐ N Y Y

T&C Accepted ‐ ‐ Y N

Display Messages Screen Indicating

Why No Offer X

Display My Net Cost X

Display Awards Detail X

Display Terms and Conditions X

Logic Table 1



Name Terms and Conditions Acceptance ID 3

PrimaryActor(s)

Student, delegate

ShortDescription

User can accept of not accept terms and conditions of student self service.

EventTrigger

Home screen cascade invokes.

Flow

1. Appropriate terms and conditions of site are displayed.

2. User is prompted to accept terms and conditions.

3. Terms and conditions acceptance is updated.

4. Control is returned to home screen cascade.

Sub‐flow(s)

AlternateFlow

3.1 User declines terms and conditions. Logout is invoked.



Name Loan Authorization ID 4

PrimaryActor(s)

Student

ShortDescription

Student can authorize or revoke authorization of system.

EventTrigger

User selects loan authorization

Flow

1. User clicks “I authorize…”

2. SAM.TERMDTEC set to current date, SAM.TRMCON set to Y

3. Return to home cascade.

Sub‐flow(s)

AlternateFlow

1.1 User clicks “I take away my previous authorization”

1.2 SAM.TERMDTEC is set to current date

1.3 If SAM.TERMCON is null, set to N, else set to R.

1.4 Return to home cascade.



Name My Net Cost Screen ID 5

PrimaryActor(s)

User (any)

ShortDescription

Display Screen. This is the main home screen for most users. (See appendix B for data definitions for

these data elements.)

EventTrigger

Invoked from home screen cascade.

Flow

1. Collect and display the following Student information

1.1 Level of Study (Graduate or Undergraduate)

1.2 Dependency (independent or dependent)

1.3 Living Situation

1.4 Enrolment (based on SAM’s planned enrolment flags)

1.5 Estimated Graduation Date

1.6 FERPA release [if there is a FERPA release, link to FERPA Release Information page

2. Display the following UC Berkeley Costs

2.1 Fees

2.2 Health Insurance (if waived, show waived)

2.3 Books and Supplies

2.4 Living Expenses (transportation, personal, housing, food)

2.5 Other (includes loan fees)

3. Display Total UC Berkeley Cost

4. Display Gift Aid (less health insurance cost, where appropriate)

5. Display Net Cost

6. Display “Meeting my Net Cost”

6.1 Parental Share

6.2 Student’s loan and work



6.3 Total (Parental + Student)

7. Display link for “Award Detail” Screen.

8. Wait for student to make decision.

Sub‐flow(s)

AlternateFlow

2.1 If different statuses exist in different terms, display both.

2.2 If health insurance is waived, do not include in budget. Warning to be displayed. If there is a

difference between terms, show both statuses and include in budget as appropriate.



Name Show Budget Details by year/ term ID 6

PrimaryActor(s)

User (any)

ShortDescription

Gather and display budget details for a student.

EventTrigger

Invoked by user.

Flow

1. Tabulate each component and description from current fall and spring terms. Sort

components, ensuring that codes starting with Z, X3 and X4 are listed as “Additional Costs”

2. Calculate and display standard budget components.

3. Display Health Insurance details.

4. Display “Budget Details by Term” button.

Sub‐flow(s)

1.1 If budgeting by term, show only terms for which enrollment is planned.

1.2 If budget code has supplemental data, show this in the description.

1.3 If this is for the year, add together terms to give annual totals.

4.1 If Independent, show budget components for health insurance.

4.2 If dependent and AidIDs WHIF/WHIS on the package, show “waived” and do not include the

health insurance in the total cost. (Make cost 0.00 in screen) otherwise show budget

components for health insurance.

4.3 If aided is XHIF or XHIS and amount offered > $0 on the package, add a note to the bottom of

the Screen: “If you choose to waive out of the University Student Health Insurance

program, this amount will be deducted from your student budget. If you do not choose

to waive out, the Financial Aid Office will offer you additional aid for this cost once the

waiver deadline has passed for the term.”



AlternateFlow



Name Award Description by year or term. ID 7

PrimaryActor(s)

User (any)

ShortDescription

Show the awards available to the student, and allow the student to accept or decline loans.

EventTrigger

User triggered.

Flow

1. If term is selected, all fields are set to read only, and term, rather than aggregate data is

produced in following sequences.

2. Display Gift Aid Name, Amount and Status

3. Display Other Gift Aid, Waivers and Exemptions [Name, Amount, Status]

4. Display resources reported by you

5. Display Total Gift Aid [sum of Gift Aid, Other Gift Aid and Resources Reported by You.]

6. Display Work‐Study Name, Amount and Status

7. Display subsidized loans

8. Display unsubsidized loans

9. If FAFSA has been filed, Display EFC

10. Display Page Footer

11. Await changes in selections if applicable. If update button is clicked, invoke “Update Award”

[ID 8]

Sub‐flow(s)

2.1 Get gift aid where AWD.UserCd1=GF

2.2 Get description from award file (Where no long description exists, pull the short

description.)

2.3 Get offer amount (where offer is not 0)

2.4 Get origination status [This is modeled in logic table 2]

2.4.1 If Award Code is ACG1, ACG2, FSM3, FSM4, TECH, and



FLO.LOANSTAT=A, then set status to confirmed, otherwise set status to

“estimated”.

2.4.2 For Cal grants, if aid ID begins with X, set status to “estimated”, if aid ID

begins with C, set status to “confirmed”

2.4.3 If aid id starts with Z, set status to “conditional”

2.4.4 If no other condition exists, set status to “confirmed.”

3.1 Get awards where AWD.UserCd1 = GO, WV, OT or PS


description.)


3.4 Set status to confirmed

4.1 Get awards where AWD.UserCd1=SR

4.2 Get name from fixed AidID, or the entry from the outside resources screen, <long

description> tag.

4.3 Set status to “Report not yet received”

6.1 Get awards where AWD.UserCd1=WS


description.)


6.4 Where AidID starts Z, set status to conditional. Where 2nd character of AidID is W, set

status to “offered”. Else, set status to “referred”

7.1 Get awards where AWD.UserCd1=SL


description.)

7.3 If AidID begins with Z, set status to conditional. Do not show dropdown box (student

cannot accept a conditional loan.)

8.1 Get awards where AWD.UserCd1=VL/PL


description.)

8.3 If AidID begins with Z, set status to conditional. Do not show dropdown box. (student



cannot accept a conditional loan.)

10.1 If AidID SACH exits, add the following line to the footer: “Congratulations

Regents' and Chancellor's Scholar! Your Regents' and Chancellor's Scholarship is supported

by the generosity of donors who established the scholarships listed in your financial aid

package.”

10.2 If AidID SCOP exists, add the following line to the footer: “Congratulations Cal

Opportunity Scholar! Your Cal Opportunity Scholarship is supported by the generosity of

donors who established the scholarships listed in your financial aid package.”

10.3 If AidID SBUG exists, add the following line to the footer: “Congratulations

Berkeley Undergraduate Scholar! Your Berkeley Undergraduate Scholarship is supported by

the generosity of donors who established the scholarships listed in your financial aid

package.”

10.4 If the student has any AidIDs that begin with Z include “Your offer of Financial

Aid is unofficial and conditional on your completing additional steps. Please see the

messages page for information on what steps you must complete to receive an official

Financial Aid Offer.”

AlternateFlow

7.3 Otherwise, follow logic in table 3.

8.3 Otherwise, follow logic in table 4.


Page 40

Paul Heald. Sigma System

s, Inc.

1

2 3

4 5

6

Award Co

de is ACG

1, AGC2

, FSM

3, FSM

4, TEC

H

Y Y

N

N

N

N

Status of FLO

.LOAN

STAT

A

!A

‐ ‐

‐ ‐

Is a Califo

rnia Grant

‐ ‐

Y Y

N

N

First Letter o

f AidID

‐ ‐

X C

Z !X, !C,

!Z

Status set to

"Estim

ated

"

X X

Status Set to

"Co

ndition

al"

X

Status set to

"Co

nfirm

ed"

X

X

X

Logic Table 2

UC Be

rkeley’s Experience with

MyFinAid and Ku

ali

Paul Heald, Sigma System

s Inc.

Page 41

1

2 3

4 5

6

Status ((A)ccep

ted, (D

)eclined

) D

A A

A A

A

Accept Amou

nt

‐ 0

>0

>0

>0, < Offe

rAmou

nt

=Offe

rAmou

nt

Type

Aid

‐ ‐

B !B, !J, !L

J or L

J o

r L

Show

Status as "Declin

ed"

X

Show

Status as "Offered

"

X

Show

Status as "Co

nfim

ed"

Show

Status as "Ac

cepted

"

X

X X

X

Show

Accep

t/Declin

e Dropd

own

X X

X

Show

Entry Box

for smaller a

mou

nt

X

Show

accep

ted am

ount in

4th colum

n

X

Logic Table 3


Page 42


s, Inc.

1

2 3

4 5

6 7

Status

D A

A A

A A

A

Type

Aid

‐ C, H, D

, I,

5

C, H, D

, I,

5 ‐

‐ ‐

‐

AidID

‐ ‐

‐ ELOA

OLN

F/OLN

S Starts 'E' excep

t

ELOA

Starts

'E'

AcceptAm

ount

‐ 0

>0

‐ ‐

0 >0

Show

Declin

ed

X

Show

Offered

X

X

Show

Con

firmed

X

Show

Accep

ted

X

X

Show

Certified

X

Show

Dropd

own

X X

Show

Entry Box

X

Place

Nam

e in

4th

Column

X

Logic Table 4



Name Update Award ID 8

PrimaryActor(s)

Student

ShortDescription

Award changes are validated and submitted.

EventTrigger

Student clicks update having made changes to the award details.

Flow

1. Process subsidized loans

2. Process unsubsidized loans

3. Display any warnings

4. Update SAM records

5. Display result of triggered process.

Sub‐flow(s)

1.1 For loans being accepted, ensure accepted amount is between $100 and the offered

amount.

1.2 Record amount in <TotalAccepted> and Change <AcceptStatus> to A

1.3 For loans being declined, set <TotalAccepted> to 0 and <AcceptedStatus> to D

2.1 For loans being accepted, ensure accepted amount is between $100 and the offered

amount.

2.2 Record amount in <TotalAccepted> and Change <AcceptStatus> to A

2.3 For loans being declined, set <TotalAccepted> to 0 and <AcceptedStatus> to D

3.1 If any unsubsidized loans are accepted, display the message “If I become eligible for

Subsidized Loan, I authorize UC Berkeley to accept these loans on my behalf so long as



the total subsidized and unsubsidized loan amounts do not exceed the amount I have

accepted above”

3.2 Store total authorized (typeaid B, C, I, H, 5) in SAM.USERNR7

3.3. Store total unsubsidized (typeaid C,I, H, 5) in SAM.USERNR6

AlternateFlow

1.1 If out of range, flag warning. Do not process.

3.1 If not accepted, do not process.



Name Convert Loans to Work ID 9

PrimaryActor(s)

Student

ShortDescription

Student requests to make conversion. They may only convert in one direction; therefore entry into both

sides of the form is not possible.

EventTrigger

Student requests conversion.

Flow

1. Validate that student may make conversion.

2. Calculate the maximum available to convert7

3. Request “I wish to convert amount” from student. Input limited to the maximum calculated

in 2.

4. Check that student is sure.

5. Accept change, post new maximum work‐study amount to ProSAM.

6. Return updated results after triggered process.

Sub‐flow(s)

1.1 Ensure student has filed a FAFSA

1.2 Validate that section has not been disabled by FASO

1.3 Validate that the option is available to student by date

6.1 Get paid amount of subsidized loan

6.2 Get paid portion of need‐based unsubsidized loan

6.3 Add together, and display the message “$xxxx of your need‐based loan has already been

7 Calculation of this number is Berkeley specific. Original calculation is in Appendix C for completeness.



paid out that you can convert to work‐study if you are willing to be billed for it. Read

More8”.

AlternateFlow

1. Message that this is not possible and return user to home screen.

2. If this is less than zero, then display “You have no loans eligible to convert to Work‐Study.” Exit

back to home screen.

8 Read More hyperlinks to the Revise Loan Amounts page. where students can reduce their loan amounts in order to make them available for conversion..



Name Convert Work‐Study to Loan ID 10

PrimaryActor(s)

Student

ShortDescription

Student requests to make conversion. They may only convert in one direction; therefore entry into both

sides of the form is not possible.

EventTrigger

Student requests conversion.

Flow

1. Validate that student may make conversion.

2. Calculate the maximum available to convert to subsidized or any loan9

3. Request entry for the amount to convert, limited to the maximum available to convert.

Provide radial button for maximum subsidized amount.

4. Check that student is sure.

5. Trigger the request to ProSAM

6. Return result of triggered process.

Sub‐flow(s)

5.1 [if “Best Available…] Repackage the loan in the following order:

5.1.1 For independent students, Subsidized, Unsubsidized. If graduate, GradPLUS

5.1.2 For dependent students, Subsidized, Unsubsidized, parent PLUS

AlternateFlow

1. Message that this is not possible and return user to home screen.

9 Calculation of this number is Berkeley specific. Original calculation is in Appendix D for completeness.



3. If maximum available is $0, display the message “You have no work‐study available for

conversion.” Do not permit any entry into the entry box.

4. If entry is for subsidized loan, and amount requested exceeds the subsidized loan amount,

display “You do not have enough of this type of loan to make your request. Please choose

another loan type or revise your request”.

6. If student clicked the subsidized button, repackage as a subsidized loan.



Name Award Payment Status Screen ID 11

PrimaryActor(s)

User (any)

ShortDescription

Display payments and problems with payments if applicable.

EventTrigger

User accesses the screen.

Flow

1. Get calendar and current date information to ensure that only the appropriate awards are

being shown. [Spring should not show until December, etc.)

2. Get terms that have planned enrollments

3. Show aid for active terms (include the AidID description) where the accepted amount is

above $0, and the ProcResp = Y or Aidid begins G.

4. Show term breakdown of amount accepted and amount paid.

5. Moved these to messages paidReport Work‐Study earnings by getting individual payment

transactions. Display these in separate table of earnings including total offered, total

earned, amount remaining.

Sub‐flow(s)

AlternateFlow



Name Report other Resources ID 12

PrimaryActor(s)

Student

ShortDescription

Student is able to report other resources to the system.

EventTrigger

Student accesses the screen.

Flow

1. Display the awards that already exist in the package in columns by terms. Group the items

on a single line per the table in appendix E. Where awards are not listed in the table, list

each term as a separate line.

2. Display a dropdown box of all items in appendix E.

3. Once an award has been selected, allow student to enter a value of the award.

4. Once student hits submit, return award to the ProSAM system.

5. Return the results of triggered process.

6. Return student to My Net Cost screen.

Sub‐flow(s)

4.1 Add the following records to the XML return:

7.3.1 the AidID per table in appendix E (or XOFL/XOSP for other)

7.3.2 If “Other”, the Long Description

7.3.3 Total Offered, per student report

7.3.4 Set Total Accepted to Total Offered

AlternateFlow

3.1 If student selects other, allow student to enter name of resource [limit to 40 characters]

along with amount.



3.2 If the student selects an award that was already on the package [except for “Other”] do

not allow them to “add” a new award, rather modify the current award. Modifications are

not allowed for awards starting with W or O or numbers. Only for Awards starting with X.



Name Update Your Information ID 13

PrimaryActor(s)

Student

ShortDescription

Student updates

EventTrigger

User visits the appropriate logon portal.

Flow

1. Display expected graduation date.

2. Display current enrollment.

3. Display current housing situation

4. Display link to “Cancel my Financial Aid”

5. Display link to “Change Third Party Authorization” [hyperlink to Third Party Authorization

screen]

6. Display link to “Review Acknowledgements and Payment Authorization” [hyperlink to

Acknowledgements screen.

7. On update, trigger validation check, then update ProSAM

Sub‐flow(s)

7.1 If expected graduation date is changed, update in ProSAM

7.2 If planned enrolment is changed, update enrolment data with ProSAM. Trigger a

recalculation of EFC, rebudget, repackage.

7.3 If student changes house type, update SUT.HseTyp. Rebudget, Repackage.

AlternateFlow

3. If student is confirmed living with relative [SUT.Hold1 = LR] or SUT.HseType is C,N, D, A,M or E,



this value will be read‐only. These housing types indicate that housing for the term has been

confirmed independently by the Financial Aid and Scholarships Office



Name Display Missing Documents ID 14

PrimaryActor(s)

User (any)

ShortDescription

User can view list of financial aid documentation that is either missing or not reviewed.

EventTrigger

User accesses page.

Flow

1. Display missing documents

2. Display not‐reviewed documents

Sub‐flow(s)

1.1 Display long description of the documents with a blank date in the tracking module.

1.2 Display a hyperlink to the document download screen.

1.3 Display document count in left‐hand menu bar.

2.1 Display long description of the documents with a non‐blank date, and status code of “N”

AlternateFlow

2. If there are no documents returned by either 1 or 2, display “You have no missing documents at

this time”



Name Messages Screen ID 15

PrimaryActor(s)

User (any)

ShortDescription

Display messages from FASO based on type of student and dates

EventTrigger

User selects screen

Flow

1. Get messages from message matrix.

2. Filter by student type, status and date.

3. Display messages

4. Get all memo types “VR”, if sequence 201 exists, and <track><document>08 or 09 exists

with a status of N. Display the special memo type from the action screen.

5. Display the count of messages in the left menu bar.

Sub‐flow(s)

AlternateFlow

1. If there are no messages, display “you have no messages at this time.”



Name Revise Loan Amounts Screen ID 16

PrimaryActor(s)

Student

ShortDescription

Student can view and change loan amounts on their account.

EventTrigger

User selects screen.

Flow

1. Retrieve and display loans on the students account in the following order: GradPLUS,

Unsubsidized loan, Subsidized Direct loan, Perkins Loan, HPSL.

2. Display each loan description, amount, and disbursement date (from ADS record or ACT

record) for which both the paid amount and the accepted amount for the term is

greater than zero and the disbursement date for the loan is within the last 120 days.

[Note that we will need to treat the two fall and spring disbursements of academic year

loans separately due to the disbursement date issue)]

3. Validate that the student has made the best choice, or accepts that they have not.

4. Ensure that student is sure.

5. For non‐disbursed loans, follow subflow.

6. For disbursed loans, follow subflow.

Sub‐flow(s)

3.1 Where student changes lower‐loans before they change higher ones, display “You are

trying to reduce a loan with better terms than a loan you are choosing to keep. Do you

with to continue or go back and reduce the other loan?”

5.1 Send a transaction to ProSAM to update the accepted amount.

5.2 If the accepted amount is greater than zero, reduce the loan amount to the new



accepted amount and add another loan of the same type for the difference.

5.3 Display the resulting package on the award details screen

6.1 If the student enters a smaller amount or zero, display an “are you sure” message with

the warning “You will be billed for the loan you cancel or reduce and this amount will be

due to UC Berkeley immediately.”

6.2 If the student continues, send a transaction to ProSAM to update the accepted amount

(adding both terms together for academic year loan) and, if the accepted amount is

greater than zero, reduce the loan amount to the new accepted amount and add

another loan of the same type for the difference.

AlternateFlow



Name Manage My Loans ID 17

PrimaryActor(s)

User

ShortDescription

Display information relating to loans

EventTrigger

User requests page.

Flow

1. For undergraduates, display Subsidized Stafford Loan, Unsubsidized Stafford Loan, Perkins

Loan, Parent Plus Loan

2. For each type, display extended information.

Sub‐flow(s)

2.1 Date Master Promissory Note Completed (PromNoteSigDate).

2.2 Date MPN Expires

2.3 Date Entrance Counseling Completed (EntranceCounselDate) [Display N/A for Parent PLUS.]

2.4 Cumulative Debt amount (from History Award Screen).

2.5 Date Exit Counseling Completed (ExitCounselDate)

AlternateFlow

1. For graduates, display Subsidized Stafford Loan, Unsubsidized Stafford Loan, Perkins Loan,

HPSL and GraduatePLUS loan.

Future enhancement will display a total of private borrowing at Berkeley from the History Award Screen.



Name FERPA Screen ID 19

PrimaryActor(s)

User (any)

ShortDescription

User is given information relating to authorization of people on their account.

EventTrigger

User selects FERPA page.

Flow

1. Display “People you have authorized”

2. Display “People whose authorization you have revoked”

3. Display link to add another authorization.

4. Display Footer

Sub‐flow(s)

1.1 Scan PSN file, for all users with type FERPAn where Authorization = Y”

1.2 Display Person Name, Relationship and email

1.3 Display link to edit or revoke authorization.

2.1 Scan PSN file, for all users with type FERPAn where Authorization = R”

2.2 Display Person Name, Relationship and email

2.3 Display link to restore authorization.

3.1 If student chooses to add another authorization, display editable fields for Name,

Relationship and email.

3.2 Upon acceptance, return these values to SAM, with Authorization = Y



4.1 Check status of TrackDocument69.

4.2 If it exists, show the message “You have authorized another person through a paper form.

Please contact the financial aid office if you are unsure who you have previously authorized

to view your financial aid data.”

AlternateFlow

1.3.1 If student chooses to edit, provide editable fields, and return new values to SAM.

1.3.2 If student chooses to revoke, send back PSN.Authorization = Y

2.3.1 If student chooses to reauthorize, send back Authorization = N”



Name College Enrollment Verification Screen ID 20

PrimaryActor(s)

User (any)

ShortDescription

User is show college enrolment verification and verified other family members in college.

EventTrigger

User visits page. Link to page is not visible if students do not have document D3 in

TrackData/Documents.

Flow

1. Display Family Members You have verified are In college.

2. Display link to allow student to add other family members.

3. Display check box for “I am the only family member in college”

4. Display “OK”

Sub‐flow(s)

1.1 Display any PSN records with type A1 through A5.

1.2 Display the Name, Relationship, EnrolledCollege Date of Birth, AcademicLevel, and

GraduationDate; and PlannedDegree).

2.1 If additional family member is selected, display blank fields for Name, Relationship,

EnrolledCollege, Date of Birth, AcademicLevel, and GraduationDate; and Planned

Degree

2.2 Upon accepting changes, send back all the fields to update ProSAM

3.1 Once accepted, if checkbox for only student is checked, return 1 as

<FinancialData><NumberInCollege>, otherwise count through filled links A1‐A5, add

one, and return this value.



3.2 Trigger recalculation of EFC, and repackage.

a. Link back to home screen.

AlternateFlow



Name Summer Financial Aid Menu Item ID 21

PrimaryActor(s)

User (any)

ShortDescription

Link to summer financial aid.

EventTrigger

User selects item

Flow

1. Check that the summer aid system is available (by date)

2. Link to summeraid.berkeley.edu

Sub‐flow(s)

AlternateFlow

1.1 If session is not active, display message that summer system is unavailable.

1.2 Future Enhancement to Integrate Summer into ProSAM processing and display summer

information and allow award acceptance directly on MyFinAid (Summer 2011)

In future versions, this will work in much the same was as aid for other terms (going to a “My Net Cost” page).



Name Logoff ID 22

PrimaryActor(s)

User (any)

ShortDescription

Session is ended via logoff link.

EventTrigger

User clicks logoff.

Flow

1. Log off session.

2. Return user to splash screen.

Sub‐flow(s)

AlternateFlow



Name Choose a Student ID 23

PrimaryActor(s)

Third party users with more than one student authorization, Staff (both FASO and non‐FASO)

ShortDescription

For users who have access to more than one student, user can change view to a different student.

EventTrigger

User selects option (if available)

Flow

1. Entry box for SID is displayed

2. User selects student.

3.

Sub‐flow(s)

AlternateFlow

1.1 If user is a FASO, or other staff member, they may search for student via student id.

1.2 After selection, system verifies that this user has access to the records of the current

student. If not, warning is displayed.

1.3 Staff can then change student using the navigation bar, again only to students for which

they are authorized



Name Parent Loan (PLUS) Information Screen ID 24

PrimaryActor(s)

User (Any)

ShortDescription

Information relating to PLUS loans is displayed.

EventTrigger

User selects screen. The link is only available in the case of an offer amount being above zero on a PLUS

loan.

Flow

1. Get and display the following information about each PLUS loan (TypeAid=D) {Accepted

Status, BIS/PAF Receipt, MPN on File, Credit Check Results, Amount}

2. Show total of all loans.

3. Provide links to the MPN, and BIS/PAF

4. Where BIS/PAF is not available, provide link to fill out the form online.

Sub‐flow(s)

AlternateFlow

1. If credit is denied, link to Denies PLUS form.



NameBorrower Information Sheet/ Parental Authorization Form

Screen. ID 25

PrimaryActor(s)

Parent

ShortDescription

Parent fills out the BIS/PAF online.

EventTrigger

Selected from PLUS information screen.

Flow

1. User is provided with following fields {Name, SSN, date of birth, Citizenship, Default Status,

Authorized Amount and Payment Authorization.}

2. Set document types to “Missing” linked to this loan.

3. Return information to SAM

4. Allow form to be printed

5. Link amount accepted to appropriate borrower.

6. If Partial amount is accepted, repackage with second, unlinked loan for the difference.

7. Loans are only visible to relationships “Mother” and “Father” Detailed information on loans

linked to one parent are NOT visible to the other parent.

Sub‐flow(s)

AlternateFlow

1.1 Where payment authorization is “NO”, replace AidID PLUS with PLUSP.


Page 68


s, Inc.

AuthorizationsbyUser

10 Read‐Only Access

Student

Administrator

Staff (FASO)

Staff(Non‐FASO)

3rd Party

Log On/Off

Y

Y Y

Y Y

Term

s an

d Co

ndition

s

Y Y

RO

‐ Y

Loan

Autho

rization

Y

Y RO

10‐

‐

My Net Cost

Y

Y RO

RO

RO

Budget Details

Y

Y Y

Y Y

Budget Details by Term

Y Y

Y Y

Y

Award Details

Y

Y RO

RO

RO

Award Details by Term

Y Y

Y Y

Y

Convert Loa

ns to

Work

Y

Y RO

N

N

Convert W

ork to Loa

ns

Y

Y RO

N

N

Award Pa

ymen

t Status

Y

Y Y

Y Y

Repo

rt Other Resou

rces

Y

Y RO

RO

RO

UC Be

rkeley’s Experience with

MyFinAid and Ku

ali

Paul Heald, Sigma System

s Inc.

Page 69

11 Only whe

re delegate is the parent.

12 In

specific circum

stances, whe

re a stud

ent h

as m

ore than

one

role. For example, is a stud

ent the

mselves, and

has a child in

college.

13 In

specific circum

stances, whe

re a th

ird party is a delegate for m

ore than

one

stud

ent.

14 Only whe

re th

e de

legate is th

e parent.

Upd

ate Inform

ation

Y

Y N

N

N

Missing

Docum

ents

Y

Y Y

Y Y

Messages

Y

Y Y

Y Y

Revise Loa

n Am

ounts

Y

Y RO

N

N

Man

age Loan

s

Y Y

RO

N

N

Display SID

N

Y Y

Y N

Form

s

Y Y

RO

N

N

ParentPLUS Loan

s

N

Y RO

N

Y11

Select Stude

nt

Y1

2 Y

Y Y

Y13

FERP

A Au

thorizations

Y

Y RO

RO

RO

College

Enrolmen

t Verificatio

n

Y Y

RO

RO

Y

Summer Finan

cial Aid

Y

Y RO

Y

N

Complete BIS/PA

F

N

Y RO

N

Y14

"Act as S

tude

nt"

N

Y N

N

N



BasicModelofCommunicationoftheMyFinAidImplementation

Communication with systems outside of ProSAM have been omitted for clarity.



ScreenFlow



ScreenShotsofImplementation

The initial screen cascade ensures that users have agreed to the terms of the system before they can access further functionality of the system

The messages screen is displayed if there are no offers available, or if the student selects the messages option.



The My Net Cost screen is the usual entry point to the system, giving users an easy view of their financial aid package.

Award details allow the student to view awards, and accept loans. Triggered processes allow a student to accept a partial payment on a loan which results in another offered loan being created with the unused balance of the offered loan.



Award payment gives an overview of awards that have actually been paid.

Budget detail shows the student how their cost of attendance has been calculated given their personal circumstances.



College enrollment allows a student to report other family members who are in college.

Loan‐to‐work and work‐to‐loan conversions allow a student to move their aid between these two types of aid. The system has extra checks built in to ensure that only available (unworked) hours can be converted, and to counsel the student as to the best type of loan choice they can make.



FERPA Authorization allows a student to elect people who will have access to their student records, thus allowing the third party to communicate with the FASO directly.

The grant access screen allows a user to create a sub account to allow a third party limited access to their MyFinAid account.



Personal information can be changed directly by the student.

External resources (subject to validation) can be reported.



Where extra documentation is required to complete a financial aid package, the student is alerted and given links to the required documentation.

Administrators can “act as” another user. This feature allows a FASO officer to assist students and parents navigate the website if they are experiencing problems.



AboutKuali

Kuali is a project of the Kuali Foundation, a non‐profit corporation in the United States of America. The

foundation is overseeing and coordinating the production of open source educational administrative

software “for higher education, by higher education”15. Specific information relating to the Kuali project

can be found at www.kuali.org

The project, which is supported by several major U.S. universities, centers around a piece of

middleware, called Kuali Rice (KR). KR provides a framework for modular software development, and

communication between the many different enterprise systems that exist within the university setting.

In addition to KR, at present, the major components of the Kuali system are as follows16:

• Kuali Financial System (KFS)17

• Kuali Coeus (KC)‐ The research core of Kuali18

• Kuali Student (KS)‐ A student information system (SIS)19

• Kuali OLE‐ Library software20

• Kuali Ready‐ Disaster management package21

Throughout the MyFinAid project, the designers were aware that this software would eventually have to

become Kuali complaint. As such, certain design decisions were made in order to facilitate this

progression [such as the adoption of the Google Web Toolkit 2.0 (GWT) as part of the platform for

building the product].

This part of the documentation looks at some of the possible for future implementation when the Kuali

systems are deployed more widely.

15 Derived from the Kuali Foundation’s by‐laws document. 16 There are also a number of incubation projects, such as HR, knowledge management and materials management. 17 KFS can be found online at http://kuali.org/kfs 18 Coeus is the most recent update to the Kuali Research module. Information can be found at http://kuali.org/kc‐new 19 Kuali student information can be located at http://kuali.org/ks The student module contains a number of sub‐modules, many of which would contain information that is particularly useful to student financial aid. 20 Kuali OLE information can be found at http://kuali.org/ole 21 Kuali Ready information can be found at http://kuali.org/ready



TowardsaKuali‐ComplaintModel

Although at this moment, neither the MyFinAid product nor the ProSAM/SAM products are Kuali

compliant, this part of the document discusses the possibility of such a Kuali‐Ready Product. The Kuali

model will allow many aspects of the MyFinAid/ProSAM integration to be standardized, encouraging

even more integration between the two systems. Moreover, integration with the Kuali system will allow

superior functioning of the ProSAM system, as real‐time exchanges between the systems will allow for

more up‐to‐date information upon which to base decisions.

The current model of interaction between these systems is modeled here.

Current Systems Interaction Model

ProSAM receives batch data transfers from some legacy applications, as well as data transfers from (and

in some cases to) external systems (such as, for example, the Department of Education’s FAFSA system).

More modern applications within the university framework communicate via web‐services through the

IXS. The MyFinAid system also communicates with the ProSAM software through the use of the IXS.



MyFinAid also consumes services from the Campus‐Wide Authentication service (in the case of staff and

students)22.

This model works well, but it does have several drawbacks.

‐ Authentication for third parties is passed off to another system. In some cases, this could mean

that third parties have multiple delegate logons for different systems on the university campus.

‐ Data that is drawn from external systems is either done in batch fashion (and is therefore not

necessarily the most current data) or is done via web‐services which require each connector to

be written specifically for the external service in question.

‐ Didactic communication with legacy campus applications also suffers from these problems.

‐ Communications between systems have to be secured on an individual basis.

A Kuali‐Based System would have the following architecture:

Theoretical Kuali‐Based Architecture

22 3rd party (delegate) authentication is managed internally by the MyFinAid software.



ConsumptionofKualiResources

The benefit of the Kuali architecture is the ability to rely on resources and frameworks so that individual

applications do not have to continually reinvent the wheel every time they want to implement new

functionality, or, more importantly, build on other functionality.

ConsumingRiceSome of the most fundamental services that such integration will use are part of the Kuali Rice

middleware platform.

TheKualiEnterpriseServiceBus(KSB)Central to all communications in this model is the enterprise service bus. The enterprise service bus

gives all applications a standard conduit through which they can speak to each other. It abstracts away

the complexities of application‐to‐application communication. This will mean that no matter what

student system a university

plans to adopt, be it the Kuali

Student System, or some third‐

party student system that has

been made Kuali complaint, all

other applications will be coded

in the same way. This means

that a student system could be

replaced without having to

replace or update all the

systems that rely on it.

The service bus also takes care

of the security of

communication between Kuali‐

compliant applications on the

The Kuali Rice Enterprise Service Bus



bus. Not only does this mean that application programmers do not have to worry about security, it also

means that security updates can be rolled out enterprise wide without having to address each

application within the

enterprise.

The service bus defines XML as

the means of communication

between applications and the

service bus. The adoption of this

open standard means that

application writers will only

have to implement a single

method of internal

communication with the other

applications within the

enterprise system. This has a

number of important benefits,

not least of which is facilitating

the maintenance of code.

Because most, if not all

applications are connected

permanently to the service bus,

data does not have to be

retrieved from these systems in

batch processes. When

information is needed in the

ProSAM application, it can be

retrieved from the different

systems in real time, allowing

ProSAM to perform calculations

User:aUser Website:aSession

Logon Credentials

Logon

User Requests

Parsed Requests

Data UpdateValidated Update

Logoff

Logoff Request

ESB:anInstance

Sequence diagram showing the ESB (KSB). Notice that the application programmer only has to concern themselves with connecting to the ESB. All other requests to other systems are handled by the ESB. With this model, the application developer only needs worry about communication with the user and the service bus.

Sequence diagram showing the ESB (KSB). Notice that the application programmer only has to concern themselves with connecting to the ESB. All other requests to other systems are handled by the ESB. With this model, the application developer only needs worry about communication with the user and the service bus.



using the most up‐to‐date data available.

KualiIdentityManagement(KIM)KIM provides a standard way for users to be authenticated across the Kuali suite of applications. This will

include all direct actors within the university (professors, administrators, students, and other staff) and

could include other actors such as the third party delegates used by MyFinAid. There are many other

places in the university systems where externally credentialed users have a legitimate reason to

consume university services. A standard way to allow all of these different users to access services

appropriate to themselves is at the core of KIM.

Such technology will allow MyFinAid and the ProSAM applications to concentrate on their core activities,

rather than on functions such as identity management, allowing new functionality to be built more

quickly and more securely.

KualiEnterpriseWorkflow(KEW)In later revisions, standard enterprise workflow as provided by KEW could form the basis of the

workflow sequencing for the financial aid departments.

ConsumingtheKualiFinancialSystem(KFS)The KFS is a Kuali‐compliant financial system that takes care of standard financial matters such as

purchase ledger, etc. Messages on the KSB would be able to inform the KFS of deposits that are going to

be received from external sources.

ConsumingKualiStudent(KS)Kuali Student is the SIS that is being built specifically for the Kuali suite of applications. It contains a

number of applications that will be familiar to most university administrators, including curriculum

management, personal identity modules, enrolment information, admissions, grade information, and

student financials.

The ProSAM suite already consumes data from many different parts of the student information system,

from basic identity information, to course loads, enrolment data, etc. Much of this information comes

from batch uploads, meaning that the data may not be as current as it could be. With more direct access

to the student system, ProSAM will be able to give more accurate estimates of awards, and match

students to potential sources of financial aid more thoroughly. Instant access to grade data will allow



ProSAM to more easily make matches to academic‐progress related awards, and will reduce the need to

keep duplicate copies of data within both the SIS and within the ProSAM data store.

As the student financial system is part of the Kuali Student module, ProSAM will be able to easily update

student accounts with awards as they are accepted.

OtherBenefitsofUsingtheKualiFramework

In addition to the resources that Kuali makes available to application developers, there are also inherent

benefits to the open, modular design of the system. As technology continues to evolve, new ways of

accessing and consuming information will be found, and the requirements by the users for ever more

available information will continue. There are aspects of the MyFinAid package that could easily be

reused (or indeed, centralized) in a Kuali‐compliant institution. For example, the granting of access to

educational records under FERPA is of interest, not only to financial aid, but also to most other divisions

in an educational establishment. With standard modules to administer such authorizations, writers of

modules such as MyFinAid can concentrate on their core functionality.

Moreover, the Kuali framework allows applications to be developed in a fashion that allow easy

construction of access points without having to rebuild entire applications. Mobile computing is a

current trend that is showing no signs of abating, and as a new platform, it brings with it its own benefits

and challenges. Using the Kuali middleware, it will be much easier to build specific interface applications

for mobile devices (and whatever the future holds) without having to change existing enterprise

systems. This will allow ever more student choice and freedom.



Conclusions

The completion of the MyFinAid project was a major step forward for student self‐service at Berkeley.

Leveraging a number of new technologies, the system more accurately mimics the expectations of the

Berkeley student population. Allowing students to interact in real time while using an easy‐to‐use and

easy‐to‐understand interface, is simply an expectation of a generation who are used to using web 2.0

enabled applications for many aspects of their lives.

By providing easy online access to so much information and allowing students to perform so many of

their financial aid transactions online, the FASO staff are freed up to allow them to concentrate on the

less routine aspects of financial aid.

Time spent planning the design of this application was key. Ensuring that the actions of the software

matched the expectations of the user, and where the current implementation was not capable of giving

the user their expected result, the software had to be able to predict and warn the user of this outcome.

Tight coordination between Berkeley and the Sigma design team also ensured that the MyFinAid

product and the Sigma ProSAM product were integrated well, and that both programs were able to

understand each other better.

Many of the lessons learned from this project will be of broad use to not only other systems who wish to

integrate with the ProSAM suite, but also to other vendors who wish to move towards a more service‐

oriented model of software. With the Kuali set of products starting to come online at various institutions

around the country, this model is expected to proliferate in university‐based systems. The Kuali‐based

model will not only provide benefits for universities which adopt the systems, but with a proliferation of

software with clearly defined APIs based on open standards, increasing interoperability between many

more components of the university enterprise systems will become significantly easier.



AcronymsandAbbreviationsUsedinthisDocument

AJAX‐Asynchronous JavaScript and XML. The group of technologies on which the MyFinAid web pages

are written, allowing minimal page reloads when information in the application is changed.

API‐Application Programmer Interface. A defined way for programs to expose services to each other.

In ProSAM, the API is controlled via the IXS. Kuali‐compliant applications expose their services via

a connection to the enterprise service bus.

BatchProcessing‐Method of getting information between different systems by producing a batch

file and then loading that file into another system. This is the way in ProSAM sometimes has to

connect to legacy enterprise systems within an institution which were designed before the era of

web services, and real‐time transactions.

Berkeley‐ the University of California at Berkeley. The institution is variously referred to as UC

Berkeley and simply Berkeley throughout this document.

BIS‐ Borrower Information Sheet

CalNet‐ Single Sign‐On Implementation of CAS, adopted at Berkeley.

CAS‐ JA‐SIG sponsored open‐source authentication solution.

EFC‐ Expected Family Contribution

ESB‐ Enterprise service bus. Middleware that is implemented within the Kuali Rice module, allowing

applications to speak to each other.

FAFSA‐ Free Application for Federal Student Aid

FAO‐ Financial Aid Office

FASO‐ Financial Aid and Scholarships Office

FERPA‐ Family Education Rights and Privacy Act. Federal law that regulates the transfer and disclosure

of educational records.



GWT‐ Google Web Toolkit, foundation layer for Kuali applications. MyFinAid implements GWT 2.0,

which is the foundation for its AJAX functionality.

IXS‐ Integration eXchange Service, part of the ProSAM suite that enables XML‐based calls between

third‐party applications and the ProSAM database.

ISIR‐ Institutional Student Information Record. The record that the Department of Education returns

to an institution after a student files their FAFSA.

Kuali‐ Kuali is used in several ways in this document, but in general terms, it relates to the open‐

source project to produce administrative software for colleges and universities. See the specific

chapter relating to Kuali for more information, or visit www.kuali.org

KualiFinancialSystem(KFS)‐ General financial system, part of the Kuali suite of applications.

KualiRice (KR)‐ the middleware component of Kuali, that handles (among other things) identity

management (KIM), the service bus (KSB) and workflow (KEW).

KualiStudent(KS)‐ Kuali’s student information system [SIS]

Kuali‐Compliant‐ Software that is written specifically to interact with the Kuali Project’s framework.

KSB‐ Kuali Service Bus. The enterprise service bus implemented by the Kuali Rice project.

MPN‐ Master Promissory Note

MyFinAid‐ Berkeley’s implementation of student self service for financial aid.

PAF‐ Parental Authorization Form

ProSAM‐ See SAM/ProSAM

Real‐Time Processing‐ System of getting information in to an out of systems in “real time” as

opposed to batch processing. SAM uses the IXS to perform its real‐time data pushes and pulls.

The MyFinAid application performs most of its operations in real time, meaning that when a user

performs an action on the MyFinAid site, it is immediately reflected in ProSAM. Moreover, results



of the new data (including actions, such as repackaging) happen immediately, allowing the user

to see the results of their changes.

SAM/ ProSAM‐ The legacy version and current generation of Sigma Systems’ Student Aid

Management system . UCB was a user of the SAM product for many years before transitioning to

the ProSAM product line.

SME– Subject Matter Expert.

Sigma‐ Sigma Systems Inc., producer of the SAM and ProSAM suite, and collaborator on the MyFinAid

product.

SIS‐ Student Information System

SOA‐ Service Oriented Architecture

XML‐eXtensible Markup Language. An open standard for communications between applications. XML

is one of the adopted Kuali technologies, and is often used in web‐based applications. The

MyFinAid product communicates with ProSAM via the IXS using XML.



AppendixA:Budget Codes and Categories formyNet Cost Screen and

AnnualBudgetScreen

MyN

etC

ost

Cat

egor

y

Cod

e

Am

ount

Des

crip

tion

UG

G

ift

Aid

Sup

plem

enta

ry

Des

c fo

r A

nnua

l

Bud

get P

age

Special Budget

10 0 EAP Budget D

Health Insurance

11 698 EAP SHIP (UG) D

Health Insurance

12 966 EAP SHIP (Grad)

Special Budget

13 0 Consortium

Special Budget

14 0 UCDC Expenses

Special Budget

15 0 UCCS Budget

Living Expenses

AA 10113 Basic Living Expenses

Living Expenses

BA 18441 MFE Living Expenses-F/W

Living Expenses

BB 12992 MFE Living Expenses-S/S

Fees F1 19050 Fees - Fall 1stYr EWMBA Fees

Fees F2 21302 Fees - Spring 1stYr EWMBA Fees

Fees F3 16798 Fees - 2ndYr EWMBA Fees

Fees F4 14546 Fees - 3rdYr EWMBA Fees

Fees F5 5727 Fees - BUS ADM Fees

Fees F6 18526 Fees - Day MBA - Res Fees

Fees F7 16451 Fees - Day MBA - NR Fees

Fees F8 27234 Fees - HAAS MFE Fees

Fees F9 5727 Fees - Graduate Fees

Fees FA 5758 Fees - Entering JMP Fees



Fees FB 13474 Fees - Continuing JMP Fees

Fees FC 5742 Fees - JSP Fees

Fees FD 18533 Fees - Law Fees

Fees FE 24295 Fees - LLM Fees

Fees FF 11697 Fees - Optometry Fees

Fees FG 8699 Fees - Public Health Fees

Fees FH 8768 Fees - Public Policy Fees

Fees FM 7524 Non-Resident Fees - Grad Non-Resident

Tuition

Fees FN 6150 Non-Resident Fees - Prof Non-Resident

Tuition

Books and Supplies

GA 520 Books & Supplies - G/O Books &

Supplies

Books and Supplies

GB 660 Books & Supplies-JMP-1Yr Books &

Supplies

Books and Supplies

GC 330 Books & Supplies-JMP-2Yr Books &

Supplies

Books and Supplies

GD 550 Books & Supplies-JMP-3Yr Books &

Supplies

Books and Supplies

GL 748 Books & Supplies - Law Books &

Supplies

Books and Supplies

GM 1250 Books & Supplies - MBA Books &

Supplies

Living Expenses

IA 24112 UG Expenses - SISS - Yr

Living Expenses

IB 12056 UG Expenses - SISS -Fall

Living Expenses

IC 12055 UG Expenses - SISS -Spring

Living Expenses

ID 27068 Grad Expenses - SISS-Yr

Living Expenses

IE 13534 Grad Expenses-SISS -Fall

Living Expenses

IF 13534 Grad Expenses- SISS-Spring



Fees IG 30839 NR UG Tuition/Fees-SISS-Yr Fees

Fees IH 15420 NR UG Tuition/Fees-SISS-Fal Fees

Fees II 15419 NR UG Tuition/Fees-SISS-Spr Fees

Fees IJ 26154 NR GRD Tuition/Fees-SISS-Yr Fees

Fees IK 13077 NR GRD Tuition/Fees-SISS-Fl Fees

Fees IL 13077 NR GRD Tuition/Fees-SISS-SP Fees

NE 0 Not Enrolled

Other Expenses

OE 2160 Optometry Equipment

Special Budget

S0 0 EAP Budget - Summer

Special Budget

S1 0 EAP SHIP (UG) - Summer

Special Budget

S2 0 EAP SHIP (Grad) - Summer

Special Budget

S3 0 Consortium - Summer

Special Budget

S4 0 UCDC Expenses - Summer

Special Budget

S5 0 UCCS Budget - Summer

Living Expenses

S6 0 Living Expenses - Summer

Fees S7 0 Fees - Summer Fees

Other Expenses

S8 0 Work-Study Allow -Summer

Other Expenses

S9 0 Special Budget - Summer

Other Expenses

SA 0 Special Add-on - Summer

Living Expenses

U0 7192 Room & Board - On-Campus D Housing

Living Expenses

U1 3771 Rent & Utility -Off-Campus D Housing

Living U2 1236 Rent & Utility -Live w/Relatives D Housing



Expenses Living Expenses

U3 462 Food - On-Campus D Food

Living Expenses

U4 1247 Food - Off-Campus D Food

Living Expenses

U5 903 Food - Live w/Relatives D Food

Books and Supplies

U6 653 Books & Supplies D Books &

Supplies

Living Expenses

U7 668 Personal - On-Campus D Personal

Living Expenses

U8 737 Personal - Off-Campus D Personal

Expenses

Living Expenses

U9 928 Personal - Live w/Relatives D Personal

Expenses

Living Expenses

UA 307 Transportation-On-Campus D Transportation

Living Expenses

UB 515 Transportation-Off Campus D Transportation

Living Expenses

UC 973 Transportation-Live W/Relatives D Transportation

Fees UF 4761 Fees D Fees

Fees UH 834 Fall Extension Fees Fees

Fees UM 11383 Non-Resident Tuition Schol D Non-Resident

Tuition

Fees UN 11383 Non-Resident Fees Non-Resident

Tuition

Health Insurance

X1 966 Health Insurance - Grad Health

Insurance

Health Insurance

X2 698 Health Insurance - UG D Health

Insurance

Other Expenses

X3 122 Loan Fees - Grad Loan Fees

Other Expenses

X4 48 Loan Fees - UG Loan Fees



Other Expenses

Z0 0 Computer Purchases

Other Expenses

Z1 0 Computer Hardware

Other Expenses

Z2 0 Computer Software

Living Expenses

Z3 0 Additional Rent/Utilities

Other Expenses

Z4 0 Travel Home Expense

Other Expenses

Z5 0 Uninsured Med/Dental

Living Expenses

Z6 0 Additional Transportation

Other Expenses

Z7 0 Research/Fieldwork

Other Expenses

Z8 0 Child Care Allowances

Other Expenses

Z9 0 Relocating Expenses

Other Expenses

ZA 0 Dep Care Allowances

Books and Supplies

ZB 0 Additional Books & Supplies

Other Expenses

ZC 0 Home/Renter's Insurance

Other Expenses

ZD 0 Additional Medical Insurance

Living Expenses

ZE 0 Family Housing Housing

Living Expenses

ZF 0 Family Housing -School D Housing

Other Expenses

ZG 0 Special Budget

Other ZH 0 Special Add-on



Expenses Fees ZI 0 Fees - Law Joint

Other Expenses

ZR 0 Research Expenses RC Sch D



AppendixB:DataDescriptionsforMyNetCostScreen

(Note that some of these data elements are Berkeley specific, but many are standard parts of the SAM

system.)

LevelofStudy: based on SUT.User3 (U or G)

Dependency: based on SAM.DepStat (D for Dependent, I for Independent).

Livingsituation: based on SUT.HseTyp (Uor D = living on‐campus, O or N = Living off‐campus, P or R or

C = Living With Relatives, W or M On‐Campus Apartment, A or V Family Housing, E Education Abroad).

Enrollment: based on SAMs/Planned Enrollment flags (if ??YNY?, then Fall and Spring, if ??YNN? then

Fall, if ??NNY? then Spring; We will have a separate section we have not designed yet for summer).

EstimatedGraduationDate: BIO/ExpGrad

FERPARelease:

If no document FERPA Document (Document 69)<TrackData><Documents> exists, and there is

no PSN record with type “FERPAn”<RelationshipData><Type> where Type = F1,F2,F3,F4,orF5

(Where n is a number 1 through 5) exists display “No one authorized for FERPA Information

Release”

If document FERPA Document (Document 69) exists and/or there is a PSN record with type

FERPAn, <RelationshipData><Type> where Type = F1,F2,F3,F4,orF5 display “FERPA Info Release

Authorized, go to FERPA Authorization Page for details.

MyUCBerkeleyCosts: See categorization of budget codes in Appendix. Display only Fall and Spring

terms for which there is planned enrollment on MyNetCost screen.

HealthInsurance:

If no WHIF/WHIS (Waiver of Health Insurance) award on the package, show budget components for

health insurance (X1,X2,11,12,S1,S2) .



If AIDID WHIF/WHIS on the package, show “waived” and do not include the health insurance in

the total cost.

If XHIF/XHIS (Assumed Health Insurance Placeholder) with Offer Amt > 0 on the package, add a

note to the bottom of the page: “If you choose to waive out of the University Student Health

Insurance program, this amount will be deducted from your student budget. If you do not

choose to waive out, the Financial Aid Office will offer you additional aid for this cost once the

waiver deadline has passed for the term.” .

Term Differences for students enrolled Fall and Spring: If one term of WHI…and one term of

XHI… exist, show the amount of the XHI.. and the message at the bottom of the page from

previous paragraph. If one term of WHI… exists and no XHI… on the package show one term of

Health Insurance Cost in the budget only.

Books&Supplies: Books and Supplies budget component (GA‐GM, U6).

LivingExpenses: Transportation + Personal + Housing + Food components of budget

Other: All other budget components (includes loan fees and add‐ons – see ranges in Budget Detail

Screen section below).

TotalUCBerkeleyCost: Total of All Budget Components (adjusted for Health Insurance as noted

above) and a link to the Budget Details screen.

MyGiftAid: Sum of all offer amounts for awards with AWD UserCd1 GF or GO or WV or OT or SR (Less

Health Insurance Cost: Show this line only if there is XHIF/XHIS with Offer Amt > 0 on the award package

– sum of XHIF/XHIS.)

MyNetCost: My UC Berkeley Cost minus My Gift Aid minus sum of XHIF/XHIS.

Parent(s)’Share – Sum of Offer Amounts for Awards with AWD UserCd1 PL or PS

Student’sLoanandWork – Sum of all offer amounts for Awards with AWD UserCd1 WS or UL or SL

TotalResourcestoMeetMyNetCost = Parent(s)’ Share plus Student’s Loan and Work

TotalResourcestomeetMyUCBerkeleyCosts: My Gift Aid + Total Resources to Meet My Net Cost



AppendixC:CalculationofNeed‐BasedAvailability

Much of this calculation is specific to Berkeley codes. It has been included in its original form for

completeness.

The maximum is the lesser of these three variables [unless less than zero].

Need‐BasedAvailability1. Get the total unpaid portion of Subsidized Loan for Fall and Spring (Sum of Offer Amount –

PaidAmt/.995 ) where AWD UserCd1 equal SL .

2. Add the total unpaid portion of Need‐Based Unsubsidized loans (Sum of Offer Amount TypeAid

C, I and H minus EFC –Sum of Paid Amount /.995 TypeAid C, I, and H) .

3. Add Unaccepted Need‐Based PLUS(OfferAmt‐Accepted Amount of TypeAid=D minus EFC minus

Need‐Based Unsubsidized) .

4. plus Unmet Need

Work‐StudyInitialMaximumIf No Work‐study (TypeAid W) in Current Package, or If Work‐Study Paid Amount <70% of Work‐Study

Offer) ‐‐ Work Study Initial Maximum (constant set by UG/Grad Annually)

Work‐StudyAdditionalMaximumIf Work‐study Offer> $0 and Work‐study Paid Amount >= 70% of Work‐Study Offer Amount – Workstudy

Additional Maximum (constant set by UG/Grad Annually)



AppendixD:Work‐StudyMaximumConversionCalculations

�

SubsidizedAmount: If ASUB is on package $0, otherwise Subsidized Loan Annual Limit for Class Level

– Current Subsidized Loan Offer (TypeAid = B).

UnsubsidizedAmount: If AUSB is on package $0, otherwise Unsubsidized + Subsidized Loan Annual

Limit for Class Level – Current Sub Loan Offer (TypeAid = B)‐ Current Unsub Loan Offer(TypeAid = C or H)

CalculateMaximumAmountforIndependentStudentsTake the lesser of

‐ Unearned Work‐study (Sum of Offer Amounts with TypeAid = W, less Sum of Paid Amounts with

TypeAid=W).

‐ Subsidized Amount plus Unsubsidized Amount

CalculateMaximumAmountforDependentStudents

Maximum Conversion for Dependent Students is Unearned Work‐study.

For the “subsidized only” radio button show the lesser of:

‐ Unearned work‐study .

‐ Subsidized amount.



AppendixE:TypesofSelfReportedResources

Self‐Reported Aidids

to send and display

Actual Award

Aidids to display

Description Fall Spring Fall Spring UG Grad California Alumni Association XALF XALS T F Cal Veterans Waiver XCVF XCVS WVEF WVES T F Americorps XAMF XAMS OAMF OAMS T T Robert Byrd Scholarship XBYF XBYS OBDF

OBOF

OBDS

OBOS

T F

Chaffee Grant XCHF XCHS OCHF OCHS T F California Scholarshare XCSF XCSS OCSF OCSS T F Gates Millennium Scholarship XGAF XGAS OGMF OGMS T T Department Scholarship XDPF XDPS T T California Governors Award XGOF XGOS OGSF OGSS T F National Merit XNMF XNMS ONMF ONMS T F GearUP Award XGUF XGUS OGUF OGUS T F Graduate Fellowship XGFF XGFS F T RA/TA Fee Remission XGRF XGRS F T Voc Rehab Benefits XRHF XRHS T41F T41S T T Veterans Benefits XVTF XVTS VETB VETB T T



AppendixF:ProjectCharterfortheSAMtoProSAMConversion

The MyFinAid project was created as part of the transition from SAM to ProSAM at Berkeley.

A. General Information

Project Title: SAM to ProSAM Conversion – Replacing Berkeley’s Legacy Financial Aid System

Brief Project Description:

Transition Berkeley’s student financial aid system from the mainframe SAMS system to ProSAM on servers using vendor software

Prepared By: Jon Conhaim

Date: April 26, 2009 Version: 2.0 Revised

B. Project Objective: Explain the specific objectives of the project. For example: What value does this project add to the organization? How does this project align with the strategic priorities of the organization? What results are expected? What are the deliverables? What benefits will be realized? What problems will be resolved?

Value Added: The new ProSAM system will: be easier to learn for staff and students; provide enhanced reporting; provide additional diagnostic tools; and allow awards to be based on unique academic terms rather than the standard academic year. It will automate some regulatory compliance activities which must now be conducted on a case by case basis. It will streamline mandated student advising activities such as debt counseling so that staff can allocate time to other priorities. It will incorporate some stand‐alone financial aid systems into the principal financial aid system thus reducing Financial Aid and Scholarships Office (FASO) systems maintenance effort.

Strategic Priority Alignment: This conversion is consistent with a goal in the IT Strategic Plan of enhancing the student experience from prospect through alumnus. Although not developed in Service Oriented Architecture (SOA) at this time, ProSAM is consistent with Student Services 2012 goals that envision a hybrid technical environment including open source student systems developed through the Kuali consortium and proprietary systems such as ProSAM.

Expected Results: All functions of the current Classic SAM system are maintained (and, in some cases, upgraded) in the ProSAM system and there are new functions in the ProSAM system that will allow



staff to deliver services to students and parents more expeditiously and with less staff effort. The resulting efficiencies will allow the FASO to support the $300 m in additional undergraduate scholarship funds raised by The Undergraduate Scholarship Campaign for UC Berkeley. In addition, ProSAM will support the reporting of all undergraduate and graduate awards to the Office of the President. The ProSAM system, with all the new functions, will be implemented in test by June 2009. ProSAM will be in production by January 2010 for 2010‐2011 academic year. By January 2012 the FASO will retire the 2008‐2009 and 2009‐2010 academic year processes on the Classic SAM system and will be fully off the mainframe.

Deliverables: The financial aid modules and functions as described in the Statement of Work with Sigma Systems Inc., the roster of the Interface Committees, and other related documents.

Benefits Realized: Improved student web services and additional functionality for staff; faster staff learning and training; diagnostic reports to identify reasons why some process has not occurred for a student or group of students; ability to award and transfer awards to Billing and Payment Services (BPS) in individual cases requiring exceptional expedited services; better ability to aid students who enroll for a single semester or students who are in programs with a unique calendar; processes that now require individual review replaced with automated processes; stand alone systems including verification system, the cancel/withdrawal aid eligibility system (R2T4), and portions of the summer system will be replaced with those included in basic ProSAM system; legacy mainframe system retired.

Problems Resolved: The legacy Classic SAM system has become increasingly complex in the way it presents required information to staff. Many current FASO and IST staff who maintain the Classic SAM system are nearing retirement; it will be/is more efficient to train new staff on the ProSAM system. FOCUS and CICS licenses, both required for Classic SAM operation on the mainframe, are becoming increasingly expensive; moving FASO operations to the server environment will help facilitate the mainframe abatement for the campus.

C. Assumptions List and describe the assumptions made in the decision to charter this project. Please note that all assumptions must be validated to ensure that the project stays on schedule and on budget.



• UC Berkeley must move its various systems off of the IST mainframe.

• The current mainframe financial aid system, SAMS (aka the Classic SAM system) was installed in production in 1982. Current server based architecture is cheaper and more efficient.

• Since Sigma Systems Inc. has been a reliable vendor and partner with FASO on the SAM project for over 25 years, there is every expectation that it will continue to be so on the ProSAM product.

• The transition to ProSAM will allow the FASO to examine and improve its own business practices as is appropriate within the scope of the project and encourage the offices with which it exchanges data to examine theirs as well.

• Interface systems currently feeding to SAMS will be able to meet the expected timelines with the changes necessary for ProSAM to go into production in January 2010.

D. Project Scope Describe the scope of the project. The project scope establishes the boundaries of the project. It identifies the limits of the project and defines the deliverables.

• The ProSAM project will install a new student (graduate and undergraduate) financial

aid system at Berkeley which annually provides over 20,000 students with $450,000,000 in student financial aid. Specifically it will include (but is not limited to) the following modules: Audit, Budget, Correspondence/Web Services, Diagnostics, Disbursements, Funds Management, ISIR load, Locksmith (Security), Loan processing, Memoranda, Pell/ACG/Smart/Teach Grants Awarding, Packaging and Repackaging, Return to Title IV (R2T4) processing, State Grant Awarding, Summer Session Awarding, and Verification/Compliance. It will also include improved interfaces with the following systems: Billing and Payment Services (BPS), Graduate Admissions, Graduate Award, Law/LLM Admissions, OP reporting, Registrar’s systems, and Undergraduate Admissions. Sigma Systems Inc. and FASO senior staff will provide training for staff.

• The ProSAM project will include: business practice review and revision; modifications to Sigma Systems Inc. and campus software; and training and documentation for IST & FASO systems staff.

• The ProSAM project will limit the modifications to the data interfaces with other campus information systems while ensuring that they maintain the current level of exchange of data and associated functionality currently available. Other mandated



federal/state/system wide changes to regulations and policies will also be incorporated.

List any requirements that are specifically excluded from the scope.

• The ProSAM conversion will not modify the various Admissions, Registration, Billing and Payment Services (BPS), Residential Life, or Data Warehouse systems, although the interfaces will be modified to maintain the current level of exchange of data and associated functionality. As a result of the business practices review which accompanies the ProSAM installation, managers of these other systems may choose to modify, simplify and streamline their processes to better serve students, faculty and staff.

• The ProSAM project will not be SOA compliant at the time the system goes into production for the 2010‐11 academic year beginning in January 2010.

E. Revised Project Milestones (Revised April 26, 2009) List the major milestones and deliverables of the project.

Milestone Approved Completion Date

1 ISIR ‐ Phase I December 19, 2008

2 Evaluation (Budget) December 19, 2008

3 Subversion Code Management System January 21, 2009

4 QA Environment Available January 29, 2009

5 Funds Management January 30, 2009

6 Interface Assessment & Scheduling February 15, 2009

7 Correspondence November 20, 2009

8 Verification June 1, 2009

9 R2T4 October 30, 2009

10 Diagnostics November 25, 2009

11 NSLDS/HAW September 11, 2009

12 Pell/ACG/SMART COD Process June 1, 2009



Milestone Approved Completion Date

13 Packaging & Re‐packaging September 11, 2009

14 Summer Session December 15, 2009

15 Loan Processing COD Process June 30, 2009

16 ISIR ‐ Phase II June 30, 2009

17 Locksmith (including CAS compliant) October 30, 2009

18 Disbursements October 30, 2009

19 Grant/CSAC Reporting August 31, 2009

20 FISAP November 25, 2009

21 Production Environment Available September 25, 2009

22 Audit October 30, 2009

23 Hyperion Reports & PL/SQL November 24, 2009

24 Disbursements and CARS Interface Testing November 25, 2009

25 Launch ProSAM Service January 4, 2010

26 Launch Web Self‐Service March 1, 2010

27 ImageNow March 1, 2010

28 Production Load Testing TBD

29 Group 1 Interfaces December 30, 2009

30 Group 2 Interfaces June 30, 2010

C. Impact Statement List the impact this project may have on existing systems or units.

Potential Impact Systems / Units Impacted

Better Coordination of Graduate financial aid Graduate Division



Increase Frequency of updates for students accounts

Billing and Payment Services; General Ledger

Move toward real time synchronicity of undergraduate admissions, graduate admissions and awards, financial aid, registrar, CARS, and other systems

Undergraduate Admissions, Graduate Admissions, School of Law/LLM Admissions, Registration, campus census, College and Departmental Advising, CARS, University Relations, California Alumni Association, Intercollegiate Athletics

Decrease load on Mainframe IST Mainframe being shut down

Increase load on Oracle Servers Explore with IST consequences of increased load

D. Roles and Responsibilities Describe the roles and responsibilities of project team members followed by the names and contact information for those filling the roles. The table below gives some generic descriptions. Modify, overwrite, and add to these examples to accurately describe the roles and responsibilities for this project. Overall Sponsor: Provides overall direction on the project. Responsibilities include: approve the project charter and plan; secure resources for the project; confirm the project’s goals and objectives; keep abreast of major project activities; make decisions on escalated issues; and assist in the resolution of roadblocks.

Name Email / Phone

Vice Chancellor Harry LeGrande [email protected] / (510) 642‐6727

AVC and CIO Shelton Waggener [email protected] / (510) 642‐4096

ProSAM Sponsor

Name Email / Phone

Cheryl Resh [email protected] / (510) 642‐0645

Project Manager: Leads in the planning and development of the project; manages the project to scope. Responsibilities include: develop the project plan; identify project deliverables; identify risks and develop risk management plan; direct the project resources (team



members); scope control and change management; oversee quality assurance of the project management process; maintain all documentation including the project plan; report and forecast project status; resolve conflicts within the project or between cross‐functional teams; ensure that the project’s product meets the business objectives; and communicate project status to stakeholders.

Name Email / Phone

Jon Conhaim [email protected] / (510) 643‐2255

Team Member: Works toward the deliverables of the project. Responsibilities include: understand the work to be completed; complete research, data gathering, analysis, and documentation as outlined in the project plan; inform the project manager of issues, scope changes, and risk and quality concerns; proactively communicate status; and manage expectations.

Name Email / Phone

FASO Staff:

Roberta Johnson [email protected] / (510) 642‐6819

Olga Tapia [email protected] / (510) 642‐6442

Karen Rice [email protected] / (510) 642‐3789

Rachel Dubois [email protected] / (510) 643‐3768

Jennifer French [email protected] / (510) 642‐9027

Leslie Wills [email protected] / (510) 643‐8356

Adrienne Fong [email protected] / (510) 642‐8990

John Choppy [email protected] / (510) 642‐0485

Rebecca Lewis Davis [email protected] / (510) 643‐9158

Dave Williams [email protected] / (510) 642‐6872

Aaron Resendez [email protected] / (510) 642‐8116

Rochelle Rawls‐Shaw [email protected] / (510) 642‐8449

IST staff:



George Suennen [email protected] / (510) 643‐8450

Veronica Burke [email protected] / (510) 642‐7208

Walt Hagmaier [email protected] / (510) 643‐8609

Karen Kato [email protected] / (510) 643‐3371

Don MacLeod [email protected] / (510) 643‐2800

Caprice Elias [email protected] / (510) 643‐0337

Customer: The person or department requesting the deliverable. Responsibilities include: partner with the sponsor or project manager to create the Project Charter; partner with the project manager to manage the project including the timeline, work plan, testing, resources, training, and documentation of procedures; work with the project team to identify the technical approach to be used and the deliverables to be furnished at the completion of the project; provide a clear definition of the business objective; sign‐off on project deliverables; take ownership of the developed process and software.

Name Email / Phone

Financial Aid and Scholarships Office [email protected] / (510) 642‐6442

Subject Matter Expert: Provides expertise on a specific subject. Responsibilities include: maintain up‐to‐date experience and knowledge on the subject matter; and provide advice on what is critical to the performance of a project task and what is nice‐to‐know.

Name Email / Phone

Financial Aid and Scholarships Office

Meg Fink [email protected] / (510) 642‐8443

Tuan Nguyen [email protected] / (510) 643‐6216

Rachelle Feldman [email protected] / (510) 642‐1360

Kyaw Win [email protected] / (510) 642‐0160

Graduate Admissions



Betsy Livak

Michael Wong

[email protected] / (510) 643‐7476


Graduate Awards

Betsy Livak

Dennis Andersen



Registrar’s Office

Anne De Luca

Walter Wong



Undergraduate Admissions

Brian Peterson

Pam Ziehe



Billing and Payment Services

Debbie Kallman

Mindy Lopez



E. Resources Identify the initial funding, personnel, and other resources committed to this project by the project sponsor.

Resource Constraints Year One‐ $600,000 Subject to meeting project goals Year Two $760,158 Subject to budget availability Year Three $651,927 Subject to budget availability F. Project Risks Identify the high‐level project risks and the strategies to mitigate them.

Risk Mitigation Strategy

ProSAM does not deliver aid as advertised

Extensive reference checks of other ProSAM users (one user, University of Kentucky, is satisfied with the system). Complete compliance with purchasing requirement



ProSAM requires additional machine capability

Current IST/Sigma Systems Inc/FASO discussions indicate compliance with projected machine capacity

ProSAM not delivered on time and within budget

Comply with all TPO requirements. Regular assessments with PSSC and regular reports to senior decision makers should new risks emerge

Sigma Systems Inc. does not deliver as contracted

Fully comply with all purchasing and payment procedures

Three critical retired contractors not extended because of new University Policy

Comment on draft policy limiting retired contractors to one year or 1000 hours.

Student Systems technological environments are in flux (i.e. Sun ID, Kuali, data warehouse, Hyperion) which can cause contention between projects, competition for resources, and shifting integration requirements

The ProSAM project manager and the rest of the project team will consult with the Director of Student Systems and monitor the progress of other Student Services 2012 projects. The Project manager in consultation with the project team will identify opportunities to align ProSAM with other student systems as is consistent with the scope of the project. Identified opportunities will be brought to the Sponsor and PSSC for review as well as all levels of the Student Systems 2012 Governance as deemed appropriate by the Sponsor.

G. Success Measurements Identify metric and target you are trying to achieve as a result of this project. For example, overall cost savings of $50K or reduce processing time by 25 percent.

• Begin operation of ProSAM system in January of 2010 for the 2010‐2011 academic year. • Deliver financial aid to students within current census deadlines. • Enroll the undergraduate student body within goals of Faculty Committee on

Undergraduate Scholarships and Honors, Undergraduate Admissions Coordination Board and Faculty Senate Admissions, Enrollment and Preparatory Education Committee.

• Enroll Graduate students consistent with Goals of the Graduate Division. • Deliver each individual aid program within rules/regulations/terms of that aid program. • Continue to work toward and support the campus goal of maintaining the proportion of

low and middle income students currently on financial aid. • Meet the inevitable additional demands of a constantly changing regulatory and

educational environment. • Support the requirements of new undergraduate scholarships raised as part of The

Campaign for Berkeley.



H. Signatures The signatures of the people below document approval of the formal Project Charter. The project manager is empowered by this charter to proceed with the project as outlined in the charter.

Name Signature Date

Executive Project Sponsors:

Harry LeGrande

Shelton Waggener

ProSAM Sponsor:

Cheryl Resh

Project Manager:

Jon Conhaim



SelectedBibliography

Blaine, Christine, et al. (2007) Information Technology at UC Berkeley: The Student Experience. UC

Berkeley Document. Available from http://hrweb.berkeley.edu/ldp/07infotechnology.pdf

Conhaim, Jon (2009) SAM to ProSAM Conversion – Replacing Berkeley’s Legacy Financial Aid System. UC

Berkeley Document. Available from https://bspace.berkeley.edu/access/content/group/55b8a497‐677a‐

48de‐00c6‐517e84196fd9/SS2012_wiki_files/ProSAMProject_Charter_2_0.doc

Feldman et al. (2009) Financial Aid Web Self Service: Software Requirement Specifications. UC Berkeley

Internal Document.

Kuali Foundation (2006) Bylaws. Accessed online 10/8/2010. http://kuali.org/bylaws

Sigma Systems (2010) Integration Exchange Service Technical Reference. Sigma Systems Internal

Document

Sigma Systems (2010) Understanding Sigma System’s ProSAM Solution Suite Architecture. Sigma

Systems Internal Document.

Tapscott, Don (1997) Growing Up Digital: The Rise of the Net Generation. McGraw‐Hill.