PROJECT REPORT

ON

Online Book Store

SUBMITTED BY

MONIKA MATHUR

(ENROLLMENT NO: 1115603729)

In partial fulfillment of the requirement for the award of the degree of

MASTER OF COMPUTER APPLICATIONS

OF

MAHARISHI DYANANAD UNIVERSITY,ROHTAK

 TABLE OF CONTENTS

1) INTRODUCTION

2) FEASIBILITY STUDY

3) ANALYSIS

4) HARDWARE REQUIREMENTS

5) SOFTWARE REQUIREMENTS

6) REQUIREMENT ANALYSIS

7) PROJECT DESIGN

7.1 DATA MODEL

7.1.1 Database Design

7.2. PROCESS MODEL

7.2.1. Functional Decomposition Diagram
7.2.2 Data Flow Diagram (DFD)
7.3 USER INTERFACE DESIGN

8) TESTING

9) IMPLIMENTATION

10) LIMITATIONS AND FUTURE DEVELOPMENT

11) CONCLUSION

12) BIBLIOGRAPHY

2
1) INTRODUCTION

E-commerce is fast gaining ground as an accepted and used business paradigm.

More and more business houses are implementing web sites providing functionality for
performing commercial transactions over the web. It is reasonable to say that the process of
shopping on the web is becoming commonplace. The objective of this project is to develop a
general purpose e-commerce store where any product (such as books, CDs, computers, mobile
phones, electronic items, and home appliances) can be bought from the comfort of home
through the Internet. However, for implementation purposes, this paper will deal with an
online book store. An online store is a virtual store on the Internet where customers can
browse the catalog and select products of interest. The selected items may be collected in a
shopping cart. At checkout time, the items in the shopping cart will be presented as an order.
At that time, more information will be needed to complete the transaction. Usually, the
customer will be asked to fill or select a billing address, a shipping address, a shipping option,
and payment information such as credit card number. An e- mail notification is sent to the
customer as soon as the order is placed. Electronic Commerce (e-commerce) applications
support the interaction between
different parties participating in a commerce transaction via the network, as well as the
management of the data involved in the process.

STATEMENTOF THE PROJECT

To develop an application which will provide a System for all the activities carried out in a book store.

3
2) FEASIBILITY STUDY

The feasibility study purposes one or more conceptual solutions to the problem set for project.
The conceptual solutions give an idea of what the new system will look like. They define
what will be done on computer and what will remain manual. They also indicate what inputs
the system and outputs will be needed will produce. These solutions must be accepted.
Feasibility study is done so that an ill-conceived system is recognized early in definition
phase. During system engineering however, we concentrate our attention on four primary area
of interest:

 ECONOMIC FEASIBILITY: In economic feasibility, in comparing weigh of costs of

developing and implementing a new system, against the benefits that would accrue from having a
new system in plac

 TECHNICAL FEASIBILITY: A study of function, performance & constraints that may

affect the ability to achieve an acceptable system. In technical feasibility, configuration of
the system is given more importance than the actual make of hardware. The configuration
should give the complete picture about the system’s requirement. The code structure used
is technically effective.

 OPRATIONAL FEASIBILITY: It is mainly related to human organizational and political

aspects. It is carried out by a small group of people who are familiar with information
system techniques, who understand the parts of business that are relevant to the project
and are skilled in system analysis and design process.

4
3) ANALYSIS

USER REQUIREMENTS:-

Besides all the jobs that were being done in the existing system, the user expected certain
other features to be added to the package. Since the existing system is manual, reports are not
generated but in the proposed system reports are required at different queries. In the manual
system, all return items were not obtained but in the proposed system, user requires to
generate these ranges.

PERFORMANCE REQUIREMENTS:-

The following performance characteristics are taken care of while developing the system:

 User Friendliness:
The system is easy to learn and understand. A native user can also use the system
effectively, without any difficulty.

 User Satisfaction:
The system is such that it stands up to the user expectations.

 Response Time:
The response time of all the operations is good. This has been made possible by careful
programming.

5
 Safety And Robustness:
The system is able to avoid or tackle disastrous action. In other words, it should be foul-
proof. The system safeguards against undesired events without human intervention.

 Error Handling:
Response to user errors and undesired situations has been taken care of to ensure that the
system operates without halting.

6
4) HARDWARE REQUIREMENTS

Processor : Intel Pentium (IV)

Motherboard : Intel 845 chipset

RAM : 256MB

Hard Disk Space : 80GB

Video : 1024*768,256 Colors

: High Color 32-bit

Operating System : WINDOWS

