Lab II – Prototype Product Specification Steven Humbertson...

Running head: LAB II – Prototype Product Specification 1

Lab II – Prototype Product Specification

Steven Humbertson

Old Dominion University

CS411W

Janet Brunelle

November 1, 2016

Version 1

LAB I – Prototype Product Specification 2

Table of Contents

1 Introduction...............................................................................................................................................................3

1.2 Scope..................................................................................................................................................................4

1.3 Definitions, Acronyms, and Abbreviations...........................................................................................6

1.4 References.........................................................................................................................................................6

1.5 Overview........................................................................................................................................................11

2 General Description...........................................................................................................................................11

2.1 Prototype Architecture Description.......................................................................................................11

2.2 Prototype Functional Description..........................................................................................................14

3 Specific Requirements…………………………………………………………Foundinseparatedocument

List of Figures

Figure1.MajorfunctionalcomponentdiagramofPCSS......................................................................13

Figure2.PCSSprototypedatabaseschema................................................................................................14

Figure3.PCSSprototypeuserinterfacesitemap.....................................................................................15

Figure4.Studentsearchprocessflow..........................................................................................................16

Figure5.ReportGenerationprocessflow..................................................................................................17

Figure6.Coursecatalogeditprocessflow.................................................................................................18

List of Tables

Table1.PCSSreal-worldproductvs.prototype......................................................................................12


Lab II – Predictive Course Scheduling System Description

1 Introduction

According to a 2015 study performed by the U.S. Bureau of Labor Statistics, software

developers and computer systems analysts are two of the top twenty occupations expected to

have the greatest projected growth (U.S. Bureau of Labor Statistics, 2015). It reports that the

number of projected openings from 2014 to 2024 will be 135,300 for software developers and

118,600 for computer systems analysts. Additionally, it states that the 2015 median annual pay

for software developers was $98,260, and $85,800 for computer system analysts. These are

influential statistics for students selecting a college major. A study by National Center for

Educational Statistics reports that the number of awarded Bachelor’s degrees in computer

sciences and engineering increased from 117,011 in 2000-01 to 154,917 in 2013-14 (U.S.

Department of Education, 2015). As the demand for computer science degrees continues to

increase, universities struggle to meet the demand.

Schedulers are university faculty responsible for building future semester schedules.

Schedulers attempt to plan the necessary number of course sections for every class offered in a

future semester. However, schedulers are unable to anticipate student demand and intent.

Planning an insufficient number of course sections for a course results in some students not

being able to register for the courses they need. These students risk delaying their graduation,

losing full-time status, or experiencing problems with financial aid. Courses can be added prior

to the start of a semester to meet demand, but allocating university resources prior to the start of

a semester is problematic.

Limited university resources, such as teachers and classrooms, complicate adding new

course sections during registration. In a report from the Bureau of Labor Statistics, the number


of postsecondary computer science educators has declined, from 37260 in 2004 to 35410 in 2014

(Bureau of Labor Statistics, 2014). A new course section is added only if the resources can be

allocated. If a high demand for particular courses can be detected months in advance, there

would be sufficient time to allocate additional resources.

1.1 Purpose

The main goal of Predictive Course Scheduling System (PCSS) is to help anticipate the

demand for computer science courses. PCSS will compute the number of course sections to

offer in a future semester so necessary university resources can be attained in advance.

Students, advisors, schedulers, and PCSS system administrators will be the intended users of the

prototype. The instructor user role will not be supported in the prototype. The prototype will

implement an authentication and access control system to restrict features and functions to

authorized users.

To help achieve the goal of anticipating course demand, the PCSS prototype will track

student intent. The prototype will be used during student advising meetings by the advisor, who

will record advising notes and update the four-year plan for each student. The student will be

able to view this information in PCSS. However, the prototype will not allow students to edit the

course intent in their four-year planner or start a waitlist for courses that have reached full

capacity.

Schedulers will use the PCSS prototype when creating future semester course schedules.

They will be able to generate and view the course schedule predictions for future semesters. The

prototype will not import university resources, such as classroom and instructor availability, and

therefore will not implement the scheduling assistant. The scheduling assistant is the feature

responsible for building proposed course schedules and reserving the necessary resources for


each course section. The prototype will not interface with Banner to gather up-to-date

registration data or import historic course schedules. As a result schedulers and administrators

will be given a feature to add or remove courses to a semester’s roster in the prototype. This

semester course list is visible to advisors when building student long-range plans, and schedulers

when generating the predicted number of courses to offer.

The prototype will implement a reporting feature. However, since university resource

usage will not be imported and the prototype will not interface with Banner, it will demonstrate

reduced functionality. The reporting feature will show student enrollment and course intent

trends of computer science courses at Old Dominion University.

1.2 Scope

