讲解Unix、linux国外程序、辅导UNIX OS操作系统程序

SARMS Operational Concept Description

1. Scope.

1.1 Identification. This Operational Concept Description applies to the Student-At-Risk

Monitoring System that is to be developed by the students doing SIT321. This

document is identified by the code SARMS_OCD V1.0.

1.2 System Overview. The Student-At-Risk Monitoring System is to provide a

computerized solution (web-based or standalone) that identifies potential students

at risk and allows lecturers and administrators to take actions to alleviate any

potential issues.

This is the first version of this system although similar systems have been developed

by others and may provide useful design information.

1.3 Document overview. This document describes the operational concept of the

system. That is, it is the initial document describing the system. It states the

requirements informally and any constraints on the implementation to be observed

by the developers.

This document is subject to being revised as per the requirements from the

client/users or further discussions with the client/ users.

2. Referenced documents.

(To be added if necessary).

3. Current system or situation.

3.1 Background, objectives, and scope. Research has shown that proactively

monitoring student performance and attendance provides an early detection of

potential issues and enables schools to assist students who may be at risk. Such

assistance may include providing alternative teaching methods, counseling or

specific support. Monitoring student attendance and performance benefits students

at risk by providing proper support channels and benefits the school by ensuring the

student retention.

Each student is enrolled in 2 to 4 units one trimester. Currently the monitoring of

students at risk is based on the collected student attendance and performance data

of the enrolled units. If a student missed a certain number of lectures or practical

classes, or did not submit a certain number of assignments of a unit by a certain

date during a trimester (e.g., middle of the trimester), the student probably has some

potential issues with his/her study. An alert message should be sent to the student,

relevant unit lecturers, and administrator(s) with some suggested actions, such as a

face-to-face meeting. After the actions are completed, a feedback to the alert

message is recorded for future reference or monitoring tracking. In addition,

students, unit lecturers and administrator(s) also wish to get various reports about

student attendance, performance and action status of the enrolled units. Current

monitoring of students at risk is conducted manually, so it is tedious and timeconsuming.

SARMS Operational Concept Description

Page 4 of 8

The current system tries

- to enable unit lecturers to report student attendance and performance data to the

administrator(s),

- to help the administrator(s) identify students at risk and take some actions to

alleviate potential issues,

- to keep track of the action status, and

- to generate various reports showing statistic information about student attendance,

performance and actions.

The current system is only working within an education institute. People involved in

the current monitoring system are the administrator(s), lecturers and students.

3.2 Operational policies and constraints. The current monitoring system is a manual

and centralized system. At a certain time in a trimester, all unit lecturers are required

to report student attendance and performance data to the administrator(s) who will

identify the students at risk and take some actions accordingly. The actions,

feedback and status should be recorded for tracking purposes. Personal information,

attendance and performance data, monitoring records must not be released to

irrelevant persons or parties.

3.3 Description of current system or situation. In the current system, each lecturer

teaches one or more units each trimester. The name list of students enrolled in a

unit can be downloaded from the enrolment database. At a certain time, usually the

middle of a trimester, all lecturers are required to report to the administrator(s) the

students lecture or practical class attendance and assignment performance data.

After the administrator receives the data from lecturers, the administrator will check

the reported data to identify the students at risk. A student is at risk if one or both of

the following conditions are satisfied:

- If the student did not turn up in more than half of the lectures or practical classes

of one unit up to now without any acceptable reasons;

- If the student did not submit one or more assignments of one unit up to now.

Once a student is identified as of being at risk, the administrator will send an e-mail

as well as a letter to the student, notifying the student the current situation of

attendance and performance, possible consequences and actions that should be

taken. The actions to be taken include meeting with the administrator or the unit

lecturer(s), seeking help from support staff or services, and so on. The administrator

will record the meeting feedback, current status of action (e.g. no-reply, no-action,

counsel or consult with the lecturer(s), etc.) and the improvement of attendance and

performance. The records are used for future reference, such as generating reports

for analysis and decision making.

3.4 Users or involved personnel. Unit lecturers report student attendance and

performance data to the administrator who identifies and monitors students at risk.

Students are expected to take some actions after receiving the alert message from

the administrator, and give the feedback to the administrator. If a lecturer or

administrator has had a meeting with a student, the feedback from the lecturer or

administrator should also be recorded.

SARMS Operational Concept Description

Page 5 of 8

3.5 Support concept. Not applicable.

4. Justification for and nature of changes.

(Tailored out)

5. Concept for a new or modified system.

5.1 Background, objectives, and scope. The current manual monitoring operations do

not meet the requirements from education institutes because of a lot of intrinsic

drawbacks and inefficiency. A new software application system is needed. The

objectives of this new system are to implement the student-at-risk monitoring

automatically or semi-automatically, to enable students, lecturers and

administrator(s) to get the information of student attendance, performance, actions,

and feedback at any time of a trimester, improving student support services and

increasing the student retention rate. The system is required to achieve the

followings:

- Centralized operations, i.e. monitoring operations are performed on a single

central server. A web-based solution is preferable.

- On-line unit attendance and performance data entering.

