MANAGEMENT INFORMATION SYSTEM

TABLE OF CONTENT
1.0 INTRODUCTION 2
2.0 THE PROPOSED INFORMATION SYSTEM 4
2.1 User Interface
Design 6
3.0 ONLINE ORDERING SYSTEM 10
3.1 System
Interface 11
3.2 User Interface 11
3.3 Hardware
Interfaces 11
3.3 Software
Interfaces 12
3.4 Communication
Interface 12
3.5 Memory
Constraint 12
3.6 Site
adaptation requirements 12
3.7 Assumption and
constraint 12
4.0 SYSTEM FUNCIONALITY 13
5.0 STRATEGIC PLANNING 14
5.1 User
Requirement 14
5.1.1 Functional
Requirements 14
5.1.2 Non-functional
Requirement 15
5.2 Sytem
Requiremens 15
5.2.1 Software
Requirements 15
5.2.2 Hardware
Requirements 15
5.3 Planning
5.3.1 Time
Scheduling 16
5.3.2
Budget 17
5.4
Process Model 17
6.0 CONCLUSIONS 18
INTRODUCTION
INTRODUCTION

Thumbkin House Restaurant
(THR) is a western cuisine restaurant and halal family restaurant chain in
Malaysia. The chain is operated by THR Restaurants Sdn Bhd, a company
incorporated in Malaysia, which was established in June 2000.
Thumbkin House Restaurant
serves what it calls "east meet west cuisine" and original western
dishes.
With the
successful growth of THR in their domestic markets, they plan to spread the
culture of the Malaysian way of life into the internet market. Their slogan is
"when east meets west".
This paper
proposed on the additional design of a restaurant Information System (IS) that
could be used to improve the day-to-day operation at Thumbkin House Restaurant.
The main purpose of the system is to track food items stock level so that there
will never be "out of stock" problems and also to adopt online
ordering to reach more customers via food delivery service.
The overall goal
of the project was to create an application where both utility and usability
are addressed. In particular, the software should be easy to navigate and use
while providing basic restaurant management and security features.
In the
experience of the authors, the existing Information System software while
having reasonable utility features geared towards tracking money and profits,
seem to have a significant lack where intuitiveness and usability are
concerned. The Information system software has weak or non-existent real-time capabilities,
and in some cases, functionality needed for day to day operations are only
available for certain functions. This results in the undesirable situation
where food stock level cannot be detected. These problems may have resulted
from the system lack of domain knowledge or from a lack of user involvement in
the design process.
The propose
Information System includes creating and deleting orders, adding and removing
items from an order and closing orders. Orders should also be stored in the
database to be used to calculate total sales. Inventory management includes
adding new products, deleting products and updating products and resources.
The software is
responsible for a number of other functions. Menu items must be added, edited,
and deleted from the menu item database. Items that can be ordered must be able
to be added and removed from an order. All employees must be able to clock in
and clock out. Servers must be able to do what all employees do as well as take
orders.
Reports that
should be generated include sales reports showing sales by food category and
the total sales from the start of the day. Orders should also be stored in the
database to be used to calculate total sales.
The
non-functional requirements of the project included creating an intuitive,
simple application that performs consistently. To achieve these goals the
project should make menus effortlessly navigable and group user interface (UI)
components in a manner that makes them easy to find. In addition, it was the
opinion of the development team that giving each employee the appropriate level
of access to resources was imperative for usability and security.
2.0 THE
PROPOSED INFORMATION SYSTEM
While it is
acknowledged that design is not always rational and while we do not expect any
silver bullet, in our experience, software design becomes better with practice
and experience. For this proposal, the design of the software included both
architectural and subsystem design. The architecture of software defines the
major software subsystems and the dependencies and interrelationships among
subsystems. Architectural styles define a vocabulary for different classes of
architectures. Examples of well-known architectural styles include
pipe-and-filter, shared repository and event driven. In this course, each
software development team was required to design the software using two
architectural. The architectural styles chosen by the restaurant management
team were the three-tiered layered architectural style and the
shared-repository style.

