ACKNOWLEDGEMENT

I take this opportunity to express my deepest gratitude to those who have generously
helped me in providing the valuable knowledge and expertise during this
project.

I am thankful to Mr. Rajiv Bedi and Mr. S.K.Gupta Lect of Beant College of
Engineering and Technology, for their thorough guidance in making this project. I shall
also like to specially thank them for giving me the required guidance and removing any
difficulties faced by us during the project.
I want to formally acknowledge my sincerest gratitude to all those who assisted and
guided me in completing this project report and making my work a memorable and
successful experience.
 CONTENTS

Part-1

1. INTRODUCTION

1.1 Objective of the Proposed System

1.2 Project Profile
1.3 Project Detail

Part-II

2. SYSTEM ANALYSIS

2.1 Requirement Analysis

2.1.1 Hardware and Software Specification
2.1.2 Brief Description of Technology Used

2.2 Feasibility Analysis

2.2.1 Technical Investigation
2.2.2 Economic Feasibility
2.2.3 Operational Feasibility
2.3 System Development Life Cycle Model

Part-III
3. SYSTEM DESIGN

3.1 Data Flow Diagram

3.2 Entity-Relationship Diagram
3.3 Schema Design
3.3.1 Database Design
3.3.2 Description of Tables
Part-IV

4. Validation and Verification

Part-V

5. SOFTWARE TESTING

5.1 Need of Testing

5.2 Types of Testing
5.3 Approach used for Testing
5.4 Maintenance
5.5 Security
Part-VI

6. IMPLEMENTATION

6.1 Input & Output Design

Part-VII

7. Bibliography

Part-1
 Introduction

1.1 OBJECTIVE OF THE PROPOSED SYSTEM

The motto of the proposed system is to create a system which makes sales and purchase of the
goods Online in the retail stores.
The following are the objective of the proposed system.

USER FRIENDLY INTERFACE Since main interaction of the system

has to be with the user, the user
interface should be attractive and
meaningful.
MINIMUM EFFORT Ensure that very less effort will be
required the site and generation of
report
FLEXIBILITY Provides maximum flexibility to the
Administrator in maintaining and
modifying the information about existing
modules and functionalities.

ACCURATE Accuracy is the main concern of the

Proposed system.

RELIBILITY It’s the main objective so as to win the

Confidence of the user and to provide
information on which he can relies
upon.
SECURITY Since the information entered is of vital
Importance to the organization and to
the owner of the website, it should be
made to allow only the website
developers to manipulate the data.

FAST The system should be fast enough to

give
user of the system the feel of using the
best online system
1.2 PROJECT PROFILE

The project titled ‘Retail Management System’ is developed for NSPL Ltd., Amritsar .

Purchase
Retail Company
Manufacturin Managemen
Unit g Unit t Unit

Warehouse

Goods/Items

Franchise
(Retail Stores)

Sales Reports

A Retail Company may sell goods manufactured in its own company as well as goods
purchased from other companies. It constitute of following units:
• Purchase unit
• Manufacturing unit
• Management unit

• Purchase Unit: A retail company may sell goods of brands other than its own.
Purchase unit deals with the goods purchased from other manufacturing companies.

• Manufacturing Unit: A retail company may manufacture goods with its own brand
name. These goods are produced in manufacturing unit of a company. E.g. Ebony.

• Management Unit: Management unit handles the functioning of all other units of an
organization or a company.

• Warehouse: All goods purchased/manufactured are kept in warehouse of a company.

• Franchise/Retail Stores: Different stores of a company are opened at different

locations where actual selling of the goods takes place.

All the above mentioned units must work together in some orderly manner for a
company to be profitable. And this is what we going to do in our project. We are
developing a web application which will affect the functionality of these units in one or
another way.
1.3 Project Details

There will be two logins in our project, one for the Administrator and another for the
Franchise.

Administrator Features: Admin will deal with the following assets of a company:
1. Franchise: A franchise is any retail store opened at any location. E.g. Amritsar’s
Franchise. Admin can add, modify and delete any franchise from a list of franchises a
company has.

2. Item Group: A retail company has goods of different brands as well as its own
manufactured goods. E.g. Reebok. Each brand will form a single item group. Admin
can add, modify and delete any item group.

3. Item: An item group may constitute different products/items. E.g. Reebok shoes,
Reebok track suit, Reebok cap, etc. Admin can add, modify and delete any item from
any item group.

4. Schemes: Admin can launch different schemes at different times.

5. Purchase Order: Admin can place a purchase order for goods manufactured at
different companies.

6. Reports: Admin can view following reports:

• Franchise’s Manager Report
• State Wise Area Report
• City Wise Area Report

Franchise Features: Franchise will deal with the following assets of a company:
1. Customer: A customer can be any individual that visits the retail store to buy an
item(s). A franchise can add, modify or delete the details of customers from a list of
same.
2. Items: Franchise can add, modify and delete items that are currently in stock in
retail store.

3. Sales: It constitutes the actual selling of the goods by the franchise to its customer.
This form will include the sales bill that will be given to the customer on purchase of
any item. The bill will constitute the adjustments for the schemes, taxes and
membership of a customer.

4. Sales Return: If somehow an item is found defected or is not as per the customer’s
requirement then it is returned to the retail store. Sales Return will deal these kinds of
transactions.

5. Purchase Order: Franchise can place an order for the goods from the Admin.

6. Reports: Franchise can view following reports:

• Sales Report
• Sales Return Report
• Purchase Order Report
 Part-2

System Analysis

2.1 SYSTEM REQUIREMENT AND SPECIFICATION

The success of a system depends largely on how accurately a problem is defined. Thoroughly
investigating and properly carried out to the choice of the solution analyze the phase in which
the requirement of the system are identified. System analysis is a detailed study of the various
operation performed by a system and there relationships within an outside of the system.

The question is: what must be done to solve the problem? One aspect of analysis is defining the
boundaries of the system and determining whether or not a candidate system should consider
other related system. During analysis data are collected on the available files, decision points
and transaction handle by a parent system. Data flow diagram, interviews on-site observations,
questionnaires are used as a logical system model and tools to perform the analysis.

