This report delivers justifications and evaluations for the web-based system Students On Demand, providing a solution to a problem many students experience; balancing studies and finances. Using a collection of web-based languages such as PHP, MySQL, and HTML within the guideline of the software development methodology the Waterfall lifecycle, a web-based system was created as a solution to the problem and by providing the service of connecting students and public individuals who need to earn money to fund their degree and those who need a job done which they do not have the skill set to do themselves. This report also provides analysis of the work done to create the web-based system and limitations which occurred and provides reasons and explanations as to why the limitations occurred, how the limitation can be rectified and avoided in future projects.

Acknowledgements (63)

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

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

1.0| Introduction Chapter (531)

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.

2.0| Feasibility Study (725)

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

3.0| Main Chapters

3.1| Development Methodology (248)

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.

3.2| Modelling Technologies (195)

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.

3.3| Languages and technology (240)

The programming languages used within this project are Hypertext Pre-processor (PHP), JavaScript, Hypertext Mark-up Language (HTML), Cascading Style Sheets (CSS), and MySQL (an open source relational database management system based on Structured Query Language). These languages were chosen to create this project as they are the conventional languages used when creating an online web-based system with a backend database. Alongside these languages, the programs used to write the code are notepad, Notepad++ and Adminer to access the MySQL database. Cyber duck which is an open source (freely available) client for SFTP (SSH (Secure socket shell) File transfer protocol). The program, Cyber duck, was chosen for this project as it is compatible with windows and enables both notepad and Notepad++ file uploads. This ability of file uploads and downloads makes the system easier to navigate and use for testing. PHP is an open source scripting language suited for web development, used alongside the object-orientated JavaScript were used to create the functions and interactive abilities of the project. HTML and CSS are used in this project to aid in the design and layout, enabling a standardised colouring and formatting. Although HTML and CSS can be used independently they have been used together in this project as HTML can be and has been used to create actual content of the page whereas CSS is just for the design of the pages, which allows the differentiation of styles and content when writing the project.

3.4| Table and database design (279)

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.

3.5| User types (126)

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.

4.0| Legal Considerations Chapter (231) The General Data Protection Regulation(GDPR) which is enacted on 25/05/2018. The Computer Misuse Act was introduced in 1990 (1). It states that the unauthorised modification of computer material to impair the operation of any computer is illegal. AND the unauthorised access to computer material. To ensure that my project does not allow this to happen in any way the project needs to be safe from any code injections. For example, the login screens must be programmed to stop any SQL injections which could lead to data leaks. This shall be done by using mysqli_real_escape_string to ensure that the login process cannot be overridden to allow access to unauthorised users. The use of this function also ensures that the project adheres to the new General Data Protection Regulation (GDPR) which is enacted on the 25/05/2018, which states that users, also known as Data Subjects, are entitled to privacy by design (2). Users must be made aware and asked their permission to continue through the project once they have agreed that any contact or payment agreements made after the initial contact made via the project are their responsibility and that the project cannot provide any further security to either student or user. This has been created to display to users when they register to use the system, this ensures that the system and project as a whole are safe from any consumer misuse.

5.0| Ethical Considerations Chapter (202) The key ethical issues are ensuring that users do not abuse the system. The personal details such as the student users name and postcodes are only available to public users who have registered for the system. This does prevent their details being freely available to the wider internet, yet does not ensure that the registered users will not abuse their registered status. The personal data of students and public users are held securely in a database which is explained in 4.0 Legal considerations; yet to reinforce the online etiquette which should be performed when using the system, a privacy policy and website announcement has been made when a new user registers to ensure that the users are aware of what is expected of them. This announcement is designed to not only make users aware but to protect the system being subjected to scrutiny if users were to abuse their power. To ensure that no other ethical considerations affect this project, the university issues ethical checklist has been completed in accordance with university guidelines and can be viewed below.  Figure 1- Canterbury Christ Church Ethics Matrix

6.0| Conclusion Chapter (650/) To be inserted

7.0| References Bottomley, P. and Doyle, J. (2006). The interactive effects of colors and products on perceptions of brand logo appropriateness. Marketing Theory, 6(1), pp.63-83. Elliot, A. (2015). Colour and psychological functioning: a review of theoretical and empirical work. Frontiers in Psychology, 6, pp.1-8. EU GDPR Portal. (2018). EU GDPR Information Portal. [online] Available at: https://www.eugdpr.org/eugdpr.org.html [Accessed 6 Nov. 2017]. (2) Legislation.gov.uk. (2018). Computer Misuse Act 1990. [online] Available at: https://www.legislation.gov.uk/ukpga/1990/18/contents/enacted [Accessed 2 Mar. 2018]. (1) Pixel77.com. (2018). Color Psychology in Web Design – Big Websites Case Studies – PIXEL77. [online] Available at: https://pixel77.com/color-psychology-web-design-color-schemes-big-websites/ [Accessed 2 Mar. 2018]. Valacich, J. and George, J. (2013). Modern systems analysis and design. 7th ed. Pearson. Valdez, P. and Mehrabian, A. (1994). Effects of color on emotions. Journal of Experimental Psychology: General, 123(4), pp.394-409.

