High Level Description of Project (scroll to bottom for detailed Quality Assurance and Deployment Plan)

This software aims to provide a simpler and more efficient method to taking student attendance. The PSYC100 course has over 1900 students and approximately 70 different lab sections. However, attendance is taken using the conventional paper-and-pencil method, which results in a lot of administrative work. An electronic system that can efficiently track lab attendance can reduce the amount of work for teaching assistants, and divert their time for more productive work.

Introduction

The Data Secure Student Attendance Database intends to replace the current attendance-tracking method for PSYC-100 labs with QAtt, an Android app developed for TAs, and QGen, a desktop program developed for course administrators. This new system will provide course administrators with greater oversight over attendance, save TAs time, and eliminate paper waste and opportunities for academic dishonesty.

The first part of this report will cover the system’s key software quality requirements, then each quality assurance task that will be performed, and lastly it will address how problems will be reported and dealt with when they are found. The quality tasks will be addressed based on correctness, usability, performance and security. Each task is detailed in a separate subsection.

Quality

Quality in the context of QGen and QAtt means that the system will be capable of fulfilling not only the minimum requirement of the software but also the important tasks that would greatly increase the usefulness of the software, raising the overall quality. The following tasks should meet or exceed a specified level of success in order to achieve appropriate level of quality assurance.

QGen must:

(critical)

create QR codes for each PSYC-100 student in the .CSV file provided. QGen will succeed when each QR code is unique and contains each student’s netID, time, and date of lab.
populate and export a .CSV file for automatic mark distribution that follows a specific structure specified by OnQ and provided by course administrators. QGen will succeed if the .CSV file correctly specifies which students receive marks for attendance and which do not - no amount of error is acceptable in this requirement.

(important)

record each student’s information in the database. QGen will succeed if every student test case is correctly recorded - no amount of error is acceptable in this requirement.
enroll or unenroll students throughout the semester. QGen will succeed if every student test case is either successfully enrolled or unenrolled.
transfer students to another lab section without affecting their previous attendance record. QGen will succeed if every student test case is successfully transferred along with their attendance record.
email students their correct QR code. QGen will succeed if every student test case receives their respective, unique QR code.

QAtt must:

(critical)

scan and extract information from QGen’s QR codes. QAtt will succeed if every student test case successfully eventually displays the correct netID, time, and date of lab section. To account for camera issues, lighting problems, or poor visual angles, we will allow QAtt 3 attempts to scan each QR code. Each individual attempt should not add more than 5 seconds to the scan time to ensure that the overall scanning process does not go overtime. If QAtt fails to scan and extract information from a QR code 3 times in a row, or takes longer than 15 seconds to do so, QAtt fails.
store each student’s netID as they are scanned for each lab section, and also store the time of the scan. QAtt will succeed if every student test case is correctly stored.

(important)

verify that the time of scan for each student corresponds to the time they should have been scanned: this confirms that they are attending the correct lab. QAtt succeeds if every student test case is correctly identified as either “in the right lab” or “in a different lab.”
verify that the time of scan of each student falls within a 15 minute interval before or after the start of their scheduled lab time. QAtt succeeds if all student test cases inside of that interval are recorded as attended AND all student test cases outside of that interval are recorded but not marked as attended.

One of the important non-functional quality that our customers desired was the usability of the software. To address this quality concern, QAtt and QGen will have minimalistic design and self-explanatory buttons and texts. Furthermore, thorough documentation and manual will be provided to aid the users in their learning of the software. To verify that the software is user-friendly, usability testing will be performed to check that new users are able to execute required tasks in less than 10 minutes for QAtt, and less than 15 minutes for QGen.

Tasks

We intend to divide our test stages into 5 tasks:

QAtt Pre-scan
QAtt Scan
QAtt File
QGen Classlist
QGen Attendance

Each task will follow a routine of unit testing and integration testing. After individual tasks have passed all of our testing cases, we then perform integration testing as a whole on our two systems followed by system testing and acceptance testing.

The first type testing we will perform is unit testing. These tests are designed to partition the functional specifications into smaller requirements and each test would cover a part of the functional requirement of the software.

Once we finish all individual unit testing, we start combining the tested modules and start integration testing. We will combine the unit tested modules and test the behaviour as a combined unit. The final two integration testing would be QAtt integration functionality testing and QGen integration functionality testing.

