A

Minor Project On

ONLINE BOOKSTORE

Submitted in partial fulfillment of the requirements

For the award of the degree of

BACHELOR OF COMPUTER APPLICATIONS

To
Guru Gobind Singh Indraprastha University, Delhi

Under the guidance of Submitted By

Mrs.Upasna Singh BCA 5TH

Sem(1st Shift)
(Assistant Professor) Avinash Singh
Mankotia(01120602020)

Batch 2020-23

TRINITY INSTITUTE OF PROFESSIONAL OF STUDIES

(Affiliated to Guru Gobind Singh Indraprastha University, Delhi) Ranked "A+" Institution by
SFRC, Govt. of NCT of India Recognized under section 2(f) of the UGC Act, 1956 NAAC
Accredited "B++" Grade Institution
 CONTENTS

S.No Topic Page

Number
1 Certificate(s)

2 Acknowledgements

3 List of Figures

4 List of Abbreviations

5 Chapter-1: Introduction 1-9

6 Chapter-2: System Requirements and Analysis 10-14

7 Chapter-3:System Feasibility Study 15-37

8 Chapter-4:System Design 38-62

9 Chapter-5:Systems Development(Coding0 63-74

10 Chapter-6: System implementation (Screen Shots) 75-88

11 Chapter-7:Systems Testing 89-97

12 Chapter-8: Future Scope 98

13 Chapter-9: Conclusion 99

14 References 100

LIST OF FIGURES

Figure No Title Page No

1 E-R Diagram 11

2 Data Flow Diagram Symbols 13

3 Level 0 Data Flow Diagram 14

4 Level 1 Data Flow Diagram 15

 TRINITY INSTITUE OF PROFESSIONAL STUDIES

(Affiliated to Guru Gobind Singh Indraprastha University, Delhi)

Ranked "A+" Institution by SFRC, Govt. of NCT of India
Recognized under section 2(f) of the UGC Act, 1956 NAAC Accredited "B++"
Grade Institution

To Whom It May Concern

 I Avinash Singh Mankotia, Enrolment No. 01120602020 from BCA Sem-5th (1st shift) of the
Trinity Institute of Professional Studies, Delhi hereby declare that the Minor Project Report
entitled Online Bookstore Based on idea of presence of online store.
Submitted at Trinity Institute of Professional Studies is an original work and the same has not
been submitted to any other Institute for the award of any other degree.

Date: Signature of Student

Certified that the Project Report submitted in partial fulfillment of Bachelor of Computer
Applications (BCA) to be awarded by G.G.S.I.P. University, Delhi by Avinash Singh Mankotia
Enrolment No. 01120602020 has been completed under my guidance and is Satisfactory

Date: Signature of
Guide:
Name of Guide:
Ms. Neha
Designation: Assistant
Professor

Acknowledgment
We express our deep sense of guidance and indebtedness to MrsUpasana for her valuable
guidance, consistent encouragements, untiring and continuous supervision and support at every
stage of project.

We are thankful to the Lab Technicians and instructor for their help, co-operation and for
extending all possible facilities within their means to successfully complete this project.

At last but not the least we express our thanks to all those who directly or indirectly helped us
and encouraged us in carrying out this work.

Avinash Singh Mankotia

(01120602020)

CHAPTER-1
 INTRODUCTION 

 This Online BookStore follows the concept of e-commerce (online shopping) in depth.
Ecommerce it is also known as electronic commerce or internet commerce, refers to the buying
and selling of goods or services using the internet, and the transfer of money and data to execute
these transactions. Ecommerce is often used to refer to the sale of physical products online, but it
can also describe any kind of commercial transaction that is facilitated through the internet.
Online shopping is a form of electronic commerce which allows consumers to directly buy goods
or services from a seller over the Internet using a web browser or a mobile app. Consumers find
a product of interest by visiting the website of the retailer directly or by searching among
alternative vendors using a shopping search engine, which displays the same product's
availability and pricing at different e-retailers. As of 2020, customers can shop online using a
range of different computers and devices, including desktop computers, laptops, tablet computers
and smartphones. An online shop evokes the physical analogy of buying products or services at a
regular "bricks- and-mortar" retailer or shopping center the process is called business-to-
consumer online shopping. When an online store is set up to enable businesses to buy from
another businesses, the process is called business-to-business online shopping. Just Like that
Online bookstore is designed to sell products online from various categories of book collections.

This project definitely helps the user to buy something from the internet because in the book
store the user able to buy anything by selecting the book details and, By using this output design,
the user can save their time by buying the product that is wasting Time while roaming the
market. From here they can probably get all the things they want as well as they have several
options in the Single Collection.
This site is developed with the purpose of enabling vendor to setup online store, customers to
browse through the books, and a system administrator to approve and reject requests for new
books and maintain lists of book categories. Bringing a local retail bookstore.

Objective

The main objective of Project on Online Bookstore is to provide an essence of Online Bookstore.
Manage the details of books, customers, order, payment. It manages all the information about
Books, Payment, Up-to-date Descriptions. The Project is 5

totally built at administrator end and thus administrator is guaranteed the access. The purpose of
the project is to build an application to reduce the manual work for the managing the Books, Bill,
Customers. It tracks all the details about the Customers, Order etc.

Scope of the Project

The system is highly flexible one is well efficient to make easy interaction with the customer.
The key focus is given on data security, as the project is online and will be transferred in
network. The speed and accuracy will be maintained in a proper way.
 This will be user-friendly one and can successfully overcome strict and severe validation
checks.
This will be user-friendly one and can successfully overcome strict and severe validation checks.
The system will be a flexible one and changes whenever can be made easy. Using the facility and
flexibility in PHP and SQLite software can be developed in a neat and simple manner there by
reducing the operator's work.
Since The project is developed in HTML, CSS as a Front-end and PHP, SQL as a back-end it can
be modified easily and used for a long period.

Definition of the Project

Starting the project, we should fully know about the meaning of project. There are seven letters
in the word "PROJECT". Each character has its own technical meaning. P-planning: this deals
with the idea at thinking and which are required for project.

R- Resource: the money problem will be solved and resources from which collected.
0 - Operating: the procedure from which getting job is prepared in a systematic way is known as
operation.
J - Joint effort: this is directly proper to a operation output is a made of several person working
sincerely is known as JOIN EFFORT.
E - Engineering: A well-educated engineer can do this work in a better way to find out better
result. Hence the project is as engineer function.
C - Cooperation: To make the project successfully, it is necessary for its success and completion
of project.
T-a Technique: It must as it gives a better shape. It is not possible to complete the project
without technique.
The project is a system that gives the systematic way of planning and working.

It representing the temporary task, in a scientific manner carried out of engineers to achieve a
goal. The basic concept of the application is to allow the customer to shop virtually using the
Internet and allow customers to buy the clothes. The Server process the customers and the items
are shipped to the address submitted by them. The details of the items are brought forward from
the database for the customer view based on the selection through the menu and the database of
all the products are updated at the end of each transaction.

What is Responsive Website

A responsive website has an adaptive design, such that it is able to respond according to the
device or technology used by visitors. The basic idea behind designing a responsive website is to
create a website that looks good on all screen sizes.
• The layout of a responsive website changes as the user device's screen size changes.

• The functionality of a responsive website is dependent on the user device. 

• A responsive website has a lot of dynamic content that changes from device to device.
• A responsive website improves the usability of a website by simply shrinking it.
Problem Statement

• One of the most common problems today small scale business face is there presence and its
name in the market. In The pandemic most of small scale business went downhill because of lack
of customers

As everybody was stuck in there home or they were Doing online shopping. Is to find a specific
deal which offers the best of service according to our needs.

Solution:

Online Bookstore as the name suggested is a website through which we provide an local
bookstore an online presence to their business in online(global) scale everyone who wants to
Discover the joy of buying is provided the service as same as a local bookstore.

Users find the best service available, saving time, resources and effort. The website fills up
efficiently and time can be utilized properly by commercial and corporate entities.
 CHAPTER-2

Systems Requirement Analysis

A software requirements specification is a detailed description of a software system to be

developed with its functional and non-functional requirements. The SRS is developed based the
agreement between customer and contractors. It may include the use cases of how user is going
to interact with software system. The software requirement specification document consistent of
all necessary requirements required for project development. To develop the software system we
should have clear understanding of Software system. To achieve this we need to continuous
communication with customers to gather all requirements.

A good SRS defines the how Software System will interact with all internal modules, hardware,
communication with other programs and human user interactions with wide range of real life
scenarios. Using the Software requirements specification (SRS) document on QA lead, managers
create test plan. It is very important that testers must be cleared with every detail specified in this
document in order to avoid faults in test cases and its expected results.
A software requirements specification (SRS) is a description of a software system to be
developed. It is modeled after business requirements specification (CONOPS). specification lays
out functional requirements specification and non-functional requirements, and it may include a
set of use cases that describe user interactions that the software must provide to the user for
perfect interaction. Software requirements specification establishes the basis for an agreement
between customers and contractors or suppliers on how the software product should function (in
a market-driven project, these roles may be played by the marketing and development divisions).
Software requirements specification is a rigorous assessment of requirements before the more
specific system design stages, and its goal is to reduce later redesign. It should also provide a
realistic basis for estimating product costs, risks, and schedules. Used appropriately, software
requirements specifications can help prevent software project failure.
The software requirements specification document lists sufficient and necessary requirements for
the project development. To derive the requirements, the developer needs to have clear and
thorough understanding of the products under development. This is achieved through detailed
and continuous communications with the project team and customer throughout the software
development process. The SRS may be one of a contract's deliverable data item descriptions or
have
other forms of organizationally-mandated content.

Typically a SRS is written by a technical writer, a systems architect, or a software programmer.

It is highly recommended to review or test SRS documents before start writing test cases and
making any plan for testing.

 Correctness of SRS should be checked. Since the whole testing phase is dependent on
SRS, it is very important to check its correctness. There are some standards with which
we can compare and verify.
 Ambiguity should be avoided: Sometimes in SRS, some words have more than one
meaning and this might confuse testers making it difficult to get the exact reference. It is
advisable to check for such ambiguous words and make the meaning clear for better
understanding.
 Requirements should be complete: When tester writes test cases, what exactly is
required from the application, is the first thing which needs to be clear. For e.g. if
application needs to send the specific data of some specific size then it should be clearly
mentioned in SRS that how much data and what is the size limit to send.
 Consistent requirements: The SRS should be consistent within itself and consistent to
its reference documents. If you call an input "Start and Stop" in one place, don't call it
"Start/Stop" in another. This sets the standard and should be followed throughout the
testing phase.

• Verification of expected result: RS should not have statements like "Work as expected", it
should be clearly stated that what is expected since different testers would have different
thinking aspects and may draw different results from this statement.

• Testing environment: some applications need specific conditions to test and also a particular
environment for accurate result. SRS should have clear documentation on what type of
environment is needed to set up

 Pre-conditions defined clearly: one of the most important part of test cases is pre-
conditions. If they are not met properly then actual result will always be different
expected result. Verify that in SRS, all the pre-conditions are mentioned clearly.

 Requirements ID: These are the base of test case template. Based on requirement Ids,
test case ids are written. Also, requirements ids make it easy to categorize modules so just
by looking at them, tester will know which module to refer. SRS must have them such as
id defines a particular module.

 Security and Performance criteria: security is priority when a software is tested

especially when it is built in such a way that it contains some crucial information when
leaked can cause harm to business. Tester should check that all the security related
requirements are properly defined and are clear to him. Also, when we talk about
performance of a software, it plays a very important role in business so all the
requirements related to performance must be clear to the tester and he must also know
when and how much stress or load testing should be done to test the performance.
  Assumption should be avoided: sometimes when requirement is not cleared to tester, he
tends to make some assumptions related to it, which is not a right way to do testing as
assumptions could go wrong and hence, test results may vary. It is better to avoid
assumptions and ask clients about all the "missing requirements" to have a better
understanding of expected results.

 Deletion of irrelevant requirements: there are more than one team who work on SRS so
it might be possible that some irrelevant requirements are included in SRS. Based on the
understanding of the software, tester can find out which are these requirements and
remove them to avoid confusions and reduce work load.

 Freeze requirements: when an ambiguous or incomplete requirement issent to client to

analyse and tester gets a reply, that requirement result will be

updated in the next SRS version and client will freeze that requirement. Freezing here means that
result will not change again until and unless some major addition or modification is introduced in
the software.

Most of the defects which we find during testing are because of either incomplete requirements
or ambiguity in SRS. To avoid such defects it is very important to test software requirements
specification before writing the test cases. Keep the latest version of SRS with you for reference
and keep yourself updated with the latest change made to the SRS. Best practice is to go through
the document very carefully and note down all the confusions, assumptions and incomplete
requirements and then have a meeting with the client to get them clear before development phase
starts as it becomes costly to fix the bugs after the software is developed. After all the
requirements are cleared to a tester, it becomes easy for him to write effective test cases and
accurate expected results.

Functional vs Non-Functional Requirements

Knowing exactly what features and functionalities a customer wants in the app is quite
challenging for a software development team. To avoid any misunderstandings, a customer and a
software development team need to define project requirements: both functional and non-
functional requirements for the future application. In this article, we explain the difference
between the two types of requirements and share the best practices on how they are gathered.

What Are Functional Requirements?

In software development, functional requirements determine the functions an entire application

or just one of its components should perform. A function consists of
three steps: data input - system behavior - data output. It can calculate, manipulate data, carry out
business processes, establish user interaction, or do any other tasks

In other words, a functional requirement is WHAT an application must or must not do after some
data input.

Functional requirements are important as they show software developers how the system is
intended to behave. If the system doesn't meet functional requirements it means that it doesn't
work properly.

What Are Non-Functional Requirements?

Non-functional requirements determine the performance standards and quality attributes of

software, e.g. system usability, effectiveness, security, scalability, etc.

While functional requirements determine what the system does, non-functional requirements
describe HOW the system does it. For example, a web application must handle more than 15
million users without any decline in its performance, or a website must not load more than 3
seconds.

If an app doesn't meet non-functional requirements, it continues to perform its basic functions,
however, it won't be able to provide a great user experience. Non-functional requirements are
important as they help software developers to define the system abilities and constraints that are
essential for developing high- quality software. Therefore, non-functional requirements are as
important as functional requirements for successful product adoption.
Why Is the Difference Between Functional and Non-Functional
Requirements Important?

Well-defined functional and non-functional requirements help software developers to build the
product that exactly corresponds to the client's needs. However, is it really necessary to know the
difference between functional and non-functional requirements?

The main reason to know the difference between functional and non-functional requirements is
that they define the scope of work for a project. Software developers need to keep up with this
scope to develop an application within its timeframe and budgetIf the scope of work constantly
changes, the development team has to extend the deadlines and the development costs increase.
This may lead to adverse consequences for a project.

The importance of distinguishing between the two types of requirements is paramount when
creating an MVP. A development team and a customer should discuss which features and
functionalities to implement in the app first. A customer may have his own vision of the project
and its requirements. If a customer decides that they want to remove or modify some feature, it's
essential to realize what type of requirement it is. Most of the time, software developers can
simply change the non-functional requirements while functional requirements will demand more
work and profound changes.

When a customer and a software development provider know the difference between functional
and non-functional requirements, it helps them to more

7.security - defines how secure the app should be, for example, FinTech and banking apps should
meet the international and regional security standards;

8. capacity - assesses the amount of data or services the app can handle.

Example

There is a wide range of other formats that can help make up the project requirements. Let's have
a look at the most effective ones.

User Stories
It is a common practice to formulate the requirements in a form of user stories. User stories are
the requirements conveyed by a user. They usually take the form of several simple sentences
which have the same pattern:As a (user), I want to (goal) so that (reason).

A user story example: As a project manager, I want to understand the software development
team's progress so that I can report on the outcomes to the CEO and project stakeholders.

Software developers usually compile requirements using user stories when they want to
communicate the ideas on product features and functionality to non- technical members.

Use Cases

Use cases have a broader scope than user stories. They include types of users and all the possible
actions a user can do in an app. Unlike user stories that describe the end purpose of a feature, use
cases involve the flow of steps which lead to the purpose.

For example, if you want to create an application for logistics and supply chain management, the
number of roles software developers should think about are: sellers, buyers, suppliers, managers,
dispatchers, and many others.

The actions for these roles can look like these:

both seller and buyer can view the product route in the app;

all the dispatchers can track products in warehouses;

all the users can view the delivery time on items in their accounts, etc.
TOOLS: HARDWARE & SOFTWARE SPECIFICATION:

 Hardware Requirements:
 CPU: 2.9GHz Intel Core i7-7500U (dual-core, 4MB cache, up to 3.5GHz)
 Microsoft Compatible
 RAM: 8GB DDR4
 Graphics: Intel HD Graphics 620
 Storage: 1 TB Hard Drive
 Keyboard & Mouse

Software Requirements:

 Front-End: PHP, HTML, JavaScript, Bootstrap, CSS.

 Back-End: MySql

 Hosting: Freenom.com and 000 Webhost.com

 CHAPTER – 3
Feasibility Study
Feasibility Study:

Feasibility study is a preliminary study undertaken before the real work of project starts to
ascertain the likelihood of the project's success. It is an analysis of all possible solution to a
problem and a recommendation on the best solution to use. It involves evaluating how the
solution will fit into the corporation.

It is used to determine if the project should get the go-ahead. If the project is to proceed, the
feasibility study will produce a project plan and budget estimates for the future stages of
development.

Feasibility is defined as the practical extent to which a project can be performed successfully. To
evaluate feasibility, a feasibility study is performed, which determines whether the solution
considered to accomplish the requirements is practical and workable in the software. Information
such as resource availability, cost estimation for software development, benefits of the software
to the organization after it is developed and cost to be incurred on its maintenance are considered
during the feasibility study. The objective of the feasibility study is to establish the reasons for
developing the software that is acceptable to users, adaptable to change and conformable to
established standards. Various other objectives of feasibility study are listed below.

• To analyse whether the software will meet organizational requirements.

• To determine whether the software can be implemented using the current technology and
within the specified budget and schedule.

• To determine whether the software can be integrated with other existing software.
Some common question asked during the study?

1. Who Are the People You Will Serve?

One of the first things that you should ask yourself as soon as a business idea strikes you is 'will
it work in the market you are planning to serve?' Take the culture, lifestyle, & geography of your
target market into account and you will geta black & white picture on whether a business can
work there or not. For example, opening a gas range selling website is a potential business idea
in the US, but rather a silly one in India.

If you are assured 'yes, it will', narrow down your target audience. It might require a little
brainstorming but it shouldn't be too difficult a task. For example, if you are opening an online
fashion store, your prime target audience will be young and middle-aged women, who are also
tech-savvy. Define a customer persona to clearly outline their needs & expectations.

Once you get a clear picture of your target audience, take a moment and analyze 'as a business,
are you capable & willing to serve them?', 'do you have enough industry knowhow or access to
resources to keep your target audience engaged over a long period of time?', and most
importantly, 'do you have a vision?' If the answer is yes, (which it should be after that much of
analysis & market segmentation) assuredly, you have a better chance at succeeding.

2. How Much Do You Know about the Product?

Just because a business is in trend, doesn't mean that you can succeed at it. Your knowledge of
the product at hand is what holds the key to success. Let's elaborate with an example;

Say, you are associated with textile industry. Do you have a better chance to succeed at
launching an apparel ecommerce store or at offering travel booking services? Travel booking
may be the ongoing big thing, but if you don't have any industry knowhow, there is a very thin
chance that things will work out for you. The importance of product knowledge becomes more
apparent when it comes to enhance the customer experience. Without any product knowledge
and usage experience, the best you can do is offer a me-too product, which in no way can
guarantee you the success.

Preferably, you should be a consumer yourself, since only then you can come up with ways to
improve the product visually, practically, & emotionally and give customers a reason why they
should choose you over competitors.

3. Does It Have the Potential to Attain Mass Adoption?

For a scalable business, this is one important factor' to determine. Primarily, the adoptability of
your business revolves around the practical value of your product. Is it something that is in huge
demand? Or does it address an existing problem that has no solution available presently?
For that, you would need public-opinion to get a clear picture on whether the market is really in
need of such a product, or can the need for it be created (like Airbnb. Uber, and so many other
products/services have created).

So, begin with asking people in your social circle about your product or service. Is it something
that they want or are missing in their life? To get more critical & honest feedback, present it as
someone else's idea. If you have a good social media following, you can ask them the same thing
and make a more informed decision before taking any major action.

However, catering to customers' need is only one of the various factors that decide whether a
product will be adopted by masses. Other key factors include - how accessible is the product or
service, is it easy to use, and is it something your target customers can afford.

To ensure these other factors, you have to analyze your entire chain of business operations - from
accumulation of resources to the means of facilitating the service (which we will discuss in point
5). Only by taking care of these concerns can you be sure that your product/service will click
with your target audience.

4. Will Your Product/Service Last?

Besides adoption, sustainability is another crucial aspect you need to judge your business idea
upon. Despite the popularity of the business, you mustn't step forward without asking whether
the product or service at hand will still be in demand 2-3 years down the line, or can it become a
victim of a disruptive innovation. Groupon can serve as a good example here. During the initial
years, Groupon's

business model spread like a jungle fire, but over the last few years it has been constantly
degrading. (The company is continuously ceasing its operations in international markets; cut
down more than 1000 position from its staff in 2015, and suffered a loss of nearly $200 million
in 2016)

Reason for Groupon's fall is that customer loyalty cannot be built by offering something nearly
free. And without taking customer relation into account, a business model cannot sustain.
Merchants associated with Groupon soon realized that there is no guarantee that a past customer
would ever return; so gradually they began to leave.

In Groupon's case it might have been unlikely for a common man to predict that it will fail,
however, many marketing gurus had raised questions about its sustainability when it was
launched. That is why it is important that you do a rigorous market research on the business idea
you have in mind to be aware of such critical views and take a more informed decision whether
you should go for it or not.

4. Are the Resources Required to Facilitate the Service Easily

Accessible?
With constantly rising internet penetration across the world, there is no dearth of online business
ideas with huge future potential. However, whether a business idea will make its mark in the
market or not depends on how it is executed. This brings up the need to consider one important
factor - 'which fulfillment channel will you choose to provide your service?' For example, for an
ecommerce store - Is a responsive website enough, or should you also offer a mobile app for
shopping? Or, should you build up your own delivery system, or should youpartner with a third
party delivery service provider?

Market research & studying your intended target audience should give you some cues on which
fulfillment channel should bring the maximum ROI. However, their establishment would require
some capital & resources. And if you don't or can't have access to that required capital &
resources, that business idea is not for you - whether or not, you have figured out how to execute
it in the right manner. one of the above-mentioned choices, if partnering with the 3rd delivery
service providers is the right way to go, but if your target market has a scarcity of such delivery
services, then it is better to rethink the whole thing.

6. Will It Grab Market Attention?

While gathering public opinion is crucial to ensure your business's market acceptance, for a
scalable business, it is also important that it catches the eye of investors and peripheral
businesses.

During the initial stage, for business expansion you would need to provide some discounts and
other offers to attract & gain customers. Without any investor or capital, you cannot do that or
else you will burn out of cash before you have barely even begun. Investors determine the
success of your business idea based on its adoptability & sustainability (both of which we have
discussed already). One the other hand, for peripheral businesses (these are the businesses that
you will link with to run your ecommerce store such as suppliers, delivery partner, etc.), your
business idea should be something that brings them more and more business. Style Seat (for
salon booking) & OpenTable (for restaurant table booking) are two good examples in this
context. Both these businesses bring their associated peripheral partners more business by
minimizing their ideal time. So, if your business idea is something that makes the pie bigger for
your partner businesses, it should be a hit.

7. How Much Time Its Setup Will Take?

Irrespective of how good your business idea scores on all the above mentioned factors, if it isn't
executed in timely manner, chances of its success are thin. For aspiring entrepreneurs, their
prospective market share shrinks with every passing moment. Besides, there is always the chance
of reaching market saturation, which you have begun. will put you out of the picture even before
Luckily for prospective online startups, the timing concern is partially addressed by ecommerce
solutions readily available in the market. However, it is important tonote every ecommerce
platform is built to address a certain set of business goals & needs. Therefore, first it is important
to determine which ecommerce platform is best for your business.

that

The concern is only partially addressed because your business can have some custom
requirements that readymade scripts cannot address. In such a scenario, you need to make sure
that the developers you partner with are proficient enough

to help you setup your website in timely manner.

If it would naturally take too much time, you need to analyze how much marketyou might lose
during the period your desired website is getting ready. If you believe the final product will be
able recapture the market, then it is worth it, otherwise, you need to play smart and should enter
the market with your minimum viable product.

8. How Much Cost Its Setup Will Take?

Big or small, scalable or not, money is the life force of every business. Whichever business idea
you choose, do a fair analysis on how much money its establishment will take and make sure you
have quick access to capital (privately held or in the form of venture capitalists) required to start
that particular business.

There are pretty good chances that you will underestimate the cumulative business setup cost, as
in most cases what business owners consider are only development and operational costs. Permit
& licensing, registration with tax authority, brand development, marketing, hiring employees,
etc. are some other mandatory expenditure that you must take into account while deciding the
budget for your

venture.

Apart from that, if you are aiming to expand to new geographies & verticals down the line, you
should have an estimate of how much it will cost. If the cost is something that your business idea
is unlikely to acquire through funding, then it is time for some reconsideration.

Of course, a minimum risk is always involved when it comes to acquire funding for business
expansion. The point here is to understand the line between risky & unlikely. Since only by truly
believing in your business idea can you approach investors in the right manner & make an
impression to secure the deal.

9. How Much Will be the Cost per Acquisition?

Cost
per Acquisition (CPA) simply means the amount of money a firm spends to acquire a new
customer. There are many theories about what should be the ideal cost per acquisition. For
instance, many agree that it should be 15% of a

customer's lifetime value (revenue generated via a customer during a lifetime). But largely, it
depends on the industry.

Image: The Average CPA in AdWords across all industries through search & display

ad network

Here you can get a fairly good idea on how much money you need to spend to acquire a new
customer for a particular type of business. Of course, during the initial stage of your business, the
cost per acquisition will be way more than the corresponding average value due to extra
expenditure on business setup & branding. But it would fall around the average value as your
business grows withtime. Now, after consuming all these details, you need to determine - a) Are
you capable of spending the amount on acquiring each customer that the business in mind takes
on average? & b) Do you have viable plans to reduce that amount down the line? Only after
addressing these concerns can you say that the business idea you have in mind is the right choice.