Task, which are performed by an analyst:

• Gather all facts about the present system from the employees.
• Studied strength and weakness of the current system
• Determined “what” must be done to solve the problem.

PRELIMINARY INVESTIGATION:-

Before designing a system, the requirement of the system has to be properly determined and
user need have to be properly determined and user needs have to be taken into account, initial
investigation is the first step in the development of the system. This is the way handle the
investigation of need i.e. the user request to change, improve or enhance an existing system.

During this phase that are to be considered:

How the present system works?
Volume of the work type of transaction etc
Time taken to process the data through system
Frequency in issuing the reports
List of documents, files and repots associated with the system

By the following the above steps of initial investigation are carried out first the existing system
was carried out. The reporting format are gathered, the next step in initial investigation is to find
out and collect more information from users and respective users who actually carry the existing
system. From the discussion, the information about outputs, reports were obtained.

2.1.1Hardware and Software Requirements

SOFTWARE REQUIREMENTS

The system must have the following software requirements:

1 Visual Studio 2005 (version 2.0)

2 .Net Framework (version 2.0)
3 SQL Server 2000/2005

HARDWARE REQUIREMENTS

The system must have the following hardware requirements:

1 Pentium IV Processors
2 256 MB of RAM
3 5GB of Hard Disk
4 Server Machine
5 Client Machine

2.1.2 BRIEF DESCRIPTION OF TECHNOLOGY USED

IIS (Internet Information Server):- IIS is the best place to install ASP.NET web sites,
because it is likely to be closest to the configuration required when you deploy a web site.
The security model is different to IIS - the application runs in the context of the current user
rather than an ASP.NET-specific account.

ASP.NET:- ASP.NET is part of the .NET Framework & is a technology that allows for the
dynamic creation of documents on a web server when they are requested via HTTP. This
mostly means HTML documents, although it is equally possible to create WML documents
for consumption on WAP browsers, or anything else that supports MIME types.
ASP.NET provides access to all of the controls on a page as objects, in a rich environment.

HTML (Hyper Text Transfer Protocol):- HTML is the default output of ASP.NET
pages.
The ASP.NET coding is complied & the output in the form of HTML is shown to the user by
the browser. You are presented with the basic code required for an HTML page following the
XHTML schema, with a few extra bit of code. The most important extra is the <form>
element, which will contain your ASP.NET code.

SQL (Structured Query Language):- SQL is a language that provides an interface to

relational database systems. SQL was developed by IBM in the 1970s for use in system
R.SQL is often pronounced as SEQUEL.
In common SQL also encompasses DML (Data Manipulation Language) & DDL (Data
Definition Language).

SQL SERVER 2005:- SQL Server 2005 is a new host of the .NET runtime. It allows running
a .NET assembly inside the SQL Server process, where it is possible to create stored
procedures, functions, data types, & triggers with CLR code.

INTERNET EXPLORER: - It is the browser that is used by a lot of users, a browser through
which a user asks any web page to be used.
2.2 FEASIBILITY ANALYSIS

It is the second stage in the system development life cycle. Depending on the initial investigation
the survey is expanded to a more detailed study.
A feasibility study is the test of proposal according to its viability impact on the organization,
ability to meet user needs and effective use of the resources.
The objective of the feasibility is not to solve the problem but to acquire a sense of its viability
scope. There are three key consideration involve in the feasibility analysis.
Feasibility study asks if the system will work when it is developed and installed. It tries to find out
the technical, operational, social, financial and other barriers, if any, in the project development.
For a project to be successfully implemented there should be sufficient support for the project
from management and users. There should be a curiosity for change from the management to
improve an existing system or to replace the older one because of its obsoleteness or to
introduce new technology for greater performance. The users should be involved in the project
planning. The project should not produce erroneous results, with proper security of company’s
data.

(i)Technical Feasibility:-
A system is said to be technically feasible if either there exists the required technology or the
company is willing to go for the technology after the ‘Cost & Benefit analysis’ is done and the
necessary technology exists. A project is also said technically feasible if further development of
the software is possible. So far as this project is concerned, this project uses C# as the front-end
GUI tool. So, the users find the same ease in operating the software as if they were operating
the familiar Microsoft Windows based any other application. Further, the use of MS-SQL Server
7.0 reduces most of the data maintenance activities like, inconsistencies in data, taking backups,
though a specialized Database Administrator is required to do so. On the hardware part, the
company has two options to choose from. The first option is to go for a standalone system and
install the complete software on every system. The second option is to go for a client-server
system, with the database server (MS-SQL Server 2005) installed on the server with an
operating system like Windows 2003 Server/XP and this software on every Client. Of course, the
third option is to go for remote booting with dumb terminals depending for everything on the
server, including the processing needs.
This project is based on the second option of the ‘Client-Server’ based networking. This reduces
the inconsistencies in data that is possible with stand-alone systems and this also reduces the
chance of overloading the server with lots of processing with processors-hungry dumb-terminals,
which is caused by the third option.

(ii)Operational Feasibility:-

Considering analysis of the preliminary information obtained, the volume of data, numbers of
application and rough output requirements, it is possible to arrive at some options on the
hardware front. It is possible to arrive at some broad estimates of disk space requirements, data
entry loads and print loads. Getting details of hardware and system software selection required
the detailed input and output needs of the project, users of the developed application and
available resources.
The study yielded the following results:
Hardware requirements to run the Application under consideration:-

Option 1:
The first option would be to go in for a PC. Automation will be done using a machine for all
concerned departments. The configuration of machine would have a large disk capacity with a
good printer attached to the main system for high volume printing. This configuration could be
considered in consonance with option1 for software development, with the common database
residing in the centralized system and having facility of either online or offline data storage as
well. This must for data security reasons.

