student scheduling system part ii fcr arb

87
Student Scheduling System Part II FCR ARB Bo Wang, Bohan Zheng, Chenyang Bai, Xiaoran Li, Rui Tong, Shuai Wang, Frank Varela Team #10 1

Upload: gauri

Post on 23-Mar-2016

37 views

Category:

Documents


0 download

DESCRIPTION

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. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Student Scheduling System Part II FCR ARB

1

Student Scheduling System Part II

FCR ARBBo Wang, Bohan Zheng,Chenyang Bai, Xiaoran Li,Rui Tong, Shuai Wang,Frank Varela

Team #10

Page 2: Student Scheduling System Part II FCR ARB

2

Remote Team Member

Page 3: Student Scheduling System Part II FCR ARB

3

Team’s Strong Points

Operational View• 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!”

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

Page 4: Student Scheduling System Part II FCR ARB

4

Team’s Weak Points

Operational View• 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 View• No team member has any experience

with some of the libraries and or frameworks utilized in the leveraged software.

– PLAY framework.

Page 5: Student Scheduling System Part II FCR ARB

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.

Page 6: Student Scheduling System Part II FCR ARB

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.

Page 7: Student Scheduling System Part II FCR ARB

7

Requirements

Page 8: Student Scheduling System Part II FCR ARB

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

Page 9: Student Scheduling System Part II FCR ARB

9

There is only ONE main goal!

That is

Page 10: Student Scheduling System Part II FCR ARB

10

Five categories

Page 11: Student Scheduling System Part II FCR ARB

11

Algorithm & Level of Service

Page 12: Student Scheduling System Part II FCR ARB

12

System Constraints

Page 13: Student Scheduling System Part II FCR ARB

13

User Interface

Page 14: Student Scheduling System Part II FCR ARB

14

Tools and Languages

Page 15: Student Scheduling System Part II FCR ARB

15

Operational Concept Description

Page 16: Student Scheduling System Part II FCR ARB

16

System Purpose

Page 17: Student Scheduling System Part II FCR ARB

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.

Page 18: Student Scheduling System Part II FCR ARB

18

Shared Vision

Page 19: Student Scheduling System Part II FCR ARB

19

• The Program model

Page 20: Student Scheduling System Part II FCR ARB

20

Page 21: Student Scheduling System Part II FCR ARB

21

• Benefits Chain Diagram

Page 22: Student Scheduling System Part II FCR ARB

22

Page 23: Student Scheduling System Part II FCR ARB

23

System Boundary & Environment

Page 24: Student Scheduling System Part II FCR ARB

24

Page 25: Student Scheduling System Part II FCR ARB

25

System Objectives Constraints & Priorities

Page 26: Student Scheduling System Part II FCR ARB

26

• Capability Goals

Page 27: Student Scheduling System Part II FCR ARB

27

Page 28: Student Scheduling System Part II FCR ARB

28

•Level of Service Goals

Page 29: Student Scheduling System Part II FCR ARB

29

Page 30: Student Scheduling System Part II FCR ARB

30

•Organizational Goals

Page 31: Student Scheduling System Part II FCR ARB

31

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.

Page 32: Student Scheduling System Part II FCR ARB

32

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.

Page 33: Student Scheduling System Part II FCR ARB

33

•Constraints

Page 34: Student Scheduling System Part II FCR ARB

34

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.

Page 35: Student Scheduling System Part II FCR ARB

35

Proposed New System

Page 36: Student Scheduling System Part II FCR ARB

36

•Element Relationship Diagram

Page 37: Student Scheduling System Part II FCR ARB

37

Page 38: Student Scheduling System Part II FCR ARB

38

• Business Workflows

Page 39: Student Scheduling System Part II FCR ARB

39

Page 40: Student Scheduling System Part II FCR ARB

40

Organizational and Operational Implications

Page 41: Student Scheduling System Part II FCR ARB

41

• Organizational Transformations

Page 42: Student Scheduling System Part II FCR ARB

42

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