10. Is It Strictly Legal?

your

Adoptability and scalability of your business model won't be of any use if it isn't legal. For
instance, buying/selling alcohol online is legal some US states, but restrictive in others.
Moreover, in India, it is simply not possible, given the current state of law.

Surprisingly, legality is a factor that is overlooked quite often when selecting a business model.
It's a huge mistake, which can swipe-off all your efforts and investment in an instance, or at least
become a long-term pain in the neck, like in the case of Uber.

Uber's business model doesn't meet the criteria for a legal business in many countries since it
doesn't have its own fleet; neither has it kept drivers on company payroll. As a result, the
company is currently facing numerous lawsuits. Lyft, another American transportation network
company, is amidst similar lawsuits. In most cases, you should be able to identify an illegitimate
business model on your own. In case of doubt, it is better to have a legal audit of the business
idea to stay on the safe side.

Type of Feasibility study

Technical Feasibility:
Technical feasibility assesses the current resources (such as hardware and software) and
technology, which are required to accomplish user requirements in the software within the
allocated time and budget. For this, the software development team ascertains whether the
current resources and technology can be upgraded or added in the software to accomplish
specified user requirements.

The key customer/user benefits kept in mind while envisaging this architecture were:

 Increased Safety while traveling.

 Real-Time trendiest travel.
 Enhanced Travel Experienced.
 Provide Customer Support.
 Increase Services.

