1. NCAA Student Athlete Compliance System May 09-17

2. Team Structure Client Dustin Gray Eileen Flaherty ISU Department of Athletics Compliance Office Faculty Advisor Dr. Doug Jacobson Development Team Andy Dorman Jared Eakins Ryan Kent Ben Youngblut

3. Problem Statement  The client needs to keep detailed compliance data on all student-athletes in the athletic department.  The current solution involves packets of forms completed by each student-athlete.  This method is very labor intensive, and wasteful of paper.

4. Approach  The new product will provide a green software solution for both the student-athletes and the athletic officials.  Students will be able to submit their information online, while officials can monitor and approve the student’s progress.  Officials will also be able to create the online forms students complete.

5. Market Survey  Similar products do exist to solve a similar problem. A number of Big 12 schools have implemented systems internally to handle NCAA forms for their student athletes while others have contracted out development of commercial systems. Our own athletics department received an estimate from ISU Information Technology Services, but the cost was beyond their budget. The estimate from ITS was $13,600 for development with an annual hosting cost of $1,700.

6. Deliverables  ISU NCAA Online Compliance System  Final deployment will yield a fully functional system which contains an initial set of user accounts, compliance forms, and help files.  Documentation will be created and delivered throughout the development process to ensure client needs are met.

7. Operating Environment  End-User Environment  End-users: AD staff and student-athletes  Web browsers, at home or office  IE6+, Firefox 1.5+, Safari 3+, and Opera 9+ web browsers  Host Environment  IIS web server  PHP support  MySQL database  RAID-1 redundant backup

8. Requirements  Will include Admin Accounts and User Accounts  Admin Accounts  Manage user accounts  Create/modify forms  Manage forms  Review user form responses  User Accounts  Fill out/submit forms  Forms can be created  Forms can be completed  Form responses are stored

9. System Description  Client-server design model  PHP, Javascript, MySQL  Two Modes: Admin and User  Admin  Import student-athletes  Create forms for athletes to fill out  User  Fill out and submit forms  Heavy use of AJAX  Javascript initiated HTTP requests to web server  Server responds in parsable format  Multi-tiered system, only one layer communicates w/ database

10. System Diagram

11. Application Flow

12. User Interface Description  Web-based interface: familiar and accessible to users  Simple, straight-forward, and easy to use  When student-athlete completes a form, next form appears  More advanced UI for admins  Displayed information presented in a logical manner  Admin functionalities clear and simple

13. ExtJS  JavaScript Library  User Interfaces  AJAX Communication w/ Server  Easy to implement drag-and-drop GUI  Dynamic page content  Allows for easy JSON object functionality  Cross Browser compatibility

14. System Diagram

15. Model/View/Controller  Separates out business logic and data structures from user interface specifics  Reasons:  Modularized software components – can easily and simply swap user interfaces without changing workings of other components  Single point-of-entry into the system – all requests routed through one mechanism  Single layer of data access – allows for easy changing of data sources  Quicker development – given interface connections, developers can develop in parallel on one piece of the system  Tools:  EZPDO – object-oriented relational data access library  XMI2PHP – turn a UML class diagram directly into EZPDO- consumable classes

16. Model

18. View  Has no knowledge of business logic  Arranges contents of model map into form consumable by client  JSON – JavaScript Object Notation  ExtJS specific

19. Controller  Acts as link between model and view  Simple hand-constructed control routing mechanism  A controller method can be accessed directly by the URL  Handles retrieving the controller and the view  Has no knowledge of user interface – it just populates a hash map of model objects  Data access point – all data access happens in the controller and business logic is applied through model business managers

20. Authentication & Authorization  SSL Certificate; issued by ISU  Login w/ ISU PubCookie Single Sign On  PubCookie maintained by IT  After secure login, cookie would be accessible by application  XML-defined role-to-permission table  Each user has a set of Roles  Each role has a set of Permissions  Each page and each controller method requires a permission

21. Testing  Unit Testing – done concurrently  Database Relations  Front End Functionality  Business Logic  Integration Testing – as major components were finished  Beta Testing – releases to Client with feedback  User Acceptance/Quality Assurance  Interface Layout/Preferences  Student Email Notifications

22. Obstacles  Feature Creep  Moving requirements  Gold plating  Server Issues  IIS vs Apache  Pubcookie and SSL  PHP versions  Development Issues  Learning large-scale PHP “best practices”  Performance/extensibility tradeoff  Post-graduation support

23. Conclusion  Software solution saving time/resources  Extensible PHP framework with MVC architecture  Intuitive user interface  Administrative functionality doesn’t require programming background  “Test-as-you-go” unit testing  Frequent client feedback  Maintainable for future development

24. Demo

25. Questions?