PROJECT REPORT ON FAST-FOOD MANAGEMENT SYSTEM

SUBMITTED BY: ----------------------------CHAPTER 1 DEFINITION OF THE PROJECT INTRODUCTION: The project named Fast Food Automation has been prepared by the programmer, keeping in view the objective to make sure that all the needs of a Fast Food Centre should be taken care of. The Objective of creating the project is to make whole of the manual work of the restaurant such as Adding of a new product to the existing menu of products of the restaurant, Selling of a product to the customer of the shop, maintaining a list of products available at the library, preparing a bill for the products purchased by the customer etc. fully computerized. The Scope of the project named Fast Food restaurant is very wide. The programmer has prepared the project in such a manner that it can fulfill the needs of any Fast Food restaurant be it be very small or very big. The project can handle large number of customers at the same time. The user can add any number of products to the existing list of products, and can maintain a long list of products available with the restaurant without any difficulty. Products can be sold to the customers and the bill can be generated for the products sold to the customer. The software provides the scope for editing the details of products available at the restaurant. The software also provides the scope for adding a new product, and also modifying and deleting the existing products. It is very important for creating a successful and robust project that the problem or need of the client for which the project has to be developed should be clearly defined to the programmer. Unless, the programmer does not clearly understand the problem for the solution of which the project is to develop, he/she cannot develop successful and bugs free software. Hence,

relating to our project named Fast Food Automation, the problem for the solution of which the project has been developed is that of turning a big Fast Food Restaurant into a fully computerized one. CHAPTER - 2 FEASIBILITY STUDY Feasibility is the determination of whether or not the project at hand is worthwhile. The process followed in making this determination is called a feasibility study. Feasibility study determines whether a project can and should be done. 1. ECONOMIC FEASIBILITY: Economic analysis is the most frequently used technique for evaluating the effectiveness of a proposed system. More commonly known as cost / benefit analysis; in this procedure we determine the benefits and savings that are expected from a proposed system and compare them with costs. We found the benefits outweigh the costs; we take a decision to design and implement the new proposed system. It is very essential to ascertain the cost, which is to incur for developing the project, before starting the development of the project. If the benefit, which is to be accrued by developing the software, exceeds the cost to be incurred for developing the project by a fair amount of margin, then only the software should be developed. The process of cost and benefit analysis is not only limited prior to the time period of development of the project, but this process is a continuous process, and it keeps on going during the entire life cycle of the software. ANALYSIS OF COST: The programmer has done the analysis of cost of the project named FAST-FOOD MANAGEMENT in a very effective manner. According to the programmer, the total cost involved in the development and implementation of the software at the client site would be around Rs. 50000. This is so, as the Fast-Food Management is manual, a computer system is to be purchased to implement the project

at the Restaurant. The computer system would cost around Rs.50000, the cost involved in the development of the project would be around Rs.10000, the cost involved in the purchase of software required for implementing the project would be around Rs.5000, and above all the cost of training the manager to use the software is around Rs.5000 as the manager is not familiar with computers. ANALYSIS OF BENEFIT: As it is necessary to do cost analysis of the developed project, it is also very essential to do benefit analysis along with it. The programmer has done the analysis of the benefit arising from the use of the software named Fast-Food Management in a very effective way. The points which the programmer has kept in mind while performing the task of benefit analysis of the software are as follows: (i) Stationery Cost: The use of stationery in the day-to-day functioning of the restaurant is on a large scale. Thus, the cost of purchasing the stationery for the restaurant is also very high. But, since after the implementation of software it would become fully computerized, this step would save a big amount of money, which is previously used for purchasing the stationery for the restaurant. Now, all the work for which a large amount of stationery was being used previously can now be done on the computer.
(ii)

Manager Assistants Salary: In a restaurant, as there are number of activities involved in the day-to-day working, the workload becomes so much that the owner of the restaurant has to keep two or more assistants along with the Manager. This step increases the financial burden of the owner. Now, the owner has to pay the salary of assistants along with the Managers salary. But, since after the implementation of the software, the whole of the work, which is previously spread over large number of files, becomes computerized and centralized

to a single computer, the work can now be handled by a single person thus saving the cost of employing the manager assistants. Thus, by doing the cost and benefit analysis of the software, we find that there are more benefits arising by using the software as compared to the cost involved in the development and implementation of the software.

2.

TECHNICAL FEASIBILITY: This is concerned with specifying equipment and software that will

successfully satisfy the user requirement. The technical needs of the system may vary considerably, but might include: The facility to produce outputs in a given time. Response time under certain conditions. Ability to process a certain volume of transaction at a particular speed. Facility to communicate data to distant location. After examining technical feasibility, we give more importance to the configuration of the system than the actual make of hardware. The configuration gives the complete picture about the system's requirements: Twenty to thirty workstations are required; these units should be interconnected through LAN so that they could operate and communicate smoothly. They should have enough speeds of input and output to achieve a particular quality of printing. 3. OPERATIONAL FEASIBILITY: -

It is mainly related to human organizational and political aspects. The points to be considered are:

What changes will be brought with the system? What organizational structures are disturbed? What new skills will be required? Do the existing staff members have these skills? If not, can they be trained in due course of time? Generally project will not be rejected simply because of

operational infeasibility but such considerations are likely to critically affect the nature and scope of the eventual recommendations. For operational feasibility study we appointed a small group of people who are familiar with information system techniques, who understand the parts of the business that are relevant to the project and are skilled in system analysis and design process.

CHAPTER - 3 ANALYSIS 1: REQUIREMENT SPECIFICATIONS: -

The analysis phase is a problem-solving phase. The problem is that in manual restaurant record keeping system, excessive staff employment is required, extremely time consuming process is involved, inconveniences to both customers as well as to the manager. So, while analyzing I found many requirements expected from the system like: - to save time of both the manager as well as the customer of the restaurant, to perform automatic calculation of bill according to the purchased made by the customer. To reduce the whole paper work involved in restaurant, which otherwise without computerization would very tedious to maintain and keeping it update. To make easy work procedure which otherwise monotonous and tedious and involves at least two staff members, now can be managed and handled by only one person. In the Fast-Food MANAGEMENT SYSTEM project, there are five options such as: 1)

Purchase Menu: Purchase menu is the first option for the user in our project named Fast Food Automation. Under this option, the customer can purchase any item of his/her choice from the restaurant by placing an order with the user of the software.

2)

See Menu: See Menu is the second option for the user in our project named Fast Food Automation. Under this option, the user can maintain a list of products available with the restaurant. The user can show this list of products to the customer on request and on the basis of it the customer can make purchase of the products of his/her choice from the list of products available with the restaurant.

3)

Edit Menu: The Edit Menu consists of three options for making it easy for the user to use the software, these options are as follows: -

(a)

Adding a Product: Using this option the user can add a new product to the

existing basket of the products with the restaurant. The list of products goes on updating as the user is adding new products. (b) Modifying a Product: Using this option the user can modify the details of the existing products available with the restaurant. (c) Deleting a Product: Using this option, the user can delete a product from the list of existing products available with the restaurant. This option helps user in maintaining a fair list of items available with the restaurant. 4) Total Bill: This menu is the fourth option in the software. Using this option, the user can generate a bill of the total amount of items purchased by the customer from the restaurant. This option minimizes the risk of less or wrong collection of amount from the customer as this option prepares a fair bill for the items purchased by the customer. 5) Quit: This is the last option provided to the user. Using this option, as the name of the option itself suggests the user can quit the software safely on a click of a mouse or by pressing a key from the keyboard after completing his/her work. 2: REQUIREMENT ANALYSIS: A software project is initiated by the clients need. In the beginning these needs are in the minds of various people in the client organization. The requirement analyst has to identify the requirement by talking to these people and understanding their needs.

Hence identifying requirements necessarily involves a specifying what some people have in their minds. As the information in their minds by nature is not formally stated or organized, the input to the software requirement specification is inherently informal and imprecise, and it is likely to incomplete when inputs from multiple people are to be gather, as is often the case these inputs are likely to be inconsistent as well. Regardless of how the requirement process precedes it

ultimately ends with the software requirement specification. (a) PROBLEM ANALYSIS: In this project we have tried to simulate the functioning of fastfood restaurant using C++. This system automates the process of fast-food restaurant. The system allows user to add items into the system and provide list of all items in the system. The system also allows user to modify and delete the items into the system. The system also allow user to purchase items form the restaurant and generates bills. (b) PROPOSED SYSTEM ANALYSIS: In this system Analysis, we have carefully study all the requirements of a fast food restaurant and the system is designed in such a manner so the system should be user friendly. (c) ADVANTAGES OF THE PROJECT: This project on fast food automation system tries to provide some amount of automation in fast food restaurant system. The objective of the project is to help restaurant in making their business more efficient. It is also believed that automated system might be an added attraction for their potential customers. It will also show the attitute of the management that they are aware to the newly introduced technologies and ready to adopt them.

The system provides a very good user interface to make the system user friendly. The system also provides features to gracefully come out from the system at any time to the main menu and select any other game or can exit from the system. CHAPTER 4 SYSTEM DESIGN FLOW CHARTS

Star t
A Purchase Enter Item Code Display List of All Items Is Valid Code? Edit Yes No B A

Display List of record Retrieve All billsfrom file produced Enter Quantity Exit Calculate Fees

Return

Add Items

Modify Items C Delete Enter Items Information

Exit Save Reco rd Yes Save Record into file No

Return

Enter Items Number E

Enter Items Foun Number d? Yes Fou Display Details of nd?item Yes Display Details of Modif item y? Yes Delet e? Modify Existing record Yes Delete Existing Save record Record No Display Error Message No Display Error Message

Return Return

DFD OF THE PROJECT

Fast Food

List of Items

Purchas e Items

Customers Bill Paid Purchas e Items

E-R DIAGRAM

Dat e

Total BILLS

Quant ity

Cost

Price

OF Cost Item Name

ITEMS

Item code

Price

Item Code