System testing is a software testing method that identifies if a system is successfully integrated. Because we will be replacing the previous attendance method, integration for us means ensuring that the transition to the QGen/QAtt system will go smoothly. We plan to hold a testing session (or a series of them) with the course administrators, walking them through both pieces of software and answering any last questions that come up. The success criteria will be their approval.

Finally, acceptance testing would be our final testing based on specifications of the end-user (TA, Professor, students in the course) and customer. We verify the product aligns what our stakeholders are hoping for and deliver the final product.

QAtt:

We will begin by creating the unit tests for QAtt. These tests will define precise requirements for the QAtt before the scanning stage, during the scanning stage and file access stage. It will be in the format of a set of explicit test inputs and expected outputs. They are written in reference to our requirements document, QAtt activity diagram, QAtt use case and QAtt UML.

These are some examples of black-box unit tests that could be created based on our requirement specification, and much more units tests will be created after the system has been coded for white-box unit tests that would test more specific codes in depth.

QAtt Pre-scan unit tests

Testcase Name	Description	Input	Output	UI Display
SU01_start_program	Check that QAtt can successfully start up	None	None	Pick current week
SU02_camera_mode	Once week is selected, the app will switch to a camera mode	None	None	Camera

QAtt Scan unit tests

Testcase Name	Description	Input	Backend	UI Display
SU01_scan_result_exceedtime_after	QAtt will not recognize scans after 15 minutes from the start of the lab	QR Code	- Checks time	Red, “Time limit exceeded”
SU02_scan_result_exceedtime_before	QAtt will not recognize scans before 15 minutes from the start of the lab	QR Code	- Checks time	Red, “Too early to scan”
SU03_scan_result_successful_correct_lab	Valid QR code with correct lab section is placed to be captured by the forward camera	QR Code (correct lab section)	- Check QR code - Check lab section - Saves QR code information + time scanned to local database on phone	Green, “Scan verified!”
SU04_scan_result_successful_incorrect_lab	Valid QR code with incorrect lab section is placed to be captured by the forward camera	QR Code (incorrect lab section)	- Check QR code - Check lab section - Saves QR code information + time scanned to local database on phone	Yellow, “Student is attending an expected lab!”
SU05_scan_result_invalidQR	Invalid QR code is placed to be captured by the forward camera	QR Code (invalid)	- Check QR code	Red, “Invalid scan!”

QAtt File unit tests

Testcase Name	Description	Input	Backend	UI Display
F01_save_to_database	Check that QAtt can successfully save information to local database	QR code	Insert entry to database	none
F02_write_to_file	Check that a csv file can be created from the SQL database on android device	database	(requires android 2.2 or higher) Creates csv file on phone	Csv file is successfully created
F03_get_csv	Check that csv can be exported when connected to PC	None (connect to PC)	none	none

Once each unit module is tested and runs successfully, we will combine the unit tested modules and test them together as a whole.

QAtt Sample Output file should be in the format as below:

NetID	Attendance	Time of scan	Day	Week
15ysj	true	16:32:47	Mon	3
14dhe	false	16:33:05	Mon	3
13ake	false	16:58:34	Mon	3

QGen:

Quality assurance tasks for QGen will also start from creating unit tests for basic but essential features of QGen. It will be created based on the following requirements for QGen:

QR codes will be generated by QGen when provided with a .CSV file containing the student’s netID, time and date of the lab section
QGen can email students their QR codes
QGen saves backup images of QR code
QR codes are unique for each student
A master .CSV file is extractable from the QGen database
Marks are given to a student who has attended the lab section
Marks are not given to students who are absent (did not scan QR code)
QGen will display list of students who attended the wrong lab
QGen’s database can be updated to account for drop and new enrollments of the course at beginning of the term
QGen’s database records can be updated to account for changes in the lab sections
QGen can produce a .CSV file in the format which can be uploaded to OnQ, to appropriately distribute student marks
QGen can save each student’s information on local database

Requirements for QGen are largely divided into two main features, which are generating QR codes from student and lab information, and manipulation of attendance database for updating weekly attendance. Therefore we splitted the test cases into two sections; Classlist and Attendance.

QGen Classlist unit tests

Examples:

