SDFGH Pages Deleted

Download as pdf or txt
Download as pdf or txt
You are on page 1of 38

Madan Mohan Malviyia University of Technlogy

Gorakhpur,Uttar Pradesh-273010

A Report on
“Inventory Management System”
SUBMITTED IN
PARTIAL FULFILMENT FOR AWARD OF DEGREE OF BACHELOR OF
TECHNOLOGY
IN
COMPUTER SCIENCE AND ENGINEERING
By
Team
(Name) (Roll-No.)
Anjali Mishra 2021021017
Anshu 2021021018
Arun Kumar Yadav 2021021019
Arun Yadav 2021021020
Aryan Anand 2021021021

Submitted in
Department of Computer Science and Engineering
Under the Guidance of

Prof. Uday Shankar


Head , CSE Department
MADAN MOHAN MALAVIYA UNIVERSITY OF TECHNOLOGY
GORAKHPUR-273010
CONTENT

1 Introduction
1.1 Introduction to IMS
1.2 Literature Review
1.3 Problem Statement
1.4 Objective Of the Project
1.5 Features of the project
1.6 Scope of the Application
2 System Analysis
2.1 The Proposed System
2.2 The Theoretical Background
2.3 Description of System
2.4 Limitations of Existing Project
2.5 Advantages of Proposed System
2.6 Feasibility Study
2.7 Background Knowledge
2.8 Software and hardware requirements
3 System design
3.1 Process flow diagram
3.2 Use case diagram
3.3 ER diagram
3.4 Components of ER diagram
3.5 Diagram Relationship
3.6 Activity Diagram
3.7 Inventory Activity
3.8 Class diagram
3.9 Sequence diagram
3.10 UML Diagram
3.11 DFD Diagram
4 Analysis and Design
4.1 Background research
4.2 Requirement Analysis
4.3 Ims Requirement
4.4 User requirements
Chapter:1

INTRODUCTION
1.1 Introduction to Inventory Management System
The project Inventory Management System is a complete web based application An inventory
management system is the combination of technology (hardware and software) and processes and
procedures that oversee the monitoring and maintenance of stocked products, whether those
products are company assets, raw materials and supplies, or finished products ready to be sent to
vendors or end consumers. Inventory Management System plays an important role because it
reduces the stress, monitoring of products, making balance sheets and many more which was done
manually. Simply Inventory Management System overtook the manual things and also it optimizes
the cost and time constraint. Inventory Management Software is an open source project developed
by procedural php, MySQL, bootstrap, and jquery. This application is based on web application and
develop with procedural php, MySQL database, jquery, data tables plugins, and bootstrap. This
application provides the users to manage brands, category, product, orders, and report. This system
provides best inventory management software features. This system can be also used for small
business.

1.2. Literature Review

Products are considered as the business resources for the organization. This includes managing the
product with appropriate way to review any time as per the requirement. Therefore it is important to
have a computer based IMS which has the ability to generate reports, maintain the balance of
The stock, details about the purchase and sales in the organization. Before developing this application
we came up with Inventory Management System existing in the market, which helps to give the
knowledge for the development of our project. After analyzing the other inventory management
system we decided to include some of common and key features that should be included in every
inventory management system. So we decided to include those things that help the small organization
in a way or other.
1.3. Problem Statement

To make the system easily managed and can be secured.



To cover all the areas of IMS like purchase details, sales details and stock management.
1.4. Objective of the Project
 Primary objective
To fulfill the requirement for achieving the Bachelor‘s degree of Computer Science .

 Secondary objective

To develop an application that deals with the day to day requirement of any production
organization
To develop the easy management of the inventory
To handle the inventory details like sales details, purchase details and balance stock details.
To provide competitive advantage to the organization.
To provide details information about the stock balance.
To make the stock manageable and simplify the use of inventory in the organization.
1.5 Features of Project
This application is used to show the stock remaining and details about the sales and purchase. It gives
the details about the stock on daily based and weekly based. The details components are described
below:
Create Stock
We can create stock if we need to extend or we have more than one stock. We can create the stock
along with the date.
Sales details
It show the details about the sales and the remaining stock of sales. It also show the details about the
sales in return.
Purchase details
It shows the details about the purchase made by the organization along with the price and dates.
Generate Report details
It generate the purchase report of any months. And the report show in pdf format.

1.6. Scope of the Application


