Real-Time Restuarant Booking

N.Tait [Software Engineering - 2000/01]

Stop Press: Final Report

http://www.mycgiserver.com/~neil_tait [Up-to-the-minute updates]
Demo: [http://62.31.70.95:7001]

The aim of this project is to supply a restaurant table booking system that will support multiple restaurants and allow customers to book tables on-line. The restaurants will book tables through terminals located in the restaurants, and customers will book via a graphical interface on the World Wide Web. The system will compare the levels of trade against predefined criteria, and offer customers incentives to visit the quieter outlets. The criteria and incentives may be changed at any time by the restaurant staff.

"We could conceivably put a company out of business with a bug in a spreadsheet, database, or word processor."

Chris Mason, Microsoft.

The system must provide safeguards against malicious use, in that it must not be possible for someone to book up all the tables at once. The system should also be able to monitor use and signal an alert in the event or unusual activity. A variety of management reports will be available from the terminals in the restaurants. These will be based on historical information in the database.

Needs Addressed

This type of system could be applied to a wide variety of business areas as the shared database of bookings is used to offer supply and demand based discounts to customers. Many businesses could benefit from being able to offer customers incentives to trade at their quietest times, however cannot always predict exactly when business will be quiet. Further, by supporting multiple outlets the system adds the additional element of distributing peak trade over several sites. The data that is collected in the course of the systems operations will be able to provide historical and predictive reports on trade levels. In turn these reports can be used to fine-tune the incentives given to customers in order to maximise the systems effectiveness.

Goals

The ultimate goal of this project is to produce a fully operational software system using a structured approach to software engineering. This can be broken down into the following areas:

	Plan and control the project through a Project Plan
	Clearly define the systems requirements through proven methodologies
	Designing a workable software plan based on the Requirements Analysis Time

Constraints

This project must be completed by the end of semester 2, which allows approximately 30 weeks.

Deliverables

	Project Plan
	Requirements Gathering and Analysis Documents
	Software Design Documents
	Testing Plan
	Fully tested and implemented software
	User manual
	Technical manual Project Organisation

Project Objectives

The objective of this project is to produce a fully operational software system using a structured approach to software engineering. This can be broken down into the following areas:

	Plan and control the project through a Project Plan
	Clearly define the systems requirements through proven methodologies
	Designing a workable software plan based on the Requirements Analysis
	Separating the design from the implementation language
	Fully tested and implemented software Utilise a structured testing plan
	Ensure that the software will be maintainable

Project Controls

Formal control methods will be used to monitor the progress of the Project. Weekly reports to the Project Supervisor will be used to track the Project against the progress set out in the Project Plan. A Project Review will take place approximately halfway through the time allotted to the Project, including the Project Supervisor and the Second Marker. This meeting will be used to establish that the Project is under control.

Risk Management

The main risks to the success of the Project are detailed below alongside the contingency plans for each:

Unavailable or Unsuitable Server Technologies
In order to provide a central database of booking information the system will need access to a database server. Napier University does have a server, which has been used by students in the past for projects that had similar requirements, however it cannot be assumed that these resources will fit the exact requirements of the Project. Therefore as contingency, commercially available facilities must be considered in order to guarantee the availability of the required facilities - despite the costs this may incur.

Implementation Difficulties
Since the design of the system is separate from any implementation languages, the most suitable can be chosen to implement the systems components. This may well involve using programming languages that have not been covered as part of the BEng Software Engineering course. This could prove serious problems at the implementation stages therefore there must be substantial extra time allocated during the implementation stages, to allow for learning new languages. As a contingency plan to counter the possibility of severe implementation problems, a staged delivery life cycle model will be used. The system will be broken into smaller deliverable components during the project plan and the completion of each will represent a milestone in the project. Therefore, should the worst case happen and an area of the implementation fail completely, at least certain predefined components will delivered complete and with technical documentation.

Technical Processes

As stated above the life cycle model of this project will be that of staged delivery, allowing the progress of the project to be monitored better. The requirements gathering phase will involve interviews with the target users of the system, restaurant staff & managers and potential users of the web site. The Use Case Development methodology will be used at this stage and will tested with Scenarios. These Scenarios will then provide input to the Requirements Analysis and in turn, to the initial design phase. An Object Oriented approach to the design will be used, with the Scenarios developed in Requirements Analysis used to identify potential Classes and Attributes. These will be modelled using the Unified Modelling Language and Sequence Diagrams. The various components of the system will then be implemented as per the design documentation, starting with the most central component and building more functionality as each further component is implemented. This process will involve iteration back to the design and the requirements stages, and will include aspects from the testing schedule. Work Packages & Schedule The Top Down Approach was used to create the Work Breakdown Schedule for this project with the implementation stage broken down into three stages, to reflect the staged delivery of the system.

Work Breakdown Schedule

1.0 Concept
1.1 Create report on previous and existing systems
1.2 Gather user requirements
1.2.1 Intital Interview with Paul Duncan
1.2.2 Create Requirements Definition
1.2.3 Review with end users
1.2.4 Report
1.3 Define Specific Requirements
1.3.1 Create Use Cases
1.3.2 Create Scenarios
1.3.3 Test Use Cases with Scenarios
1.4 Review Risks
1.4.1 Risk Evaluation Report
1.4.2 Interview with Paul Duncan
1.4.3 Contingency Report
1.5 Project Plan
1.5.1 Work Breakdown Schedule
1.5.2 Create Gantt Chart
1.5.3 Program Evaluation and Review Technique
1.6 Review Project Plan with Project Supervisor
1.7 Write up Project Plan in Dissertation
2.0 Design
2.1 Identify candidate Classes and Properties from Scenarios
2.2 Create Unified Modelling Language Diagrams
2.2.1 Create Sequence diagram for Staff System
2.2.2 Create Collaboration diagram for Staff System
2.2.3 Create Sequence diagram for Web System
2.2.4 Create Collaboration diagram for Staff System
2.3 Create Entity Relationship Diagrams
2.4 Review Design Documents with Project Supervisor
2.5 Write up Design Documents in Dissertation
3.0 Implementation
3.1 Database System
3.1.1 Select suitable database system
3.1.2 Implement database tables
3.2 Staff System
3.2.1 Review available programming languages
3.2.2 Select programming language
3.2.3 Design prototype user interface
3.2.3.1 Evaluate interface with users
3.2.3.2 Review
3.2.4 Create database connection
3.2.5 Implement Staff System
3.3 Web System
3.3.1 Review available technologies
3.3.2 Select implementation technology
3.3.3 Design interface
3.3.4 Evaluate with Paul Duncan
3.3.5 Review
3.3.6 Connect to database
3.3.7 Implement Web System
3.4 Review implementation with Project Supervisor
3.5 Report on Implementation in Dissertation
4.0 Testing
4.1 Individual Packages
4.1.1 Test Database System
4.1.2 Test Staff System
4.1.3 Test Web System
4.2 Integration Tests
4.3 Concurrency Tests
4.4 Review tests with Project Supervisor
4.5 Report on Testing in Dissertation
5.0 Documentation
5.1 Create the User Guide
5.1.1 Review with Paul Duncan
5.2 Create the Technical & Maintainance Guide
5.3 Review the documentation with Project Supervisor
5.4 Add Documentation to Dissertation
6.0 Closing Processes
6.1 Create Presentation Poster
6.2 Demonstrate System & poster
6.3 Submit Project & Dissertation

Up-to-date information

WWW page

Chapters

Interim report.