Team 06: Student Scheduling System

CSCI577b – Spring 2013– Team 6 – RDCR, ARB

1

Team 06: Student Scheduling System

• Client: David Klappholz– Stevens Institute of Technology CS Dept.

• Douglass Kinnes - Project Manager• Alexey Tregubov - System Architect• Mihir Daptardar - Operational Concept

Engineer• Ihsan Tolga - Life Cycle Planner• Simone Lojeck - IV&V, Quality Focal Point04/20/23 1


2

Changes from 577A

• Staff Loss– Prototyper did not return this semester– Doug Kinnes has taken over role– Luckily our GUI prototyping was almost finished

• Member change to DEN– More need for effective skype collaboration

04/20/23 2


3

DEN Observations – Strong/Weak Pts. No Significant Changes

Team’s Strong Points: • Operational View:

o Strong Team Communication / Coordinationo High Level of Team Involvement

• Technical View: o Wide Array of Team Capabilities

Team’s Weak Points: • Operational View:

o Widespread Physical Locationo Unfamiliar with ICSM Process

• Technical View: o Experience Mostly limited to Scholastic Projectso Limited Development/Deployment Experience

Strong Points Supported & Weak Points Mitigated

with: •Weekly Skype Meetings•Frequent Email Communication


4

DEN Observations – Shaping & Eval No Significant Changes

WinWin Shaping Status: Open WinCs: 15 Win Conditions Agreed WinCs with Issues & without Issues

15 Conditions Agreed to; 0 Potentially Agreeable 8 Conditions w/o Issue; 7 w/Issue (all resolved)

Overall Project Evaluation The Team worked well together during the past semester to accomplish

goals and resolve issues. The products have developed into near complete, highly descriptive project

artifacts, reminiscent of industry documents. Risks, that were identified, appear to have been addressed. Issues that were

identified were mitigated promptly.


5

• Set of Test Cases will confirm satisfaction of Minimum Marketable Features:• Construct Schedule• Student Specify Courses• Enter Degree Requirements

• Detailed Test Cases will confirm incorporation of requirements (as captured in Winbook) into software.

• 3 top level Test Cases defined to cover critical constraints:• TC-01: Student Plan Construction• TC-02: Degree/Course Maintenance• TC-03: Level of Service

Test Plan and Cases - Overview


6

• Test Case Satisfies Minimum Marketable Features:• Construct Schedule• Student Specify Courses

• Sub Test Cases will Test Requirements: • WC_1345• WC_1346• WC_1347• WC_1348• WC_1352• WC_1353• WC_1354• WC_1512

Test Plan and Cases: TC-01: Study Plan Construction

*Subset of Test Case Parameters


7

• Test Case Satisfies Minimum Marketable Feature:• Enter Degree Requirements

• Sub Test Cases will Test Requirements: • WC_1329• WC_1349• WC_1350

Test Plan and Cases: TC-02: Degree/Course Maint.

Test Case Number TC-02-01: Degree Program Creation

Test Item Item evaluates the ability of the admin user to add degree programs.

Test Priority M (Must have)

Input Specifications User will log into the system and attempt add degree programs.

Expected Output Specifications System will update database with admin user’s information.

Pass/Fail Criteria Admin user will be able to enter information into the system.

Dependencies TC-02-04

Traceability None

Test Case Number TC-02-02: Degree Requirements Addition

Test Item Item evaluates the ability of the admin user to add degree requirements.


Input Specifications User will log into the system and attempt to add degree requirements



Dependencies TC-02-03, TC-02-04

Traceability None

Test Case Number TC-02-03: Course Group Addition

Test Item Item evaluates the ability of the admin user to add course groups.


Input Specifications User will log into the system and attempt to add course group information.



Dependencies None

Traceability None

Test Case Number TC-02-04: Course Addition

Test Item Item evaluates the ability of the admin user to add courses.


