A

Project Report

On

“Online Book marriage hall and lawn”

Submitted to

Veer Bahadur Singh Purvanchal University, Jaunpur

In partial fulfillment of the requirements of the degree of

Bachelor of Computer Application

Prepared by: Project Supervisor:

Payal verma Mr. Subhradip Chakraborty

BCA 5th Semester Assistant professor
Roll number:21141000981

2022-2023

Department of Computer Application

Technical Education & Research Institute
Post-Graduate College, Ghazipur-233001(U.P.)

1
 CERTIFICATE

This is to certify that “Payal verma”, pursuing BCA 5th Semester from this institute, has
prepared the project report entitled “Online book marriage hall and lawn” in partial
fulfillment of the requirements of the degree of Bachelor of Computer Application from Veer
Bahadur Singh Purvanchal University, Jaunpur, for the session 2022-2023.

This report is based on the project work undertaken by Payal verma at Technical
Education & Research Institute under the supervision of Mr.Subhradip Chakravarti and
fulfills the requirements of regulations relating to the nature and standard of BCA course of
V.B.S Purvanchal University, Jaunpur, and Uttar Pradesh.

I recommended that this project report may be sent evaluation.

Mr.Subhradip Chakravarti Dr. Ajit Pratap Singh

Assistant Professor Head Of Department

2
 DECLARATION
I, payal verma , hereby declare that this project report entitled “Inventory Management
System” has been prepared by me on the basis of academic project done at TERI P.G.
College, Ghazipur during the course period under the supervision of Mr.Subhardip
Chakravarti.

This project report is my bonafide work and has not been submitted in any form to any
University or Institute for the award of any degree or diploma prior to the under mentioned
date. I bear the entire responsibility of submission of this project report.

Payal verma

BCA 5th Semester

Department of Computer Application

Technical Education & Research Institute

P. G. College, Ghazipur

3
 PREFACE

The project “Online book marriage hall and lawn” is designed as the project work of BCA
6th semester.

Problems have been solved by manually which required lot of time. Here is a system
designed to simplify the task and make it so easily to do.

The project starts with system analysis. This part focuses on the requirements analysis &
specification. It first describes the present working system. Then the problems are identified.

After the complete analysis of present system and the problem related to old system has been
specified new system is proposed, which gives the user a better and efficient way of
managing transaction and updating his knowledge regarding the latest development.
.
Requirement documentation is very important activity after the requirements decision
and analysis. This is the way to represent the requirements in a consistent format.
Requirement document is called Software Requirement Specification (SRS).

System design provides the understandings and procedural details necessary for
implementing the system recommended in the system study

Then we have covered topics of ER diagram, and DFD to be easily understandable by any
one.

4
 ACKNOWLEDGEMENT
The development process of any software project was to the hard work of a lot of people
besides the person whose name appears on the front. I take opportunity to express me
profound sense of gratitude & respect to all those helped me throughout the duration of the
project.

The reliability of this project was to the constant watchful eye of my project supervisor as
well as Head Of Department Dr. AJIT PRATAP SINGH GAUTAM who provides me the
technical accuracy & support in the project work. This project would never have been
complete without his help & guidance.

The overwhelming response of my friends & they taken interest shown my learned teachers,
promoted more meaningful compact & comprehensive. It is a pleasure to let you know that I
have put my feeling into practice.

In addition, I want to thanks the people at Google Search Services provided for their
assistance in setting up the help.

Date :- January 2023

Place: Ghazipur Payal verma

BCA 5th Semester

Roll No:21141000981

5
 INDEX
1- Introduction 8
2-Objective 15
3- System analysis 16-22

3.1- Existing System Description

3.2- Proposed System

3.3- Feasibility study with report

4-Software requirement specification 23-34

4.1- Objective

4.2- Scope

4.3 –Requirement

4.3.1- functional Requirements

4.3.2- Security requirement

4.3.3-Output requirement

4.4- Software requirement

4.5- Hardware requirement

5- System design 35-43

5.1- Design approach

6
6- High Level Design 44-54
6.1- Data flow diagram
6.2- E-R-Diagram

7- Low Level Design 55

8- Coading 56-64

9- Testing 65-70

10- Implementation 71

11- Maintenance 72

12 -Bibliography 73

7
 INTRODUCTION

1. INTRODUCTION

One of the most used over software of all time are custom business “Inventory Management
System” but still as new business is starting every now and then, there are demands for it.
Currently most of them uses the desktop version of the inventory system made in either Java,
VB or Pascal. But with the popularity of web, online inventory will soon take over the
desktop market. Online inventory system has lots of benefits compared to the traditional
desktop system, the best of them is accessibility from anywhere you will just need an internet
connection. You can check your inventory status from your mobile too given that it has
internet. Another benefit of making Online Inventory System is that multiple user can access
it at the same it. So if your partner who lives at different place wants to check the current
stocks,

The software requirement analysis is a process of obtaining and understanding of the need of
client and users. What exactly is desired from the software and what the constraints of the
solution are?

The software project is initiated by the client need. During analysis, the environment the
personal skill of the analyzer is just as important as if not more as the technical skill.
Interviewing the user and client require good communication skills. The situation can be
more complex If some are reluctant to part with information they process. Careful
requirement for the system will satisfied the needs of the client and the concern of the users
have to be communicated to the developer.

The scope of this system is to provide user efficient working environment and more output
can be generated through this. This system provides user friendly interface resulting in
knowing each and every usability features of the system.

This system helps in tracking records so that past records can be verified through them and
one can make decisions based on the past records. This system completes the work in a very
less time resulting in less time consumption and high level of efficiency.

8
This system is developed in such a way that even a naïve user can also operate the system
easily. The calculations are made very quickly and the records are directly saved into
databases and the databases can be maintained for a longer period of time. Each record can be
retrieved and can be verified for the future transactions.

Also this system provides high level of security for data leaking as only admin people can
access the database no changes can be made in it until it verifies the user login id and
password.

We also have operator login through which operator can take orders but can’t make changes
in the database. Limited access is available to the operator.

9
 SOFTWARE DEVELOPMENT LIFE CYCLE (S.D.L.C.)

A software life cycle is the series of identifiable stage that a software product undergoes
during its lifetime. A life cycle represents all the activities required to make a software
product transit through its life cycle phases. The different stage includes problem recognition
and feasibility study, requirement analysis and specification, design, coding, testing and
maintenance. These different stages are carried out in different order in different life cycle
models.

Software development life cycle consists of several phases and these phases need to be
identified along with defining the entry and exit criteria for every phase. A phase can begin
only when the corresponding phase entry and exit criteria for every phase.

A phase can begin only when the corresponding phase entry criteria are satisfied. Similarly, a
phase can be considered to be complete only when the corresponding exit criteria are
satisfied. If there is no clear indication of the entry and exit for every phase, it becomes very
difficult to track the progress of the project. This problem is termed as 99% complete
syndrome. In even when the project is far from completion.

10
11
 SOFTWARE DEVELOPMENT LIFE CYCLE
PHASES
Phases Of Software development Life Cycle

Initiation Phase

The initiation of a system (or project) begins when a business need

opportunity is identified. A project Manager should be appointed to manage the project. This
business is documented in a concept proposal is approved the System Concept Phase is begin.

