1. EcpE Student Database Team 21 Adviser: Tien Nguyen Client: ECpE and Tony Moore Team: Steven Murray Justin Sliekers Nathan Staley Mike Walsh

2. Problem Faculty and staff in the ECpE department at Iowa State University currently do not have the ability to query undergraduate student information for opportunities available in department. This problem is resolved by creating a web application with a database that contains all of the students in the department with their information that is needed for the faculty and staff to assign opportunities.

3. Functional Requirements 1.Will be maintained by the Engineering Complete Support Group after completion. 2.All users of the product will have a valid Iowa State NetID. 3.All users of the product shall be associated with the ECpE Department. 4.The product shall allow advisers to query all available student information. 5.The product shall run on an Engineering Complete Support Group managed server. 6.The product shall provide a web application interface to allow the advisers to query student information. 7.The product shall allow multiple users to be on at the same time.

4. Non-Functional Requirements 1.The cost of this product shall not exceed $500. 2.The product shall prevent a student from viewing another student’s information. 3.The database shall not exceed the storage size of the provided server. 4.The product shall be accessible through ISU servers on the web. 5.Users must authenticate with ISU before logging into the server. 6.The product shall not block user activity during network actions. 7.The product shall work on IE, as well as the other major browsers.

5. Web Framework

6. Database Design

7. Implementation: A Module Smallest unit of functional use in the website Required to extend a subclass of the Module class o ensures permissions enforcement on all pages Comprised of four main parts o someModule.class.php o someModule.js o someModule.css o someModule.tpl

8. Security: Pubcookie authentication grants access to the server User found in database grants access to framework Module Permissions grant access to functional portions of website Database Authentication to prevent unauthorised access to the database

9. Functionality: Student View What can a student do? Students are allowed to edit their personal data that is not managed by the 10 Day List upload. Students can only view their scholastic and personal data on the Homepage module.

10. Functionality: Adviser View What can an adviser do? Search for candidates for opportunities: Advisers can view students scholastic and personal information. Advisers are able to query students using multiple scholastic and personal variables. Manage Opportunities: Advisers are able to add opportunities. Advisers are able to edit opportunities.

11. Functionality: Administrator View Functionality focused on maintaining the framework Linking new modules to the framework o by default, no user has access to a new module Assigning users to groups o user will have access to all modules that a group has access to Assigning modules to groups o user will have complete access to module once it has been granted. o access can be removed as well as granted

12. Security Testing Layer 1: Pubcookie Authentication o No Resource in the website is accessible without Pubcookie authentication Layer 2: Known User o Unknown Users are blocked before site load. Layer 3: Module Permissions o Users unable to load modules without adequate privileges o Student unable to view another's personal information Layer 4: Database Authentication o MySQL database cannot be accessed from a remote server

13. Run-time Testing Reaction Time o Opportunity Search  Minimum query reaction time: 293 ms  Maximum query reaction time: 34.32 sec  Average query reaction time: 8.53 sec o 10 Day List Upload  Average upload time: 1.56 mins o System Response  Average system response time: 368ms Browser Support o Firefox, Safari, Chrome, IE

14. Questions