Inventory Management System (IMS) is targeted to the small or medium organization which doesn‘t
have many warehouses i.e. only to those organization that has single power of authority. Some of the
scope are:

 Determination of economic order quantity:


 Effectiveness towards running of store:
Chapter 2
SYSTEM ANALYSIS
2.1 The Proposed System:-


The proposed system is computerized and has been developed using advance language therefore it


gives more facilities than present system.

By user friendly we mean to make records available to the user at just the hit of a keystroke.


To maintain the list of Student records, to maintain records of Customers and Event, to
maintain records of Customer, to maintain the transaction details. To add/update/search them
from the database-all these features have been considered for the management of the system.


Besides maintaining the data in the database the system also has the provision for printing
various reports.


The system helps reduce the paper work and provide an efficient environment that is user friendly
to work in.

2.2 THEORETICAL BACKGROUND

Inventory Management systems (IMS) :- are part of the so-called inventory System Process, which
are applications supporting the direct contact with the volunteer and Customers.The aim of the project titled
INVENTORY MANAGEMENT is to development enterprise software that optimizes the performance
of an event management company. This system helps the managers at different departments to
coordinate their work and thereby save their valuable time and finance.

2.3Description of System

Existing System:--

In present non-computerized system all jobs are performed manually. All records of Customer,
and Customers details are written and stored in paper format in a file
2.4 Limitation of Existing System:-


  in files, so there will be lot of redundancy
In present system each and every record is maintained
in maintaining ‗Customer and Volunteer records.
 
 Also there is no security as all records are maintained in files.

 Modification of one record causes changes to other records related to that record, so work becomes
very critical, there are chances of data loss
 
 Storage of information is costly.

 Require knowledge about the system

 Searching any old record requires more time due to critical system of register

 Present system is very time consuming.

 A lot of paperwork is maintain

 Difficult in maintaining records

 It is difficult to keep through registers for many years or months safely.

There are many chances of mistakes as all the data is handled manually. 

2.5 Advantages of Proposed System

 
 The system is platform independent as it is developed in Asp.net with C# Web Application.
 
 It facilitates quick processing of data.
 
 Data present in database is highly secured.
 
 Searching of data is done very easily & more efficiently.
 
 Maintaining of data is very proper & accurate.
 
Information of any Item can be retrieved any time.
 
 It provides facility to modify records.
 
 It will save user time.
 
User can get several responses at a place.

2.6 Feasibility Study

Feasibility study tells whether the system would be beneficial for the organization with respect to the
requirements of the organization. Feasibility study is divided into the following phases:
I. Operational Feasibility:
Operational feasibility is dependent on the human resources available for the project and involves
projecting whether the system will operate and used once it is install. It is mainly concerned with the
availability of human resources for the project. In the staff, Student and Teachers, different departments
and members are assigned according to their jobs.

II. Technological feasibility:


Technical feasibility is a measurement of the practicality of a specific technical solution and the
availability of technical resources and expertise. In the School Management System we use two specific
languages i.e. HTML,CSS and JavaScript as front end and PHP Mysqlas back end. To use this
languages we use respected software .

III.Economical and financial feasibility:


Economical feasibility is the measurement of the cost effectiveness of the project proposed System
cost are practically impossible to estimate at that stage because the end user requirement and
alternative technical solutions have not identified.

2.7 BACKGROUND KNOWLEDGE

I. Architectural Review
This Web based application is based on 3-tier architecture. The3-tier includes the three hierarchy of the
flow of programming logic from user interface to database and again database to user interface with
the desired information requested by the clients. In between there involves the logic layer for
effectively and correctly manipulating the request. The 3-tier includes the following:

II Client tier
The visual part is implemented using all kinds of swing components, which does not make database
calls. For example, inventory list will display when user click ―display‖ button if he or she wants to
know the list of stock remaining in the organization.

III Business tier


The middle tier, business logic, is called by the client to make database queries. It provides well as
core function of the system as connectivity to the data tier, which simplify tasks that
were done by the clients tier.

IV. Data tier


Data layer is also the class which gets the data from the business tier and sends it to the database or
gets the data from the database and sends it to business tier. This is the actual DBMS access layer or
object layer also called the business object. Mysql database connectivity is used to manage the
communication between the middle tier and the backend database by issuing Complex database
queries.

Tier Architecture diagram