Testcase Name	Description	Input	Backend	UI Display
GC01_generate_QR	Create QR codes when given required information	Student.CSV Labs.CSV	Uses the student data and lab section to generate unique QR code	User can view the generated QR codes
GC02_load_classlist	Able to load new classlist info and also replace existing one	Student.CSV Labs.CSV	Populate the database with new classlist data	New classlist data are populated in the database
GC03_student_add	Check that QGen adds a newly enrolled student to the database	New student info including name, netID, lab time, etc	New student is added to database	New student appears in searches and the classlist
GC04_email_QR	Able to send out emails to students with their QR code	Student’s netID	Using the netID, sends out generated QR code to the specific email address	Operation success message

QGen Attendance unit tests

Examples:

Testcase Name	Description	Input	Backend	UI Display
GA01_attended	QGen properly updates attended students as “attended”	QAttWeek#.CSV	Populate the database by marking attended students as “attended”	New week’s column is populated with student attendance
GA02_unattended	QGen does not give mark to unattended and students who attended wrong section	QAttWeek#.CSV	Populate the database, and also distinguish not attended at all and attending wrong section	Attendance is colour coded red for not attended at all, and yellow for attending wrong section
GA03_create_OnQ_CSV	QGen produces a .CSV that is appropriate for upload onto OnQ	Attendance data of chosen week from QGen database	Using the chosen week’s data, create a .CSV file that is in proper format for OnQ upload	New .CSV file is generated at designated location
GA04_create_master_CSV	QGen produces a .CSV that contains complete attendance data	Attendance data of all weeks from QGen database	Combines entire attendance data into one .CSV file	New .CSV file is generated at designated location

As mentioned in the quality section, since these are black-box tests, they checks for the functional correctness of the system. Therefore the success criteria for these tests would be that they pass all these tests with no amount of error. In addition, non-functional requirements which are important to our software should also be either tested for, or addressed by other methods.

The most vital non-functional quality attributes that concerned our customers were security, followed by the usability of the software. The system could be made much more convenient and easy-to-use if our database was stored online. However to conform with our customer’s security demands, we sacrificed usability for security as they did not want any data online. Usability was also a big interest for our software, so we intend to arrange a usability testing session with the users where we will observe any difficulties encountered while conducting assigned tasks, and note down user’s feedback to improve the usability of the software. As we start to code our program, we could also perform code injection techniques to not only make sure code is being executed, but also add performance instrumentation procedure to check that the performance of the software and space occupying meets our quality standards.

One tool we are considering using to assist us in testing the system at different levels is JUnit. It is a unit testing framework for Java and is linked as a JAR at compile time. We will write a test method for every class with expected results on the object under test. We will then run each test case on the console and verify that the test results matches our text output. A successful test will match our expected output.

We currently plan on testing the GUI manually. This is because we only have a few test cases concerning our GUI. Automating the process is also hard and require a lot of effort and work as data input for GUI is very dynamic. Input can be in form of images, scanning, csv files or clicks.

Reporting Mechanism

Workflow:

We expect to face bugs in the development process. To make the inevitable easier, we will write informative error messages and exceptions, and these messages will help us narrow down the cause and location of errors. These errors should not stop the program, so that more errors can be identified if there are more after the first.
When an error is found, we will document it with Github’s bug tracker “Issues”. Issues allows us to specify a name for the bug, a short description, and tags that we can use to sort and search all ongoing bugs.
Collaborative debugging will be done in-person and remotely with the aid of Google Docs and Github Issues. Each error will be assigned to one person taking the lead on repairing it, but Issues’ comments section will allow everyone to provide feedback along the way.
After the necessary rounds of testing are passed, we will decide the error has been resolved.
We will make a note of the error in a shared Google Doc dedicated solely to a history of debugging, and we will update its status in Github Issues along with any further information that should be logged.

Deployment

Introduction

The second part of this report will cover the deployment of the two systems. It will go over the deployment platform, media, recipient, deliverables, configuration, requirements of customer, training, maintenance resources, steps and timeline and the other issues in getting the software deployed. This part of the report involves a more detailed description of what is expected of the final deliverable product.

Deployment Platform

QAtt

Since QAtt is an Android application, it will naturally be run on an Android platform, which supports the Java platform. The Android platform, developed by Google, is a free and open source software primarily designed for touchscreen mobile devices. Currently, Android is the world’s leading smartphone platform. It can be commonly found and accessed freely in most smartphones.

