r dcr arb student scheduling system part ii

T10-Student Scheduling System CS-577B Software Engineering RDCR ARB

1

RDCR ARBStudent Scheduling System Part II

Client: David Klappholz

Team 10Bo Wang, Bohan Zheng, Chenyang Bai

Rui Tong, Shuai Wang, Xiaoran Li

Bowen

Presenter: Bowen


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

1 2 3 4 5 602468

1012141618

Progress

Initial PlanActual

Week #

Cum

ulati

ve T

asks

Com

plet

ed

Class BeginsJan.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

RolesMember

Name Construction Iteration Transition Iteration

Wang, Bo Back-end ConductorAssistant Tester Transition Negotiator

Bai, Chenyang Developer System Deployer

Zheng, Bohan Front-end Conductor Maintainer

Wang, Shuai Algorithm Solver Manual ComposerTrainer

Tong, Rui CoordinatorAssistant Tester

Manual ComposerTrainer

Li, XiaoranChief Tester Tester

Quality Assurer Manual Conductor


8

ResponsibilitiesMember

Name Construction Iteration Transition Iteration

Wang, Bo Construct back-end of Administrative SidePerform white-box testing on solver Deploy system

Bai, Chenyang Construct back-end of Administrative Side Deploy system

Zheng, Bohan Construct Front-end on Stu & Admin Side Fix defects

Wang, Shuai Design scheduling algorithmRealize and construct scheduling solver

Composite user manualPerform training

Tong, Rui Coordinate front-end and back-endPerform white-box testing on solver

Compose maintenance man.Perform training

Li, Xiaoran

Perform essential black-box testingReport bugs in Bugzilla

Conduct manual compositionPerform testing

Ensure quality on construction Review and verify documents


9

Project Iteration Plan – In Progress


10

Project Iteration Plan – Transition


11

Project Iteration Plan – Operation


12

Definition of Done1 With the interaction between students and system, a study plan can be

generated within one hour.

2 If the solver doesn’t respond in 5 minutes, students will be asked to relax constrains.

3 Given brief instruction, students can operate student side by simple clicks and inputs.

4 Administrators and directors can get full access to the data through administrative side.

5 The whole system passes acceptance testing.

6 The system will give error descriptions when exceptions occur.

7 Documents and user manuals are completed.


13

Risk AnalysisRisk Rationale

Risk ExposureRisk Mitigations

PM PL RE

Algorithm failed Algorithm efficiency untested 5 7 35

Finish the algorithm as soon as possible, thus we have more times to test and improve the algorithm. On the

other hand, if the algorithm can not give a solution in a acceptable time, we should find a way to give a useful hint

about how to get the result in a acceptable time.

Transition environment

mismatch

Do not have clear understanding about

SIT’s sever4 7 28

Getting more details about the sever from client, and we can test the sever at first before formal transition, in this way we can have more time to adjust our system to the

sever, so we can reduce the transition risks of our project.

Requirements Volatility in

transition phase

New requirements may occur in the transition phase according to the

real environment

2 4 8 Keeping on weekly negotiations, testing and getting feedback before formal transition.

User interface mismatch

Administrator side is satisfied but students’

side is not finished.2 3 6 Identifying what is exactly client want. Reporting program

progress timely to clients.

Schedule confliction

All of our team members have a lot of work load and different schedule

2 3 6Make a detailed plan for each phase of the next semester,

based on the experience of this semester to avoid unnecessary time cost.

Bowen

Presenter: Bai


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)OCD Requirements SSAD Test Case

OC-1 WC_1350(Last Year)WC_1329(Last Year)

UC-7, UC-8, UC-9, UC-10, UC-11, UC-12

TC-02-01, TC-02-03, TC-02-04, TC-02-05, TC-02-06

OC-2 WC_1533(Last Year) UC-1, UC-2, UC-3, UC-4, UC-5 TC-03-01, TC-03-02, TC-03-03

OC-3OC-4 WC_2657 UC-6 TC-01-01, TC-01-03, TC-01-05

OC-5 WC_2657, WC_2658 UC-6 TC-01-01, TC-01-02, TC-01-03, TC-01-04

OC-6 WC_2656 UC-10, UC-11, UC-12 TC-02-02

OC-7 WC_2655, WC_2659 UC-6 TC-01-05, TC-01-06

OC-8 WC_2660 N/A N/A

OC-9 WC_2658 UC-6 TC-01-04


17

Prioritized Requirements TraceabilityRequirements

(Win-Condition ID) Brief Description TOPSIS Score

Test Cases(Test Identifier)

WC_1350 (Last Year)WC_1329 (Last Year)

Degree Requirements Management N/A

TC-02-01 Add/Modify CourseTC-02-03 Create/Modify Course GroupsTC-02-04 Create/Modify Simple RequirementTC-02-05 Create/Modify Degree ProgramsTC-02-06 Create/Modify Requirement (Complex)

WC_1533 (Last Year) Authentication and Roles N/ATC-03-01 User LoginTC-03-02 Add/Modify Director InformationTC-03-03 Invalid User Login Credentials

WC_2658 Scheduling Upper Bound 0.934 TC-01-04 View Study PlanTC-01-06 Required Relaxation

WC_2657 Study Plan Generation 0.554TC-01-02 Auto Course SelectionTC-01-03 Semester CriteriaTC-01-04 View Study Plan

WC_2659 Constraints Relaxation 0.528 TC-01-06 Required Relaxation

WC_2654 Friendly Requirement Layout on Student Side 0.428

TC-01-01 Manual Course SelectionTC-01-02 Auto Course SelectionTC-01-03 Semester CriteriaTC-01-05 Insufficient Course SelectionsTC-01-06 Required Relaxation

WC_2655 Better Error Explanations 0.379TC-01-05 Insufficient Course SelectionsTC-01-06 Required RelaxationTC-02-01 Add/Modify CourseTC-02-06 Create/Modify Requirement (Complex)

WC_2656 Hints for Administrator 0.363 TC-02-02 Co-requisite/Prerequisite Hints

WC_2660 Tools/Languages Compatibility 0.026 N/A


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)

http://127.0.0.1:9000/

Bowen

Presenter: Bohan


20


21

A&I Diagram


22

Class Diagram (admin side)


23

Class Diagram (student side)


24

Software Component Diagram


25

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.

Bowen

Presenter: Rui


2726


27

Prototype

• Student side will be focus of our work during next iteration.– User Interface– Solver

Bowen

Presenter: Bohan


28

Student side

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

solver.

Bowen

Presenter: Bohan


29

Student side

Bowen

Presenter: Bohan


30

Algorithm - Admin Side

• ImplementationIn 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 designCombine the back-end with the UI.

Bowen

Presenter: Shuai


31

Algorithm - Student Side

• ImplementationWe 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.

Bowen

Presenter: Shuai


32

Thank You

r dcr arb student scheduling system part ii

Documents

test plan

study plan

end programming

cs students

play frameworkoperational

quick learnersoperational

endperform whitebox

bohanconstruct frontend