1 / 32

R DCR ARB Student Scheduling System Part II - PowerPoint PPT Presentation

  • Uploaded on

R DCR ARB Student Scheduling System Part II. Client: David Klappholz Team 10 Bo Wang, Bohan Zheng , Chenyang Bai Rui Tong, Shuai Wang, Xiaoran Li. Personnel Turnover. Former IIV&V left this semester Responsibility hands over to PM and Tester No new t eam member.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' R DCR ARB Student Scheduling System Part II' - roanna-cox

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

RDCR ARBStudent Scheduling System Part II

Client: David Klappholz

Team 10

Bo Wang, BohanZheng, ChenyangBai

Rui Tong, Shuai Wang, Xiaoran Li

Personnel turnover
Personnel Turnover

  • Former IIV&V left this semester

  • Responsibility hands over to PM and Tester

  • No new team member

Team s weak points
Team’s Weak Points

  • Technical View:

    • Do not have previous experience on Play Framework

  • Operational view:

    • Language barrier

    • Heavy schedule

Team s strong points
Team’s Strong Points

  • Technical view:

    • All CS students

      (with both back and front end programming exp.)

    • Quick learners

  • Operational view:

    • Early Development phase setup

    • Strong team communication & coordination

    • High level of team involvement

    • Strong sense of responsibility

    • More experienced than the first semester

Progress indicator
Progress Indicator

Class Begins


Progress in new semester
Progress in New Semester

  • No change in Win Conditions and OCD

  • Updated Risks, Life Cycle, Test Plan and Cases

  • Enhanced Prototype

  • Core capacities of Admin Side are almost done

  • Algorithm Implementation in Progress

Test plan
Test Plan

  • Test Strategy:

    • Requirements-test traceability

    • Value-based Test Prioritization

  • Full test cases have been designed to validate the working order of key functional system aspects that must succeed in order to fulfill project requirements as captured in the Win-Win conditions.

Test cases
Test Cases

  • TC-01-01 Manual Course Selection

  • TC-01-02 Auto Course Selection

  • TC-01-03 Semester Criteria

  • TC-01-04 View Study Plan

  • TC-01-05 Insufficient Course Selections

  • TC-01-06 Required Relaxation

  • TC-02-01 Add/Modify Course

  • TC-02-02 Corequisite/Prerequisite Hints

  • TC-02-03 Create/Modify Course Groups

  • TC-02-04 Create/Modify Simple Requirements

  • TC-02-05 Create/Modify Degree Programs

  • TC-02-06 Create/Modify Requirements (Complex)

  • TC-03-01 User Login

  • TC-03-02 Add/Modify Director Information

  • TC-03-03 Invalid User Login Credentials

Test report
Test Report

  • Unit Testing on Front-end of Admin Side

  • 28 issues found

  • 15 of them were critical defects


  • The major functions of administrative side has been completed.

  • Detailed document is needed to explain the expression input for co/prerequisite courses

  • URL: (Demo)

Class diagram admin side
Class Diagram (admin side)

Class diagram student side
Class Diagram (student side)

Defect metric
Defect Metric

  • As the coordinator of front & back side, I collected the bugs and defects from Jan. 3rd to present.

  • The data mainly came from Bugzilla and Test Report.




  • Student side willbefocusofourworkduringnextiteration.

    • UserInterface

    • Solver

Student side

  • The design of the UI remains the same.

  • Maybe need little modify because of the solver.

Student side1

Algorithm admin side
Algorithm - Admin Side

  • Implementation

    In the administrator side, the system is responsible for doing operation about database: add/modify/delete degree program, requirement information, requirement relation, course information, course relation. Also, the system needs to read data from database to form “requirement graph” and construes “course graph data structure”.

  • API Reference:


  • Current Issue:

    Refine the API design

    Combine the back-end with the UI.

Algorithm student side
Algorithm - Student Side

  • Implementation

    We just begin the detail algorithm implementation of front-end.

    Tasks have been done: when student chooses courses, the system can help him add all prerequisite, corequisites with both the “and” & “or” relation.

    Tasks to be done: To deal with the “or” relation, now we pick one choice randomly.

  • API Reference:


  • Current Issue:

    Recovery mechanism for algorithm:

    How to make algorithm strong enough to deal with the “picky” situation.