NCAA Student Athlete Compliance System

May 09-17

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

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.

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.

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.

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.

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

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

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

System Diagram

Application Flow

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

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

System Diagram

Model/View/ControllerSeparates 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

Model

Model

ViewHas no knowledge of business logic

Arranges contents of model map into form consumable by client

JSON – JavaScript Object Notation ExtJS specific

ControllerActs 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

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

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

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

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

Demo

Questions?