System Concept Development Phase

Once a business is approved, the approaches for accomplishing the concept are
reviewed for feasibility and appropriateness. The System Boundary Document identifies the
scope of the system and requires Senior Official approval and funding before beginning the
planning phase.

Planning Phase
The concept is further developed to describe how the business will operate
once the approved system is implemented and to access how the system will impact
employee and customer privacy. To ensure products and services provide required capability
on-time and within budget, project resources, activities, schedules, tools and reviews are
defined. Additionally, security certification and accreditation activities begin with the
identification of system security requirements and the completion of a high level vulnerability
assessment.

Requirement Analysis Phase

Functional user requirements are formally defined and delineate the
requirements in terms of data, system performance, security, and maintainability
requirements for the system. All requirements are defined to a level of detail sufficient for

12
systems design to proceed. All requirements needs to be measurable and testable and relate to
the business need or opportunity identified in the initiation ph
Design Phase
The physical characteristics of the system are designed during this phase. The
operating environment is established, major subsystems and their inputs and outputs are
defined, and processes are allotted to the resources. Everything requiring user input or
approval must be documented and reviewed by the user. The physical characteristics of the
system are specified and a detailed design is prepared. Subsystem identifies during design are
used to create a detailed structure of the system. Each subsystem is partitioned into one or
more design units or modules. Detail logic specifications are prepared for each software
modules.
Development Phase
The detailed specifications produced during the design phase are translated
into hardware, communications, and executable software. Software shall be unit tested,
integrated and rested in a systematic manner. Hardware is assembled and tested.

Integration and Test Phase

The various components of the system are integrated and systematically
tested. The user tests the system to ensure that the functional requirements, as defined in the
functional requirement document, are satisfied by the developed or modified system. Prior to
installing and operating the system in a production environment, the system must undergo
certification and accreditation activities.

Implementation Phase
The system or system modifications are installed and made operational in a production
environment. This phase is initiated after the system has been tested and accepted by the user.
The phase continues until the system is operating in production in accordance with the
defined user requirements.

Operation and Maintenance Phase:-

The system operation is ongoing. The system is monitored for continued performance in
accordance with user requirements and needed system modifications are incorporated. The

13
operational system is periodically assessed through In-Process Reviews to determine how the
system can be made more efficient and effective. Operations continue as long as the system
can be effectively adapted to respond to an organization’s needs. When modifications or
changes are identified as necessary, the system may reenter the planning phase.

Deposition Phase
The deposition activities ensure the orderly termination of the system and
preserve the vital information about the system so that some or all of the information may be
reactivated in the future if necessary. Particular emphasis is given to proper preservation of
the data processed by the system, so that the data is effectively migrated to another system or
archived in accordance with applicable records management regulations and policies, for
potential future access.

SDLC OBJECTIVE

This guide was developed to disseminate proven practices to system developers, project
managers, account analyst and system owners/users. The specific objectives expected include
the following:
 To reduce the risk of project failure.
 To consider system and data requirements throughout the entire life of the system.
 To identify technical and management issues early.
 To disclose all life cycle costs to guide business decisions.
 To foster realistic expectations of what the systems will and will not provide.
 To provide information to better balance programmatic, technical, management, cost
aspects of proposed system development or modification.
 To encourage periodic evaluations to identify systems that is no longer effective.
 To measure progress and status for effective corrective action.

14
 2. Objective
• The main objective of this system is to keep records of the complete inventory.

• It support for inventory management helps you record and track materials on the basis
of both quantity and value.

• It improves cash flow, visibility, and decision making.

• For inventory management, you can track quantity and value of all your materials,
perform physical inventory, and optimize your grocery resources

15
 SYSTEM ANALYSIS

3. SYSTEM ANALYSIS
System analysis:

System analysis is the process of gathering and interpreting facts, diagnosing problems and
using the information to recommend improvements on the system. System analysis is a
problem solving activity that requires intensive communication between the system users and
system developers. System analysis or study is an important phase of any system
development process. The system is studied to the minutest detail and analyze.

System analysis and design refers to the process of

examining a situation with the intent of improving it through better procedure and
methods. System design is the process of planning a new system or one to replace
or complement an existing system. But before this planning can be done, we must
thoroughly understand the system and determine how computer can best be used to
make its operation more effective. System analysis is, therefore, the process of
gathering and interpreting facts, diagnosing problems and using the information to
recommend improvements to system.

A detailed study of these processes must be made by various techniques like Interviews,
Questionnaires etc. The data collected by these sources must be scrutinized to arrive to a
conclusion. The conclusion is an understanding of how the system functions. This system is
called the existing system. Now, the existing system is subjected to close study and the
problem areas are identified. The designer now functions as a problem solver and tries to sort
out the difficulties that the enterprise faces. The solutions are given as a proposal. The
proposal is then weighed with the existing system analytically and the best one is selected.
The proposal is presented to the user for an endorsement by the user. The proposal is

16
reviewed on user request and suitable changes are made. This loop ends as soon as the user is
satisfied with the proposal

System Development strategies:-

Computer information system serves many different purpose, ranging

from the processing of financial transaction to providing information needed to decide
recurring issues, assisting senior officials with difficult strategy formulation.

There are distinct approaches to the development of computer information system.

1. System development life cycle

2. System prototype method
3. Structured analysis & development method

17
 3.1 Existing System Description

Existing System Description:-

The main problem with the existing system is that the records are maintained manually. All
tasks are required to be handled manually with a lot of time consume and also includes the
maintenance of records or registers that include a lot of paper work. All the information
regarding the student as well as the project have to be maintained in the registers and if we
have to find out any detail about any field it involves a lot of time and it is too tedious.
LIMITATIONS OF EXISTING SYTEM:

The present needs to be computerized because the present manual system has the
following drawbacks:-

Thus to overcome all these problems the existing manual system is to be

computerized on whole. It will help in manpower planning and will give perfect
estimation of packages information. There is almost need for computerization as to
facilitate “Inventory Management System” will help this to maintain better records.
As we know manual system are quite tedious ,time consuming and less efficient and accurate
in comparison to the computerized system.

So following are some disadvantages of the old system:

1.Time consuming

2.Less accurate

3.Less efficient

4.Lot of paper work

18
5.Slow data processing

6. Not user friendly environment

3.2- Proposed System

The proposed of this system is to provide user efficient working
environment and more output can be generated through this. This system provides
user friendly interface resulting in knowing each and every usability features of
the system.

This system helps in tracking records so that past records can be verified through
them and one can make decisions based on the past records. This system
completes the work in a very less time resulting in less time consumption and high
level of efficiency.

This system is developed in such a way that even a naïve user can also operate the
system easily. The calculations are made very quickly and the records are directly
saved into databases and the databases can be maintained for a longer period of
time. Each record can be retrieved and can be verified for the future transactions.

Also this system provides high level of security for data leaking as only admin
people can access the database no changes can be made in it until it verifies the
user login id and password.

We also have operator login through which operator can take orders but can’t
make changes in the database. Limited access is available to the operator.

19
 3.3 Feasible Study with Report

Introduction:-

When a project is started an initial investigation is carried out. During

