Essay: Web Application for online car race booking system

ABSTRACT

• This is a Web Application for online car race booking system. This is an online booking service for those people who are really passionate about Car Race. The day when Car Race is organized by organizer, that day is Drive Day. In this system, we provide the every details of the Drive Day which is hold by an organization. By this system, interested people can find all the information about the Drive Day.
• People, who are interested in the Car Race, can purchase coupons online which are provided on the other websites that is distributed by the organizer. Users can register in the system by email or phone number and can book the tickets by using coupon code. When user books the slot, the coupon codes deactivate from the database, and remove from the other websites.
• It is a web based application which is run on the any web browser like Google Chrome, Firefox, Internet Explorer, etc. It is built by using PHP CodeIgniter and MySql. The basic aim of this application is for user facility. This application is use anywhere at any time by connected users only, just user need their internet connection and rights of each other to access this application.
• Users, who are purchased the coupons, user can book slots from our website. After the registration, user is notified by email or text message. We provide the One Time Password (OTP), for the conformation after booking the ticket for the security purpose. User can get the OTP by email.
• User, for which Drive Day, he/she book the slot, will get the information on the email or get notification by text message before the Drive Day. User can get the information about the schedule, location, information about drivers and other information about the Drive Day.
• For any reasons, user wants to cancel his/her slots; he/she can cancel the slot from the website before the Drive Day. It will automatically update the database, and active the coupon code on the website.

CHAPTER 1 – INTRODUCTION

1.1 Project Summary
We are developing an online Car Race Booking System PHP based website. This website is using for view, book & search different types of Rally. We book the different types of rallies held in forest, desert, etc. We book slots for interested people for rally using coupons which are distributed on the different web-sites. We are also providing a secure registration and profile management facilities for Customers. Our website providing online payment system through PayPal. We are regular updates to registered users about new rallies.Our website is to help of Users to get connected in their own region.
1.2 Project Purpose
The administration module will enable a system administrator to manage time date and locations for rallies.Secure registration and profile management facilities for Customers. Regular updates to registered users about new rallies. Our purpose is customer book race slots without go to any booking agent and booking a race in own house.
1.3 Project Scope
 The main Scope is Consumers who are interested in booking online race slot by PayPal.
 They can use this website to search the rallies, view race tracks.
 Users must register for book slot. .
 User can also managing their profiles & know about new rallies
1.4 Project Objectives
Registration for the customers requires them to provide their personal details. The objective behind this is that the registered customer can get the updates regularly about the race to his/her registered number or email id. The registration of customers is confirmed by the
Admin. The customer can search for a Drive Day of the rally interested after registration.
After searching, the customer can view the track of the selected rally and then book the slots
Booked slots will have to be confirmed by the Admin, the aim here is to avoid overlapping of multiple slot booking. Admin will send a confirmation e-mail to the customer through our own personalized mailing system, notifying the customer that their slots have been confirmed.
1.5 Technology Review
 Front End:
 PHP
This is a web based application developed using technology PHP in the front end.
Fig. 1.5.1 php logo
PHP is a server-side scripting language designed for web development but also used as a general-purpose programming language. PHP code can be simply mixed with HTML code, or it can be used in combination with various tinplating engines and web frameworks.
 JavaScript
JavaScript is a high level, dynamic, untyped, and interpreted programming language. It has been standardized in the ECMAScript language specification.
JavaScript is prototype-based with first-class functions, making it a multi-paradigm language, supporting object-oriented, imperative, and functional programming styles. It has an API for working with text, arrays, dates and regular expressions, but does not include any I/O, such as networking, storage or graphics facilities, relying for these upon the host environment in which it is embedded.
 Platform:
 CodeIgniter
Fig. 1.5.2 CodeIgnitor Logo
CodeIgniter is an open source rapid development web application framework, for use in building dynamic web sites with PHP.
CodeIgniter is loosely based on the popular Model -View -Controller development pattern. While controller classes are a necessary part of development under CodeIgniter, models and views are optional.
 Back End:
 MySql
Fig 1.5.3 MySql Logo
MySQL is an open-source relational database management system (RDBMS). The MySQL development project has made its source code available under the terms of the GNU General Public License, as well as under a variety of proprietary agreements.
1.6 Literature Review
1.6.1 Study of current Existing System:
 www.rallyqueensland.com.au