The PCSS prototype is being developed as a proof-of-concept for tracking student intent

in order to help schedulers anticipate the appropriate number of course sections to offer in future

semesters. The first functional goal is to store advising notes for each computer science student.

Advisors will have the capability to search for a student from a list of computer science students.

Once a selected student is loaded, the advisor will be presented with a record of the students

advising, as well as their four-year plan. Advisors will create or modify student’s four-year

plans during student advising. Students will have the capability to view the record of the

advising session in the prototype.

The second functional goal is to develop a scheduling module responsible for computing

the number of course sections to offer in future semesters. For each course offered in the future

semester, the prototype will evaluate the long-range student intent planners to determine the

correct number of course sections to offer. The scheduler will have the ability to view statistics

regarding the number of students intending to take each course and the number of course


sections offered historically. To mitigate the risk that some courses may not be offered in future

semesters or new courses may be added, the administrator and scheduler will have the capability

to add or remove courses from the available courses list. This will eliminate the possibility that a

removed or canceled course could be added to a student’s planner or be taken into account when

predicting the number of course sections to offer.

1.3 Definitions, Acronyms, and Abbreviations

Adaptive Prediction System (APS): A system that adapts its predictions based on the analysis of

different datasets pertinent to course registration. One of the three main components of

PCSS.

Adjunct: Instructor hired by a college to teach but isn't a full member of the faculty

Admin: An abbreviation for administrator. Administrator users in the PCSS system have access

to the functionalities of all users in the PCSS system.

Advising Information: Information that assists students in course planning that the advisor

reviews or has access to. Includes advising notes and student intent data.

Advising Notes: Text notes an advisor supplies to a student. Contains advisor recommendations

regarding the upcoming semester. Accessible from the advisor UI or the student UI.

Advisor: Faculty member assigned to a student that oversees that student’s course planning and

offers advice on course selection. Not all advisors are instructors and vice versa.

Algorithm: Step-by-step set of operations or computations to perform.

Application Programming Interface (API): Set of methods and tools for building software

Authentication and Access control: Permission system to allow for different users (students,

advisors, scheduler) similar to UNIX.


Automation: Automating tasks that were previously manually. In the context of the PCSS, the

manual tasks were done by the scheduler, faculty, and advisors.

Back-end: Data access layer of the PCSS. Includes the prediction system and the PCSS database.

Banner: ODU’s academic and administrative records system. It is the source of the majority of

historic registration data used by the PCSS system.

Course: A course subject with set curriculum taught at ODU. E.g. CS 330, CS 361. Multiple

sections of a particular course can be offered.

Course Creation Assistant (CCA): A component of the PCSS system that facilitates the creation

of a course schedule draft.

Course Schedule (Schedule): A list of course sections that a university department offers each

semester, made of all courses that are to be offered that semester.

CS: Abbreviation for computer science.

Database: Structured set of data held in a computer. Typically organized by tables, data fields

and data type.

Firewall: Computer system or program designed to prevent unauthorized access

Four Year Plan (FYP): A form that contains a student’s course plan per semester, up until their

graduation, which typically is four years long for most students.

Front-end: Presentation layer of the PCSS. Includes authentication and access control and GUIs.

Graphical User Interface (GUI): Type of user interface that allows program usage through

graphics and visuals instead of text based commands through a command line.

Instructor: A faculty member that teaches a course at the university. Not all instructors are

advisors and vice versa.


Interface: A connection between two entities. They can be two pieces of software, humans, or

both.

Java: A multi-platform object-oriented programming language developed by Sun Microsystems.

Java Database Connectivity (JDBC): A Java application programming interface that allows java

code to directly communicate with a database.

Legacy system: Older systems used in the previous scheduling process prior to the introduction

of the PCSS.

Leo: Web-based self-service student information tool that allows students and faculty access to

information, such as registration information and status of semesters’ courses. It obtains

data from Banner.

Major Functional Component Diagram: A diagram showing the major software and hardware

components of the PCSS, as well as the legacy systems that it must directly interact with.

MySQL: An open-source relational database management system.

Notification: A message. The PCSS has two forms of messages: internal and external messages.

Internal messages are messages stored within the PCSS system. External messages are

emails.

ODU: Abbreviation for Old Dominion University.

Pair programming: An agile software development technique where two programmers

simultaneously develop code. One programmer will type, while the other programmer

looks for errors and assists with problem solving.

Parsing: Analyze into parts by following a set of rules.

PCSS: Abbreviation for Predictive Course Scheduling System.


Portal: A page with links to functionality. Each user has their own portal with links to various

pieces of functionality that they are authorized to use.

Prediction: An output of the list of courses and sections that the PCSS system has determined

would represent the ideal courses schedule to meet student demand. A prediction makes