Page 43: Student Scheduling System Part II FCR ARB

43

• Operational Transformations

Page 44: Student Scheduling System Part II FCR ARB

44

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

Page 45: Student Scheduling System Part II FCR ARB

45

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

Page 46: Student Scheduling System Part II FCR ARB

46

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

Page 47: Student Scheduling System Part II FCR ARB

47

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

Page 48: Student Scheduling System Part II FCR ARB

48

Students’ info

Page 49: Student Scheduling System Part II FCR ARB

49

Course selection

Page 50: Student Scheduling System Part II FCR ARB

50

Semester selection

Page 51: Student Scheduling System Part II FCR ARB

51

Courses List

Page 52: Student Scheduling System Part II FCR ARB

52

Course information

Page 53: Student Scheduling System Part II FCR ARB

53

Group List

Page 54: Student Scheduling System Part II FCR ARB

54

Group information

Page 55: Student Scheduling System Part II FCR ARB

55

Complex Group

Page 56: Student Scheduling System Part II FCR ARB

56

Requirement

Page 57: Student Scheduling System Part II FCR ARB

57

Degree Program

Page 58: Student Scheduling System Part II FCR ARB

58

Architecture

Page 59: Student Scheduling System Part II FCR ARB

59

Top-level Physical Architecture

Page 60: Student Scheduling System Part II FCR ARB

60

Top-level Logical Architecture

Data Set

Data Access

User Interface

Data Processing

Solver

Graphical Display

UserInterface

Events

Page 61: Student Scheduling System Part II FCR ARB

61

NDI Choices

WC_2660: The current system shall be compatible with the previous version of the system written using the Play Framework and MySql.

Page 62: Student Scheduling System Part II FCR ARB

62

• Key Stakeholder’s Responsibilities

Life Cycle Plan

• Life Cycle Strategy

• Resource Estimation

• Project Plan for Foundation Phase

Page 63: Student Scheduling System Part II FCR ARB

63

Life Cycle Strategy (Architected Agile)

Phase Strategy

Exploration One Incremental Commitment Cycle;

ValuationWin-Win Negotiation;

Prototyping to Mitigate Risks;Design Top-Level Architecture;

FoundationDetail Project Plan;

Learn Required Technologies;Assess Architecture;

Development Collaborate on Construction;Alpha Testing;

Operation Transition; Training; Beta Testing;

Page 64: Student Scheduling System Part II FCR ARB

64

Project Plan for Foundation Phase

Task Name Duration Resource Name

Detail Project Plan 7 days Project ManagerLife Cycle Planner

Learn Play Framework 15 days Implementation Team

Develop DC Package 7 days All Team Members

Assess Feasibility Evidence 7 days Feasibility Analyst

Verify & Validate Win Conditions 7 days IV & V

Assess Architecture; 7 days System Architecture

10/21 – 12/09

Page 65: Student Scheduling System Part II FCR ARB

65

Key Stakeholder’s Responsibilities

Role Responsibilities

Client Participate in Win-Win Negotiation(Represent Maintainer & User)

Team Follow ICSM EPG

Maintainer Participate in TrainingMaintain Course Data

User Participate in Beta TestProvide Feedback

Page 66: Student Scheduling System Part II FCR ARB

66

Resource Estimation

No. Module Name Brief Description SLOC REVL

1 Data Set Information of Courses 300 5%

2 Data Access Manipulate Database 800 10%

3 Data Processing Formats Data Between Structures 500 10%

4 Solver Generates Study Plan 1700 15%

5 GUI Friendly UI with Clear Layout 3300 20%

Page 67: Student Scheduling System Part II FCR ARB

67

Resource Estimation

Page 68: Student Scheduling System Part II FCR ARB

68

Resource Estimation

Cost Driver Value Rationale

PVOL Low Low frequency to have platform changed.

PCAP Very High All team members are good programmers

PCON Very High All members will participate in CS577b

Page 69: Student Scheduling System Part II FCR ARB

69

Feasibility Evidence

