Dr Muna Al-Jepoori, I would like to acknowledge you for your teaching and guidance over the past three years, particularly during this project. Gerald Stock, for your breakfast meetings and wealth of database knowledge. Henrietta Thӧnnersten, for your continued support and coffee breaks and grammar checks. And finally to my housemates for the daily encouragement and takeaways during the late night work sessions.
Contents Abstract (138) Acknowledgements (63) Contents 1.0| Introduction Chapter (531) 2.0| Feasibility Study (725) 3.0| Main Chapters 3.1| Development Methodology (248) 3.2| Modelling Technologies (195) 3.3| Languages and technology (240) 3.4| Table and database design (279) 3.5| User types (126) 4.0| Legal Considerations Chapter (231) 5.0| Ethical Considerations Chapter 6.0| Conclusion Chapter (650/) 7.0| References 8.0| Bibliography 9.0| Appendix Appendix A: Appendix B: Appendix C: Changes to the project initiation Document Appendix D: Current Environment Investigation Report Appendix E: Requirement Specifications 1433 Appendix F: Design Report178 Appendix G: Implementation Appendix H: Testing Appendix I: User Guide Appendix J: Project Management288 Appendix K: Meetings with Supervisor K1: Module leader meetings K.2: Mentor with Personal Supervisor Appendix L: Agile Development: Timebox 1 Appendix M: Agile Development Timebox 2 Appendix N: Agile Development Timebox 3
This web-based system has been created to fill the gap for students who require an income throughout their studies to support themselves yet, aren’t able to fit in a part-time job. With the rising tuition fees and the cost of living (Statista, 2018), (Ullman, 2018), the average student has to depend upon their student loans and relations for financial help (Insurance, 2018), (The complete university guide, 2018). Yet the student loans have been disregarded as ‘fair’ way of supporting students throughout their studies (Jenkins, 2018), so this web-based system has been designed and created to enable students to be selective as to what they do for ‘work’ and when they do it as there is no contractual binding. The idea came from both personal experience as to how a demanding part-time job can affect the quality of studies undertaken at the same time and from peers who have either stopped studying due to their financial situation or have had to retake academic years of their studies as they prioritized paid work over academic work. As a result, both the students and universities are affected by the overall percentages of retakes or average pass marks (Universities UK, 2018). The software development lifecycle used for this project will be the conventional waterfall lifecycle (Valacich and George, 2013). The decision to use the conventional waterfall lifecycle is due to the clear concise phases within the lifecycle such as the pathway made up of the idea, initial study, feasibility study, systems analysis of the current environment, systems analysis of the requirement specification, systems design, Programming, testing, implementation, post-implementation review, maintenance and obsolescence. These steps show a clear pathway for the project progression. The use of the conventional modelling techniques which go alongside the waterfall lifecycle demonstrates the system of the project best due to use of a large backend database. The modelling techniques such as data flow diagrams and entity relationship diagrams will enable the visual representation of digital information and how the data travels through the systems as well as how the data is used by different entities in the system. The use of these models will also ensure the progression and the structure of the project is viable to the criteria of a successful web-based system and ensuring that all the types of feasibility are covered in all the six key aspects including, technical, economic, operational, executive, and scheduling. This report will contain all the design components and options chosen during the creation of the web-based system, the report will also include how these options arose and were carried out. Legal and ethical considerations which may affect the project will also be included in this report alongside a log of the meeting minutes with the project mentor as evidence of the progression of the project. The aims of this project are to learn how to, and, to produce a successful web-based system, which meets the users’ requirements and is fully functional to have a future as a published system to the public. Another aim of this project is to implement the conventional waterfall development lifecycle fully and successfully.
Executive summary Students on demand (SoD) is a student made and a student-run web-based system to allow flexible employment of students by public individuals. Created with both student and the public in mind. Currently, there is no other platform which allows public individuals to hire students on a temporary (one time/ non-permanent) basis. The idea is to allow the students of universities to earn a wage on a (choice platform/ personal decision/ one-off allowance). Eventually, the plan for SoD is to grow large enough to be rolled out into universities across the country to allow all university students the option of earning money they require, when they require, filling the gap between student finances and financial outgoings without the time-consuming pressures of a part-time job. This document outlines this system and the process surrounding it. Description of products and services SoD has a target market of university students and public individuals who can both benefit for a temporary employment contract, by the public users requiring a specific service from a student who can offer the skills and the time to complete a one-off job. The web-based system will allow the public users to search through the student users and their skills and request their time in return for an agreed fee for the student. The web-based system will keep a record of the students and their skills and their ratings made by the public users, enable emails requests to students to notify them of a job possibility and to allow the public users to have an opportunity to comment on the student users based upon the job done. Technology Feasibility / Organisation and staffing For SoD there is no system, employees or environment in place as this is a brand new web-based system. The lack of these key factors is both a hindrance and an advantage as it allows a clear platform for a new innovative web-based system to be created and maintained. The web-based system will be created on a standalone laptop with backups on the Canterbury Christ Church Networks and a secure off-campus hard drive. The new SoD web-based system is to be created to be run by one systems administration, if the web-based system becomes more popular it enables the opportunity for the system to be profitable which may present another opportunity to employ a few members of staff to run and maintain the web-based system with additional hardware to run the web-based system on a larger scale. Economic feasibility The creation of the project will cost nothing as the web server is open sources, the hardware is pre-purchased for personal use, not just for the project. ensures minimal hardware costs during the creation of the web-based system. The only foreseeable costs of the project will incur if the project grows and requires the need for new hardware and software to deal with more traffic on the web-based system and requires more employees to run the newly purchased hardware and software. Marketplace analysis Currently, there are no known businesses that offer the same niche employment opportunities and hiring opportunities for both students and public individuals. This enables the SoD web-based system to be completely unique and to have the entire student and non-student population to be the target audience of the SoD web-based system. This new system needs to ensure that it will enable the customer satisfaction levels are high to ensure constant customer satisfaction which will act as good publicity for the new SoD web-based system, this will potentially allow for an increase in company revenue. This is detailed later in this document. Schedule The new web-based system is expected to take eight months from project start to completion of the systems analysis and implementation phases. Below is a timeline of the major event completion dates, (a more detailed breakdown of the timeline can be found within the project Gantt chart in Appendix J of this document): October 2017: Initiate Project November 2017: Project kick-off meeting December 2017: Design phase completion January 2018: Programming start February 2018: Complete online site design March 2018: Complete testing of the web-based system April 2018: Complete beta testing trials of the system May 2018: Go live with site launch and submission
The traditional waterfall development lifecycle methodology used for a large percentage of this project as it provided a clear and logical progression for the project to take. The decision to use the traditional waterfall methodology more than to use the updated agile methodology included many factors, such as the predictability of the end deliverables. With the waterfall methodology all planning, designs and risk assessments are completed at the beginning phase of the project whereas with agile the project is constantly evolving and being adjusted throughout the entire process. The iterative approach of an agile development methodology did not suit every stage of this project as it required several repetitive cycles of the same steps to perfect them. However, within each stage of the waterfall methodology, there were iterations of each step, thus combining both waterfall and agile methodologies. This injection of agile occurred when meetings with the project mentor were conducted and alterations and improvements were discussed. Despite the occasional use of the agile development methodology, the waterfall development methodology is the backbone to the process of the project as it provided a clear structure of start and end points for each stage of the process. The use of the traditional waterfall development lifecycle for this project has also enabled the project planning to have a clear and distinctive layout to match that of the phases of the lifecycle, which can be seen in Appendix J: Project management of this document with the comparison of figures five and six.
To show the design and layout of the system and the database, Entity Relationship Diagrams (ERD’s), Data Flow Diagrams (DFD’s) have been used. These diagrams show the relationships between the different entities which make up the tables within the database (ERD) and also show the progression of data within the online web system when in use(DFD). The ERD’s created for this project are designed to help provide a structure of the database during the systems analysis and design stages of the project. During the programming phase of the project, the ERD’s are used to ensure that the relationship and data types used for each entity are correct and have been implemented correctly. Data flow diagrams have been used within this project to provide a graphic overview of the processes and movement involved with data moving through the system. Showing the physical users and implementation of the data and the logical movement of the data to perform the required functions within the project. These diagrams tie in with the systems design phase of the waterfall development methodology prior to the programming of the project and can be seen in Appendix E: Requirement Specification of this document.
Using a web-hosted database for MySQL is a standard default for web-based systems. MySQL was chosen for this project not only due to its resilience to handle large sets of data but also because it is able to store data efficiently which is a key function of a web-based system. MySQL is also very compatible with the PHP language and Apache web server software. MySQL is a free open source which enables the costs of the project to be kept to a minimum. MySQL security is frequently updated to ensure the database is always secure. Another reason that MySQL has been used for this project is due to the many different platforms on which it can be used so is able to maintained and integrated with many different devices even if they’re running different operating systems. Using the university hosted student sever had enabled the database and web-based system to be accessed anywhere in the world and to be free of charge. To ensure the tables within the database not only receive but send out data quickly the tables have been normalised to hold fewer attributes. The only downside to this table arrangement is when data from several tables need to be displayed together. This function requires a join which can be an expensive and time-consuming function to perform. Yet within the web-based system, few joins of tables are required therefore to maximise the efficiency normalisation was performed and de-normalisation was not performed. The entity relationship diagrams in Appendix E shows the tables in the database in their normalised state and provides an entity description of the tables to explain what each of the table entities is.
The project will allow two different types of users to log in and use the web-based system; Canterbury Christ Church students and members of the public are distinguished by their login email addresses. This allows the student logins to update, create and delete their profiles and provide them with notifications when they have been selected for a job. Public user logins allow them to search for specific skills which they require which will provide the user with a list of students who meet their requirements. Public users will also be allowed to select students who they wish to employ, which will then allow the user to email the student to arrange a time and date and any other details which are required for the users’ needs.
- A suitable graphical user interface must be implemented.
The graphical user interface needs to be easy to use yet professional in design to attract both students and users to use the web-based system.
- The system needs to be efficient with loading times to ensure the users get the best possible impression from the first few pages they use.
- The web-based system should have a sufficient speed at which it can process the upload and send the notifications and messages between users.
- The web-based system should have the reliability required to ensure that the effective running of the new web-based system and that there are minimal to no glitches when the system is implemented to ensure a smoother roll out of the system and potential expansion of the system if it is ever required due to popularity.
- The scalability of the system should be easily implemented to accommodate for both an increase and decrease in users.
- The maintenance of the system needs to be cost-effective when looking to host it long term.
- The maintenance of the system needs to be cost-effective when looking to host it long term.
- The system will not be built to perform interoperability with other software or systems, as this would increase the vulnerability of the system.
The functional requirements for this web-based system are outlined using the MoSCoW methodology of prioritization: Must have:
- Documentation of the reports made by the web-based system is required to be collected, not only for the user’s own personal records but for the owner of the system to ensure that there are records of all the data collected from the system and that they are stored correctly and safely.
- The ability to send and receive notifications from users and the confirmation of acquiring temporary employment.
To act as a communication link between the two different types of users (students and users) as these notifications will notify students of new job requests from users seeking their skills. Could have:
- Text alerts for users wishing to be notified and updated when not on a search engine.
- A mobile app version of the web-based system to enable all devices to provide the best version of the web-based system.
- External, paid for advertisement. This will cause the web-based system to become clogged and appear unprofessional which by extension will not attract users of either students or users.
|Test Number||Test Item||Test Data||Expected Outcome||Actual Outcome|
|Issue Test Number||What is the issue||Why is this an issue||What can be done||Why did it fail?|
|Meeting Number||Meeting Attendees||Meeting Date||Meeting Time||Meeting Location||Meeting Purpose||Meeting Description||Meeting Actions|
|1||Gerald Stock, Sophie Lavis||26.09.2017||12.00||Lf16||IP40 introduction, schedule and project discussion||A large meeting with all the potential IP40 students and Gerald Stock. We ran through the outline of an IP40 and what is expected from all of the projects and to ensure that we make each of our projects large enough to ensure it meets the criteria to be large enough to be IP40. Ensuring that students need to keep on top of all their university work as an IP40 is a third of their degree. Hammering in the point that this project is writing of a system and not a data entry clerk job. Notified of PID due date to find out mentor selections.||Work on PID for submission by 16:00 October 6th 2017.|
|2||Gerald Stock, Sophie Lavis, Henrietta Thӧnnersten, David Thornton||31.10.2017||12:00||Rf04||IP40 current environment investigations, requirement specifications and overall presentation||Reviewing previous submissions from previous years, comparing the good and the bad points of each report for the projects. Showing how to write academically and with deep analysis to enable the reader of each report to understand fully. Ensure that all possible legal issues are avoided, an ideal example is to ensure there is no personal data included in any part of the project especially the test data.||Redo all test data to ensure there is no personal data in any of the tables.|
|3||Gerald Stock, Sophie Lavis, Henrietta Thӧnnersten||05.12.17||12:00||Boardroom||Defining the difference between the analysis and design parts of the IP40 alongside database discussion||Database design and layout and discussion of what database language to use for the writing. This resulted in the work I had done for my database to be changed as I had written it all in SQL to be written with the Oracle database management system, which was not the best idea to be used with my web-based system. Therefore, the method and thought process behind how and why I had chosen to write my database in SQL was discussed and flaws were found and has shown different pathways that I could take to ensure the web-based system has the best possible backend database to secure the implementation of it.||Rewrite the database with test data, redo the entity relation diagram and start to implement the rewritten creation of the database on the web-hosted database server.|
|4||Gerald Stock, Sophie Lavis, Henrietta Thӧnnersten, David Thornton||08.03.18||12:00||ES01||Catch up and check in with the different IP40 approaches||Ensuring that the report written so far for the IP40 is on track, to ensure that the project will be finished in time. The discussion of the size and ability to submit the project and report electronically rather than a hard copy||Ensure many backup copies are kept and that the full project and report is submitted before the deadline day.|
|5||Gerald Stock, Sophie Lavis, Henrietta Thӧnnersten||19.04.2018||12:00||Rg02||Final group meeting to confirm submission details||Ensuring all details regarding submissions are known by all students.|
|1||Dr Muna Al-Jepoori, Sophie Lavis||26.10.2017||15:00||Ig09||First meeting with mentor||Discussed the PID submitted for the mentor selection, and the steps needed to be taken to move forward and start the project. The layout and method of how both types of users (student and public) will move through the web-based system were discussed to enable a clear a concise thought process as to how the data will move through the system from the point of view of the users.||Re-draw the web-based system layout diagrams, re-draw the entity diagrams(ERD’s), the data flow diagrams and the class diagram.|
|2||Dr Muna Al-Jepoori, Sophie Lavis||20.11.2017||14:15||Ig09||Second Mentor Meeting||Discussion of ERD and the entities included in each table and how they will be stored in the database and how the tables with interact with each other. Discussion of languages and techniques used for specific parts of the web-based system.||Rethink and redo the diagrams and start to rehash the code required to create the web-based system.|
|3||Dr Muna Al-Jepoori, Sophie Lavis||04.12.2017||14:15||Ig09||Third mentor Meeting||Discussion of the database storage of images of blobs versus a varchar binary versus the storage of images physically and storing in the database just the reference to the image on file. Alongside the uses of views to update the databases. Deadline for initial paragraphs of the report due soon||Keep researching the data type of images. Continue writing the report and ensure it is submitted on time.|
|4||Dr Muna Al-Jepoori, Sophie Lavis||02.02.2018||14:15||Ig09||Fourth mentor meeting||Went through the setup of the open source SFTP server Cyber Duck which is being used to host the web-based system, and the setup of the online database, stweb, hosted by the university. Found that the open source server does not allow public viewing of the site||Fix the public viewing of the open source server. Fix the tables in the database which is having issues with the relationship connection of primary and foreign keys|
|5||Dr Muna Al-Jepoori, Sophie Lavis||16.02.2018||11:00||Ig09||Fifth mentor meeting||Review of the fixes made since the last meeting||Continuing to work on the report and constantly update the diagrams and the layouts to ensure the maximised efficiency of both the organisation of code and layout.|
|6||Dr Muna Al-Jepoori, Sophie Lavis||09.03.2018||11:30||Ig09||Sixth mentor meeting||Review of work done on the report so far. How to layout the document to ensure the report meets all the requirements. The differentiation of the types of functional requirements included in the report needs to be specifically identified. The report needs citations throughout from trusted articles and reports||Edit all of the report written so far ready for the next meeting and so the coding can be produced.|
|7||Dr Muna Al-Jepoori, Sophie Lavis||23.03.2018||11:30||Ig09||Seventh mentor meeting||Reviewed the written report so far, final edits are to be made.||Need to finalise code. Get a large portion of the work done in time for an all-day meeting in the Easter Holidays to iron out any small issues|
|8||Dr Muna Al-Jepoori, Sophie Lavis||27.04.2018||10:45||Ig09||Eighth mentor meeting||Reviewed where the project is at. Confirmed changes and improvements to be made to the report before final submission.||Continue to improve report and code so that everything is up to standard for a final run through before submission|