MIS330FinalReport
- 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