slide1 n.
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


Download Now 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.