this phase of study users need has recognized and other requirements are determined.

Once the problem has been defined a study is carried out to select the best system
i.e. a feasible system that meets performance requirements. So Feasibility is the
determination of whether or not a project is worth doing and the process followed in
making this determination is called a Feasibility Study. In order to conduct the
feasibility study we have seven distinct, but inter-related types of feasibility, these are
Technical feasibility, Operational feasibility, Economical feasibility, Social feasibility,
Management feasibility, Legal feasibility and Time feasibility. Out of these seven three are
key feasibilities to consider, those are:

 Technical Feasibility

 Economical Feasibility

I. Technical feasibility:-
This is concerned with specifying equipments i.e. (hardware) and software
that will successfully satisfy the user’s requirement. It considers the following facts:

 The facility to produce outputs in a given time.

 Response time under certain conditions.

 Ability to process a certain volume of transactions at a particular speed.

 Facility to communicate data to a distant location.

While examining technical feasibility, huge importance is given to the configuration of

the proposed system. The configuration should give the complete picture about the system’s
requirement such that what kind of hardware is required and how these units are

20
 interconnected so that they could operate and communicate smoothly. The proposed system
can be run on currently existing software and hardware.

II. Economical feasibility:-

Since cost plays quite an important role in deciding the new
system, it must be identified and estimated properly. So economic analysis is the most
frequently used technique for evaluating the effectiveness (economical feasibility) of a
proposed system. To determine the economical feasibility of the system a cost/benefit
analysis is to be made. This procedure is to determine the benefits and savings that are
expected from a proposed system and compare them with costs. Four facts that plays
an important role in deciding economical feasibility of the proposed system are as
follows: Cost-saving benefits, Cost-avoidance benefits, Improved-performance benefits,
Improved-information benefits, Hence the proposed system is economically feasible.

III. Behavioural feasibility:-

This includes the following questions:
 Is there sufficient support for the users?
 Will the proposed system cause harm?

The project would be beneficial because it satisfies the objectives the objectives when
developed & installed. All behavioral aspects are considered carefully & conclude that the
project is behaviorally feasible.
Feasibility Study Report:-

The end product i.e. The documentation after feasibility study

report document. It contains the following sections:

1. Covering the report which briefly indicates the management about the nature, general
findings and recommendations to be considered.
2. Table of contents.

21
 3. Narrative study, and the explanation of the purpose and scope of the project, reason
for undertaking feasibility department involved or affected by candidate system.
4. Detail findings outline the methods used in the present system. Effectiveness, efficiency
operating costs, description of objectives and general procedures of the candidate system.
5. Economic justification details point-to-point cost comparisons and preliminary cost
estimates for the development and operation of the candidate system. Return on Investment
(ROI) is also given.
6. Recommendations and conclusion suggest to management the most beneficial and cost
effective system.

22
 SOFTWARE
REQUIREMENT
SPECIFICATION

4. Software Requirement Specification

A software requirements specification (SRS) is a description of the behavior of a system

to be developed. It lays out functional and non-functional requirements, and may include a
set of use cases that describe user interactions that the software must provide. Software
requirements specification establishes the basis for an agreement between customers and
contractors or suppliers on what the software product is to do as well as what it is not
expected to do.

It includes a set of used cases that describe all the interactions the users will have with the
software. In addition to use cases, the SRS also contains non-functional (or supplementary)
requirements. Non-functional requirements are requirements which impose constraints on the
design or implementation (such as performance engineering requirements, quality standards,
or design constraints).

23
Requirement documentation is very important activity after the requirements decision
and analysis. This is the way to represent the requirements in a consistent format.
Requirement document is called Software Requirement Specification (SRS).

The software requirement specification is produced at the culmination of the

analysis task. This is the way to represent requirements in a consistent format. It is a
specification for a particular software product , program or a set of programs that
performs certain functions in a specific environment .The function and allocated to
software as part of system engineering are refined by establishing a complete
information description, a detailed functional and behavioral description, an indication
of performance requirements and design constraints, appropriate validation criteria,
and other data pertinent to requirements.
Software product, program or set of programs that perform certain
functions in a specific environment. There are two important cases regarding SRS:
First one, SRS is used to define the needs and expectations of the users. The second
one, SRS is written for different purpose and serve as a contract document between
customer and developer. This produces the probability of the customer being
disappointment with the final product.

SYSTEM ENGINEERING

SOFTWARE REQUIREMENT ANALYSIS

SOFTWARE DESIGN

24
  A condition of capability needed by a user to solve a problem or achieve
an objective.
 A condition or capability that must be met or processed by a system to
satisfy a contract, standard, specification, or other formally imposed
document.
Generally, the SRS is a document that completely describes what the proposed
software should do without describing how the software will do it. The basic goal
of the requirements phase is to produce the SRS, which describe the complete
external behavior of the proposed software.

Organization of an SRS:-
The most general organization of an SRS is as follow:-

 Introduction

 Purpose

 Scope

 Definitions

 System Overview

 Overall Description

 Product Perspective

 Product Functions

 User Characteristics

 Constraints, Assumptions and Dependencies

 Specific Requirements

 External interfaces

 Functions

25
 Performance requirements

 Logical database requirement

 Design constraints

An SRS must consist of the following features:-

 consistent

 complete

 unambiguous

 modifiable

 verifiable
NEED FOR SRS:-
The SRS is needed for the following reasons:

 An SRS establishes the basis for agreement between client and developer.
 An SRS provides a reference for validation of the final product.
 A high- quality SRS is a prerequisite to high–quality software.
 A high- quality SRS reduces the development cost.
Platform:-
Windows is very powerful scalable Operating System that provides basic file and
prints services as well as robust platform for server applications. Main features are as
follows:-

 More extensive network management features.

 Improved Network Performance.

 Enhanced communication features.

26
 4.1Objective

A software requirement specification is literally the conversation of a specific point. It's

difficult in this instance to avoid the circular reference. A project's specifications consist of

the body of information that should guide the project developers, engineers, and designers

through the work of creating the software.

A software requirement specification document describes how something is

supposed to be done. A specifications document may list out all of the possible error states

for a certain form, along with all of the error messages that should be displayed. The

specifications may also describe the steps of any functional interaction, and the order in

which they should be followed by the user. A requirements document, on the other hand,

would state that the software must handle error states reasonably and effectively, and provide

explicit feedback to the users.

The document gives the detailed description of the both functional and non functional
requirements proposed by the client. The document is developed after a number of
consultations with the client and considering the complete requirement specifications of the

27
given Project. The final product of the team will be meeting the requirements of this
document.
A software requirement specification is literally the conversation of a specific point. It's
Difficult in this instance to avoid the circular reference. A project's specifications consist of
the body of information that should guide the project developers, engineers, and designers
through the work of creating the software. A software requirement specification document
describes how something is supposed to be done. A specifications document may list out all
of the possible error states for a certain form, along with all of the error messages that should
be displayed. The specifications may also describe the steps of any functional interaction, and
the order in which they should be followed by the user. A requirements document, on the
other hand, would state that the software must handle error states reasonably and effectively,
and provide explicit feedback to the users.