Economical Feasibility:
Economic feasibility determines whether the required software is capable of generating financial
gains for an organization. It involves the cost incurred on the software development team,
estimated cost of hardware and software, cost of performing feasibility study, and so on. For this,
it is essential to consider expenses purchases (such as hardware purchase) and activities required
to carry out software development. In addition, it is necessary to consider the benefits that can be
achieved by developing the software.

Cost Benefits Analysis was done in this stage. Following activities were performed during this
stage:-

Each phase of the project was analyzed for the cost involve in it.

This was calculated based upon resources and infrastructure used.

Benefits of each phase which were the end products were also analyzed and listed.

Both cost involved and benefits obtained were compared to the details to get the final result.

Operational Feasibility:

Operational feasibility assesses the extent to which the required software performs a series of
steps to solve business problems and user requirements. This feasibility is dependent on human
resources (software development team) and involves visualizing whether the software will
operate after it is developed and be operative once it is installed.

Our website is uniquely suited to help customers provide the highest level of

customer services.
Travel enables customers too quickly and easily provide service of:-

• Consulting

• Booking

Methodology & Tools Used:

Methodology & Tools Used:

The model that is basically being followed is the WATERFALL MODEL, which states that the
phases are organized in a linear order. First of all the feasibility study is done. Once the part is
over the Requirement Analysis and Project Planning begins. The design starts after the
requirement analysis is complete and the coding begins after the design is complete. Once the
coding is completed, the testing is done. In this model the sequence of activities performed in
software development project are:

 Requirement Analysis

 Project Planning
 System Design
 Unit Testing
 System Integration and Testing