Option 2:
The second option that could be considered would be to go in for a distributed network. The
hardware could consist of a LAN (Windows 2003 Server O/S) with multiple nodes and a server.
Each node would be located at the respective departments. All common files and databases
would be located and updated on the main server, with appropriate locks and security
mechanisms being built in the nodes would also enable local processing for standalone jobs, if
any so that any node has a separate hard disk drive.
(iii)Economic Feasibility:
Economic analysis is most frequently used method for evolution of a proposed system.
Costs/benefits and savings are determined. Those are expected from the proposed system and
compare with the cost. He different types of cost are considered as manpower cost and
operating cost.
• Man Power Cost
The system is designed and development in the company development department. So
on extra cost need to pay of redevelopment of the system no special training is required
to operate this software as it has a user friendly GUI interface so there is no need to extra
man power.
• Hardware Cost
Since the system is designed for internet use so no additional hardware are needed to
run this software and the company has enough computers at it hand to maintain this
software and to update according to its need.
• Operation Cost
The proposed system is designed for internet users and it is designed to provide easy,
fast, accurate data and information and work far way better than the existing system. So
the time to access and process information reduces considerably which make it cost
effective.
2.3 SYSTEM DEVELPOMENT LIFE CYCLE MODEL

This is also known as classic life cycle or linear sequential model or waterfall method.
This has the following activities.

• System/Information Engineering and modeling

• Software Requirement analysis
• System Analysis and design
• Code Generation
• Testing
• Maintenance

(i)System/information engineering and modeling

As software is always of large system (or business), work begins by establishing requirements
for all system elements and then allocating some sunset of these requirement of software. This
system view is essential when software must interface with other elements such as hardware,
people and other resources. System is the basic and very critical requirement for the existence
of software in any entity. So if the system is not in place, the system should be re-engineered
and spice up.
Once the ideal system is engineered or tuned up, he development team studies the software
requirement for the system.

(ii)Software Requirement Analysis:

This is also known a feasibility study. In this phase the development team visits the customer
and studies their system. They investigate the need for possible software automation in the
given system. By the end of the feasibility study the team furnishes a

document that holds the different specific recommendations for the candidate system. It also
includes the personnel assignments, costs, project schedule and target dates. The requirements
gathering process is intensified and focused specially on software. To understand the nature of
the program to be built, the system engineer (analyst) must understand the information domain
for the software as well as required function, behavior, performance and interfacing. The
essential purpose of this phase is to find the need and to define the problem that needs to be
solved.

(iii)System Analysis and Design

In this phase, the software’s overall structure and its nuances are defined. In terms of the
client/server technology, the number of tires needed for the package architecture, the database
design, the data structure design etc are all defined in this phase. Analysis and design are very
expensive to solve in the later stage of the software development. Much care is taken during this
phase. The logical system of the product is developed in this phase.

(iv)Code Generation
The design must be translated into a machine-readable form. The code generation step
performs this task. If design is performed in a detailed manner, code generation can be
accomplished with out much complication. Programming tools like computers, interpreters, ad
debuggers are used to generate the code different high level programming language like
ASP.NET, HTML, and SQL SERVER are used for coding. With respect to the type of
application, the right programming language is chosen.

(v)Testing:
Once the code is generated the program testing begins. Different testing methodologies are
available to unravel the bugs that were committed during the previous phases. Different testing
tools and methodologies are already available. Some companies build there own testing tools
that are tailor made for there own development operations.

(vi)Maintenance:
Software will definitely undergo change once it is delivered to the customer. There are many
reasons for the change. Change could happen because of some unexpected input values into
the systematic addition, the changes in the system could directly affect the software operations.
The software should be developed to accommodate changes that could happen during the post
implementation period.

-> Prototyping Model:

This is a cyclic version of the linear model. In this model, once the requirement analysis is done
and the design for a prototype is made, the development process gets started. Once the
prototype is created it is given to the customer for evaluation. The customer tests the package
and gives his/her feedback to the developer who refines the product according to the customer’s
exact expectation. After a finite number of iterations, the final software package is given to the
customer. In this methodology, the software is evolved as a result of periodic shutting of
information between the customer and developer. This is the most popular development model
in the contemporary IT industry most of the successful software products have been developed
using this model as it is very difficult (even for a whiz kid) to comprehend all the requirements of
a customer in one shot. There are many variations of this model skewed with respect to the
project management style of the companies. New versions of software product evolve as a result
of prototyping.
 Part-3

System Design

SOFTWARE ENGINEERING PARADIGM APPLIED

3.Structured Analysis & Detailed DFD

Structured analysis is a set of techniques and graphical tools that allow an analyst to develop a
new kind of system specification that are easily understandable to the end-user and other non-
technical and managerial people. The structured analysis tools used in this project are Data
Flow Diagrams, Structure Charts, and Flow Charts etc.

Software Engineering
Software Engineering is a planned and systematic approach to the development of software. It is
a discipline that consists of methods, tools and techniques used for developing and maintaining
software.
To solve actual problems in an industry setting, a software engineer or a team of engineers must
incorporate a development strategy that encompasses the process, methods and tool layers and
generic phases. This strategy is often referred to as a process model or Software Engineering
paradigm. For developing a software product, user requirements are identified and the design is
made based on these requirements. The design is then translated into a machine executable
language that can be interpreted by a computer. Finally, the software product is tested and
delivered to the customer.

Design is an activity of translating the specifications generated in the software

requirements analysis into specific design. The design involves designing a system that

satisfies customer requirements.

In order to transform requirements into a working system, we must satisfy both the customer and

the system builders on development team. The customer understands what the system is to do.

At the same time, the system builders must understand how the system is to work. For this

reason, system design is really a two-part process. First, we produce a system specification that

tells the customer exactly what the system will do. This specification is sometimes called a

conceptual system design.

This mirrors the two parts of requirement description. The conceptual design concentrates on the function

of the system, while the technical design describes the form the system will take.

CONCEPTUAL DESIGN:

The conceptual design tells the customer what the system will do. The system is

described in terms of its boundary, entities, attributes, and relationships. In the conceptual

designing phase we have considered the following questions: -

• Where will the data come from?

• What will happen to it in the system?