4.2 Scope
Boundaries of software products are defined by a set of Requirements. The
software development team designs, implements, tests, and delivers these Requirements to
you. A Requirement is an atomic unit of a software product from the viewpoint of the user.
As a rule, Requirements are always correct, unambiguous, verifiable, and traceable.
Requirements are numbered and prioritized.

All Functional Requirements are then listed in a requirements attributes

spreadsheet, where all necessary attributes for each Requirement are maintained. Changes to
the project scope can be made only by issuing new Specifications through a process called
Change Requests. Each Change Request implies that changes will be made to the Budget,
Schedule, and Risks.

When a ROM Estimate is approved, an Alpha-Specification is created. Upon your approval,

the Alpha-Specification becomes a Beta-Specification. When the project begins and the
Budget is approved (following a LCO Milestone), the Beta-Specification becomes an
effective Specification.

28
 4.3 – Requirements
Requirement:-
The software requirements specification is produced at the culmination
of the analysis task. This is the way to represent requirements in a consistent format.
It is a specification for a particular software product , program or a set of
programs that performs certain functions in a specific environment .The function
and allocated to software as part of system engineering are refined by establishing a
complete information description, a detailed functional and behavioral description, an
indication of performance requirements and design constraints, appropriate validation
criteria, and other data pertinent to requirements.

4.3.1- Functional Requirement

Functional Requirement:
Functional requirements specify which output should be produced from
the given input. They describe the relationship between the input and output of the system.
For each functional requirement, a detail description of all the data inputs and their sources,
the units of measure, and the range of valid inputs must be specified.

All the operations to be performed on the input data to obtain the output
should be specified. This includes specifying the validity checks on the input and output data,
parameters affected by the operations, and equations or other logical operations that must be
used to transfer the inputs into corresponding outputs.

An important part of the specification is the system behavior in abnormal

situations, like input unit (which can occurs in many ways) or error during computations.

The functional requirement must clearly state what the system should do if
such situations occurs. Specially, it should specify the behavior of the system for invalid

29
input and invalid outputs. Furthermore, behavior for situations where the input is valid but the
normal operations cannot be performed should also be specified. In short, the system for the
foreseen inputs and all foreseen system states should be specified. These special conditions
are often likely to be overlooked, resulting in the system that is not robust.

4.3.2- Security Requirement

Security Requirement:
Security requirements are the particularly significant in defense system
and many database systems. Security requirement place restrictions on the use of certain
commands, control access to data, provide different kind of access requirement for different
people, require the use of passwords and cryptography techniques, and maintain a log of
activities in system. Given the current security needs even of common systems, they may also
require proper assessment of security threats, proper programming techniques, and use of
tools to detect flaws like buffer overflow.

For the purpose of security process I have added the login feature into my
project so as to keep it safe from the external problem. One can only interact with my project
by giving it the suitable i.e. the accurate ID and password.

4.3.3 - Output Requirement

It is important to identify the input and output requirements of the proposed system. Inputs
and Outputs include:

 Interaction with project coordinator’s computer systems.

 Interaction with User computer systems.
 Interaction with users.
 Interaction with internal systems.

30
  Provide a framework for packages
 Supports multiple projects.
 Supports distributed development.
 Allow to define fine-grained project step like task and subtask.
 Allow to create complex dependencies between tasks.

4.4- Software Requirement

Software Requirement:-
Software requirement plays a very important role in the making and
development of a project, as it provides a suitable language as well as the perfect medium to
implement our program or project on the system. Software requirement is very necessary for
the implementation of a program.

The Software requirements specification is produced at the

culmination of the analysis task. This is the way to represent requirements in a consistent
format. It is a specification for a particular software product, program or a set of
programs that performs certain functions in a specific environment .The function
and allocation to software as part of system engineering are refined by establishing a
complete information description, a detailed functional and behavioral description, an
indication of performance requirements and design constraints, appropriate validation
criteria, and other data pertinent to requirements.

Software product, program or set of programs that perform

certain functions in a specific environment. There are two important cases regarding
SRS: First one, SRS is used to define the needs and expectations of the users. The
second one, SRS is written for different purpose and serve as a contract document
between customer and developer. This produces the probability of the customer being
disappointment with the final product.

31
SOFTWARE REQUIREMENT:-

 Front End - HTML, DHTML, CSS

 Back End - MY SQL

 Server - PHP

 Operating System - Window-10

4.5 -Hardware Requirement

Hardware Requirement:-
The hardware requirements specification is produced at the culmination of the analysis task.
This is the way to represent requirements in a consistent format. It is a specification for a
particular hardware product, program or a set of programs that performs certain
functions in a specific manner.

In the designation of my project hardware requirement is also very necessary as it provide

various tools for the making of my project.

HARDWARE REQUIREMENT:-
 RAM 4 GB
 Processor 10th Gen
 Mother Board Intel
 Hard Disk 1 TB
 Mouse - Optical

32
  Keyboard - Normal

SRS OF MY PROJECT

Introduction:-

Challenge of our today technology not only attracts the need and convenient
process. Different kind of reports should be generated by administrator to take various
decisions. Tourism is travel for pleasure or business, also the theory and practice of
touring, the business of attracting , and entertaining tourist, and the business of
operating tours.

Purpose:

The purpose of this document is to specify all the information required to design,
develop and test software. The purpose of this project is to provide a friendly environment to
maintain the details of packages and tourist.

Scope:-

33
 This application can easily implement under various situations. We can add new
features and when we required. Reusability of this application is also possible. Any tourist
agency can make use of it for saving customer details in database.

System Overview:-

The implementation of “Inventory Management System” system start with

entering and updating master records like package details, payment details. Any further
transaction like Booking and cancelation package will automatically update the current
package.

Product Perspective:-

It provides simple database rather than complex ones for high requirements and
it provides good and easy graphical user interface to both new, native as well as experienced
users of the computers.

Product Function:-

In this web site we have four functions that is login, create users, view services,
book their services.

User Characteristics:-

 No pre knowledge of HTML.

 NO pre knowledge of database management.

Constraints, Assumptions and Dependencies:-

To make Fast access and responsive website. Dependency on window platform

and web browser.

Specific Requirements:-

It supports all web browsers.

34
External Interface:-

A detailed description of all inputs and outputs from the software system. It
complements the interface description in further also but does not repeat information there.
Then it contains the inputs of the tourist request then the output will be various category of
the information flow just like as package details etc.

Performance Requirements:-

It will be fast and easy to access for users.

Logical Database Requirement:-
The logical database requirement is to produce the SRS, which
describe the external behavior of the proposed software.
Design Constraints:-

It will be attractive and user friendly.

SYSTEM DESIGN

5 - System Design

Introduction:

35
System design provides the understandings and procedural details necessary for
implementing the system recommended in the system study. Emphasis is, translating the
performance requirements into design specifications. The design phase is a transition
from a user-oriented document (system proposal) to a document oriented to the
programmers or database personnel.

The systems objectives outlined during the feasibility study serves as the basis from which

The work of system design is initiated. Much of the activities involved at this stage are of

Technical nature requiring a certain degree of experience in designing systems, sound

Knowledge of computer related technology and through understanding of computers

available in the market and the various facilities provides by the vendor.

In the project “Inventory Management System” system design is a solution to a business