Here the linear ordering of these activities is critical. Output of one phase is the input of another
phase. The output of each phase is to be consistent with overall requirement of the system. Some
of the qualities of spiral model are also incorporated like after the people concerned with.

Some of the qualities of spiral model are also incorporated like after interface designing the user
was asked to validate the design as per the requirements. Interaction with the user was also done
from time to time for identifying further requirements.

WATERFALL MODEL was being chosen because all the requirements were known beforehand
and the objective of our website development is the computerization/automation of an already
existing manual working system.
Requirement Analysis & Specification

Design

Implementation & Unit Testing

Integration & System Testing

Operation & Maintenance

Various Stages of WATERFALL MODEL

Requirement Analysis &Specification:

The goal of this phase is to understand the exact requirement of the customer and to document
them properly. The requirements describe the "what" of the system, not the "how". This phase
produces a large document, written in a natural language, contains a description of what the
system will do without describing how it will be done. The resultant document is known as
Software Requirement Specification (SRS). The SRS document may act as a contract between
the developer

& customer.

Design Phase:

The goal of this phase is to transform the requirements specification into a structure that is
suitable for implementation in scripting language. Here, overall software architecture is defined,
and the high level and detailed design work is performed. This work is documented and known
as Software Design Description (SDD)

document.

Implementation & Unit Testing:

During this phase, design is implemented. If SDD is complete, the implementation or coding
phase proceeds smoothly.

During Testing, the major activities are centered on the examination and modification of the
code. Initially small modules are tested in isolation from the rest of the website product.

Integration& System Testing Phase:

This is a very important phase. Effective testing will contribute to the delivery of higher qualify
web products, more satisfied users, lower maintenance costs, more accurate and reliable results.
It is a very expensive activity and consumer one-third

to one-half of the cost of typical developments projects.

As we know, the purpose of unit testing is to determine that each independent

module is correctly implemented. This gives a little chance to determine that the interface
between modules is also correct, and for this reason integration testing of the entire system is
done whereas software is part of the system. This is essential to build confidence in the
developers before software is delivered to the customer or released in the market.

Operation & Maintenance Phase:

Website maintenance is a task that every development group has to face, when the software is
delivered to the customer's site, installed and is operational. Therefore, release of website
inaugurates the operation and maintenance phase of the life cycle. The time spent and effort
required to keep the website operational after is very significant. Despite the fact that it is very
important and challenging task; it is routinely the poorly managed headache that nobody wants to
face.

Website maintenance is a very board activity that includes error correction, enhancement of
capabilities and optimization. The purpose of this phase is to preserve the value of the Website
overtime. This phase of this phase is for 5-50 years whereas development may be 1-3 years.

Modules Used:
The modules that can be included in the Parking Selection synopsis are as follows:

> Administrator Module: The administrator can add, delete, modify andview the data related to
places, etc. Admin monitor maintains and improve the

content.

➤ Main Page: This Page is the front page for the website. It contains the option for existing user
and administrator to login. This page is the home page for every user. When an anonymous user
views this page, he is given menu options like Home, About (Timeline, Developer, Contact us),
Booking, Features (Reviews, Location, Price Plan).

> Feedback/Review Module: The Feedback/Review module allows you to conduct surveys to
collect feedback. Unlike the Survey tool it allows you to write your own questions, rather than
choose from a list of pre-written questions and unlike the tool, you can create non-graded
questions. The Feedback activity is ideal for the likes of course or teacher evaluations.

➤ Contact Us Module: The Contact module allows site visitors to send emails to other
authenticated users and to the site administrator. The Contact Us module helps one to implement
a contact us page in a website. It allows one to make a contact us request which is send to the
appropriate person. One can also view all the contact request made on a website.

- Price Plan Module: The Price Plan module allows site visitors to check the

reasonable prices packages offered by the website. This Page gives you the information about
our travelling packs.

Inquiry form Module: The module allows site visitors to make an inquiry related to website,
destination etc. It provides a platform where the visitor can ask the queries and get the answers
from the team.

About Page: This Page allows a visitor to know about our company, what our website do, great
deals and package of the desired vacation destination and further information.

> Review Page: This Page provide the review form where customer can share their reviews,
thoughts and suggestions and experience with us through a feedback form

➤ Services page: It contains a description about our all provided services so that the customer
can avail these services and enjoy their vacation with any worries.

Advantage and Disadvantage of waterfall model:

Advantages of the Waterfall model

Waterfall relies on teams following a sequence of steps and never moving forward until the
previous phase has been completed. This structure is suited to smaller projects with deliverables
that are easy to define from the start. Ben Aston from The Digital Project Manager explains,
"Waterfall is generally regarded with some disdain as an inefficient and passé traditional project
management approach. But Waterfall can be a useful and predictable approach if requirements
are fixed, well documented, and clear, if the technology is understood and mature, if the project
is short, and if there's no additional value gained from 'going agile.' A Waterfall approach can
actually provide more predictable end result for budget, timeline, and scope."

Here's an in-depth look at what the Waterfall methodology does best.

1. Uses clear structure

When compared with other methodologies, Waterfall focuses most on a clear, defined set of
steps. Its structure is simple each project goes through these steps: Requirement gathering and
documentation

• System design

• Implementation

• Testing

Delivery/deployment

Maintenance

Teams must complete an entire step before moving onto the next one, so if there are roadblocks
to completion, they're brought to light right away. Half-finished projects are less likely to get
pushed aside, leaving teams with a more complete, polished project in the end.

In addition to being clear, the progression of Waterfall is intuitive. Unlike Six Sigma or Scrum,
Waterfall does not require certifications or specific training for project managers or employees.
If you visually outline the process at the beginning using Lucidchart and explain the
methodology, team members will be able to jump into the system without a steep learning curve
slowing their progress.

Waterfall

2. Determines the end goal early

One of the defining steps of Waterfall is committing to an end product, goal, or deliverable at the
beginning, and teams should avoid deviating from that commitment. For small projects where
goals are clear, this step makes your team aware of the overall goal from the beginning, with less
potential for getting lost in the details as the project moves forward.
Unlike Scrum, which divides projects up into individual sprints, Waterfall keeps the focus on the
end goal at all times. If your team has a concrete goal with a clear end date, Waterfall will
eliminate the risk of getting bogged down as you work toward that goal.

3. Transfers information well

Waterfall's approach is highly methodical, so it should come as no surprise that the methodology
emphasizes a clean transfer of information at each step. When applied in a software setting,
every new step involves a new group of people, and though that might not be the case at your
company, you still should aim to document information throughout a project's lifecycle. Whether
you're passing projects off at each step or experience unexpected personnel changes, Waterfall
prioritizes accessible information so new additions to the team can get up to speed quickly if
needed.

