A Business Information System Framework for Restaurants Thomas Slinger Computing for Business 2010 / 2011

Transcription

1 A Business Information System Framework for Restaurants Thomas Slinger Computing for Business 2010 / 2011 The candidate confirms that the work submitted is their own and the appropriate credit has been given where reference has been made to the work of others. I understand that failure to attribute material which is obtained from another source may be considered as plagiarism. (Signature of student)

2 Summary The following report describes the creation of a prototype business information system framework for restaurants and specifically one client, in order to automate the business where able and improve overall business efficiency. The report covers the problem, the initial background research performed, a detailed analysis in which requirements are derived and the designing and development process of the system. The report concludes with an evaluation of the systems successes and flaws and future improvements.! i

3 Table of Contents 1. The Problem Domain Aim Objectives Minimum Requirements Criteria for Evaluation Project Schedule Background Research Methodology Implementation Languages Databases Development Method Content Management Systems Features Usability SEO Server Analysis Interview Existing Systems Carts Summary Users Requirements Validated / Integrity Compatibility Design Structure Layout Design Database Design Iteration Schedule Client Feedback Initial Development Iteration Website Layout Manager Interface Layout Configuration Users Pages Client Feedback Summary Second Development Iteration Changes Reservations Menu Gallery Client Feedback Summary...36 ii

4 7. Third Development Iteration Changes Supplier Kitchen Newsletter Help Client Feedback Changes Summary Project Evaluation Use Of Methodology Use of Development Tools Features Developed Web Compatibility, Usability, SEO and Integrity Existing Solutions Future Development Maintenance Conclusion...50 References...51 Appendices..54 Appendix A Personal Reflection Appendix B Schedule Appendix C Client Interview Transcript Appendix D Database Schema Appendix E Entity Relationship Diagram Appendix F Initial Development Iteration Client Testing Appendix G Second Development Iteration Client Testing Appendix H Final Development Iteration Client Testing Appendix I Cross Browser Compatibility Appendix J Client Letter iii

5 1. The Problem Domain Restaurants whether they are small, medium or large all perform day-to-day tasks such as taking reservations, taking and serving orders, ensuring that there is enough food in the kitchen to process the orders and so on. Most restaurants are taking advantage of modern technology in order to make their business more efficient this could be anything from a website to touch screen tills. The problem is, every item of technology that is available works on a separate system to one another. The analysis in this report reflects this finding. Restaurants are not taking advantage of combining modern technologies to make their businesses as efficient as possible. 1.1 Aim The project s aim was to specify, design and build a flexible, web-based framework to be used by restaurants to meet certain business needs and ultimately increase efficiency. For example: booking tables through a dynamic website where menus can be adapted on the fly, and newsletters can be sent out to customers. The development of a prototype of the framework to demonstrate its use took place for a client. 1.2 Objectives The objectives of the project were: To automate a restaurant business where possible, e.g., by supporting online bookings for tables at the restaurant to improve efficiency. To provide a digital storage facility for the kitchen to keep a record of food stock levels. To help broadcast information, special offers and events to customers via a newsletter. To provide a dynamic website, which is fully editable. To provide all of the above in the form of a general framework that is easily adaptable to the needs of different businesses in this domain. 1

6 1.3 Minimum Requirements The minimum requirements were to: Perform an analysis of the restaurant business field. Design and deliver a general web-based framework that can meet the needs of a restaurant business. Deploy a prototype of the framework. Provide user documentation for the end user of the framework. Perform an evaluation of the prototype. 1.4 Criteria for Evaluation At the end of the project an evaluation took place. The following criteria was set in order to evaluate different aspects of the project: Use of Methodology - The chosen methodology should be evaluated against how effective it was against making use of time throughout the project and what benefits and drawbacks it brought to the project. Use of Development Tools - The languages and technologies used in the project should be evaluated against the selection criteria for choosing them to decide whether or not a particular language or technology has fulfilled the criteria. Features Developed - The features developed in the system should be evaluated against the proposed solution for each feature in the system requirements. Web Compatibility, Usability, Standards, SEO and Integrity - These criteria are discussed in more detail later on in the report. Each of the criteria should be used to evaluate whether or not the system has fulfilled it. Comparison to existing solutions - To arbitrate the success of the prototype, a comparison should be made from the prototype to existing solutions. Future Development - Discuss the implications or justifications of how the system could be developed further in the future. 2

