1. Final Report
Team: 6
Project Name: Study Swaps
Project Manager: Nicolas Gaetjen
Project Team Members: James Phillips
Varis Abdullin
Melissa Lovo
Bahar Monawer
Date: May 5, 2015
2. 1. Introduction:
a. System Overview:
As more and more people enter colleges and universities to obtain technical
degrees, the ability to exchange notes with former students and classmates is key to
successfully completing many courses. Study Swap would take advantage of this
opportunity to help students by allowing them to use this service at no charge if they help
contribute notes, study guides, and other helpful information for students around the
country. Small service fees for non-contributors and advertisements will fund the project
and keep it going along the way.
This project is not only feasible and economical to undertake, but would grow
with the ever-growing student population who rely on access to information to do well in
their higher education careers. It is highly recommended to establish Study Swaps now to
allow it to take full advantage of this growth. Interviewing professors, university
presidents and even students would provide the insight needed to see just how much
potential there is for Study Swaps.
b. Feasibility Assessment:
i. Economic Feasibility: Developing the system would cost approximately $50,000.
After an increase in popularity and use of the system, advertising and a small fee
would be introduced to cover the costs, and eventually make a profit.
ii. Operational Feasibility: The system will offer a platform for students to come
together and trade study guides and any materials that come along with any selected
course they are taking or have taken. This will attract students to help better their
performance in any course.
3. iii. Technical Feasibility: The in-house programmer, IT manager believes the project to
be feasible. Developing an application and online system to handle the uploading of
documents, sharing the documents, and creating accounts is within their abilities and
capacity.
iv. Scheduling Feasibility: The programming team are confident with the project as are
all project members and the proposed project will be completed by January 1st, 2016.
v. Legal and Contractual Feasibility: Any materials posted on the Study Swaps system
may violate copyright laws if they are from a copyrighted source. Professors’ notes
may or may not be published and thus susceptible to copyright infringement. Though
non-profit and educational use would exempt copyright infringement laws in most
circumstances, and we can give special access to professors for such circumstances.
vi. Political Feasibility: There are no known political issues with the proposed project.
c. Schedule:
This schedule details the major milestones of the Study Swaps project.
2. System Analysis:
a. Requirements Gathering:
Even having come up with an idea of what we thought our users would want, we
decided to go and retrieve data from prospective users first. Both students and professors
4. were selected for this surveying process, with slightly varying questions due to the
difference in uses between the two user types. Students were surveyed through social
media outlets and professors individually by group members, both at various times and
dates up to the presentation of this report. We were looking to either verify our project’s
need and desirability amongst students and faculty, or to come to the realization that our
prospective users would not care for such a service to exist.
Advertisers were not included in the surveying process, as generic advertising
systems would be linked to our system for that purpose. Examples of advertising
programs that we have in mind include adMod as a general, overarching system for web-
based use and all smartphone applications; alternatively, Google AdSense could be used
for our web-based advertisers, and we could also alternatively use Google Mobile Ads for
Android users’ applications. These advertising programs would all be using context-
sensitive advertisement algorithms to give our users relevant ads according to both our
program and the user’s individual other searches on a web browser; there is a risk of
inadvertently advertising for a competitor, but we feel this risk is minimal and acceptable.
Copies of each respective questionnaire are given as exhibits at the end of this report.
b. Requirements Structuring:
Context Diagram
6. Detailed above are the Context and Level-0 Data Flow Diagrams as well as an Entity-
Relationship Diagram for our system to show our requirements structuring.
c. Requirements Definition:
Functional Requirements:
1. File Uploading Service
1.1. The system will allow students to create accounts within our system
1.2. The system will allow users with accounts to upload files
1.3. The system will restrict users without accounts
2. File Viewing Service
2.1. The system will allow users to view self-uploaded and others’ uploaded files
2.2. The system will restrict the downloading of files
3. File Rating Service
3.1. The system will allow users to place a rating on other users’ files and accounts
3.2. The system will generate an average rating for each file and account
3.3. The system will allow users to view ratings for all files and accounts
3.4. The system will allow administrators to scan for spam and unhelpful ratings
Non-Functional Requirements:
1. Operational and Usability
1.1. The system should be accessible across all computer operating systems
1.2. The system should be accessible across all smartphones as an application
1.3. The system should be accessible across all smartphone web browsers
1.4. The system will not require additional downloads for web-based usage
2. Performance and Reliability
7. 2.1. The system should update itself on file uploads and rating votes within 5 seconds
2.2. The system’s servers should be able to handle a capacity of over a thousand
students with appropriate anticipated uploads
2.3. The servers should each be able to run the system individually if necessary
3. Security and Legality
3.1. The system should only allow users with registered accounts to upload, view, or
rate files and accounts on the system
3.2. The system should encrypt personal information using third-party software for
users’ safety
3.3. The system should only allow administrators to edit or delete information that is
not their own
3.4. The system will protect all privacy laws
3.5. The system should not allow anybody, administrators included, to see users’
private personal information
3.6. The system should never allow the transfer of any personal information to any
source outside of the system
3.7. The system will not allow third party advertisers to view any personal information
3.8. The system will not allow users to see another user’s private personal information
3. Design:
a. Database Design: We have come up with a couple of means of helping increase the
performance of our system. First off, for reliability of the system, we intend to install
several different servers to act as backups for one another, preferably at different
locations to help serve as backups in cases such as a power outage as well. This multi-
server setup will also allow us to create a cloud-esque means of security for our
information, as well as potentially increasing the speed by which the users may access
information, due to being able to access a closer server. To also help with speed for our
system, we do intend to keep the interface fairly basic in design, so as to create as few
loading problems as possible. Examples are to follow in the next section.
b. User Interface Design:
Detailed below is a dialogue diagram detailing the series of pages that our users will go
through for the entirety of our system. There may be omitted screens that are for
administration use only, and as such, were intentionally not included. The payment
8. screen will only be accessed if the user decides to be a paid user instead of or in addition
to a contributing user; if the user uploads a file upon account creation, no payment would
be necessary. All other dialogue paths should be self-explanatory.
Following the dialogue diagram are a few sample user screens.
Dialogue Diagram
Main Menu sample screen User Profile sample screen
9. File Search sample screen
c. Architecture Design: We expect to be using a thin client-server architecture for our
system. A client-based architecture clearly could not work, as we intend for this to be
available both on computers and handheld devices, the latter of which could not handle
the stress that a client-based server architecture would generate; additionally, there could
be increased security risks with all the information being hosted on the client’s side.
Server-based architectures are intended more explicitly for business use with high
security and control, and, while we do value a high amount of security, our users will
vary and could hardly be contained or classified as a singular business entity; this sort of
architecture also puts all the stress on our servers, which would create the unnecessary
need for higher processing power from our servers. In the middle of these extremes is the
client-server architecture: we can easily add new backup servers as we deem fit and there
10. is a very broad and well-used presentation logic. By then choosing to take a thin approach
with our architecture, we can then also guarantee convenience for both computer and
phone users (presentation logic handled by web browser, available for both computers
and phones) while also ensuring a single user being able to have access through multiple
devices (due to all data being stored on our servers and not locally by users).
4. Implementation
Once the Study Swaps system is developed, we plan to use Inspection testing techniques
which are when participants examine program code for predictable language-specific errors.
Study Swaps would be first deployed to George Mason students, then to college students in
general, and eventually made available to high school students. Since today almost every college
or university has some type of computer science or information technology department, it will be
cost-effective to allow students inspect our source code and recommend changes or corrections.
Our system code will therefore be open-source but any changes to the code will be monitored by
system administrators to ensure that changes are beneficial and does not hinder the service.
Students who are able to find errors or bugs will be rewarded with premium accounts to utilize
Study Swaps.
System analysts and developers will first test the system to ensure that it is ready to be
launched. Once this is finalized, the web-hosted and mobile applications will be released to
1,000 students who will be our alpha testers. These students will create accounts, input personal
information, upload files, view other student’s files, and rate accounts. The system administrators
will log user activity and evaluate how efficiently the client-server interaction is operating. Once
the alpha testing is completed, Study Swaps service will be available to 10,000 students as part
of our beta testing. The main purpose behind our beta testing stage is to evaluate how our servers
11. and database operates when being accessed by a large number of users. After the beta testing
phase, the system will be available for all users who wish to utilize it.
Study Swaps is a new web-hosted and mobile system that will not be replacing any
legacy systems, and therefore there will not be an installation phase; the system will be
developed and launched as the first of its kind. Also, the Study Swaps interface will be simple
and user-friendly like existing online databases such as Google Drive and EverNote which are
similar in functionality to our system (examples were included in the prior design section).
Therefore there is less of a need to establish a Training and Support Phase before launching our
system. Our system will be supported by George Mason University’s IT Department whom users
can call in to receive assistance.
5. Maintenance:
Study Swaps system administrators will follow active and preventive maintenance
methodologies where they will do a periodic and scheduled inspection of the system to ensure
that the service being provided is at its maximum. The preventive maintenance is the most
appropriate maintenance plan to this system because the number of users and files added to the
system will increase over time. Therefore, it may be necessary in the future to migrate from one
system to another depending on the level service usage.
12. Exhibits:
Exhibit 1. Student Questionnaire
Questions Answers
1) Do you think such a program would help in your studies? YES or
NO
2) Would you make use of such a program if it existed? YES or
NO
3a) If yes to question 1, would you prefer to pay a small service fee (ex. $5
one-time) or submit your own work to gain access to the materials?
3b) If no to question 2, end survey.
FEE or
SUBMIT
4a) If answer to question 3 was fee, how much do you think the service would
be worth, assuming a one-time fee?
4b) If answer to question 3 was submit work, how much effort would you put
into the work to refine it for others? (Does not include original effort of
assignment for class)
1-5, 6-10, 11-15, 16-20,
21+
in $ Dollars
1, 2, 3, 4,
5
No effort High effort
5) How much of a letter grade difference do you think this program would
make for your classes,on average?
0, > 0 & ≤ ½, > ½ & ≤ 1,
>1
in letter grades (1 = B→A)
6) How much would you trust the rating systemcontrolled by student’s votes? 1, 2, 3, 4,
5
Not at all
Completely
Exhibit 2. Professor and Faculty Questionnaire
Questions Answers
1) Do you think such a program would help your students study? YES or
NO
2) Would you allow your students to use this program? YES or
NO
3a) If yes to question 2, would you explicitly recommend this program to your
students?
3b) If no to question 2, end survey.
YES or
NO
4) How much of a letter grade difference do you think this program would
make for your students,on average,assuming no change to curriculum due to
inclusion of program?
0, > 0 & ≤ ½, > ½ & ≤ 1,
>1
in letter grades (1 = B→A)
5) Would you like special priority in responses in matters of improper YES or
13. uploads,such as copies of tests,test banks,or assignments that is against class
policy to share?
NO
6) How much would you trust our administration to keep improper uploads
(as listed in question 5) off of the service?
1, 2, 3, 4,
5
Not at all
Completely
7) Would you like our administration to get directly involved with the school
board in matters of honor code violations to help keep improper uploads out
of system?
YES or
NO