V. Database Theory
A database is a collection of information that is organizes so that it can easily be accessed, managed
and updated. In one view, database can be classified according to types of content: bibliography, full-
text, numeric, and image.
VI. Relational Database
IMS has the relational database model. A relational database is a digital database whose organization is
based on the relational model of data. This model organizes data into one or more tables of rows and
columns. The standard user and application program interface to a relational database is the structured
query language (SQL). SQL statement are used both for interactive queries for Information from
relational database and for gathering data for reports.

VII.PrimaryKey

The primary key of a relational table uniquely identifies each record in the table A primary key‘s main
features are:
 It must contain a unique value for each row of data.
 It cannot contain null value.

VIII. Foreign Key


A foreign key is a column or group of column in a relational database table that provides a
link between data in two tables. In foreign key reference, a link is created between two tables when the
column or columns that hold the primary key value for one table are referenced by the column
or column in another table thereby establishing a link between them.

IX. Structured Query Language (SQL)


SQL has three major Components:
 Data Manipulation Language (DML)
 Data Definition Language (DDL)
 Data Control Language (DCL)

X. ACID Property
Every database transaction obeys the following rules:

1. Atomicity
2. Consistency
3. Isolation
4. Durability
. 2.8 SOFTWARE AND HARDWARE REQUIREMENTS

Software Requirements :-

 
Front End : HTML ,CSS ,JavaScript
 
Operating System : Windows 11
 
For Documentation : Microsoft Office 2007

Hardware Requirements :-


Processor :- Intel core i5
 RAM :- 1GB onwards
 Free Hard Disk Space :- 2 GB or more
Chapter 3

SYSTEM DESIGN

3.1 Process Flow Diagram


Process Flow Diagram or Flowchart is a diagram which uses geometric symbols and arrows
to define the relationships. It is a diagrammatic representation of the algorithm. The Process
flow Diagram of our application is shown below:

3.2Use Case Diagram


A use case diagram at its simplest is a representation of a user's interaction with the system and
depicting the specifications of a use case. A use case diagram can portray the different types of
users of a system and the various ways that they interact with the system.
Use cases should start off simple and at the highest view possible. Only then can they be
refined and detailed further.
Use case diagrams are based upon functionality and thus should focus on the "what" and not the
"how".

So in brief, the purposes of use case diagrams can be as follows


 Used to gather requirements of a system.
 Used to get an outside view of a system.
 Identify external and internal factors influencing the system.
 Show the interacting among the requirements are actors.

3.3 ENTITY RELATION DIAGRAM

Entity relationship diagrams are useful for illustrating the relationships between different
elements in a database. With the help of entity relationship diagrams, the structure of a database
is made clear, and it is possible to see exactly how the different elements are interlinked. You
can use entity relationship diagrams to plan a database you are going to build, or to maintain an
existing database structure.

An ER model is an abstract way of describing a database. In the case of a relational database,


which stores data in tables, some of the data in these tables point to data in other tables - for
instance, your entry in the database could point to several entries for each of the phone numbers
that are yours. The ER model would say that you are an entity, and each phone number is an
entity, and the relationship between you and the phone numbers is 'has a phone number'.
Diagrams created to design these entities and relationships are called entity–relationship
diagrams or ER diagrams.

ER Diagram is a visual representation of data that describes how data is related to each other. In
ER Model, we disintegrate data into entities, attributes and setup relationships between entities,
all this can be represented visually using the ER diagram.

For example, in the below diagram, anyone can see and understand what the
diagram wants to convey: Developer develops a website, whereas a Visitor visits a
website.
3.4 Components of ER Diagram
Entity, Attributes, Relationships etc. form the components of ER Diagram and there are defined symbols
and shapes to represent each one of them.

Let's see how we can represent these in our ER Diagram.

Entity
Simple rectangular box represents an Entity.

Relationships between Entities - Weak and Strong


Rhombus is used to setup relationships between two or more entities.

Attributes for any Entity


Ellipse is used to represent attributes of any entity. It is connected to the entity.

Weak Entity
A weak Entity is represented using double rectangular boxes. It is generally connected to another entity.

Key Attribute for any Entity


To represent a Key attribute, the attribute name inside the Ellipse is underlined.
Derived Attribute for any Entity
Derived attributes are those which are derived based on other attributes, for example, age can be
derived from date of birth.
To represent a derived attribute, another dotted ellipse is created inside the main ellipse.

Multivalued Attribute for any Entity


Double Ellipse, one inside another, represents the attribute which can have multiple values.

Composite Attribute for any Entity


A composite attribute is the attribute, which also has attributes.

3.5 Diagram: Relationship


