1 / 87

Student Scheduling System Part II FCR ARB

Team #10. Student Scheduling System Part II FCR ARB. Bo Wang, Bohan Zheng , Chenyang Bai , Xiaoran Li, Rui Tong, Shuai Wang, Frank Varela. Remote Team Member. Team’s Strong Points. Operational View. Technical View.

myrna
Download Presentation

Student Scheduling System Part II FCR ARB

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 #10 Student Scheduling System Part II FCR ARB Bo Wang, BohanZheng, ChenyangBai, Xiaoran Li, Rui Tong, Shuai Wang, Frank Varela

  2. Remote Team Member

  3. Team’s Strong Points Operational View Technical View Extensive knowledge of programming languages/environments. Low Level: Assembly, C/C++ Managed languages: C#, Java UI: QT, MFC Scripting: PHP, Python, Perl Web: HTML, JavaScript, CSS, XML, JSP Database: MySQL IDE: Eclipse, Visual Studio, Dreamweaver • Highly motivated. • Shared responsibilities. • Good team players. • Diligent and hard working. • Punctual with deliveries. • Good negotiation skills with client. • Good project management. • Very responsive. • Milestone/delivery tracking. • Provides extra motivation. • Ends almost all e-mails with “Fight On!”

  4. Team’s Weak Points Operational View Technical View No team member has any experience with some of the libraries and or frameworks utilized in the leveraged software. PLAY framework. • Lack of collaborative history between some teammates. • First time the off-campus student is working with any of the team members. • Ineffective team communication. • Sparse details in meeting notes. • No action items linked to owners. • Open issues not highlighted. • Progress of tasks unclear. • No regularly scheduled team meeting. • Schedule complexity among all members of team makes it difficult to regularly meet.

  5. Technical Concerns • Concern #1: • Lack of prior experience/understanding of the primary “Solver” algorithm. • Possible Solution: • Increase frequency and effectiveness of communication with the algorithm designer. • Concern #2: • Relatively low practical “Real World” development experience. • Possible Solution: • Increase effective communication amongst team in to collaborate and collectively solve challenges and resolve any road blocks.

  6. Operational Risks • Risk #1: • Lack of a regular “effective” communication due to very busy schedules for each team member. • Possible Mitigation: • Increase verbosity in team meeting notes. • List open issues and proposed resolution strategies. • Specify status of tasks in progress. • Enumerate action items with assigned owners and delivery dates. • Make usage of more collaboration tools. • Shared project pages (e.g. Wiki or discussion board). • Collaborative document editing/sharing tools (e.g. Google Docs). • Schedule at least 1 team meeting on a regular basis. • It could be on the weekend or more convenient time for everyone. • It doesn’t have to be long, just enough to make sure that no critical issues are blocking people.

  7. Requirements

  8. Based on last year project. • Current scenario: Manually choose courses • Problem with current system: Slow solver • Project shared Vision: 1. Run faster 2. Enhance system GUI

  9. There is only ONE main goal! That is

  10. Five categories

  11. Algorithm & Level of Service

  12. System Constraints

  13. User Interface

  14. Tools and Languages

  15. Operational Concept Description

  16. System Purpose

  17. The vision for this system is to create an easier and less complicated way for students to be able to create schedules in order for them to graduate in the time frame they desire. • The major goal for system part II is to improve efficiency for students to generate study plan with more clear and friendly user interface.

  18. Shared Vision

  19. The Program model

  20. Benefits Chain Diagram

  21. SystemBoundary&Environment

  22. System Objectives Constraints & Priorities

  23. Capability Goals

  24. Levelof Service Goals

  25. Organizational Goals

  26. OG-1: Improve better user satisfaction via clearer and friendlier user interface design. OG-2: Reduce frustration of the course director via better error hint during degree program construction phase. OG-3: Reduce frustration of the course director and students during study plan construction phase.

  27. OG-4: Save time by allowing students to create schedules on their own time. OG-5: Reduces incorrect course selection. OG-6: Improve speed and reduce the study plan construction time via more efficient algorithm.

  28. Constraints

  29. CO-1: Zero Monetary Budgets. CO-2: The system must use technological infrastructure that can be maintained by client. CO-3: The current system shall be compatible with the previous version of the system written by the Play Framework and MySql.

  30. Proposed New System

  31. Element Relationship Diagram

  32. Business Workflows

  33. Organizational and Operational Implications

  34. OrganizationalTransformations

  35. The need to make sure that the if the server in SIT could support for the proposed system • The need to hire a maintainer to take care of the system. • The need for system to store study plans. • The need separately store courses, course groups, requirements and degree programs in database.

  36. OperationalTransformations

  37. The course director needs to add/update degree program as following steps: add courses-> add courses groups-> add requirements ->add degree programs.

  38. The course directors would have to update the degree programs online. This can be as minor as adding or updating a course in the current degree requirement or as major as adding a new degree programs and its corresponding requirements. They may also authorize any other employee (ex: a student worker, part time employee) to update degree programs.

  39. The proposed systems reduce workloads for course directors. They don’t need to teach students how to generate study plan manually, update degree requirements and course selection limitation by modifying the department website than announce it to all students. Also they don’t need to help students to fix their plan bugs manually, With the proposed system, they could make any requirement change by updating database and teach students how to use the systems.

  40. Students don’t need to fill in their desire in one step and wait for result coming out without error hints. With new system, students needs to fill in their desires step by step: add basic & history information-> add desire courses -> add desire course order ->relax desires -> get study plan.

  41. Students’ info

  42. Course selection

  43. Semester selection

More Related