The QR code scanner will be implemented using Zxing, which requires Android SDK 19+, which was released in 2013 and accounts for over 90% of Android devices. SQLite would be used to store the scanned data into the database, and has a maximum storage database size of 140 TB. Since 140TB is significantly more than the average storage size of an Android phone, the amount of records that can be retained by SQLite will be dependent on the storage size of the phone. Since the amount of memory consumed for each student record will be miniscule, a smartphone with a storage size of 32 or 64 GB would be sufficient.

Access to the internet would only be required to install QAtt. Our Android application is designed to function without internet connection, and would not require internet connection after installation.

QGen

QGen is a Java program that will be run on a desktop. Since QGen will be packaged as a .jar file, java runtime environment would need to be installed on the desktop in order to execute QGen. Zxing will be used to generate the QR codes and requires and current supports Java 7+.

Like QAtt, QGen is designed for minimal internet access. Most of the functionalities available by QGen, such as student management and mark distribution, would not require internet connection. The only functionalities that would require internet access would be to send QR codes to the students enrolled in PSYC 100 and uploading marks onto OnQ.

QGen uses SQLite to store the attendance data, and would require the desktop to have the SQLite Java Database Connectivity (JDBC) driver installed. This would allow QGen to open up a connection to the SQLite database and store information.

Media

Both QAtt and QGen will be delivered by two means: email and USB. The emailed copies will be delivered using the Queen’s email system, which is Outlook Office 365. The maximum size of the email is 25 MB, but the limit of each individual size may be limited by the email client. For example, the Outlook Web app has a limit of 10 MB.

QAtt

There are numerous ways an Android application can be distributed, the most common method generally being to broadcast it on Google Play. However, since this app is not meant to be publicized, the app will be distributed by email and through USB.

Preparing the Android application for release through email is accomplished using the same method as releasing it on Google Play. An Android application package (APK) is produced, which can then be attached to an email and sent. The recipient would need to open the email on their Android-powered device in order to install it. When opening the package on the smartphone, the Android system would recognize the APK and provide the user with the option to install the application. However, since the application will not be released on Google Play, the recipient would need to opt-in for installing unknown apps. This can be accomplished by enabling the “Install unknown apps” settings in the smartphone’s system settings. An advantage to emailing the system is that it can then be forwarded and distributed to other users if the devices running the app need to be replaced in the future.

The size of a typical Android application is 6MB. Since QAtt is a small application, designed to simply scan and store data, the size will likely be much smaller than 6MB. This means that sending QAtt via email should not be an issue.

An USB backup containing the APK, along with the source code, will also be provided with the system.

QGen

QGen will be delivered as an executable .jar file via email and USB. Like QAtt, the files will be emailed to our customers. QGen is not designed to be a large application, as it functions mainly as a database system. Delivering QGen by email should not be an issue.

If QGen exceeds the file limit size, the executable .jar file and a corresponding .exe file will be provided in a USB. The addition of the .exe file is to allow our customer to run the program if JRE is not installed on the desktop. However, the .exe file would only be able to be executed on a Windows operating system.

Recipient

The following are a list of people with whom we will interact in making the delivery:

Meghan Norris - Chair of Undergraduate Studies for the Department of Psychology

Cheryl Hamilton - Administrative Coordinator for the Department of Psychology

Rick Eves - General Technician for the Department of Psychology

Meghan Norris and Cheryl Hamilton are our customers. We have been interacting with them from the very beginning to gather the requirements of the software system, and will continue to interact with them until the software has been delivered. Weekly progress reports will be given to our customers beginning next week, and they will also be involved in our acceptance testing rounds. Once the software system has been completed, we will train our customers in using QAtt and QGen.

Rick Eves is the general technician for the department of psychology and will be present when we are training Meghan Norris and Cheryl Hamilton in using our software system.

Deliverables

Program files for QAtt (APK) and QGen (.jar and .exe) will be delivered, along with the source code. By providing our customers with the source code, the program files can be easily recreated, modified, and/or extended. Documentation will also be provided to allow future developers to understand the structure of QAtt and QGen.

A user manual will be delivered to our customers, including instructions for installation and use of software. Screenshots will be provided in the manual to provide more context when guiding the reader. A small section for frequently asked questions (FAQs) will be included, consisting of questions that we anticipate will be asked. This may include clarifications on QR scans, more informative descriptions of pop-up windows which our program will produce for invalid user input, or instructions for special situations.