- Identification of students at risk and alert message sending.

- On-line feedback and action status information entering.

- On-line information retrieval of student attendance and performance of a unit.

- Report generation.

5.2 Operational policies and constraints. It is preferable that the system runs on the

Web in a centralized manner, but the initial demonstration of application maybe runs

as a standalone or isolated system. The system operations must conform to the

responsibilities of the administrator(s), lecturers and students. Information privacy

must be guaranteed.

5.3 Description of the new or modified systems.

a. The operational environment and its characteristics

The system shall be eventually running on the Web.

b. Major system components and the interconnections among these components

The target machine type is a standard PC running one of Windows Vista, 7, 8 or

Linux or other workstation using Unix.

c. Interfaces to external systems or procedures

The application shall use a windowing system available with the development

system being used. Application data should be held in one or more database files,

normal text and Excel files, registry entries and system variables.

d. Capabilities/functions of the new or modified system

The system shall be able to

- set up accounts for lecturers, students by the administrator(s);

- suspend and terminate accounts by the administrator(s);

SARMS Operational Concept Description

Page 6 of 8

- edit and remove lecturer accounts by the administrator(s);

- edit and remove student accounts by the administrator(s);

- allow the administrator(s) to add, edit and remove units;

- allow the administrator(s) to enrol/remove students into/from units;

- allow the administrator(s) to assign lecturers to units;

- allow unit lecturers to enter student attendance and performance data for the

assigned units;

- allow unit lecturers to make changes to the entered attendance and

performance data;

- identify students at risks and send alert messages to the students and the

related lecturer(s);

- allow the administrator(s) and lecturers to enter feedback or comments for

the students at risk;

- allow students to enter responses to the received alert messages;

- allow students to retrieve their attendance and performance information, as

well as feedback, comments and responses;

- allow unit lecturers to retrieve student attendance and performance

information for an allocated unit, and for a specific student;

- allow the administrator(s) to generate various reports;

- allow unit lecturers to generate various reports of an allocated unit;

e. Charts and accompanying descriptions

Not applicable.

f. Performance characteristics

Not applicable.

g. Quality attributes

The design is to be object-oriented although it may be implemented in non objectoriented

languages. The system will eventually be running on a variety of

machines and operating systems. If database files are used, access to them shall

be via objects which represent database tables and records.

More quality attributes are to be added following further discussions with the

client/users.

h. Provisions for safety, security, privacy, and continuity of operations in

emergencies

The database used for the system must be backed up periodically. More

provisions are to be added following further discussions with the client/users.

5.4 Users/affected personnel. The administrator(s), lecturers and students.

5.5 Support concept. Design information, source code including project files,

developer’s guide and user’s guide shall be provided by the developer.

6. Operational scenarios. Some scenarios/use cases to be incorporated are:

6.1 Set up a student account. The name list of students who are enrolled in a unit can

be downloaded from the student enrolment database and saved as an Excel file. If the

SARMS Operational Concept Description

Page 7 of 8

name list cannot be downloaded, the original enrolment data should be entered manually

and saved in an Excel file. The Excel file contains student ID number, student user name,

email address, initial password, enrolled unit code and name, and other personal

information. The system reads the Excel file and uses the data in the file to create an

account for each student. If an account already exists, other information such as enrolled

units should be added to the account. After the accounts are set up, the administrator

decides whether to send e-mails to the students notifying them the user name and

password. Students can change their password after they first login to the system.

6.2 Enrol a student into a unit. The administrator selects the unit a student wants to

enrol in, and adds the unit into the student account. If the student has already enrolled

in this unit, a message is displayed showing this information; otherwise, the message

shows that the student is now enrolled in the unit successfully.

6.3 Remove a student from a unit. The administrator selects the unit a student wants

to be unenrolled, and removes it from the student account. If the unit does not exist in

the student account, a message is displayed showing this information; otherwise, the

message asks the administrator to confirm if the unit is to be removed. Once confirmed,

the unit is removed from the student account.

The above scenarios are for the purposes of example and must not be construed as an

upper limit. More scenarios are to be added. Detailed scenarios/use cases are

necessary for the system analysis and design.

7. Summary of impacts.

7.1 Operational impacts. To be added.

7.2 Organizational impacts. To be added.

7.3 Impacts during development. Not applicable.

8. Analysis of the proposed system.

8.1 Summary of advantages.

Reduced working load and increased efficiency on monitoring students at risk,

flexibility in entering and retrieving student attendance and performance information,

automatic identification and tracking of students at risk. (More advantages are to

be added).

8.2 Summary of disadvantages/limitations.

(To be added and modified if necessary)

8.3 Alternatives and trade-offs considered

A single central server has been considered, but it is vulnerable to overload from

time to time and denial of service attacks.

A stand-alone system, which is running on a single machine rather than on the Web,

is considered as an alternative to avoid overload and security problems on the

SARMS Operational Concept Description

Page 8 of 8

Internet/Intranet. But some functions/capabilities of the system have to rest on the

administrator shoulders, such as entering attendance and performance data,

entering feedback and so forth.

9. Notes.

(To be added if necessary)

Appendixes (To be added if necessary)