R dcr arb student scheduling system part ii
This presentation is the property of its rightful owner.
Sponsored Links
1 / 32

R DCR ARB Student Scheduling System Part II PowerPoint PPT Presentation


  • 82 Views
  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

R DCR ARB Student Scheduling System Part II

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


R dcr arb student scheduling system part ii

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


Roles

Roles


Responsibilities

Responsibilities


Project iteration plan in progress

Project Iteration Plan – In Progress


Project iteration plan transition

Project Iteration Plan – Transition


Project iteration plan operation

Project Iteration Plan – Operation


Definition of done

Definition of Done


Risk analysis

Risk Analysis


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


Traceability matrix updated

Traceability Matrix (Updated)


Prioritized requirements traceability

Prioritized Requirements Traceability


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)


A i diagram

A&I Diagram


Class diagram admin side

Class Diagram (admin side)


Class diagram student side

Class Diagram (student side)


Software component diagram

Software Component Diagram


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.


R dcr arb student scheduling system part ii

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.


Student side1

Studentside


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.


Thank you

Thank You


  • Login