Bangladesh University of Business and Technology

(BUBT)

A PROJECT REPORT
ON
“M ESS M ANAGEMENT S YSTEM ”

BACHELOR OF SCIENCE
IN
COMPUTER SCIENCE & ENGINEERING(CSE)

Submitted To:
Md. Abdullah Al Mamun
Lecturer, Dept of CSE
(BUBT)

Submitted By:
Dipto Ranjan Mondol ID:16173103067
Tanmay Ghosh ID:16173103061
Md.Hadiuzzaman Himal ID:16173103059
Intake:36th
Program: DEPT. OF CSE

Date Of Submission:14.01.2020

1
 Acknowledgements

It is a great a pleasure to present this report on the project named Mess Manage-
ment System undertaken by us as part of our B.Sc. in (CSE) curriculum.

It is pleasure that we find ourselves penning down these lines to express my sin-
cere thanks to the people who helped me along the way in completing our project. i
find inadequate words to express my sincere gratitude towards them.

First and foremost we would like to express our gratitude towards our training
guide Md. Abdullah Al Mamun for placing complete faith and confidence in our
ability to carry out this project and for providing us his time,inspiration,encouragement,
help, valuable guidance. without the sincere and honest guidance of our respect
project guide we would have not been to reach the present stage.

we would like to express our sincere thanks to our head of Department Dr. M. Ameer Ali
and my internal guide who gave me an opportunity to undertake such a great challenging and
innovative work. i am grateful to them for their guidance,encouragement, understanding and
insightful in the development process. We are also thankful to entire staff of BUBT for their
constant encouragement,suggestions and moral support throughout the duration of my project.

Last but not the least we would like to mention here that we are greatly indebted
to each and everybody who has been associated with my project at any stage but
whose name does not find a place in this acknowledgement.

Best Regards

Dipto Ranjan Mondol

Tanmoy Ghosh
Md.Hadiuzzaman Himal
Contents

1 INTRODUCTION 2
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Objective of The Project . . . . . . . . . . . . . . . . . . . . . . . 3
1.4.1 Primary Objective . . . . . . . . . . . . . . . . . . . . . . 3
1.4.2 Secondary Objective . . . . . . . . . . . . . . . . . . . . . 3
1.5 Development Tools: . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.6 Functionalities: . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6.1 Administration Functionalities . . . . . . . . . . . . . . . . 4
1.6.2 End user Functionalities . . . . . . . . . . . . . . . . . . . 4

2 System Method 5
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Agile Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Agile Model Phases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1 Planning and Requirements Analysis. . . . . . . . . . . . . 6
2.3.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.3 Development and programming . . . . . . . . . . . . . . . 7
2.3.4 Unit Testing and . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.5 Deployment. . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 When to use Agile Model? . . . . . . . . . . . . . . . . . . . . . . 8
2.5 Agile Model Advantages . . . . . . . . . . . . . . . . . . . . . . . 8
2.6 Agile Model Disadvantages . . . . . . . . . . . . . . . . . . . . . . 9

3 Requirement Analysis 10
3.1 Requirements: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Reasons for Requirements . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Types of Requirements . . . . . . . . . . . . . . . . . . . . . . . . 10
 3.3.1 Business Requirements . . . . . . . . . . . . . . . . . . . . 10
3.3.2 Functional Requirements . . . . . . . . . . . . . . . . . . . 11
3.3.3 Non-Functional Requirements . . . . . . . . . . . . . . . . 11
3.3.4 User interface specification . . . . . . . . . . . . . . . . . . 11
3.4 Requirement Gathering . . . . . . . . . . . . . . . . . . . . . . . . 11
3.5 Requirement Gathering Techniques . . . . . . . . . . . . . . . . . 12
3.5.1 Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5.2 Questionnaires . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5.3 Workshops . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5.4 Role Playing . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5.5 Use Cases Scenarios . . . . . . . . . . . . . . . . . . . . . 13
3.5.6 Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.6 Questionaries Perspective Event Management System . . . . . . . 13
3.6.1 Closed-Ended Questions . . . . . . . . . . . . . . . . . . . 13
3.6.2 Open-Ended Questions . . . . . . . . . . . . . . . . . . . . 14

4 System Design 15
4.1 Database Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Front End Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.1 Home Page . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.2 Admin Login . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.3 user Registration . . . . . . . . . . . . . . . . . . . . . . . 19
4.3 Database Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.1 Registration Details . . . . . . . . . . . . . . . . . . . . . . 20
4.3.2 Admin Details . . . . . . . . . . . . . . . . . . . . . . . . 21

5 Tools and Technology used 22

