1 / 32

RDCR ARB Student Scheduling System Update - Team 10 Progress Report

This report details Team 10's progress on the RDCR ARB Student Scheduling System, highlighting personnel changes, technical strengths and weaknesses, and ongoing development. Key improvements include enhanced prototype work, risk updates, and the design of comprehensive test cases to ensure system functionality. The team possesses a strong sense of responsibility, effective communication, and quick learning abilities. Future focus will be on elaborating the student side algorithm and refining API design for seamless integration. Class begins Jan 13.

maxima
Download Presentation

RDCR ARB Student Scheduling System Update - Team 10 Progress Report

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. RDCR ARBStudent Scheduling System Part II Client: David Klappholz Team 10 Bo Wang, BohanZheng, ChenyangBai Rui Tong, Shuai Wang, Xiaoran Li

  2. Personnel Turnover • Former IIV&V left this semester • Responsibility hands over to PM and Tester • No new team member

  3. Team’s Weak Points • Technical View: • Do not have previous experience on Play Framework • Operational view: • Language barrier • Heavy schedule

  4. 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

  5. Progress Indicator Class Begins Jan.13

  6. 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

  7. Roles

  8. Responsibilities

  9. Project Iteration Plan – In Progress

  10. Project Iteration Plan – Transition

  11. Project Iteration Plan – Operation

  12. Definition of Done

  13. Risk Analysis

  14. 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.

  15. 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

  16. Traceability Matrix (Updated)

  17. Prioritized Requirements Traceability

  18. Test Report • Unit Testing on Front-end of Admin Side • 28 issues found • 15 of them were critical defects

  19. 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)

  20. A&I Diagram

  21. Class Diagram (admin side)

  22. Class Diagram (student side)

  23. Software Component Diagram

  24. 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.

  25. 26 27

  26. Prototype • Student side willbefocusofourworkduringnextiteration. • UserInterface • Solver

  27. Studentside • The design of the UI remains the same. • Maybe need little modify because of the solver.

  28. Studentside

  29. 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.

  30. 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.

  31. Thank You

More Related