Changes between Version 10 and Version 11 of BrainstormingPage
- Timestamp:
- 09/03/2007 07:35:46 AM (17 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
BrainstormingPage
v10 v11 10 10 * Elodie 11 11 12 == Josh's brainstorming ==12 == Josh's Brainstorming == 13 13 14 14 Why? There are many aspects in our lives that we need to deal with, scheduling classes and flights, room assignments at hospitals, scheduling domestic and international meetings and etc... Many softwares are provided for support, and yet, clarity in customer needs is a problem. As long as requirements are lucid, the cost of application and production will be held to a minimum. 15 15 16 '''What do we need?''' 17 16 === What do we need? === 18 17 1. A scheduler, which deals with all scheduling information. 19 18 * Goal: is to reduce communication costs and time costs … … 23 22 24 23 25 '''How everything works,''' 24 === How everything works === 25 26 26 All the requirements and specifics will be manually inputted by the client and sent to the server side. The server will then deal with all the scheduling information. 27 27 … … 35 35 36 36 37 '''Client side:''' 38 37 ==== Client side ==== 39 38 40 39 Register New user: 41 42 40 1. Login to www.oursystem.com the system website 43 41 2. Create user, by adding all data stated above … … 45 43 4. Registration granted/denied 46 44 47 48 49 '''Reschedule/Schedule a meeting''' 50 45 Reschedule/Schedule a meeting: 51 46 1. Login to website 52 47 2. Replan/Request for a meeting (must be requested 7 days before the actual meeting time) … … 58 53 * rejected (can’t schedule meeting) 59 54 60 --------------------------------------------------------------------- 61 '''Server side''':(assuming all information is inputted and updated)55 ==== Server side ==== 56 (assuming all information is inputted and updated) 62 57 63 '''Assumptions''': 64 58 Assumptions 65 59 1. Our server is secure, privacy is guaranteed, so I think we should run this under https??? 66 60 2. Our database information will not have any flaw. … … 68 62 69 63 70 '''Technical issues''' 64 Technical issues 71 65 1. Concurrency issues, this is an implementation part, so I think we can deal with this later on. (meeting requests and in-meeting communication) 72 66 73 67 Preprocess the information sent by the client (to rectify the information before the scheduler actually schedules the meeting) 74 75 76 68 1. Receives the data from the client 77 69 2. Checks if there are any conflicts in the information … … 81 73 82 74 Meeting setups 83 84 85 75 1. collects all the information being sent from the client 86 87 76 2. identify all users that are requested to be involved in the meeting 88 89 77 3. we run the programs to determine if the meeting can be scheduled (I propose that we use the priority algorithms in operating systems. (I believe the rest of the information is implementation issues, so I’m not stating anything about it as of right now) 90 91 78 4. if meeting is not scheduled, send the unscheduled meeting results to the user, if needed for further assistance, repeat from step 1. Else, send out an invitation to all users about the scheduled meeting. We are assuming that they will follow their preferences as given in the database. 92 93 79 5. We book the meeting when finalized. 94 80 95 81 96 '''The Database''' 97 components 82 ==== The Database ==== 83 84 Components 98 85 1. Information for all users 99 86 * Preferences for meeting time … … 105 92 106 93 107 108 94 This is it folks, feel free to critique. 109 95 96 ---- 110 97 == Russell's Brainstorming == 111 98 … … 120 107 7. If not using email then visit/call each participant or send memo to tell each participant the date, time and location of meeting. 121 108 109 ---- 122 110 == José's Brainstorming == 123 111