o In this website, the organizer Brisbane Sporting Car Club Ltd organizes the rally in Queensland, Australia. In this system, organization gives the schedule of the rally, maintains the records of the rally and shows the result of the rally which is hold in Queensland. It provides the details of the sponsors and future rally schedule that is hold in Queensland.
 www.rallyaustralia.com.au
o In this website, the organizer organizes the rally called FIA WRC-World Rally Championship in Australia. In this system, it gives the schedule information about the rally, keeps the track about rallies and provides the news and other media about the rally. It books the sits called the baskets. It also gives the information about the future events about the rally
 www.dudleyracingcarclub.co.uk
o In this website, the organizer organizes the car race at Coseley School and Leisure Centre. In this system, it provides the information about schedule of the race day, venue, and results. It keeps the records about the race that will hold in past. It books the tickets of rally by registration. It also provides the photo gallery of the race.
1.6.2 Limitation of Existing System:
 Very complicated sitemap.
 Inefficiency and estimation of cost.
 Very hard to use for new users.
 Does not provide secure transactions for payment.
 No cancellation facility.
1.6.3 Usability Of Project:
 To create simple, easy to use web application.
 To provide accuracy and precision with reduced human intervention.
 Anytime anywhere booking facility.
 24 x 7 booking service.
1.6.4 Innovative Ideas Of Project:
 Secure payment system for every customer.
 Location for non familiar people with race venue.
 Cancellation facility
 Quick updates by notification of updates by email or sms.
 Conformation of the transaction by OTP
 Registration via coupons.

CHAPTER 2 – PROJECT MANAGEMENT

2.1 Project Planning:
2.1.1 Project Development Approach And Justification:
The systems development life cycle (SDLC), also referred to as the application development life-cycle, is a term used in systems engineering, information systems and software engineering to describe a process for planning, creating, testing, and deploying an information system.
A systems development life cycle is composed of a number of clearly defined and distinct work phases which are used by systems engineers and systems developers to plan for, design, build, test, and deliver information systems. Like anything that is manufactured on an assembly line, an SDLC aims to produce high quality systems that meet or exceed customer expectations, based on customer requirements, by delivering systems which move through each clearly defined phase, within scheduled time-frames and cost estimates.
Fig. 2.1.1.1 Software Development Life Cycle
2.1.1 Project Plan:
We are planning our project completing in given time duration. We are also gathering customer’s requirement and satisfying all that needs. We are using best functionality to developing this website. Required Database was designed and normalized as required. Code was written in such a way that maximum functionality was coded with minimum possible lines of code.
2.2 Project Scheduling:
Gantt chart:
Fig. 2.2.2 Gantt Chart
2.2 Risk Management:
2.2.1 Risk Identification:
All projects have risks. If a potential risk of the project is not identified early, then the project will be at high risk to complete as per schedule. Hence, it is the most important process in risk management planning.
2.2.2 Risk Analysis:
It is the second step of risk management. Impact is the effect of the risk in case it happens. There are some technical and business factors while assigning impact.
 Customer loss.
 Loss of business, financial loss.
 Hardware integration problems.
2.3 Canvas Designing:
2.4.2 AEIOU Framework:
Fig 2.4.2.1 Activity Canva
Fig 2.4.2.2 Environment Canvas
Fig 2.4.2.3 Interaction Canvas
Fig 2.4.2.4 Object Canvas
Fig 2.4.2.5 User Canvas
2.4.2 Empathy Summary:
Fig 2.4.2 Empathy Summary:
2.4.3 Ideation:
Fig 2.4.3 Ideation
2.4.4 Product Development:
Fig 2.4.4 Product Development

CHAPTER 3 – SYSTEM REQUIREMENT STUDY

3.1User Characteristics:
 Customer:
Customer as an actor demands for particular product along with specification of all the requirements. Customer can:
 Create a new product request.
 Specify all requirements
 Optionally attach design specifications
 View all past request and its details.
 Admin:
The main job of an administrator is to manage the tasks performed by the user. Admin performs the following tasks:
 Creating whole systems.
 Configure all the parameters for displaying information.
 Configure role of the user be it the employee or the customer.
3.2 Software Requirements:
 Technology: PHP
 Language: PHP, Java Script, jQuery
 For Development: CodeIgniter
 Back End: MySQL
3.3 Specific Requirements:
3.3.1 Functionality:
 All requirements are very well known, clear and fixed.
 Whole technology should be understood.
 Code simplicity is one the best feature to understand the coding phase.
 Login, Registration will be done efficiently.
 The important key is contact number, verified the number or register the number.
 Logout.