8.0| Bibliography Statista. (2018). UK inflation rate forecast 2017-18 | Statista. [online] Statista. Available at: https://www.statista.com/statistics/306720/inflation-rate-forecast-consumer-price-index-cpi-united-kingdom-uk/ [Accessed 18 Feb. 2018]. Insurance, E. (2018). 77% of students now work to fund studies. [online] Endsleigh. Available at: https://www.endsleigh.co.uk/press-releases/10-august-2015/ [Accessed 18 Feb. 2018]. Jenkins, S. (2018). Student finance is broken. A graduate tax is the only solution | Simon Jenkins. [online] the Guardian. Available at: https://www.theguardian.com/commentisfree/2018/feb/19/student-finance-broken-graduate-tax-theresa-may-tuition-fees [Accessed 19 Feb. 2018]. Thecompleteuniversityguide.co.uk. (2018). Student Jobs-Working Part-Time. [online] Available at: https://www.thecompleteuniversityguide.co.uk/preparing-to-go/student-jobs-working-part-time/ [Accessed 18 Feb. 2018]. Ullman, M. (2018). How Inflation Affects Your Cost of Living. [online] Investopedia. Available at: https://www.investopedia.com/articles/personal-finance/081514/how-inflation-affects-your-cost-living.asp [Accessed 18 Feb. 2018]. Universities UK (2018). Higher Education in Facts and Figures. [online] Universities UK. Available at: http://www.universitiesuk.ac.uk/facts-and-stats/data-and-analysis/Documents/higher-education-in-facts-and-figures-2017.pd [Accessed 18 Feb. 2018].

9.0| Appendix Appendix A: Glossary To be inserted before submission

Appendix B: Marking Scheme The default marking scheme for the project should be used and as is follows:  Appendix C: Changes to the project initiation Document Deliberately Left Blank. Appendix D: Current Environment Investigation Report Not Applicable. Appendix E: Requirement Specifications 1433  Figure 2- Level 0 Data Flow Diagram, also known as a context diagram The level 0 data flow diagram in figure two shows the system as a basic overview of the relationship to the external entities involved with the system such as the different types of users. The low-level data flow diagram only covers the main transactions of data between the external entities and the web-based system. Figure 3 depicts a level 1 data flow diagram which shows the full system overview in more detail, including more sub processes than in the level 0 data flow diagram. The level 1 data flow diagram depicts data stores and relationships which are used by the significant processes. Due to the deeper complexity of the relationships and functions shown each function is labelled show keep the diagram organised and to show the order in which the functions are performed within the web-based system.  Figure 3 – Level 1 Data Flow diagram depicting the movement of data throughout the web-based system  Figure 4- Entity Relationship diagram showing the relationships between the different entities of the web-based systems’ database Figure 5- Detailed ERD  Figure 6 – Updated and detailed Entity Relationship Diagram The database for the web-based system includes several different tables, these tables act as the entities within the entity relationship diagram shown in figure 2. Each of these entities has their own set of attributes to enable them to hold the relevant data about each entity and by extension the system. The User table includes a unique identification number for each user of the system to ensure they are easily identifiable and cannot be mistaken for another user. The user table also includes contact information for the users to ensure the interaction between the students and users via the web-based system is seamless. The user table also holds information for the ratings of students left by the user (if they have rated any students) to ensure that the posts which are available for public viewing can be traced back to the original author. The Pending Requests table includes information about both the user who has requested students for a job and the students the user has selected. To identify each of these pending requests each has a unique identification number. The pending requests table also has an entity holding the status of each request to see if it is still pending/open or closed and the job has been accepted by one of the students. The skill ID number is also held as a foreign key attribute within this table so that all the information relating to the request is visible in one place without having to perform a join of multiple tables. The requested job time of the transaction is also held as this attribute may be a deciding factor to the students who have been selected for the job. The Jobs table includes the information that has been updated once a student has accepted the job from a user. This enables a record to be made of all the jobs accepted and completed via the web-based system and for all the records to be held in one table. The rating table holds the attributes of rating, student and user ID: and rating, rating description and vetted. This enables each rating and review of a student to be unique and all parties involved to be identified. The rating is a numerical rating between 1 to 5, which allows the users to visually show their opinion of the student and the work carried out by them. The rating description allows users to write a comment as an expansion of their numerical rating of the student. The vetting attribute allows the comment to be checked to ensure that it is safe for public viewing and isn’t holding and profanities or is discriminatory towards anyone. The student table holds all the information relevant to the student who wishes to make an account and use the web-based system. It holds the student’s full name, gender, postcode and contact details. By holding this information, it enables the student to be checked that they are enrolled at a higher educational facility via their email address. Their age attribute allows checks to be made if any skills have age requirements thus rendering the student unavailable for the job. Holding their postcode as an attribute allows their location to be shown and for the distance between student and user to be calculated which may play a large role on both the decisions made by students and users when selecting a job to be done. The student profile holds all the additional data which will be shown to users viewing profiles of students, such as their minimum hourly pay rate and the minimum job time they charge for, alongside this their skills and skill departments are shown to the user. The skill table holds all the different types of skills available to be selected by either users or students, this table also holds a description of the skill. Each skill is uniquely identified by their own ID number. Each skill is also allocated to a skill department to allow the filtering of options for the user when selecting the skills, they require. The skill department holds the department ID of each different category of skill alongside the department name of each category of skill. The student image table holds just the student image ID and the image of the student for their profile. This table was created by normalising the student table to reduce the redundancy within the table due to its size. This was also done to ensure the loading speed of the table does not affect the web system when in use. Originally the student, student profile and student image tables were all one table. The decision to normalise out this large table was made to make any updates and data fetching from these tables quicker. The login credentials table holds the username and password for the accounts of each of the users; when a password is forgotten and updated this will get updated. To ensure that the ERD is correct, the test data used will outline the connections and relationships between the different tables of the database the test data and the outcomes of the testing are detailed in the testing appendix (appendix H) within this document. The non-functional requirements for this web-based system are outlined using the MoSCoW methodology of prioritization: Must have:

