Running Head: Lab 2 – REMSY Product Specification
Lab 2 - REMSY Product Specification
Blue Team
Seth Hohensee
CS411W
Janet Brunelle & Hill Price
April 14, 2014
Version 2
1
Lab 2 – REMSY Product Specification
2
Table of Contents
1 INTRODUCTION
1.1 PURPOSE ................................................................................................................................ 3
1.2 SCOPE .................................................................................................................................... 4
1.3 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS................................................................... 6
1.4 REFERENCES .......................................................................................................................... 8
1.5 OVERVIEW ............................................................................................................................. 8
2 GENERAL DESCRIPTION
2.1 PROTOTYPE ARCHITECTURE DESCRIPTION ............................................................................ 8
2.2 PROTOTYPE FUNCTIONAL DESCRIPTION............................................................................... 10
2.3 EXTERNAL INTERFACES ....................................................................................................... 10
2.3.1 Hardware Interfaces ..................................................................................................... 10
2.3.2 Software Interfaces ...................................................................................................... 10
2.3.3 User Interfaces ............................................................................................................. 11
2.3.4 Communications Protocols and Interfaces................................................................... 11
3 SPECIFIC REQUIREMENTS
3.3 ASSUMPTIONS AND CONSTRAINTS ....................................................................................... 11
List of Figures
Figure 1. Prototype Major Functional Components Diagram. ....................................................... 9
List of Tables
Table 1. Effects of Assumptions, Dependencies, and Constraints on Requirements. .................. 12
Lab 2 – REMSY Product Specification
3
1 INTRODUCTION
Resource management is critical to the success of any organization. The ability to
continue operation, and the effectiveness of these operations, are directly affected by the
availability and allocation of a limited pool of resources. Whether the resource in question is a
workspace, employee, or piece of equipment, it is important to ensure that it is not used
wastefully. Waste, in this case, could mean that two separate employees are assigned to complete
a task that could have easily been handled by one of them. This makes intra-organization
communication especially critical.
Collecting and communicating the necessary data to analyze and improve the
management of tutoring resources at Old Dominion University (ODU) has been one of the
largest problems faced by tutoring administrators (Turner, 2014). Tutoring at ODU is made
available to students by several disparate programs with their own requirements, goals, and
resources. This can make it difficult for students to identify what services are available to them,
and the lack of communication can mean that employees of one program may not know enough
to refer students to the program that does offer the help they seek. This problem could be
mitigated, however, by a resource management system which allows for the scheduling of any
program’s resources through the same interface.
1.1 Purpose
REMSY is a web and mobile application designed to facilitate the management of
tutoring resources at ODU. Students, tutors, professors, and program employees can access
REMSY via its web portal. The system allows for tutoring sessions to be scheduled by
administrators of tutoring programs who then assign tutors to each session. These sessions are
associated at the course level within REMSY, so any tutoring sessions offered for the course are
Lab 2 – REMSY Product Specification
4
visible regardless of physical location, sponsoring program, or assigned tutor. This allows
students to understand what tutoring is available to them at a glance, and helps the employees of
tutoring programs advise students of their options. Administrators also have the ability to
generate reports, using REMSY data, regarding student attendance, requests, and performance.
This allows for review of student behavior and program effectiveness by administrators.
Students can view available sessions for classes they are enrolled in, sign up, withdraw,
or apply to be a tutor. They can also request tutoring in courses where insufficient or no tutoring
at all is currently offered or volunteer to informally tutor their peers in a subject or course.
Student attendance verification and logging is performed by opening and closing a tutoring
session within the REMSY system. This can be accomplished through the web portal on any
desktop computer or a kiosk machine hooked up to a card reader at tutoring locations. Students
and tutors can elect to receive email, SMS, or mobile app-based alerts. Tutors can view
enrollment in their sessions and cancel or reschedule a session in case they will be unable to
attend. Professors can sign into the system to check if any of their students have attended
tutoring for their course.
Students can make use of the REMSY mobile application to quickly perform tasks like
signing up for or withdrawing from a session. Student attendance verification can also be quickly
performed via the mobile app. Tutors can also make use of the mobile application to check the
roster for their sessions and participate in attendance verification. Both the web portal and
mobile app will demonstrate FERPA and Section 508 compliance.
1.2 Scope
REMSY’s primary goals are to enhance understanding of tutoring needs and
effectiveness at ODU and streamline the tutoring process for students and tutors. By collecting
Lab 2 – REMSY Product Specification
5
information on all students, making use of tutoring resources at ODU within the same system,
data does not have to be manually shared between programs. This allows for reports based on
this data to be easily generated, which can aid in the analysis or resource needs and performance.
The relative effectiveness of tutoring in one course versus another could be analyzed by
examining the reduction in D, F, withdrawal, and incomplete (DFWI) grades earned in each
course, without the large amount of legwork such a comparison would currently require. By
making use of data already available to ODU, designing the user interface with the user’s
experience in mind, and offering functional mobile access, REMSY can reduce the
administrative burden that tutoring currently places on tutors and students. Instead of going
through each possible program and location to see if tutoring for a course is available, a student
should be able to click on a course and see any available sessions. If there are none, the student
should be able to indicate their interest without sending an email or visiting an office. If tutoring
begins being offered in that course, the student should receive a notification. Mobile support will
also reduce the dependency on fixed lab locations for tutoring as students and tutors will be able
to open and close sessions using their phones. Reducing the hassle associated with tutoring
should increase the number of students willing to take advantage of it.
The prototype of REMSY will implement all major systems designed for the finished
product. It will also, similarly, demonstrate FERPA and Section 508 compliance. However, due
to a lack of access to sensitive ODU resources, several external systems will need to be
simulated. University authentication (Shibboleth), student database access (Banner), and email
services will be approximated to show proof of concept. A test harness will also be created to
allow developers to quickly populate and remove sample data to allow for the testing of REMSY
functionality.
Lab 2 – REMSY Product Specification
6
1.3 Definitions, Acronyms, and Abbreviations
508 Compliance: Amendment of the Rehabilitation Act which requires Federal agencies to
make electronic and information technology accessible to people with and without disabilities.
Apache: Open source web server providing a full range of web server features distributed by the
Apache Software Foundation.
Banner: Centralized academic and administrative records system.
DFWI: D grade, failure, withdrawal, or incomplete in a given course.
Family Educational Rights and Privacy Act (FERPA): Federal law that protects the privacy
of student education records. The law applies to all schools that receive funds under an
applicable program of the U.S. Department of Education.
Human Interface Device (HID): Type of computer device that interacts directly with, and most
often takes input from, humans and may deliver output to humans.
Hypertext Transfer Protocol Secure (HTTPS): Communications protocol for secure
communication over a computer network, with especially wide deployment on the Internet.
Java: Computer programming language that is concurrent, class-based, object-oriented, and
specifically designed to have as few implementation dependencies as possible.
Internet Protocol (IP): Network layer protocol used for identifying network devices and
directing traffic between them. Part of TCP/IP.
Kerberos: Computer network authentication protocol which works on the basis of 'tickets' to
allow nodes communicating over a non-secure network to prove their identity to one another in a
secure manner.
Lightweight Directory Access Protocol (LDAP): Application protocol for accessing and
maintaining distributed directory information services over an IP network.
Lab 2 – REMSY Product Specification
7
MySQL: Open Source SQL database management system by Oracle Corporation.
Objective-C: General-purpose, object-oriented programming language that adds Smalltalk-style
messaging to the C programming language.
ODU: Old Dominion University.
PHP: General-purpose scripting language that is especially suited to web development.
Remote Desktop Protocol (RDP): Proprietary protocol developed by Microsoft, which provides
a user with a graphical interface to connect to another computer over a network connection.
REMSY: Resource Management System to aid in scheduling and collecting information on
tutoring at Old Dominion University developed by the Spring 2014 CS411 Team Blue.
Secure Shell (SSH): Cryptographic network protocol for secure data communication, remote
command-line login, remote command execution, and other secure network services between
two networked computers.
Shibboleth: Single sign-on process that authenticates and authorizes a user, and allows a user to
access secure sites by using university computing account username and password.
SMS: Short Message Service.
Simple Mail Transfer Protocol (SMTP): Internet standard for electronic mail (e-mail)
transmission.
Structured Query Language (SQL): Special-purpose programming language designed for
managing data held in a relational database management system (RDBMS).
Transmission Control Protocol (TCP): Transport layer protocol used for reliable
communication between devices across a network. Part of TCP/IP.
TutorTrac: Completely web-based management software for learning, writing, reading, tutoring
departments, and academic skills centers developed by Redrock Software.
Lab 2 – REMSY Product Specification
8
UI: User Interface.
UIN: University Identification Number.
1.4 References
Hohensee, Seth. (2014). Lab 1 – REMSY Product Description. Norfolk, VA
Turner, Jeffrey. Personal interview. February 11, 2014.
United States Government. (n.d.). Resources for understanding and implementing Section 508.
In Section508.gov Opening Doors to IT. Retrieved February 12, 2014, from
http://www.section508.gov/
U.S. Department of Education. (n.d.). Family Educational Rights and Privacy Act (FERPA). In
ED.gov. Retrieved February 12, 2014, from
http://www.ed.gov/policy/gen/guid/fpco/ferpa/index.html
1.5 Overview
This product specification details the REMSY prototype’s hardware and software
composition, external interfaces, and functions. Detailed descriptions of the prototype
architecture, functional components, and external interfaces can be found in the sections to
follow. The prototype’s key features, the characteristics exhibited by these features, and the ways
in which these features will be expected to perform are also detailed.
2 GENERAL DESCRIPTION
The REMSY prototype’s composition, general functionality, and external interfaces are
outlined in the following subsections.
2.1 Prototype Architecture Description
REMSY’s major components include the REMSY virtual machine, web server, mobile
application, and the REMSY database server. These will interface with the model Banner
Lab 2 – REMSY Product Specification
9
database, and Active Directory server, the ODU Computer Science Exchange email servers. The
web server, database servers, and test harness are hosted on a CentOS virtual machine. The web
portal is written in PHP and running on Apache. It is the main interface for REMSY, through
which administrators, professors, tutors, and students can perform any of their assigned actions.
The mobile application runs on student and tutor mobile devices running Android or iOS. This
can be used to complete common tasks and receive alerts. The REMSY database is a MySQL
database used to store user, session, and location data. The Banner model database is used in
place of access to ODU actual banner system for development purposes. The test harness is used
to modify its contents for development and testing purposes. The web server and mobile app
authenticate logins against the Active Directory server. Email and SMS alerts are sent out from
the web server through the Exchange servers. A visual representation of the prototype
architecture can be seen in Figure 1.
Figure 1. Prototype Major Functional Components Diagram
Lab 2 – REMSY Product Specification
10
2.2 Prototype Functional Description
The web server allows for tutors and students to seek or offer tutoring and manage their
sessions, personal information, and notification settings. It also contains the test harness which is
used to clear and repopulate simulated student information for testing purposes. It allows
administrators to generate reports based on attendance and performance data and manage
tutoring sessions. Professors will be able to see which students from their classes have attended
tutoring for the course in question. The mobile app will provide students and tutors with the
ability to seek tutoring and manage their sessions, as well as receive notifications.
2.3 External Interfaces
This section identifies the external interfaces and protocols used in the development and
operation of the REMSY prototype.
2.3.1 Hardware Interfaces
A HID card reader will be used to read UIN data from ODU Identification cards. It will
communicate via USB with a kiosk computer set up to allow communication with the REMSY
web server. This will be used to open and close tutoring sessions.
2.3.2 Software Interfaces
The REMSY web server will access data from the Banner model databases via SQL
query. The Department of Computer Science Exchange email servers will be sent mail using
SMTP. LDAP and Kerberos will be used by the web server and mobile app to authenticate
against Active Directory.
Lab 2 – REMSY Product Specification
11
2.3.3 User Interfaces
REMSY can be both administered and accessed via a keyboard and mouse from a
desktop or laptop computer. Laptops may additionally make use of a track pad or touch screen
display in lieu of a mouse. Mobile users will make use of a touch screen display with on screen
keyboard. Mobile users may, in some cases, also make use of a stylus. Desktop and laptop users
will most likely view REMSY through an LCD flat panel display of varying size. Users opening
a session through a kiosk machine may make use of a card reader.
2.3.4 Communications Protocols and Interfaces
The majority of communications between desktop users and REMSY, as well as between
REMSY components, will be handled via TCP/IP over 1Gb Ethernet. Mobile users may make
use of IEEE 802.11 to access REMSY wirelessly. Card readers be connected to will kiosk
machines via USB. Prototype authentication will be handled using LDAP and Kerberos to
connect to an Active Directory domain. The REMSY web portal will be accessed via HTTPS
using a web browser. SSH will be used to administer the REMSY server, while Remote Desktop
Protocol will be used to administer the Active Directory server. Email will be sent from the
REMSY web server using SMTP.
3 SPECIFIC REQUIREMENTS
The requirements which the REMSY prototype must meet are detailed in the following
subsections.
3.3 Assumptions and Constraints
The assumptions, constraints, and dependencies detailed in Table 1 have been observed
in the REMSY prototype. These included conditions which, if not met, will affect the
Lab 2 – REMSY Product Specification
12
functionality, performance, or usability of the prototype in some way. Several of these conditions
are based around external influences on the REMSY project.
Condition
A HID card-reader is
available for the prototype
A mobile device is available
for the prototype
Integration of REMSY with
legacy software
Use of University resources
is available for the prototype
User data from the
University will be available
to populate the Banner
model database
Only valid data entries will
be provided
Type
Dependency
Constraint
Effect on Requirements
The HID reader function must be
simulated if one is not available
The mobile application must be simulated
if one is not available
Modeled software will need to be created
Constraint
Resources will need to be modeled
Constraint
Simulated data will need to be created
Dependency
Assumption
Allow for minimal error checking for
purposes to developing and demonstrating
the prototype
Allow for minimal errors for purposes to
developing and demonstrating the
prototype
Only valid data regarding
Assumption
courses, users, and tutoring
sessions are stored in
databases
All necessary data will be
Assumption Allows for development and
simulated for the prototype
demonstrating the prototype
All protocols of
Assumption Allow for all forms of required
communication for sending
communication to be developed and
notification will be available
demonstrated for the prototype
for the prototype
REMSY will be accessible
Assumption Allow for all browsers to be used for
on all popular browser
demonstrating the prototype
Reporting module and
Assumption Allow for generation of reports
Tracking module will be
available for prototype
Table 1. Effects of Assumptions, Dependencies, and Constraints on Requirements