problem. Design demands the translation of the requirement uncovered in analysis into
possible ways of meeting them. There are many potential solutions to a specific problem and
the analyst will identify some of these and consider the relative merits of each in turn.

DESIGN REQUIREMENT

In the project “Inventory Management System” as the project will be accessed by many
people. So design should be done keeping in mind all kind of requirement of people with
easy and convenient and easy way to access the database.

Report is also generated in a manner, which is helpful for the people accessing the
website. In the null shell, both the site and report are designed by keeping in mind the varying
needs and demands of diverse kind of people

36
System design goes through two phases of the development:

1- Logical design
2- Physical design

A data flow diagram shows the logical flow of the system. For a system it describes the
input(source), output(destination), database(data stores), and procedures(data flows) all
in a format that meets the user requirement. When analysis prepare the logical
system design, they specify the user needs at a level of detail that virtually determines
the information flow into an out of the system and the required data resources. The
logical design also specifies input forms and screen layouts.

Logical and Output Design:

The logical design of an information system is

analogous to an engineering blue print of an automobile. It shows the major features
and how they are related to one another. The detailed specification for the new
system was drawn on the basis of user’s requirement data. The outputs inputs and
databases are designed in this phase.

Outputs from computer system are required primarily to communicate

the results of processing to users, They are also used to provide a permanent hard
copy of these results for later consultation. Various types of outputs required can be
listed as below:

 External outputs, whose destination is outside the organization

 Internal outputs, whose destination is with the organization
 Operational outputs, whose use is purely within the computer department e.g.,
program-listing etc.
 Interactive outputs, which involve the user is communicating directly with the
computer, It is particularly important to consider human factor when designing
computer .
 Other important factors that were taken into consideration are:

37
  The end user, who will use the output.
 The actual usage of the planned information.
 The information that is necessary for presentation
 When and how often output and their format is needed. While designing
output for project based Attendance Compilation System, the following
aspects of outputs designing were taken into consideration.
 The outputs (i.e., well formatted table outputs in the screen itself) designed
are simple to read and interpret.
 Format of each output was another important point taken into consideration.
Output media, for each output appropriate media is decided whether it will
be displayed on screen or will be taken to printer or both.
 Other output design related specifications, i.e., how frequently the outputs
will be generated, how many pages or sheets approximately it will keep
up, what is its planned use and output distribution to users are also taken
into account.

. Once all the output reports to be generated by ACS system were identified, they
were given to users for their acceptance. For prototyping various outputs, final outputs
models were created with dummy data, before they were finished.

Output Sources:

Output contents originate from these sources:

 Retrieval from a data source.

 Transmission from a process or system activity.
 Directly from an input source.

The information produced in an output can be presented as:

 Tabular contents
 Graphic format
 Using Icons

38
Output Definition:

The output should be defined in terms of:

Types of outputs

 Content-headings, numeric, alphanumeric, etc.,

 Format-hardcopy, screen, microfilm, etc.,
 Location-local, remote, transmitted, etc.,
 Frequently-daily, weekly, hourly, etc.,
 Response-immediate with in a period, etc.,

Data items:

The name given to each data item should be recorded and its
characteristics described clearly in a standard form:

 Whether alphanumeric or numeric

 Legitimate and specific range of characteristics
 Number of characters
 Positions of decimal point, arithmetic design, etc.,

Input Design:

The input design is the link that ties the information system into the
user’s world. Input specifications describe the manner in which data enters the system
for processing. Input design features can ensure the reliability of the system and
produce results from accurate data, or they can result in the production of erroneous
information.

39
Input Design consists of

 Developing specifications and procedures for data preparation

 Steps necessary to put data into a usable form for processing.
 Data entry, the activity of putting data into the computer processing.

Objective of Input Design

 Five objectives of design input focus on

 Controlling the amount of input required
 Avoid delay
 Avoiding errors in data
 Avoiding extra steps.
 Keeping the process simple.

Input stages several activities have to be carried out as part of the overall input
process.

They include some or all of the following.

 Data recording (i.e., collection of data)

 Data encapsulation (i.e., transfer of data)
 Data conversion (i.e., controlling the flow of data)
 Data transmission (i.e., transporting the data)
 Data validation (i.e., checking the input data)
 Data correction (i.e., correcting the errors)

Input Performa were designed, after a careful discussion with users. It was attempted
to cover all user requirements. Designed Performa were given to user for any
suggestion and final approval.

Various data items were identified and wherever necessary were recorded.

Input designs are aimed at reducing the changes of mistakes of errors. As the human
begins are prone to errors there is always a possibility of occurrence of chance of
errors. Adequate validation checks are incorporated to ensure error free data storage.
Some of the data validation checks applied are as following:

40
  Redundancy of data is checked. It means the records of primary key do not
occur twice.
 Primary key field of any table must not be left blank.
 Whenever items are coded, input code is checked for its validly with respect
to several checks.

Utmost care has been taken to incorporate the validation at each stage of the
system. E.g., when entering record into employee information table for employee, it is
checked that whether the corresponding employee exists in the employee information
table etc.

Enough messages and dialogue boxes are provided while design screen, which
does guide user at the time of any errors, or at time of entry. This feature provides a
user-friendly interface of native users. It emphasized that input design of is so designed
that it ensures easy and error free data entry mechanism. Once one is sure of input
data the output formatting becomes an routine work.

Software Design:

The purpose of this phase is to plan a solution for the problem

specified by the requirement document. This is first step in moving from the problem
domain to solution domain. Designing activity is divided into two parts.

1.specification of these modules and how they interact with each other to produce the
desired result.
2.Detailed Design: The internal goal of each of the modules specified in the system
design is decided.

Database Design:

A database is a collection of inter-related data stored with a

minimum of redundancy to serve many applications. It minimizes the artificiality
embedded in using separate files. The primary objectives are fast response time to
enquires, more information at low cost, control of redundancy, clarity and ease of
use, accuracy and recovery. The organization of data in a database aims to achieve

41
three major objectives, they are data integration, data integrity and data independence.
During the design of the database at most care has been taken to keep up the
objectives of the database design.

Code Design:

The process of code is to facilitate the identification and retrieve

of items of information. The code should be simple and easy to understandable. The
codes were designed in such a way that the features such as optimums human-
oriented use and machine efficiency unaffected.

For the code to be designed effectively, the following characteristics were also
considered while designing the code.

 Uniqueness
 Versatility
 Stability
 Simplicity
 Consciousness

The code should be adequate for present and anticipated data processing for machine
and human use. Care was taken to minimize the clerical effort and computer time
required to continue operation.

Process Design:

The process can be conceptualized in such a way to keep the methodology of main
module process along with some auxiliary task, which will run concurrently with the
main program.

The top-down approach is maintained so as to keep track of the

process, which satisfies the maintenance reliability testing requirements. The
concurrency of the data is checked during data entry, by means of validation check for
data in each field.

42
Design Requirements:

As the project will be accessed by many people. So design should be done keeping in
mind all kind of requirements of people and provided with easy and convenient and
easy way to access the database.

Reports are also generated in a manner, which is helpful for the people accessing the
website. In the nutshell, both the site and reports are designed by keeping in mind
the varying needs and demands of diverse kind of people.

