Download
1 / 87
870 likes | 976 Vues
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.
E N D
Team #10 Student Scheduling System Part II FCR ARB Bo Wang, BohanZheng, ChenyangBai, Xiaoran Li, Rui Tong, Shuai Wang, Frank Varela
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!”
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.
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.
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.
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
There is only ONE main goal! That is
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.
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.
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.
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.
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.
The course director needs to add/update degree program as following steps: add courses-> add courses groups-> add requirements ->add degree programs.
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.
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.
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.