7 1.5 Project Schedule For project schedule see Appendix B. 2. Background Research Background research was carried out here in order to select the correct methodologies, tools and evaluation criteria for the project. It is desirable that sources used in background research are reliable and of high quality, ideally peer-reviewed journals or well-regarded textbooks. Unfortunately, new web technologies are often not discussed in such sources. Careful comparisons were made between the technologies. Advantages and disadvantages of the technologies were looked at in terms of their portability, usability, compatibility, security, efficiency and documentation. 2.1 Methodology Sommerville [1] defines three models of software development. Two of which are: the waterfall model and iterative development. The iterative approach intertwines specification, development and validation. A number of iterations are performed in order to develop the software. At first an initial system is developed from initial specifications. The client is then given the opportunity to provide feedback. Developers take the feedback on board in order to perform an additional iteration and so on until the system satisfies the client s needs. The approach came across efficient and beneficial to the client. It encouraged a greater understanding of the problem. Although, it did seem time costly as a number of iterations of development will have to occur rather than one as in the waterfall model. [1] An iterative approach was adopted to allow for on-going development, testing and feedback from the client. Different approaches to Iterative software development were researched: Agile methods take the form of an iterative approach. They focus on the clients needs throughout the development of the system and are suitable for projects that require feedback from the client per iteration of development [1]. There are many different agile methods: Extreme Programming is a popular method. It introduces short cycles of development 3

8 in order to introduce checkpoints for the client to make changes. It primarily focuses a lot of attention on testing and is often carried out in pairs or teams [14]. Extreme Programming didn t seem suitable as a method for the project as it is intended for teams of developers who are on a limited time schedule. Feature based is another popular method. This method is [15] driven from clientvalued feature perspective. A list of features is drawn up, assigned a priority in the project, and are then assigned accordingly to each iteration of development [15]. As outlined in the requirements, it is noted that there are key features of the system. These features were encapsulated at different iterations to ensure that time was used efficiently throughout the project. [15]. After looking into other Agile Methods, it was found that most focused on teams rather than individual. They were also structured for organisations. It was decided that the feature based agile method was most appropriate for the project. The system would be developed in iterations. Features would be assigned to different iterations, in order of priority in the system. If the client was not satisfied with a particular feature it would be passed onto the next iteration and placed at the top of the list. The only limitation found was that if the client was unhappy with all features of the system at iteration one, changes for all features would be passed onto the next iteration resulting in double the work load at iteration two. Although, the limitation was discarded as it was decided that the reward of gaining valuable client feedback would hopefully play an important aid in ensuring the features met the client s requirements. It was determined that there would be three iterations. The initial iteration of 6 weeks would be longer than the second as it would be the initial stage of design and development containing the major features of the system. The second stage would be 4 weeks long to allow for changes and would feature less workload than the first iteration to equate for any changes. The third stage would be 6 weeks long as it would require the final evaluation of the system to be completed. For each stage of development, testing will take place. A list of tests will be provided to the client for each stage. The client must complete all the tests, answer if they were able to complete the test without any problems and will have the chance to provide feedback on each test. The feedback may come in the form of changes or something they are happy 4

9 about. The manager of the restaurant will test the first two stages of development. The chef, supplier, and manager will test the final stage. 2.2 Implementation There are many different technologies and languages available for use on the web. It is not just the technologies and languages that are important. Web standard rules must be followed to ensure that the framework is consistent and usable across a range of browsers. To ensure standards are met, XHTML and CSS used by the framework will be validated with the W3C Mark-up Validation Service. Before development can take place it is vital that certain factors are taken into account in order to select the correct technologies and languages for the development. For instance, the following factors are important and relative to the system: Adaptability the technologies and languages the system is based upon will have to flexible and adaptable to the needs of the business i.e. capable of dealing with developing a table booking system, etc. Portability the system being developed acts as a business framework to all restaurant businesses (not just the client). It is important that the technologies and languages the system is based on are portable - meaning they are transferable to a new system. Efficiency the system must be fast and be able to cope with demand from customers. To ensure efficiency the server used for the system must be agile enough to cope with the traffic to provide fast response times. The design of the website will play an important role in response times, as more graphical content results in a longer response time. Security different departments and personnel who work for restaurant businesses will be using the system. Therefore it is vital that user accounts are kept separate from one another with the use of permissions. Certain personnel will have access to certain parts of the system, but will not be able to view what personnel with a higher security permission can. Documentation in order to build the system as efficiently as possible there must be a sufficient amount of documentation available on the technologies and languages involved. 5