Input Specifications User will select the links that will lead to the New Course page, then enter the data to identify the course (title, Course Prefix, Course Number, Credits, Schedule year, Semester offered, Prereqs, CoReqs



Dependencies TC-02-02

Traceability None *Subset of Test Case Parameters


8

• Test Case Satisfies All 3 Minimum Marketable Features:• Construct Schedule• Student Specify Courses• Enter Degree Requirements

• Sub Test Cases will Test Reqs:

Test Plan and Cases: TC-03: Level of Service

Test Case Number TC-03-01: Trivial Test Case

Test Item Item evaluates the total system with a trivial input case.

Test Priority M (Must have)Input Specifications User will log into the system and attempt to

input simulated student information into the appropriate User Interface prior to initiating study plan generation.

Expected Output Specifications

System will generate study plan based on user’s inputs and provide study plan in a manner available to the user.

Pass/Fail Criteria Study plan generated will satisfactorily incorporate the student’s and advisor’s constraints into a plan.

Dependencies NoneTraceability TC-03-02, TC-03-03

Test Case Number TC-03-02: Solvable Test Case

Test Item Item evaluates the total system with a solvable input case.

Test Priority M (Must have)Input Specifications User will log into the system and attempt to input

simulated student information into the appropriate User Interface prior to initiating study plan generation.


System will generate study plan based on user’s inputs and provide study plan in a manner available to the user.

Pass/Fail Criteria Study plan generated will satisfactorily incorporate the student’s and advisor’s constraints into a plan.

Dependencies TC-03-01Traceability TC-03-03

Test Case Number TC-03-03: Impossible Test Case

Test Item Item evaluates the total system with an impossible input case. It is an impossible case where the user has made decisions which can not be resolved into a valid study plan. This test case confirms that when issues arise, that the system addresses the problems accordingly. This involves appropriate communication to the user that there is an issue and some troubleshooting to identify the offending inputs, so the user can rectify the situation and try again.

Test Priority M (Must have)Input Specifications User will log into the system and attempt to input simulated student information into the appropriate

User Interface prior to initiating study plan generation. .


System will provide an error message to the user identifying that a study plan solution could not be identified due to the inputs: CS 492, CS 392, CS 385

Pass/Fail Criteria Study plan failed to find a solution for the student’s and advisor’s constraints.

Dependencies TC-01-01, TC-03-02Traceability None

*Subset of Test Case Parameters

^WCs Tested exclusively by TC-03.

Operational Concept Document

Team 6 - Student Scheduling System:

Douglass Kinnes, Alexey Tregubov, Mihir Daptardar, Ihsan Tolga, Zheng Lu, Simone Lojeck



10

OCD Plan Outline

System purpose Proposed new system Benefit-chain diagram System boundary Desired capabilities and goals


11

System Purpose

Why do we need the system?The purpose of the system is to generate a semester-by-semester study plan for undergraduate computer science students studying at Stevens Institute of technology based on their inputs.

Is there a current system?Yes, but the current system is a manual. A brief description of the system is as follows:

The students have to schedule an appointment with the advisor Once an appointment is granted, they have to let the advisor know about

their graduation date and courses they wish to take The advisor then drafts a schedule based on the inputs


12

Proposed new system

•Here is a very brief and general overview about new proposed system:

The student logs into the system Upon successful login, the student has to choose his degree and input his

desired semester and year of graduation The student then chooses his/her preferred courses and other

requirements (transfer credits, internship credits, etc.) The system would then construct a student plan which tries to satisfy the

students requirements


13

Benefit Chain Diagram

Develop, deliver and fill the system with initial data

Developers

Stevens’ students

Stevens’ advisors

Hold training sessions

Inform new students about the

system

Efficient study plan

construction

Reduce students

frustration

Reduce number of

errors in Study plans

Students are aware about the system

Automated system for study plan construction

Faster study planconstruction

Assumptions:1. Students and advisers will use new system.2. Available courses and degree requirements will be kept up to date.

Automated system for study plan construction,

that check errors

Stevens’ course directors

Keep degree requirements and available courses in the

system up to date

Keep the systemup to date

Enhance the system

Software maintainers

System administrators

Move server from USC hosting to Stevens hosting

and maintain the server

Stabilizing the system

Migrating the system

Save time

Students are aware about the system, that helps them

automatically construct study plan


14

System Boundary


15

Desired capabilities and goals

System Capabilities:

The system should be able to construct a custom schedule based on the inputs of the student

If the inputs are too rigid, the system then should relax the constraints and come up with a alternate schedule

If the inputs are out of bounds, then the system should either suggest or ask the student to change or modify the inputs


16

Prototype

• Team 6 - Student Scheduling System:

• Douglass Kinnes, Alexey Tregubov, Mihir Daptardar, Ihsan Tolga, Zheng Lu, Simone Lojeck



17

Changes

• Navigation Flow• Prototype GUI• Development Prototype• Prototype Algorithm

04/20/23


18

Navigation Flow

04/20/23


19

Prototype GUI

04/20/23


20

Prototype UI contd.

• Background etc will all be different and more readable

• More neutral colors, less harsh.• Represents the information on the page• Links will not be blue, nor will background be

black• Breadcrumbs for navigational awareness• PreReq/CoReq input still being prototyped

04/20/23


21

Development Prototype

• Play Framework• User Interface still rough• Basic interface and controller logic exists• Incremental prototype

– First prototype for input to heuristic/solver testing– Increments after that focusing on usability

04/20/23 21


22

Algorithm prototype


23

Integer Linear ProgrammingTools: MS Excel ILP and LP solvers

Total number of courses:

40

Number of semesters:

4

Number of constraints:

3

Prerequisites: 3

Corequisites: 2

Time: <1 seconds (for both cases with solution and without)

Difficulties: Excel solver is limited to 200 decision variables.It is difficult to input all the constraints manually.


24

Summary for ILP-solving approach

• Continue exploring• UI for testing real-life test cases


25

Constraint Programming Tools: Java, Choco constraint solverTotal number of courses:

100

Number of semesters:

8

Number of constraints:

3

Prerequisites: No Corequisites: NoTime: <5 seconds for test case where solution is

possible; >5 minutes for test case with no solution.

Difficulties: It is difficult to make test case more complicated, because it takes too much time to enter all necessary data in Java code.


26

CP-Solving: backtracking


27

Summary for CP-solving approach

• Refine branching strategy by using – consistency techniques– constraint propagation– variable ordering

• Use of other heuristics to reduce solution space

• UI for testing real-life test cases


28

Study plan construction


29

Architecture

• Team 6 - Student Scheduling System:

• Douglass Kinnes, Alexey Tregubov, Mihir Daptardar, Ihsan Tolga, Zheng Lu, Simone Lojeck



30

Changes and updates

•Refined: •High-level architecture•Interfaces between layer (MVC)•Artifacts & information •Algorithm


31

Deployment diagram


32


33

DB Schema


34

Interface Class Diagram


35

Study plan construction class diagram


36

Request Study Plan Sequence Diagram


37


38

Architecture styles, patterns and frameworks

•Styles: •Client-server•REST

•Patterns:•Three-tier

•Technological frameworks:•MySQL•Java•Play framework for Java.

•NDIs:•CHOCO library – constraint solver


39

Life Cycle Plan


40

Life Cycle Plan

Revised Rebaselined Foundations Phase Rebaselined Foundation Phase Deliverables Project Estimations Roles & Responsibilities Plans for Upcoming Phases Iteration Plan


41

Current Phase – Rebaselined Foundations Phase

01/14/2013 – 02/20/2013 Milestone: Architecture Board Review – Rebaselined Development

Commitment Review

Deliverables RDC Package (OCD, SSAD, LCP, FED, QMP, PRO, TP, TPC, SID) Core Constraint Solver Core Course Database Simulated User Data Core Study Plan Constructor Test Cases – Plans Core User Interface Controller Modules ER, PR, COTIPMO Reports, Project Plans, Meeting Notes

Life Cycle Plan


42

Project Estimations - COCOMO

Life Cycle Plan


43

Project Estimations - COCOMO

Life Cycle Plan


44

Project Estimations - COTIPMO

Life Cycle Plan


45

Project Estimations

Scale factor is 15.6 PREC was set to LO. TEAM was set to VHI

Estimated total SLOC is 5000. (excluding framework) Estimated total effort is 6.6 person/month most likely (COTIPMO

survey, former (foundations phase estimation was 11.47) According to the recent PM estimations, 4.20 persons are

needed to complete the project within the time limits of CS577a and CS577b.

It can be done within the CS577a and CS577b course periods and with 5 team members. (1 missing team member in CS577b)

Previous scale factors reside.

Life Cycle Plan


46

Roles & Responsibilities

Revised development roles due to personnel turnover 5 development team members for CS577b. No new team member for CS577b.

Alex, Mihir : Solver Algorithm Implementation, Solver Library Integration, Database Implementation

Doug, Ihsan: User Interface, Templates Implementation, Controller Modules, Authentication, UI-Database Integration

Simone : Test Plans and Cases, CCD Preparation

Life Cycle Plan


47

Development Phase Activities - Construction

01/14/2013 – 02/28/2013 Concept: Implementation of solver algorithm,

complete database implementation with simulated administrators, integration of problem solver libraries to algorithm, complete user interface / controller classes, regular weekly client meetings, effort/progress reports, risk mitigation.

Deliverables: Scheduling Algorithm, Test Cases, Executable Beta Product, Effort Reports, Progress Reports, Project Plan, Complete Transition Plans, Complete User Interface

Strategy: Incremental Commitment Cycles, Weekly Sprints (Architected-Agile) (Starts in Fridays with Sprint Backlogs)

Life Cycle Plan


48

Development Phase Activities - Transition

03/01/2013 – 04/29/2013 Concept: End implementation of system algorithm,

assessing the system capability, implementation database and UI integration, continue risk assessment process, system transition, documenting User’s Manual, Deliverable Product Package, regular weekly client meetings, effort/progress reports, risk mitigation.

Deliverables: Final Student Scheduling System software product, Project Test Case. User’s Manual, Development Documents, Source Files.

Strategy: Incremental Commitment Cycles, Weekly Sprints (Architected-Agile), Team feedbacks and bug resolving.

System Installation : 04/19/2013 04/29/2013 - Operational Commitment Review for Initial

Operational Capability 05/07/2013 – Client Evaluation

Life Cycle Plan


49

Iteration PlanID Capability Description Priority Iteration1 Solving schedule

constraints.The prototype algorithm will solve the course constraints. 1 1

2 User Interface Prototype

We are forming mock-up user interface prototypes before starting implementing them in Java.

2 1

3 Test-case for constraint solver

We are implementing draft a test-case (courses, constraints) to test the scheduling algorithm.

3 1

4 Formalism for Specifying

Requirements

We are documenting a formalism document as a implementation guideline for future development phase.

2 1

5 Mathematical Model

We are forming a mathematical model in which we will define the course information and constraints.

1 2

6 Solver Library We are defining the software architecture for best interconnection between the modules and database

connection.

2 2

7 Entering Course Information

Input

Administrative side will be able to enter course information. Thus we are implementing prototypes related to input

format and specifications.

2 2

8 Controller Modules

Implementing controller classes operating between user interface and database for data inputting, schedule

constructing with provided data from solver, authentication for administrative side.

2 2

Life Cycle Plan


5004/20/23

Life Cycle Plan


51

Project Plan

Rebaselined Foundations Phase (CS577b)

3 Weeks focused on

Implementing solver module, controller / UI

PLAY framework

Preparing for RDCR ARB

Development Phase

10 Weeks, 5 Modules

Relaxation for response time

Weekly sprints

Developed concurrently in steps by two main teams

More time/focus on modules with more risk.

Life Cycle Plan


52

Project Plan (Development Phase)

Modules

Each module is split into pieces

For each piece there are programming, unit tests and function tests.

For each module there are unit tests and function tests for brought together pieces.

There are always two pieces being developed/implemented at one time.

Team A: Alex, Mihir (DB, Research, Solver/Algo)

Team B: Doug, Ihsan (Views, Controllers, Wrapper)

With Simone doing module tests, CCD Preparation.

After implementing controller modules and UI, Team B will move in Team A with respect to the related risk.

Life Cycle Plan


53

Feasibility Evidence


54


Revised / Added Risk Assessment Traceability Matrix Definition of Done


55

Risk AnalysisRisks

Risk ExposureRisk MitigationsPotential

MagnitudeProbability

LossRisk

Exposure

Undeveloped complex algorithm 6 636 Developing an early algorithm during

Foundations Phase as a prototype which works with a smaller domain.

Long response (for study plan building) time compared to the requirements. 5 6 30

Prototyping constraint solver module with test-case information in the foundation phase for benchmarking and feedback..

Not designated maintainers.5 3 15

It is mentioned to the client (Nature of CS577a/b schedule) since it is client side’s responsibility to maintain system after the transition phase. Stevens web hosting maintainers may be responsible for this role.

The interface required by the customer and provided by the development team may be different.

4 3 12Prototyping complete user interfaces in the foundation phase and give feedbacks from the customer about its defects and strong points and setting a final agreement upon them.

Team process inexperience related to ICSM methods. 3 3

9 Following ICSM EPG guideline, package reviews by TAs and evaluations.

Requirements Volatility (New procedures by Stevens management) 2 3

6 Prototyping, weekly negotiations



56

NDI/NCS Operability

NDI/NCS Products PurposesCHOCO Java Library To use its defined functions/classes

in the “solver” module. It is an open source library thus it brings no extra cost for the project.

Apache Web Server It will be used for setting the software running on school’s webpage.

MySQL It is used for implementing database entities and module. (course information, constraints.)

PLAY Framework* It provides a strong basis for web-based application, saves time on implementing user interface and controllers. Besides it is open source.



57

Traceability Matrix

OCD WinWin Agreement SSAD Test CaseOC-1 WC_1512 UC-6 TC-01

TC-03-02OC-2 WC_1329 UC-7 TC-02-02OC-2 WC_1349 UC-9

UC-10TC-02-04

OC-3 WC_1354 UC-6 TC-01TC-03-02

OC-3, OC-2 WC_1353WC_1352WC_1348WC_1347WC_1346WC_1345

UC-1UC-2UC-3UC-4UC-5

TC-01TC-03-02

OC-3 WC_1533WC_1512WC_1355

UC-6 TC-01TC-03-02TC-03-03

OC-2 WC_1350WC_1329

UC-7UC-8

TC-02-02

OC-2 WC_1355 UC-6 TC-03-03LOS-1 WC_1357 TC-03-02CO-1 WC_1356 CO-2 WC_1356 CO-3 WC_1357 TC-03-02



58

Definition of Done For Iteration 1

1 Test cases formed and ready.

2 Solver algorithm can work with given simulated inputs.

3 Core user interface implemented and can get simulated inputs as arguments for algorithm.

4 Core controller classes implemented and they can pass data from user interface to solver algorithm and construct study plan with given data from solver.

5 Controller classes can log the testers in by using given simulated user privileges.

6 Core database module implemented and connected with solver algorithm to retrieve course data.

7 Tester (User) can navigate through the system and template screens by clicking button on user interface. System opens with main screen and general user interface to lead the tester.

8 Study plan construction response time limit is relaxed.