• What will the system look like to user?

• What choices will user be offered?

• What will the reports and screen look like?

Moreover, the system is described in language that the customer can understand, rather

than in computer jargon and technical terms.

The system description may even list acceptable user responses and the actions that may

result. However, the customer is not told how the data are stored in the system or what kind

of database management system is used for data manipulation. At the time of conceptual

design, we have written in the client’s language, which does not contain technicalities. It

describes the functions of the systems and incorporates all requirements in adequate details.
TECHNICAL DESIGN:

The technical design explains the system to those hardware and software experts who will

implement it. The design describes the hardware configuration, the software needs, the

communication interfaces, the input and output of the system and anything else that

translates the requirements into a solution to the customer’s problem. The design description

is a technical picture of the system specification. Thus we include the following items in the

technical design:

 The System Architecture: A description of the major hardware components and their

functions.

 The System Software Structure: The hierarchy and function of the software components.

 The data structure and flow through the system.

DESIGN APPROACH:

Modular approach has been taken into consideration. A design is the determination of the

modules and inters modular interfaces that satisfy a specified set of requirements. A design

module is a functional entity with a well-defined set of inputs and outputs. Therefore, each

module can be viewed as a component of the whole system, just as each room is a

component of a house. A module is well defined if all the inputs to the module are essential

to the function of the module and all outputs are produced by some action of the module.

Thus if one input will be left out, the module will not perform its full function. There are no

unnecessary inputs; every input is used in generating the output. Finally, the module is well

defined only when each output is a result of the functioning of the module and when no input

becomes an output without having the transformed in some way by the module.

Modularity: Modularity is a characteristic of good system design. High level modules give

us the opportunity to view the problem as whole and hide details that may distract us. By
being able to reach down to a lower level for more detail when we want to, modularity

provides the flexibility , trace the flow of data through the system, and target the pockets of

complexity.

These all are interrelated with each other and also self sufficient among themselves and help

in running the system in an efficient and complete manner.

Level of Abstraction: Abstraction an information hiding allows us to examine the way in

which modules are related to one another in the overall design the degree to which the

modules are independent of one another is a measure of how good the system design is.

Independence is desirable for two reasons.

First it is easier to understand how a module works if its function is not tied to others. It is

much easier to modify a module if it is independent of others. Often a change in

requirements or in a design decision means that certain modules must be modified. Each

change affects data or function or both. If the modules depend heavily on each other, a

change to one module may mean changes module that are affected by the change.

Coupling: Coupling is a measure of how modules depend on each other. Two modules are

highly coupled if there is a great deal of dependence between them. Loosely couple modules

have no interconnection at all. Coupling depends on several things

• The references made from one module to another.

• The amount of data passed from one module to another.

• The amount of control one module has over the other.

• The degree of complexity in the interface between one module and another.
 Thus, coupling really represents a range of dependence, from complete dependence to

complete independence. We want to minimize the dependence among modules for several

reasons. First, if an element is affected by a system action, we always want to know which

module causes an effect at a given time. Second, modularity helps in tracking the cause of

the system errors. If an error occurs during the performance of particular function,

independence of modules allows us to isolate the defective module more easily.

Cohesion: cohesion refers to the internal “glue” with which a module is constructed. The

more cohesive a module, the more related are the internal parts of the module to each other

and to the functionality of the module. In other words, a module is cohesive if all elements of

the module are directed towards and essential for performing the same function.

For example the various triggers written for the Subscription entry form are performing the

functionality of the module like querying the old data, saving the new data, updating records etc.

So it’s a highly cohesive system.

Scope of control and effect: Finally we want to be sure that the modules in our design do

not affect other modules over which they have the control. The modules controlled by the given

module are collectively referred to as the scope of effect. No module should be in scope of effect

if it not in scope control.

Thus in order to make the system easier to construct, test, correct, and maintain our goals had

been: -

• Low coupling of modules

• High cohesive modules

• Scope of effect of a module limited to its scope of control

It was decided to store data in different tables in SQL Server. The tables were normalized and

various modules identified so as to store data properly create designed reports and on screen

queries were written. A menu driven (user friendly) package has been designed containing

understandable and presentable menus. Table structures are enclosed. Input and output details

were made which are enclosed herewith.

Number of modules and their description:

The Project is divided into two modules ie. Administrator and franchisee

Administrator:
This module has only access to the administrator. The administrator only can check this module
and make the required modifications as per requirements and he can add and delete the
Franchisees. Administrator is also responsible for issues of goods to the Franchisee
The Spiral model incorporates the best characteristics of both the waterfall and prototyping
model. In addition, the Spiral model also contains a new component called Risk Analysis, which
is not there in waterfall and prototype model.
In the Spiral model, the basic structure of the software product is developed first. After the basic
structure is developed, new features such as user interface and data administration are added to
the existing software product. This functionality of the Spiral model is similar to a spiral where
the circles of the spiral increase in diameter. Each circle represents a more complete version of
the software product.

Franchisee:
According to the requirement login is provided to Limited administrator and Franchisees. This
module is integrated with Restriction of unauthorized access. Each Franchisee can only access
those data, which are required for his/her work.

3.1 DATA FLOW DIAGRAM

Data flow diagram illustrate low data is processed by a system in terms of inputs and outputs.
Data flow diagramming is a mean of representing a system at any level of detail with a graphic
network of symbols showing data flow, data stores, data process and data sources/ destination.
The data flow diagram is analogous to a road map. It is a network model of all possibilities with
different detail shown on different hierarchical levels. The process representing different details
level is called “leveling” or “portioning” by some data flow diagram advocated. Like a road map,
there is no start or stop point, no timeout timing or steps to get somewhere. We just know that
the data path must exist because at some point it will be needed. A road map shows all existing
or planned roads because the roads are needed.