1.Business Case

2.NDI Analysis and Results

3.Major Risks

4. 5 Personas

Page 70: Student Scheduling System Part II FCR ARB

70

Business Case(program model)

Page 71: Student Scheduling System Part II FCR ARB

71

Cost Analysis(Personnel Costs)Activities Time Spent (Hours)

Development period(24weeks)

Exploration,Valuation and Foundation Phases: Time Invested (C577a, 12 weeks)

Online win-win session with client(2hours*2sessions*8 people)32

Online meetings with client via video-conference(2hours/week*12 weeks* 7peopel)168

Architecture review boards(1.5hours*2sessions*8people) 24Analyzing current system(8hours*6people) 48Defining requirement of UI 15Defining requirement of algorithm 15Creating project website 5User interface prototyping 15Life Cycle Planning and Documenting 24Feasibility Evidence Description and Documenting 24System and Software Requirement Development 24Operational Concept Development 24System and Software Architecture Development 24Quality Management 18Team Meetings 36Sub Total 496

Development and Operation Phases: Time Invested (CS577b, 12 weeks)

Online meetings with client via video-conference(2hours/week*12 weeks* 7peopel)168

Architecture review boards(1.5hours*2sessions*8people) 24Implementation (10hours*6people*8weeks) 480Testing 120Verifying and validating work products 18User training 6Maintainer training 15Documenting 60Sub Total 891

Total 1387

Maintenance Period(1Year)(5hours/day*24weeks) 120Total 120

Page 72: Student Scheduling System Part II FCR ARB

72

Cost Analysis-Hardware and Software Costs(Development)Type Cost Rationale

Winbook $0 It is available in CSCI577 students’ tools, this item is free.

Bugzilla $0 It is available in CSCI577 students’ tools, this item is free.

COCOMOII/COINCOMOII $0 It is available in CSCI577 students’ tools, this item is free.

JAVA SDK $0 It is open source software, this item is free.

Eclipse $0 It is open source software, this item is free.

Play framework $0 It is open source software, this item is free.

MySQL $0 It is open source software, this item is free.

Apache Web Server $0 It is open source software, this item is free.

Balsamiq $0 Free demo version is used for project, so it is free.

Microsoft Project $0 USC grants free license for this software, so it is free

Visual Paradigm for UML $0 Free demo version is used for project, so it is free.

Page 73: Student Scheduling System Part II FCR ARB

73

TYPE COST RATIONALE

Hardware Web-Server

$0 The current server of Stevens Institute of Technology will be used for this item. So there is

no additional cost.

Hardware Web-Hosting

$0 The current hosting of Stevens Institute of Technology will be used for this item. So there is

no additional cost.

Cost Analysis-Hardware and Software Costs(Operation)

Page 74: Student Scheduling System Part II FCR ARB

74

Current activities & resources used % Reduce Time Saved (Hours/Year)

Students build their own plan(2 hours average/student*2500=5000hours) 80% 4000

Students realize their degree and course requirements(2 hours average/student*2500=5000hours) 20% 1000

Administrators help students to build their study plan(15minutes average/student*2500=625hours) 40% 250

Total 5250

Benefit AnalysisWith the Student Scheduling System, students can reduce the time and effort of making study plan. What is more, this system can also save time for both students and advisors by reducing their conversation time about study plan.

Page 75: Student Scheduling System Part II FCR ARB

75

Year Cost Benefit(Effort Saved)

Cumulative Cost

Cumulative Benefit ROI

2013 496 0 496 0 -1.00

2014 1071 2625 1567 2625 0.68

2015 132 5250 1699 7875 3.64

2016 145.2 5250 1844 13125 6.12

ROI Analysis

Note: In 2013, cost just contains Fall semester(Exploration, Valuation and Foundation period). In 2014, cost contains Spring Semester(Development and Operation period), Fall Semester(Maintenance period). Benefit contains Fall Semester.

Page 76: Student Scheduling System Part II FCR ARB

76

Figure 1: ROI Analysis Graph

