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

(1)

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) ____________________

A Business Information System

Framework for Restaurants

Thomas Slinger

Computing for Business

2010 / 2011

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

(3)

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.

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

(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:

(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 client-valued 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

(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

(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 platform-dependent, 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.

(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 2006. 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

(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

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

(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 7025+ [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 6241+ [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).

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

(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

(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 email 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 25-35 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 http://www.website.com/about, rather than http://www.website.com/about.html?req=two. ‘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.

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

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

(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

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

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

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

(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 email. 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

(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

(23)

Website Front-End

Managers Interface

Homepage

- About the restaurant - Newsletter subscribe

Food

- About the food - Interactive menus

Gallery

- Interactive gallery

Contact

- Contact information - Google maps

Reservations

- Book a table

- Options for group or

single booking

Opening hours

- Opening hours - Picture

Manager Interface

Configuration

- Restaurant name - Website template

Pages

- Create, edit and delete pages

- Publish / hide pages - Order pages

Users

- Create, edit, and delete users

- Assign permissions

Management

- Add, edit, and delete menus

Gallery

- Add, edit and remove images

Newsletter

- Create and send newsletter

- View subscribers

Reservations

- Create, edit and delete reservations - View reservations

Kitchen

- Add, edit and delete orders

(24)

Chef Interface Supplier Interface

Chef Interface

Catalogue

- View categories - View items - Add items to cart - Search for items

Checkout / Cart

- Check order - Edit quantities - Remove items

Orders

- Check order status - Cancel orders

Catalogue

- Add, edit and remove categories

- Add, edit and remove items

Supplier Interface

Orders

- View orders - Set order status

(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

Booking a Table

Website navigation

Page content will sit within this box. Content from Gallery, Food, Contact, Reservations, Opening Hours, and the Home page Standard Page Layout Table Booking Layout Calendar object Checks availability and returns a list of times

Select lunch or dinner

(26)

Managers Interface Chefs 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 Remove item Quantity Completes the order process Add child page – new page

(27)

Suppliers Interface

Remove item New item New category

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

For database schema see Appendix D. For entity relationship diagram (ERD) see Appendix E.

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

(29)

Manager Interface

5 Configuration 4 1hr 6 Users 2, 3, 4 2hr 7 Pages 1, 4 4hr Total 13hrs Iteration Two Managers Interface

12 Reservations 4 4hrs

13 Menu 4 4hrs

14 Gallery 4 3hrs

General

15 Reservations for Website 12 2hr

16 Menu for Website 13 3hrs

17 Gallery for Website 14 2hr

Total

18hrs Iteration Three

Suppliers Interface

(30)

19 Create Managing Orders Component

2 4hrs

Chefs Interface

20 Create Catalogue Component 3 4hrs

21 Create Order Status Component 3 4hrs

Managers Interface

22 Add Tab for Kitchen 20, 21 1hr

23 Newsletter 4 4hrs

General

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.

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

(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

(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:

(34)

5.4 Users

The users component is based on the initial component given in Frog CMS.

Additional development took place in order to allow for new ‘Roles’ (user permissions) in the system. Meaning that certain users would be assigned a level of access under the attribute of a ‘Role’. This would ultimately mean that each role would only allow access to certain components of the system.

The default roles that come packaged with Frog CMS are ‘Administrator’, ‘Developer’, and ‘Editor’. The first task was to rename these roles to the specified roles earlier in the report. The roles were changed via accessing the database and modifying the permissions records. Resulting in:

The next task was to ensure that only specified users such as the ‘Chef’ could only access certain parts of the system – i.e. a Chef can only access the Kitchen & Help tabs. Frog CMS has a handy built in class defined ‘AuthUser’ which contains a function that returns whether or not a specified role has permission to access the desired part of the system:

Multiple IF statements were written in the main administration interface layout that allowed specified users such as the Chef to only be able to access certain parts of the system.

5.5 Pages

The pages component is also based on the initial component given in Frog CMS. Certain attributes were stripped from the pages component, as they were not necessary. The pages function allows the user to edit the contents of a page on the website. It was foreseen that there was no requirement for the user to add / edit any of the text on the ‘Food’ – displaying menus, ‘Gallery’ – viewing photos and ‘Reservations’ – booking tables. For each of these features, any text that needed to be written to the page would be

(35)

‘Food’, ‘Gallery’, and ‘Reservations’ were disabled from editing as each page contained code that was vital to making each component display on the website correctly. See result below:

5.6 Client Feedback

A working demo of the interfaces and the website was given to the client. A list of tests were given to the client, see results in Appendix F.

The first testing results were excellent. The client was extremely pleased with the progress on the front-end of the website. The client did have one suggestion, which was that there should be a link to ‘View the Website’ at the top of the administrative interface. This would enable them to go directly to the website from the administrative page, without having to change the address in the address bar of the browser.

5.7 Summary

The initial development iteration provided the founding principles of the system. The client’s feedback was positive. The client’s suggestion regarding the administrative interface was passed onto the next stage for implementation (second development iteration).

(36)

6. Second Development Iteration

The second iteration of development focused on adding components such as the table reservations component, the food & drink menu component and gallery component to the administrative interface and the website.

6.1 Changes

As noted in 5.6, the client pointed out that there should be a link on the administrative interface that takes you straight to the website. The change was made and the link created as follows:

6.2 Reservations

Frog CMS works on a model-view-controller approach (MVC). The documentation suggests that to create an additional function / tab in the system, an adoption of the Skelton plugin template provided must take place. A plugin being the term Frog CMS use to denote the creation of an additional feature. The skeleton plugin, as with all components within the system uses the MVC approach [6]:

The reservations component was one of the first components to be addressed, as it would perform one of the main features in the system – table bookings for the restaurant. Upon performing background research into existing systems, it was quickly understood that the problem of booking a table online was fairly complex and required a great deal of time in order to test it properly. An open source component – mySeat was found during research. It was clean, consistent and had great reviews.

The mySeat open source component was implemented into the reservations tab (administrative interface). Parts of the component that were not relevant to the user

Model

Where the code exists to perform functions.

View

Acts as a template for the model, it is what is displayed to the user.

Controller

Where interaction with the user takes place.

(37)

requirements, such as statistics were removed. The template of the system was modified to ensure it was consistent with the design of the administrative interface.

The front-end of the mySeat system (reservation form) was implemented on the website. The form was styled for consistency with the design of the website. Additional validation was added in the form of Javascript in order to ensure that the data input into the form was valid. Dialog boxes prompt the user when there is an invalid input in the form:

It should be noted that the reservations form is an alternative option to calling the restaurant and booking a table. Should false details be left through the reservation form; there is an equal chance a person may do so via telephone. Data validation aids in protecting the reservation form from a user

inputting bogus details but cannot prevent it entirely.

6.3 Menu

The next feature to implement was the menu component. As mentioned in the background research – it was decided that the implementation of an existing solution would aid me in developing the prototype in time. Easy CafeEngine was implemented into the administrative interface tab ‘Menus’.

Many modifications were made to the component in order for it to sit correctly in the ‘Menus’ tab. Mostly involving removing unnecessary styling from the template where menus are added, edited and deleted.

Surprisingly no form validation came packaged with the menu component. JavaScript was implemented into each form that allows the user to add / edit / delete menus, categories of food and dishes. Below is a snippet of JavaScript checking a add category of food form. It checks if the name of the category has been left empty and alerts the user accordingly:

The menu component came packed with pixelated icons that were unusable. New icons were designed in Photoshop for the component to continue the consistency of design:

(38)

Abutton was implemented on the right hand side of the administrative interface to allow the user to add a new menu:

The menu tab first saw the use of the ‘Tips’ box on the right hand side of the interface. The ‘Tips’ box was developed to ensure

that helpful documentation was available to aid the user in using the components provided in the system. Every ‘Tips’ box throughout the system relates to the component the user is currently on:

The front end of the menu component was added to the website to enable customers to read the menu through a web page. Rather than having to download a PDF file.

6.4 Gallery

Frog CMS provides a third party extension for a simple gallery component. This gallery component was implemented into the gallery tab in the administrative interface. Again, buttons were implemented for easy access to basic functionality in the component such as: adding a photo or viewing the gallery:

The gallery extension makes excellent use of validation error messages that are helpful in aiding the user perform tasks ‘correctly’:

(39)

Upon implementing the gallery to the website (front-end), a bug was found. This bug caused photos to display incorrectly – one photo per row rather than three. The bug was found on the web browser - Google Chrome. Testing was carried out a different web browser - Internet Explorer and the bug did not occur.

The Cascading Style Sheet (CSS) for the gallery was inspected for errors in cross browser compatibility. The photos parameter ‘padding’ was set to 100px. Internet Explorer clearly did not pick up on the fact this parameter was set to 100px. It was set to 30px to allow for Google Chrome to compensate. After the correction, three photos were displayed on each row.

6.5 Client Feedback

At this stage of development the client expressed that the system was becoming familiar to them. They felt as if they could navigate the system efficiently without getting lost. The client was given the second list of tests to perform. See Appendix G for results.

From client testing, it was expressed that in trying to delete a photo the client had uploaded to the gallery – they found couldn’t find the delete button. At the current stage at in the project, it seemed unnecessary to revise the way to delete photos. Instead reassurance was promised to the client. It was mentioned that the system would be fully documented by the end of development. The documentation would contain a guide to every operation performable within the system.

Secondly, the client wasn’t able to complete test #3, as they couldn’t find the search box. A suggestion was made to the client that in the next development stage, the word search could be written next to the search field to make it easier to find.

Aside from the testing, the client mentioned two other requirements. They requested a new button within the menu tab. They noted that navigating back to displaying the menus from navigating to dishes wasn’t obvious.

Lastly, upon logging into the system a numerous amount of times - the client

expressed the need for not having to input login details every time from the same computer. After discussing the security risks of adding such a feature, the client was still adamant in

(40)

implementing a feature to solve the problem. They justified the fact that they were a small business and the security risk of an intruder unlawfully accessing the system would be very low. It was suggested that the client’s login session should expire after 7 days if a feature as such was implemented. That way, the client would be at a lower security risk. The client was in agreement that the session should expire after 7 days. If the system were to be

implemented at a bigger company, a remember me feature should be stripped from the system due to the malicious risk involved.

6.6 Summary

The second development iteration provided the system with more functionality of key components in the system to aid in the automation of the business. The client’s feedback was fair and understandable. The client’s suggestions: view menus and remember me at login features were passed onto the next stage for implementation (third development iteration).

(41)

7. Third Development Iteration

The third iteration of development involved continuing to implement new functionality into the system. Functionality such as: the supplier, kitchen, newsletter and help component.

7.1 Changes

As mentioned in client feedback 10.6 there were three changes to be made to the system. The first change was to simply add the word Search: to the reservations system to ensure the client could find the search box to search for reservations:

The second change was to implement a solution to navigating to the ‘View Menus’ page, regardless of what page within the menu component the user is on. To solve this problem a ‘View Menus’ button was provided in the style of the ‘New Menu’ button:

The final change the client requested was to implement a feature that allows the client to login to the administrative interface automatically from one computer. I.e. the client does not wish to enter the login details multiple

times. Functionality was implemented to ensure that upon logging into the administrative interface a session would be created with an expiry date of 7 days. This would allow the client to login to the administrative interface, without having to input any login details for 7 days.

(42)

7.2 Supplier

The supplier component was first for implementation, as the kitchen component relied on the supplier component being developed first. The kitchen / supplier components are based on a basic shopping cart software package ‘OpenCart’ as mentioned in the background research.

The administration (back-end) component of the shopping cart package acts as the supplier component – where a supplier is able to add categories of food, add food ready to order from the kitchen and review orders. The front-end of the package acts as the kitchen component – where a chef is able to make food orders and check the status of orders.

OpenCart was installed on the server and the back-end of the package was implemented into the supplier tab. Under the supplier tab, three tabs – Products, Categories and Orders were

implemented in order for efficient access to different features of the cart package.

The OpenCart default templates were completely stripped to ensure the package conformed to the design of the system and performed seamlessly in the supplier tab. The products tab was linked to the new / edit / delete products section of the package. The categories tab was linked to the new / edit / delete categories section of the package. The orders tab was linked to the orders section of the package.

7.3 Kitchen

The front-end of the OpenCart package was implemented into the kitchen tab. Under the tab, two tabs – Catalogue and My Account were implemented. The Catalogue tab was linked to the chef view of the shopping cart – where the chef could make food orders for the kitchen. The ‘My Account’ tab was linked to the account component of the shopping cart –

where the chef could view orders, add a delivery

address and input contact information. As part of making an order, the chef

receives an email confirmation from the OpenCart system.

The email template is basic; this was restyled to match the rest of the system:

(43)

7.4 Newsletter

A very basic newsletter function comes packaged with Frog CMS. It is based on a PHP built in library ‘Mail’. The function was implemented into the newsletter tab. Features were added such as the ‘Subscribers’ feature, which acts as a landing page for the

component. Three buttons were introduced to perform three different tasks in the component

The subscriber’s feature was built to display a list of subscribers in the newsletter system, with an option to delete subscribers if required. An add subscriber function was written within the component to allow the user to manually add a user into the system:

Add Subscriber takes input from the form above and posts it to a function below. The function uses a query to insert the user data gathered from the form, into the database where the subscribers are stored.

The ‘Letter Management’ feature presents the user with a form to create a letter through the interface. It allows for the letters to be modified and deleted. The function below queries the database for letters, assigns each row to an array id and for each letter prints an option to modify or delete it.

(44)

A subscription form was implemented on the website (front-end) for customers to sign up to the newsletter. Meaning that when a customer inputs their details into this form a request is sent to add the user to the subscribers list in the database:

7.5 Help

The final stage of the implementation was to provide a help component that contains a walk through guide for every operation the system could provide. The help tab would act as documentation for the system. As it is a web-based system, it wouldn’t make sense to create a hard copy of the documentation. It should be available on the web.

Topics were created; each topic was assigned a snippet of JavaScript that would allow the user (upon selecting a topic) to view walkthrough tasks within each topic. This is best illustrated by interacting with the help component:

(45)

PHP IF statements were written to ensure that the user that is logged in only sees the documentation they need to see. For example, below is an IF statement that will only allow the ‘Kitchen’ part of the documentation to be viewed by the chef and manager.

7.6 Client Feedback

As part of the final stage of development three lists of tests were given to the client. The chef would test the Kitchen & Help (chef specific) components. The supplier would test the Supplier & Help (supplier specific) components. Finally, the manager would test the Newsletter / Help (manager specific) components. See Appendix H for results.

Client testing at the final stage of development was a success as all three users of the system were able to perform the tests given. There was one concern the chef testing made clear. Test #4 had been completed successfully, although the chef mentioned in the feedback that there was no list of items ordered in the email confirmation for the order.

7.7 Changes

As part of the final stage of development, final changes would commence. One issue was noted in the client feedback, 11.6. The chef had received a confirmation of their order without a list of items that they had ordered. They commented that there should be a list of items in the order confirmation for ‘record purposes’.

Modifications took place to ensure that templates for the order confirmation contained a list of items ordered. To produce the list, a function was called from the checkout model. The function list_order will return an order if called. The function called from within the order confirmation email template to create what is shown on the right. The restaurant

(46)

logo (generated from the config component) and the delivery address were added for a finishing touch.

7.8 Summary

The final iteration of development has introduced the final functionality of the system including the supply, kitchen, newsletter and help components of the system. Changes were made from the second iteration client feedback. The reservations search box was made clearer, a new ‘View Menus’ button was introduced to menus and a ‘remember me’

checkbox was provided for login. Client feedback created a request from the chef to change the email template for the order confirmation of a food order. With the final stage of

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

A Business Information System

Framework for Restaurants

Thomas Slinger

Computing for Business

2010 / 2011

Summary

Table of Contents

1. The Problem Domain ...1

2. Background Research ...3

3. Analysis...14

4. Design ...18

5. Initial Development Iteration ...27

6. Second Development Iteration...32

7. Third Development Iteration...37

8. Project Evaluation ...43

References……….………..51

Appendices……….……….54

1. The Problem Domain

1.1 Aim

1.2 Objectives

1.3 Minimum Requirements

1.4 Criteria for Evaluation

1.5 Project Schedule

2. Background Research

2.1 Methodology

2.2 Implementation

2.3 Languages

2.4 Databases

2.5 Development Method

2.6 Content Management Systems

2.7 Features

2.8 Usability

2.9 SEO

2.10 Server

3. Analysis

3.1 Interview

3.2 Existing Systems

3.21 Carts

3.22 Summary

3.3 Users

3.4 Requirements

3.5 Validated / Integrity

3.6 Compatibility

4. Design

4.1 Structure

Homepage

Food

Gallery

Contact

Reservations

Opening hours

Manager Interface

Configuration

Pages

Users

Menu

Management

Gallery

Newsletter

Reservations

Kitchen

Chef Interface

Catalogue

Checkout / Cart

Orders

Catalogue

Supplier Interface

Orders

4.2 Layout Design

4.3 Database Design

4.4 Iteration Schedule

4.5 Client Feedback

5. Initial Development Iteration

5.1 Website Layout

5.2 Manager Interface Layout

5.3 Configuration

5.4 Users

5.5 Pages

5.6 Client Feedback