A Relationship describes relation between entities. Relationship is represented using diamonds or rhombus.
There are three types of relationship that exist between Entities.

1. Binary Relationship
2. Recursive Relationship
3. Ternary Relationship

3.6 Activity Diagram


Activity diagrams are graphical representations of workflows of stepwise activities and actions with
support for choice, iteration and concurrency. In the Unified Modeling Language, activity diagrams are
intended to model both computational and organizational processes
Basic Activity Diagram Notations and
Symbols Initial State or Start Point
A small filled circle followed by an arrow represents the initial action state or the start point for any activity
diagram. For activity diagram using swim lanes, make sure the start point is placed in the top left corner of
the first column.
Activity or Action State
An action state represents the non-interruptible action of objects. You can draw an action state in
SmartDraw using a rectangle with rounded corners.

Action Flow
Action flows, also called edges and paths, illustrate the transitions from one action state to another. They
are usually drawn with an arrowed line.

Object Flow
Object flow refers to the creation and modification of objects by activities. An object flow arrow from
an action to an object means that the action creates or influences the object. An object flow arrow from
an object to an action indicates that the action state uses the object.

Decisions and Branching


A diamond represents a decision with alternate paths. When an activity requires a decision prior to moving
on to the next activity, add a diamond between the two activities. The outgoing alternates should be
labeled with a condition or guard expression. You can also label one of the paths "else."
Guards
In UML, guards are a statement written next to a decision diamond that must be true before moving next to
the next activity. These are not essential, but are useful when a specific answer, such as "Yes, three labels
are printed," is needed before moving forward.

Synchronization
A fork node is used to split a single incoming flow into multiple concurrent flows. It is represented as a
straight, slightly thicker line in an activity diagram.
A join node joins multiple concurrent flows back into a single outgoing flow.
A fork and join mode used together are often referred to as synchronization.
Time Event
This refers to an event that stops the flow for a time; an hourglass depicts it.

Merge Event
A merge event brings together multiple flows that are not concurrent.

Sent and Received Signals


Signals represent how activities can be modified from outside the system. They usually appear in pairs of
sent and received signals, because the state can't change until a response is received, much like synchronous
messages in a sequence diagram. For example, an authorization of payment is needed before an order can be
completed.

Interrupting Edge
An event, such as a cancellation, that interrupts the flow denoted with a lightning bolt.
Final State or End Point
An arrow pointing to a filled circle nested inside another circle represents the final action state.

3.7 Inventory Activity


4

Fig.Inventory Activity
3.8 CLASS DIAGRAM

What is a Class Diagram?


A class diagram models the static structure of a system. It shows relationships between classes,
objects, attributes, and operations.

Basic Class Diagram Symbols and Notations Classes


Classes represent an abstraction of entities with common characteristics. Associations represent
the relationships between classes.

Active Classes
Active classes initiate and control the flow of activity, while passive classes store data and serve
other classes. Illustrate active classes with a thicker border.

Visibility
Use visibility markers to signify who can access the information contained within a class. Private visibility,
denoted with a - sign, hides information from anything outside the class partition. Public visibility, denoted
with a + sign, allows all other classes to view the marked information. Protected visibility, denoted with a #
sign, allows child classes to access information they inherited from a parent class.

Associations
Associations represent static relationships between classes. Place association names above, on, or below the
association line. Use a filled arrow to indicate the direction of the relationship. Place roles near the end of
an association. Roles represent the way the two classes see each other.
Multiplicity (Cardinality)
Place multiplicity notations near the ends of an association. These symbols indicate the number of instances
of one class linked to one instance of the other class. For example, one company will have one or more
employees, but each employee works for just one company

.
Composition and Aggregation
Composition is a special type of aggregation that denotes a strong ownership between Class A, the
whole, and Class B, its part.

Illustrate composition with a filled diamond. Use a hollow diamond to represent a simple aggregation
relationship, in which the "whole" class plays a more important role than the "part" class, but the two
classes are not dependent on each other.

The diamond ends in both composition and aggregation relationships point toward the "whole" class (i.e.,
the aggregation).
Class Diagram

Fig .Class Diagram


Generalization
Generalization is another name for inheritance or an "is a" relationship. It refers to a relationship between
two classes where one class is a specialized version of another. For example, Honda is a type of car. So the
class Honda would have a generalization relationship with the class car.
3.9 SEQUENCE DIAGRAM

A sequence diagram is an interaction diagram that shows how processes operate with one another and
in what order. It is a construct of a Message Sequence Chart.