10 2.3 Languages PHP by far one of the web s most popular server-side languages used by the masses on the Web. The language works as follows: a user enters a webpage that contains a search query for a book. They input the book title they are looking for, and the server (PHP) processes the query requested and returns the results to the user s web browser. PHP contains build in functionality that makes printing data, performing mathematical calculations, making comparisons, and making Boolean choices effective. Such functionality can be built on to develop complex functions and loops [16]. There is plenty of documentation available as it is so popular, and therefore very well supported. As it is so popular - many development companies have already developed many frameworks, which are available for free. These frameworks may come in handy to the development of the system as they can define low-level building blocks or foundations to ensure speedy development. Due to previous experience with PHP, only a small amount of additional learning will be required in order to develop the system with this language. PHP is ubiquitously supported across most web-hosting providers; where as other languages aren t always supported. ASP.NET stands for Active Server Pages and is a Microsoft server-side framework. The.NET part comes from Microsoft s.net framework that is now packaged with the latest Microsoft Windows 7 operating systems. The framework was developed in order to build, deploy and run web applications. This framework is very flexible as it can be used with three core programming languages C#, VB, and J#. ASP.NET is packed with large libraries that make it easier and quicker to write code, and the support is excellent. ASP.NET commonly runs on the Windows platform, but can be implemented on Mono an open source implementation of the.net framework. Web-hosting providers do not commonly offer mono as part of a Unix package. [3] Java an Object Oriented Programming (OOP) language that can be client and / or server based. It has syntax similar to C++. An advantage of Java is that it is not platformdependent, meaning it can be used on almost any operating system. Due to the unfamiliarity with Java in comparison to the other two languages, using it may result in a steep learning curve in learning how to program using the language. Although it is well documented and very well supported. 6

11 PHP seems to be the obvious choice for this project. Previous experience will ensure that the learning curve is kept relatively small. Efficient development is desirable in order to produce a more complete solution that better meets the needs of the client. Due to previous experience, PHP should allow for more efficient development. It is recognised to be one of the most popular languages on the web, because of this there is plenty of documentation and support available. As software development companies have already developed frameworks in PHP - it is clearly a successful language. Development companies would not continue to develop and support such frameworks if it wasn t. Unfortunately, in the past PHP has not had a good security record. As Robert Lemos (2006) suggests Perhaps PHP should stand for Pretty Hard to Protect: A week after a prominent bug finder and developer left the PHP Group, data from the National Vulnerability Database has underscored the need for better security in PHP-based Web applications. The article [17] talks about flaws in the code of PHP, particularly when developers modify default settings. Having noted this, many of the articles that construe PHP to have bad security are very dated mainly from pre To this very day PHP is still a very popular choice of language. Security Focus notes, The fact is, the vast majority of vulnerabilities found in PHP applications are due to poor programming practises, and are one step away from the language itself [24]. Good programming practises must be carried out, this could involve following the official PHP documentation to write PHP code. This should result in a lower risk of security breaches. Security functions such as logins should be written into features where required. 2.4 Databases Choosing a database platform is just as important as choosing a language. It is vital that the database drivers are available for PHP. In this case PHP has been chosen. The most common database platforms used with PHP are MYSQL and PostgreSQL. MYSQL is the world s most popular open source database platform. The platform claims to be consistent, fast performing, highly reliant, and user friendly [4]. Web-hosting providers commonly offer MYSQL as a standard database platform in their packages, as it is open source the only costs are running it and supporting it. The majority of PHP frameworks that are available work with MYSQL databases PostgreSQL is an open source object-relational database platform. This platform is also very popular and has a strong reputation for its reliability, continuous development and 7

12 support. It is commonly known for its compatibility with many operating systems. It is now less common for PostgreSQL to be included in large brand web-hosting providers, but the majority of providers offer PostgreSQL additional to MYSQL at no additional cost. [5] Due to previous experience with MYSQL, it is a perfect fit to continue to build skills. PHP web applications that require a database are commonly associated with MYSQL and advertised together in packages by web-hosting providers. 2.5 Development Method There are various development methods available for software. The language and database platform have been chosen. Methods of developing the system such as extending an existing framework, building it from scratch or extending a content management system were some of the methods researched. Extension of Framework A web application framework is designed to support development of web-based applications, dynamic websites and services. Frameworks are a great place to start to build a web-based application, as they provide libraries for database access, templates, sessions, and most are open source. In a nutshell, they should be used to avoid writing repetitive code from the very start of the system. Frameworks are often based on the Model View Controller (MVC) concept. The model represents the data, the view presents the data and the controller processes the data. [6] Extending an existing framework would be very efficient in retrospect of this system, as it would allow me to work efficiently, test throughout the development, and not have to start from scratch. Built from Scratch developing the system from nothing. This approach can be useful. If the development was for a very specialised system, then there may be no option to use an existing framework. In the case of this project all of the functionality can be built upon an existing framework. It would take far too long to develop the system from scratch - time that isn t available. It would be inefficient to reinvent the wheel in this case, as the functionality is readily available to handle all of the generic tasks. Content Management Systems are systems that can be used to a developer s advantage (with the right scenario). They allow the end-user to create, edit, manage and 8