5.1 HTML: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2 CSS: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.3 PHP: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.4 XAMPP: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6 Implementation and Testing 24

6.1 System Implementation . . . . . . . . . . . . . . . . . . . . . . . . 24
6.2 System Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

7 Conclusion 26
7.1 Limitations: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.2 Future Works : . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.3 Conclusion: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
 CHAPTER 1. INTRODUCTION

Chapter 1

INTRODUCTION

1.1 Introduction

For simplicity and better understanding of the mess manager. It would avoid confu-
sion and help operate the software easily. Also, such a software that is easy to use
will reduce the work of mess managers who still maintain all the logs in registers
and files. It would be of great benefit as all calculations would be done easily on the
click of a button.

1.2 Motivation

• Consisting of more than 10 members ,one of the most massive task of the mess
management to take care of the dining needs of its members.

• Here we are providing security,good environment,good foods.

• We are providing free Wi-Fi.

1.3 Features

We have so many features.Here are some features given billow:

• Registration page.

• Log in page.

• Admin change system.

• Admin can see user details.

• Monthly end system.

Department of CSE,BUBT 1 1
 CHAPTER 1. INTRODUCTION

• Payment system.

• Meals system.

• Update user data.

• User can see his details and can payment.

1.4 Objective of The Project

There are two types of objective.First one is primary objective and second one is
secondary objective.

1.4.1 Primary Objective

The primary objectives of the project are given below:

• To develop an application that manager can manage easily.

• To handle easily the mess members information.

• Manager can manage easily the hole system make it easy.

1.4.2 Secondary Objective

The Secondary objectives of the project are given below:

• To fulfill the requirement for Software Engineering project.

• To design,development,and maintenance of a software in discipline way.

1.5 Development Tools:

• Front-end:HTML,CSS

• Back-end:php.

• Database:MySQL.

• Server:Xampp.

2
 CHAPTER 1. INTRODUCTION

1.6 Functionalities:

To ensure that solve difficult problems by making the system should have the fol-
lowing functions:

1.6.1 Administration Functionalities

• Admin can add all information.

• Admin can add new member.

• Admin can edit,delete members information.

• Manage overall system.

1.6.2 End user Functionalities

• Members can see his all information.

• Members can payment.

3
 CHAPTER 2. SYSTEM METHOD

Chapter 2

System Method

2.1 Introduction

Agile SDLC model is a combination of iterative and incremental process models

with focus on process adaptability and customer satisfaction by rapid delivery of
working software product. Agile Methods break the product into small incremental
builds. These builds are provided in iterations. Each iteration typically lasts from
about one to three weeks. Every iteration involves cross functional teams working
simultaneously on various areas like

2.2 Agile Model

Agile model believes that every project needs to be handled differently and the ex-
isting methods need to be tailored to best suit the project requirements. In Agile, the
tasks are divided to time boxes (small time frames) to deliver specific features for a
release.
Iterative approach is taken and working software build is delivered after each
iteration. Each build is incremental in terms of features; the final build holds all the
features required by the customer.
Here is a graphical illustration of the Agile Model

Department of CSE,BUBT 4 4
 CHAPTER 2. SYSTEM METHOD

2.3 Agile Model Phases

• Planning and Requirements Analysis.

• Design.

• Development and programming.

• Unit Testing and

• Deployment.

2.3.1 Planning and Requirements Analysis.

Each software development life cycle model starts with the analysis, in which the
stakeholders of the process discuss the requirements to the final product. The goal
of this stage is the detailed definition of the system requirements. Besides, it is

5
 CHAPTER 2. SYSTEM METHOD

needed to make sure that all the process participants have clearly understood the
tasks and how every requirement is going to be implemented. Often, the discussion
involves the QA specialists who can interfere the process with additions even during
the development stage if it is necessary.

2.3.2 Design

At the second phase of the software development life cycle, the developers are actu-
ally designing the architecture. All the different technical questions that may appear
on this stage are discussed by all the stakeholders, including the customer. Also,
here are defined the technologies used in the project, team load, limitations, time
frames, and budget. The most appropriate project decisions are made according to
the defined requirements.

2.3.3 Development and programming

After the requirements approved, the process goes to the next stage actual develop-
ment. Programmers start here with the source code writing while keeping in mind
previously defined requirements. The system administrators adjust the software en-
vironment, front-end programmers develop the user interface of the program and the
logics for its interaction with the server. The programming by itself assumes four
stages

• Algorithm development

• Source code writing

• Compilation

• Testing and debugging

2.3.4 Unit Testing and

The testing phase includes the debugging process. All the code flaws missed during
the development are detected here, documented, and passed back to the developers to
fix. The testing process repeats until all the critical issues are removed and software
workflow is stable.