Details that are not shown on the different levels of the data flow diagram such as volumes,
timing, frequency etc is shown on supplementary diagrams or in the data dictionary. For
example, data store contents may be shown in the data dictionary.
PURPOSE/OBJECTIVE:
• Graphical eliminating thousands of words.
• Logical representing, modeling what a system does, rather that physical models showing
how it does it.
• Hierarchal, showing system at any level of detail
• Jargon less, allowing user understanding and reviewing.
The goal of data flow diagramming is to have a commonly understood model of a system.
The diagram are supposed by other techniques of structured system analysis such as
data structure diagrams, data dictionaries and procedure representing techniques such
as decision tables, decision trees and structured English.

Data flow diagrams have the objective of avoiding the cost of………
• User/developer misunderstanding of a system, resulting in a need to redo system or in
not using the system.
• Having to tart documentation from scratch when the physical system changes since the
logical system, what gets done often remain the same when technology changes.
• System inefficiencies because a system gets computerized before it gets systematized.
• Being unable to evaluate system project boundaries or degree of automation, resulting in
a project of inappropriate scope.

PROCEDURE:
The procedure for producing a data flow diagram is to:

• Identify and list external entities providing inputs/receiving outputs from system
• 8 Identify and list inputs from outputs to external entities.
• Confirm through personnel contact sent data is received and vice-versa.
• Trace and record what happens to each of the data flows entering the system (data
movement, data storage, data transformation/processing).
• Attempt to connect any diagram segment into a rough draft.
• Verify all data coming out of store goes in.
• Redraw to simplify ponder and question result.
• Review with informed.

Administrator Login
Process
Not Valid

Exit
Validatio
n
Check

Create
Franchise
e

Franchisee
Data Store

Issue Items
Items Data Store

Levy Schemes
Schemes Data Store

Payment Payment Mode

Modes Data Store

Flow Diagram: ADMINISTRATOR

Franchisee
Login
Not Valid Process

Exit

Validatio
n
Process

Valid

Create Own
Accounts

Accounts
Data Store

Items Items
Data Store

Sales to
Account
s Sales Data
Store

Purchase
Order to PurchOrder
Administrat Data Store
or

Flow Diagram: FRANCHISEE

 3.2 Entity Relationship Diagram

Attributes of Login

User_Name

User_id Password

Login

Sales Bill : Sales Bill is issued by franchisee. It’s Inputs come from Accounts, Items, Items
Group, Payment Mode and Output is Sales ,Sales Detail, sales Charges.
Accounts Items Items Groups Payment Mode

Payment
Accounts ID Items ID Mode ID

Sales

Sales Order Sales Charges Sales Details

3.3.1 DATABASE DESIGN

One of the most important factors in designing a database is a well executing application and
the design of the database tables. For a good database design, good understanding of the
normalization concept is needed.

The tables are the basic building material of data. A table is two dimensional grids with rows and
columns. The columns indicate fields of the tables while row indicate records of the tables. The
table has been so created that duplicity of the items and optimizing the database prevents
redundancy. The packages is made in mind that job mustn’t be time consuming and less man
power an efforts are required so that the user ids satisfied.

DESCRIPTION OF TABLES

The database consists of ninety tables each has its own primary key and defines a unique
relation among data items each of the tables are described separately from the next page.

1) Accounts
2) Charges
3) Discount
4) Franchisee
5) Item Groups
6) Items
7) Payment Modes
8) Purchase Order Details
9) Purchase Orders
10) Sales Detail
11) Sales Return Charges
12) Sales Return Details
13) Sales
14) Sales Charges
15) Scheme ,16) Users
Table 1: Accounts
Primary Key AccountKey Numeric 10 No

FranchiseKey Numeric 18 Yes

AccountCode Nvarchar 15 Yes

AccountName Nvarchar 50 No
Business Nvarchar 50 Yes
ContactPerson Nvarchar 50 Yes
OfficeAddress Nvarchar 30 No
OfficeCity Nvarchar 30 Yes
OfficeState Nvarchar 30 Yes
OfficeCountry Nvarchar 30 Yes
ResidentialAddress Nvarchar 50 Yes
ResidentialCity Nvarchar 30 Yes
ResidentialState Nvarchar 30 Yes
ResidentialCountry Nvarchar 30 Yes
Telephone Nvarchar 20 No
Fax Nvarchar 20 Yes
Email Nvarchar 50 No
RefferedBy Nvarchar 50 Yes
MaritalStatus Bit Yes
BirthDateCustomer Nvarchar 20 Yes
BirthDateCustomerSpouse Nvarchar 20 Yes
KidStatus Bit Yes
BirthDateKid1 Nvarchar 20 Yes
BirthDateKid2 Nvarchar 20 Yes
UsagePerMonth Numeric 10 Yes
PreferredBrand Nvarchar 50 Yes
Membership Bit Yes
MembershipCode Nvarchar 15 Yes
MembershipType Nvarchar 30 Yes
IssueDate Nvarchar 20 Yes
ExpiryDate Nvarchar 20 Yes
Terms Nvarchar 1000 Yes

Table2: Franchisee
Key Constraints Column Name Data Type Length Allow Nulls
Primary Key FranchiseKey Numeric 10 No
FranchiseCode Nvarchar 10 No
FranchiseType Nvarchar 50 Yes
FranchiseName Nvarchar 50 No
FranchiseManager Nvarchar 50 Yes
ContactPerson Nvarchar 50 Yes
Address Nvarchar 50 Yes
City Nvarchar 30 Yes
State Nvarchar 30 Yes
Country Nvarchar 30 Yes
Telephone Nvarchar 20 Yes
Email Nvarchar 50 Yes
BankAccountNumber Nvarchar 20 Yes
BankCity Nvarchar 30 Yes
BankName Nvarchar 50 Yes
VATNumber Nvarchar 20 Yes
CSTNumber Nvarchar 20 Yes
ServiceTaxNumber Nvarchar 20 Yes
DateOfBirth Datetime Yes
MaritalStatus Bit Yes
AnniveryDate Datetime Yes
AreaState Nvarchar 30 Yes
AreaCity Nvarchar 30 Yes
AreaCityAbreviation Nvarchar 10 Yes
FromDate Datetime Yes
ToDate Datetime Yes
Terms Nvarchar 1000 Yes
Target Numeric 10 Yes
CommissionOnSales Numeric 4,2 Yes