1. 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.

2. 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.

Should have:

1. The web-based system should have a sufficient speed at which it can process the upload and send the notifications and messages between users.

2. 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.

3. The scalability of the system should be easily implemented to accommodate for both an increase and decrease in users.

4. The maintenance of the system needs to be cost-effective when looking to host it long term.

Could have:

1. The maintenance of the system needs to be cost-effective when looking to host it long term.

Won’t have:

1. 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:

1. 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.

Should have:

1. 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:

1. Text alerts for users wishing to be notified and updated when not on a search engine.
2. A mobile app version of the web-based system to enable all devices to provide the best version of the web-based system.

Won’t have:

1. 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.

Appendix F: Design Report178 For the design of the system, mock-ups of the key pages were made during the systems design phase of the waterfall software development methodology. This provided the project with a clear aim of how the web-based system should look. Alongside designing the layout of the pages for the web-based system, a colour scheme was chosen based on research outlining the successes of websites and the target audience of the web-based system. The colour blue was chosen for the theme of the web-based system as it has been shown that websites featuring the colour blue are seen as more trustworthy. (Elliot, 2015) Valdez and Mehrabian (1994) studied the effects in which colours have on the users’ emotions. From these studies, it was shown that blue is associated with secure, comfortable and soothing emotions. This is a result of it being a short wavelength hue, which is seen as more pleasant. Bottomley and Doyle (2006) explored the relations between context and colour, and it was shown that blue is more appropriate for functional products, such as websites. Examples of websites who have used blue within their design include IBM. The IBM website uses blue, grey and white as their colour pallet. This creates a contrast to show clear visibility of the page components whilst presenting the page as professional (Pixel77.com, 2018).    Figure 9 – Student profile mock-up page of web-based system

Appendix G: Implementation Awaiting code completion to be inserted.

Appendix H: Testing A list of all the testing conducted throughout the project are listed below including a management summary overviewing the tests that were not completed, failed or still posing issues.

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?

Appendix I: User Guide Awaiting code completion to be inserted.

Appendix J: Project Management288  Figure 9- Project Gantt chart detailing tasks and their durations  Figure nine shows the project Gantt chart and the breakdown of the tasks which make up the project. As predicted in the feasibility study of the project the Gantt chart timeline spans over eight months to ensure that there is a sufficient amount of time allocated to each section of the project. The milestones are in bold and also designed to display as the development methodology phase headings. This shows clear boundaries and mimics the design of the waterfall lifecycle. Figure 10 – The Waterfall Development Lifecycle The Gantt chart has been created to factor in commitments which have taken away time from working on the project, such as university assignments, exams and employment. The Gantt chart in figure ten was created at the start of the project to show the projected timeline. During the project, there have been several setbacks from personal illness and injury. Yet due to the scope of the project timeline, this has not affected the end date of the project. Each phase of the project was given an allotted amount of time. This worked well as a guideline to work towards during the entire project. To ensure that the project was on schedule, a second Gantt chart was made with the start and end dates entered to compare against the projected milestones of each phase. In figure eleven this alternative Gantt chart is shown, the most significant difference is the start and end times of the separate tasks of the systems analysis and design as it took much longer than initially anticipated, however tasks such as writing up the report and meetings took much less time than initially anticipated so these two changes cancelled out the potential delay which could have been caused.

Appendix K: Meetings with Supervisor All meetings held with both the personal supervisor of this project (Dr Muna Al Jepoori) and the module leader (Gerald Stock) of the individual project 40 credits are as follows:

K1: Module leader meetings

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.

K.2: Mentor with Personal Supervisor

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

Appendix L: Agile Development: Timebox 1 “Not Applicable.”

Appendix M: Agile Development Timebox 2