A small cheat sheet for using QAtt and QGen summarizing the programs will also be delivered. The QAtt cheatsheet is intended to be provided to PSYC 100 TAs as a quick reference for both the usual tasks they will encounter in the lab, and any rarer cases that come up that they may not feel as familiar with. Similarly, the QGen cheat sheet is intended for the psychology administrators, who will be interacting with QGen.

Configuration

QAtt

QAtt will be installed on an Android phone connected to the internet. Once installed, and at the start of every school year, QAtt will need to be set up for the upcoming year. QAtt set-up involves indicating the dates for each week. Currently, PSYC 100 is a full-year course with 24 weeks of labs, and holidays occuring between the weeks. In order to ensure QAtt can be used every year, or in case the course is changed to a half-year course, the user will need to indicate the number of weeks present in the course. A calendar will be shown, from which the user would need to indicate the corresponding dates for each week of the course. Instructions will be provided by the Android application and in the user manual to guide the user through set-up.

Once QAtt has been set up, a short initialization will be required by the PSYC 100 TAs at the beginning of each labs, prior to scanning. QAtt will ask the PSYC 100 TAs to specify the week that they are scanning for, and check that the week selected matches the current week specified during the initial set-up. A window will pop up if there are any discrepancies.

Note that QGen will create and provide the students with their QR codes for QAtt to scan.

QGen

Before QGen can be used, two files are required: the class list containing PSYC 100 student information and the lab sections offered by PSYC 100. Both files will need to be of .csv type. Once initialized, QGen is ready to be used!

Requirements of Customer

The customer will need to provide templates of the initialization files for QGen, and templates of the files outputted by QGen. This is to ensure that QGen will be able to read the data correctly and produce files formatted according to the customer’s expectations. The initialization files will be two .csv files: the class list containing PSYC 100 student information and the lab sections offered by PSYC 100. The output files will also be two .csv files: student marks which will be uploaded onto OnQ, and a master .csv file containing all the data within the database at the time of export.

QR codes will be generated by QGen and automatically emailed to the students. However, the students will also be given a sticker with their QR code at the beginning of the school year, allowing them to adhere it on an item which is generally kept on them, or brought to the lab. This could be a cell phone, a PSYC 100 note book, a student card, etc. In order for QGen to successfully print the QR code stickers, the customer will need to provide their chosen dimensions of the stickers.

Although not necessary, the Android phones intended to be used for QAtt can also be provided to ensure successful delivery. QAtt will be developed in Android Studio, which can create emulators to simulate the application on any Android smartphone. However, having the physical phone that will be used for QAtt will provide assurance during testing and for an absolutely successful delivery.

We have spoken to our customers about these requirements and our customers have agreed to them. The templates have already been provided, and the Android phone will be provided by the end of February so we can begin testing.

Training

Training will be provided to our customers, Meghan and Cheryl, and the tech support team from the department of psychology to ensure that our customers understand how to use the software system. This will be in the form of a short in-person tutorial, demonstrating how QGen and QAtt can be installed and used. In accordance to our customer’s wishes, the PSYC 100 TAs will not be present during the training. Our customers will be responsible for training the PSYC 100 TAs in using QAtt.

A user manual will also be provided for written instructions of installation and use of QAtt and QGen. A short cheat sheet for both softwares, which will be a short summary of what is included in the user manual, will also be provided for the users. This would be especially helpful for the PSYC 100 TAs, since they will be able to quickly refer to the cheat sheet during the lab if they do not recall how to deal with a use case that they do not frequently encounter (ie a student showing up at a different lab.)

Other Issues

Student privacy is a big concern for our clients, but after discussion it has been clarified that linking students’ NetIDs with their lab section and time is not a huge privacy concern, and our security and the limited access to the software will ensure that this is not an issue.

Our clients have no other issues at the time of this document.

Maintenance Resources

A user manual will be provided to our customers to help with installation or re-installation of the software. It will also include instructions on using our software, and a FAQ section to answer questions we anticipate that our customers may have. A cheat sheet for QAtt and QGen will also be provided to summarize the general use of the software and clarify rarer cases for QAtt that the TAs may not feel familiar with.

Documentation containing all the architecture and design of QAtt and QGen will also be provided to our customers. This will allow our customers to task new developers in modifying or extending QAtt and/or QGen with new features in the future. By providing the documentation, future developers will be able to quickly understand the softwares, and make appropriate changes. The source code will also be provided so that QAtt and QGen can be expanded upon, rather than having to recreate both pieces of software. This will also allow any maintenance work that is needed.