Table3: Item Groups

Key Constraints Column Name Data Type Length Allow Nulls
Primary key ItemGroupKey Numeric 10 No
ItemGroupName Nvarchar 50 yes

Table4:Items

Primary key ItemKey Numeric 10 No

ItemCode Nvarchar 15 No
ItemName Nvarchar 50 No
ItemRate Numeric 10,2 Yes
ItemUnit Nvarchar 50 Yes
ItemGroupKey Numeric 10 Yes
OpeningStock Numeric 10,2 Yes
ItemType Nvarchar 50 Yes

Table5: Payment Modes

Primary key PaymentModeKey Numeric 10 No

PaymentModeName Nvarchar 50 Yes
PaymentModeName Nvarchar 50 Yes

Table6: Charges

Primary Key ChargeKey Numeric 10 No

ChargeName Nvarcha 30 No
ChargeRate Numeric 10,2 Yes
ChargeMode Nvarchar 30 Yes
ChargeType Nvarchar 30 No

Table7: Purchase Orders

Key Constraints Column Name Data Type Length Allow Nulls
Primary key TransactionKey Numeric 10 No
FranchiseKey Numeric 10 Yes
TransactionDate Datetime Yes
TransactionNumber Nvarchar 20 Yes
AccountKey Numeric 10 Yes
GrossAmount Numeric 10,2 Yes
Additions Numeric 10,2 Yes
Reductions Numeric 10,2 Yes
NetAmount Numeric 10,2 Yes
PaymentModeKey Numeric 10 Yes
PaymentDescription Nvarchar 200 Yes
DueDate Datetime Yes
ReferenceTransactionKey Numeric 10 Yes

Table8: Purchase Order Charges

Primary key TransactionChargeKey Numeric 10 No

TransactionKey Numeric 10 Yes
ChargeKey Numeric 10 Yes
ChargeableAmount Numeric 10,2 Yes
ChargePercentage Numeric 4,2 Yes
ChargeAmount Numeric 10,2 Yes

Table9: Purchase Order Details

Primary key TransactionDetailKey Numeric 10 No

TransactionKey Numeric 10 Yes
Sno Numeric 15 Yes
ItemKey Numeric 10 Yes
Quantity Numeric 10,2 Yes
Rate Numeric 10,2 Yes
Amount Numeric 10,2 Yes

Table10: Sales

Primary key TransactionKey Numeric 10 No

FranchiseKey Numeric 10 Yes
 TransactionDate Datetime Yes
TransactionNumber Nvarchar 20 Yes
AccountKey Numeric 10 Yes
GrossAmount Numeric 10,2 Yes
Additions Numeric 10,2 Yes
Reductions Numeric 10,2 Yes
NetAmount Numeric 10,2 Yes
PaymentModeKey Numeric 10 Yes
PaymentDescription Nvarchar 200 Yes
DueDate Datetime Yes
ReferenceTransactionKey Numeric 10 Yes
SchemeKey Numeric 10 No

Table11: Sales Charges

Primary key TransactionChargeKey Numeric 10 No

TransactionKey Numeric 10 Yes
ChargeKey Numeric 10 Yes
ChargeableAmount Numeric 10,2 Yes
ChargePercentage Numeric 4,2 Yes
ChargeAmount Numeric 10,2 Yes

Table12: Sales Details

Primary key TransactionDetailKey Numeric 10 No

TransactionKey Numeric 10 Yes
Sno Numeric 15 Yes
ItemKey Numeric 10 Yes
Quantity Numeric 10,2 Yes
Rate Numeric 10,2 Yes
Amount Numeric 10,2 Yes

Table13: Sales Returns

Primary key TransactionKey Numeric 10 No

FranchiseKey Numeric 10 Yes
TransactionDate Datetime Yes
 TransactionNumber Nvarchar 20 Yes
AccountKey Numeric 10 Yes
GrossAmount Numeric 10,2 Yes
Additions Numeric 10,2 Yes
Reductions Numeric 10,2 Yes
NetAmount Numeric 10,2 Yes
PaymentModeKey Numeric 10 Yes
PaymentDescription Nvarchar 200 Yes
DueDate Datetime Yes
ReferenceTransactionKey Numeric 10 Yes
SchemeKey Numeric 10 No

Table14: Schemes

Primary key SchemeKey Numeric 10 No

SchemeName Nvarchar 50 Yes
StartDate Datetime Yes
ExpiryDate Datetime Yes
SchemeAmount Numeric 10,2 Yes
SchemeType Nvarchar 30 Yes
DiscountPercentage Numeric 4,2 Yes
DiscountAmount Numeric 10,2 Yes
AuthorizedBy Nvarchar 50 Yes

Table15:Users
Primary key UserKey Numeric 10 No
FranchiseKey Numeric 10 Yes
FullName Nvarchar 50 Yes
UserName Nvarchar 10 Yes
Password Nvarchar 50 Yes
UserType Nvarchar 20 Yes

Part -4
4.VERIFICATION & VALIDATION

Validation refers to the process of using software in a live environment using real data. The

process of validation refers to a set of activities that ensure that the software that has been built

is matching to customer requirement. Validation is successful when software functions in a

manner that can be reasonably expected by the customer.

Suitable validation checks have been put wherever need was felt so as to avoid wrong data

input. Coding has been done so as to avoid wrong entries in the tables. For example Numeric

characters are not allowed in the Student’s name. Various modules have different process logic,

which involves sorting of data on different attributes and selection of required attribute

depending upon conditions have been decided. Most of these are SQL queries.

Two types of V & V

Verification: This checks if we are building the product right (i.e. does it meet the

requirements specification?)

Validation: This determines if we are building the right product? (i.e. does the requirement

specification describe what the customer wants?)

The various kinds of validations performed in our system are as follows:

1) Date Validation: The validation on date data type has been specified to be of the format

DD/MM/YY. Any other format is unacceptable.