Design Objectives:

Following goals were kept in the mind designing the whole project:

 To make this user friendly.

 To make this simplicity.
 To allow only authorized persons to change the database.
 To prevent of erroneous data from entering into database

5.2 - DESIGNING APPROACH

TOP DOWN DESIGN

The TOP DOWN approach starts from the highest level component of the hierarchy and
proceed through to lower levels. A top down design approach starts with the major

43
component of the system. Decomposing them into their lower level component and iterative
until the desired label of detail is achieved. Top down design method is in some form of step
wise refinement. Starting from a abstract design in each step the design is refine to more
concrete level, until we reach a level were no more refinement is needed. A system consists
of components, which have components of their own; indeed a system is a hierarchy of
components. The highest level component corresponds to the total system. The top down
approach begins from the highest level component of hierarchy and proceeds through to
lower levels. By contrast a bottom up approach starts with the lowest level component of the
hierarchy and proceeds through progressively higher levels to the top level components. The
top down approach has been promulgated by many researches and has been found to be
extremely useful for design. Most design methodologies are based on the top down approach.
A top down approach suitable only if the specifications of the system is clearly known and
the system development is from scratch.

6.HIGH LEVEL DESIGN

TABLE SCHEMA
(Login Table)

44
Column Name Data Type Description

USER_NAME Varachar(100) Admin Username

PASSWORD Varachar(100) Admin password

(Customer Details Table)

Column Name Data Type Description

Cust_Id Int(11) Customer identification

Cust_Name Varachar(100) Name of the customer

Cust_Add Varachar(100) Customer Address

Cust_Cont Varachar(100) Customer Contact

First_name Varachar(50) Customer First Name

Last_Name Varachar(50) Customer Last Name

(Product Detail Table)

Column Name Data Type Description

Product Id Int(11) Customer identification

Product_code Varachar(50) Code of the product

45
Description_Nam Varachar(50) Describing the product specification
e

Product_Name Varachar(100) Describing product Name

Product_Cost Varachar(100) Cost of the product

Cashier Detail Table

Column Name Data Type Description

Cash_Id Int(11) Cashier Identification

Cash_Name Varachar(100) Cashier Name

Cash_Position Varachar(100) Cashier Position

Cash_User Varachar(100) Cashier Username

Cash_Pass Varachar(100) Cashier Password

6.1- DATA FLOW DIAGRAM

46
A Data Flow Diagram (DFD) is a graphical representation of the information flow &
transformation that are applied, as data moves from the input to the output. It is also known
as “Data Flow Graph” or “Bubble Chart”. The DFD may used to represent increasing
information flow & function details. A level 0 DFD, also called a “Fundamental System
Model”, represent an entire software element as a single bubble with the input & the output
data directed by the incoming & outgoing arrows. Data Flow Diagram is commonly used
during problem analysis. Data Flow Diagram is quite general & nit limited to problem
analysis for Software Requirement Specifications (SRS). DFD’s are very useful if
understanding a system & can be effectively used during analysis.
A DFD shows the flow of data through the system. It views the system as a function
that transforms the input into desired output. The DFD aims to capture the transformations
that take place within a system to the input data so that eventually the output data is
produced. The agent that performs transformation of data from one state to another is called a
“Process”. So a DFD shows the movement of data through the different processes.
Named & circle shows the processes & data flows are shows by arrows entering or
leaving the circles. A rectangle represents a source or sinks & is a net originator or consumer
of data. A source or sink is typically outside the main system of study.
The DFD should be carefully scrutinized to make sure that all the processes in the
physical environment are shown in DFD. It should also ensure that none of data flow is
actually control information.

47
 FEATURES OF DATA FLOW DIAGRAM

1. The exceptional simplicity of the DFD symbology is one reason why data oriented analysis
techniques is the most widely used.
2. The data flow diagram is a graphical tool that can be very valuable during the system
analysis.
3. The DFD depicts information flow without explicit notation of control. (E.g. condition of
loops).
4. The level 0 Data Flow Diagram should depict the software as a single bubble.
5. Primary input / output files should be maintained.
6. One bubble at a time should be refined.
There is a natural tendency to over complicate the DFD. This happens when we try to show
too many details early.

SYMBOLS USED IN DATA FLOW DIAGRAM REPRESENTATION

48
 EXTERNAL An entity which interacts with our system. It
will produce information and consume it.
ENTTITY

A process which transforms information

received producing further output.
PROCESS

DATA
ITEM The flow of direction in particular direction.

The storage area which is used by one or

DATA STORE more process.

49
 Zero Level Data Flow Diagram

Inventory Customer
Management Enquiry
Request for
Supplier products Customer
Management Management
Inventory Report of stock
Products are
Management availability
supplied
System
Cashier
Payment Management
Management

Receving
Management

50
 1st Level Data Flow Diagram

Login to Check
Administrator Roles of Manage Inventory
System
Access System

Manage Customer

Check Manage Details

Credential
s Modules

Manage Purchasing
Details

Manage Payment

Details Manage Receiving

Stock Details

Manage System Manage Supplier Manage Login

Administration and Profiles Report
control

51
 6.2 ENTITY RELATIONSHIP DIAGRAM

The entity relationship model is a generalization of primitive commercial systems, which are
based on hierarchical and network approaches. The E-R relationship, which is also known as
Entity Relationship is based on the theory of real world which consists of a set of basic
objects, which are called entities and relationships among these object. An entity exists as an
object and is distinguishable from other objects.

For example: account number 1002 at the ICICI bank is an entity that uniquely identifies
one particular account.

Entity:

Any distinguishable person, place, thing, event or concept about which information is kept or
an object which can be distinctly identified and distinguished and represented in a database or
anything about which we store information is called an Entity.

Attribute:

Attributes describe the entity to which they are associated. A particular instance of an
attribute is a value. In other words attributes are the characteristics of an entity type.
Attributes can be classified as descriptors or identifiers. A descriptor describes a non-
uniquely identify an instance of an entity.

Notification For E-R Diagram:

There is no standard for representing data objects in E-R diagram. Each modeling
methodology uses its own notation. All notational style represents entities as rectangular
boxes and relationship as lines connecting boxes. Each style uses a special set of symbols to
represent the cardinality of a connection. An entity is represented in E-R diagram as a

52
 rectangular box enclosing the entity type name. Attribute names are enclosed in ellipses and
attached to their entity type by straight lines.

The symbols used for the basic E-R constructs are:

Notation Use Symbols

Lines Linking attributes

to entity sets to
relationship sets

Ellipse Representing
attributes

Rectangle Representing entity

set

53
 KEYS:-

A key is a value which can always be used to uniquely identify an object instance. It becomes
important to invent a method to distinguish entity and relationships. The differences between
entities must be expressed in terms of attributes.

Super Key:

A Super Key is a set of one or more attributes which, taken

collectively, allows us to identify uniquely an entity in the entity set.

Candidate Key:

An attribute that uniquely identify a row is called Candidate Key. Candidate key is also
referred to as Surrogate keys.

Primary Key:

A candidate key to choose to identify rows uniquely is called a Primary key.

Alternate Key:

If there are multiple candidate keys in a table, then the keys which are not chosen as primary
key will be called as alternate key.

