Mark_Phelps_Lab_5_Section_2.doc

290 views

Published on

Published in: Business, Technology
  • Be the first to comment

  • Be the first to like this

Mark_Phelps_Lab_5_Section_2.doc

  1. 1. 1 Technical Approach This part of the document will outline the overall technical approach of the prototype by identifying its major capabilities, facilities and equipment, and the key personnel involved in the prototype demonstration. Furthermore, it will provide proposed activities to switch from prototype to product. 1.1 Prototype Capabilities This part of the document will outline the overall architecture of the prototype by identifying its major components and their purpose. Furthermore, it will provide a summary of the functions that the product will provide or perform, generally what they do, and how they relate to each other. 1.1.1 Prototype Architecture Description The ThrillTracker prototype will consist of: • A commercial off the shelf (COTS) Phidget 1023 RFID reader that is included in a RFID developer’s kit provided by the university. Also included in the developer’s kit are several read-only RFID cards and tags. These cards and tags are pre-coded with a unique identifier. • A student or university provided laptop that will be used to simulate the kiosk environment through the use of HTML and scripting languages such as PERL and PHP. This HTML and script code will demonstrate the look and feel of the kiosk GUI as well as perform the functions of the ThrillTracker application. The Phidget Application Programming Interface (API) as well as the RFID Event Manager will also reside and run on this laptop. • A MySQL database will be used to store all of the data required to demonstrate ThrillTracker and will reside on a university server. Data stored in the database includes patron account
  2. 2. data, attraction data and itinerary information. A backup copy of the database will also reside on the laptop used for the demonstration. The laptop will be installed with all of the software required to accommodate queries that are sent from the ThrillTracker simulation. This software will include Apache web server, MySQL, PHP and PERL. Figure 1 ThrillTracker Prototype Major Functional Component Diagram.1 1.1.2 Prototype Functional Description The major functional components of the ThrillTracker prototype include the following: • RFID Reader: Used to simulate RFID gates placed at park attractions. The RFID reader will sense the RFID tag and read the encoded unique identifier. 1 Blue Group, Fall 2007
  3. 3. • RFID Interface: A Software application which will provide the interface to the RFID reader, receive messages containing the tag ID from the RFID reader, and then dispatch the tag ID to the ThrillTracker database. The interface will utilize the Phidget API provided with the RFID toolkit and the RFID Event Manager written by a member of prototype development team. • Application Simulation: HTML and scripting languages such as PERL and PHP will be used to create a patron GUI and an Administrative GUI. These GUI screens will provide the simulated functionality of the ThrillTracker application. o Patron GUI: HTML based application used to simulate the look and feel of the kiosk GUI. The simulation will cover the features available to ThrillPass patrons including:  Login and create a user name.  Create and modify a ThrillPass itinerary.  Party location.  Park information.  Party creation and modification. o Admin GUI: HTML based application used to simulate the look and feel of the Administrative GUI. The simulation will cover the features available only to system administrators including:  Access of historical attraction data.  Adding an admission pass to the database.  Access patron data.  Update or delete patron account.
  4. 4. Figure 2 illustrates the logic flow to be used when accessing the Patron GUI simulation. In this logic flow, the unique ID of the RFID tag is entered in the text box on the welcome screen. The PERL script simulating the ThrillTracker application checks the database to ensure that the ID is active. If the ID is not active or invalid, the GUI simulation will display an error. If the ID is determined to be active, the Patron GUI simulation then queries the database see if the ThrillPass account has been set up. If there the account has not yet been set up, the account setup process is called and the account setup screen is presented. If the account has already been set up, then the account access process is called and the ThrillPass Patron GUI is presented. Figure 2 Logic Flow: Patron GUI Access2 2 Blue Group, Fall 2007
  5. 5. 1.1.3 External Interfaces This section will describe the hardware, software, user and communication interfaces of the ThrillTracker prototype. 1.1.3.1 Hardware Interfaces • USB Interface: This is a high-speed USB interface which establishes the data exchange path between the laptop running the ThrillTracker application and the Phidget 1023 RFID card reader. Information transferred on this interface will include the unique identifier code of the RFID tag. • Network Interface: The network interface will allow communication between the laptop simulating the ThrillTracker application and the remote database server. The ThrillTracker prototype laptop will utilize the onboard Ethernet port to connect the LAN. 1.1.3.2 Software Interfaces • RFID Interface: A Software application which will provide the interface to the RFID reader, receive messages containing the tag ID from the RFID reader, and then dispatch the tag ID to the ThrillTracker database. The interface will utilize the Phidget API provided with the RFID toolkit and the RFID Event Manager written by a member of prototype development team. • Database Interface: This interface is provided by the ThrillTracker application and will send and receive messages to and from the remote MySQL database. 1.1.3.3 User Interfaces • Screen: A screen color display capable of at least 800 by 600 pixels is required. • Keyboard: A keyboard is necessary for data entry.
  6. 6. • Mouse: A mouse will be needed to navigate through the ThrillTracker software. • RFID Reader: A RFID reader will be needed to demonstrate one of the ThrillTracker software functionality. 1.1.3.4 Communications Protocols and Interfaces ThrillTracker will use the standard TCP/IP networking protocol and the standard Ethernet interface to communicate with the database server. The EM4102 protocol will be used to communicate with the Phidget 1023 RFID reader. 1.1.4 Specific Requirements This section of the document contains all the detailed requirements that have been built and will be demonstrated during the prototype presentation. 1.1.4.1 Functional Requirements This section will define the functional requirements for the ThrillTracker prototype. 1.1.4.1.1 ThrillPass Patron GUI 1.1.4.1.1.1 ThrillPass Patron Welcome Screen/Process This function will provide the starting point for the GUI interface for ThrillPass users. The following functional requirements shall be provided/simulated: 1. The welcome screen will display basic system information. a. Name of the park. b. ThrillPass logo. 2. A text box for admission pass ID input. 3. A submit button.
  7. 7. If a patron inputs an invalid ID, an error message will be displayed. If the patron enters a valid ID for an account that is not yet associated with a user name, then the Setup New Account Screen will be presented. If the patron enters a valid ID for an account that is associated with a user name, then the Returning Account Information screen will be presented. In order to limit the scope of the ThrillTracker prototype, only manual entry of the pass ID will be supported. The Phidget RFID reader will not be used to input the pass ID. 1.1.4.1.1.2 Setup New Account Screen/Process This function will provide the ability to set up a new ThrillPass account. The following functional requirements shall be provided/simulated: 1. The ID of the RFID tag entered at the welcome screen will be displayed. 2. An informative message reminding patrons not to input personal data. 3. A text box for the input of a user name. 4. If the user name is currently in use, an error message will be displayed requesting that the user input a new user name. 5. A submit button. The PERL script used to create the screen will query the database and determine if the user name is in use. If an unused user name is input, the database will be updated with the new user name. A message informing the patron that the account setup was successful will then be presented along with a continue button. When the continue button is clicked, the Returning Account Information screen will presented. 1.1.4.1.1.3 Returning Account Information Screen/Process
  8. 8. This function will provide ThrillPass patrons the ability to access the ThrillPass features. This screen will only be available to registered ThrillPass users. The following functional requirements shall be provided/simulated: 1. The name of the park will be displayed. 2. The ThrillPass logo will be displayed. 3. The unique ID of the admission pass and the user name will be displayed. 4. A button which will navigate to the Itinerary Info Screen. 5. A button which will navigate to the Party Information Screen. 6. A button which will navigate to the Park Information Screen. 7. A logout button, which when clicked, will navigate back to the initial Welcome screen. 1.1.4.1.1.4 Itinerary Info Screen/Process This function will provide ThrillPass patrons a view of the current ride itinerary. This screen will only be available to registered ThrillPass users. The following functional requirements shall be provided/simulated: 1. The current ride itinerary for the account will be displayed. 2. A button which will navigate to the Modify Itinerary Screen. 3. A button which navigates back to the Returning Account Information Screen. 4. A logout button, which when clicked, will navigate back to the initial Welcome screen. 1.1.4.1.1.5 Modify Itinerary Screen/Process
  9. 9. This function will provide ThrillPass patrons the ability to modify the ride itinerary. This screen will only be available to registered ThrillPass users. The following functional requirements shall be provided/simulated: 1. A group of check boxes representing each attraction that can be placed on the itinerary. 2. A group of check boxes representing the available timeslots for the attraction. 3. Checked boxes will indicate a ride that is currently active on the itinerary. Removing a check from a checked a box will indicate that a ride is to be removed from the itinerary. 4. A submit button, that when clicked, will update the itinerary and navigate back to the Itinerary Information screen. 5. A logout button, which when clicked, will navigate back to the initial Welcome screen. 1.1.4.1.1.6 Park Information Screen/Process This function will provide a ThrillPass patron with a map of the park, display the current location of the patron and current wait time of various attractions. This screen will only be available to registered ThrillPass users. The following functional requirements shall be provided/simulated: 1. A map of the park with an arrow indicating current location of the simulated kiosk in use. 2. When an attraction is clicked, a popup window will open and display current wait time information for the selected attraction. 3. A button which navigates back to the Returning Account Information Screen. 4. A logout button, which when clicked, will navigate back to the initial Welcome screen.
  10. 10. Only one kiosk will be simulated and the location will remain static. The PERL script used to create the screen will query the database when an attraction is clicked. The PERL script will use the information from the query to simulate the attraction wait time information in the pop up window. 1.1.4.1.1.7 Party Information Screen/Process This function will provide ThrillPass patrons the ability to access the Party Information features. This screen will only be available to registered ThrillPass users. The following functional requirements shall be provided/simulated: 1. The current members of the patron’s party will be displayed. 2. A button which will navigate to the Find Party Member Screen. 3. A button which will navigate to the Modify Party Screen. 4. A button which navigates back to the Returning Account Information Screen. 5. A logout button, which when clicked, will navigate back to the initial Welcome screen. 1.1.4.1.1.8 Find Party Member Screen/Process This function will provide ThrillPass patrons a display of the last known location of a party member. This screen will only be available to registered ThrillPass users. The following functional requirements shall be provided/simulated: 1. A list of party members and their last recorded location. 2. A button which navigates back to the Party Information Screen. 3. A logout button, which when clicked, will navigate back to the initial Welcome screen. 1.1.4.1.1.9 Modify Party Screen/Process
  11. 11. This function will provide ThrillPass patrons the ability to set up a party as well as add or remove party members. A patron can only be a member of one party at a time. Addition or removal of party members will be accomplished by inputting either the user name or admission pass RFID tag ID. This screen will only be available to registered ThrillPass users. The following functional requirements shall be provided/simulated: 1. A list of current party member’s user names and admission pass IDs will be displayed. 2. A text box for user name input. 3. A text box for ID input. 4. A remove member button. 5. An add member button. 6. A button which navigates back to the Party Information Screen. 7. A logout button, which when clicked, will navigate back to the initial Welcome screen. 1.1.4.1.2 ThrillTracker Admin GUI 1.1.4.1.2.1 Admin Welcome Screen/Process This function will provide the starting point for the GUI interface for ThrillTracker administrators. When a valid user name and password are submitted, buttons which navigate to other administrative features will be made available. In order to limit the scope of the prototype, administrative user names and passwords will be pre-loaded into the database. The following functional requirements shall be provided/simulated: 1. The welcome screen will display basic system information. a. Name of the park.
  12. 12. b. ThrillTracker logo. 2. A text box for user name input. 3. A text box for password input. 4. A login button. If an invalid user name or password is entered, an error message will be displayed. If a valid user name and password are entered, then a welcome message including the user name will be displayed along with the following buttons: 5. A button which navigates to the Access Data by Attraction Screen. 6. A button which navigates to the Access Patron Data Screen. 7. A button which navigates to the Patron Account Administration Screen. 8. A logout button, which when clicked, will navigate back to the initial Welcome screen. In order to limit the scope of the ThrillTracker prototype, attraction information and timeslot availability will remain static. There will be no support for adding or removing attractions. There will also be no support for modifying the number of available timeslots for a particular attraction. 1.1.4.1.2.2 Setup New Admission Pass Screen/Process This process will provide an administrator the ability to enter the unique ID of the RFID tag embedded in an admission pass into the database. The following functional requirements shall be provided/simulated: 1. A text box for admission pass ID input.
  13. 13. 2. A checkbox labeled ThrillPass. 3. A Submit button. 4. A button which navigates back to the Admin Welcome Screen. If the submit button is clicked and no ID is input, an error message will be displayed. If an ID is entered and the ThrillPass checkbox is checked to indicate that the ThrillPass option has been purchased, then the ID will be entered into the database as an active ThrillPass. If the ID is entered and the checkbox is not checked, the ID is entered into the database as a normal admission pass. 1.1.4.1.2.3 Access Data by Attraction Screen/Process This function will provide buttons which will navigate to data screens for each attraction monitored by ThrillTracker. The following functional requirements shall be provided/simulated: 1. A button for each ride monitored by ThrillTracker twill navigate to the Attraction data screen for the associated attraction when activated. 2. A button which navigates back to the Admin Welcome Screen. 3. A logout button, which when clicked, will navigate back to the initial Welcome screen. 1.1.4.1.2.4 Individual Attraction Data Screen/Process This function will provide the administrator with statistical data for the associated ride. The following functional requirements shall be provided/simulated: 1. Name of the attraction. 2. Attraction data. a. Number of ThrillPass patrons in line.
  14. 14. b. Number of non ThrillPass patrons in line. c. Current wait time for each line. d. Average wait time for each line. e. Current number of patrons riding the attraction. 3. A button which navigates back to the Access Data by Attraction Screen. 4. A logout button, which when clicked, will navigate back to the initial Welcome screen. In order to limit the scope of the prototype, historical data will be simulated. 1.1.4.1.2.5 Access Patron Data Screen/Process This function will provide the administrator with the ability to retrieve a patron’s account data. Patron data will be accessed by inputting either the user name or admission pass RFID tag ID. The following functional requirements shall be provided/simulated: 1. A text box for user name input. 2. A text box for ID input. 3. A submit button. 4. A display of patron data. a. User name and pass ID. b. Last recorded location. c. Itinerary. 5. A button which navigates back to Admin Welcome Screen. 6. A logout button, which when clicked, will navigate back to the initial Welcome screen.
  15. 15. 1.1.4.1.2.6 Patron Account Admin Screen/Process This function will provide the administrator with the ability to modify or delete a patron’s account. A Patron account will be accessed by inputting either the user name or admission pass RFID tag ID. The following functional requirements shall be provided/simulated: 1. A text box for user name input. 2. A text box for ID input. 3. A submit button. 4. A button which navigates back to Admin Welcome Screen. 5. A logout button, which when clicked, will navigate back to the initial Welcome screen. If an invalid user name or pass ID is entered, an error message will be displayed. If a valid user name or pass ID is entered, then a new screen will be displayed with the following: 6. A display of patron data. a. User name and pass ID 7. A text box for the input of a new user name. 8. A submit button. 9. A delete patron button which deletes the associated account from the database. 10. A button which navigates back to the Patron Account Admin Screen. If the user name is currently in use, an error message will be displayed requesting that the administrator input a new user name. If an unused user name is input, the database will be updated with the new user name. A message informing the administrator that the account setup
  16. 16. was successful will then be presented along with the patron account data and a continue button. When the continue button is clicked, the Patron Account Admin Screen will presented. 1.1.5 Performance Requirements The ThrillTracker prototype shall meet the following performance requirements: 1. The design of the database tables, database queries and GUI screen layouts should be such that no single GUI screen takes longer than three seconds to load. 2. A ThrillPass itinerary will allow no more then six rides per day. 3. Each attraction will allow 15 time slots every 15 minutes. 4. Party size will be limited to a maximum ten patrons. A patron can only be a member of one party at a time. 1.1.6 Non-Performance Requirements This section will define the non-functional requirements for the ThrillTracker prototype. 1.1.6.1 Security ThrillPass features will only be accessible to patrons who have purchased the premium ThrillPass service upon park entry. The unique ID of the RFID tag embedded in the admission pass will be entered into the database at the time of purchase. Administrative features will not be delivered by the ThrillPass kiosk GUI. A valid administrative username and password combination is required to access the administrative features of ThrillTracker. 1.1.6.2 Privacy ThrillTracker will not collect or store personal information. Patrons will be warned not to use personal information.
  17. 17. 1.1.6.3 Maintainability The ThrillTracker system will require two levels of maintenance. The first level can be covered by a single systems administrator who will be skilled enough to install update patches, monitor the system and correct networking issues. The second level will require a person skilled in repairing and replacing hardware present in the park environment. 1.1.6.4 Reliability The effect of a ThrillTracker system failure is dependent upon the extent of the failure. The ability of a patron to access an attraction must not be hindered by the ThrillTracker system. If a critical component of the ThrillTracker system should experience a failure, ThrillTracker will not be able to deliver the premium ThrillPass service or collect real-time data for the park. When ThrillTracker recovers from the failure, the information contained in the database will refer to the state of the system prior to the failure. Data collected around the time of a ThrillTracker system failure should not be included when performing historical analysis because the data may be inaccurate. If the ThrillPass service becomes unavailable during normal park operating hours, the park will likely have to refund all or a portion of the ThrillPass purchase price. Components critical to the operation of the ThrillTracker system are: • Database Server • ThrillTracker Application Server • RFID Server • Local Area Network 1.2 Proposed Activities to Transition Prototype to Product
  18. 18. Numerous activities will be performed during Phase 2 to transition the prototype into the product. One of the most important of these activities will be communicating with the amusement park to ensure that the product performs to their expectations. Interviews will need to be conducted with representatives from the amusement park to ensure that ThrillTracker matches the needs of the company. During this time, ThrillTracker staff will gather information about the amusement park’s policies and procedures. In addition, the desired format of the historical and real-time data gathering component of the ThrillTracker product will be defined. This shall allow the ThrillTracker staff to understand how to update the prototype so that the product will fulfill the amusement park’s expectations. This will require each component of the prototype to be redesigned and developed. In addition, security will need to be implemented in the product. As stated in the Prototype Specification, the prototype does not utilize any type of security measures except for a user name and password to login to the system. The product shall encrypt information that is sent over the Internet and will encrypt the information stored in the database. The ThrillTracker software shall be modified to address secure issues and errors. 1.3 Key Personnel • Project Manager: This person is responsible for the coordination and completion of the overall project and assign tasks to members of the team. The person in this role also sets deadlines and monitors overall project progress. • Software Engineer: Plans, designs, develops, and debugs the software required for ThrillTracker, Inc. Also responsible for support and modification of these software applications. • Quality Assurance Engineer: Inspects the quality of code, software, and hardware modules
  19. 19. that are produced by ThrillTracker, Inc. Should be grounded in software design and initially set up coding standards that will be used for the lift time of the project. • Web Developer: Responsible for development and maintenance of the ThrillTracker, Inc. website and also responsible for production of web-based software solutions that are to be used for the ThrillTracker product. Will work closely with the Database Special and Software Engineers, as well as the GUI Developer. • Database Specialist: Responsible for creating preliminary database design, creation of DB's, tables, defining data types within those tables. Creating flow charts for the flow of data and data decomposition. Additionally, responsible for writing SQL code for database and table access, and maintenance of the databases. • Technical Writer: Responsible for the creation of technical documentation of code modules Also responsible for the creation of users manual and documentation for the ThrillTracker product. • Network Engineer: Responsible for the development of network topology based upon the target customer. Tests to ensure that communications between network devices are kept secure, reliable, efficient and fast. • IT Specialist: Configures, installs, and maintains hardware and software for the team. Performs software and hardware audits. Also helps deploy the final ThrillTracker product and insures compatibility with any existing systems. • GUI Developer: Develops user-friendly, intuitive GUI designs that integrate well with software modules developed by Software Engineers, and web pages developed by Web Developers. Should keep a common theme between any GUI elements developed for web deployment and kiosk deployment.
  20. 20. 1.4 Facilities and Equipment Item Part Number Quantity Price Cost RFID Antennae Gates EnvisionWare 6 $2,000 $12,000 RFID Writer GAOF5 2 $80 $160 RFID Cards Mifare 1K 100 $0.70 $70 Development Servers Dell 2950 5 $3,200 $16,000 Application Servers Dell 2950 5 $3,200 $16,000 RFID Kiosk Slab X2 3 $3,000 $9,000 Routers Cisco 2611 5 $365 $1,825 Notebook Workstations HP nx6325 11 $875 $9,625 MS SQL Developer Toolkit 1 $50 $50 MS Visual Studio Pro 4 $799 $3,196 MS SQL 2005 5 $13,819 $69,095 RFID Antennae Gates- Several working RFID Antennae gates will be required to simulate attraction conditions and to determine strengths an weakness of the technology. RFID Kiosk- Working kiosks will be required to simulate park conditions and to familiarize the team with the development environment and interface. HP nx2611 Laptops – There will be 11 team members in phase 2, so naturally 11 workstations will be required. The systems will have Microsoft Windows XP Professional, Microsoft Office Microsoft Visual Studio Pro will be required for the development staff. Laptops were chosen for this phase due to their portability. Dell PowerEdge 2950 – (Servers) the server will hold as our mock datacenter for initial testing. The server will be installed with Windows® Server 2003, Web Edition. Cisco 2611 Routers –In phase 2 we will be developing and testing the functional prototype and we will need to simulate a large, stable network used to connect our RFID equipment, Kiosks and Servers together. All software must be updated as new versions are released and as new hardware is purchased.

×