7
 5) SOFTWARE REQUIREMENTS

TECHNOLOGIES

(A): Visual Studio 2010

(B): SQL Server or MS access: database

Development Tool:

Visual Studio 2010 IDE.

8
 Database:

SQL Server 2005 or MS access

Platform:

Microsoft Windows 7 Operating System.

METHODOLOGIES

1. Object Oriented Approach.

2. Centralized Database.

9
6) REQUIREMENT ANALYSIS

(A) FUNCTIONAL REQUIREMENTS:-

The functionality of the software is clearly divided into two parts-:

 One part corresponds to the basic information that is stored and needed to be
retrieved.

 Second part is for reflecting the current changes and updates (i.e. day to day) into
the existing database for future requirements.

(B) NON-FUNCTIONAL REQUIREMENTS:-

It deals with the characteristics of the system that can’t be expressed as functions e.g.
Maintainability,

Portability, Reliability, Accuracy; Interface and constraints on the system implementation.

As per the point of view of the maintainability, this software is easy to maintain there is
less need for updating of the software.

General

Requirement Analysis is a software engineering task that bridges the gap between system level
requirements engineering and software design.

In the proposed project Software Requirement Analysis has been divided into five areas of effort as
follows :-

(a) Problem Recognition.

(b) Evaluation and Synthesis.

(c) Modeling.

10
 (d) Specification.

(e) Review.

Requirements Elicitation for the Software

Before requirements can be analyzed, modeled, or specified they are gathered through an elicitation
process. Context free questions were asked to the management people belonging to different
organizations/ institutes and a few Indian Army Officers posted in Meerut, regarding how they would
characterize a good output that would generate a successful solution, what kind of problems will this
solution address, how they describe the environment in which the solution will be used and will
special performance issues or constraints affect the way the solution is approached.

Quality Function Deployment

Quality function deployment (QFD) is a quality management technique that translates the needs of the
customer into technical requirements for the development of the software. In QFD three types of
requirement are identified:-.

(a) Normal Requirements.

(i) Graphical display.
(ii) Fully Menu driven.
(iii) Intuitive key assignments and user interactive screen.
(iv) User Configurable.
(v) Back up and restore facilities.
(vi) Search Facilities.
(vii) Facility to add, delete, modify an entry/ record/ case.
(viii) Report Generation.
(b) Expected Requirements. These requirements are implicit to the product or
system and may be so fundamental that the customer does not state them. The
following are listed:-
(i) Indexing.
(ii) Ease of human/ machine interaction.
(iii) Reliability and operational correctness.
(iv) Ease of software installation.
(v) Single point data storage for each data element.

11
 (vi) Maintenance of integrity and inter-linkages of data.
(vii) Extensive query facility to provide immediate answers for
management.
(viii) Matching of physical and logical movement of files.
(ix) Should be upgradeable to incorporate new features.
(x) Should be expandable.
(xi) Should have fastest possible response while processing queries, reports
and updates.

(c) Exciting Requirements.

(i) Help features.
(ii) Error control mechanism.
(iii) Tool tip text display.
(iv) Other look and feel appeals.
(d) Security Requirements. The following security requirements are considered
in this project :-
(i) User Level Authentication.
(ii) Restricted Menu access.
(iii) Back Up and Restore.
(e) Functional Requirements. The current project in hand should have the
following functional requirements:-
(i) It should allow an entry of new cases.
(ii) It should include the provision of inclusion and modification and
deletion of new profile.
(iii) It should be able to process the tracking details related to a particular
case.
(iv) It should generate various reports related to cases.

12
7) PROJECT DESIGN

In order to design a web site, the relational database must be designed first.
Conceptual design can be divided into two parts: The data model and the process
model. The data model focuses on what data should be stored in the database while the
process model deals with how the data is processed. To put this in the context of the
relational database, the data model is used to design the relational tables. The process
model is used to design the queries that will access and perform operations on those
tables.

13
7.1 Data Model
A data model is a conceptual representation of the data structures that are required
by a database. The first step in designing a database is to develop an Entity-Relation
Diagram (ERD). The ERD serves as a blue print from which a relational database maybe
deduced. Figure shows the ERD for the project and later we will show the
transformation from ERD to the Relational model.

entity A matches exactly one record in entity B and every record in B matches exactly
one record in A. One to many means that every record in A matches zero or more records
in B and every record in B matches exactly one record in A. If there is a one to many
relationship between two entities, then these entities are represented as Associative
Entities. In the Relational Database model, each of the entities will be transformed into a

14
table. The tables are shown below along with the attributes.

7.1.1 Database Design

