slide1
Download
Skip this Video
Download Presentation
R DCR ARB Student Scheduling System Part II

Loading in 2 Seconds...

play fullscreen
1 / 32

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


  • 99 Views
  • 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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
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
slide1

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

Jan.13

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
prototype
Prototype
  • The major functions of administrative side has been completed.
  • Detailed document is needed to explain the expression input for co/prerequisite courses
  • URL: http://127.0.0.1:9000/ (Demo)
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.
slide26

26

27

prototype1
Prototype
  • Student side willbefocusofourworkduringnextiteration.
    • UserInterface
    • Solver
student side
Studentside
  • The design of the UI remains the same.
  • Maybe need little modify because of the solver.
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:

AIED_RDCR_S14b_T10.doc

  • 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:

AIED_RDCR_S14b_T10.doc

  • Current Issue:

Recovery mechanism for algorithm:

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

ad