Figure 1: Shared Repository
Architecture
The shared
repository architectural style is shown in Figure 4. The design shows five
major subsystems interacting with a shared data store. While this design is
ideal for data driven applications that share a common database schema, it
constraints the evolution of the database as well as the data formats on the
individual subsystems. A layered architecture is shown in Figure 2.

Figure 2: Layered 3-Tier Architecture

Figure 3: Class Diagram
2.1 User
Interface Design
Because
of the nature of the proposal, an intuitive graphical user interface was
required. The user interface design in Figure 4 is the JAVA Swing equivalent of
the earlier design. There are a few alterations that had to be made. The
buttons on the far right side on each screen have been removed and put onto a
single menu accessible after login. On the first screen visible to the user we
have removed all buttons except the sign in button. The functionality that was
originally on this particular screen has been moved to subsequent menus and
screens. In addition, we have added the clock functionality to every screen in
the program so that no matter which screen an employee is viewing, he or she
will be able to keep track of time.

Figure 4: First user screen
The
next screen (Figure 5) is where the employee can choose which tasks he or she
wants to do. Options that appear grayed out are not available for the user that
has logged in. Managers have all options, servers have all options except the
management button, and finally normal employee are only granted access to
system to log in and log out. All orders that are currently “owned” by this
particular employee are listed in the list above the “add” and “edit” buttons.
Below are three screenshots that show this.

Figure 5: Employee Task Menu
Management
menu functions include the ability to add and remove employees as well as
items. Although our group did not implement report generation, report
generation would be completed from the management menu. Below are screenshots
of the management menu and the various submenus for editing employees and
items.

Figure 6: Ordering menu

Figure 7: Edit Item Menu

Figure 8: Item Type Selection
The ordering
screen allows a server or manager to create an order by selecting from four
lists that represent the four types of food: beverage, appetizer, entrée, or
dessert. When the item is selected, pressing the add button below the list adds
the item to a fifth list which is the actual customer order. When the screen is
exited, the information is stored in the database. All the screens are
periodically updated with the current contents of the database.
3.0 ONLINE
ORDERING SYSTEM
The Online Sales System is not a part of a
large system. It is a standalone web application which will digitalize the
current THR Information System processes. It is being claimed by THR
Information System that it is very hard to work with existing mean of handling
orders which is based on paper. Therefore, it is good for THR Information
System to have a digitalized system through which they can search and process
orders without hassling through the piles of documents. This will also help the
staff to access the information remotely. Thus, the solution to be developed
should be a web based application instead of desktop application. The figure 1
depicts a block diagram showing major interconnections of web-based system.

Figure 9: Deployment model of the new online ordering
system.
3.1 System
Interfaces
There
are three different types of users who are interacting with the system
interface.
·
Customer
·
Account manager
·
Finance manager
Customer
of THR shall be able to order, search, track and edit order information, in
addition to this he can cancel an order under certain conditions. On the other
hand the system shall let “Account Manager” to approve/reject an order, add new
suppliers, and products. The “Finance Manager” shall be able to handle
financial transactions and logistic support like shipment.
In
future the system shall be able to let Shipment Company, bank and supplier to
interact directly with the system.
3.1 User
Interface
The
user interaction with THR will be through the website, initially. In future,
according to the business need the company would like to have a mobile software
version as well. This interface has to be “user friendly” and intuitive so that
the user won’t get lost or gets frustrated. Moreover, the web’s standards
concerning graphical user interface will be respected.
3.2 Hardware
Interfaces
The
hardware recommended is a computer or any other terminal such as PDA,
Smartphone, iPhone, iPad, and cellular phone which supports a web browser.
3.3 Software
Interfaces
The
system must be designed in a way that it can interact with multiple data
storage locations. The web interface must be written in a web standard language
such as Asp.Net, php, and etc.
3.4 Communication
Interface
The
THR system should support commonly used web browsers such as Internet Explorer,
Firefox, Google Chrome, Safari, Opera and Netscape. More over the system shall
provide support for mobile devices such as smartphone, iPhone, and PDAs; and
iPad.
3.5 Memory
Constrains
No
memory constrains were identified.
3.6 Site
adaptation requirements
Since
the system is not an up gradation of any existing system, therefore there is no
adaptation required.
3.7 Assumption
and Constrains
The
following constrains were identified for THR
·
Internet connection for web server shall be
available 24 hours a day and 7 days a week.
·
In case of downtime the communication shall not
affect the user.
·
Continuous downtime shall not exceed a day.
·
All the payments are handled by the Bank, which
is not the part of the system
·
The system shall support at least 600 users
simultaneously.
·
Data encryption shall be used for sensitive data
sharing between user and the system.
·
The system shall support its deployment at more
than one geographical location, if needed.
·
It should be possible/easy to add new
functionality into the system without affecting it
·
The system shall accept customer order in
different formats such as in XML, PDF, and JPEG (scanned paper) other than
through company’s website
4.0 SYSTEM
FUNCTIONALITY
The project
features discussed in this proposal are based upon three modules, which are
taken into consideration, namely Customer, Account Management and Financial
Management. Customer module will help in order booking, order inquiry, payment
delivery, shipment information, and etc. Account Management module is
responsible for create, viewing, confirming, and changing information related
to orders and customer. Whereas the Finance Management will deal with the
generation, validation, and confirmation of pro-forma invoice and customer
invoice; and will manage customer payments.