A sequence diagram shows object interactions arranged in time sequence. It depicts the objects and
classes involved in the scenario and the sequence of messages exchanged between the objects needed to
carry out the functionality of the scenario.

Sequence diagrams are typically associated with use case realizations in the Logical View of the system
under development. Sequence diagrams are sometimes called inventory diagram.

A sequence diagram shows, as parallel vertical lines (lifelines), different processes or objects that live
simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which
they occur.
Visual
Notation Description
Representation

Actor

 A type of role played by an entity that interacts with the subject (e.g., by
exchanging signals and data)

 external to the subject (i.e., in the sense that an instance of an actor
is not a part of the instance of its corresponding subject).

 represent roles played by human users, external hardware, or
other subjects.
Note that:

 An actor does not necessarily represent a specific physical entity


but merely a particular role of some entity

 A person may play the role of several different actors and, conversely, a
given actor may be played by multiple different person.

Lifeline

 A lifeline represents an individual participant in the Interaction.


Activations

 A thin rectangle on a lifeline) represents the period during which


an element is performing an operation.

 The top and the bottom of the of the rectangle are aligned with
the initiation and the completion time respectively

Call Message

 A message defines a particular communication between Lifelines of


an Interaction.

 Call message is a kind of message that represents an invocation
of operation of target lifeline.

Return Message

 A message defines a particular communication between Lifelines of


an Interaction.

 Return message is a kind of message that represents the pass of
information back to the caller of a corresponded former message.
Self Message

 A message defines a particular communication between Lifelines of


an Interaction.

 Self message is a kind of message that represents the invocation
of message of the same lifeline.

Recursive Message

 A message defines a particular communication between Lifelines of


an Interaction.

 Recursive message is a kind of message that represents the invocation
of message of the same lifeline. It's target points to an activation on top
of the activation where the message was invoked from.

Create Message

 A message defines a particular communication between Lifelines of


an Interaction.

 Create message is a kind of message that represents the instantiation of
(target) lifeline.
Destroy Message

 A message defines a particular communication


between Lifelines of an Interaction.

 Destroy message is a kind of message that represents
the request of destroying the lifecycle of target lifeline.

Duration Message

 A message defines a particular communication


between Lifelines of an Interaction.

 Duration message shows the distance between two
time instants for a message invocation.

Note
A note (comment) gives the ability to attach various remarks to elements.
modeler.
3.10 UML DIAGRAM

The Unified Modeling Language (UML) is a general-purpose,


developmental, modeling language in the field of software engineering, that is
[1]
intended to provide a standard way to visualize the design of a system.
The creation of UML was originally motivated by the desire to standardize the
disparate notational systems and approaches to software design. It was
developed by Grady Booch, Ivar Jacobson and James Rumbaugh
at Rational Software in 1994–1995, with further development led by them
through 1996.
In 1997 UML was adopted as a standard by the Object Management
Group (OMG), and has been managed by this organization ever since. In
2005 UML was also published by the International Organization for
Standardization(ISO) as an approved ISO standard. Since then the standard
has been periodically revised to cover the latest revision of UML.

[4]
UML offers a way to visualize a system's architectural blueprints in a diagram, including elements such as:

 any activities (jobs);



 individual components of the system;


 and how they can interact with other software components.

 how the system will run;


 how entities interact with others (components and interfaces);

 external user interface.
Structuring Use Cases
UML defines three stereotypes of association between Use Cases:

<<include>> Use Case


The time to use the <<include>> relationship is after you have completed the first cut description of all
your main Use Cases. You can now look at the Use Cases and identify common sequences of user-system
interaction.

<<extend>> Use Case


An extending use case is, effectively, an alternate course of the base use case. The <<extend>> use case
accomplishes this by conceptually inserting additional action sequences into the base use-case sequence.

Abstract and generalized Use Case


The general use case is abstract. It can not be instantiated, as it contains incomplete information. The title of
an abstract use case is shown in italics.
PROGRAM (DATA) FLOW CHART

A data flow diagram (DFD) is a graphical representation of the "flow" of data through an information
system, modeling its process aspects. Often they are a preliminary step used to create an overview of
the system which can later be elaborated. DFDs can also be used for the visualization of data processing
(structured design).

