SLADS
BSc Computer Science dissertation and department project, 2019.Due to the nature of the work, the code and any personal information will not be revealed.
Scroll down for video and to access the full document. Please note that the further implementation has not been tracked in this report. It is shown on the video.
Abstract
An ordered and efficient office solution is essential for any workforce. Staff management systems are a key factor for smooth running, especially for an organization having an extensive number of employees. With this in mind, the decision to renovate the current SLA Database Management System has been considered to make improvements to modernize the processes.
SLADS logo design
SLADS (Student Learning Assistant Database System) will be a web application, with a rich, user-friendly Graphical User Interface, developed using HTML and CSS, used on a daily basis to acquire details of SLAs and modules, in addition to assigning modules and events to the SLAs, and tracking down the application of an SLA. Initially developed for the SLA team, but further can be equipped for use of SLAs and lecturers as well.
This project, in general, aims to enhance efficiency and accuracy of information; all the makings of a good database system. The clients will be interviewed for prospective suggestions on the use of the database and improvements for the new system. The system will then be designed as per the user specifications, built and tested using various methods such as unit testing and user testing as well. This will be iteratively be enhanced in phases according to user feedback and feasibility.
This report provides a brief into the key ideas, principles, approaches and processes that will go into the
completion of this system.
Introduction
Working with the SLA database, as one of the team members, the database is not exactly user-friendly and there is so much that can be automated. Part of the job requires me to come up with innovative ideas on how to manage the database tasks and make the system easier to use.
This is the challenge. A proposed system can be so much more innovative and uncomplicated. A purpose-built database management system to help the team with their work, along with some project management features, is exactly what this application hopes to achieve.
Upon the completion of this project, a fully functional database application, with the possibility of project management tools as an extension, should be provided for use for the SLA team.
Background Literature
Database Systems
Manual filing systems are a rarity in today's digital age. Those times seem like centuries ago. While some people still
proceed to use such systems, it can make tasks like querying for a certain product or tallying reports, a tedious and time-consuming thing to do.
Database Management Systems (DBMS) are the digital equivalent to those filing systems. Use of
this system increases the accuracy and efficiency in businesses and lessens overall costs.
“The human being is a very poorly designed machine tool. The human being excels in coordination. He excels in
relating perception to action. He works best if the entire human being, muscles, senses, and mind, is engaged in the
work.” Peter Drucker
Looking At Systems
In exploring the design of my system, I decided to look at two examples of already existing on-campus systems that are
much like the application I am building. I have had the chance to work with both these systems and have also engaged in
feedback discussions with coworkers, in terms of usability and accessibility.
Design
Generally speaking, clients don’t specifically know what they want from a system. Clients would know better what they use
the system for and how the system is used, so asking potential users about what a system should do is ineffective. To be
successful in acquiring the right requirements from the user, the following acts help:
- Don’t assume that you understand what the user wants
- Involve the user in the agreement of the scope of the project
- Ensure that the requirements are realistic
- Avoid talking about technology until requirements are clear
- Prioritize the users’ needs
- If in doubt, always clarify
It is important to get the right requirements early in the design process so that any irrelevant development or
misunderstandings can be avoided. The work process will be much smoother, and the delivery will be a lot quicker.
Another key concern is the appropriateness of the interface and arrangements for the
features supported by the system. Fundamentally, the progression of interactive design includes four elementary
activities:
- Recognizing needs and creating requirements
- Developing designs that capture those requirements
- Constructing various designs so they can be connected and evaluated
- Assessing the product through the course.
A crucial entity that is frequently spoken about in requirements engineering is traceability, which is the ability to trace
things back to the process that produced them. The
assessment of the consequences of making necessary or unnecessary changes to this product can also be evaluated.
Security, Privacy and Legal Issues
“Digital warfare and worldwide cyberattack rates are on the rise, and protection on corporate networks is even more crucial.” Charlie Osborne
Vulnerability is the grade of weakness which is intrinsic in every network and device. Vulnerabilities in a system can often be found at any stage in a system’s life cycle, whether it is in the creation, the implementation or the updating phases.
One of the most common causes of database vulnerabilities is that there are not many checks to make sure the database is not doing something that it shouldn’t be, even though it has been tested for functionality. Data in databases can also be susceptible to hackers, who can capture this sort of traffic to exploit it. To evade such a drawback, the habit of SSL- or TLS-encrypted communication platforms should be used.
A more generalized way to fight these vulnerabilities would be to ensure that the machines, which the application runs on, have firewall permitted and the operating system is up to date, along with the latest security updates installed. If these precautions are practiced, then the danger of being hacked is slight and no data can be taken.
Methodology
You need a solid foundation before going out and looking for work. The first step is system analysis. Collecting information on how the existing system works and establishing its inputs, outputs and relevant details and then identifying and evaluating solutions to the existing problems, which will also be investigated. Interviews with the clients and questionnaires may also be part of the investigation of the problem.
Once the problems with the system have been identified, the user information and requirements will be established and formed. The information will be recorded by visual representations, using UML diagrams and tables.
When looking into the implementation of the system, which will be done throughout, a phased implementation mechanism will be used. This involves the introduction of the new system one part at a time which fits with the iterative process. On each iteration, the system will be evaluated, and the limitations of the system will be identified and worked on.
For over two months, I’ve worked with the SLA team and I’ve come to understand the workflow process, and that they need a reliable database system, to handle all sorts of data retrieval and report generation, whenever required. I have also worked with the system, to know a few of the faults and quirks the system faces. A few of the questions that were asked to the team were:
✓ What do you use the system for?
✓ Where and how do you get the data from?
✓ When do you mostly use the system?
✓ Would you require remote access to the system at any point? (Consideration for mobile app.)
✓ Do you have any trouble accessing the system?
✓ What are the problems you encounter with the system?
And then a few design questions were asked as well, to get a feel of what they would want the system to look like.
✓ How would like the page to look?
✓ Would you like to go ahead with the current colour scheme?
✓ Do you have any suggestions for the design?
The clients (users) were also interviewed and asked about what they would require out of a new system. All faults and complaints from the clients were taken into consideration for the design.
One of the few issues with the system that the users described was the user interface. Some of the buttons were faulty, the colour scheme of the interface made the text hard to read (see Figure 4) and some of the queries would return unpredictable or varying information.
SLA Database: User interface
“I can run a query once by clicking on a button, but search a different item and click on it again, and nothing happens.”
“If I enter [this name] in the database, and run a query for [this name], it should bring up every instance of the name, on clicking Find, but it doesn’t.”
SLA Old System: Database Schema, slightly improved
Another redundant thing is that there are files all over the place, from where information is to be retrieved and referred to at various points in the workflow or application procedure. With the system, this should solve the problem of looking into various files for various answers.
By having a web application, we eliminate the problem of requiring all the different Excel files (for nomination, for assigning modules, for recording profiles, for keeping track of observations, etc.).
“The database should be the only system to look at, for anything to do with SLAs, but there are multiple files to view for every little thing and this is very inefficient.” To quote one of the clients.
Requirements Specification
The SLA Database System (SLADS), within the SLA scheme, will be a database system that offers various SLA services to the SLA team, who deals with the training and handling of SLAs at Middlesex University. They, depending on the time of the year, require the system to perform basic tasks, like monitor the SLA modules and retrieve contact information, if any issues or otherwise.
My goal is to transform the current Microsoft Access database system from an application over a shared drive to a web-enabled database with an improved feature set that would be available for use by the team.
This system may, after completion, be open to a wider scope, accepting SLAs and lecturers to use the system as well, covering nominations of the SLAs for the lecturers and observation forms and evaluations on the SLA end. This would, of course, vary from user to user, allowing different rights to each category.
Requirement F1.1: Retrieval of information about SLAs
One of the top uses of the database system is to review and retrieve information about an SLA, whether it is to contact the SLA or just check to see if everything is complete and up-to-date. Once queried, all the data regarding the SLA should be displayed.
Requirement F1.2: Retrieval of module and lecturer information
To check if modules have enough SLAs, as per request, or to get information from the lecturer and contact them, regarding any concerns.
Requirement F1.3: Ability to check status of an SLA
Some SLAs are rejected in the initial stage of nomination. Some SLAs withdraw due to certain reasons over the course of the year. This would allow the team to know the SLAs current state or status.
Requirement F1.4: Ability to check class schedule of SLA
SLAs have specific schedules they must submit, to cross-check with the timesheets for payment. This is to ensure that the SLA is not doing more than the allotted time, or sometimes, the SLA is subject to spot checks, where the schedule can be checked to retrieve this.
Requirement F1.5: Ability to record events
SLAs have events that run throughout the year, like training, CPDs, the Student Success Festival, and ongoing projects, like the yearbook and event-planning. This needs to be recorded against the SLA’s profile to keep track of what the SLA participates in.
Requirement F1.6: Ability to add/check Mahara profile details
Mahara is an online platform used by the SLA team to record reflections. To complete reflective reports using Mahara at the end of each month is a requirement for payment for the SLAs. The reflections need to be kept track of and if any SLA fails to submit, action needs to be taken.
Read the full list of requirements below.
Workflow
The workflow models illustrate the current workflow of the clients, demonstrating various stages and activities that follow over the course of the year and the different aspects that need to be kept track of.
SLADS workflow model: main
Figure 7 shows the basic workflow that is followed by the team throughout the year. They go through various processes to select, plan and assign SLAs to their modules, along with dealing with lecturer requests and SLA issues.
SLADS workflow model: nomination of SLAs
For all other schools, lecturers are asked to nominate students to be SLAs for the coming year. The lecturers send back responses and the team organizes the requests.
SLADS workflow model: application process
After the nominations, the applications are sent to the students to fill out and send back. Once the students send in the applications, the applications are checked, and candidates are selected for the next process.
SLADS workflow model: assignment of modules
The next step is assigning all the successful students to the modules, by the module and lecturer request. And a lot of
planning and timetabling goes into account. A lot of rules, like no student should be assigned to more than two modules
without exception, a student should’ve confirmed their place at training to be assigned, are also considered.
SLADS workflow model: training
An email for the training registration and other formalities to be completed by the SLA. Everything is prepared for the training and finally, after the training, the SLA can officially start working.
SLADS workflow model: update
The work doesn’t stop after the training. If there’s an event, preparation is required. Even without an event, there is a weekly newsletter that should be distributed. At the end of every month, the Mahara* reflections have to be checked and timesheets have to be approved. And then all contact with the SLAs, whether in office or by email or phone, have to be dealt with and recorded.
*Mahara is an online platform used by the SLA team to record reflections. It is a free to use application and is being used by people all over the world. To complete reflective reports using Mahara, at the end of each month, is a requirement for payment for the SLAs.
Analysis and Design
Conceptual model for SLA system
Figure 13 shows how the objects will be created with respect to the structure of the database. Based on the requirements
and my own understanding of the system, along with a couple of my own ideas to increase efficiency, this model has been
derived.
Note: The above table and diagram may acquire changes due to further analysis and review.
Database
SLADS database schema
The database consists of nine tables. The main table is the SLA table. This table now holds only the relevant details about the SLA. The rest of the tables connect to the SLA table in one way or the other by foreign keys. The tables Observer and Event are not connected for now. This will require some re evaluation.
Some of the design principles I’ve picked up and tried to use in my own system:
➢ Effectiveness: Should meet all desired requirements, as per the user
➢ Efficiency: Qualitative results, in a feasible amount of time
➢ Safety: Password protected system, to ensure data is safe
➢ Utility: A non-complex system, beneficial to the team
➢ Learnability: Provide hovering feedback for buttons and text
➢ Memorability: Using common icons and symbols for buttons, to make it easier to associate
On taking ideas from the literature review, the database is password protected and would require a login. There would also be a session control that automatically logs out the person in case the client forgets to log out, or if the session is idle for too long.
Implementation
This section will include a few screenshots of the work done on the application. A point to note is that the login and administrative rights has not been included into the design yet. This will be worked into at a later time.
The design that I have incorporated into the application is minimalistic and follows closely to the SOBmonitor design used by the university. I picked a red, black and white colour scheme to match the previous system.
SLADS initial design: Adding SLA screen
Adding an SLA individually can be tedious and often, human input can tend to be inaccurate. During the initial review of the
applications, the team downloads all the applications onto a .csv file, which can be uploaded. Once uploaded, the data will
be processed and stored. The option for adding SLAs individually is also added as an option, to have both available to the
staff.
SLADS design: drop-downs and menus
The thought of how to implement security and protection was not given enough consideration. I thought I had an idea of
how to get about the login and user registration, but working in regards with the university ID number or the user IT ID
seemed easy to be easier said than done. It will be implemented at a later time, with a little knowledge on how exactly the
university handles this and the system behind it.
Testing
Note: UC = Use Case
UC01 Tests
UC01 T1: Test that, a user enters valid credentials for login.
UC01 T2: Test that, if a field is left blank, an alert notifies the user to fill all fields.
UC01 T3: Test that, if the user’s details do not match, an alert notifies the user of incorrect details.
UC02 Tests
UC02 T1: Test that, on entering the search page, all SLAs are displayed.
UC02 T2: Test that, if no search term was entered by the user, all SLAs are displayed.
UC02 T3: Test that, if a search was conducted, the user achieved expected results.
UC02 T4: Test that, if a search was conducted, and no results were found, an alert is displayed to the user.
UC03 Tests
UC03 T1: Test that, if a field is left blank, an alert notifies the user to fill all fields.
UC03 T2: Test that, a user can only register events that have a past date.
UC03 T3: Test that, the event appears when searching for an event.
UC04 T4: Test that, if the user adds the event to an SLA, the event appears in their profile.
26
UC04 Tests
UC04 T1: Test that, if a field is left blank, an alert notifies the user to fill all fields.
UC04 T2: Test that, after the user has updated the details, the change does not revert.
UC05 Tests
UC05 T1: Test that, if a user deletes an SLA, the SLA does not appear in the system.
Evaluation
The new and developed SLADS system
The clients have been updated with the progress of this project throughout this time and although the application hasn’t
been completed as of the deadline, it will carry on after the deadline to make sure of completion and implementation for the
clients.
The system will also be re-tested and re-evaluated, in phases as initially planned, at various stages to make sure
that it is safe to use.