13 publish content to web pages that are constrained to rules devised by the developer. These rules ensure consistency in the appearance of the website. Important benefits to note about content management systems (CMS) are that they enable an end-user with a basic level of understanding of IT to create web pages without the use of HTML. The administrative interfaces are web-based, meaning no additional software is required off the web. Content can be edited anywhere with an Internet connection (if not an intranet environment). The website content will be more up to date as a result of freedom to post anytime and anywhere by the end-user. The website will be kept consistent - this plays a vital role in the scoring of web sites in terms of usability. [8] Examples of Open Source CMS include: Joomla! [25], Drupal [26] and Frog CMS [10]. These web based CMS can be hosted on most web-hosting providers, as they are all based on PHP and MYSQL the choice of language and database platform to work with. In the aspect of choosing a CMS there are many factors that are important such as the choice of navigation the system will offer, ease of use, flexibility for third party plugins, information storage and much more. [9]. Demos of Joomla!, Drupal, Frog CMS and ezpublish were tested. All offered Adaptability (third party plugins and extensions), Portability (easily transferable to a new server), Efficiency, Security (encrypted passwords, and lock out functions), and Documentation (all extremely well documented). To conclude the research on development methods, it is clear that a Content Management System would best suit the project in terms of the criteria set at the beginning of the implementation section. Most CMS work on the basis of PHP, and MYSQL where as Frameworks and Bespoke software are not limited to one language, or database platform. This is as an advantage due to having previous skills in PHP and MYSQL. Building from scratch is time consuming and prone to more bugs. There is a clear difference between CMS and frameworks. CMS primarily focus on content and support extensions / plugins, where as frameworks allow for more adaptability than just a dynamic website. Universally frameworks and CMS are both a learning curve. Having previous experience with CMS, it would be valuable in aiding the development process. The system will be based on a CMS. Necessary adaptations such as building a table booking system, kitchen ordering facility, build a template (visual, the appearance of the website) will take place to fit the client s needs. 9

14 2.6 Content Management Systems The following are four out of hundreds of CMS that seemed appropriate for the system. They are all open source (free). All are very well documented, and supported but some more than others. Demos of each of the CMS were tested. Drupal has many features. It allows for easy development. Editing functions are available on the fly, if logged in as an administrator. URLs are simple and search engine friendly. The majority of the Drupal s [20] extensions (modules) available are free so there is the potential to use adapted extensions for features specified in the requirements such as the Newsletter. User permissions are highly configurable, which is important to the development of the system since, as highlighted previously, different personnel will use the system and will need to be assigned to permissions that only allow them to access what they are supposed to. Major companies all over the world use Drupal. The administrative area is not very user friendly to an IT novice; the design is not very appealing (friendly buttons, intuitive colours) which makes it look complicated to use. Adding a visual theme is time consuming, although it is expected. Joomla! is arguably the world s most popular open source CMS. It is extremely well supported by a very large community in excess of 100,000+ members making it the largest open source CMS community in the world [18]. The administrative interface is much friendlier than Drupal s. Editing content is more visually pleasing with a more intuitive WYSIWYG (what you see is what you get) editor. The extensions database is huge in excess of [19], not as many as Drupal but after demoing a few of the popular extensions on Joomla and Drupal the quality of Joomla extensions felt higher than Drupal. There are many available for free and commercially which may play in favour of the discussed features in the requirements, as it is highly likely that a greater amount of extensions will be available for a particular feature. As Joomla is so popular it is updated more frequently than Drupal because of this the chances are that there will be more bug fixes available for Joomla than Drupal. The terminology is more complex for development, and the SEO is not as good as Drupal s. Themes seemed to be easier to skin than in Drupal, as the template system is less complex. Joomla s permission allowances are limited; this could be a problem (as discussed in Drupal). 10