Composite Keys:

When the key that uniquely identifies the rows of the table is made up of more than one
attribute it is called a composite key.

54
 Guideline for Drawing E-R Diagram:

When gathering information I have to:

a. Identify the entities in the system.

b. Identify the attribute of each entity.

Identify the relationship between the entitiy.

55
 User Address #login_id login_username

Admin mobile Admin_pass

Login
Admin Name

Admin Id

Admin Has

Cus_name
Manage
#Cus_id

Inv_num

6
Customer

has
Inventory

Cus_add #inv_id
Cus_pass
Inv_desc

Inv_type
Cus_mobile
Stock Inv_items

56
 #stk_id Stk_type Stk_desc

7.Low level design

Module ration:

. A system is considered modular if a consist of discreet component show that each

component can be implemented separately and a change to one component has minimal
impact on other components

 Each function in each abstraction has a single well defined purpose .

 Each function manipulates no more than one major data structure .
 Function share global data selectively. It easy to identify all routine that share a major
data structure .
 Function that manipulate instances of abstract data types are encapsulated with the
data structure be in manipulated.

Structure Chart:-

The structure chart is one the most commonly used methods for system design. Structures
chats are used during architectural design to document hierarchical structure, parameters and
interconnection in a system.

57
58
 8. Coding
The goal of the coding or programming phase is to translate the design of the system
produced during the design phase into code in a given programming language which can be
executed by a computer, and which performs the computation specified by the design. For a
given design, the aim is to implement the design in the best possible manner.

The coding phase affects both testing and maintenance profoundly. As we saw earlier,
the time spent in coding is a small percentage of the total software cost, while testing and
maintenance consume the major percentage. Thus it should be clear that the goal during
coding should not be to reduce the implementation cost, but the goal should be to reduce the
cost of later phases, even if it means that the cost of this phase has to be increase. In other
words, the goal during this phase is not simplify the job of the programmer. Rather the goal
should be to simplify the job of the tester and the maintainer.

This distinction is important, as most programmers are individualistic, and are mostly
concerned about how to finish their job quickly, without keeping the later phases in mind.
During implementation it should be kept in mind that the programs should not be constructed
so that they are easy to write but, that they are easy to read and understand.

There are many different criteria for judging a program, including readability, size of
the program, execution time, and required memory. In an experiment conducted, different
programmers were required to implement a program, and were given different goals. It was
found that the programs written by different programmers were very different, and each
tended to satisfy its goal. For our purposes ease of understanding and modification should be
tbasic goals of the programming activity. This means that simplicity and clarity are desirable,
while cleverness and complexity are undesirable.

Programming Practice:

The primary goal of the coding phase is to translate the given detailed design into
source code in a given programming language, such that code is simple, easy to test, and easy
to understand and modify. Simplicity and clarity are the properties a programmer should
strive for in the programs.

59
Top-Down and Bottom-Up:

The design of a software system consists of a hierarchy of modules. The main

program invokes its subordinate modules, which in turn invoke their subordinate modules
and so on.In a top down implementation, the implementation starts from the top of the
hierarchy, and then proceeds to the lower levels. First the main module is implemented and
then its subordinates are implemented and then their subordinates and so on. In a bottom up
implementation, the process is the reverse. The development starts with implementing the
modules that are at the bottom of the hierarchy. The implementation proceeds through the
higher levels, until it reaches the top.

Top down and bottom up implementation should not be confused with top down and bottom
up design. It is most reasonable to have implementation proceed in a top-down manner if
testing is being done in a top-down manner. On the other hand, if bottom-up testing is
planned then bottom-up implementation should be preferred.

Structured Programming:

Structured programming is often regarded as go to less

programming. A program has a static structure as well as a dynamic structure. The static
structure is the structure of the text of the program which is usually just a linear organization
of statements of the program. The dynamic structure of the program is the sequence in which
the statements are executed during the program execution. The goal of structured
programming is to write a program such that its dynamic structure is the same as its static
structure. In other words, the program should be written in a manner such that during
execution its control flow is linearized and follows the linear organization of the program
text. For structured programming, a statement is not a simple assignment statement, but could
be a structured statement. The key property is that the statement should have a single entry
and single exit. That is during execution, the execution of the statement should start from one
defined point and the execution should terminate at a single defined point.

60
Information Hiding:

To reduce coupling between modules of a system it is best that different

modules be allowed to access and modify only those data items that are needed by them. The
other data items should be “hidden” from such modules and the modules should not be
allowed to access these data items. Language and operating system mechanisms should
preferably enforce this restriction. Thus modules are given access to data items on a “need to
know” basis.

One form of information hiding that is supported by many modern programming

languages is data abstraction. The advantage of this form of data abstraction is that the data is
entirely in the control of the module in which the data is encapsulated.

Programming Style:

It is impossible to provide an exhaustive list of what to do and what not to do in order

to produce a simple and readable code. Being able to do this will amount to providing an
algorithm for writing good code. Here we will list some general rules which are usually
applicable.

 Names:
Most variables in a program reflect some entity inthe problem domain,
and the modules reflect some process. Variable names should be closely related to the
entity they represent and module names should reflect their activity. It is bad to
choose cryptic names or totally unrelated names. It is also bad practice to use the
same name for multiple purposes.

 Control constructs:
As discussed above it is desirable that as much as possible single entry,
single exit constructs should be used. It is also desirable to use a few standard control
constructs rather than using a wide variety of constructs, just because they are
available in the language.

61
 Gotos:

Gotos should be used sparingly and in a disciplined manner. Only when the
alternative to using gotos is more complex should the gotos be used. In any case
alternatives must be thought of before finally using a goto. If a goto must be used forward
transfers is more acceptable that a backward jump.

 Information Hiding:
Information hiding should be supported where possible. Only the access
functions for the data structure should be made visible while hiding the data structure
behind these functions.

 User Defined Types:

Modern languages allow the users to define types like the enumerated type.
When such facilities are available, they should be exploited where applicable.

 Nesting:
The different control constructs, particularly the if-then-else, can be nested. If
the nesting becomes too deep, the programs become harder to understand. In case of
deeply nested if-then-else, it is often difficult to determine if statement to which a
particular else clause is associated. Where possible, deep nesting should be avoided
even if it means a little inefficiency.

 Module Size:
A programmer should carefully examine any routine with very few
statements or with too many statements. Large modules often will not be functionally
cohesive and too small modules might be incurring unnecessary overhead. There can
be no hard and fast rule about module size and the guiding principle should be
cohesion and coupling.

 Module Interface:
A module having a complex interface should be carefully examined.
Such modules might not be functionally cohesive and might be implementing
multiple functions. As a rule of thumb any module whose interface has more than five

62
 parameters should be carefully examined and broken into multiple modules with a
simpler interface if possible.

 Program Layout:
How the program is organized and presented can have great effect on the
readability of programs. Proper indentation, blank spaces, and parenthesis should be
employed to enhance the readability of programs. Automated tools are available to
“pretty print” a program, but it is good practice to have a clear layout of programs.

Side Effects:

When a module is invoked, it sometimes has side effects of modifying the

program state beyond the modification of parameters listed in the module interface definition,
for example, modifying global variables. Such side effects should be avoided where possible,
and if a module has side effects, they should be properly documented