3.3.2 Usability:
 The whole system takes an hour to understand all requirements, specifications and functionality for a normal user.
 Developers need to be up-skilling and expected to bring great code to an organization.
 Developers must follow the specific standards, which the technology is used.
3.3.3 Reliability:
 Maintainability: If any requirement occurs, then it should be easily incorporated in the system.
 Portability: The application should be portable on any browser
3.3.4 Performance:
 Response time for transaction: This term represents the time for a database transaction. This application will take one to two seconds (average) for database transaction.
 Capacity: The system can accommodate around the many customer’s capacity in this application.
 Resource Utilization: This application contain resources like,
o Laptop, mobile, tablet, etc.
o Communication is done through internet
 Cost Sensitivity: Under all circumstances, the maximum cost payable as submitted by the user will be the maximum cost charged to the user.
3.3.5 Supportability:
This section includes following supportability requirements:
 Naming Conventions: All code will be written as specified by the Pascal Naming Convention (for Class name and Methods name), Camel Casing Convention (Method arguments and local variables) and Hungarian Naming Convention (Data type identification).
 Coding Standards: All codes will be written as required by the php Coding Standards.
 Cost-Effective-To-Maintain: It may covers divers level of documentation, such as system documentation as well as test documentation.
3.3.6 Design Constrain
There are many aspects of any design project that must be considered to determine the feasibility of the system.
Software Language: All coding will be done in standard of php platform.
Scheduling Constraints: Exhaustive searches of the entire set of combinations of jobs will not be done. Heuristics will be developed for this scheduling problem.
3.4 Assumptions and Dependency
There are no assumptions in this web application.

CHAPTER 4 – SYSTEM ANALYSIS

4.1 Requirements Of New System:
4.1.1 User Requirements:
User must be aware the system works properly with full availability, reliability, security and safety. The user responsibilities are as follows:
 Should know the data needed to address the problem.
 Should know how to use it.
 Should adhere to guidelines and prescribed standard.
4.1.2 System Requirements:
This web application is designed to booking the slots of race . It must fulfill all the functional and non-functional requirements.
4.2 Feasibility Study:
4.2.1 Technical Feasibility:
Technical feasibility determines whether the work for the project is being done with the present equipment, current procedures, existing software’s technology and available persons or not. Thus it is important to check the system to be technically feasible.
System would be implemented using php technology which is quite easy to use and user friendly IDE CodeIgnitor.
 Software Platform:
o Database server- MySql
o Technologies- PHP
 Development Tool:
o CodeIgnitor
4.2.2 Economical Feasibility:
Economic feasibility looks at the financial aspects of the project. Economic feasibility concern with returns from the investments in project.
The software resources requirements for the proposed system is PHP development environment, MySql that are already owned by the client and do not require additional investment.
4.2.3 Implementation Feasibility:
Implementation feasibility deals with the study whether the service, which is being developed will run in the environment available with us, will the management of the organization approve the system?
Implementation feasibility is about basic infrastructure and material required to develop the system. It is found that:
 Infrastructure provided was a high configuration computer system to implement the application.
 The required software’s like CodeIgnitor, MySql is provided.
 Literature like books, technical manuals and reports.
 Proper and timely guidance was provided by the guide.
4.3 Requirements Validation:
It is a process in which it is checked that gathered requirements represents the same system that customer really wants or it is showing different. The basic objective of requirement validation is that the SRS reflects the actual requirements correctly and accurately.
The common methods for requirement validation are as follows:
 Requirement Review:
It is review by group of people to find errors and point out other matters of concern. It may be formal or informal.
 Prototype:
The requirements can be checked using executable model of the system. Prototype which is build during analysis, can be used for requirement validation.
 Test Case Generation:
In this technique, various tasks are developed for requirements and they are- Verifiability, Comprehensibility, Traceability and Adaptability.
4.4Features of New System:
 This system is a web based application.
 It is an system which is for specific organization.
 Provide easy navigation and user-friendly interface:
 Payment Gateway Integration :
4.5 Oriented Approach:
Fig 4.5.1 Activity Admin
Fig. 4.5.2 Activity User
Fig 4.5.3 Collaboration Admin
Fig 4.5.4 Collaboration User
Fig. 4.5.5 Sequence Admin
Fig. 4.5.6 Sequence User
Fig 4.5.7 Use case
Fig 4.5.8 Class Diagram

CHAPTER 5 – SYSTEM DESIGN

