Skip to content

Spring Quarter – Cycle 12

06/22/2015 — 07/03/2015

Work Complete

Appreview Plus

  • Created database migrations. Database “Migrations” are the application code that create database tables. By implementing these in code we can run them systematically on various environments, check them into version control, make them DBMS platform agnostic.
  • Implemented “Old Applicant Data” as array structures contained in DataSource module with classes for each data type. This gives a segregated layout to the code that is easier to understand and utilize.
  • Import process created for about 1/3 of the Appreview tables. This work will continue in next cycle.
  • Did not complete search tool or applicant detail page, planned for next cycle.

Budgets

  • Editable food approval flag, set by fiscal staff, based on COE policy, displayed along side UW food policy value. (Completed in DEV, waiting for SME approval.)

Courses

  • Get Term data filled out through AY 2017-18 from UW Calendar.
  • Improved UWTS linking, show all the matching sections including deleted and already linked. Completed Winter 2016 import and linking with new tool.

Grants

  • Update grant data nightly using automated import from UW Enterprise Data Warehouse. (Development complete, needs to be deployed in production.)

Educ

  • Created a base form handler class that simplifies form development in future projects. Provides structure for user input scrubbing, validation, error handling and storage.
  • Fixed bug – application index page now accessible by anyone logged in with UW NetID.

Students

  • Fix problem where current registration tool does not show course names. Significant revision of Web Service Client code: central configuration, much better error logging, more flexible exception handling, consistent interface across implementations, all using JSON representations.
  • Refined Doc Committee import process added more automation so it can be run on a weekly basis.
  • Added Program views for ECFS Teaching & Learning option.

Reporting and Information Dashboards

  • Install Tableau and connect to UW Server
  • Design 2015 Undergraduate Survey data visualizations, results located here.

Infrastructure

  • More refinements to Builder utility. Builder generates skeleton application code for entity classes based on database structure. Long term time saver automates routine repetitive work.

Work Planned

Cycle 12 is our last two week work cycle we are calling part of Spring Quarter work. Our quarterly review and planning meeting for Summer 2015 is Tuesday, 6/23, 2:00 PM in Miller 215.

Previous work on Appreview Plus has been planning and low level. This cycle we want to get a couple items done that users can see, touch, give feedback on.

New heading below for “Educ” which is our shared application infrastructure. We expect Educ to give us better results, more quickly, with greater consistency across applications. Read more about the Educ: Unified Application Infrastructure.

  • Appreview Plus
  • Courses
  • Grants
  • Educ
  • Students
  • Reporting and Information Dashboards

Educ: Unified Application Infrastructure

The College of Education has somewhere between nine and a dozen (depends how you count them) distinct information system applications.

Building these applications separately had some advantages. It kept the domain logic specific, gave a clear context to design decisions, prevented cross system bugs, and let us keep iterating on and improving our framework. But it has gotten to the point where the technical debt of maintaining those multiple systems is impacting our ability to deliver new functionality.

Going forward our plan is to have a shared infrastructure that we implement new applications in and when the opportunity arises fold the existing applications into the shared framework. We are calling the new unified application infrastructure "Educ" since it will potentially house all College of Education information systems. The new Person and Budget databases are built in Educ and Appreview Plus project includes migrating SOARS to the shared framework.

Within the Educ project we create "contexts" so the single application and database under the hood can still appear as distinct systems on the surface. Switching "contexts" between Person and Budget and Appreview gives you different titles, menus, and search scopes. It looks like you are switching applications, but you are navigating between sections.

Educ uses Laravel which is a robust, popular, and high performance PHP framework. Educ has a shared person repository which allows greater consistency of data and easier sharing of information across contexts.

Spring Quarter – Cycle 11

06/08/2015 — 06/19/2015

Work Complete

Work deviated from plan a bit this cycle as the complexities of the Appreview Plus database migration became clearer. Added a side task of a “Builder” utility which will pay off in efficiency and accuracy over the long term.

Starting to refer to our unified application platform that currently houses the Person and Budget project and will house Appreview Plus as “EDUC”.

Appreview Plus

  • Prepare the unified EDUC project to handle large contexts starting with applicant data. Structure code to have logical segregation of subject matter, while sharing infrastructure. Revise application to find all the existing code in new context organization.
  • Database plan with Entity Relationship Diagram: Restructure application data to be compatible with Grad School application and handle purely local applications. Rename tables and columns to follow unified EDUC database conventions. Unify repetitive tables in applicant data into standard tables that can be used accross unified EDUC database including activity log, email, comments, attachments.
  • Convert ERD into migrations – write application code that creates database tables
  • Email plan – handle existing applicant email history and provide more complete logging going forward
  • Create plan for importing old incomplete applicant data: Bring all data where we have a Grad School applicant record in XML. Bring older records where we have link to UW institutional data example: the applicant has a SDB system key or a UW NetID.