In this section, the basic structure of the tables composing the database for the
project are shown along with information about primary and foreign keys.

Members Table

15
Editorial Categories Table

Categories Table

16
Credit Card Types Table

Orders Table

17
Editorials Table

7.2 Process Model

A Process Model tells us about how the data is processed and how the data flows
from one table to another to gather the required information. This model consists of the
Functional Decomposition Diagram and Data Flow Diagram.

7.2.1 Functional Decomposition Diagram

A decomposition diagram shows a top-down functional decomposition of a
system and exposes the system's structure. The objective of the Functional
Decomposition is to break down a system step by step, beginning with the main function
of a system and continuing with the interim levels down to the level of elementary
functions. The diagram is the starting point for more detailed process diagrams, such as
data flow diagrams (DFD). Figure shows the Functional Decomposition Diagram for
this project.

18
19
7.2.2 Data Flow Diagram (DFD)
Data Flow Diagrams show the flow of data from external entities into the system,
and from one process to another within the system. There are four symbols for drawing a
DFD:
1. Rectangles representing external entities, which are sources or destinations of
data.
2. Ellipses representing processes, which take data as input, validate and process it
and output it.
3. Arrows representing the data flows, which can either, be electronic data or
physical items.
4. Open-ended rectangles or a Disk symbol representing data stores, including
electronic stores such as databases or XML files and physical stores such as filing
cabinets or stacks of paper.
Figures are the Data Flow Diagrams for the current system. Each process within
the system is first shown as a Context Level DFD and later as a Detailed DFD. The
Context Level DFD provides a conceptual view of the process and its surrounding input,
output and data stores. The Detailed DFD provides a more detailed and comprehensive
view of the interaction among the sub-processes within the system.

20
Customer-Browse Context DFD

Customer-Browse Detailed DFD

21
Customer - ShoppingCart Context DFD

Customer - ShoppingCart Detailed DFD

22
Authenticated User-Purchase DFD

23
7.3 User Interface Design
Before implementing the actual design of the project, a few user interface designs
were constructed to visualize the user interaction with the system as they browse for
books, create a shopping cart and purchase books. The user interface design will closely
follow our Functional Decomposition Diagram. Figures show the initial designs of the web
pages.

24
Home Page

25
Registration

26
Login

27
Administration Main Page

28
Administration Members

29
Administration Orders

30
Administration Books

31
Administration Categories

32
Administration Editorials

33
Administration Editorial Category

34
Administration Credit card Types

35
Shopping Cart

36
Searching

37
Advance Search

38
Categories

39
Book Details

40
8) TESTING

Software Testing is a critical element of software quality assurance and represents the ultimate review
of specification, design and code generation. The increasing visibility of software as a system element
and the attendant “costs” associated with a software failure are motivating forces for well planned,
thorough testing.

Testing Objectives
The following are the testing objectives:
(a) Testing is a process of executing a program with the intent of finding an error.
(b) A good test case is one that has a high probability of finding an as-yet-
undiscovered error.
(c) A successful test is one that uncovers an as yet undiscovered error.
Testing Principles
The basic principles that guide software testing are as follows:
(a) All tests should be traceable to customer requirements.
(b) Tests should be planned long before testing begins.
(c) The Pareto principle applies to software testing. Pareto principle states that 80
percent of all errors uncovered during testing will likely be traceable to 20 percent of
all program components.
(d) Testing should begin “ in the small “ and progress toward testing “ in the
large”.
(e) Exhaustive testing is not possible.
(f) To be most effective, testing should be conducted by an independent third
party.

41
Testability
Software Testability is simply how easily (a computer program can be tested). The following
characteristics are considered that lead to testable software.
(a) Operability: “ The better it works, the more efficiently it can be tested”.
(b) Observability: “ What you see is what you test”.
(c) Controllability: “ The better we can control the software, the more the testing
can be automated and optimized.”
(d) Decomposability: “ By controlling the scope of testing, we can more quickly
isolate problems and perform smarter retesting.
(e) Simplicity: “ The less there is to test, the more quickly we can test it.”
(f) Stability: “ The fewer the changes, the fewer the disruptions to testing.”
(g) Understandability: “ the more information we have, the smarter we will test.
Test Case Design
The design of testing can be divided into two broad categories :-
(a) Black Box testing.
(b) White Box Testing.
Black Box Testing. When computer software is considered, black-box testing alludes to tests
that are conducted at the software interface. Although they are designed to uncover errors,
black-box tests are used to demonstrate that software functions are operational, that input is
properly accepted and output is correctly produced and that the integrity of external
information (e.g a database) is maintained.