Page 77: Student Scheduling System Part II FCR ARB

77

NDI Analysis and Result(1) MySQL

It is used for implementing database entities and module, such as save course information and constraints about course select. It is quite capable for database needs and brings no extra costs since it is open source, and it can applied to all platform.

(2) Paly Framework

It is used for User Interface and Controllers. It will save a great deal of time on implementing controller

interface, since it has a large number of modules, and there is no need to find other integration frameworks. With the aid

of Play Framework, more focus can be given on more risky aspects of the project.

Page 78: Student Scheduling System Part II FCR ARB

78

Major Risks

RisksRisk Exposure

Risk MitigationsPotential Magnitude

Probability Loss

Risk Exposure

Long response time 8 6 8 Based on previous algorithm, we could improve searching strategy efficiency by adding heuristic factor. Since there are many students choosing their study plans. It means we could get many existing study plan from many students 'choices. So we could use data mining algorithm like Decision tree.Thus we can reduce the load of code analysis and reengineering.

User interface mismatch 6 8 48 Identifying what is exactly client want. Early Prototype and Specify error expression when an error occurs. Improving javascript formula validation. We can provide nicer HTML/CSS user interface.

Communication Misinterpretation

5 5 25 Exchange ideas and report progress in time through weekly negotiations

Heavy Schedule 4 4 16 Make a detailed plan for each phase, predicting the time cost in each phase and distributing time reasonable.

Do not clearly realize the system constrains about the existing product

5 3 15 We should have a further communication with the students in SIT and the previous developers.

Relative low practical development experience of team members.

2 1 2 Reference to some successful cases and absorb experience form it. On the other hand , discussing positively among team members when meet problems. Further more, intensify the communication with clients, make sure what they really want us to do.

Page 79: Student Scheduling System Part II FCR ARB

79

PersonasAndrew: Freshman in SIT Computer Science School

Basic Demographic:Age: 18 Gender: MaleOccupation: CS StudentHometown: New York CityMarital Status: Not Married

Description: Andrew just graduated form BYD high school and got offer from several Universities, then he decided to go to SIT and major in computer science. Cause he interested in programming Apps for cellphone since he was in middle school.

User Scenario: Andrew has designed 3 Apps for ios platform and he is familiar with C language and Java. But on the other hand, he is confused about what other knowledge the SIT CS School offer can attract him because he want to get more skill about CS not only cellphone Apps.

Attributes: Interested in CSAlready have some basic knowledge and practical experience in coding.

Goals and Aspirations: Explore more knowledge in CSFinding domain he does not touch before and related courses.Keep developing his interest in programming Apps for cellphone.

Information source:Gmail, Facebook, Twitter.

Page 80: Student Scheduling System Part II FCR ARB

PersonasTracy: Failed in two exams and retake courses

Basic Demographic:Age: 21Gender: FemaleOccupation: CS StudentHometown: ChicagoMarital Status: Not Married

Description: Tracy is a Junior student in SIT, she Failed in two final exams last year, so she need to retake the two courses this year and get the credit back.

User Scenario: Tracy failed in the exam last semester but she do not think it is her real ability. She wants to prove herself in the coming semester ans she has to retake the two courses this year, she want to know how to conduct it.

Attributes: Retake coursesBusy schedule

Goals and Aspirations: She wants to take courses which are more helpful to her to get practical skillsShe want to graduate in time although she is changing major, so she want to take as more courses as possible.

Information source:Gmail, Facebook, Twitter.

Page 81: Student Scheduling System Part II FCR ARB

81

PersonasLucy: Double major student in SIT CS School and Political School

Basic Demographic:Age: 19Gender: FemaleOccupation: CS, Political studentHometown: BostonMarital Status: Not Married

Description: Lucy was top students in class science she was in middle school, she has talent absorbing all kinds of knowledge, so she can get more knowledge than others using same times. What is more, she is eager to learn different things and exploring different domain.

