Institution Name: Syracuse University Work Package Title: ASC CY4 IC Project Title: Training Management Database -- Phase 2 POC: Bernholdt David E Email: bernhold@npac.syr.edu Phone: 315 443 3857 Fax: 315 443 1973 CTA or PEI: Information and Communications Project Description: Design, implement and deploy a web-based, database-backed system to support training course administration. This project is based on a Statement of Work agreed to in February 1999 which sets out a three phase plan for the development of a Training Management Database system, each offering increasing levels of functionality and sophistication. Phase 1 of this effort was undertaken during Year 3 at no cost to ASC. This particular project corresponds to Phase 2 of the SOW, and a separate Year 4 proposal corresponds to Phase 3. Project Objectives: Statement of Work Training Database Project 1.Design, implementation, and deployment of a web-based data support system for course administration. ASC/MSRC has defined the architecture for an Oracle database to support course administration that is compatible with the ASC/MSRC user database. The database architecture is attached. For security reasons, the web support structure will interface with a mirror of the ASC/MSRC internal database. The work will be completed in three phases as noted in each section. We estimate the time and cost of each phase as follows: Phase Delivery Date Cost 1 1 May 1999 $0 (per agreement w/ GCF) 2 2.5 months after go ahead $25k 3 3-6 months after Phase 1 & 2 ESTIMATED at roughly $50k Please note that further discussions are required on Phase 3 before a firm estimate can be given. 2. The administrative module will consist of web interfaces to the database and will provide the following functionality: 2.1. There should be four levels of access: 2.1.1. Public should be able to view the training schedules, which would include the date(s) the course will be offered, the name of course, description, instructor, and similar information. 2.1.2. Instructors: write access via registration and input forms only. No edit privileges except via registration form. Instructors should have access to web form to input course description and syllabus and any other class information the instructor wishes to provide in advance. Instructors should have access to class enrollment information to include information on enrolled students. 2.1.3. Student: write access via registration and evaluation forms only. No edit privileges except via registration form. Read access to all of class information 2.1.4. Administrator should have read/write access to all tables i.e. access to web form to confirm all additions to schedule and edit, if necessary. 2.1.5. CTA's: Read access to all tables *Note: Individuals control what personal information is displayed (address, phone, email, etc) on the class roster at the public/instructor/student access level. Access levels will be included in phase 1. 2.2 Web Database Interfaces 2.2.1 Administrator read/write access forms, including creation of new courses and class sessions. 2.2.2 Instructor registration and input forms. 2.2.3 Student registration and editing forms. These forms will be included in phase 1, but will only interact with the database tables (web pages and account creation are in later phases). 3.Examples of Functionality 3.1. New course is announced: 3.1.1. Automatic updates to the website: 3.1.1.1. Creates updated training index/schedule web page 3.1.1.2. Creates syllabus web page 3.1.1.3. Creates web page(s) for other class info (conversion may be necessary to ps or pdf) 3.1.1.4. Creates class attendance list or roster web page 3.1.1.5. Updates extended schedule web page 3.1.1.6. Updates news link 3.1.1.7. Creates links to items 3.1.1.1 - 3.1.1.7 from training index/schedule page 3.1.1.8. Update html/cgi-bin registration form to include the new class (es). 3.1.1.9. Creates a text course announcement file and posts to listserver or emails to fixed list 3.1.1.10.Tracks Instructor and student registrations and automatically responds with confirmation automatically based on criteria set forth for each. 3.1.1.11.Upon completion of course, web schedule pages must be migrated from current to previous (items a - d above) and other web pages (items 3.1.1.1 - 3.1.1.12) must be "cleaned up". 3.1.1.12.Updates to existing information (e.g. cancellations, date changes) should be automated incorporate changes to items 3.1.1.1 - 3.1.1.12 above. Web site creation and maintenance of pages is included in phase 2. 3.2 Registration 3.2.1 Registration form should exist for Student and Instructor and include provisions for assignment of a student and/or instructor HPC account. 3.2.2 Registration for student account: dB should maintain current class list and respond with confirmation automatically based on class count, citizenship and DoD affiliation. There are 20 student accounts available per class session. 3.2.3 Registration for instructor account: dB should respond with confirmation automatically based on citizenship and DoD affiliation 3.2.4 Automated mailings should be sent out at predetermined times (e.g. final details). The capability of sending other necessary mailings necessary (e.g. cancellations) is also available. 3.3 Course Preparation 3.3.1 Student and Instructor accounts prepared semi automatically 3.3.2 Instructor unix and kerberos passwords need to be made current 3.3.3 A flag that a SecurID card must be mailed is raised 3.3.4 Kerberos passwords are made current and SecurID passcodes created for them (existing ASC/MSRC oracle database and scripts already exists, a web interface is necessary) 3.4 Upon Completion of a Course: 3.4.1 Information in instructor accounts must be archived 3.4.2 Instructor and student accounts must be cleaned out. (Scripts already exist for these functions but will need a web interface). All of the above items in section 3 pertaining to account creation will be in one part of phase 3. 3.4.3 On-line evaluations form results must be tracked and results automatically totaled, collated and formatted into a standard report. On-line evaluation forms, tabulation and reports will be a part of Phase 3. 3.5 Reports 3.5.1 All fields should be searchable (based on predefined user access) and output directed into custom reports 3.5.2 Standardized reports must be available. Searches, custon reports and availability of other reports will be a part of Phase 3. Deliverables: Phase 2 of the previously agreed SOW will be delivered by September 1999 Customers/End Users: The system will be used primarily by on-site MSRC and PET staff, but also by training instructors and training recipients (MSRC users). Benefit to Warfighter: The system will reduce the human effort required to oversee routine training activities, and thereby allow staff additional time to devote to other MSRC and PET activities which benefit the warfighter. Project Dependencies and Scope: Interacts with on-site Training, I/C PET staff, MSRC User Support and Database Support personnel. Is based on completion of Phase 1 of the SOW, which is underway during Year 3 at no cost to ASC. Risk Element: The principal risk of this project is the fact that the principal developer is a foreign national who (according to present policies) cannot obtain accounts on any ASC MSRC system. Therefore certain installation, testing, and debugging activities will have to rely on the participation of other staff (Syracuse, PET, and MSRC). We have been aware of this situation from the start of the project and can manage the risk. Required Funding Level Year X: 25,000 Year X+1: 10,000 (suport and modest enhancements) Year X+2: 0 (support folded into core activities)