White Box Testing. White box testing of software is predicated on close examination of
procedural detail. Logical paths through the software are tested by providing test cases that
exercise specific sets of conditions and /or loops. The main disadvantage with white box
testing is even for smaller programs the number of possible logical paths can be very very
large.
In the present project Black Box testing is used.
Software Testing Strategies
Software testing is one element of a broader topic that is often referred to as Verification and
Validation (V & V). Verification refers to the set of activities that ensure that software

42
correctly implements a specific function. Validation refers to a different set of activities that
ensure that the software that has been built is traceable to customer requirements. In other
words V & V can be stated as :-
(a) Verification: “ Are we building the product right”.
(b) Validation: “ Are we building the right product”.
The following issues were considered for a successful software testing strategy is to be
implemented :-
(a) Specify product requirements in a quantifiable manner long before testing
commences.

(b) State testing objectives explicitly.

(c) Understand the users of the software and develop a profile for each user category.

(d) Develop a testing plan that emphasizes “ rapid cycle testing.”

(e) Build “robust” software that is designed to test itself.

(f) Use effective formal technical reviews as a filter prior to testing.

(g) Conduct formal technical reviews as filter prior to testing.

(h) Conduct formal technical reviews to assess the test strategy and test cases themselves.

(j) Develop a continuous improvement approach for the testing.

Unit Test Procedures

Unit testing is normally considered as an adjunct to the coding step. After source code is developed,
reviewed and verified, test cases were established. Functional behavioral were tested for each module.
In the present project the following unit test were conducted :-

(a) Entering new case details including modifications and successfully tracking various
cases based on inputs by the user.

(b) Validation of member/ client details.

(d) Submission of Data in the database.

(e) Automatic retrieval of data from the database.

43
 (f) Automatic display of options in the front end depending on the option selected by the
user.

(g) Output on securities deposited by clients.

(h) Results of searching for clients/ profiles/ cases.

(j) Generation of Reports.

For example, where user selects New Case, the relevant menu/ form for the entry of New Case should
open up automatically. Any entries made by the user should be correctly stored in the relevant
database. Similar behavior is being tested for other menus/ forms and entries.

Integration Testing
Integration testing is a systematic technique for constructing the program structure while at
the same time conducting tests to uncover errors associated with interfacing. In the present
project the main interfaces of the system are as follows :-
(a) Interface with Database.

(b) Interface with Reports generation.

Validation Testing
Software validation is achieved through a series of Black Box tests that demonstrate
conformity with requirements. Validation checks have been performed for all the units/
functions described in the requirements specifications. In the present project the following
validations were checked :-
(a) Whether the fields (such as Number field) starts with a characters or contains
special characters
(b) Whether the character fields starts with number fields
(c) Whether the functions such as calculation of result/ performance is done
properly or not.
(d) Whether valid and required data is send into the database.
Under Validation testing two types of test are described :-

44
 (a) Alpha Testing. The alpha test is conducted at the developers site by a
customer.
(b) Beta Testing. The Beta Test is conducted at one or more customer sites.

System Testing
System testing fall outside the scope of the software process and are conducted solely by
software engineers. It includes the following :-
(a) Recovery testing
(b) Security testing
(c) Stress testing
(d) Performance testing
Considering the fact that the present project is not much large to invite System testing, this
test has not been performed for the present project.

45
9) IMPLEMENTATION

Implementation of the present project can be simply done by doing it live on server.Before installing
the project at client side its better to implement the software as a parallel run in order to test the
software function. This time period can be between 15 days to 2 months. Later if the system shows a
efficient functionality then the software can be used in complete and then the old system can be
discarded, if present

46
10) LIMITATIONS AND FUTURE DEVELOPMENT

There are some limitations for the current system to which solutions can be
provided as a future development:
1. The Website is not accessible to everyone. It can be deployed on a web
server so that everybody who is connected to the Internet can use it.
2. Credit Card validation is not done. Third party proprietary software can be
used for validation check.
As for other future developments, the following can be done:
1. The Administrator of the web site can be given more functionality, like
looking at a specific customer’s profile, the books that have to be
reordered, etc.
2. Multiple Shopping carts can be allowed.

47
11) CONCLUSION

