SDSHOWTO:Survey 2011 Responses: Difference between revisions
No edit summary |
No edit summary |
||
Line 108: | Line 108: | ||
Responses: '''61''' | Responses: '''61''' | ||
The SDS developers must deal with several [http://en.wikipedia.org/wiki/Non-functional_requirement "non-functional" requirements] when programming the SDS. | The SDS developers must deal with several [http://en.wikipedia.org/wiki/Non-functional_requirement "non-functional" requirements] when programming the SDS. Unlike adding features or fixing bugs, non-functional requirements involve qualities of the system, like how fast it should run, how many hours a day it should be available, how secure it should be, etc. Security is one of the most difficult to get right, as many large companies find out every year. Now that we are giving parents access to some of the information stored in SDS, we must be even more careful about information disclosure. | ||
The SDS is designed with security in mind. Each different screen in the SDS is secured separately, meaning that we can list exactly who has access to each page. Additionally, we enforce that users must be logged in to access most pages of the SDS, and ensure that non-authenticated pages are limited in the information displayed. Critical errors are configured to not display any "debugging" information to the user (although we receive the debugging information by email) as per best practices. We are scanned quarterly by a PCI-DSS certification company to verify that we do not have any obvious security flaws in our server architecture. We also do internal scans with a vulnerability checking tool called Nessus. User passwords must be changed every 90 days, and must satisfy complexity requirements. Any change to SDS data is logged and we can (and have) go back and figure out who changed a value in the system. Logins, impersonations, unimpersonations, and certain functions are also logged. Impersonation (which carries one of the greatest risks for information disclosure) does not grant any extra permissions over what the original user had. | |||
'''The SDS is available whatever time of day or night I'm trying to use it''' | |||
Strongly Agree (5): '''22''' | |||
Agree (4): '''30''' | |||
Neutral (3): '''6''' | |||
Disagree (2): '''3''' | |||
Strongly Disagree (1): '''0''' | |||
Average: '''4.16''' | |||
Responses: '''61''' | |||
Other than our maintenance period (Fridays from 4:00 pm until 5:00 pm), we try to ensure that all sections of the SDS are available at all times. We have set up several monitoring systems to alert us whenever anything goes wrong (services go down, errors are encountered, etc.) to get things up and running again as soon as possible if something does break. | |||
Revision as of 12:47, 16 May 2011
Reference Material
- SDS: http://sds.smus.ca
- SDS Beta: http://sds-beta.smus.ca
- Submitting a request: [1]
- Viewing the status of your requests: http://secure.smus.ca/rt
- SDS Roadmap: https://secure.smus.bc.ca/wiki/index.php/SDSHOWTO:Roadmap
- SDS Changelog: https://secure.smus.bc.ca/wiki/index.php/SDSHOWTO:Changelog
Multiple Choice Questions
The SDS is easy to use
Strongly Agree (5): 9 Agree (4): 29 Neutral (3): 7 Disagree (2): 13 Strongly Disagree (1): 3 Average: 3.46 Responses: 61
We're doing our best to improve usability. As we continue to add functionality to the SDS, it gets more difficult to present all of the options available. Some of the pages in SDS are quite old and do not follow our more recent usability guidelines, but we're improving those as we find time. Please let us know if you have any specific suggestions on how to make the page you use most easier to use.
Finding information using the SDS is fast
Strongly Agree (5): 9 Agree (4): 21 Neutral (3): 15 Disagree (2): 14 Strongly Disagree (1): 2 Average: 3.34 Responses: 61
Similar question to the last one, and a similar response. Again, any specific suggestions please let us know.
When I click on something, the SDS shows the next screen quickly
Strongly Agree (5): 14 Agree (4): 34 Neutral (3): 9 Disagree (2): 4 Strongly Disagree (1): 0 Average: 3.95 Responses: 61
The responsiveness of the SDS depends on several factors, including how many people are trying to use the SDS at the same time as you, how complex the page you're trying to load is, how fast your local computer is, and what web browser you're using.
Some things you can control: a laptop will generally load the SDS slower than a desktop. Internet Explorer version 8 and below tend to load the SDS slower than other web browsers, so it's better to use Firefox, Safari, Google Chrome, etc. when using the SDS. Over the summer, the MIS department will be pushing out Internet Explorer version 9 to the Windows 7 desktops and notebooks, which will make things load faster if you still prefer Internet Explorer.
We try to keep the SDS response time below 1 second, so after you click on something, it should always take less than 1 second to come back with the next screen. Some admissions statistics pages take longer than 1 second, but they're loaded infrequently and also process ~5000 students at once. Most pages are well below this threshold (for example, the front page of SDS takes ~ 0.15 seconds). If you try the page under SDS Beta and scroll down to the very bottom of the page, it tells you how long the page took to load (in seconds) like this: "Page generation time: 0.189" Please let us know if you find pages that consistently take a very long time to load and we'll look into speeding them up.
The SDS helps me to do my job
Strongly Agree (5): 15 Agree (4): 28 Neutral (3): 15 Disagree (2): 1 Strongly Disagree (1): 2 Average: 3.87 Responses: 61
This is the most important question for us, as the reason for the SDS to exist is that it makes your job easier. If we're not meeting your needs, make sure to send in a request to get the SDS changed so it works for you.
The SDS is essential to do my job
Strongly Agree (5): 17 Agree (4): 25 Neutral (3): 13 Disagree (2): 4 Strongly Disagree (1): 2 Average: 3.84 Responses: 61
We try to make the SDS fast and easy to use, especially for the people who must use the SDS in order to do their jobs. In particular, there are some admin staff who are the only people to use their section of the SDS, and yet we must still make their module fast and easy to use so that they can do their job. This specialization will continue to increase as we integrate more functionality into the SDS.
I only use the SDS because I have to
Strongly Agree (5): 6 Agree (4): 17 Neutral (3): 15 Disagree (2): 17 Strongly Disagree (1): 6 Average: 3.00 Responses: 61
This one is particularly interesting, as the people who disagree are balanced with the people who agree.
I frequently experience errors when using the SDS
Strongly Agree (5): 2 Agree (4): 6 Neutral (3): 13 Disagree (2): 32 Strongly Disagree (1): 8 Average: 2.38 Responses: 61
We're glad most people disagree with this one! Any time you receive a fatal error from the SDS, we get emailed, which is a strong incentive for us to correct the errors. There are several other types of errors that we do not currently receive emails for, though, and we'll be working on developing a way to receive these in the future, too.
Information I put into the SDS is secure
Strongly Agree (5): 5 Agree (4): 29 Neutral (3): 25 Disagree (2): 1 Strongly Disagree (1): 1 Average: 3.59 Responses: 61
The SDS developers must deal with several "non-functional" requirements when programming the SDS. Unlike adding features or fixing bugs, non-functional requirements involve qualities of the system, like how fast it should run, how many hours a day it should be available, how secure it should be, etc. Security is one of the most difficult to get right, as many large companies find out every year. Now that we are giving parents access to some of the information stored in SDS, we must be even more careful about information disclosure.
The SDS is designed with security in mind. Each different screen in the SDS is secured separately, meaning that we can list exactly who has access to each page. Additionally, we enforce that users must be logged in to access most pages of the SDS, and ensure that non-authenticated pages are limited in the information displayed. Critical errors are configured to not display any "debugging" information to the user (although we receive the debugging information by email) as per best practices. We are scanned quarterly by a PCI-DSS certification company to verify that we do not have any obvious security flaws in our server architecture. We also do internal scans with a vulnerability checking tool called Nessus. User passwords must be changed every 90 days, and must satisfy complexity requirements. Any change to SDS data is logged and we can (and have) go back and figure out who changed a value in the system. Logins, impersonations, unimpersonations, and certain functions are also logged. Impersonation (which carries one of the greatest risks for information disclosure) does not grant any extra permissions over what the original user had.
The SDS is available whatever time of day or night I'm trying to use it
Strongly Agree (5): 22 Agree (4): 30 Neutral (3): 6 Disagree (2): 3 Strongly Disagree (1): 0 Average: 4.16 Responses: 61
Other than our maintenance period (Fridays from 4:00 pm until 5:00 pm), we try to ensure that all sections of the SDS are available at all times. We have set up several monitoring systems to alert us whenever anything goes wrong (services go down, errors are encountered, etc.) to get things up and running again as soon as possible if something does break.