5.1 Database Design:
5.1.1 Admin_Master
Description: To store the login id and password and name of admin.
Primary Key: UserId
Field Name Data Type (With Size) Constraint
UserId int Primary key
UserName varchar(50) Not Null
Password varchar(50) Not Null
IsActive bit Not Null
UserType int Not Null
CreatedDate datetime Not Null
ModifiedDate datetime Not Null
Table 5.1.1
5.1.2 BookingMaster:
Description: to store the Detail of Booking.
Primary Key: BookId
Field Name Data Type (With Size) Constraint
BookId int Primary Key
CustId int Foreign Key
SlotId int Not Null
VoucherNo varchar(50) Not Null
IsConfirmed bit Not Null
CreatedDate datetime Not Null
ModiifiedDate datetime Not Null
Status varchar(25) Not Null
TransId varchar(25) Not Null
Amount decimal(10, 2) Not Null
IsCustParticipant bit Not Null
PartName varchar(50) Not Null
PartEmail varchar(50) Not Null
PartPhoneNo varchar(12) Not Null
IsCancelled bit Not Null
IsSendNotiToRecipient bit Not Null
Table 5.1.2
5.1.3 CMS Master:
Description: To Store the detail of company contact detail
Primary Key:ComapnyId
Field Name Data Type (With Size) Constraint
CompanyId int Primary Key
CompanyName varchar(50) Not Null
ContactPerson varchar(50) Not Null
ContactNO varchar(12) Not Null
CreatedDate datetime Not Null
ModifiedDate datetime Not Null
Table 5.1.3
5.1.4 Company Master:
Description: To store Company Details
Primary Key: CompanyId
Field Name Data Type (With Size) Constraint
CompanyId int Primary key
CompanyName varchar(50) Not Null
ContactPerson varchar(50) Not Null
ContactNO varchar(50) Not Null
CreatedDate datetime Not Null
Table 5.1.4
5.1.5 Table Name: Course_Master
Description: To store the Detail Of Course or Race..
Primary Key: CourseID
Field Name Data Type (With Size) Constraint
CourseID int Primary key
CourseName varchar(50) Not Null
LocationID int Foreign Key
Price decimal(10, 2) Not Null
CreatedDate datetime Not Null
ModifiedDate datetime Not Null
Table 5.1.5
5.1.6 Table Name: Course_Master
Description: To store the Detail Of Course or Race..
Primary Key: CourseID
Field Name Data Type (With Size) Constraint
CourseID int Primary key
CourseName varchar(50) Not Null
LocationID int Foreign Key
Price decimal(10, 2) Not Null
CreatedDate datetime Not Null
ModifiedDate datetime Not Null
Table 5.1.6
5.1.7 Table Name: CustDetai
Description: To store the details of customers
Primary Key: CustId
Field Name Data Type (With Size) Constraint
CustId int Primary key
RaceId varchar(50) Foreign Key
CustName varchar(50) Not Null
Email varchar(50) Not Null
Password varchar(50) Not Null
PhoneNo varchar(12) Not Null
VoucherNo varchar(15) Not Null
CreatedDate datetime Not Null
ModifiedDate datetime Not Null
IsBookingConfirmed bit Not Null
IsEmailConfirmed bit Not Null
IsActive bit Not Null
EmailVerificationCode varchar(20) Not Null
Street varchar(120) Not Null
City varchar(20) Not Null
Postcode varchar(20) Not Null
State varchar(20) Not Null
5.1.8 Table Name:DealMaster
Description: To store the details of Maps
Primary Key: DirectionID
Field Name Data Type (With Size) Constraint
DirectionID int Primary Key
Title varchar(200) Not Null
TextColumn varchar(5000) Not Null
LocationID int Not Null
DirectionMap varchar(200) Not Null
CreatedDate datetime Not Null
ModifiedDate datetime Not Null
TripNoteFile varchar(200) Not Null
Table 5.1.8
5.1.9 Table Name:DirectionMaster
Description: To store the details of Maps
Primary Key: DirectionID
Field Name Data Type (With Size) Constraint
DirectionID int Primary key
Title varchar(50) Not Null
TextColumn varchar(50) Not Null
LocationID int Foreign Key
CreatedDate datetime Not Null
ModifiedDate datetime Not Null
DirectionMap varchar(200) Not Null
Table 5.1.9
5.1.9 Table Name:ErrorList
Description: To store the details of errors
Primary Key:ErrorId
Field Name Data Type (With Size) Constraint
ErrorId bigint Primary Key
ErrorCode varchar(50) Not Null
ErrorDate datetime Not Null
ErrorName varchar(250) Not Null
EventName varchar(50) Not Null
IPAdd varchar(50) Not Null
PageUrl varchar(250) Not Null
Table 5.1.10
5.1.10 Table Name:LocationMaster
Description: To store the details of location
Primary Key:LocationId
Field Name Data Type (With Size) Constraint
LocationID int Primary Key
LocationName varchar(10) Not Null
CreatedDate datetime Not Null
ModifiedDate datetime Not Null
ModifiedBy int Not Null
Table 5.1.10
5.1.11 Table Name: MessageMaster
Description: To store the Detail of the message
Primary Key: MessageID
Field Name Data Type (With Size) Constraint
MessageID int Primary key
Message varchar(500) Not Null
Table 5.1.11
5.1.12 Table Name: RaceSlot
Description: To store the Detail Of Race Slot
Primary Key: SlotID
Field Name Data Type (With Size) Constraint
SlotID int Primary key
LocationID int Foreign Key
CourseID int Foreign Key
StartDate datetime Not Null
StartTime varchar(20) Not Null
EndTime varchar(20) Not Null
Status varchar(200) Not Null
NoOfSeat int Not Null
CreatedDate datetime Not Null
ModifiedDate datetime Not Null
BookedSeat int Not Null
MoveNotes varchar(MAX) Not Null
IsDeleted bit Not Null
IsCancelled bit Not Null
Table 5.1.12
5.1.13 Table Name: SiteSetting
Description: To store the Detail Of Site..
Primary Key: SettingID
Field Name Data Type (With Size) Constraint
SettingID int Primary key
NoOfDays int Not Null
EmailForNotification varchar(50) Not Null
Password varchar(50) Not Null
HostName varchar(50) Not Null
CancelationCharegDays int Not Null
CancellationPercet Decimal(5,2) Not Null
PaypalID varchar(100) Not Null
SMSHttpApi varchar(100) Not Null
EmailSignature varchar(100) Not Null
LblForCoupon varchar(100) Not Null
DaysbeforeRegStop int Not Null
Table 5.1.13
5.1.14Table Name: tblfaq
Description: To store the Detail of frequently asked questions
Primary Key: FaqId
Field Name Data Type (With Size) Constraint
FaqId int Primary key
Question varchar(500) Not Null
Ans varchar(500) Not Null
Table 5.1.14
5.1.15 Table Name: VoucherMastr
Description: To store the Detail of the voucher..
Primary Key: VoucherID
Field Name Data Type (With Size) Constraint
VoucherID int Primary key
VoucherNo varchar(25) Not Null
Status smallint Not Null
CreateDate datetime Not Null
ModifiedDate datetime Not Null
RaceID int Not Null
Cancelpercent int Not Null
CouponPrice decimal(10, 2) Not Null
PurchaserName varchar(100) Not Null
StateId int Not Null
DealId varchar(100) Not Null
ActivationCount int Not Null
Table 5.1.15