User Scenario: Occupied with the strong ability of learning, Lucy has enough times and energy to handle two major’s courses. At the same time, she should be careful of the time conflicts of courses, because her schedule is very busy.

Attributes: Double majorHigh talentBusy schedule

Goals and Aspirations: She wants to arrange her time reasonable, so she should make sure which course must be take in a certain semester(some courses just offered in one semester in the whole year) and the priority among courses. She also wants to know how much courses she can take in one semester.

Information source:Gmail, Facebook, Twitter.

Page 82: Student Scheduling System Part II FCR ARB

82

PersonasByron: Transfer student in SIT CS School

Basic Demographic:Age: 20Gender: MaleOccupation: CS StudentHometown: New JerseyMarital Status: Not Married

Description: Byron has finished freshman and Sophomore study in IIT, and he decide to transfer to SIT this summer, because he think it is near his hometown and SIT’s CS department is more competitive.

User Scenario: Byron his finished first two years study in IIT major in CS, so he has take the basic courses in CS, and he found him self interest in software engineering, he also get excellent performance in his classes.

Attributes: Transfer studentAlready took two years courses in CS

Goals and Aspirations: He want to transfer his credit form IIT to SIT and do not take same courses again.He want to development his interest in software engineering.

Information source:Gmail, Facebook, Twitter.

Page 83: Student Scheduling System Part II FCR ARB

83

PersonasJordan: One of the administrators in SIT CS School

Basic Demographic:Age: 30Gender: MaleOccupation: Administrators in CSHometown: New York CityMarital Status: Married

Description: Jordan is a administrators in CS School, he got married 3 years ago and know he has a 2 years old daughter. His duty is to input courses and course’ introduction to the Study Scheduling System. Also has duty to help students make their study plans.

User Scenario: Because many students confused by the course selecting rules, so Jordan has to introduce many details to students, which will take a lot of time and lead to repeating work and work overtime. On the other hand Jordan wants to spends more time with his daughter.

Attributes: Repeating workWork overtimeBusy

Goals and Aspirations: He wants a system to lighten his workload, which can easily accept by students in short time.He also needs higher limits of authority, so he can add courses or delete courses depend on need, sorting courses, affirming the degree requirement.

Information source:Gmail, Facebook, Twitter.

Page 84: Student Scheduling System Part II FCR ARB

84

Quality Focal Point

Page 85: Student Scheduling System Part II FCR ARB

85

Traceability MatrixOCD WinWin Agreement SSAD Test

OC-1 WC_1350(Last Year)WC_1329(Last Year)

UC-1UC-2UC-7UC-8UC-9

OC-2 WC_1533(Last Year) UC-1UC-2UC-3UC-4UC-5

OC-3 WC_2657 UC-6

OC-4 WC_2657 UC-6

OC-5 WC_2657 UC-6

LOS-1 WC_2658 UC-6

OG-1 WC_2654 UC-6

OG-2 WC_2655,WC_2659 UC-6

OG-3 WC_2658 UC-6

OG-4 WC_2657, WC_2659 UC-6

OG-5 WC_2655, WC_2657 UC-6

OG-6 WC_2658 UC-6

Page 86: Student Scheduling System Part II FCR ARB

86

Quality Management Strategies

• Defect Prevention Strategies Prototyping, Dry Run, Project Reviews Incremental Commitment Model Standard

• Defect Identification Strategies Team Artifact Process Reviews IIV&V Reviews, Auxiliary Reviews

• IIV&V Coordination

• Tools Bugzilla WinBook

Page 87: Student Scheduling System Part II FCR ARB

87

Defect Removal Tracking# Issue ID Comp. Reason Removal Solution

1 138 Team Website Directory structure does not comply with the assignment requirements.

Alter the directory structure

2 224 User Interface Some features are needless

Remove needless features

3 225 FED Risk assessment is wrong

Revise Potential Magnitude and Probability Loss

4 315 User Interface Page and capabilities Missing

Add initial page and hints

5 316 User Interface Page uncompleted Complete all pages on Student side and Administrator side