2) Amount Validation: There is a validation on amount that is entered in rupees in the

following format. “00,000,000.00” E.g. 15, 65,789.00

3) From Date to Date: The “From Date” always has to be less than the “To Date”, e.g. From

1 Nov, 2003 to 4 Nov, 2003 is correct and it cannot be other way round.
4) Number Field Validation: The field specified with Number as then their data-type will

not accept Character or any other data type.

5) User Authentication: When a user logs on to the system to access data from the

database, the password needs to be checked for user authentication.

6) Password change Validation: Only authorized users are allowed to change the

password and the process requires asking the old password before changing it to the new one.

Part-5

Software Testing
5.TESTING

TESTING MESSUREMENT

Requirement Regarding testing:-

The requirement for the application testing is as follows:

• Test Guidelines
• Integration Strategy
• Special Considerations
• Test Documents

The development of software system involves a series of production activities where

opportunities for human fallibility are enormous. Errors may begin to occur at every inception of
the4 process where the objectives may be erroneously or imperfectly specified as well as later
design and development states. Because of human inability to perform and communicate with
perfection, software development is accompanied by quality assurance activity.

Software testing is a critical element of software quality assurance and represents the ultimate
reviews of specification design and coding.

The increasing visibility of software as a system element and attendant “cost” associated with a
software failure is motivating forces for well planned, thorough testing.

Testing Objectives:
A number of rules that can serve well as testing objectives:
Testing is a process of executing a program with the intent of finding an as yet undiscovered
error. A successful test is one that uncovers a yet undiscovered error. Our objective is to design
tests that systematically uncover different classes of errors and to do so with a minimum amount
of time and effort. Data collected as testing is conducted provide a good indication software
reliability and some indication of software quality as a whole.
Three level of Testing

Level 1 Testing (Alpha Testing)

At this level a test data is prepared for testing. Project leaders test the system on this test a data
keeping following point in consideration.
Proper Error handling.
Exit points in code Exception handling.
Input/Output format.
If the system is with testing phase at level 1, than it is passed on to level 2.

Level 2 Testing (Beta Testing)

Here the testing is time on the live database. If errors are not corrected it is send back to level 1
for modification otherwise it is passed at level 3.

Level 3
Here the error free and properly tested system is implemented.
Standard Software Development vs. Integrated Testing:

In normal software development mythologies, testing doesn’t begin until after code is
constructed. It a defect is found after coding, there is a good deal of scrap and rework to correct
the code, and possibly the design, test cases and requirements as well. Defects must be tested
out of the system, rather than being avoided in the first place. But in the other case as testing
begins at the requirements as well. Defects are avoided instead of being tested out of the code.
This is a less costly and timelier approach. User manuals and training materials can be
developed sooner. The entire software development lifecycle is compressed. Testing is
performed in parallel with development instead of the end.

Test case Design:

The design of tests can be as challenging as the initial design of the project itself. Testing design
tests that have the highest likelihood of finding the most errors with a minimum amount of time
and effort.

Any software product can be tested in any of the two ways

1. Knowing the specific function that a product has been designed to perform, test
can be conducted that demonstrate each function is fully operational.
2. Knowing the internal working of a product. Test can be conducted to ensure that
the internal operation of product performs according to specification and all
internal components have been adequately exercised.

The first step is called the white box testing and the second black box testing.
Test cases are design to answer the following questions:
• How is functional validity tested?
• What classes of input will make good test cases?
• Is the system particularly sensitive to certain input values?
• How are the boundaries of a data class isolated?
• What data rates and data volumes can the system tolerate?
• What effect will specific combinations of data have on system operation?

Testing Strategies:

A software testing strategy provides a road map for the software developer. The quality
assurance organization and the customer a road map that describe the steps to be conducted
as part of testing. Any testing strategy must incorporate test planning. Test case design. Test
resultant data collection and evaluation.

A strategic approach to software testing:

A number of software testing strategies have been proposed in the literature all provides the
software developer with a template for testing and all have the following generic characteristics.
 • Testing begins at the module level and works “outward” toward the integration of the
entire computer based system.
• Different testing technique is appropriate at different point in time.
• Testing conducted by the developer of the software and (for large project) an independent
test group.
• Testing and debugging are different activities but debugging must be accommodated in
any test strategy.

A software testing strategy:

Unit Testing:
Unit testing focus verification effort on the smallest unit of software designs the module. The unit
test is always White-Box – oriented and the step can be conducted in parallel for
Multiple modules. In our modules, different testing at module level is shown above in test
reports.

Integration Testing:
Integration testing address the issues associated with the dual problem of the verification and
program construction. Black box test case design techniques are the most prevalent during
integration, although a limited amount of white box testing may be used to ensure coverage of
major control paths.

Validation Testing:
Validation testing provides the final assurance that software meets all functional behavioral and
performance requirement Black box testing techniques are user exclusively during validation
testing is performed in terms of efficiency of coding and in terms of checking weather particular
application is meeting its requirement.
System testing system testing tests the flow of data through the entire system. Data flows from
the table were checked. This also includes the preparation of test, checking the entire system
with this data to see if all the requirements are met and the system performs as specified by the
requirements.
The system being developed will follow bottom up approach of testing where each functional unit
will be independently tested and then integrating testing of the module or sub module will be
done.

Testing Procedure:
Testing plays a critical role in quality assurance of the software testing is a dynamic method for
verification and validation. With the help of testing we observe the failure of the system in terms
of logical and runtime errors. The testing process can deduce the presence of fault in the
system; however activities have to be performed to identify the faults.

As the foal of testing is to detect any errors in the programs, different flavor of testing are often
used. Unit testing are used to test a module or a small collection of modules and the focus is on
detecting coding errors in modules. During integration testing modules re combined into sub
system, which are ten tested. The foal here is to test the system design. In system testing and
acceptance testing, the entire system is tested the foal here is to test the fulfillment of the
requirement. Structural testing can be used for unit testing while at higher level mostly functional
testing is used.