CHAPTER 6 – Testing

6.1Testing Strategy:
A strategy for software testing integrates the design of software test cases into a well-planned series of steps that result in successful development of the software. The strategy incorporates test planning, test case design and the result collection and evaluation.
Testing begins “in the small” and progresses “to the large”. Initially individual components are tested using white box and black box techniques. After the individual components have been tested and added to the system, integration testing takes place. Once the full software product is completed, system testing is performed. The best specification document should be reviewed like all other software engineering work products.
Strategic Approach to Software Testing:
 Testing begins at the component level and works outward toward the integration of the entire computer-based system.
 Testing is conducted by the developer of the software and by an independent test group.
 Different testing techniques are appropriate at the different points in time.
 Testing and debugging are different activities, but debugging must be accommodated in any testing strategy.
 Software testing is a part of broader group activities called verification and validation that are involved in software quality assurance.
Levels of Testing in Software:
1) Unit Testing:
 Black box and white box testing.
 Module interfaces are tested for proper information flow.
 Local data are examined to ensure that integrity is maintained.
 Boundary conditions are tested.
 Basis path testing should be used.
 All error handling paths are should be tested.
 Drivers and/or stubs need to be developed to test incomplete software.
2) Integration Testing:
Top-down integration testing:
 Main control module used as a test driver and stubs are substitutes for components directly subordinate to it.
 Subordinate stubs are replaced one at a time with real components.
Bottom-up integration testing:
 Low level components are combined in clusters that performed a specific software function.
 A driver is written to coordinate test case input and output.
 The cluster is tested.
 Drivers are removed and clusters are combined moving upward in the program structure.