15 Frog CMS a less popular open source CMS. Although that doesn t draw away from how intelligent this CMS really is. The Frog philosophy [10] is its fast, its simple and it works. First impressions are that the look of interfaces is clean, and very aesthetically pleasing. The administrative interface is very basic and simple, but works efficiently nevertheless. The Frog CMS has excellent permission features allowing administrators to create new user accounts that can only access certain parts of the interface a sought out feature. Layout customisation is easy, as each page can be set to inherit a template. Global snippets can be defined (small pieces of content) for example a page header to ensure efficient and adaptable templates. There are many contributors that submit extensions, although the list is very few. There are 50+ [20] in comparison to Joomla and Drupal but contains essential extensions such as a Gallery (six available plugins) that could be utilised to save time in development. An important point to note is that the response times for the Frog interface are a lot faster than Joomla and Drupal. This is probably due to the complexity of Joomla s and Drupal s additional features. Frog CMS would therefore meet the criterion efficiency set earlier in the report. Overall it is obvious that when it comes down to making the choice on a CMS, it depends on the purpose of the system. All of these CMS s meet the criteria set for selection of development technologies. They are all very similar, yet some seem a little simpler than others in terms of terminology. Simplicity, performance, and usability are important. By meeting these criteria, better use of time in the development process should ultimately result in a better system. Each CMS will have to be adapted regardless of the choice, but some may be easier than others to work with. Frog CMS is an obvious choice; the likelihood of bugs is much lower as there is less code involved. The Frog CMS philosophy appeals to the requirements, and development of the system. For that reason Frog CMS will be used. 11

16 2.7 Features This section discusses the features that the prototype system will have. For each feature a solution will be derived from the research carried out. Menu Management a feature that will allow the client to design, and structure their restaurant menu via the administration interface. The menu will have to be displayed as part of the website. Upon researching into Menu Management software, it was found that there aren t many existing solutions available. Easy CafeEngine was one of the only solutions for this feature it is apparently the perfect solution to managing your restaurant online [11]. After demoing the software it was found to be extremely efficient, a perfect fit for the system. A free version is available and a paid version. The free version looked to be more than sufficient. To code this feature from scratch would take a very long time, thus not making efficient management of time. Easy CafeEngine will be implemented to ensure maximum time efficiency in the development. Table Bookings this feature took a lot of research, as it is a common feature restaurants now offer online. Not so much for smaller businesses, but most franchised restaurants take advantage of this to maximise productivity of staff (not having to take as many bookings via phone) and to automate the process with such a system. Open Table and Top Table are the most popular systems available. Open Table claims to serve more than 15,000 restaurants with their bespoke restaurant management software [12]. Open and Top Table work on the basis of installing their systems in a restaurant, and provide a function to generate a piece of code for the website of the restaurant to take orders. It s very simple, and the system works having previous experience. It is extremely costly and not sensible for small businesses. On the basis of the framework being developed, it is clear that there would have to have some form of contract with one of the companies, this would make the feature very complicated to implement. A great piece of open source software was discovered - myseat [21]. By viewing the myseat website, it was clear that the software was clean, very robust, easy to implement and had great reviews. MySeat will be implemented, purely due to the complexity of building similar software from scratch. Kitchen / Supplier - a feature where the kitchen manager / head chef will be able to order food for the kitchen from their supplier. To simplify this feature it will only be able to order meat / vegetables. No ingredients will be taken into account. Stock levels will be kept 12

17 to ensure that food can be ordered when required. There are no solutions available to solve this feature. Although, it seems sensible to base this feature on a shopping cart as with a shopping cart items are brought and an order is sent off to the supplier. The database linked to the cart will hold items of food, a catalogue if you like. Initially this will have to be input by the Kitchen. This facility will aid the chef in speeding up the process of reordering meat / vegetables. Rather than doing it over the phone or via an order form. Newsletter a simple feature, Frog CMS comes with basic functionality to provide a newsletter. This functionality will be built upon to provide a fully functional newsletter component. To re-cap the newsletter feature will enable the restaurant to send out information via regarding the restaurant such as special offers, parties etc. Gallery is a slightly more complex feature. There are a number of extensions available for free via the Frog CMS website. It would be sensible to use the most popular which is a simple gallery allowing the restaurant to display photos of the inside and exterior of the restaurant building. Rather than develop one from scratch. 2.8 Usability There are certain standards of usability that need to be taken into account whilst designing websites. It is important that the quality of the website part of the system is user friendly in its design in order to attract more a higher frequency of customers. Nielsen et al. [2] talk about optimising a user s experience. They encourage the use of fewer clicks to get to pages, popup windows are not recommended and vertical scroll bars should be avoided. They talk about the homepage of a website being the most important page of the site, and that the average user spends seconds on it. From reading this literature, it is clear that usability should be an important aspect of the system. The design must be clear and narrative to ensure the user receives an intuitive web experience [2]. 2.9 SEO It is important that the framework is optimised for Search Engines (SEO). The Frog CMS system retains user friendly URLs such as rather than The Art of SEO by Enge et al. (2009) [13] is a very well detailed book that discusses the basics to the advanced methods of SEO. 13

