1 / 58

Team 06: Student Scheduling System

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

Download Presentation

Team 06: Student Scheduling System

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

  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

  3. DEN Observations – Strong/Weak Pts.No Significant Changes • Team’s Strong Points: • Operational View: • Strong Team Communication / Coordination • High Level of Team Involvement • Technical View: • Wide Array of Team Capabilities • Team’s Weak Points: • Operational View: • Widespread Physical Location • Unfamiliar with ICSM Process • Technical View: • Experience Mostly limited to Scholastic Projects • Limited Development/Deployment Experience • Strong Points Supported & Weak Points Mitigated with: • Weekly Skype Meetings • Frequent Email Communication

  4. DEN Observations – Shaping & EvalNo 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. Test Plan and Cases - Overview • 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

  6. Test Plan and Cases: TC-01: Study Plan Construction • 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 *Subset of Test Case Parameters

  7. Test Plan and Cases: TC-02: Degree/Course Maint. • Test Case Satisfies Minimum Marketable Feature: • Enter Degree Requirements • Sub Test Cases will Test Requirements: • WC_1329 • WC_1349 • WC_1350 *Subset of Test Case Parameters

  8. Test Plan and Cases: TC-03: Level of Service • Test Case Satisfies All 3 Minimum Marketable Features: • Construct Schedule • Student Specify Courses • Enter Degree Requirements • Sub Test Cases will Test Reqs: • WC_1345 • WC_1346 • WC_1347 • WC_1348 • WC_1352 • WC_1353 • WC_1354 • WC_1355^ • WC_1357^ • WC_1512 ^WCs Tested exclusively by TC-03. *Subset of Test Case Parameters

  9. Operational Concept Document 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

  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 Operational Concept Document • 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

  18. Navigation Flow

  19. Prototype GUI

  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

  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

  22. Algorithm prototype

  23. Integer Linear Programming

  24. Summary for ILP-solving approach • Continue exploring • UI for testing real-life test cases

  25. Constraint Programming

  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 Operational Concept Document • 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. DB Schema

  33. Interface Class Diagram

  34. Study plan construction class diagram

  35. Request Study Plan Sequence Diagram

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

  37. Life Cycle Plan

  38. Life Cycle Plan • Revised • Rebaselined Foundations Phase • Rebaselined Foundation Phase Deliverables • Project Estimations • Roles & Responsibilities • Plans for Upcoming Phases • Iteration Plan

  39. Life Cycle Plan • 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

  40. Life Cycle Plan • Project Estimations - COCOMO

  41. Life Cycle Plan • Project Estimations - COCOMO

  42. Life Cycle Plan • Project Estimations - COTIPMO

  43. Life Cycle Plan • 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.

  44. Life Cycle Plan • 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

  45. Life Cycle Plan • 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)

  46. Life Cycle Plan • 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

  47. Life Cycle Plan • Iteration Plan

  48. Life Cycle Plan

More Related