use of one of four data sets: FYP, rollover, pre-registration, and student intent data.

Predictive Course Scheduling System(PCSS): A proposed system that aims to solve many of the

issues that encumber the course schedule process.

Pre-registration data: Data from current students registered in the first five days of the

registration period.

Process Flow: Visual flowchart of how individuals act within a domain model Section -- a

particular instance of a class with an instructor, time-slot, and assigned classroom (in the

event of a live class session).

Prototype: Initial or preliminary model used typically as a proof-of-concept and a starting point

for incremental developments For the PCSS, it is a simplified version of the full PCSS

product, intended to demonstrate the core functionality of the system.

Real World Product: The overall design and functionality expected from a real world system.

Rollover: A spreadsheet of courses that were offered exactly one year from a particular semester

of interest. For example, the rollover spreadsheet that is used for spring 2017 schedule

planning is the final spring 2016 course schedule.

Scalability: Ability for a system to maintain reasonable efficiency as the dataset grows.

Scheduler: University staff member that creates future semester schedules for a specific

department, by planning the courses that will be offered and allocates resources to each

course section.


Scheduling assistant: PCSS functionality that centralizes the information needed to construct a

future semester include timeslots, classrooms, and available instructors.

Scheduling/Schedule planning: The process of creating a schedule for a department. Done by the

department scheduler.

Screen Scraping: The process of using a computer program to extract data from a webpage.

Student: A university student using the PCSS system.

Student Application: One of the two parts that make up the notification system. The student

application makes students’ recommended course selections available to them online

after an advising session.

Student Intent: A list of courses a particular student is interested in taking in a particular

semester.

Unit Test: Tests for smaller, more specific modules of a larger software system.

User: A user of the PCSS system. The users are students, advisors, instructors, schedulers, and

administrators.

User Interface: The graphical part of the application that the end user interacts with.

Virtual Machine: A software computer typically run within another operating system

Wait List: A queue of students waiting to enter a full. 1.4 References

Bureau of Labor Statistics. (2014, May). Occupational Employment and Wages. Retrieved

March 25, 2016, from 25-1021 Computer Science Teachers, Postsecondary:

http://www.bls.gov/ oes/current/oes251021.htm

ODU Office of Institutional Research. (2015). Headcount Majors with Secon Majors.

Retrieved 9 17, 2016, from ODU Factbook:

http://ww2.odu.edu/ao/ira/factbook/hc_majors/hcmajor_main.shtml


Humbertson, S. (2016, October 24). Lab I - predictive course scheduling system description.

Unpublished paper, Old Dominion University, Norfolk, VA.

U.S. Bureau of Labor Statistics. (2015, December 17). Most New Jobs: 20 Occupations with

the Highest Projected Numeric Change in Employment. Retrieved September 16, 2016,

from Bureau of Labor Statistics: http://www.bls.gov

U.S. Department of Education. (2015, October). 2015 Digest of Education Statistics Table

318.20. Bachelor's, master's, and doctor's degrees conferred by postsecondary institutions,

by field of study: Selected years, 1970-71 through 2013-14. Retrieved September 16, 2016,

from Institute of Education Sciences National Center for Educational Statistics:

https://nces.ed.gov

1.5 Overview

This product specification is for the PCSS prototype. The remainder of this document

provides a detailed description of the components necessary to build and implement the

prototype. The key hardware piece is the virtual machine that will host the prototype. The key

software components to the PCSS application are the graphical user interface, back-end

algorithms, and database. This section will cover the inputs, outputs, and simulated data that will

be supplied to the system for purposes of developing and testing the prototype.

2 General Description

ThePCSSprototypewilldevelopasystemtotrackandstorestudentintent.Itwill

includefunctionstopredictthenumberofcoursesectionstoofferinafuturesemester

basedonstudentintentandadvising.AsindicatedinTable1,theprototypewillimplement

asubsetoffeaturesofthereal-worldproduct.Duetotimeandbudgetconstraints,the

prototypewillnotincludeanotificationsystem,studentmobileapplication,instructor


profiles,orinstructoruserinterfaces.Theuserinterfaceforstudentswillbepartially

implementedtoallowthemtoviewtheiradvisingnotes.

DuetoODUrestrictingaccesstoBanner,thePCSSprototypewillnotinterfacewith

itorincludealgorithmstoparsedataimportedfromBanner.Thepredictivesystemand

reportgenerationalgorithmswillbepartiallyimplementedintheprototypesincePCSSwill

nothaveaccesstohistoricsemesterschedules,real-timepreregistrationdata,or

registrationinformation.Additionally,duetotherulesandregulationsprotectingstudent

data,simulateddatasuchasnames,datesofbirth,anduniversityidentificationnumbers

willbesuppliedtothesystemtodevelopandtestthepredictivesystem.