A DFD shows what kinds of information will be input to and output from the system, where the data will
come from and go to, and where the data will be stored. It does not show information about the timing of
processes, or information about whether processes will operate in sequence or in parallel (which is shown
on a flowchart.

What is a data flow diagram (DFD)?


Data Flow Diagrams (DFD)A data flow diagram can also be used for the visualization of Data Processing. It
is common practice for a designer to draw a context-level DFD first which shows the interaction between the
system and outside entities. This context-level DFD is then "exploded" to show more detail of the system
being modeled.

A DFD represents flow of data through a system. Data flow diagrams are commonly used during problem
analysis. It views a system as a function that transforms the input into desired output. A DFD shows
movement of data through the different transformations or processes in the system.

Dataflow diagrams can be used to provide the end user with a physical idea of where the data they input
ultimately has an effect upon the structure of the whole system from order to dispatch to restock how any
system is developed can be determined through a dataflow diagram. The appropriate register saved in
database and maintained by appropriate authorities.

We usually begin with drawing a context diagram, a simple representation of the whole system. To
elaborate further from that, we drill down to a level 1 diagram with additional information about the major
functions of the system. This could continue to evolve to become a level 2 diagram when further analysis
is required. Progression to level 3, 4 and so on is possible but anything beyond level 3 is not very common.
Please bear in mind that the level of detail asked for depends on your process change plan.

Diagram Notation

Now we'd like to briefly introduce to you a few diagram notations which you'll see in the tutorial below.

1. External Entity

An external entity can represent a human, system or subsystem. It is where certain data comes from or goes
to. It is external to the system we study, in terms of the business process. For this reason, people use to
draw external entities on the edge of a diagram.

Process

A process is a business activity or function where the manipulation and transformation of data takes place.
A process can be decomposed to finer level of details, for representing how data is being processed within
the process.

3.Data Store
A data store represents the storage of persistent data required and/or produced by the process. Here are
some examples of data stores: membership forms, database table, etc.

4. Data Flow
A data flow represents the flow of information, with its direction represented by an arrow head that shows at
the end(s) of flow connector.

Data flow diagram symbol

Symbol Description

Data Flow – Data flow are pipelines through the packets of information
flow.

Process : A Process or task performed by the system.

Entity : Entity are object of the system. A source or destination data of a


system.

Data Store : A place where data to be stored.


Chapter 4
ANALYSIS AND DESIGN
4.1 Background Research
We started research by identifying the need of IMS in the organization. Initially we bounded our
research to find the general reasons that emerged the needs of Inventory Management System. We
used different techniques to collect the data that can clearly give us the overall image of the
application. The techniques we used were interview with the developers, visiting online websites that
are presented as the templates and visiting some organization to see their IMS application. Basically
the following factors forced us to develop IMS application:
 Cost and affordability

 Lack of stock management.

 Effective flow of stock transfer and management.

 Difficulty in monitoring the stock management.

4.2 Requirement Analysis


We collected a number of requirements for project from our primitive research, website visits, and
interview to the concerned personnel and their experiences regarding the concepts of its development.
We have even visited some organization in Kathmandu valley and analyze its importance and try to
develop the project by fulfilling all the weakness that were found in the application. We then decided
to build same type of application with different logic flow and new language which will be suitable for
the small organization.

4.3 IMS Requirement


The goal for the application is to manage the inventory management function of the organization. Once
it is automated all the functions can be effectively managed and the organization can achieve the
competitive advantage. Business requirement are discussed in the Scope section, with the following
additional details:
Helps to search the specific product and remaining stock.
Details information about the product sales and purchase.
4.4 Users Requirement
User requirement are categorized by the user type

Admin
 Able to create new go down along with date.
 Able to edit the entry as per entry.
 Able to add, modify and delete the stock entry.

Inventory management
 Able to check the stock available.
 Able to check the balance payment.
 Able to view the remaining sales stock

Feasibility Analysis
This software has been tested for various feasibility criterions from various point of views.

Economic Feasibility
The system is estimated to be economically affordable. The system is medium scale desktop
application and has affordable price. The benefits include increased efficiency, effectiveness, and the
better performance. Comparing the cost and benefits the system is found to be economically feasible.

Technical Feasibility
Development of the system requires tools like:
MySQL,
Which are easily available within the estimated cost and schedule.

Operational Feasibility
The system provides better solution to the libraries by adding the typical requirement and necessities.
The solution provided by this system will be acceptable to ultimate solution for the stock management.

Schedule Feasibility
The organized schedule for the development of the system is presented in the schedule sub-section.
The reasonable timeline reveals that the system development can be finished on desired time
framework.

You might also like