18 Enge et al. talk about methodology. According to the book, it is vital that websites are kept as simple as possible in order for search engines to detect keywords, and links. In doing so the layout must be clean, contain good content, and must be highly usable. Most businesses will agree that it is important to get their websites on search engines in order to attract new customers. Better yet to be placed as a higher rank in order for optimum results [14]. This literature will be used as guidance to ensure the website is optimised correctly for Search Engine use Server The language and technologies chosen to base the framework are common and are compatible with most web-hosting providers. This gives the framework a competitive advantage over generic frameworks that may be based on ASP.NET that restaurants may choose to adapt to fit their needs. 3. Analysis An analysis of the problem was carried out in order to ensure the project requirements would be met. Information was gathered via an interview with the client and by researching into existing systems restaurants currently occupy. The analysis was used to generate a list of system requirements to effectively design, develop, and evaluate the system at each iterate. 3.1 Interview An interview was carried out in person with the client in order to obtain information that would aid the development process of the prototype system. The questions were constructed to gain a greater understanding of the processes that take place within the client s restaurant. The client s answers were recorded see transcript in Appendix C. To conclude the interview, a lot of information was gathered from the client that was not initially covered. Most processes in the clients business were performed on paper; there was little or no IT involved. There were deficiencies in the business that could be made more efficient with simple solutions. For instance booking a table seemed to be a lengthy process and was clearly wasting staff time. After questioning editing the current website, the body language perceived was very negative. From that alone it was gathered that it wasn t easy to get the current website edited efficiently. 14

19 One of the initial objectives set was to create a digital storage facility for the kitchen to keep a record of food stock levels and order new stock. It was concluded from the interview that having a stock list of food quantities wasn t important and potentially inefficient as counting every carrot in stock could be a lengthy process. The client revealed that the head chef does a rough check of ingredients that are low. If the stock level of food was implemented, every week the system would have to be updated with a stock check from the chef this goes against one of the requirements to automate the business where possible. The interview revealed that the chef places an order to a local farmer over the phone. In this process there is a chance that the order could become distorted resulting in incorrect quantities of ingredients being ordered or not being ordered at all. A potential additional feature to the framework was discovered that might aid staff in viewing their working hours from a computer. The client revealed that hours the staff work are drawn a paper sheet on the wall in the staff room. A feature could be introduced to allow staff to check their hours electronically. It was decided that the scale of such a feature would be rather large and would require an excessive amount of time to implement. 3.2 Existing Systems As discussed in the background research there are no systems available that are capable of managing / automating many processes specifically within a restaurant. Background research concluded that the system would be based upon the Frog Content Management System and that components would be built into this system to complete the prototype. There are many components available that could potentially construct the system. Features discussed potential components that could be used for menu management, table bookings, newsletter, and gallery in the background research carried out. It was derived that no additional features will be added to the system from the client interview. The interview with the client concluded that one of the components could be adopted to improve the system even further, the kitchen digital storage facility. Rather than keeping information on food stock levels, the feature could aid the chef in processing the orders. As mentioned in features, there are no restaurant specific components available that can aid 15

20 the ordering process. For maximum efficiency of time a generic component such as a shopping cart could be adapted in order to fulfil this feature Carts Carts were researched for their simplicity and ease of adoption to the kitchen facility. OpenCart a free open source cart [22]. The OpenCart came across as user friendly. Boasting rich design features, free support and documentation that included adaption of the cart for a specific purpose. XCart is a commercial cart [23]. The cart is marketed as a universal concept that provides an optimal solution for all e-commerce projects. The customisation features were specifically designed to allow developers to adopt the cart to all business scenarios. Of the two carts, OpenCart was found to be most suitable - for its ease of integration and user friendliness. OpenCart runs on PHP and MYSQL, the two platforms the framework will be based upon Summary It is a problem that there are no existing systems available that can support various processes that take place within a restaurant. To develop such a system a restaurateur would have to employ a company to develop a bespoke system. It is clear that there is an opportunity to develop a generic restaurant framework to solve this problem. 3.3 Users As there are different actors that will be using the system it is important that each one is defined, and given the appropriate permissions to access their part in the administration interface. Manager the restaurant manager will be in charge of editing the website, creating menus and making edits and updating the image gallery. As the manager runs the business it is important that they have permission to all components of the system. 16