You can maximize your benefits from this characteristic of Waterfall by staying organized with
the right process. Use Lucidchart (it's free to sign up!) to document processes so each team
member knows what has already been done on a project when it gets to them.

The disadvantages of the Waterfall model:

Waterfall is a respected methodology, but lately it's faced criticism for being an outdated model.
The methodology's limitations become more apparent depending on the size, type, and goals of
the project it's guiding. Rather than adapting your organization to Waterfall's guidelines later,
consider these limitations to assess whether Waterfall is truly a fit for your team.

1. Makes changes difficult

Waterfall is based entirely on following a set of steps that keep teams always moving forward.
The methodology, in its traditional form, leaves almost no room for unexpected changes or
revisions. If your team has loyally followed the steps of Waterfall nearly to the end of the project
but then faces an unplanned roadblock that necessitates a change in scope or goals, pivoting
won't be easy. You'll have put a considerable amount of work into a project under very specific,
rigid assumptions. A sudden change to the parameters of the project could render much of the
work you've carried out up to that point useless, which can throw off the entire timeline. If your
team's projects are unpredictable or involve frequent change, consider adapting Waterfall to
allow more room for reflection and revision as you go, rather than just at the end, to prevent
wasted time and energy. If you decide to go this route, tailor a Lucidchart template to your team's
version of Waterfall to keep everyone aware of how to use the adjusted process.

2. Excludes the client and/or end user

As an internal process, the Waterfall methodology focuses very little on the end user or client
involved with a project. Its main purpose has always been to help internal teams move more
efficiently through the phases of a project, which can work well for the software world.
However, if you work in an industry other than software, clients often want to be involved during
a project, adding opinions and clarifying what they want as the project moves forward.

If your projects have clear, unchanging goals from the beginning and you aren't responsible for
updating end users or clients through the development process, then Waterfall will probably
work well for your team. In other cases, consider an agile methodology to better anticipate
change and keep stakeholders informed through the life of the project. By involving
stakeholders, you lower the risk of late requests for change throwing off your project deadlines.

3. Delays testing until after completion

Saving the testing phase until the last half of a project is risky, but Waterfall insists that teams
wait until step four out of six to test their products. Outside of the software industry, the testing
phase could mean showing a new website design to a client, A/B testing content, or taking any
number of steps to gain empirical data on the viability of the project. At this point, the project
has likely taken considerable time to complete, so large revisions could cause significant delays.

The agile methodology was created in direct response to this principle of Waterfall. Critics of
Waterfall felt that there was too much room for problems to remain unnoticed until the project
neared completion, which left large, costly changes as the only solution. If you feel that frequent
testing would serve your team better, implement testing at the end of every project stage so that
you don't move forward until you know things are working. Or consider a different project
management methodology that encourages reflection and revision throughout the process.
 CHAPTER-4
What is systems design?
What is system design

Systems design is simply the design of systems. It implies a systematic and rigorous approach to
design an approach demanded by the scale and complexity of many systems problems.

Where did it come from?

Systems design first appeared shortly before World War II as engineers grappled with complex
communications and control problems. They formalized their work in the new disciplines of
information theory, operations research, and cybernetics. In the 1960s, members of the design
methods movement (especially Horst Rittel and others at Ulmand Berkeley) transferred this
knowledge to the design world. Systems design continues to flourish at schools interested in
design planning and within the world of computer science. Among its most important legacies is
a research field known as design rationale, which concerns systems for making and documenting
design decisions.

What can designers learn from systems design?

Today, ideas from design methods and systems design may be more relevant to designers than
ever before as more and more designers collaborate on designing software and complex
information spaces. Frameworks suggested by systems design are especially useful in Modeling
interaction and conversation. They are also useful in modeling the design process itself.
modeling interaction and conversation. They are also useful in modeling

What is the most important thing to be aware of in systems design?

A systems approach to design asks:

For this situation, what is the system? What is the environment?

What goal does the system have in relation to its environment? What is the feedback loop by
which the system corrects its actions? How does the system measure whether it has achieved its
goal? Who defines the system, environment, goal, etc.-and monitors it? What resources does the
system have for maintaining the relationship it desires?

Are its resources sufficient to meet its purpose?

Is systems design incompatible with user-cantered design?

systems approach to design is entirely compatible with a user-cantered approach. Indeed, the
core of both approaches is understanding user goals. systems approach looks at users in relation
to a context and in terms of their interaction with devices, with each other, and with themselves.

What is the relationship between systems design and cybernetics?

Cybernetics (the science of feedback) provides an approach to systems and a set of frameworks
and tools. Among the most important ideas for designers:
Definition of a system depends on point of view.
We are responsible for our actions.
All interaction is a form of conversation
All conversation involves goals, understandings, and agreement.
Are there times when systems design isn't appropriate?
A systems approach to design is most appropriate for projects involving large systems or systems
of systems. Such projects typically involve many people, from many disciplines, working
together over an extendedperiod of time. They need tools to cope with their project's complexity:
to define goals, facilitate communications, and manage processes. Solo designers working on
small projects may find the same tools a bit cumbersome for
their needs.
Explaining ER Diagram
Entity Relationship Diagrams are a major data modelling tool and will help organize the data in
your project into entities and define the relationships between the entities. This process has
proved to enable the analyst to produce a good database structure so that the data can be stored
and retrieved in a most efficient manner.

 Entity - A data entity is anything real or abstract about which we want to store data.
Entity types fall into five classes: roles, events, locations, tangible things or concepts.
E.g. employee, payment, campus, book. Specific examples of an entity are called
instances. E.g. the employee John Jones, Mary Smith's payment, etc.
 Relationship:- A data relationship is a natural association that exists between one or more
entities. E.g. Employees process payments.
 Attribute:- A data attribute is a characteristic common to all ormost instances of a
particular entity. Synonyms include property, data element, field. E.g. Name, address,
Employee Number, pay rate are all attributes of the entity employee. An attribute or
combination of attributes that uniquely identifies one and only one instance of an entity is
called a primary key or identifier. E.g. Employee Number is a primary key for Employee.

What is ER Model?
ER Model stands for Entity Relationship Model is a high-level conceptual data model diagram.
ER model helps to systematically analyze data requirements to produce a well-designed
database. The ER Model represents real-world entities and the relationships between them.
Creating

an ER Model in DBMS is considered as a best practice before

implementing your database.

• ER Modeling helps you to analyze data requirements

systematically to produce a well-designed database. So, it is considered a best practice to

complete ER modeling before implementing your database.

History of ER models
ER diagrams are visual tools that are helpful to represent the ER model. Peter Chen proposed ER
Diagram in 1971 to create a uniform convention that can be used for relational databases and
networks. He aimed to use an ER model as a conceptual modeling approach.

Why use ER Diagrams?

 Here, are prime reasons for using the ER Diagram

 Helps you to define terms related to entity relationship modeling
 Provide a preview of how all your tables should connect, what fields are going to be on
each table
 Helps to describe entities, attributes, relationships
 ER diagrams are translatable into relational tables which allows you to build databases
quickly

ER diagrams can be used by database designers as a blueprint for implementing data in specific
software applications

The database designer gains a better understanding of the information to be contained in the
database with the help of ERP diagram

ERD Diagram allows you to communicate with the logical

structure of the database to users

Facts about ER Diagram Model

Now in this ERD Diagram Tutorial, let's check out some interesting facts about ER Diagram
Model:

ER model allows you to draw Database Design

It is an easy to use graphical tool for modeling data

Widely used in Database Design

It is a GUI representation of the logical structure of a Database It helps you to identifies the
entities which exist in a system and the relationships between those entities

ER Diagrams Symbols & Notations

Entity Relationship Diagram Symbols & Notations mainly contains three basic symbols which
are rectangle, oval and diamond to represent relationships between elements, entities and
attributes. There are some sub-elements which are based on main elements in ERD Diagram. ER
Diagram is a visual representation of data that describes how data is related to each other using
different ERD Symbols and Notations. Following are the main components and its symbols in
ER Diagrams:

 Rectangles: This Entity Relationship Diagram symbol represents entity types

 Ellipses: Symbol represents attributes
 Diamonds: This symbol represents relationship types
 Lines: It links attributes to entity types and entity types with other relationship types
 Primary key: attributes are underlined
 Double Ellipses: Represent multi-valued attributes

ER Diagram Symbols
Relationship

Entity or Strong Entity

Weak Entity

Weak Relationship

Attribute

Multivalued Attribute

Components of the ER Diagram

This model is based on three basic concepts:

 Entities
 Attributes
 Relationships
 ER Diagram Examples:-
For example, in a University database, we might have entities for Students, Courses, and
Lecturers. Students entity can have attributes like Rollno, Name, and DeptID. They might have
relationships with Courses and Lecturers.

WHAT IS ENTITY?
A real-world thing either living or non-living that is easily recognizable recognizable. It is
anything in the enterprise that is to be represented in our database. It may be a physical thing or
simply a fact about the enterprise or an event that happens in the real world.

and non

data in the database. The characteristics of entities are must have an An entity can be place,
person, object, event or a concept, which stores attribute, and a unique key. Every entity is made
up of some 'attributes' which represent that entity.
Examples of entities:
 Person: Employee, Student, Patient Place: Store, Building
 Object: Machine, product, and Car
 Event: Sale, Registration, Renewal Concept: Account, Course
Notation of an Entity
Entity set:
Student
An entity set is a group of similar kind of entities. It may contain entities with attribute sharing
similar values. Entities are represented by their properties, which also called attributes. All
attributes have their separate values. For example, a student entity may have a name, age, class,
as attributes.

A university may have some departments. All these departments employ various lecturers and
offer several programs.

Some courses make up each program. Students register in a particular program and enroll in
various courses. A lecturer from the specific department takes each course, and each lecturer
teaches a various group
of students.
Relationship
Relationship is nothing but an association among two or more entities. E.g., Tom works in the
Chemistry department.

Tom Chemistr
y
 Entities take part in relationships. We can often identify relationships with verbs or verb phrases.
For example:
 You are attending this lecture
 I am giving the lecture
 Just loke entities, we can classify relationships according to
relationship-types:
 A student attends a lecture
 A lecturer is giving a lecture.
Weak Entities
A weak entity is a type of entity which doesn't have its key attribute. It can be identified uniquely
by considering the primary key of another entity. For that, weak entity sets need to have
participation.

ATM Weak
Transaction
Relatio
n

ATM ID Address Time

Trans No Amount Type

In above ER Diagram examples, "Trans No" is a discriminator within a group of

transactions in an ATM.
Attributes
It is a single-valued property of either an entity-type or a relationship- type.
For example, a lecture might have attributes: time, date, duration, place,
etc.
An attribute in ER Diagram examples, is represented by an Ellipse

Cardinality
Defines the numerical attributes of the relationship between two entities or entity sets.
Different types of cardinal relationships are:
 One-to-One Relationships
 One-to-Many Relationships
 May to One Relationships Many-to-Many Relationships
1.One-to-one:
One entity from entity set X can be associated with at most one entity of entity set Y and vice
versa.
Example: One student can register for numerous courses. However, all

Student Course

2.One-to-many:
One entity from entity set X can be associated with multiple entities of entity set Y, but an entity
from entity set Y can be associated with at least one entity.
For example, one class is consisting of multiple students.

Class Student
3. Many to One
More than one entity from entity set X can be associated with at most one entity of entity set Y.
However, an entity from entity set Y may or may not be associated with more than one entity
from entity set X.
For example, many students belong to the same class.

Student Class

4. Many to Many:
One entity from X can be associated with more than one entity from Y
and vice versa.
For example, Students as a group are associated with multiple faculty members, and faculty
members can be associated with multiple students.

Ss STUDENT Faculty Member

How to Create an Entity Relationship Diagram (ERD)

 Now in this ERD Diagram Tutorial, we will learn how to create an ER Diagram. Following are
the steps to create an ER Diagram:

Relationship Cardinality Identify

Entry Identification Create ERD
Identification Identification Attributes

Steps to Create an ER Diagram

Let's study them with an Entity Relationship Diagram Example: In a university, a Student enrolls
in Courses. A student must be assigned to at least one or more Courses. Each course is taught by
a single Professor. To maintain instruction quality, a Professor can deliver only
one course
Step 1) Entity Identification
We have three entities

 Student
 Course
 Professor

