Академический Документы
Профессиональный Документы
Культура Документы
By
NAMRATA KUNDU(11700211041 OF 2011-2015)
SOUMITRA HALDER (11700211067 OF 2011-2015)
GOURAB DEY (11700212101 OF 2012-2015)
MAITRAYEE KUNDU (11700212104 OF 2012-2015)
UNDER THE SUPERVISION OF
Mr. Abhijit Das
Assistant Professor
Dept. of Information Technology
AT
RCC INSTITUTE OF INFORMATION TECHNOLOGY [Affiliated to
West Bengal University of Technology] CANAL SOUTH ROAD,
BELIAGHATA, KOLKATA 700015
1|P a ge
CERTIFICATE
The
report
of
the
Project
by NAMRATA
KUNDU (11700211041 OF 2011-2015) SOUMITRA HALDER (11700211067 OF 20112015)GOURAB DEY (11700212101 OF 2012-2015) MAITRAYEE KUNDU (11700212104 OF
2012-2015) of B. Tech.(IT) 7th Semester of 2014 has been prepared under our supervision for
the partial fulfillment of the requirements for B Tech (IT) degree in West Bengal University of
Technology. The report is hereby forwarded.
_______________________
___________________________
[Name of Guide]
Designation
Institute Name
(External Examiner)
Countersigned by
.
Dr. Siddhartha Bhattachryya
Department ofInformation Technology
RCC Institute of Information Technology, Kolkata 700 015, India
2|P a ge
ACKNOWLEDGEMENT
We are extremely thankful to our respected teacher Mr. Abhijit Das who
has inspired us to go ahead with this extremely difficult project involving
massive data handling. Once again, we take this opportunity to thank
him for his trust and confidence which urged us to undertake this
project. We also acknowledge the efforts of our institute RCC Institute
of Information Technology for providing with the infrastructure to move
ahead with the project. We truly acknowledge the co-operation of our
batch-mates for their valuable tips and unlimited supports toward
making this project a huge success.
Date: .. 2015
ABSTRACT
4|P a ge
Table of contents
Section 1 Introduction
Section 2 Feasibility Study
Section 3 Requirement Specifications..
Section 4 Lifecycle Model Used
Section 5 System Requirements
Section 6 Design Analysis.
Section 7Database
Section 8 Online Book Shop Application
Section 9 Conclusion
Section 10 References..
5|P a ge
SECTION: 1.0
6|P a ge
1. Introduction
In the world of software development there lots of improvement in the area ofArchitectural
design and principles. The philosophies and implementation details arechanging as the people
guiding the development of the application. In this fantasticand yet sometimes complex world of
software development there are some tried andtrue architecture patterns and software
development guidelines employed by mostarchitects. Also your design must have an ability to
turn towards innovation instead oflending itself to common practices. Web services are one
such area where architectsmust lean on their creative side and hope that their solutions are still
successful. Inthis report we will explain an exciting voyage down the road of Web services
application. From requirements to use cases, to database design, to componentframeworks, to
user interfaces, we will cover each and every aspect of system designrequired to build an
application with collaborative Web services. The reason why weselected online Bookstore web
service is everybody walking down the street has someidea about bookstores. The objective of
this project is to develop an e- book storewhere books can be bought from the comfort of home
through the Internet.
An online book store is a virtual store on the Internet where customers can browse thecatalog
and select books of interest. The selected books may be collected in ashopping cart. At
checkout time, the items in the shopping cart will be presented as anorder. 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 shippingaddress, 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.
7|P a ge
SECTION: 2.0
8|P a ge
Example of a static Web page is the page displaying company information. In a dynamic Web
page, content varies based on user input and data received from external sources. We use the
term data-based Web pages to refer to dynamic Web pages deriving some or all of their
content from data files or databases. A data-based Web page is requested when a user clicks a
hyperlink or the submit button on a Web page form. If the request comes from clicking a
hyperlink, the link specifies either a Web server program or a Web page that calls a Web server
program. In some cases, the program performs a static query, such as Display all items from
the Inventory. Although this query requires no user input, the results vary dependingon when
the query is made. If the request is generated when the user clicks a forms submit button,
instead of a hyperlink, the Web server program typically uses the form inputs to create a query.
For example, the user might select five books to be purchased and then submit the input to the
Web server program. The Web server program then services the order, generating a dynamic
Web page response to confirm the transaction. In either case, the Web server is responsible for
formatting the query results by adding HTML tags. The Web server program then sends the
programs output back to the clients browser as a Web page.
9|P a ge
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.
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 relationships
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 table. The tables are
shown below along with the attributes.
10 | P a g e
FEASIBILITY STUDY:
TECHNICAL FEASIBILITY
The client requirements can be easily fulfilled using PHP in the front-end and MYSQL in the
back-end. The licensed versions of the above software are easily available. The licensed
version of the operating system, Windows7 (SP2) and PHP package as WAMP, XAMP on
which the application will be executed is commonly used.
OPERATIONAL FEASIBILITY
The front-ends developed using HTML, CSS, PHP, JQUERY, AJAX is designed to make it
easier to use and make the interface user-friendly. Special considerations have been taken into
account regarding the users of the application. The GUI is designed such that it will not require
extensive training for the users. The concept of having a single database that can be remote or
local makes the database easier to maintain. This will require a single database administrator.
FINANCIAL FEASIBILITY
Owing to the scale of implementation of the application the cost of licensed versions of the
above mentioned software are free. Moreover Windows is one of the most popularly used
operating system. Along with the above the cost involved in operating and maintenance of the
application is minimal since the degree of expertise required is quite low. There is the need of a
single database administrator having prior knowledge in query language for the maintenance of
the database. The cost involved in training the users of the application will be at most 6 hours
due to its interactive and easy to use interface. Another advantage is that the same application
can be used for maintaining stock levels and selling them at the same time. This will save cost
in terms of time and number of operators required.
SOCIAL FEASIBILITY
The implementation of the software will not lead to abrupt reduction of manpower. Owing to the
flexibility of the application to be able to operate in a network provides an opportunity to operate
multiple cash counters. In keeping with the rapid rate of growth of the retail BOOK SHOP
marketing concept, this application will provide the scope for business expansion without
11 | P a g e
significant additional costs. Thus the application will also promote employee satisfaction and
improved growth opportunities along with the business growth.
LEGAL FEASIBILITY
The database maintaining the transactions and storing the operational details of the shopping
mall are securely cached by international standards in the database by and MySQL.
Internationally renowned organizations providing secure and integrated data storage,
manipulation and retrieval techniques. The data stored in the database are protected by
passwords and other data protection techniques that can accessed only by an authorized user.
Thus the data from the database can be used as official documents. Any operations on the
database will be recorded by the respective database applications which can be easily
monitored.
12 | P a g e
SECTION: 3.0
13 | P a g e
3.0
REQUIREMENT SPECIFICATIONS
Various softwares are currently available in the field of Online Book Shop System.Owners and
other people in the related field through questionnaires and personal interviews revealed the
following requirements which include some features which are currently unavailable in the
existing software:
A system which generates a bill while selling and buy-back of the products.
A system which allows the record of sales and provides daily, monthly and
yearly/quarterly sales record view.
A system which automatically alerts the user on overstock and under stock
conditions. The stock limits should be alterable at the users discretion.
A system which automatically alerts the user, providing details of the BOOKs
nearing their old Edition stock. The Edition should be modifiable by the user.
The graphical user interface should be user friendly and various options should
be easily identifiable and operable.
14 | P a g e
SECTION: 4.0
15 | P a g e
Planning
Analysis
Design
Development
Testing
Maintenance
We have followed the iterative waterfall model for developing this project. The classical waterfall
model is idealistic since it assumes that no development errors are committed during any
phases of the life cycle. In this model every subsequent stages are performed to completion
before moving to the next stage. However in the real scenario various errors might creep up in
the different phases of the life cycle model due to oversight, wrong assumptions, use of
inappropriate technology, communication gap amongst the team members etc. The defects are
not necessarily be rectified in every developmental phases of the project. They are usually
detected in the later stages of product development and thus engineers need to revert back to
the phase in which the error occurred, in-order to negate its effect on the subsequent stages.
The feedback paths in the Iterative Waterfall Model provide us with the flexibility to revert back
to the stages where error occurred. But detecting errors at every stage will increase the cost of
product development. A separate phase for testing and debugging is also provided by the
Iterative Waterfall Model for this purpose. Significant errors like logical error when detected at a
later stage require a reformulation of the coding and thereby contributing to the cost scaling.
The principle of detecting the errors as close to their points of introduction possible is known as
phase of containment of errors. An important technique is to conduct reviews after every
milestone.
16 | P a g e
SECTION: 5.0
17 | P a g e
5.0
SYSTEM REQUIREMENTS
5.1
5.2
Operating System
: Windows 7 (SP1)
Display Mode
Operating System
: Windows 7 (SP1)
Software Required
Processor
Video Memory
: 32 MB or higher
Display Adapter
: 20 GB or higher
CD ROM Drive
: 52X max
Printer
18 | P a g e
SECTION: 6.0
19 | P a g e
6.0
DESIGN
The goal of the design phase is to transform the requirements specified in the
requirement specifications into a structure that is suitable for implementation in some
programming language. Two distinct methods are available while deriving the software
architecture from the SRS document. They are as follows:
The traditional design approach consisting of the Data Flow Diagram , Entity
Relationship Diagram
The object oriented design approach consisting of the Use Case Model .
Data flow Diagrams (DFD): The DFD is a simple graphical formalism that can be used to
represent a system in terms of the input data to the system, various processing carried out on
this data and the output data generated by the system.
Entity Relationship Diagrams (ERD): The ERD is also a graphical representation of the
relationship between the entities that are available in the system. Various attributes like the
generalization and specialization are also defined in an ERD.
Use Case Model: Theuse casemodel for any system consists of a set of use cases, which
represents the various ways in which the system can be used by the user. The use case
partitions the system behavior into transactions, such that each transaction performs a useful
action from the users point of view. Each transaction can include either a multiple message or
single message exchanges between the user and the system to complete itself.
20 | P a g e
Add books
Books
Admin
Update
Register Sales
Book seller
Customer
Main DB
Admin operates
DB
Payment
Cart
Customer
Online Book Shop
21 | P a g e
SECTION: 7.0
22 | P a g e
Database
23 | P a g e
24 | P a g e
25 | P a g e
SECTION: 8.0
26 | P a g e
27 | P a g e
28 | P a g e
29 | P a g e
SOFTWARE TESTING
The aim of testing is to identify all defects existing in the software product. However, for
most practical systems, even after satisfactorily carrying out the testing phase it is not
possible to guarantee that the software is error free. This is because of the fact that the
input data domain of most software products is very large. Testing does expose various
defects existing in a software product. Thus testing provides a practical way of reducing
defects in a system and increasing the users confidence on the product. In this phase of
software development the program is subjected to a set of test input cases and its
behavior is observed. If the program fails to behave as expected necessary debugging
techniques are adopted to remove the execution anomalies. Terms associated to
testing:
Test Case: A test case is the triplet [I, S, O] where I is the data input to the
system, S is the state of the system at which the data is input and O is the
expected output of the system.
Test Suite: A test suite is the set of all test cases with which a given software
product is tested.
We have adopted various testing and debugging methodologies which are subsequently
discussed.
8.1
UNIT TESTING
All the units of the MART-MAINT software have been individually tested after they have been
coded and successfully reviewed. In order to test a single module we need a complete
environment to provide all that is necessary for execution of the module. As a result we
designed necessary driver and stub modules to provide a complete environment to the module.
30 | P a g e
Driver module
Global Data
Figure: 9.a
The role of a stub and driver are shown pictorially in Figure 9.a. A stub procedure is a
dummy procedure that has the same I/O parameters as the given procedure but has a
highly simplified behavior. While a driver module would contain the non local data
structures accessed by the module under test.
8.2
In black box testing approach the test cases are designed using only the functional
specifications of the software, without any knowledge of the internal structure (design or code)
of the software. Thus, it is also termed as functional testing. The following are the two main
approaches to design black box test cases:
31 | P a g e
Statement coverage: This strategy aims to design test cases so that every
statement in the program is executed at least once.
Branch coverage: This strategy aims to design test cases so that every branch
condition in the program is executed. Branch testing is also known as edge
testing. It is better testing strategy than statement coverage method since the
test cases for branch testing ensures statement coverage. The principal strategy
behind it is that unless we execute we cannot determine the existence of errors
in it. Our application is capable of handling the database on one platform, namely
MySQL. This requires extensive condition checks prior to a database transaction.
These modules are tested using this strategy.
Path Coverage: The path coverage based testing strategy requires us to design
test cases such that all the linearly independent paths in the program are
executed at least once.
Data flow-based testing: this method of testing selects the test paths of a
program according to the locations of the definitions and uses of the different
variables in the program.
Mutation testing: In this type of testing after the software is initially tested,
deliberate changes are incorporated into the program. Every time a program is
changed is called a mutated program and the change effected is termed as a
mutant. Since mutation testing requires a huge number of test cases to test each
mutant it is not suitable for manual testing.
32 | P a g e
DEBUGGING
Once the errors are identified, it is necessary first to locate the precise program statements
responsible for errors and to fix them. The debugging techniques adhered to while developing
this application are detailed below.
BACKTRACKING
In this approach, beginning from the statement at which an error is observed, the source code is
traced backwards until the error is discovered. Unfortunately, as the number of source lines to
be traced back increases, the number of potential backward paths increases and may become
unmanageably large, and thus limiting the use of the approach.
33 | P a g e
ALPHA TESTING
Alpha testing refers to the system testing carried out by the test team within the organization.
While testing this application the team members carried out the alpha testing.
PERFORMANCE TESTING
This is carried out to check whether the system meets the nonfunctional requirements identified
in the SRS document. There are several types of performance testing. The ones followed are
described subsequently. All performance tests can be considered as black box tests.
CONFIGURATION TESTING
It is especially important to check whether the data structures have been designed successfully
for extraordinary situations. Since the application requires a printer to print the bill, the spooling
capabilities were tested using simultaneous requests.
COMPATIBILITY TESTING
This type of testing is required when the system interfaces with other type of systems.
Compatibility aims to check whether the interface functions perform as required. The interface of
the application is tested for the speed and accuracy of the data when the application
communicates with a larger database like Oracle.
RECOVERY TESTING
Recovery testing tests the response of the system to the presence of faults, or loss of power,
devices, services, data etc. the system is subjected to the loss of the mentioned resources (as
applicable and mentioned in the SRS document) in order to check if the system recovers
satisfactorily. This application was tested with the removal of a printer while printing the bill. It
was observed that the printer resumed printing the bill once it was reconnected to the system. In
addition to that there were no anomalies in the data which were being operated upon during
printing.
USABILITY TESTING
Usability testing pertains to checking the user interface to see if it meets all the user
requirements. During usability testing the display screens, messages, report formats and other
aspects related to the user interface were tested.
34 | P a g e
SECTION: 9.0
35 | P a g e
CONCLUSION:
The developed system is flexible and changes can be made easily. The system is developed
with an insight into the necessary modification that may be required in the future. Hence the
system can be maintained successfully without much rework.
One of the main future enhancements of our system is except administrator , no one can see or
access the database and admin panel. Less than the certain amount of book stock throws
warning to the user.
Scope has aloes be made to add a link to the library.
36 | P a g e