Figure 10: System functionality
5.0 STRATEGIC PLANNING
5.1 User Requirements
The
system will be designed to be user friendly. The user friendly and interactive interfaces
design helps to achieve this by enabling customers to easily browse through the
menus place orders with just a few clicks and also allows restaurant employees
to quickly go through the orders as they are placed and produce the necessary
items with minimal delay and confusion. The system will be simple to use.
5.1.1 Functional
requirements
Functional requirements define the
capabilities and functions that a system must be able to perform successfully.
The functional requirements of this online ordering system include:
·
The
system shall enable the customer to view the products menu, create an account,
login to the system and place an order.
·
The
customer shall specify whether the order is to be picked up or delivered
·
The
system shall display the food items ordered, the individual food item prices
and the payment amount calculated.
·
The
system shall prompt customer to confirm the meal order.
·
The
system shall provide visual confirmation of the order placement
·
The
system shall enable the manager to view, create, edit and delete food category
and descriptions
·
The
system shall allow confirmation of pending orders.
·
The
system shall allow generation of sales report for the orders made.
·
The
system shall allow the manager to update additional information (description,
photo, ingredients etc.) for a given food item.
·
The
system shall allow the manager to update price for a given food item.
5.1.2 Non-functional requirements
A non-functional requirement is a
requirement that specifies criteria that can be used to judge the operation of
a system, rather than specific behaviors. Some of the non-functional
requirements include:
·
The
should be sufficient network bandwidth
·
Backup-
provision for data backup
·
Maintainability-
easy to maintain
·
Performance/
response time- fast response
·
Usability
by target user community- easy to use
·
Expandability-
needs to be future proof or upgradable
·
Safety-
should be safe to use
5.2 System
requirements
These consist of the hardware and
software components of a computer system that are required to install in order
to use the software efficiently.
5.2.1 Software requirements
·
Operating
system: Windows XP / windows 7
·
Technology : PHP
·
Database : MySQL
·
Tool : Dreamweaver
·
Antivirus
software
·
Backup
& Data Recovery software
5.2.2 Hardware requirements
·
Processor: Intel dual core or above
·
Processor Speed:1.0GHZ or above
·
RAM: 1 GB RAM or above
·
Hard Disk: 20 GB hard disk or above
·
Printer for printing reports
·
Uninterruptible power supply to
ensure a constant access of data.
·
USB flash disk( At least 2GB)
5.3 Planning
5.3.1
Time scheduling
Task Name
|
Start
|
End
|
Duration (days)
|
|
|
|
|
RESEARCH AND DATA COLLECTION
|
16-01-15
|
21-01-15
|
20
|
PROPOSAL WRITING
|
22-01-15
|
23-01-15
|
5
|
PROPOSAL APPROVAL AND PRESENTATION
|
22-01-15
|
28-01-15
|
3
|
CODING DESIGN AND TESTING
|
06-02-15
|
29-01-15
|
14
|
DEPLOYMENT AND DOCUMENTATION
|
21-02-15
|
04-03-15
|
11
|
PROJECT PRESENTATION
|
05-03-15
|
08-03-15
|
3
|