Student Course Professor

Step 2) Relationship Identification

We have the following two relationships
 The student is assigned a course
 Professor delivers a course

Student Professor
Course
Assign Deli
ed vers

Step 3) Cardinality Identification For them problem statement we know that, A student can be
assigned multiple courses A Professor can deliver only one course
 Professor
Student Course
Deli
Ass
vers
ign

Step 4) Identify Attributes

You need to study the files, forms, reports, data currently maintained by the organization to
identify attributes. You can also conduct interviews with various stakeholders to identify entities.
Initially, it's important to identify the attributes without mapping them to a particular entity.
Once, you have a list of Attributes, you need to map them to the identified entities. Ensure an
attribute is to be paired with exactly one entity. If you think an attribute should belong to more
than one entity, use a modifier to make it unique.
Once the mapping is done, identify the primary Keys. If a unique key is not readily available,
create one.
For Course Entity, attributes could be Duration, Credits, Assignments, etc. For the sake of ease
we have considered just one attribute.
Step 5) Create the ERD Diagram
A more modern representation of Entity Relationship Diagram Example

Best Practices for Developing Effective ER Diagrams

some best practice or example for Developing Effective ER Diagrams.

 Eliminate any redundant entities or relationships

 You need to make sure that all your entities and relationships are properly labeled
 There may be various valid approaches to an ER diagram. You need to make sure that the
ER diagram supports all the data you need to store
 You should assure that each entity only appears a single time in the
ER diagram
 Name every your diagram relationship, entity, and attribute are represented on
 Never connect relationships to each other
 You should use colors to highlight important portions of the ER
diagram
 Our Practical ER diagram
DFD:DATA FLOW DIAGRAM

A Data Flow Diagram (DFD) is a graphical representation of the "flow" of data through an
information system. A DFD is often used as a preliminary step to create an overview of the
system. DFDS can also be used for the visualization of data processing (structured design).
ADFD shows what kind of information will be input to and output from the system, where the
data will come from and go to, and where the data will bestored. It does not show information
about the timing of process or information about whether processes will operate in sequence or
in parallel.
History
Data flow diagrams were proposed by Larry Constantine. The original developer of structured
design, based on Martin and Estrin's "Data Flow Graph" model of computation. Starting in the
1970s, data flow diagrams (DFD) became a popular way to visualize the major steps and data
involved in software system processes. DFDs were usually used to show data flows in a
computer system, although they could in theory be applied to business process modelling. DFD
were useful to document the major data flows or to explore a new high-level design in terms of
data flow
A data flow diagram represents the following:

Zero-level DFD model:

It is also known as a context diagram. It's designed to be an abstraction view, showing the system
as a single process with its relationship to external entities. It represents the entire system as a
single bubble with input and output data indicated by incoming/outgoing arrows.

Our project 0 Level DFD:-

Futher Explaining the DFD
The Data Flow Diagram has 4 components:
Process
Input to output transformation in a system takes place because of process function. The symbols
of a process are rectangular with rounded corners, oval, rectangle or a circle. The process is
named a short sentence, in one word or a phrase to express its essence
Data Flow
Data flow describes the information transferring between different parts of the systems. The
arrow symbol is the symbol of data flow. A relatable name should be given to the flow to
determine the information which is being moved. Data flow also represents material along with
information that is being moved. Material shifts are modeled in systems that are not merely
informative. A given flow should only transfer a single type of information. The direction of
flow is represented by the arrow which can also be bi- directional.
Warehouse
The data is stored in the warehouse for later use. Two horizontal lines represent the symbol of
the store. The warehouse is simply not restricted to being a data file rather it can be anything like
a folder with documents, an optical disc, a filing cabinet. The data warehouse can be viewed
independent of its implementation. When the data flow from the warehouse it is considered as
data reading and when data flows to the warehouse it is called data entry or data updating.

Terminator
The Terminator is an external entity that stands outside of the system and communicates with the
system. It can be, for example, organizations like banks, groups of people like customers or
different departments of the same organization, which is not a part of the model system and is an
external entity Modeled stems also communicate with terminator.
Rules for creating DFD
 The name of the entity should be easy and understandable without any extra
assistance(like comments).
 The processes should be numbered or put in ordered list to be referred easily.
 The DFD should maintain consistency across all the DFD levels.
 A single DFD can have maximum processes upto 9 and minimum 3 processes.
Levels of DFD
DFD uses hierarchy to maintain transparency thus multilevel DFD's can be created. Levels of
DFD are as follows:
 0-level DFD
1-level DFD:
 2-level DFD:
Advantages of DFD

 It helps us to understand the functioning and the limits of a system.

 It is a graphical representation which is very easy to understand as it helps visualize
contents.
 Data Flow Diagram represent detailed and well explained diagram of system components
 Data Flow Diagrams can be understood by both technical or nontechnical person because
they are very easy to understand
Advantages of DFD
At times DFD can confuse the programmers regarding the system.
Data Flow Diagram takes long time to be generated, and many times due to this reasons analysts
are denied permission to work on it.
 CHAPTER-5
SYSTEM DEVELOPMENT
An effective System Development Life Cycle (SDLC) should result in a high quality system that
meets customer expectations, reaches completion within time and cost evaluations, and works
effectively and efficiently in the current and
planned Information Technology infrastructure.
System Development Life Cycle (SDLC) is a conceptual model which includes policies and
procedures for developing or altering systems throughout their life
cycles.
SDLC is used by analysts to develop an information system. SDLC includes the following
activities
 requirements
 design
 implementation
 testing
 deployment
 operations
 maintenance
Overview
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 is manufactured on an
assembly line, an SDLC aims to produce high-qualitysystems to plan for, design, build, test, and
deliver information systems. Like anything that delivering systems which move through each
clearly defined 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. Computer systems are link multiple
traditional systems potentially supplied by different software vendors. complex and often
(especially with the recent rise of service-oriented architecture) To manage this level of
complexity, a number of SDLC models or methodologies have been created, such as waterfall,
spiral, Agile software development, rapid prototyping, incremental, and synchronize and
stabilize.
SDLC can be described along a spectrum of agile to iterative to sequential processes which allow
for rapid changes (without necessarily following the pattern methodologies. Agile
methodologies, such as XP and Scrum, focus on lightweight of SDLC approach) along the
development cycle. Iterative methodologies, such as Rational Unified Process and dynamic
systems development method, focus on limited project scope and expanding or improving
products by multiple iterations. Sequential or big-design-up-front (BDUF) models, such as
waterfall, focus on complete and correct planning to guide large projects and risks to successful
and predictable results. Other models, such as anamorphic development, tend to focus on a form
of developinent that is guided by project scope and adaptive iterations of feature development.
In project management a project can be defined both with a project life cycle (PLC) and an
SDLC, during which slightly different activities occur. According to Taylor (2004), "the project
life cycle encompasses all the activities ofthe project, while the systems development life cycle
focuses on realizing the product requirements".
The SDLC is not a methodology per se, but rather a description of the phases in the life cycle of
a software application. In a broad sense, these phases are,: investigation, analysis, design, build,
test, implement, and maintenance and support. All software development methodologies follow
the SDLC phases but the method of doing that Varies vastly between methodologies. In the
Scrum framework, for example, one say a single user story goes through all the phases of the
SDLC within a single two-week sprint. Contrast this to the waterfall