6
 CHAPTER 2. SYSTEM METHOD

2.3.5 Deployment.

When the program is finalized and has no critical issues it is time to launch it for
the end users. After the new program version release, the tech support team joins.
This department provides user feedback; consult and support users during the time
of exploitation. Moreover, the update of selected components is included in this
phase, to make sure, that the software is up-to-date and is invulnerable to a security
breach.

2.4 When to use Agile Model?

• When new changes need to be implemented. The freedom agile gives to change
is very important. New changes can be implemented at very little cost because
of the frequency of new increments that are produced.

• To implement a new feature the developers need to lose only the work of a few
days, or even only hours, to roll back and implement it.

• Unlike the waterfall model in agile model very limited planning is required to
get started with the project. Agile assumes that the end users needs are ever
changing in a dynamic business and IT world. Changes can be discussed and
features can be newly effected or removed based on feedback. This effectively
gives the customer the finished system they want or need.

• Both system developers and stakeholders alike, find they also get more free-
dom of time and options than if the software was developed in a more rigid
sequential way. Having options gives them the ability to leave important de-
cisions until more or better data or even entire hosting programs are available;
meaning the project can continue to move forward without fear of reaching a
sudden standstill.

2.5 Agile Model Advantages

The advantages of the Agile Model are as follows

• Is a very realistic approach to software development.

• Promotes teamwork and cross training.

• Functionality can be developed rapidly and demonstrated.

7
 CHAPTER 2. SYSTEM METHOD

• Resource requirements are minimum.

• Suitable for fixed or changing requirements

• Delivers early partial working solutions.

• Good model for environments that change steadily.

• Minimal rules, documentation easily employed.

• Enables concurrent development and delivery within an overall planned con-

text.

• Little or no planning required.

• Easy to manage.

• Gives flexibility to developers.

2.6 Agile Model Disadvantages

The disadvantages of the Agile Model are as follows

• Not suitable for handling complex dependencies.

• More risk of sustainability, maintainability and extensibility.

• An overall plan, an agile leader and agile PM practice is a must without which
it will not work.

• Strict delivery management dictates the scope, functionality to be delivered,

and adjustments to meet the deadlines.

• Depends heavily on customer interaction, so if customer is not clear, team can

be driven in the wrong direction.

• There is a very high individual dependency, since there is minimum documen-

tation generated.

• Transfer of technology to new team members may be quite challenging due to

lack of documentation.

8
 CHAPTER 3. REQUIREMENT ANALYSIS

Chapter 3

Requirement Analysis

3.1 Requirements:

Requirements management is the process of documenting, analyzing, tracing, pri-

oritizing and agreeing on requirements and then controlling change and communi-
cating to relevant stakeholders. It is a continuous process throughout a project. A
requirement is a capability to which a project outcome (product or service) should
conform.

3.2 Reasons for Requirements

requirements management is to ensure that an organization documents, verifies, and

meets the needs and expectations of its customers and internal or external stakehold-
ers.

3.3 Types of Requirements

The software requirements are description of features and functionalities of the tar-
get system. Requirements convey the expectations of users from the software prod-
uct. The requirements can be obvious or hidden, known or unknown, expected or
unexpected from clients point of view.There are some requirements given bellow:

3.3.1 Business Requirements

Business requirements, also known as stakeholder requirements specifications (StRS),

describe the characteristics of a proposed system from the viewpoint of the system’s
end user like a CONOPS. Products, systems, software, and processes are ways of

Department of CSE,BUBT 9 9
 CHAPTER 3. REQUIREMENT ANALYSIS

how to deliver, satisfy, or meet business requirements. Consequently, business re-

quirements are often discussed in the context of developing or procuring software or
other systems.

3.3.2 Functional Requirements

In software engineering and systems engineering, a functional requirement defines

a function of a system or its component, where a function is described as a specifi-
cation of behavior between outputs and inputs.
Functional requirements may involve calculations, technical details, data ma-
nipulation and processing, and other specific functionality that define what a system
is supposed to accomplish. Behavioral requirements describe all the cases where the
system uses the functional requirements, these are captured in use cases.

3.3.3 Non-Functional Requirements

In systems engineering and requirements engineering, a non-functional requirement

(NFR) is a requirement that specifies criteria that can be used to judge the operation
of a system, rather than specific behaviors. They are contrasted with functional
requirements that define specific behavior or functions

3.3.4 User interface specification

A user interface specification (UI specification) is a document that captures the de-
tails of the software user interface into a written document. The specification covers
all possible actions that an end user may perform and all visual, auditory and other
interaction elements.