The Internet has become a major resource in modern business, thus electronic shopping has
gained significance not only from the entrepreneur’s but also from the customer’s point of
view. For the entrepreneur, electronic shopping generates new business opportunities and for
the customer, it makes comparative shopping possible. As per a survey, most consumers of
online stores are impulsive and usually make a decision to stay on a site within the first few
seconds. “Website design is like a shop interior. If the shop looks poor or like hundreds of
other shops the customer is most likely to skip to the other site”. Hence we have designed the
project to provide the user with easy navigation, retrieval of data and necessary feedback as
much as possible.
In this project, the user is provided with an e-commerce web site that can be used to buy
books online. To implement this as a web application we used ASP.NET as the Technology.
ASP.NET has several advantages such as enhanced performance, scalability, built- in security
and simplicity. To build any web application using ASP.NET we need a programming
language such as C#, VB.NET, J# and so on. C# was the language used to build this
application. For the client browser to connect to the ASP.NET engine we used Microsoft’s
Internet Information Services (IIS) as the Web Server.ASP.NET uses ADO.NET to interact
with the database as it provides in-memory caching that eliminates the need to contact the
database server frequently and it can easily deploy and maintain an ASP.NET application.
SQL Server or MS access was used as back-end database since it is one of the most popular
open source databases, and it provides fast data access, easy installation and simplicity.
A good shopping cart design must be accompanied with user-friendly shopping
cart application logic. It should be convenient for the customer to view the contents of
their cart and to be able to remove or add items to their cart. The shopping cart
application described in this project provides a number of features that are designed to
make the customer more comfortable.
This project helps in understanding the creation of an interactive web page and
the technologies used to implement it. The design of the project which includes Data
Model and Process Model illustrates how the database is built with different tables, how
the data is accessed and processed from the tables. The building of the project has given

48
me a precise knowledge about how ASP.NET is used to develop a website, how it
connects to the database to access the data and how the data and web pages are modified
to provide the user with a shopping cart application.

49
12) BIBLIOGRAPHY

Articles
1. Chen, L. (2000). Enticing Online Consumers: A Technology Acceptance
Perspective Research- in-Progress. ACM Proceedings, SIGCPR.
2. Diwakar, H., Marathe, M. (2000). The architecture of a one-stop web-window
shop. December, ACM SIGecom Exchanges, Volume 2 Issue 1.
3. Morrison, M., Morrison, J., and Keys, A. (2002). Integrating Web Sites and
Databases. Communications of the ACM, September, Volume 45, Issue 9.
4. Kubilus, N. J. (2000). Designing an e-commerce site for users. September 2000,
Crossroads, Volume 7 Issue 1.
5. Norman, D.A. The Design of Everyday Things. Doubleday, New York, 1994.
6. Tilson, R., Dong, J., Martin, S., Kieke, E. (1998). A comparison of two current ecommerce
sites. September, Proceedings of the 16th annual international
conference on Computer documentation.
Books
7. Anderson, R., Francis, B., Homer, A., Howard, R., Sussman, D. and Watson.
(2001) Professional ASP.NET. Wrox Press Ltd.
8. Brown, S., Burdick, R., Falkner, J., Galbraith, B., Johnson, R., Kim, L., Kochmer,
C., Kristmundsson, T. and Li S (2001). Professional JSP. Wrox Press Ltd.
9. Walther, S. (1998) Active Server Pages. SAMS Net.
10. Wagner, R., Daniels, K., Griffin, G., Haddad, C. and Nasr, J. (1997) JavaScript
Unleashed. SAMS Net.
11. Wiley, Y. M. J. & Sons. (1997) Creating the Virtual Store: Taking Your Web Site
from Browsing to Buying.
Websites
12. http://encyclopedia.laborlawtalk.com/IIS for information on IIS
13. http://aspnet.4guysfromrolla.com/articles/020404-1.aspx for relationship between
IIS and ASP.NET.
14. http://216.15.201.66/dpec/course.htm?fullpg=http%3A//216.15.201.66/dpec/cours

50
es/wac312/wah006.htm&acro=wac312 for security authentication in ASP.NET
15. http://samples.gotdotnet.com/quickstart/aspplus/doc/mtstransactions.aspx for
information on Transactions in ASP.NET.
16. http://www.x-cart.com/articles/design_development.html for online customer
behavior.
17. http://aspnet.4guysfromrolla.com/articles/011404-1.aspx for relation between IIS
and ASP.NET.
18. http://www.informatik.uni-bremen.de/uniform/gdpa_d/methods/m-fctd.htm for
definition of Functional Decomposition.
19. http://www.agilemodeling.com/artifacts/dataFlowDiagram.htm for definition of
Data Flow Diagram.
20. http://www.startvbdotnet.com/ado/default.aspx for information on ADO.NET
21. http://mypage.iusb.edu/~hhakimza/505/index.html for ADO.NET objects.
22. http://msdn.microsoft.com for ADO.NET objects.

51