The primary objective for test case design is to derive a set of test that has the highest likelihood
for uncovering errors in the software. To accomplish this objective, two different categories of
test case design techniques are used White box testing and black box testing.
White box test focuses on the program control structure. Test cases are derived to ensure that
all statement in the program has been executed at least once during testing and that all logical
conditions have been exercised Basis path testing. A white box technique makes use of
program graphs (or graph matrices) to derive the set of linearly independent test that will ensure
coverage. Condition and data flow testing further exercise loops of varying degrees of
complexity.

Black box tests are designed to uncover errors functional requirements without regard to the
internal workings of a program. Black box testing techniques focus on the output domain of a
program in a manner that provides thorough test coverage. The black box test are used to
demonstrate that software functions are operational, that input is properly accepted and output is
properly produced, and that the integrity of external information data file) is maintained.
A black box test examines some fundamental aspect of a system with little or no regard of the
integral logical structure of the software.
Graph based testing methods explore the relationships between and behavior of program likely
to exercise specific software function. Boundary value analysis probes the program’s ability to
handle data at the limits of acceptability.

TESTING PRINCIPLES

Before applying methods to design effective test cases, we must understand the basic principles
that hide software testing.

• Al tests should be traceable to customer requirements, as we have seen the objective of

the software testing is to uncover errors. It follows that the most sever defects (from the
customer’s point of view) are those that cause the program to fail to meet its
requirements.
• The pair to principle applies to software testing. Stated simply, the pair to principle implies
that 80 percent of all errors uncovered during testing will likely be traceable to 20 percent
of all program modules and to thoroughly test them.
• Testing should begin “in small” and progress toward testing “in large”. The first test
planned and executed generally focus in an attempt to find errors in integrated clusters of
modules and ultimately in the entire system.
• Exhaustive testing is not possible. The number of path permutations for even a
moderately sized program is exceptionally large. For this reason, it is impossible to
execute every combination of paths during testing. It is impossible; however to adequately
cover program logic and to ensure that all conditions in the procedural design have been
exercised.
• To be most effective, testing should be conducted by an independent third party by “most
effective”; we mean testing that has the highest probability of finding errors (the primary
objective of testing) for reasons; the software engineer who created the system is not the
best person to conduct all tests for the software.
Experienced software developers often say “testing never ends” it just gets transferred from you
(the software engineer) to your customer. Every time your customer uses the program, a test is
being conducted. By applying test case design, the software engineer can achieve more
complete testing and thereby uncover and correct the highest number of errors before the
“customer tests” begin.

System Testing
Once satisfied with all the modules work well in themselves and there are no problems. Then go
in to see how the system will work or perform once all the modules are put together. The main
types of system testing are:

• Peak load Testing:

It determines whether the system will handle the volume of activities that occur when the
system is at the peak of its processing demand.
• Storage Testing:
It determines the capacity of the system uses to process transaction generate report.
• Recovery Testing:
It determines the ability of the system to recover data or restart after failure
• Procedure Testing:
It determines the clarity of the documentation on operation and use of system.
• Human Factor Testing:
This test determines how the user would use the system when processing data and
preparing reports. As this system provides readability and user friendliness, the screen is
never left blank.

MAINTENANCE:
The systems operation and support phase begins when a system become operational and
continues until the system reaches the end of its useful life. Throughout the development
process, the objective has been to create an information system that is efficient, easy to use,
and affordable. After delivering the system, the analyst has two other important tasks. He or she
must support users and provide necessary maintenance to keep the system operating properly.

MAINTENANCE TASKS

Corrective Maintenance:
• Diagnose and fix logic errors
• Replace defective network cabling.
• Restore proper configuration settings.
• Debug program code.
• Update drivers
• Install software patch.

Adaptive Maintenance:
• Add online capability
• Create new reports.
• Add new data entry field to input screen.
• Install links to web site
• Create employee portal

Perfective Maintenance
• Install additional memory
• Write macros to handle repetitive tasks
• Compress system files
• Optimize user desktop settings
• Develop library for code reuse.
• Install more powerful network server.

Primitive Maintenance
 • Install new antivirus software
• Develop standard backup schedule.
• Implement regular defragmentation process.
• Analyze problem report for patterns.
• Tighten all cable connection.

SECURITY
Maintaining system security involves two main tasks. First there must be provisions to assign
and monitor user ids, Passwords, and access levels. Second the system security tools must
handle virus protection and detect any unauthorized access, including attempts by intruders to
enter the system.

Many security management software products are available, including he SAFE suite products.
Notice that the Internet security systems web site mentions three main areas security
assessment, intrusion detection, and security management applications.

In addition to built in controls and security software, company can take other steps to enhance
system security, such as user training safeguards for the physical security of hardware and
software, security audits, and strong security policies that is well understood and reinforced
throughout the organization.
 Part-6
IMPLEMENTATION

6.1 Input/Output Form Design

Login Page:
Administrator Home Page :
Franchisee Home Page:
Franchisee: Only Administrator Can Add Franchisee
Accounts: Only Franchisee Can Add Customers
Items: Available items
Sales: Franchisee made Sales to the Customers
Schemes: Administrator can offer various Schemes as per various occasions
Change Credentials
Sales Return: Customer can return Sales to Franchisee
 Part-7
Bibliography

LINKS:-

www.123aspx.com/
www.microsoft.com/.net/
www.programmerheaven.com/
www.411asp.net/home/sites
www.devasp.net/
www.hotscripts.com/
www.myasp-net.com/
www.dallasasp.net/

BOOKS:-

• ASP.Net 2.0 Website Programming Problem-Design-Solution.

• ASP.Net 3.5 Unleashed.
• Programming Microsoft ASP.Net 2.0 Core Reference.
• Essential ASP.Net 2.0.
• Microsoft ASP.Net 2.0 Step By Step.
• Mastering Visual C#.Net by Jason Price.
• Essential ADO.Net by Bob Beauchemin.
• ADO.Net Examples For C# Programmers by William R. Vaughn.
• ADO.NET Cook BOOK by Bill Hamilton.
• C#.Net 2.0 Unleashed.