Changes between Version 1 and Version 2 of DocumentsPage

Timestamp:

08/30/2007 03:05:40 PM (17 years ago)

Author:

josh

Comment:

--

DocumentsPage

@@ -1 @@
-CS6361 FALL 2006 Documents Page
+C''''''S6361 FALL
 
+ 2006 Documents Page
+
+Josh's brain storming-----------------------------------------------------------------------------------------------------
+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. 
+
+'''What do we need?'''
+
+1. A scheduler, which deals with all scheduling information.
+        Goal: is to reduce communication costs and time costs
+2. Database: which saves the information of all possible users available.
+        Data included: calendar, physical rooms data, virtual room data, user information, user preferences (dates they    can and can’t attend meetings), scheduled meetings, 
+3. GUI, the interface that the user will interact with.
+
+   
+
+
+'''How everything works,''' 
+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.
+
+What the client needs to know:
+
+
+1. hardware requirements (i.e. explore 6.0, XP…)
+
+
+2. Information requirements (what information is needed to schedule a meeting)
+
+
+3. Our system is user-friend 
+
+4. Please respond to the server messages of scheduled meeting ASAP
+
+
+
+'''Client side:'''
+
+
+Register New user:
+
+
+1. Login to www.oursystem.com the system website
+
+
+2. Create user, by adding all data stated above
+
+
+3. Wait a few days for the registration to be authorized by us.
+
+
+4. Registration granted/denied
+
+
+
+'''Reschedule/Schedule a meeting'''
+
+
+1. Login to website
+
+
+2. Replan/Request for a meeting (must be requested 7 days before the actual meeting time)
+
+
+3. Identify the preferred date/time/location/monitoring user.
+
+
+4. Scheduled meeting status
+
+
+       -Granted (all set)
+
+
+       -pending (still scheduling)
+
+
+       -modification (modification of meeting data required)
+
+
+       -rejected (can’t schedule meeting)
+---------------------------------------------------------------------
+'''Server side''': (assuming all information is inputted and updated)
+
+'''Assumptions''':
+
+
+1. our server is secure, privacy is guaranteed, so I think we should run this under https???
+
+
+2. Our database information will not have any flaw.
+
+
+3. We assume that all users will respond ASAP (within 24 hours) to the meeting request
+
+
+
+'''Technical issues'''
+1. Concurrency issues, this is an implementation part, so I think we can deal with this later on. (meeting requests and in-meeting communication)
+
+Preprocess the information sent by the client (to rectify the information before the scheduler actually schedules the meeting)
+
+
+1. Receives the data from the client
+
+
+2. Checks if there are any conflicts in the information
+
+
+3. If there is, respond to the client for rectification, else, send information to the scheduler.
+
+
+
+Meeting setups
+
+
+1. collects all the information being sent from the client
+
+
+2. identify all users that are requested to be involved in the meeting
+
+
+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)
+
+
+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.
+
+
+5. We book the meeting when finalized.
+
+
+
+'''The Database'''
+components
+1. Information for all users
+
+
+    -Preferences for meeting time
+
+
+    -Current location (real-time update?)
+
+
+    -Personal information
+
+
+2. Physical rooms available
+
+
+3. Virtual rooms available
+
+
+4. Scheduled meeting information (there might be cases where rescheduling is being requested even before the server responds to the client, so we need to have information about this)
+
+
+
+
+
+This is it folks, feel free to critique.