5.3.2
Budget
ITEM
DESCRIPTION
|
AMOUNT (KSH)
|
XAMPP
SOFTWARE
|
FREE
|
DREAMWEAVER
|
FREE
|
LAPTOP/
DESKTOP
|
60000
|
DATA
COLLECTION
|
1000
|
FLASH
DISK
|
500
|
STATIONERY
AND PRINTING
|
400
|
HOSTING
CHARGES
|
10,000
per year
|
MISCELLANEOUS
COST
|
4000
|
TOTAL:
|
65,900
|
5.4 Process Model
For this project the propose plan is
to use waterfall as a process model. The waterfall model is a sequential design
process, often used in software development processes, in which progress is
seen as flowing steadily downwards (like a waterfall) through the phases of
Conception, Initiation, Analysis, Design, Construction, Testing and
Maintenance.

6.0 CONCLUSIONS
At any point of
the day, a computerized management information system can instantly tell you
how many of a particular product has been sold today (or last week, or last
month) how much money you have in your cash drawer, and how much of that money
is profit. Detailed sales reports make it much easier for you to keep the right
stock on hand. Track your remaining inventory, spot sales trends, and use
historical data to better forecast your needs. Often, the software can alert
you to reorder when stocks run low. Many store owners think they know exactly
what trends affect them find a couple of surprises once they have this data.
The wrong system, however, can be
waste of money and a source of ongoing frustration. Switching from a
traditional cash register to a computerized management information system can
be difficult- there are many factors to consider and some pitfalls to avoid.
However the return on investment and benefits to your business can really make
it worth your time and effort. As a result, the need for a computerized
management information system cannot be overemphasized.
ATTACHMENT
REFERENCES
Ansel,
D., & Dyer, C. (1999).A framework for restaurant information technology.
Cornell Hotel and Restaurant Administration Quarterly, 40, (3), 74-84.
David,
F. R. (2009). Strategic management: concepts and cases (11th ed., Rev.).
Upper Saddle River, NJ: Pearson Education.
K.
Kamarudin, et al., “The Applictaion of Wireless Food Ordering System”, MASAUM
Journal of Computing, vol. 1,pp. 178-184, 2009.
Flyvbjerg,
B.(2006). “Distribution and Management Information System: Getting Risks
Right.”Flybourge. NLK Press and Co
Heerkens,
G.(2001).Effective Sales of Point Systems (The Briefcase Book Series). McGraw-Hill
New York
J.
Purnama, et al.“Application of Order
Management System in Restaurants”, Seminar Nasional Aplikasi Teknologi
Informasi 2007, Yogyakarta, 16 June
2007 (SNATI 2007) ISSN: 1907-5022.
K.
Kamarudin, et al., “The Applictaion of
Wireless Food Ordering System”, MASAUM Journal of Computing, vol. 1,pp.
178-184, 2009.
T.P.
Liang, et al., ”Adoption of mobile
technology in business- a fit viability model”, Industrial Management &
data systems, vol . 107, pp. 1154-1169, 2007.
Whitty,
S.J. and Schulz, M.F. (2007).The Impact of Puritan Ideology On Aspects Of
Management. International Journal of Sales Management
Whitty,
S. and Jonathan A. (2005).A Emetic Paradigm of Sales Management.
International Journal of Project Management.
Woolf,
M. (2007). Faster Construction Management Information System with CPM
Scheduling, 1st,McGraw-Hill. California USA.Cornell Hotel and Restaurant
Administration Quarterly, 44, (2), 94-105.
Yang,
H. O. & Fu, H.W. (2007). Creating and Sustaining Competitive Advantages
of Hospitality Industry.