University of Portland
Donald P. Shiley School of Engineering
5000 N. Willamette Blvd.
Portland, OR 97203-5798
Phone 503 943 7314
Fax 503 943 7316
Final Report
AdviseUP Mark II: Web-based scheduling and
advising application
Team Members:
Kekai Ariola (Spring Team Lead)
Eric Bergquist (Fall Team Lead)
Megan Yamamoto
Industry Representatives:
Brian Toole (WAS)
Sam Burich (Concordia University)
Faculty Advisors:
Dr. Tammy VanDeGrift
Other Contributors:
Dr. Kenneth Lulay (Client)
Ronan Cranley (IS Infrastructure)
Jacob Caniparoli (WAS)
University of Portland
Donald P. Shiley School of Engineering
Contact: Eric Bergquist
FINAL REPORT
TEAM HOPWORKS
REV. 0.95
PAGE 2
Table of Contents
INTRODUCTION .................................................................................................................................3
CONTEXT ...........................................................................................................................................4
TECHNICAL OUTCOMES ......................................................................................................................4
OVERVIEW ................................................................................................................................................... 4
SCREENSHOTS OF INTERFACE MODIFICATIONS .................................................................................................... 6
PROCESSOR AND DATABASE .......................................................................................................................... 16
PROCESS OUTCOMES ....................................................................................................................... 18
PROJECT REQUIREMENTS .............................................................................................................................. 18
MILESTONES ............................................................................................................................................... 19
BUDGET ..................................................................................................................................................... 21
UNFORESEEN TIME EXPECTATIONS ................................................................................................................. 21
RISKS REVISITED .......................................................................................................................................... 23
USER TESTING ............................................................................................................................................. 24
CLIENT RESPONSE ........................................................................................................................................ 24
POSSIBLE ADDITIONS TO APPLICATION ............................................................................................................ 24
CONCLUSION ................................................................................................................................... 25
ACKNOWLEDGEMENTS .................................................................................................................... 26
REFERENCES .................................................................................................................................... 27
APPENDIX A: ADVISEE USER TEST ..................................................................................................... 28
APPENDIX B: ADVISEE USER SURVEY ................................................................................................ 29
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: KEKAI ARIOLA
FINAL REPORT
TEAM HOPWORKS
REV. 0.95
PAGE 3
Introduction
AdviseUP is a web-based academic planning tool intended to assist in the advising process for advisors
and advisees at the University of Portland. AdviseUP allows advisees to plan their 4 or 5 year academic
schedule and store it in the application so that it can be accessed by their advisor. AdviseUP also checks
course completion for courses in past semesters in the academic plan and prerequisite/co-requisite
requirements for all courses in the academic plan. The results of these checks are displayed visually,
allowing users to quickly and easily spot problems.
Team Hopworks chose to work on AdviseUP because of its potential to be adopted and used by advisees
and advisors at the University of Portland. AdviseUP was originally created by Team Foxfire for a faculty
client in the School of Engineering. They created a great final product that was not fully useable. Team
Hopworks expanded AdviseUP to include the features necessary for widespread use at University of
Portland. AdviseUP is an application that can greatly assist the advisees at University of Portland in
planning their academic schedules and assist the advising process.
Figure 1 illustrates the typical view of the application for an advisee when viewing his/her schedule.
Figure 1: Screenshot of Application (Advisee)
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: KEKAI ARIOLA
FINAL REPORT
TEAM HOPWORKS
REV. 0.95
PAGE 4
The advisee can view their schedule and can move courses/electives to different terms to plan out their
academic schedule. Course boxes are colored to indicate errors, the color mappings are described later
in the paper.
In this document the finished application will be described starting with the Context section that
provides information about the advising process at University of Portland. Next, the Technical Outcomes
section begins with screenshots and descriptions of the additions to the application interface. Behind
the scenes changes and the application database are also described in this section. The next section,
Process Outcomes, details all the functionality the team added and the differences between the
proposed design and final product. Feedback from user testing and the client is given, along with
possible additions to the application.
Context
Every semester at University of Portland advisees are required to meet with their advisor and receive
their advisor’s approval for the classes they plan on taking the following semester. During this meeting
the advisor checks that the advisee has satisfied all prerequisite and co-requisite requirements for the
classes they are planning on taking and makes sure that the advisee is still on track for graduation. This
process is time consuming and takes the majority of the advising meeting, leaving little time for the
advisee to interact with their advisor. Additionally advisors store their advisee’s course schedules and
academic plans in a variety of ways that are not always easily accessible for advisees.
At the University of Portland several disciplines have created a “sample schedule” for their degree
requirements. These sample schedules can be found in the University of Portland Bulletin and on
department websites. Advisees can use these sample schedules as a guide when planning their own
schedule. AdviseUP has templates, which are a sample schedule for a major. Advisees are given the
template for their declared major in AdviseUP and can then move the courses to plan their academic
schedule.
Technical Outcomes
Overview
The AdviseUP application consists of an interface written in ASP.NET, a processor consisting of C# and
JavaScript code, and a SQL Server application database. The database is hosted by the Web and
Administrative Services at University of Portland. These components are depicted in Figure 2 in black.
The arrows demonstrate the interactions between the components.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: KEKAI ARIOLA
FINAL REPORT
TEAM HOPWORKS
REV. 0.95
PAGE 5
Figure 2: Overview of Architecture
As part of AdviseUP Mark II, Team Hopworks integrated AdviseUP with the University of Portland Portal
website and Banner database. These new components are shown in red in Figure 2. The Portal website
provides advisees and advisors with links to the University of Portland’s resources. With the help of WAS,
Team Hopworks created a link to AdviseUP in the advising section of the Portal to make AdviseUP more
accessible. Banner is University of Portland’s Student Information System that stores all student, faculty, and
course information. AdviseUP does not access Banner directly. Instead Brian Toole wrote queries to get all the
data the application needs from Banner. The results of these queries are stored in Materialized Views which
are updated nightly. These are connected to the internal database of AdviseUP through a database link. While
developing AdviseUP the Portal link to AdviseUP was only added to the test version of the Portal, and the
materialized views pulled information from the Banner test database. References in this document to the
Portal and Banner data are referring to the test Portal and Banner data from the testing database, not the real
production environments.
Figure 3 below show how the different components of the application work together. This diagram shows the
data flow while the page is loading after an advisee logs in to AdviseUP.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: KEKAI ARIOLA
FINAL REPORT
TEAM HOPWORKS
REV. 0.95
PAGE 6
Figure 3: Data Flow Diagram
After the advisee logs in to AdviseUP the application must retrieve all of the advisee’s information and
display their academic schedule. The C# processor starts by calling a stored procedure in the SQL Server
internal database that retrieves the advisee’s transcript information from the view of Banner data and
stores it in the internal database. This information is only stored while the advisee remains logged in.
Next the processor will call another stored procedure to retrieve the classes the advisee is planning on
taking from the internal database. The processor uses this information to create the course boxes in
ASP.NET for all courses that are currently visible in the advisee’s schedule. After creating the course
boxes the process writes JavaScript code dynamically that allows the course boxes to be dragged in the
schedule. The processor will then use a stored procedure to retrieve the prerequisite and co-requisite
requirements from the internal database as well as the advisee’s transcript information that was
inserted by the first stored procedure. This information will be compared against the advisee’s proposed
schedule and the processor will color the course boxes with the resulting errors. Once this is completed
the advisee sees the graphical view shown in Figure 1. AdviseUP has components in four languages
interacting to make the application work.
Screenshots of Interface Modifications
This section includes screenshots and descriptions of all interface pages that have been modified or added.
The figure names include whether the feature is entirely new or is a modification to a preexisting feature. For
information about the other pages of the interface refer to Team Foxfire’s Final Report document [5].
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: KEKAI ARIOLA
FINAL REPORT
TEAM HOPWORKS
REV. 0.95
PAGE 7
Figure 4: New: Portal Link to AdviseUP
Figure 4 shows the link to AdviseUP on the University of Portland portal website (https://pilotstst.up.edu/group/main/academic-resources ). This is a new link that will direct the user to the AdviseUP
login page.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: KEKAI ARIOLA
FINAL REPORT
TEAM HOPWORKS
REV. 0.95
PAGE 8
Figure 5: Modified: Advisor’s Graphical View of Advisee Schedule
Figure 5 is a screenshot of an advisor/administrator’s graphical view of an advisee’s proposed academic
schedule. The advisee’s graphical view of their schedule is displayed similarly. The major new
functionality is the coloring of course boxes with errors. Additionally, advisors can reinitialize an
advisee’s schedule to give them a new template.
Course boxes are colored if there is an error with that course in that particular semester. Courses with
no errors are colored light blue. Courses in past terms in an advisee’s proposed schedule are checked
against the advisees transcript data from Banner. Table 1 below shows the possible errors and the
resulting color of the course box.
Table 1: Course Violations and Colors
Color
Violation
Yellow
Red
Orange
Light Grey
Dark Grey
Black
The advisee received a low passing grade of D- to D+
The advisee received an F
The prerequisite/co-requisite requirements are not fulfilled
The course was taken pass/fail or was dropped
There is no record of the advisee taking the course
There is no record of the course taken that semester but the transcript shows
the advisee took the class a different semester
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: KEKAI ARIOLA
FINAL REPORT
TEAM HOPWORKS
REV. 0.95
PAGE 9
Figure 6: New: Graphical View Transfer Credits Region
Figure 6 shows the transfer credits region of an advisee’s schedule in graphical view. Advisees with AP
credit or transfer credits from another university can move the courses they received credit for into this
region. Courses in this region do not have their prerequisite and corequisite requirements checked nor
are they checked against the advisee’s transcript.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: KEKAI ARIOLA
FINAL REPORT
TEAM HOPWORKS
REV. 0.95
PAGE 10
Figure 7: Modified: Advisor’s List View of Advisee Schedule
Figure 7 is a screenshot of an advisor’s list view of an advisee’s proposed academic schedule. The
advisee’s list view of their schedule is displayed similarly. This page was modified by the addition of the
transfer credits section.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: KEKAI ARIOLA
FINAL REPORT
TEAM HOPWORKS
REV. 0.95
PAGE 11
Figure 8: Modified: PDF Generated by Print Functionality
Figure 8 is a screenshot of a PDF that the application generates when a user clicks the Print button. This
now includes a section for transfer credits. Additionally, a disclaimer was added at the top that the PDF
is not a transcript and is for planning purposes only.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: KEKAI ARIOLA
FINAL REPORT
TEAM HOPWORKS
REV. 0.95
PAGE 12
Figure 9: Modified: Advisor’s Manage Course Page
Figure 9 is a screenshot of the advisor/administrator’s Manage Course page, which now includes the
Enrollment Prediction feature. This feature allows an advisor to view the number of students who are
planning on taking any given class for any semester.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: KEKAI ARIOLA
FINAL REPORT
TEAM HOPWORKS
REV. 0.95
PAGE 13
Figure 10: Modified: Administrator Create/View Template Page
Figure 10 shows the page that allows an administrator to create, view, and modify templates. The
administrator can now use the Add Existing Elective button to add a preexisting elective to the template.
Additionally, the application now requires that template names be unique. Also, similar to the graphical
view of advisees’ schedules in Figure 5, courses with unfulfilled prerequisite or co-requisite
requirements are colored orange.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: KEKAI ARIOLA
FINAL REPORT
TEAM HOPWORKS
REV. 0.95
PAGE 14
Figure 11: New: Administrator Add Existing Elective Page
Figure 11 shows the page that allows an administrator to add a previously created elective to a template.
Administrators can select an elective and click the View button to view the list of courses that satisfy the
elective. After selecting an elective, semester, and year the administrator can add the elective to the
template.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: KEKAI ARIOLA
FINAL REPORT
TEAM HOPWORKS
REV. 0.95
PAGE 15
Figure 12: New: Administrator Management Page Part 1
Figure 12 shows the page where administrators can manage the application. In the first list, an
administrator can remove another administrator’s privileges and make them an advisor. Additionally,
administrators can promote current advisors to administrators. The third list allows administrators to
remove advisors from the application who are no longer listed as academic advisors in Banner. The
fourth list displays unused electives and allows administrators to remove them from the application. See
Figure 13 for a screenshot of the rest of this page.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: KEKAI ARIOLA
FINAL REPORT
TEAM HOPWORKS
REV. 0.95
PAGE 16
Figure 13: New: Administrator Management Page Part 2
Figure 13 shows the lower half of the administrator management page. This consists of five Sync buttons
that allow administrators to sync the data stored in the internal database with the materialized views of
Banner data for Advisees, Advisors, Courses, Prerequisites and Co-requisites.
Processor and Database
Internal Database
The application database is a MS SQL Server database. This is hosted by Web and Administrative
Services on the SQL Server up-mssql4. The database consists of tables to store all of the application’s
data and stored procedures that allow the application to access the data. The internal database is
connected to materialized views of Banner data via a database link. The information contained in each
table and view is outlined below. Greater detail of the stored procedures and tables can be found in
Team Foxfire’s Design Document [4] and Team Hopworks’ Design Document [2].
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: KEKAI ARIOLA
FINAL REPORT
TEAM HOPWORKS
REV. 0.95
PAGE 17
Figure 14: Internal Database Tables
Figure 14 shows all 15 of the tables in the internal database. The title of a box is the name of the table
and describes what data the table stores. The fields in the table are listed below the title. Fields in bold
are required and the underlined fields of a table form its primary key (if the table has a primary key).
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: KEKAI ARIOLA
FINAL REPORT
TEAM HOPWORKS
REV. 0.95
PAGE 18
Figure 15: Materialized Views of Banner Data
Figure 15 shows all 7 materialized views of Banner data. The title of a box is the name of the
materialized view and describes what data it holds. Below the title is the name of the fields in the view.
Process Outcomes
Project Requirements
The team encountered many unforeseen setbacks and challenges during this project. The milestones
and schedule initially created did not accurately reflect the time required for each part of the project.
Despite these setbacks the team was able to add all intended functionality. Table 2 below lists each
function that was added to AdviseUP.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: KEKAI ARIOLA
FINAL REPORT
TEAM HOPWORKS
REV. 0.95
PAGE 19
Table 2: Proposed Functionalities with Completion Checklist
Primary Functionality
Completed
P1 AdviseUP uses SQL queries to pull current data from the
University of Portland’s live Banner database and store in its
application database.
P2 The AdviseUP link is accessible by all students and faculty across
campus through the advising portlet on the portal.
P3 Advisors can copy a template and then modify it instead of having
to create a new template for every discipline variation.
P4 AdviseUP will purge sensitive material after every user session.
Academic schedules will be purged after a student has graduated.
Graduation data will be received from Banner.




Secondary Functionality
S1
S2
S3
S4
S5
AdviseUP crosschecks advisees’ completed courses with the
previous semesters on their academic schedules. Advisors and
advisees receive visual and textual warnings if the Advisee has
not completed a course on their academic schedule or if they have
not completed the required prerequisites and co-requisites to
take a given course.
AdviseUP calculates how many students plan to take any given
class for any given semester. Advisors can view a future
enrollment prediction.
The Graphical User Interface of AdviseUP matches the look and
feel of other UP web pages and applications.
Notes on AdviseUP will be encrypted when being stored in the
application database.
Existing electives can be searched and added when editing or
creating a template.





For the details of each function refer to Team Hopworks’ Design Document [2]. The date of completion
for each function can be found in the Milestones section below.
Milestones
Table 3 shows the description, projected, and actual completion date of all the project milestones.
Detailed descriptions of each milestone are available in Team Hopworks Design Document [2].
Table 3: Project Milestones
Milestone
A
Description
Hold AdviseUP code review with Sam Burich
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
Projected
Completion
Date
5 Oct 2012
Completed Date
2 Oct 2012
CONTACT: KEKAI ARIOLA
FINAL REPORT
TEAM HOPWORKS
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
T
U
V
W
X
Y
Z
AA
BB
CC
DD
EE
FF
REV. 0.95
Identify what data must be drawn from Banner
Registrar approval to use Banner database
Complete policy for purging data
Complete code for future course enrollment
prediction feature
Complete requirements for views of Banner database
Complete CAS authentication code
Complete code to modify templates
Test CAS authentication
Test views of Banner database
Test course prediction and template procedures
Write template guide document for advisors
Client approval for template functionality
Complete code that adds and drops data from
internal database as needed
Complete code for portal links to AdviseUP
Test adding and dropping internal data
Complete code to check student schedules against
Banner data
Test the checking of student schedules against
Banner data
Complete code for purging data of graduated
students
Complete code to modify data to test purging of
graduated student data
Modify AdviseUP GUI to conform to UP style guide
Modify AdviseUP to remove outdated functionality
Complete code for encrypting notes
Code Complete
Test procedures for purging graduated students data
Test procedures for accessing Banner data
Test portal links to AdviseUP
Write Users Guide and Maintenance Guide
User and Faculty Testing Complete
Registrar Final Approval for live Banner database
IS Approval for portal links
Code frozen after integration testing
PAGE 20
8 Oct 2012
12 Oct 2012
24 Oct 2012
31 Oct 2012
5 Dec 2012
10 Oct 2012
24 Oct 2012
31 Oct 2012
7 Nov 2012
12 Nov 2012
23 Nov 2012
23 Nov 2012
28 Nov 2012
28 Nov 2012
5 Dec 2012
25 Jan 2012
11 Jan 2013
7 Nov 2012
INCOMPLETE
12 Nov 2012
INCOMPLETE
15 Feb 2012
23 Nov 2012
24 Jan 2013
2 Apr 2013
6 Dec 2012
18 Jan 2013
25 Jan 2013
25 Jan 2013
2 Apr 2013
31 Mar 2013
8 Mar 2013
1 Feb 2013
8 Mar 2013
1 Feb 2013
21 Feb 2013
8 Feb 2013
25 Feb 2013
8 Feb 2013
8 Feb 2013
15 Feb 2013
15 Feb 2013
20 Feb 2013
20 Feb 2013
25 Feb 2013
1 Mar 2013
8 Mar 2013
15 Mar 2013
22 Mar 2013
5 Apr 2013
3 Apr 2013
3 Apr 2013
17 Mar 2013
9 Apr 2013
1 Mar 2013
26 Mar 2013
3 Apr 2013
20 Apr 2013
3 Apr 2013
INCOMPLETE
INCOMPLETE
23 Apr 2013
Table 2 shows that many milestones were completed later than expected, however all functionalities
were completed. Reasons behind the delays can be found in the Unforeseen Time Expectations section.
More information on why milestones G and I are incomplete can be found in the Unforeseen Time
Expectations section under LDAP to CAS Authentication Switch. Likewise information on milestones DD
and EE can be found in the Risks Revisited section under Final Product Not Adopted by the University.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: KEKAI ARIOLA
FINAL REPORT
TEAM HOPWORKS
REV. 0.95
PAGE 21
Budget
Table 4 gives the development budget for AdviseUP Mark II. Because the development software is free and
the servers are provided by Information Services, the only expense was the food and drinks provided at the
user testing session.
Table 4: Project Budget
Line
Category
1
1.1
Printing
2
2.1
2.2
3
3.1
Food
Description
Number
A hard copy of each
of the previous
team’s documents
Large 1 topping pizza
Drinks
# of pages
245
Rate
$0.05
Estimated
Amount
Subtotal
$12.25
# of parts
10
10
$7
$2
$70
$20
3
$5
$15
$117.25
Actual
Amount
Subtotal
$12.25
$75
$4.98
Accessories
Plates and napkins
TOTAL
$8.83
$101.06
Unforeseen Time Expectations
LDAP to CAS Authentication Switch
Last year Team Foxfire planned to implement CAS authentication however they ultimately decided to
authenticate using LDAP. Team Hopworks planned to change the authentication from LDAP to CAS to
allow the use of single sign on. This means that if a user signs into one CAS authenticated website such
as the Pilots portal, they can access other CAS authenticated websites without having to sign in again.
Initial research showed that this would not be difficult to accomplish and would only require changing
some parts of the web.config XML file. This was not the case. The team managed to modify the
application to authenticate users using CAS, but while using CAS web browser cookies and session info
could not be used. These are necessary for the application to function, and while it is technically possible
to use these with CAS, it is very difficult and would have required extensive work. The team decided to
continue using the working LDAP authentication and devote more time to higher priority functionalities.
Receiving Materialized Views of Banner Data
The application accesses Banner data via materialized views created by the team’s industry advisor Brian
Toole. During the project the University of Portland’s Web and Administrative Systems (WAS) and
Internal Systems (IS) departments underwent many personnel changes. Due to this the creation of the
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: KEKAI ARIOLA
FINAL REPORT
TEAM HOPWORKS
REV. 0.95
PAGE 22
materialized views was delayed for over a month. This delayed all aspects of the project that utilized
Banner data.
Internal Database Redesign Overview
Significant modifications were made to the internal database over the course of the project. In the initial
design of the project SQL queries were to be used to obtain information from Banner. This design was
not possible and Brian Toole instead created materialized views of the Banner data that the application
needed and connected these to the internal database through a database link. The materialized views
contain all the information needed from Banner, however in some cases this differed from how the data
was stored in the internal database. This required the internal database be redesigned to reflect how
data is stored in Banner. Examples of three of the required changes are detailed below.
Redesign: Prerequisite Table
The AdviseUP database originally stored a prerequisite requirement as a courseID and a prereqID in the
Prerequisite table. This design allowed a course to have multiple prerequisites, however each
prerequisite course was required. Real courses can have more complicated prerequisite requirements,
for example BIO 307 could require either BIO205 or BIO207 be taken previously. The Banner
prerequisite data supports these more complicated prerequisite requirements, so the application had to
be redesigned to accommodate this.
Redesign: Multiple Advisors
Additionally the internal database only allowed an advisee to have one advisor. In reality advisees can
have several different advisors if they are double majoring or completing a minor. One of the
materialized views of Banner data links each advisee with all of their advisors. The internal database was
modified to no longer store their advisors ID as part of the student’s record. Instead the database
accesses this materialized view when the advisee wants to see information about their advisor.
Redesign: Course ID
The most significant modification dealt with the way a course was identified in the internal database.
Originally a unique number was generated for each course, and this was used in tables throughout the
database to identify that course. This numeric ID did not correspond in any way to the course that it was
identifying. With the inclusion of Banner course data this would have created problems when comparing
courses internally to the Banner course data. This prompted the redefinition of a courseID to be the
concatenation of the course department and number, i.e. CS203. This change had to be duplicated
everywhere in the internal database where courses were stored, as well as everywhere in the C#
processor where a numeric courseID was expected.
Materialized Views Access Delay
One unforeseen issue when accessing the materialized views was a 2-4 second delay. Since the
application checks the advisees planned schedule against transcript, co-requisite, and prerequisite
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: KEKAI ARIOLA
FINAL REPORT
TEAM HOPWORKS
REV. 0.95
PAGE 23
information from the materialized views every time a course is moved, this delay slowed down the
application considerably. To circumvent this issue tables were added to the internal database to store
this information so that accessing the views and the corresponding delay only occurs during the initial
login. This required the implementation of procedures that would purge the advisees’ transcript
information from the internal database when they log out or when their session times out.
Data Syncing Policies
Some Banner data from the materialized views is duplicated and stored internally. The application had
to ensure that the internally stored data was always consistent with the data from Banner. Some of the
Banner data only changes once a semester such as course, prerequisite, and co-requisite data. Stored
procedures were written that sync these internal database tables with the materialized views. Research
into having these procedures run automatically discovered SQL Server Agent, which allows the
procedures to be run at scheduled times. Implementing this scheduling via SQL Server Agent was not
successful because this tool requires administrative privileges on the SQL Server hosting the database,
which could not be granted to the team. An Administrative Management page was created where
administrators could manually sync the internal database with the Banner data. Some information
changes more frequently or at unscheduled times, such as when new advisees or advisors join the
university. The application was originally only useable to users whose information was stored in the
internal Advisee or Employee table, which would not allow recently added students to use the
application. This problem was solved by having the application check the materialized views if a user
logs in and is not in the internal database. If they are in the view, their information is added to the
internal database and they can now access the application.
Risks Revisited
1. The Office of the Registrar Will not Approve The Use Of Banner Data
The primary goal of AdviseUP Mark II was to connect the application to live data from the University of
Portland’s Banner database. The outcome of the project rested on the approval by the Registrar’s office
to access this data. With the help of Brain Toole and WAS, AdviseUP was granted access to the data
through materialized views of Banner data.
2. Not Enough Time for Testing
Because the materialized views were received later than expected, Team Hopworks was not able to test
AdviseUP as thoroughly as planned. The team did conduct a user test session but did not have enough
time to implement the testers’ suggested features.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: KEKAI ARIOLA
FINAL REPORT
TEAM HOPWORKS
REV. 0.95
PAGE 24
3. Final Product Not Adopted by the University
Team Hopworks worked hard to make AdviseUP a tool that could be adopted by University of Portland.
While this is possible, the University purchased Degree Works, a degree auditing application that has a
built-in planning tool. It is unlikely that the University will decide to host and maintain AdviseUP when
they have already paid for a similar utility. The team is meeting with the Registrar’s office and WAS to
allow them to assess AdviseUP and decide whether or not to adopt it. Additionally the team has
prepared a maintenance document to detail what would need to be done by WAS to support AdviseUP
in the future. This includes issues such as modifying the materialized views to pull the most current data.
If the University did adopt AdviseUP then as part of this the link to AdviseUP would be moved to the live
Portal site and the materialized views would be modified to pull live production Banner data.
User Testing
A user testing session with 45 student participants was conducted on April 3, 2013. The testers were
initialized with the template for their major, or if that template did not exist, the closest existing
template.
Testers were then given instructions on how to access the website and asked to rearrange the courses in
their template to best match their freshman year at the University. After testers had adjusted their
schedules, they participated in a short survey asking for their thoughts about the application. The user
test procedure and survey can be seen in Appendix A and Appendix B respectively. On a scale of one to
five, with five being the easiest, the average ease of use score for the application was 3.63. This was very
good considering that users were only given 10 minutes with the application and very little in the way of
instructions. Additionally 93% of testers said they would use the application and that it was a useful
addition to the current advising process.
Client Response
After demonstrating the application for the client, Dr. Lulay, he was very pleased with AdviseUP. His
favorite functionality was the connection to Banner and the resulting color-coded violations. His two
suggestions were to make the color key easier to understand and to change the file name to include
advisees names when generating PDF documents. The original auto-generated file name format was:
schedule_ID#.pdf. It has since been changed to: lastName_firstName_ID#_schedule.pdf.
Possible Additions to Application
Switch Authentication from LDAP to CAS
The authentication switch would allow for single sign-on across the other CAS authenticated University
websites such as the Pilots portal, email, and selfserve.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: KEKAI ARIOLA
FINAL REPORT
TEAM HOPWORKS
REV. 0.95
PAGE 25
Update User Interface
Our application follows the University’s branding policies but it is not officially approved by the
University. The University Brand Book was used to select the colors of the application. A meeting would
have to be set with the University’s Marketing and Communications department along with the
Registrar’s office. Button layout could also be improved.
Allow Courses to Be Dragged Across More Than the Five Visible Semester Panels
The most requested feature from the user testing session was to allow students to drag courses farther
than the five visible semester regions in graphical view. This was an issue when upper class students
were initialized with a template and had to move courses across many semesters, such as from their
senior year to their freshman year.
Smooth Page Refreshing
When a student moves a course, the whole page reinitializes. Using JavaScript, future implementations
can have this process appear smoother.
Automatic database syncing (between internal database and Banner data)
Currently the application relies on the administrators to manually sync student and course information
with the materialized views of Banner data. Future implementations could have the internal database
sync on a specified schedule making it easier to maintain.
Conclusion
AdviseUP provides the advisors and advisees of the University of Portland with a scheduling tool that
can be used to expedite the advising process and help advisees create their academic schedule. Using
AdviseUP advisees could plan their academic schedule by rearranging the classes in the template for
their major. When advisees go to their advising meeting their advisor can pull up their schedule and can
quickly see from the coloring that the advisee has taken everything they planned in previous semesters
and that they have satisfied all prerequisite and co-requisite requirements for the next semester. This
allows the advisee and advisor to spend more time talking about how the advisee is doing and
answering any questions that they have.
The team succeeded in implementing all of the primary and secondary functionality requirements. This
was a significant accomplishment after the team was not able to understand the inherited project as
quickly as planned and received the materialized views much later than anticipated. A significant portion
of the team’s work was not covered by the initial planning. The team spent a lot of time making policy
decisions and handling issues inherent in dealing with real data. The team learned a great deal while
working on AdviseUP and is very proud of their efforts.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: KEKAI ARIOLA
FINAL REPORT
TEAM HOPWORKS
REV. 0.95
PAGE 26
Acknowledgements
We would like to give special thanks to the people who helped make our project a success. First Dr.
Tammy VanDeGrift, our faculty advisor, who provided guidance to our team and helped us solve the
many policy issues. Next Sam Burich, one of our industry advisors and a member of Team Foxfire who
helped us understand AdviseUP. Lastly we need to thank our other industry advisor Brian Toole. Brian
created our views of Banner data and who attended our weekly meetings and gave us great information
and advice.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: KEKAI ARIOLA
FINAL REPORT
TEAM HOPWORKS
REV. 0.95
PAGE 27
References
1. Kekai Ariola, Eric Bergquist, Megan Yamamoto. Team Hopworks Functional Specification
rev
1.0.
Published:
Sept,
2012.
Accessed:
September
2012.
teaching.up.edu/SrDesign/AY13/Hopworks/documents.htm
2. Kekai Ariola, Eric Bergquist, Megan Yamamoto. Team Hopworks Design Document rev 1.0.
Published:
Dec,
2012.
Accessed:
December
2012.
teaching.up.edu/SrDesign/AY13/Hopworks/documents.htm
3. Sam Burich, Kapua Chandler, Chris Lewis. Team Foxfire Functional Specification rev 0.9.
Published:
Sept,
2011.
Accessed:
September
2012.
teaching.up.edu/SrDesign/AY12/Foxfire/documents.htm
4. Sam Burich, Kapua Chandler, Chris Lewis. Team Foxfire Design Document rev 0.97.
Published:
Nov,
2011.
Accessed:
September
2012.
teaching.up.edu/SrDesign/AY12/Foxfire/documents.htm
5. Sam Burich, Kapua Chandler, Chris Lewis. Team Foxfire Final Report rev 0.97. Published:
Apr, 2011. Accessed: April 2012. teaching.up.edu/SrDesign/AY12/Foxfire/documents.htm
6. Sam Burich, Kapua Chandler, Chris Lewis. Team Foxfire Developer Documentation.
Published:
Apr,
2012.
Accessed:
September
2012.
teaching.up.edu/SrDesign/AY12/Foxfire/documents.htm
7. University
of
Portland
Bulletin
2012-2013.
Accessed:
http://www.up.edu/provost/default.aspx?cid=9663&pid=1950
February
2013.
8. Transact SQL Reference (Database Engine) Accessed: September 2012 – April 2013.
http://msdn.microsoft.com/en-us/library/bb510741(v=sql.105).aspx
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: KEKAI ARIOLA
FINAL REPORT
TEAM HOPWORKS
REV. 0.95
PAGE 28
Appendix A: Advisee User Test
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: KEKAI ARIOLA
FINAL REPORT
TEAM HOPWORKS
REV. 0.95
PAGE 29
Appendix B: Advisee User Survey
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: KEKAI ARIOLA