Budgets

  • Didn’t get food approval complete. This triggered some work to form handling infrastructure in EDUC project which needs to be completed first. Food approval will get taken care of in the upcoming cycle.

Students

  • Refined career import job title merging logic for new titles in this year’s Seattle Public Schools data

Techsupport

  • Add configurable room entity to classroom check utility
  • Removed Do Not Reply message from Help Desk emails, going full release with email ingestion
  • Added editable footer to email

Infrastructure

  • Builder utility is a PHP application that writes PHP application code. A certain portion of our application code is predictable based on structure of tables in the database. Instead of repetatively writing out three or four files we created the Builder utility that takes the database structure as input and output the framework of the application code. This save coding time simply by generating the core file, but the big time savings is in the consistency and accuracy of programmatically generated code.
  • MRBS Room Schedule tool on application context menu
  • Standardize new unified EDUC app search menu and page context level menu. Implement menus responsively for small (mobile) screen sizes.

Work Planned

  • Appreview Plus
  • Bizops
  • Budget
  • Person
  • Student Database
  • Tech Support
  • Infrastructure

 

Appreview Plus

Our existing online applicant review system (SOARS) was built as a view on top of the live Graduate School application data. When you look at the detail page of an applicant in SOARS, a big chunk of what you see gets queried real time from MyGrad. This met the original specifications and has the nice advantage of being up-to-date and authoritative, but it has several downsides.

  • If Graduate Service goes down, SOARS goes down
  • The only applications we can have in SOARS are ones that come from the Graduate School
  • Once the Graduate School stops making applicant data available through the web service, it disappears completely in SOARS

To address these issues we have decided to build Appreview Plus. Appreview Plus will operate like SOARS feature for feature. But it will store application data locally and the application data will be structured for College of Education needs. For graduate applications the data will still map back to the Graduate School and get updated from their web service. But it will not be a requirement for there to be Graduate School data for our system to have data. This decoupling allows

  • Continue to view old application data (e.g. for current students) after MyGrad application is removed
  • Have local applications included side by side with MyGrad applications (e.g. existing students who change programs or continue on to additional degrees)
  • Able to handle applications from students that don’t apply through Graduate School (e.g. ECFS)

While we are restructuring data to exist as local application records we are also restructuring to better integrate the data with other systems. This offers many potential benefits, two big ones include

  • Inclusion of application data in student data views (e.g. Statement of Purpose, previous degrees, contingencies visible in STEP).
  • Shared storage of Person records simplifies administration and reporting.

This is a big project we want to do thoughtfully over the Summer (2015). This means reviewing existing system with SME’s and thoroughly reviewing existing code and database so we protect current capabilities while implanting the new features.

Ticket First

Our initial requirement for the Business Operations database (Bizops) was to implement an electronic version of the travel form. This was a complex process that frequently required back and forth revision so it was identified by the college process improvement group as a first place to focus.

The Bizops system was built using code from the Help Desk ticket system which contained many useful entities like Tickets (a project or task) a requestor, a person responsible for completing the work, a collection of messages related to the ticket, etc.

As we talked with the fiscal team we became concerned that Bizops: Travel Form might be another disjointed collection of tasks to keep track of. If some work is listed in email, some is in one-of-three excel sheets, some is in the shared drive, some is on a post-it, and now some are in the Bizops: Travel Form, it can be messy.

Ticket First” represents our plan to surface the Ticket concepts and user interface from the existing Help Desk code so that Bizops can be a repository for any request, any task, not just Travel Forms.

Travel Forms now become an extra artifact related to the ticket. The ticket structure provides the context for who the requester is, who the staff responsible is, and what messages went back and forth about this particular travel form.

Ultimately it will be up to the fiscal team to decide if Bizops tickets helps them track work and share information.

Spring 2015 — Cycle 10

05/25/2015 — 06/05/2015

Work Complete

This cycle continued to focus on Appreview Plus. Significant work discovering how this is working now and how it should work going forward.

In Business Operations system we worked on implementing Ticket First.

School of Social Work is going to uses our Courses Database at their unit and we provided a little help getting them oriented and took the opportunity to get our documentation refreshed.

Appreview

  • Move updater code (part of the application that scans Grad School web service and discovers application data) to the new EDUC system. Some revisions and testing to existing import processes (Person, Budget).
  • Restructure EDUC project to contain multiple contexts (Person, Budget, Appreview).
    Create Appreview entities and repository classes.
  • Plan map of existing data, table by table, to new system.

Business Operations

  • Build Ticket First migration script.
  • Continued work implementing Ticket First. Deployed working version to dev for QA and user testing.

Courses

  • Delete UW Time Schedule records and child record routines, utility to clean up bad duplicate data.
  • Merge person record tool. Simple fast GUI for combining multiple repetitive person records into a single data point.
  • Refreshed documentation.

Recruitment

  • Fixed bug in bulk email tool.

Students (STEP)

  • Mentor payment report fixed and revised.

Infrastructure

  • Review big bicture documents with stakeholders