3) Regression Testing:
 Representative sample of existing test cases is used to exercise all software functions.
 Additional test cases focusing software functions likely to be affected by the change.
 Tests cases that focus on the changed software components.
4) Smoke Testing:
 Software components already translated into code are integrated into a build.
 A series of tests designed to expose errors that will keep the build from performing its functions are created.
 The build is integrated with the order builds and the entire product is smoke tested daily (either top-down or bottom-up integration may be used).
5) Exploratory testing:
 Exploratory testing is also called adhoc testing, but in reality it\’s not completely adhoc.
 Ad hoc testing is an unplanned, unstructured, may be even an impulsive journey through the system with the intent of finding bugs. Exploratory testing is simultaneous learning, test design, and test execution. In other words, exploratory testing is any testing done to the extent that the tester proactively controls the design of the tests as those tests are performed and uses information gained while testing to design better tests.
6) Black box testing:
 Black box testing is a testing strategy based solely on requirements and specifications.
 Black box testing requires no knowledge of internal paths, structures, or implementation of the software being tested.
7) White box testing:
 White box testing is a testing strategy based on internal paths, code structures, and implementation of the software being tested. White box testing generally requires detailed programming skills.
8) Pusability testing:
 Usability testing is a testing methodology where the end customer is asked to use the software to see if the product is easy to use, to see the customer\’s perception and task time. The best way to finalize the customer point of view for usability is by using prototype or mock-up software during the initial stages.
 By giving the customer the prototype before the development start-up we confirm that we are not missing anything from the user point of view.
9) Random testing:
 Random testing is sometimes called monkey testing. In Random testing, data is generated randomly often using a tool. For instance, the following figure shows how randomly-generated data is sent to the system.
 This data is generated either using a tool or some automated mechanism. With this randomly generated input the system is then tested and results are observed accordingly.
6.2Test Cases
Admin:
SR NO. LABEL DESCRIPTION EXPECTED RESULT ACTUAL RESULT
1 Coupons Coupons are added for the registration. For the register of tickets for the drive day Test is successfully completed
2 Password When password is correct after the system is logged on Message will generated “enter valid password” Test is successfully completed
3 Admin Management Admin can change the update time of rally and other formats Admin changed
the schedule
Test is successfully completed
4 Requirement Management Admin can add or remove the profile of racer and maps for the rally Maps and profiles are added or removed in the particular table Test is successfully completed
5 Viewing Details Admin can view all the details of the customer through his registered id If number is not registered then admin cannot view the details of the customer Test is successfully completed
6 User Management Providing Coupons for the online bookings Provided Coupons and registration Test is successfully completed
Customer:
SR NO. LABEL DESCRIPTION EXPECTED RESULT ACTUAL RESULT
1 Profile Show and update his/her bookings On bookings profile, he/she can change and cancel the bookings Test is successfully completed
2 Sign Up He/She can sign up by adding proper formatted data in registration form On submitted, without any error registration will be done. On error, field must be filled with proper formatted data by user Test is successfully completed
3 Requirement specification Specify requirements with required contact number, email, name, address etc Specified requirements can be viewed successfully Test is successfully completed
4 Login He/She can login with their own username and password after registration and book their slots online for the drive day. On submitted, without any error login will be done. On error, field must be filled with proper formatted data by user Test is successfully completed

CHAPTER 7 – Limitation and Future Enhancement

7.1Limitations:
 Lot of mundane and repetitive work.
 Inefficiency and estimation of cost.
 Maintenance of records for future references.
 Internet connection loss.
 Payment error occurs if slow internet connection.
7.2 Future Enhancement:
 Can provide facility of chatting for quick answer asked by user.

CHAPTER 8 – Conclusion and Discussion

8.1Self Analysis Of Project Viabilities:
When studied about current system, some draw backs are to be found;
 Inefficiency and estimation of cost.
 Maintenance of records for future references.
 Loss of connection may be occurred.
8.2Problem Encountered And Possible Solutions:
Problems Possible Solutions
Slow Internet Connection Use High Internet Connection
Payment error Use High Internet Connection
Leak of data
Protection of data.
8.3Summary of Project:
For this project, I have completed the whole analysis phase which includes Project Report, All GTU PMMS Activities (PPR, PSAR, PLAGIARISM, CANVAS).

CHAPTER 9 – REFERENCES

 www.google.com
 www.wikipedia.co
 www.codeidnitor.com
 www.w3xchools.com