21 Supplier where all food orders are directed. In this case, the farmer will be able to access an interface that allows them to add food to the cart system that can be purchased by the head chef. The farmer will receive orders via . No other components of the system will need to be accessed. Head Chef will select the food he wishes to order via the cart system but cannot see the same interface the farmer will see. Order will be sent to the farmer upon checkout. No other components of the system will need to be accessed by this user. Customer will be able to book tables via the website, access information about the restaurant such as contact information and menus and receives offers via a newsletter. No administrative interface will be required for the customer. 3.4 Requirements A list of requirements was derived from the background research and the client interview. The list will be used to create a plan for the different iterations of the development process. Login providing access to the administrative areas of the system. User accounts for login with the ability to assign permissions that only enable access to certain parts of the system. Administrative interface for all users to access different components of the system. Manager interface the ability to add, edit and delete web pages. Add, edit and remove images from the gallery. Create, edit and remove menus. Create and send newsletters, to view and remove subscribers when deemed necessary. Access to the chef and supplier interfaces. Website to display data rendered from the managers interface. Chef interface ability to make orders via a cart system that is updated by the farmer. Supplier interface ability to add, edit and remove items to the cart system. Check orders. 3.5 Validated / Integrity As a lot of data is being input into the system through various components data must be validated to ensure there are no incorrect types of data input for a certain field. For 17

22 example if the manager wishes to upload an image to the gallery, it must be of an image file extension i.e. jpeg, png rather than doc. If the farmer is entering a new product into the cart system it must not contain numbers. 3.6 Compatibility FrogCMS features the use of JavaScript; there may be users that have manually disabled JavaScript. Therefore the system should prompt the user if they have it disabled before using the system this will ensure that features work as they are designed to. The framework will be web-based. The system will need to be viewable across a range of different web browsers such as Apple Safari, Google Chrome, Microsoft Internet Explorer, Mozilla Firefox and Opera. In order to ensure the system is compatible with the browsers above the system must be validated by W3C (World Wide Web Consortium) specifications for HTML & CSS. 4. Design As planned in the schedule an initial design phase was carried out in order to develop the preliminary structure of the system. This included the database schema, the design and structure of the systems user interfaces. A plan was drawn up that contained a list of the features that would be completed at the iterations. The requirements from the clients interview were taken into account to ensure the system would be suited to the prototype model for the client. 4.1 Structure To illustrate the structure of the system a diagram for each parent function of the system was drawn up. The structure being: A website front-end for the customer. A manager s interface that encapsulates all the functionality in the system such as maintaining the website, creating menus, checking reservations, and so on. A chef s interface that only provides functionality to create, view the status of, edit and delete orders for the kitchen. A supplier s interface that only provides functionality to process orders from the kitchen. 18

23 Website Front-End Food - About the food - Interactive menus Contact - Contact information - Google maps Homepage - About the restaurant - Newsletter subscribe Reservations - Book a table - Options for group or single booking Gallery - Interactive gallery Opening hours - Opening hours - Picture Managers Interface Configuration - Restaurant name - Website template Pages - Create, edit and delete pages - Publish / hide pages - Order pages Manager Interface Reservations - Create, edit and delete reservations - View reservations Kitchen - Add, edit and delete orders Menu Management - Add, edit, and delete menus Gallery - Add, edit and remove images Users - Create, edit, and delete users - Assign permissions Newsletter - Create and send newsletter - View subscribers 19

24 Chef Interface Chef Interface Checkout / Cart - Check order - Edit quantities - Remove items Catalogue - View categories - View items - Add items to cart - Search for items Orders - Check order status - Cancel orders Supplier Interface Supplier Interface Catalogue - Add, edit and remove categories - Add, edit and remove items Orders - View orders - Set order status 20

25 4.2 Layout Design Initial layouts were designed for the website front-end, managers interface, chefs interface and suppliers interface. Website Front-End Layout Standard Page Layout Website navigation Page content will sit within this box. Content from Gallery, Food, Contact, Reservations, Opening Hours, and the Home page Booking a Table Select lunch or dinner Number of people Table Booking Layout Calendar object Checks availability and returns a list of times 21

26 Managers Interface Admin navigation links Navigation that points to features in the system Parent page Home cannot be deleted Child pages click to edit Delete pages Chefs Interface Add child page new page Remove item Quantity Completes the order process Items available for order Quantity of item required 22 Adds item to cart

27 Suppliers Interface New category New item Remove item 23

