| Institution Name: |
Syracuse University |
| Project Identifier: |
ASC-CY4-IC--8 |
| Project Title: |
Training Management Database -- Phase 3 |
| POC: |
Bernholdt, David E |
| Email: |
bernhold@npac.syr.edu |
| Phone: |
315 443 3857 |
| Fax: |
315 443 1973 |
| CTA: |
IC |
| 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. A separate Year 4
proposal has been submitted corresponding to Phase 2, and this project
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: |
Discussions finalizing Phase 3 details will follow delivery of Phase 2.
Phase 3 will be delivered by May 2000 |
| 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: |
Interacts with on-site Training, I/C PET staff, MSRC User Support and
Database Support personnel.
Is based on completion of Phases 1 and 2 of the SOW. Phase 1 underway
during Year 3 at no cost to ASC, Phase 2 offered as a separate Year 4
proposal. |
| 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. |
Year X Funding:
Year X+1 Funding:
Year X+2 Funding: |
(suport and modest enhancements)
(support folded into core activities) |