Robustness:

A program is robust if it does something planned even for exceptional condition. A

program might encounter exceptional conditions in such forms as incorrect input, the
incorrect value of some variable and overflow. A program should try to handle such
situations. In general a program should check for validity of inputs, where possible, and
should check for possible overflow of the data structures. If such situations do arise, the
program should not just “crash” or “core jump”, but should produce some meaningful
message and exit gracefully.

63
 Login page:

Home page:

64
Product List:

Customer List:

65
Purchase Order List:

Purchase Order form:

66
Supplier:

67
 9. Testing

The code is tested at various levels in software testing. Unit, system and user acceptance
testing are often performed. This is a grey area as many different opinions exist as to what the
stages of testing are and how much, if any iteration occurs. Iteration is not generally part of
the waterfall model, but usually some occur at this stage. In the testing the whole system is
test one by one

Following are the types of testing:

 Defect testing the failed scenarios, including defect tracking

 Path testing
 Data set testing
 Unit testing
 System testing
 Integration testing
 Black-box testing
 White-box testing
 Regression testing
 Automation testing
 User acceptance testing
 Software performance testing.

68
System Testing:

It involves two kinds of activities: integration testing and acceptance testing

developing strategy for integration the components of a software system in to a
complete system requires functioning of the whole system and careful planning so that
modules are available for integration when needed.

Acceptance testing involves planning and execution of various types of tests in

order to demonstrate that implemented software system satisfies the requirement
document.

Integration testing:

It is a systematic technique for testing the programmed structure while

at the same time conducting test to uncover errors associated with
interfacing. The objective is to play unit tested modules and build a
programmed structure that has been dedicated by design. Bottom-up
integration was used in developing.

Testing mechanism:

Software testing is the most important phase of any software development life
cycle. It is the testing part, which validates the software and check whether the
software is working as desired or not.

The major purpose of testing is to retrieval bugs in the software. In testing

software design is executed with various test inputs for which the test programmer
knows result in advance.

69
The departure of the programmed output from the known results confirms that the

software contains error.

Testing is divided into following phases:-

1. The module interface was tested to assume that information properly float into
and out of the program unit test.
2. The local data structure was examined to assume that data stored temporally
maintain their integrity during all steps in an algorithm execution.
3. Boundary condition were tested to assume that module operated properly at
boundaries establish to limit or restrict processing.
4. All independent parts through this control structure were exercised to assume
that all statement in a module have been executed at least once.
5. All error handling path were tested.

Acceptance testing:
Acceptance testing is performed with realistic data of the client to demonstrate
that the software is working satisfactory.
Testing here is focused on external behavior of the system; the internal logic
of program is not emphasized.

White box testing:

This is a unit testing method, where a unit will be taken at a time and tested
thoroughly at a statement level to find the maximum possible errors.

70
Black box testing:
This testing method considers a module as a single unit and checks the unit
at interface and communication with other modules rather getting into details at
statement level. Here the module will be treated as a block that will take some input
and generate output. Output for a given set of input combinations are forwarded to
other modules.
Desirable features are frequently dropped because there is no time to
implement them. Code rewrites are also set aside, even if they are needed to bring a
fragile first working version to a level a programmer considers professional. A
conscientious programmer might take the initiative and do the job anyway, “on the
sly”. Late in the project, he may drop a significant change into the package without
warning. These efforts go beyond the call of duty and the 40- hour week. They may
improve the product tremendously or destabilize it badly, probably both for a time.
Whatever the result, people take personal initiative to improve the product.

71
 Black Box Testing (Functional Testing) through mannual

TEST TEST CASE TEST CASE INPUT EXPECTE ACTUAL Result

CASE ID DESCRIPTIO PROCEDU DATA D RESULT RESULT
N RE
Tc Need a valid Verify the Enter Login Login Ok
_login_01 username and Login valid Successfully
valid Password username
and valid
Password
Tc Need a valid Verify the Enter Login Login Failed Not
_login_02 username and Login valid Successfully Ok
valid Password username
and
invalid
Password

Test Case table for Log In:

72
TEST CASE TEST CASE TEST INPUT EXPECTED ACTUAL RESU
ID DESCRIPTI CASE DATA RESULT RESULT LT
ON PROCEDU
RE
Tc_SignUp_0 Need a valid Verify the Enter valid Registration/ Registration/ Ok
1 Name ,valid Registration Name, valid signUP signUP
Mobile ,valid Mobile ,valid successfully
successfully
Password, Password,
valid Address valid
, valid City Address,
valid City
Tc_SignUp_0 Need a valid Verify the Enter valid Registration/ Registration/ Not Ok
2 Name, valid Registration Name, valid signUP signUP Failed
Mobile ,valid Mobile ,valid
successfully
Password, Password,
valid Address valid
, valid City Address,
valid City
Test Case table for Sign Up:

73
 8. IMPLEMENTATION

For the implementation of the proposed solution we use the coding conventions. The
main reason for using a consistent set of coding conventions is to standardize the structure
and coding style of an application so that we and other can easily read and understand the
code.

Good coding conventions result in precise, readable and unambiguous source code
that is consistent with other language.

Conventions are as intuitive as possible. For the database the attributes have been
named in away that each attribute is predictable to depict the meaning. For the tables the
names have been given to symbolize the exact nature and need of the table.

74
 11. MAINTENANCE

Software maintenance is the last phase in the software engineering process that
eliminates errors in the working system during its work span and to tune the system to any
variations in its working environment. The system requires maintenance as there may be
changes and requirement in the organizational needs, government policies, hardware and
software environment etc. Often small deficiencies are found as a system is brought into
operation and changes are made to remove them. System requirements may be revised as a
result of system usage or changing operational needs. Perhaps oversight that occurred during
the development process need to be corrected. Often the maintenance need arises to capture
additional data for storage in a database or in transaction files or perhaps it may be necessary
to add error detection features to prevent system users from in adversely taking an unwanted
action.

Maintenance of the system after it is installed is concerned with an additional factor in

hardware. Once the system is delivered and installed there is a brief warranty period during
which time the vendor is responsible for maintenance. This is a typically a 90 day period after
that time the purchase has the option of acquiring maintenance from various sources.
Maintenance source excepting vender is also available from companies specializing in
providing the service called third party maintenance companies.

When the system is installed, it is generally used for long period the average life of
system is 4.6 years with the eldest applications often is used for over 10 years the need for
debugging and correcting errors or failure on an emergency basic is comparatively low: less
than 20% of the task of correction system and organization are in constant state of flux;
therefore the maintenance of the system also involved adoption for earlier version of
software.

75
 BIBLIOGRAPHY

BOOKS

1. “Introduction to Cloud Computing Architecture” 1st Edition June 2009, Sun

Microsystems Inc.

2. PankajJalote , “ An approach to software engineering” , third edition , 2005 ,

Narosa Publishing House.

3. Leon &Leon , “Database Management System” , Vikas Publishing House.

4. Elmasri , Navathe,” Fundamentals of database systems ”,addision Wesley.

Websites:
1. www.wikipidea.com

2. www.tutorialspoint.com

3. www.youtube.com

4. www.w3school.com

76