Could methodology, as another example, where every business requirement (recorded in

the analysis phase of the SDLC in a document called the Business Requirements Specification) is
translated into feature/functional descriptions (recorded in the design phase in a document called
the Functional Specification) which are then all built in one go as a collection of solution features
typically over a period of three to nine months, or more. These methodologies are different
approaches, yet they both contain the SDLC phases in which a requirement is born, then travels
through the life cycle typically starts again for a subsequent version of the software life cycle
phases ending in the final phase of maintenance and support, after-which

application.
7 Stages of the System Development Life Cycle
There are seven primary stages of the modern system development life cycle.
Here's a brief breakdown:
Planning Stage
Feasibility or Requirements of Analysis Stage
Design and Prototyping Stage
Software Development Stage
0
Software Testing Stage
C
Implementation and Integration
Operations and Maintenance Stage
Now let's take a closer look at each stage individually.
Planning Stage
Before we even begin with the planning stage, the best tip we can give you is to take time and
acquire proper understanding of app development life cycle.
The planning stage (also called the feasibility stage) is exactly what it sounds like: the phase in
which developers will plan for the upcoming project.
It helps to define the problem and scope of any existing systems, as well as determine the
objectives for their new systems.
By developing
an effective outline for the upcoming development cycle, they'll
theoretically catch problems before they affect development.

And help to secure the funding and resources they need to make their plan happen.\
Perhaps most importantly, the planning stage sets the project schedule, which can be of key
importance if development is for a commercial product that must be sent to
market by a certain time.
Analysis Stage
The analysis stage includes gathering all the specific details required for a new system as well as
determining the first ideas for prototypes.
Developers may:
 Define any prototype system requirements
 Evaluate alternatives to existing prototypes
 Perform research and analysis to determine the needs of end-users
Furthermore, developers will often create a software requirement specification or SRS document.
This includes all the specifications for software, hardware, and network requirements for the
system they plan to build. This will prevent them from overdrawing funding or resources when
working at the same place as other development teams.
Design Stage
The design stage is a necessary precursor to the main developer stage. Developers will first
outline the details for the overall application, alongside specific
aspects, such as its:
 User interfaces
 System interfaces
 Network and network requirement
 Databases
They'll typically turn the SRS document they created into a more logical structure that can later
be implemented in a programming language. Operation, training, and maintenance plans will all
be drawn up so that developers know what they need to
do throughout every stage of the cycle moving forward.
Once complete, development managers will prepare a design document to be referenced
throughout the next phases of the SDLC.
Development Stage
The development stage is the part where developers actually write code and build the application
according to the earlier design documents and outlined specifications.
This is where Static Application Security Testing or SAST tools come into play. Product
program code is built per the design document specifications. In theory, all of the prior planning
and outlined should make the actual development phase relatively straightforward.
Developers will follow any coding guidelines as defined by the organization and utilize different
tools such as compilers, debuggers, and interpreters.
Programming languages can include staples such as C++, PHP, and more. Developers will
choose the right programming code to use based on the project specifications and requirements.
Testing Stage
Building software is not the end. Now it must be tested to make sure that there aren't any bugs
and that the end-user experience will not negatively be affected at any point.

During the testing stage, developers will go over their software with a fine-tooth comb, noting
any bugs or defects that need to be tracked, fixed, and later retested. It's important that the
software overall ends up meeting the quality standards that were previously defined in the SRS
document.
Depending on the skill of the developers, the complexity of the software, and the requirements
for the end-user, testing can either be an extremely short phase or take a very long time.
Implementation and Integration Stage

After testing, the overall design for the software will come together. Different modules or
designs will be integrated into the primary source code through developer efforts, usually by
leveraging training environments to detect further errors or defects.
The information system will be integrated into its environment and eventually installed. After
passing this stage, the software is theoretically ready for market and may be provided to any end-
users.
Maintenance Stage

The SDLC doesn't end when software reaches the market. Developers must now move into a
maintenance mode and begin practicing any activities required to handle Issues reported by end-
users.
are responsible for implementing any changes that the
Furthermore, developers Software might need after deployment
This can include handling residual bugs that were not able to be patched before launch or
resolving new issues that crop up due to user reports. Larger systems may
require longer maintenance stages compared to smaller systems.
Role of System Analyst
An SDLC's system analyst is, in some ways, an overseer for the entire system. They should be
totally aware of the system and all its moving parts and can help guide the
project by giving appropriate directions.
The system analyst should be:
 An expert in any technical skills required for the project
 A good communicator to help command his or her team to success
 A good planner so that development tasks can be carried out on time at each phase of the
development cycle
Thus, systems analysts should have an even mix of interpersonal, technical, management, and
analytical skills altogether. They're versatile professionals that can make or break an SDLC.
Their responsibilities are quite diverse and important for the eventual success of a given project.
Systems analysts will often be expected to:
Gather facts and information
Make command decisions about which bugs to prioritize or
features to cut
• Suggest alternative solutions
what
Draw specifications that can be easily understood by both users and
programmers

• Implement logical systems while keeping modularity for later

integration
 Be able to evaluate and modify the resulting system as is required
by project goals
  Help to plan out the requirements and goals of the project by defining and understanding
user requirements
Basic SDLC Methodologies
Although the system development life cycle is a project management model in the broad sense,
six more specific methodologies can be leveraged to achieve specific results or provide the
greater SDLC with different attributes.
Waterfall Model:
The waterfall model is the oldest of all SDLC methodologies. It's linear and straightforward and
requires development teams to finish one phase of the project completely before moving on to
the next.
Each stage has a separate project plan and takes information from the previous stage to avoid
similar issues (if encountered). However, it is vulnerable to early delays and can lead to big
problems arising for development teams later down the road.
Iterative Model:
The iterative model focuses on repetition and repeat testing. New versions of a software project
are produced at the end of each phase to catch potential errors and allow developers to constantly
improve the end product by the time it is ready for market
One of the upsides to this model is that developers can create a working version of are often less
expensive. the project relatively early in their development life cycle, so implement the changes
Spiral Model:
Spiral models are flexible compared to other methodologies. Projects pass through four main
phases again and again in a metaphorically spiral motion.
It's advantageous for large projects since development teams can create very customized
products and incorporate any received feedback relatively early in the life cycle.
V-Model:
The V-model (which is short for verification and validation) is quite similar to the waterfall
model. A testing phase is incorporated into each development stage to catch potential bugs and
defects.
It's incredibly disciplined and requires a rigorous timeline. But in theory, it illuminates the
shortcomings of the main waterfall model by preventing larger bugs from spiraling out of
control.
Big Bang Model:
The Big Bang model is incredibly flexible and doesn't follow a rigorous process or procedure. It
even leaves detailed planning behind. It's mostly used to develop broad ideas when the customer
or client isn't sure what they want. Developers simply start the project with money and resources
Their output may be closer or farther from what the client eventually realizes they desire. It's
mostly used for smaller projects and experimental life cycles designed to inform other projects in
the same company.
Agile Model:
The agile model is relatively well-known, particularly in the software development industry.
The agile methodology prioritizes fast and ongoing release cycles, utilizing small but
incremental changes between releases. This results in more iterations and many more tests
compared to other models.
Theoretically, this model helps teams to address small issues as they arise rather than missing
them until later, more complex stages of a project.
Benefits of SDL: SDLC provides a number of advantages to development teams that implement
it correctly.
Clear Goal Descriptions
Developers clearly know the goals they need to meet and the deliverables they must achieve by a
set timeline, lowering the risk of time and resources being wasted.
Proper Testing Before Installation
SDLC models implement checks and balances to ensure that all software is tested before being
installed in greater source code

Developers can't move on to the next age until the prior one is completed and
Member Flexibility
Since SDLCs have well-structured documents for project goals and methodologies, members can
leave and be replaced by new members relatively painlessly
Perfection Is Achievable
All SDLC stages are meant to feed back into one another. SDLC models can therefore help
projects to iterate and improve upon themselves over and over until essentially perfect.
No One Member Makes or Breaks the Project
Again, since SDLCs utilize extensive paperwork and guideline documents, it's a team effort and
losing one even major member will not jeopardize the project timeline.
What You Need to Know About System Development Life Cycle
Where is SDLC Used?
System development life cycles are typically used when developing IT projects. Software
development managers will utilize SDLCs to outline various development stages, make sure
everyone completes stages on time and in the correct order, and e project is delivered as
promptly and as bug-free as possible.
SDLCs can also be more specifically used by systems analysts as they develop and later
implement a new information system.

What SDLC Model is Best?

It largely depends on what your team's goals and resource requirements are. The majority of IT
development teams utilize the agile methodology for their SDLC. However, others may prefer
the iterative or spiral methodologies.
All three of these methods are popular since they allow for extensive iteration and bug testing
before a product is integrated with greater source code or delivered to market.
DevOps methodologies are also popular choices. And if you ever need a refresher course on
what is DevOps, you needn't worry as our team at Cloud Defense has got you covered!
What Does SDLC Develop?

SDLC can be used to develop or engineer software, systems, and even information systems. It
can also be used to develop hardware or a combination of both software and hardware at the
same time.
 CHAPTER-6
System Implementation
Implementation is a process of ensuring that the information system is operational.
It involves
 Constructing a new system from scratch
 Constructing a new system from the existing one.
Implementation allows the users to take over its operation for use and evaluation. It involves
training the users to handle the system and plan for a smooth conversion.
 Training