Table1.PCSSreal-worldproductvs.prototype.


2.1 Prototype Architecture Description

The PCSSapplicationwillbeimplementedonavirtualmachineonanODU

ComputerScienceDepartmentserver,asdemonstratedinFigure1.VMwareisthe

virtualizationsoftwareforthePCSSvirtualmachine.Thevirtualmachinewillemulatea

dualcore,IntelXeon2.20GHzprocessor,andrunLinuxUbuntuoperatingsystem,version

4.40-42forx86_64architecture.Theend-userswillaccessPCSSthroughtheInternetusing

personaldesktopsorlaptops. The desktop application being developed for the PCSS

prototype can be installed on the computers of end-users, however an Internet connection is still

required for the application to access the PCSS ‘Registration Database’. Users must be

authenticated prior to accessing the system. Once authenticated, each user will be transferred to

an access control system, which restricts access to only the features and functions relevant to

their role at the university.

Figure2.MajorfunctionalcomponentdiagramofPCSS.


ThesameODUcomputersciencevirtualmachinewillhostthedatabase.Itwillbe

builtusingMySQLversion14.14,distribution5.7.16,forLinuxx86_64operatingsystems.

Thedatabasewillstoreuserprofiles,schedulepredictions,andthelistofODUcomputer

sciencecourses.Duetotherulesandregulationssafeguardingstudentdata,simulated

studentdatawillbesuppliedtotheprototypedatabaseforthepurposesoftestingand

demonstratingtheprototype.Studentprofileswillbeloadedwithsimulatedcourseintent

data.

2.2 Prototype Functional Description

The database for PCSS will be managed with MySQL and will contain five tables, as

demonstrated in Figure 2. The table labeled ‘Users’ will store usernames, roles, login

credentials, university identification numbers, and birth date for every user. If the user is a

student, their major will be recorded in the ‘major’ column.

Figure2.PCSSprototypedatabaseschema


Student advising notes and long-range course intent will be saved in ‘Advising notes’ and

‘Advising intent’, respectively. The ‘Users’ table has one-to-many relationships with ‘Advising

notes’ and ‘Advising intent’ tables. ODU courses and their availability will be kept in the

‘Courses’ table. A one-to-many relationship exists between ‘Advising intent’ and ‘Courses’

tables. The semester schedule course predictions generated by schedulers will be stored in the

‘Saved predictions’ table. This table shares a many-to-many relationship with the ‘Courses’

table.

JavaFX will be used to develop the graphical user interface. The site map demonstrated

in Figure 3 shows the interface screens that will be developed. Every user is required to log into

the system. The login screen provides users the capability to enter their credentials. Once a user

is authenticated, access control will direct them to the appropriate landing page based on their

role as stored in the ‘User’ database table.

Figure3.PCSSprototypeuserinterfacesitemap.

Students will have a landing page with a link to view their profile, which contains

advising notes created by the advisor during an advising session. Administrators, advisors, and

schedulers will have screens for viewing future course trends from the ‘Current Student Intent


Data Page’, and viewing saved predictions of future semester schedules. Administrators and

advisors will have screens that will allow them to search student profiles in the database.

Selecting a student from the search results will display the advising notes and four-year planner

of a selected student in the ‘Student Profile Window’. From this window, student advising notes

can be edited and saved to the database. Administrators and schedulers will have a link to edit

the course list for semesters, providing the capability to add or remove courses to a semester’s

roster.

Figure4.Studentsearchprocessflow.

The algorithm illustrated in Figure 4 will allow advisors and administrators to search the

student profiles in the PCSS database. When provided information, such as first name, last

name, date of birth, or university identification number, the algorithm will query the database for

matches. Any matching profiles are returned and displayed to the user.


Figure5.ReportGenerationprocessflow.

TheprocessforreportgenerationisillustratedinFigure5.Thisalgorithmqueries

four-yearcourseplannersineachstudentprofile.Thereturneddataisusedtogenerate

thepredictednumberofcoursesectionstoofferinafuturesemester.Thisdatais

displayedtotheuserandstoredinPCSSasaspreadsheet.Alinktospreadsheetfileis

recordedinthedatabaseforlaterreference.

(This space intentionally left blank)


Figure6.Coursecatalogeditprocessflow.

The process to edit the list of courses offered in a semester is illustrated in Figure 6.

After the user is authenticated and navigates to the ‘Course List Page’, they will have the

capability to enter a year and term for a specific semester. Utilizing the user-supplied data, the

database is queried and a list of courses for the selected semester is displayed to the user. The

user has the option to edit the list. If the user edits the list, they can store the changes to the

database.

Lab II – Prototype Product Specification Steven Humbertson...

Documents

Transcript of Lab II – Prototype Product Specification Steven Humbertson...