TESTING Testing is major quality control measure used during software development. Its basic function is to detect errors in the software. During requirements analysis and design the output is a document that is usually textual and non-executable after the coding phase, computer programs are available that can be executed for testing purposes. This implies that testing not only has to uncover errors introduced during coding, but also errors introduced during the previous phases. Thus the goal of testing is to uncover requirement, design and coding errors in the programs. Consequently, different levels of testing are used.

The stating point of testing is Unit Testing. In this, a module is tested separately and is often performed by the coder himself simultaneously along with the coding of the module. The purpose is to exercise the different parts of the module code to detect coding errors. After this, the modules are gradually integrated into sub system, which are then integrated eventually from the entire system. During integration of modules, integration testing is performed to detect design errors by focusing on testing the interconnection between modules. After the system is put together, system testing is performed. Here the system is tested against system requirements to see if all the requirements are met and if the system performs as specified by the requirements. Finally, acceptance testing is performed to demonstrate to the client, on the real life data of the client, the operation of the system. Testing is an extremely critical and time-consuming activity. It requires proper planning of the overall testing processes. Frequently the testing process start with a test plan that identifies all the testing related activities that must be performed and a specifies the schedule allocates the resources, and specifies guidelines for testing. The test plan specifies conditions that should be tested, different units to be tested, and the manner in which the modules will be integrated together. Then for different test units, a test case specification document is produces, which lists all the different test cases, together with expected outputs. During the testing of the unit, the specified test cases are executed and the actual result compared with the expected outputs. The final output of the testing phase is the Test Report and the Error Report, or a set of reports (one for each unit tested). Each test report contains the set of test cases and the result of executing the code with these test cases. The error report describes the error encountered and the action taken to remove the errors.

Test Plan The test plan defines the testing necessary to establish quality for the system. If the system passes all tests in the test plan, then it is declared to be complete. If the system does pass all test then it is considered to be of high quality. The more complete the coverage of the system, the higher is the confidence in the system: hence the system's quality rises. The test plan could be considered as part of the design, which is the position taken here, or it could be considered as the first accomplishment in the testing phase. One of the goals of the design phase, is to establish a plan to complete the system, thus it is very natural to include the test plan. Also the trade-offs between alternative architectures can be influenced by differences in their test plans. One single test will exercise only a portion of the system. The coverage of the test is the percentage of the system exercised by the test. The coverage of a suite of tests is the union of the coverage of each individual test in the suite. Ideally, 100 percent test coverage of the entire system would be nice, but this is seldom achieved. Creating a test suite that covers 90 percent of the entire system is usually simple. Getting the last 10 percent requires significant amount of development time. For an example, consider the Basic Input/Output System (BIOS) built by IBM in the early 1980s as the foundation of the Disk Operating System (DOS) built by Microsoft. For performance reasons, the BIOS needed to be placed in a Read Only Memory (ROM) chip. Because the BIOS would be placed on a ROM, error patches would be nearly impossible. Thus 100% test coverage of the BIOS was dictated. The BIOS code itself was small, only a few thousand lines. Because the BIOS is asynchronous in nature, creating a test would first require an asynchronous environment to bring the system to a desired state, and

then an event would be needed to trigger a single test. Quickly, the test suite grew much larger than the BIOS. This introduced the problem of doing quality assurance on the test suite itself. Eventually, 100% coverage was reached but at a high cost. A more cost effective approach would be to place the BIOS on a Electronic Programmable ROM (EPROM) and ROM combination. Most of the BIOS would be on the ROM with error patches being placed on the EPROM. This is the approach that Apple took on the Macintosh. Usually, it is sufficient that the test suite includes all of the typical and a typical scenarios and need not cover the entire system. This gives reasonable quality for the investment of resources. All the typical and atypical scenarios need to be covered, but in doing so, not all threads of execution within the system may be covered. The system may contain internal branches, errors, or interrupts that will lead to untested threads of execution. Tools exists to measure code coverage. Systems are full of undiscovered bugs. The customer becomes a logical member of the testing team and bug fixes are pushed off to the next release. There are three basic approaches to testing. Functional Testing Structural Testing System Testing In Functional Testing the structure of the program is not considered. Test cases are decided solely on the basic of the requirements or a specification of the program or module, and the internals of the module or the program are not considered for selection of test cases. Due to its nature, functional testing is often called Black Box Testing . In Structural Testing, test cases are generated based on the actual code of the program or module to be tested. This structural

approach is sometimes called Glass Box Testing . To test the structure of the program a structural testing aims to achieve test cases that will force the desired converse of different structures. Various criteria have been proposed for this. Unlike the criteria for functional testing, which are frequently imprecise, the criteria for structural testing are generally quite precise as they are based upon program structures, which are formal and precise. System Testing: in this testing we check whether all the operations of the system is performing correctly or not. Here we take entire system as a unit and check the system for the correct functioning of all the modules and their specified interdependence.

SCOPE OF THE SYSTEM Scope of this project is to simulate the functioning of a fast food restaurant and provide facilities to the user to purchase items from the system and the system provides bill. The system is also able to add items into the system and modify add delete items details whenever required.