The personnel in the system must know in detail what their roles will be, how they can use the
system, and what the system will or will not do. The success or failure of well-designed and
technically elegant systems can depend on the way they are operated and used.
Training Systems Operators
Systems operators must be trained properly such that they can handle all possible operations,
both routine and extraordinary. The operators should be trained in what common malfunctions
may occur, how to recognize them, and what steps to take when they come.
Training involves creating troubleshooting lists to identify possible problems and remedies for
them, as well as the names and telephone numbers of individuals to contact when unexpected or
unusual problems arise. Training also involves familiarization with run procedures, which
involves working through the sequence of activities needed to use a new system.

User Training
End-user training is an important part of the computer-based information system development,
which must be provided to employees to enable them to do their own problem solving.
User training involves how to operate the equipment, troubleshooting the system problem,
determining whether a problem that arose is caused by the equipment or software.
Most user training deals with the operation of the system itself. The training courses must be
designed to help the user with fast mobilization for the organization.
 CHAPTER-7
System Testing:
Testing which is major part of creating our website as we want customer to use a problem free
Parking Website, for this we test the site over multiple browsers and devices to check weather its
working like supposed to. As at this point the URL is private and should launch after being
confirm all the things.
System testing involves the execution of a software component or system component to evaluate
one or more properties of interest. In general, these properties indicate the extent to which the
component or system under test:
 meets the requirements that guided its design and development,
 responds correctly to all kinds of inputs,
 performs its functions within an acceptable time,
 it is sufficiently usable,
 can be installed and run in its intended environments, and
 achieves the general result its stakeholders desire.
Finally we arrive at system testing, where the software and other system elements
are tested as a whole.
Manual testing:
A key step in the process is testing the software for correct behavior prior to release
to end users.
For small scale engineering efforts (including prototypes), exploratory testing may be sufficient.
With this informal approach, the tester does not follow any rigorous testing procedure, but rather
explores the user interface of the application using as many of its features are the possible, using
information gained in prior tests to intuitively derive additional tests. The success of exploratory
manual testing relies heavily on the domain expertise of the tester, because a lack of knowledge
will lead to incompleteness in testing. One of the key advantages of an informal approach is to
gain an intuitive insight to how it feels to use the application.
Choose a high level test plan where a general methodology is chosen, and resources such as
people, computers, and software licenses are identified and acquired.
Write detailed test cases, identifying clear and concise steps to be taken by the tester, with
expected outcomes.
Assign the test cases to testers, who manually follow the steps and record the results. Author a
test report, detailing the findings of the testers. The report is used by managers to determine
whether the software can be released, and if not, it is used by engineers to identify and correct
the problems.
A rigorous test case based approach is often traditional for large software engineering projects
that follow a Waterfall model. However, at least one recent study did not show a dramatic
difference in defect detection efficiency between exploratory testing and test case based testing..
Testing can be through black-, white- or grey-box testing. In white-box testing the tester is
concerned with the execution of the statements through the source code. In black-box testing the
software is run to check for the defects and is less concerned with how the processing of the
input is done. Black-box testers do not have access to the source code. Grey-box testing is
concerned with running the software while

having an understanding of the source code and algorithms.[citation needed]

Static and dynamic testing approach may also be used. Dynamic testing involves running the
software. Static testing includes verifying requirements, syntax of code and any other activities
that do not include actually running the code of theprogram. Testing can be further divided into
functional and non-functional testing. In functional testing the tester would check the
calculations, any link on the page, or any other field which on given input, output may be
expected. Non-functional testing includes testing performance, compatibility and fitness of the
system under test, its security and usability among other things.
Manual testing is the process of manually testing software for defects. It requires a tester to play
the role of an end user whereby they use most of the application's features to ensure correct
behavior. To guarantee completeness of testing, the tester often follows a written test plan that
leads them through a set of important test cases.
Stages:
Unit Testing:
Unit testing focuses verification effort on the smallest unit of software design, the
module.
Unit tests are typically automated tests written and run by software developers to ensure that a
section of an application (known as the "unit") meets its design and behaves as intended. In
procedural programming, a unit could be an entire module programming, a unit is often an entire
interface, such as a class, or an individual method. By writing tests first for the smallest testable
units, then the compound behaviors between those, one can build up comprehensive tests for
complex applications.
but it is more commonly an individual function or procedure. In object-oriented
During development, a software developer may code criteria, or results that are known to be
good, into the test to verify the unit's correctness. During test case execution, frameworks log
tests that fail any criterion and report them in a summary. For this, the most commonly used
approach is test - function - expected value.
Conditional Testing:
In this part of the testing each of the conditions were tested to both true and false aspects. And all
the resulting paths were tested. So that each path that may be generate on particular condition is
traced to uncover any possible errors.
Data Flow Testing:
This type of testing selects the path of the program according to the location of definition and use
of variables. This kind of testing was used only when some local variable were declared. The
definition-use chain method was used in this type of testing. These were particularly useful in
nested statements.
Loop Testing:
In this type of testing all the loops are tested to all the limits possible. All the loop
were tested at their limits, just above them and just below them. All the loops were skipped at
least once. For nested loops test, the inner most loop first and then work outwards. For
concatenated loops, the values of dependent loops were set with the help of connected loop.
Unstructured loops were resolved into nested loops or concatenated loops and tested as above.
Alpha testing:
Alpha testing is simulated or actual operational testing by potential users/customers or an
independent test team at the developers' site. Alpha testing is often employed for off-the-shelf
software as a form of internal acceptance testing, before the software goes to beta testing.
Beta testing:
Beta testing comes after alpha testing and can be considered a form of external user acceptance
testing. Versions of the software, known as beta versions, are released to a limited audience
outside of the programming team. The software is released to groups of people so that further
testing can ensure the product has few faults or bugs. Sometimes, beta versions are made
available to the open public to increase the feedback field to a maximal number of future users
White-Box testing:
White-box testing (also known as clear box testing, glass box testing, transparent box testing,
and structural testing) tests internal structures or workings of a program, as opposed to the
functionality exposed to the end-user. In white-box

Testing an internal perspective of the system, as well as programming skills, are used to design
test cases. The tester chooses inputs to exercise paths through the code and determine the
appropriate outputs. This is analogous to testing nodes in a circuit, in-circuit testing (ICT).
e.g.
While white-box testing can be applied at the unit, integration and system levels of the software
testing process, it is usually done at the unit level. It can test paths within a unit, paths between
units during integration, and between subsystems during a system-level test. Though this method
of test design can uncover many errors or problems, it might not detect unimplemented parts of
the specification or missing requirements.
Black box testing:
Black box testing treats the software as a "black box"-without any knowledge of internal
implementation. Black box testing methods include: equivalence partitioning, boundary value
analysis, all-pairs testing, fuzz testing, model-based testing, exploratory testing and specification-
based testing.
 CHAPTER-8
FUTURE SCOPE
In a nutshell, it can be summarized that the future scope of the project circles around maintaining
information regarding following:
We can give more advance software for online book store including more facilities. We will host
the platform on online servers to make it accessible worldwide. Integrate multiple load balancers
to distribute the loads of the system.
Create the backup mechanism for taking backup of codebase and database on regular basis on
different servers.

The above-mentioned points are the enhancements which can be done to increase the
applicability and usage of this project, here we can maintain the records of Books and stock.
Also, as it can be seen that now-a-days the players are versatile, I.e., so there is a scope for
introducing a method to maintain the
Online Bookstore. Enhancements can be done to maintain all Books, stock, Customer, Order,
Payment.
 CHAPTER -9
Conclusion:

One of the most common problems today for a small-scale business face is there presence and its
name in the market. In The pandemic most of small-scale business went downhill because of
lack of customers as everybody was stuck in their home or they were Doing online shopping. Is
to find a specific deal which offer the best of service according to our needs. Online Bookstore as
the name suggested is a website through which we provide an local bookstore an online presence
to their business in online(global) scale everyone who wants to Discover the joy of buying is
provided the service as same as a local bookstore.
Our project is only a humble venture to satisfy the needs to manage their project work. Several
user-friendly coding has also adopted. This package shall prove to be a powerful package in
satisfying all the requirement of the school. The objective of software planning is to provide a
frame work that enables the managers to make reasonable estimate made within a limited time
frame at the beginning of the software project and should be updated regularly as the project
progresses.

In the last we would like to thanks all the persons involved in the development of the system
directly or indirectly. We hope that the project will serve its purpose for which it is develop there
by underlining success of process.
 References:

Research papers:
 Distributed traveling Development Process Astro Grid Experience by Pedro
Contreras
 Anne-Mai Aadamsoo WEB BASED PROJECT MANAGEMENT SYSTEM Technology
and Communication 2010
 . Software project management: from concept to deployment / Kieron Conway.
Scottsdale (Ariz.): Coriolis, c2001
 Information systems project management: methods, tools and techniques / John
McManus and Trevor Wood-Harper, Harlow [etc.]: Prentice Hall, c2003
 https://www.scribd.com/document/342098884/Synopsis-of-Online-Book-
Store
 https://www.academia.edu/Documents/in/Web_Application_Development_
with_php_mysql
Websites:
1. www.en.wikipedia.org
2. www.javapoint.com
3. www.tutorialpoint.com
4. www.w3schools.com
5. www.freeprojectz.com/synopsis
6. www.researchgate.net/publication
Books:
 The complete reference by Thomas A. Powell
 Head First HTML with CSS by Chris Schalk www.(Author), Ed Burns (Author), James
Holmes.
 HTML BLACK BOOK.
 The Best-Practice Guide to XHTML by Patrick Griffiths.
 JavaScript book