28 4.3 Database Design A database schema was drawn up as a representation of where data would be stored in the system. Each entity in the database was identified along with a collection of attributes that would be used to store items of data. For instance: an item of food for the kitchen to order. An entity relationship diagram was developed in order to visually aid the presentation of relationship types between entities. Appendix E. For database schema see Appendix D. For entity relationship diagram (ERD) see 4.4 Iteration Schedule An iteration schedule was created containing a list of items that would be developed at a certain stage in the development process. As noted in the methodology it was described that the system would be developed using a featured based agile method. This was done by assigning features (items of development) to different iterations; in order of importance. As an agile method, the client would evaluate the work that would be produced at the end of each of the iterations. The core fundamentals of the system were placed in the initial iteration schedule, vital components in the second iteration and everything left in the third iteration. Initial Iteration General Item Requires Time Estimate 1 Website layout - 2hr 2 Manager interface layout 1, 3, 4 2hr 3 Chef interface layout 2, 4 1hr 4 Supplier interface layout 2, 3 1hr 24

29 Manager Interface Item Requires Time Estimate 5 Configuration 4 1hr 6 Users 2, 3, 4 2hr 7 Pages 1, 4 4hr Total Iteration Two 13hrs Managers Interface Item Requires Time Estimate 12 Reservations 4 4hrs 13 Menu 4 4hrs 14 Gallery 4 3hrs General Item Requires Time Estimate 15 Reservations for Website 12 2hr 16 Menu for Website 13 3hrs 17 Gallery for Website 14 2hr Total Iteration Three 18hrs Suppliers Interface Item Requires Time Estimate 18 Create Catalogue Component 2 4hrs 25

30 19 Create Managing Orders Component 2 4hrs Chefs Interface Item Requires Time Estimate 20 Create Catalogue Component 3 4hrs 21 Create Order Status Component 3 4hrs Managers Interface Item Requires Time Estimate 22 Add Tab for Kitchen 20, 21 1hr 23 Newsletter 4 4hrs General Item Requires Time Estimate 24 Newsletter for Website 23 1hr 25 Help Documentation 1, 6 3hr Total 25hrs 4.5 Client Feedback Initial layouts that were designed were passed onto the client for review. The client was pleased with the initial work that had taken place and had no feedback for this stage. It was a great start towards making a working prototype of the system. It was no surprise that the client had no opinion on the initial layouts that had been delivered. The assumption was made that as the system was at a very early stage the client was only able to assess the layouts and therefore the system was evaluated visually. There was no working system that the client could test. 26

31 5. Initial Development Iteration As identified in the iteration schedule in 8.4 the initial development phase would include building up the core principles of the system. This would mainly consist of building the interfaces of administration for each of the users of the system and setting up configuration parameters for the manager s interface. 5.1 Website Layout As the restaurant website is one of the fundamental parts of the system. It was made a priority to develop the structure of the website before an administration interface could be implemented. An initial page was developed in HTML using CSS (Cascading Style Sheet). CSS enabled me to style content and set positions for different content in the page. Such as the header (logo), navigation and body (mosaic background where content would be generated). Featured below is the result of the initial template: The template would later on be editable via the administration interface. For example uploading a logo to the header, adding a Favicon to the website and adding / editing and removing pages shown in the dark grey navigation bar. 27

32 5.2 Manager Interface Layout The back-end administration interface (where the manager can access all functionality of the system) was next for development. As decided in the background research, the system would be based on the Frog CMS framework. This would allow for more time to develop each component of the system. A new administration layout was created from the default Frog CMS layout below: The modifications included enhancing the font size as certain sizes on different pages were not consistent or too small, changing the colour scheme to keep the system as consistent as possible throughout and inserting the appropriate tabs for different components of the system. The end result is below: Layouts were similarly developed for the Chef and Supplier interface ready for the implementation of the Kitchen & Supplier components in the third iteration of the development. 28

33 5.3 Configuration As the administration interfaces were developed, the next stage was to begin to develop principle functionality of the system. The first aspect of functionality was the configuration. Frog CMS came packaged with some basic configuration attributes. Many of which were stripped from the CMS, as they were completely irrelevant to the objectives of the system. One attribute was kept Site Title. This was renamed to Restaurant Name and would act as a global attribute to parts of the system. I.e. the title of each page on the website would include this attribute - Restaurant Name Home. Two new functions were implemented - Logo & Favicon, relating what was mentioned in 5.1. Both functions were developed to use similar methods to perform their objectives. Each function was written containing a form that calls a snippet of PHP code that allows the user to upload a logo or Favicon. The PHP code reads the file selected, validates it to ensure it is appropriate and writes it to the server. Validation was written into the code to ensure that only image or favicon files were uploaded via checking the file extension for anything other than an image file / favicon file. Below are the results of the configuration development: 29