3.4 Requirement Gathering

This section outlines some of key techniques and methods that can be employed
for gathering and capturing requirements on a project. It includes suggestions and
ideas for ways to best capture the different types of requirement (functional, system,
technical, etc.) during the gathering process.

10
 CHAPTER 3. REQUIREMENT ANALYSIS

3.5 Requirement Gathering Techniques

Techniques describe how tasks are performed under specific circumstances. A task
may have none or one or more related techniques. A technique should be related to
at least one task.
The following are some of the well-known requirements gathering techniques

3.5.1 Interviews

These are an invaluable tool at the beginning of the process for getting background
information on the business problems and understanding a current-world perspec-
tive of what the system being proposed needs to do. You need to make sure that
your interviews cover a diverse cross-section of different stakeholders, so that the
requirements are not skewed towards one particular function or area

3.5.2 Questionnaires

One of the challenges with interviews is that you will only get the information that
the person is consciously aware of. Sometimes there are latent requirements and
features that are better obtained through questionnaires. By using carefully chosen,
probing questions (based on the information captured in prior interviews), you can
drill-down on specific areas that the stakeholders don’t know are important, but can
be critical to the eventual design of the system.

3.5.3 Workshops

Once you have the broad set of potential requirements defined, you will need to
reconcile divergent opinions and contrasting views to ensure that the system will
meet the needs of all users and not just the most vocal group. Workshows are a
crucial tool that can be used to validate the initial requirements, generate additional
detail, gain consensus and capture the constraining assumptions.

3.5.4 Role Playing

In situations where the requirements depend heavily on different types of user, for-
mal role-playing (where different people take on the roles of different users in the
system/process) can be a good way of understanding how the different parts of the
system need to work to support the integrated processes (e.g in an ERP system).

11
 CHAPTER 3. REQUIREMENT ANALYSIS

3.5.5 Use Cases Scenarios

Once you have the high-level functional requirements defined, it is useful to develop
different use-cases and scenarios that can be used to validate the functionality in
different situations, and to discover any special exception or boundary cases that
need to be considered.

3.5.6 Prototyping

There is truth to the saying ”I don’t know what I want, but I know that I don’t want
that!”. Often stakeholders won’t have a clear idea about what the requirements are,
but if you put together several different prototypes of what the future could be, they
will know which parts they like. You can then synthesize the different favored parts
of the prototypes to reverse-engineer the requirements.

3.6 Questionaries Perspective Event Management System

There are two types of questionaries-Open-ended and Close-ended.Here we given

some example for our project based questions-

3.6.1 Closed-Ended Questions

1. Do you need any payment system?

• Yes.

• No.

2. Does this system is helpful?

• Yes.

• No.

3. Do you need sms system?

• Yes.

• No.

12
 CHAPTER 3. REQUIREMENT ANALYSIS

3.6.2 Open-Ended Questions

1.What type of payment method do you want?

2.What do you know about our system?
3.Do you have any suggest for improving this sight?
4. Which types of meals do you want?

13
 CHAPTER 4. SYSTEM DESIGN

Chapter 4

System Design

4.1 Database Design

Admin
Field Name Data Type Key
Id Int Primary Key
Name Varchar(20) -
Email Varchar(20) -
Address Varchar(20) -
Number Int -
Password Int -

Figure 4.1: Admin Table.

Member
Field Name Data Type Key
Id Int Primary Key
Name Varchar(20) -
Balance Int -
Email Varchar(20) -
Address Varchar(20) -
Number Int -
Password Int -
Meal Int -
Due Int -
Payment Int -

Figure 4.2: Member Table.

Department of CSE,BUBT 14 14
 CHAPTER 4. SYSTEM DESIGN

Payment
Field Name Data Type Key
Id Int Primary Key
Name Varchar(20) -
Pay Int -
Due Int -

Figure 4.3: Payment Table.

Meal
Field Name Data Type Key
Id Int Primary Key
Name Varchar(20) -
Total Meal Int -

Figure 4.4: Meal Table.

15
 CHAPTER 4. SYSTEM DESIGN

4.2 Front End Design

Front-end web development is the practice of converting data to a graphical inter-

face, through the use of HTML, CSS, and JavaScript, so that users can view and
interact with that data.

4.2.1 Home Page

16
 CHAPTER 4. SYSTEM DESIGN

4.2.2 Admin Login

17
 CHAPTER 4. SYSTEM DESIGN

4.2.3 user Registration

4.3 Database Design

Database design is the organization of data according to a database model. The

designer determines what data must be stored and how the data elements interrelate.
With this information, they can begin to fit the data to the database model. Database
management system manages the data accordingly.

