Sample Response to Discussion Question 2: Operational
Concept
Our objective this week is to achieve consensus on an operational
concept for a Plan of Study DSS. Buede (2000)
defines an operational concept as follows:
Operational Concept: vision for
what the system is
(in general terms), a statement of mission requirements, and a
description of how the system will be used. The shared vision
is
based on the perspective of the system's stakeholders of how the system
will be developed, produced, deployed, trained, operated and
maintained, refined, and retired to overcome some operational problem
and achieve the stakeholders' operational needs and
objectives. The mission requirements are stated in terms of
measures of effectiveness. The operational concept includes a
collection of scenarios;
one or more for each group of stakeholders in each relevant phase of
the
system's life cycle.
The following
background information has been provided:
- A transcript of last
week's WebCT discussion and the minutes from the in-class
discussion.
- Guidance
from responsible university officials on resolution of key open issues
from the discussion.
- A demonstration of the current registration and degree
audit process.
- Plan of study forms for several graduate and undergraduate
degree programs.
1. A vision statement for the Plan of Study DSS. This should be a
one-paragraph description of the vision for the system as agreed upon
by all stakeholders.
The George Mason University (GMU) Objectives Assistance Tool (GOAT) is
a decision support system (DSS) designed to assist students enrolled at
GMU in selecting appropriate classes to reach their academic
objectives. The DSS will allow students to develop, save, and
compare multiple plans of study; seek approval from academic advisors;
and select the most appropriate courses for a given semester thereby
enabling students to make effective, informed decisions as to which
classes to take when thereby maximizing the likelihood of meeting their
academic objectives within personal and academic constraints. The DSS
will interface with the GMU PatriotWeb information system, extracting
data as needed for decision support functions. The DSS will not make
modifications to PatriotWeb data. The DSS will interoperate with a
future system for course planning. The DSS will be developed via
an evolutionary model with basic functionality brought online rapidly,
and used by increasingly large and diverse groups of students and
advisors from an increasing number of departments. Each evolution will
add breadth or depth to the system in both functionality and user
community, as agreed to by stakeholders.
2. A set of usage scenarios.
- User logs in to GOAT, executes
function and logs out (this segment is
common across all scenarios)
- User accesses
main GOAT page via web.
- GOAT requests
authorization.
- User provides
valid user id and password.
- GOAT verifies
unique identification
with the registrar's office.
If identification cannot be verified return to step
b.
- GOAT displays
main menu containing the following options: (i) Tutorial; (ii) Create /
Modify Plan of Study; (iii) Evaluate Plan of Study; (iv) Search for
Courses; (v) Maintain GOAT (available to authorized
administrators only)
- User selects tab
for desired module.
- GOAT displays
the entry screen for desired module.
- User executes
desired action.
- If not finished, user returns to main menu (step e); otherwise, user logs out or
is logged out automatically after maximum inactive period is exceeded.
- User executes
tutorial
- User executes
actions a-e of Scenario 1.
- User selects tab
for tutorial module.
- GOAT displays
the tutorial module
welcome screen.
- User enters
topic in which
he/she is looking for help.
- GOAT searches
database for relevant
training guides on the topic.
- GOAT returns
listing of available
guides.
- User selects the
most
appropriate guide.
- GOAT displays
the selected training
information.
- User exits scenario (executes action i of Scenario 1).
- Student creates new plan of study (this scenario will be extended in a later version to recommend courses)
- Student enters GOAT by executing
actions a-e of Scenario 1.
- Student selects
tab for creating plan of
study.
- GOAT displays
the plan of study
screen.
- Student selects tab to create new plan of study.
- System asks whether student wants to use an existing plan of study as a basis.
- Student says no.
- Student selects
the most
appropriate college (e.g. engineering, business).
- GOAT displays
all academic programs
under that college.
- Student
selects an academic program.
- GOAT retrieves a
recommended plan of
study for that program from recommended plan database. (Note:
we have not specified whether recommended plans will reside in an
internal GOAT database or whether they will reside in another
university database and be accessed by GOAT. This issue will need to be
resolved at detailed design time.)
- GOAT requests student transcript from university database.
- GOAT receives student transcript from university database.
- GOAT displays
recommended plan of
study for student's chosen program. Courses student has already taken are indicated on plan. (Note: for
some programs there will be multiple recommended plans and this
scenario will require an additional step in which student chooses from
a list of recommended plans.)
- Student modifies the study plan by:
- Adding or deleting one or more specific courses to be taken;
- Specifying one or more "TBD" courses in a given semester, together with a list of alternative courses for the TBD slot;
- Specifying or changing the semester in which a course is to be taken.
- GOAT updates,
revises, and displays
a new recommended plan of study
- Student accepts
the plan of study.
- GOAT saves the plan of study in student's study plan folder.
- Student exits scenario (executes action i of Scenario 1).
- Student searches for available courses (this scenario will be extended in a later version to provide recommendations for courses to be taken)
- Student executes
actions a-j of Scenario 3.
- Student selects
tab for course search.
- GOAT displays
the courses screen.
- GOAT displays list of saved study plans and requests student to choose a plan from the list.
- GOAT displays selected plan and requests selection of courses available for modification.
- GOAT displays
all available courses
(in a given semester) related to student's program of study. (This
is the entry point for the course recommendation feature to be inserted
later. System will allow student to select a subset of courses
available for modification (default is all non-required courses in
degree program). System will guide student through recommended
alternatives to the selected subset that best meet student's objectives.)
- Student selects
course.
- GOAT displays
course information.
- Student executes actions k-o of Scenario 3.
- Student enters goals and constraints (Note:
Initial version will include a very limited set of goals and
constraints; later versions will expand on factors to be considered.)
- Student enters GOAT by executing
actions a-e of Scenario 1.
- Student selects
tab for entering goals and constraints.
- GOAT displays
the goals and constraints dialog.
- Student enters information about goals and constraints, to include:
- Number of semesters until degree completion (minimize);
- Time slots to avoid scheduling classes (minimize classes scheduled during selected periods);
- Number of days per week on which classes are scheduled (minimize);
- Desired elective courses (maximize desired courses included in plan);
- Number of credit hours above degree/certificate requirements (minimize extra credit hours).
- Student indicates whether each item
is a constraint (no plan will be accepted if constraint is not
satisfied) or a goal (system will attempt to satisfy goals but will
accept plans that do not satisfy goal). Student enters
information on relative desirability of different goals.
- Student exits scenario (executes action i of Scenario 1).
- Student evaluates plan of study (this scenario will be extended in a later version to provide recommendations for courses to be taken)
- Student enters GOAT by executing
actions a-e of Scenario 1.
- Student selects
tab for evaluating plan of
study.
- GOAT displays
the evaluate plan of study
screen and requests selection of study plan to evaluate.
- Student selects a study plan to evaluate.
- GOAT evaluates study plan. Evaluation includes:
- Degree requirements met (with indicator of pending approvals if necessary approval has been requested);
- Degree requirements not met;
- Prerequisites
not met for planned course sequencing (with indicator of pending
approvals if permission to waive prerequisite has been requested);
- Approvals
pending (advisor or department approval of study plan; university
approval of general education requirement; department approval of
transfer credit; etc.);
- One or more
feasible schedules for upcoming semester(s) for which course schedule
is available or indication of schedule conflicts if no feasible
schedule exists for planned set of courses.
- Overall assessment of how well study plan meets student's goals.
- Student selects "request approval" button.
- GOAT
sends email to student's advisor requesting approval. (Note: some
departments may elect to route approvals to someone other than the
student's advisor.)
- Student exits scenario (executes action i of Scenario 1).
- Faculty advisor approves plan of study
(Clarification: There is not a uniform process within the university
for plan of study approvals, and it is not realistic to expect one to
be imposed. GOAT will be designed to support the existing approval
processes.)
- Advisor
receives email from student requesting approval of plan of study.
Email contains a link to GOAT plan of study for which approval is
desired.
- Advior clicks on link and is routed to GOAT entry screen.
- Advisor enters GOAT as in actions a-e of Scenario 1.
- Upon entry, GOAT displays
the student's plan of study evaluation screen with needed approvals highlighted.
- Advisor executes one of the following actions:
- If approval is routine and advisor is authorized to approve, advisor executes approval.
- If
issue requires discussion, advisor indicates that approval is deferred
pending a meeting with student, and GOAT sends email to student asking
student to make appointment with advisor.
- If
advisor accepts study plan but is not authorized to make approval,
advisor requests that approval be routed to appropriate person, and
GOAT requests explanation/comments from advisor, and sends email to
appropriate approval authority including explanation/comments.
- If advisor denies approval, advisor enters reason for denial and GOAT sends email with explanation to student.
- Advisor exits scenario (executes action i of Scenario 1).
- Authorized
administrator updates course and
pre-requisite information. (Clarification:
Several students proposed scenarios in which teachers entered
information about their courses. Course offerings, program
requirements, and prerequisites are not up to a teacher's discretion.
Courses aren prerequisites are determined by a department, and must go
through a school and university level approval process in which other
departments can comment and can protest changes that will adversely
affect their students. Furthermore, course information is used by other
university systems, such as PatriotWeb's degree audit. Therefore, we
will make the assumption that GOAT obtains its course information from
other university systems.)
- Authorized administrator enters GOAT by executing
actions a-e of Scenario 1.
- Administrator requests to synchronize course information.
- Administrator enters
secondary password.
- GOAT verifies
secondary password
with the Administrators database.
If secondary password is not valid return to step c.
- GOAT requests update of course data from university database.
- University database sends to GOAT changes since last update.
- University database sends completion message and indicator that update was successful.
- GOAT displays successful completion message.
- GOAT saves
changes.
- Administrator exits scenario (executes action i of Scenario 1).
3. A set of mission requirements.
- Coverage. The
GOAT system shall provide a means to create, store, evaluate and manage
approvals of study plans for all undergraduate and graduate degree and
certificate programs and for non-degree students, to include double
majors, combined BS/MS programs, and certificates earned along with
degree. Metric: Check list of supported programs against list of programs offered by university.
- Capacity. The GOAT system shall support five thousand concurrent users. Metric: Measure performance (speed and unscheduled downtime) of system as function of number of users simultaneously logged in.
- Availability. The GOAT system shall be available 24 hours per day, seven days per week, with no more than 5 hours of downtime per month. Metric: Collect statistics on downtime for operational system.
- Usability. The
GOAT system shall require no more than 20 minutes of training via
embedded tutorials for the average high school student to master its
usage. Metric: Perform usability study to evaluate task performance and user satisfaction as function of time spent in training.
- Interoperability. The GOAT system shall interoperate with PatriotWeb and other university systems. Metric:
Demonstrate ability to retrieve data from university database, send
emails to request authorizations (and other interoperation specified in
detailed design).
- Security.
The GOAT system shall provide multi-level security to restrict data
access and/or updating to users with authorizations appropriate to the
data being accessed or updated. Metric:
Perform evaluation study in which sophisticated individuals attempt to
break into system; demonstrate ability of authorized users to access
necessary information.
Back to SYST 542 homepage