18
 CHAPTER 4. SYSTEM DESIGN

4.3.1 Registration Details

19
 CHAPTER 4. SYSTEM DESIGN

4.3.2 Admin Details

20
 CHAPTER 5. TOOLS AND TECHNOLOGY USED

Chapter 5

Tools and Technology used

5.1 HTML:

Hypertext Markup Language (HTML) is the standard markup language for docu-
ments designed to be displayed in a web browser. It can be assisted by technologies
such as Cascading Style Sheets (CSS) and scripting languages such as JavaScript.
Web browsers receive HTML documents from a web server or from local stor-
age and render the documents into multimedia web pages. HTML describes the
structure of a web page semantically and originally included cues for the appearance
of the document.

5.2 CSS:

Cascading Style Sheets (CSS) is a style sheet language used for describing the pre-
sentation of a document written in a markup language like HTML. CSS is a corner-
stone technology of the World Wide Web, alongside HTML and JavaScript.
CSS is designed to enable the separation of presentation and content, including
layout, colors, and fonts.This separation can improve content accessibility, provide
more flexibility and control in the specification of presentation characteristics, en-
able multiple web pages to share formatting by specifying the relevant CSS in a
separate .css file, and reduce complexity and repetition in the structural content..

5.3 PHP:

PHP is a general-purpose programming language originally designed for web devel-

opment. It was originally created by Rasmus Lerdorf in 1994; the PHP reference
implementation is now produced by The PHP Group. PHP originally stood for Per-
sonal Home Page, but it now stands for the recursive initialism PHP: Hypertext

Department of CSE,BUBT 21 21
 CHAPTER 5. TOOLS AND TECHNOLOGY USED

Preprocessor.
PHP code may be executed with a command line interface (CLI), embedded
into HTML code, or used in combination with various web template systems, web
content management systems, and web frameworks. PHP code is usually processed
by a PHP interpreter implemented as a module in a web server or as a Common
Gateway Interface (CGI) executable.

5.4 XAMPP:

XAMPP is a free and open-source cross-platform web server solution stack package
developed by Apache Friends, consisting mainly of the Apache HTTP Server, Mari-
aDB database, and interpreters for scripts written in the PHP and Perl programming
languages. Since most actual web server deployments use the same components as
XAMPP, it makes transitioning from a local test server to a live server possible.
XAMPP’s ease of deployment means a WAMP or LAMP stack can be installed
quickly and simply on an operating system by a developer. With the advantage of
common add-in applications such as WordPress and Joomla! can also be installed
with similar ease using Bitnami.

22
 CHAPTER 6. IMPLEMENTATION AND TESTING

Chapter 6

Implementation and Testing

6.1 System Implementation

System Implementation uses the structure created during architectural design and the
results of system analysis to construct system elements that meet the stakeholder re-
quirements and system requirements developed in the early life cycle phases. These
system elements are then integrated to form intermediate aggregates and finally the
complete system-of-interest. Systems implementation is the process of:

• Defining how the information system should be built.

• Ensuring that the information system is operational and used.

• Ensuring that the information system meets quality standard.

6.2 System Testing

System testing is a level of testing that validates the complete and fully integrated
software product. The purpose of a system test is to evaluate the end-to-end system
specifications. Usually, the software is only one element of a larger computer-based
system. Ultimately, the software is interfaced with other software/hardware systems.
System Testing is actually a series of different tests whose sole purpose is to exercise
the full computer-based system. Two Category of Software Testing:

• Black Box Testing.

• White Box Testing.

In our project we select white box testing.

Department of CSE,BUBT 23 23
 CHAPTER 6. IMPLEMENTATION AND TESTING

WHITE BOX TESTING (also known as Clear Box Testing, Open Box Testing,
Glass Box Testing, Transparent Box Testing, Code-Based Testing or Structural Test-
ing) is a software testing method in which the internal structure/design/implemen-
tation of the item being tested is known to the tester. The tester chooses inputs to
exercise paths through the code and determines the appropriate outputs. Program-
ming know-how and the implementation knowledge is essential. White box testing
is testing beyond the user interface and into the nitty-gritty of a system.

24
 CHAPTER 7. CONCLUSION

Chapter 7

Conclusion

7.1 Limitations:

• Our project is not online based.

• It can use only a mess system.

• It can not be use for guest member.

7.2 Future Works :

• It can be develop as online base system.

• We can add guest member system.

7.3 Conclusion:

Mess management system is a customize and user friendly software for mess which
provides mess information, room information and account information. It helps ad-
min to manage. To replace the existing system which is much more time consuming.

Department of CSE,BUBT 25 25