Development of Inventory and Point of Sale Management System For Caveman Int LTD

Development of Inventory and Point of Sale
Management System for Caveman Int Ltd.
Md.Tayeb Adnan
ID # 15203116
A practicum report submitted in partial fulfillment of the requirements

for the award of Bachelor of Computer Science and Engineering
Figure 17: Level 2 DFD of Process 6
Department of Computer Science and Engineering

College of Engineering and Technology
IUBAT– International University of Business Agriculture and Technology
Summer 2019
Development of Inventory and Point of Sale Management System for Caveman Int Ltd.
Md. Tayeb Adnan
A practicum report submitted in partial fulfillment of the requirements for the degree of
Bachelor of Computer Science and Engineering (BCSE)
The practicum has been examined and approved,
Prof Dr Md Abdul Haque

Chairperson and Professor
Dept. of Computer Science and Engineering
IUBAT – International University of Business
Agriculture and Technology
Prof Dr. Utpal Kanti Das

Figure Coordinator
17: Level 2 DFD of Process 6
and Professor
M.M Rakibul Hasan

Lecturer

College of Engineering and Technology
IUBAT – International University of Business Agriculture and Technology
Summer 2019
Abstract
Inventory and point of sale management System (IPMS) is the set of processes and technologies
that support the store, manage, and create report of sells, products information of any
organization as well as it allows to sell products. There may be many a types of information like
products information and their category, customer information, vendor’s information and their
contact details, Supplier Company and products etc. Inventory management is an inherently
collaborative process. As CIL now using a system for Inventory Management which is desktop
based, the project “Development of Inventory and point of sale Management System for
Caveman international Ltd (CIL)” is developed to make this process web based automatic system
from desktop based IPMS. The modules, developed for the online based IPMS, are product,
category, sales, requisition, and report. Using the product module admin can manage the product.
Before adding or updating any product, category name must be added to select the category of
product. As like product module, admin can manage the category information using category
module, supplier information using supplier module, order info using order module, customer
info using customer module, sold product info using sales module, requisition info using
requisition module, purchase info using purchase module, and generate report for particular date
range for sales.
HTML, CSS, JavaScript, Bootstrap are used for developing the front end and Asp.Net MVC 5,
Microsoft SQL server are used to implement the backend of this IPMS.
iii
Department Certification
On behalf of the Department of Computer Science and Engineering of International University of

Business Agriculture and Technology (IUBAT University) we, the undersigned, certify that this
practicum report ‘Development of Inventory and point of sale Management System for Caveman
International Ltd.’ for the award of Bachelor of Computer Science and Engineering (BCSE)
degree was duly presented by Md. Tayeb Adnan (ID No. 15203116) and accepted by the
department.
Supervisor:
M.M Rakibul Hasan

Lecturer
Figure
Dept. of Computer Science and 17: Level IUBAT
Engineering, 2 DFD of Process 6
University.
Prof. Dr. Utpal Kanti Das

Coordinator and Professor
Dept. of Computer Science and Engineering, IUBAT University.
Prof. Dr. Md. Abdul Haque

Chairperson and Professor
Dept. of Computer Science and Engineering, IUBAT University.
iv
Letter of Transmittal
20th August, 2019
Chairman, Practicum and Placement Committee
College of Engineering and Technology (CEAT)
IUBAT- International University of Business Agriculture and Technology
4, Embankment Drive Road, Sector 10
Uttara Model Town, Dhaka -1230, Bangladesh.
Subject: Letter of Transmittal.
Dear Sir,
With due respect and humble, I would like to approach you that it is a great opportunity as well
as immense pleasure for me to submit this report titled “Online Based Inventory and Point of
Figure 17: Level 2 DFD ofLtd.”
Process
Sale Management System for Caveman international for 6the fulfillment of my practicum
course.
It was undoubtedly a splendid opportunity for me to work on this project to actualize my

theoretical knowledge and has an enormous exposure with the corporate culture of a renowned
IT in a Bank. Now I am looking forward for your kind appraisal regarding this practicum report.
I hope that you would find the report comprehensive and competent augmented.
Sincerely yours,
__________________
Md.Tayeb Adnan
ID: 15203116
v
Letter of Authorization
20th August, 2019
4, Embankment Drive Road, Sector 10
Uttara Model Town, Dhaka -1230, Bangladesh.
Subject: Letter of Authorization.
Md.Tayeb Adnan
Id# 15203116
Program: BCSE
Dear Md. Tayeb Adnan,
You will be happy to know that the project on “Online Based Inventory and Point of Sale
Management System for Caveman international Ltd.” I have received in your proposal under my
continue internship. Based Figure
on your17:proposal you will
Level 2 DFD have to6 submit the project as soon as
of Process
possible. We hope you will successfully complete it on time. After successful completion of the
project, you are requested to write a report based on the project.
For any kind of assistance don’t hesitate to contact with us.
Co- Supervisor Practicum Supervisor
------------------------- ----------------------------
Prof. Dr. Utpal Kanti Das M.M Rakibul Hasan

Coordinator, Department of
Lecturer, Department of Computer
Computer Science and Engineering
Science and Engineering
vi
Supervisor Declaration
This is to certify that Practicum report on “Development of Inventory and Point of Sale
Management System for Caveman international Ltd.” has been carried out by Md. Tayeb
Adnan, ID# 15203116 of IUBAT
– International University of Business Agriculture & Technology as a partial fulfillment of the
requirement of practicum defense course. The report has prepared under my guidance and record
of work carried out successfully. To the best of my knowledge and as per her declaration, no
parts of this report has been submitted anywhere for any degree, diploma or certificate.
Now she is permitted to submit the report. I wish her all success in her future endeavors.
Practicum Supervisor
----------------------------------------
M.M Rakibul Hasan
Lecturer,
vii
Student Declaration
I, Md. Tayeb Adnan, a student of BCSE - Bachelor of Computer Science and Engineering
program, under the College of Engineering and Technology (CEAT) of IUBAT-International
University of Business Agriculture and Technology declaring that, this report on the topic of
“Online Based Inventory and Point of Sale Management System for Caveman international Ltd.”
has been prepared for the fulfillment of the internship CSC 490, Practicum as well as the partial
requirement of BCSE- Bachelor of Computer Science and Engineering degree.
It has not been prepared for any other purposes, rewards, or presentation.
-----------------------------------Figure 17: Level 2 DFD of Process 6

Md.Tayeb Adnan
Id# 15203116
Program: BCSE
viii
Acknowledgement
In the name of Allah who is the most merciful and the most graceful it’s my pleasure to take this
occasion to thank a few people, who have, assisted, encouraged, directed and supported me
throughout my practicum program.
First of all, I want to thank my parents, who have endowed their immeasurable-innumerable
support and encouragement to attain this exquisite event of my life.
I sincerely would like to thank Md. Ashiqur Rahman (Software Engineer of Caveman
international Ltd) for giving me the opportunity to complete my internship and project at
Caveman international Ltd.
I would like to pay my gratitude to my faculty advisor M.M Rakibul Hasan, Lecturer of
Computer Science & Engineering
FigureDepartment,
17: Level 2 who
DFDhas given me
of Process 6 the opportunity to make such a
report for not only in this semester but also throughout my education life at IUBAT by giving his
valuable suggestions and advices at any time, at any situation.
Last but not least my sincere and outmost thank goes to Prof. Dr. Utpal Kanti Das, Coordinator
of Department of Computer Science and Engineering, International University of Business
Agriculture and Technology. For his continuous encouragement and contribution gave me the
courage determination needed to able to finish the internship and finish it well.
My success could not turn into reality without these people who help me in different ways. I also
like to thank all of my friends for their valuable suggestion and comments.
ix
Table of Contents
Abstract......................................................................................................................................... iii
Letter of Transmittal .................................................................................................................... v
Letter of Authorization................................................................................................................ vi
Supervisor Declaration ............................................................................................................... vii
Student Declaration ................................................................................................................... viii
Acknowledgement ........................................................................................................................ ix
Table of Contents .......................................................................................................................... x
List of Figure .............................................................................................................................. xiii
List of Table ................................................................................................................................. xv
Chapter 1: Introduction ......................................................................................................... 1
1.1 Project Overview ......................................................................................................................... 2
1.2 Objectives .................................................................................................................................... 2
1.3 Scope of the project ..................................................................................................................... 3
1.4 Figure 17: Level 2 DFD of Process 6
System benefits ............................................................................................................................ 3
1.5 Methodology and Data Collection ............................................................................................. 3
1.5.1 Primary Data ......................................................................................................................... 4
1.5.2 Secondary Data ..................................................................................................................... 4
1.6 Feasibility Study .......................................................................................................................... 4
1.6.1 Technical Feasibility .............................................................................................................. 4
1.6.2 Economic Feasibility .............................................................................................................. 5
1.6.3 Operational Feasibility .......................................................................................................... 5
1.7 Software Process Model ............................................................................................................. 5
1.7.1 Reason for choosing waterfall process model ...................................................................... 6
1.7.2 Phases of Waterfall Model in Software Engineering ............................................................ 6
1.7.3 Advantages of waterfall process model ................................................................................ 7
1.7.4 Disadvantages of waterfall process model ........................................................................... 7
Chapter 2: The Organization ................................................................................................ 8
2.1 Organization Overview .............................................................................................................. 9
2.1.1 Philosophy ............................................................................................................................. 9
x
2.1.2 Services ............................................................................................................................... 10
2.1.3 Address................................................................................................................................ 10
Chapter 3: Requirement Engineering ................................................................................ 11
3.1 Requirement Engineering ........................................................................................................ 12
3.1.1 User Requirements ............................................................................................................. 12
3.1.2 System Requirements ......................................................................................................... 13
3.1.3 Functional Requirements .................................................................................................... 14
3.1.4 Non-Functional Requirements ............................................................................................ 15
3.1.5 Specification of Each Requirement ..................................................................................... 15
3.2 Use Case Diagram ..................................................................................................................... 16
Chapter 4: System Planning ................................................................................................ 17
4.1 Functions of Proposed System ................................................................................................. 18
4.1.1 Functions’ Description ........................................................................................................ 18
4.2 Software Project Planning........................................................................................................ 20
4.2.1 System Project Estimation .................................................................................................. 20
4.2.2 Function Point Estimation ................................................................................................... 21
4.2.3 Figure 17: Level 2 DFD of Process 6
Process Based Estimation.................................................................................................... 30
4.2.4 Effort Distribution ............................................................................................................... 31
4.2.5 Effort Based Estimation....................................................................................................... 32
4.2.6 Task Scheduling ................................................................................................................... 32
4.2.7 Project Scheduling Chart ..................................................................................................... 33
4.2.8 Cost Estimation ................................................................................................................... 33
Chapter 5: Risk Engineering ............................................................................................... 36
5.1 Risk Management ..................................................................................................................... 37
5.1.1 Project Risks ........................................................................................................................ 38
5.1.2 Technical Risks .................................................................................................................... 38
5.1.3 Business Risks ...................................................................................................................... 39
5.2 The RMMM Plan ...................................................................................................................... 39
5.2.1 Risk Identification................................................................................................................ 39
5.2.2 Risk Analysis ........................................................................................................................ 40
5.2.3 Risk Planning ....................................................................................................................... 41
xi
5.2.4 Risk Monitoring ................................................................................................................... 42
Chapter 6: Analysis and Design .......................................................................................... 45
6.1 Activity Diagram ....................................................................................................................... 46
6.2 Swim Lane Diagram ................................................................................................................. 49
6.3 Entity Relationship Diagram ................................................................................................... 54
6.4 Data Flow Diagram ................................................................................................................... 56
6.5 Interface Design ........................................................................................................................ 64
6.6 Database Design ........................................................................................................................ 73
Chapter 7: System Quality & Testing ................................................................................. 77
7.1 System Testing........................................................................................................................... 78
7.1.1 Reasons for Performing System Testing ............................................................................. 78
7.1.2 Characteristics of System Testing ....................................................................................... 79
7.1.3 When to Perform System Testing ....................................................................................... 79
7.1.4 Key Areas of System Testing ............................................................................................... 80
7.2 System Testing Methodology ................................................................................................... 80
7.2.1 Black Box Testing................................................................................................................. 81
7.2.2 Figure
White Box Testing 17: Level 2 DFD of Process 6
............................................................................................................... 83
7.3 Testing Design ........................................................................................................................... 85
Chapter 8: Conclusion .......................................................................................................... 89
8.1 Conclusion ................................................................................................................................. 90
8.2 Limitation of the project........................................................................................................... 90
8.3 Future Scope.............................................................................................................................. 90
References .................................................................................................................................... 91
xii
List of Figure
Figure 1: Incremental Process Model ............................................................................................. 5
Figure 2: Use Case Diagram ......................................................................................................... 16
Figure 3: Effort Based Estimation ................................................................................................ 32
Figure 4: Project Scheduling Chart ............................................................................................... 33
Figure 5: Admin Activity Diagram ............................................................................................... 47
Figure 6: Employee Activity Diagram .......................................................................................... 48
Figure 7: Swim Lane Diagram for Managing Products ................................................................ 49
Figure 8: Swim Lane Diagram for Managing Employee .............................................................. 50
Figure 9: Swim lane Diagram for Managing Supplier .................................................................. 51
Figure 10: Swim lane Diagram for Managing Customer .............................................................. 52
Figure 11: Swim lane Diagram for Order Management ............................................................... 53
Figure 12: Swim lane Diagram for Requisition ............................................................................ 54
Figure 13: Entity Relationship Diagram ....................................................................................... 55
Figure 14: Context Level diagram ................................................................................................ 56
Figure 15: Level 1 Diagram .......................................................................................................... 57
Figure 16: Level 2 DFD of Process 1 ........................................................................................... 58
Figure 18: Level 2 DFD of Process
Figure 17: 3 ...........................................................................................
Level 2 DFD of Process 6 59
Figure 25: Log in Page .................................................................................................................. 64
Figure 26: Dashboard .................................................................................................................... 64
Figure 27: Add Category Page ...................................................................................................... 64
Figure 28: Add Company Page ..................................................................................................... 65
Figure 29: View Company page ................................................................................................... 65
Figure 30: Product Add Page ........................................................................................................ 66
Figure 31: Product View Page ...................................................................................................... 66
Figure 32: Supplier Add Page ....................................................................................................... 67
Figure 33: View Supplier Page ..................................................................................................... 67
Figure 34: Customer Add Page ..................................................................................................... 68
Figure 35: Customer View Page ................................................................................................... 68
Figure 36: Order Add Page ........................................................................................................... 69
Figure 37: Order View Page ......................................................................................................... 69
xiii
Figure 38: Requisition Add Page .................................................................................................. 70
Figure 39: Requisition View Page ................................................................................................ 70
Figure 40: Purchase Add Page ...................................................................................................... 71
Figure 41: Purchase Details Page ................................................................................................. 71
Figure 42: Sold Product Details .................................................................................................... 72
Figure 43: Sales Product Page ...................................................................................................... 72
Figure 44: Report Generation ....................................................................................................... 73
Figure 45: Company Table ........................................................................................................... 73
Figure 46: Category Table ............................................................................................................ 74
Figure 47: Product Table .............................................................................................................. 74
Figure 48: Supplier Table ............................................................................................................. 75
Figure 49: Customer Table ........................................................................................................... 75
Figure 50: Customer Order Table ................................................................................................. 75
Figure 51: Purchase Table ............................................................................................................ 75
Figure 52: Requisition Table ........................................................................................................ 76
Figure 53: Sales Table .................................................................................................................. 76
Figure 54: User Table ................................................................................................................... 76
Figure 55: System testing methodology ....................................................................................... 81
xiv
List of Table
Table I: Identifying Complexity for Transaction Function .................................................... 22
Table II: Identifying Complexity for Data Function ............................................................... 27
Table III: Unadjusted Function Point Contribution for Transaction Function ................... 28
Table IV: Unadjusted Function Point Contribution for Data Function ................................ 29
Table V: Performance and Environment Impact .................................................................... 29
Table VI: Process Based Estimation ......................................................................................... 31
Table VII: Personnel Cost .......................................................................................................... 34
Table VIII: Software cost ........................................................................................................... 34
Table IX: Total Cost ................................................................................................................... 35
Table X: Risk Identification ....................................................................................................... 39
Table XI: Risk Analysis .............................................................................................................. 40
Table XII: Risk Planning ........................................................................................................... 41
Table XIII: Project Risk (P01) ................................................................................................... 42
Table XIV: Business Risk (B01) ................................................................................................ 43
Table XV: Business Risk (B01) .................................................................................................. 43
Table XVI: Technical Risk (T01) .............................................................................................. 44
Table XVII: Technical Risk (T02) ............................................................................................. 44
Table XVIII: Testing Scenario Figure No17: 1 ..........................................................................................
Level 2 DFD of Process 6 85
Table XIX: Testing Scenario No 2 ............................................................................................. 86
Table XX: Testing Scenario No 3 .............................................................................................. 86
Table XXI: Testing Scenario No 4 ............................................................................................. 87
Table XXII: Testing Scenario No 5 ........................................................................................... 87
Table XXIII: Testing Scenario No 6 .......................................................................................... 87
Table XXIV: Testing Scenario No 7 .......................................................................................... 88
Table XXV: Testing Scenario No 8 ........................................................................................... 88
xv
Chapter 1:Introduction
1
1.1 Project Overview
In this present technological era, most of the organizations use computerized system for
business purpose. Inventory and Point of Sale Management System is a software that’s used
for tracking inventory levels, orders, sales and deliveries. Inventory or stock is the goods and
materials that a business holds for the ultimate goal of sale. The Inventory and Point of Sale
Management System used in Caveman International Ltd., is desktop based which is not
suitable for the remote working. In the existing system admin is the only user, there is no
access for the others employees. So I am going to develop “Online Based Inventory and Point
of Sale Management System for Caveman International Ltd.” where admin as well as the
employees can access the system and they can work remotely. Some of the modules of the
proposed system are product, employee, Sale, requisition, order where admin can manage the
whole system and employee can input the product details, Sale Product, Sale details.
1.2 Objectives
Figureis17:
The main objective of this IPMS to Level 2 DFD
implement anofonline
Process 6 software which will store
based
and retrieve all the related data of the Organization in a very organize and systematic way.
This system provides the company to manage their information without the need for specialist
technical skills. The system can also help to
 Improve information accuracy.
 Store product details with category.
 Manage all Product and employee record.
 Store and retrieve the sells report.
 Reduce duplication of information.
 Improve customer experience.
 Improve business responsiveness.
 Create notification if the product quantity becomes low.
 Generate the report.
2
1.3 Scope of the project
The scope of this IPMS can cover many needs, including valuing the inventory, measuring
the change in inventory and planning for future inventory levels. The value of the inventory
at the end of each period provides a basis for financial reporting on the balance sheet.
Measuring the change in inventory allows the company to determine the cost of inventory
sold during the period. This allows the company to plan for future inventory needs.
1.4 System benefits
The system will support the store, manage, and create report of sells, products and Sale
information of the organization. The system will enable a company to maintain a centralized
record of every asset and item for controlling the organization, providing accurate
information for the location of every item, vendor and supplier information, specifications,
and the total number of a particular item currently in stock. Overall, the system will provide
benefits including:
 Improved cash flow Figure 17: Level 2 DFD of Process 6
 Information of product, employee, customer, supplier, order.
 Automatic notification for restocking the demanded product.
 Better reporting and predicting capabilities
 Reduction in storage costs (overhead)
 Reduced labor costs
 Reduction in dead stock
 Better organization
 Enhanced transparency
1.5 Methodology and Data Collection
Data collection is a process of collecting information from all the relevant sources to find
answers to the problem, and evaluate the outcomes. Data collection methods can be divided
into two categories: secondary methods of data collection and primary methods of data
collection. For this IPMS system both methods have been followed.
3
1.5.1 Primary Data
Primary data collection methods can be divided into two groups: quantitative and qualitative.
 Quantitative data collection methods are based in mathematical calculations in various
formats. Methods of quantitative data collection and analysis include questionnaires
with closed-ended questions, methods of correlation and regression, mean, mode and
median and others.
 Qualitative data collection methods, on the contrary, do not involve numbers or
mathematical calculations. Qualitative research is closely associated with words,
sounds, feeling, emotions, colors and other elements that are non-quantifiable.[1]
For this project, qualitative method is used to collect the data. The primary data have
collected through UBSL’s practical experience, observation, and face-to-face interview with
both employees and managerial levels.
1.5.2 Secondary Data
Secondary data is a type of data that has already been published in books, newspapers,
magazines, journals, online Figure
portals17:
etc.Level
For the development
2 DFD of Processof6 this system, some data has
been collected from online papers.
1.6 Feasibility Study
Feasibility study determines whether that solution is feasible or achievable for the
organization or not. This means that the tasks that I will perform are worth enough or not.
There are three major areas of investigation and generating ideas about a new system. On
studying the feasibility of the system, three major considerations are dealt with, to find
whether the automation of the system is feasible.
 Technical feasibility
 Economic feasibility
 Operational feasibility
1.6.1 Technical Feasibility
The proposed system is compatible with a low qualification of computer also. To maintain
the system a computer with a browser and internal internet connection is needed which is
already exists within the organization. So, the system is technically feasible.
4
1.6.2 Economic Feasibility
Economic feasibility determines to what extent a new system, is cost effective or not. The
consideration is whether the organization will be able to pay cost for redesigning and whether
project will be best cost effective or not. In the proposed system many works can be done
within small time and which is not possible by man power within the same time. That means
it saves money and time both. It also reduces the man power needed for providing the
services. So it can be said that the system is economically feasible.
1.6.3 Operational Feasibility
Operational feasibility addresses concerns about user acceptance, management support, and
the requirements of entities and factors in the organizations external environment. The
proposed system is designed for users who have minimal knowledge to operate computer. So
the system is operationally feasible.
1.7 Software Process Model

The incremental build model is a method of software development where the product
is designed, implemented and tested incrementally (a little more is added each time) until the
product is finished. It involves both development and maintenance. The product is defined as
finished when it satisfies all of its requirements. This model combines the elements of
the waterfall model with the iterative philosophy of prototyping. First, a simple working
system implementing only a few basic features is built and then that is delivered to the
customer. Then thereafter many successive iterations/ versions are implemented and
delivered to the customer until the desired system is realized.
Figure 1: Incremental Process Model

5
1.7.1 Reason for choosing incremental process model
Every software developed is different and requires a suitable SDLC approach to be followed
based on the internal and external factors. For development of this IPMS, the incremental
process model is followed. The reasons for choosing this model are following-
 Major requirements are very well defined, however, some details can evolve with time.
 Demand for an early release of a product arises.
 Technology is understood and is not dynamic.
 The project needs regular update.
 Project needs number of release.
1.7.2 Phases of Incremental Model in Software Engineering
There are several phases in the waterfall model. They are briefly explained below.
Requirement Gathering and analysis: All possible requirements of the system to be
developed are captured in this phase and documented in a requirement specification
document.
System Design: The requirement specifications from first phase are studied in this phase and
the system design is prepared. This system design helps in specifying hardware and system
requirements and helps in defining the overall system architecture.
Implementation: With inputs from the system design, the system is first developed in small
programs called units, which are integrated in the next phase. Each unit is developed and
tested for its functionality, which is referred to as Unit Testing.
Integration and Testing: All the units developed in the implementation phase are integrated
into a system after testing of each unit. Post integration the entire system is tested for any
faults and failures.
Deployment of system: Once the functional and non-functional testing is done; the product
is deployed in the customer environment or released into the market.
Maintenance: There are some issues which come up in the client environment. To fix those
issues, patches are released. Also to enhance the product some better versions are released.
Maintenance is done to deliver these changes in the customer environment. [2]
6
1.7.3 Advantages of Incremental process model
Some of the major advantages of the Incremental Model are as follows −

 The software will be generated quickly during the software life cycle
 It is flexible and less expensive to change requirements and scope
 Thought the development stages changes can be done
 This model is less costly compared to others
 A customer can respond to each building
 Errors are easy to be identified
 Process and results are well documented
1.7.4 Disadvantages of Incremental process model
The major disadvantages of the Incremental Model are as follows −

 It requires a good planning designing.
 Problems might cause due to system architecture as such not all requirements collected up front for
the entire software lifecycle.
 Each iteration phase is rigid 17:
Figure andLevel
does not overlap
2 DFD each other.
of Process 6
 Rectifying a problem in one unit requires correction in all the units and consumes a lot of time. [3]
7
Chapter 2:The Organization
8
Chapter 2 is representing an organizational overview, mission, and company’s vision and
about company’s services. In this chapter the detail organizational overview is discussed
along with the organization’s mission and vision followed by numerous services.
2.1 Organization Overview
CAVEMAN INTERNATIONAL LTD. (CIL) is a professional Website & Software

Development Company in Uttara, Dhaka, Bangladesh transformed as specialized digital
interactive organization. The dedicated team of professionals is always ready with new and
unique ideas of promoting anyone’s business. Ranging from website designing to its
optimization, we take care of all. UBSL provides corporate IT services for business. The
services includes website design, domain registration, web hosting, software development,
web application development, SMS marketing, email marketing, SEO service, Facebook
advertising service, news portal development.
Their creative team of Graphic Designing is devoted for designing unique and interactive
graphics. They design websites meticulously, making its navigation unproblematic for the
visitor. Their database of Figure
clients 17:
ranges
Levelfrom individual
2 DFD clients
of Process 6 to big/ medium/ small
business houses & Industry. [4]
2.1.1 Philosophy
Customer satisfaction is UBSL’s number one priority. UBSL is proud of the fact that its
growth is largely driven by word of mouth through happy clients. UBSL is not one of the
companies that only relies on aggressive marketing campaigns. It offers full-featured, great
quality IT services that include everything clients need to succeed on the Internet at an
affordable price.
We understand that like us, every entrepreneur looks at getting the best service at the most
cost effective prices. Therefore, we try to provide exceptional quality web hosting and
domain registration services to all our clients at unbelievable prices. Customer can depend on
 Best Customer Service
 A Fair Price
 Solid and Honest Business
 Money Back guarantee within 30 days.
 The best professional from the IT industry
 Maintain best quality & services
9
2.1.2 Services
The services UBSL offers
 TLD Domain Registration

 .BD Domain Registration
 Business Web Hosting
 Corporate Web Hosting
 Google Email/G-Suit Services
 Local Email Server Solution
 Static and Dynamic Website Design
 SEO services
 Online Software development
 Desktop software development
 Online News, Job Portal Development
 Ecommerce Development
 Facebook marketing
 SMS Marketing
2.1.3 Address
Plot #87, BNS Center (4th floor), Suite No. 507/A,
Dhaka - Mymensingh Highway,
Sector #07, Uttara Model Town,
Dhaka-1230, Bangladesh.
10
Chapter 3: Requirement
Engineering
11
Chapter 3 is representing the requirement engineering, user requirement, system requirement,
functional requirement and non-functional requirement. This chapter describes the
methodology for the generation of software requirements for Inventory and Point of Sale
Management System. It describes what needs to be done, how to manage the sales, purchases,
orders, employees, customers, suppliers of their system.
3.1 Requirement Engineering
Requirement engineering refers to the process of defining, documenting and maintaining

requirements and to the subfields of systems engineering and software engineering concerned
with this process. [5] Designing and building an elegant computer program that solves the
wrong problem serves no one’s need. That’s why it is important to understand what the
customer wants before we begin to design and build a computer-based system. Requirement
engineering encompasses the tasks that lead to an understanding of what the business impact
of the software will be, what the customer wants, and how end-users will interact with the
software.
 User RequirementsFigure 17: Level 2 DFD of Process 6

 System Requirements
 Functional Requirements
 Non-Functional Requirements
3.1.1 User Requirements
The system has two user types: admin, employee.

Admin can
 Login and Logout.
 Manage the category.
 Manage products.
 Manage Sales.
 Manage requisition.
12
 Manage employee.
 Generate the report.
Employee can
 Login and Logout.
 Add and view the category.
 Add and view products.
 Create and view requisition
 Sale product.
 Create receipt.
 See the inventory list.
3.1.2 System Requirements
 Admin can login and logout in the system.

 Admin must have username and password.
 System will check whether the username and password is valid or not.
 If the username and password is valid, admin can access the system.
 Admin can manage the category.
 Admin must log into the system.
 For adding new category, admin must enter category name.
 Admin can update, see, delete category.
 Admin can manage the products.
 For adding new product, admin must enter product details, select the category
and brand of the product.
 Admin can update, see, delete product.
 Admin can manage requisition.

 Admin can see the requisition for products made by the employee.
 Admin can approve, update, see, delete requisition.
 Admin can manage sale.

 Admin can add new Sale.
 Admin can update, see, delete Sale.
13
 Admin can manage user.
 Admin can add new user.
 Admin can update, see, delete user.
 Admin can manage employee.
 Admin can add new employee.
 Admin can update, see, delete employee.
 Admin can generate the report on sales, purchases.
3.1.3 Functional Requirements
 Add products
 Edit, update, delete products
 View product details.
 Add category and update category.
 Add and manage employee
 Manage Sale details
14
 Manage requisition
 Generate report
3.1.4 Non-Functional Requirements
 System will need all username and password to store in database.

 System needs username and password information from the admin.
 System needs information from the customer.
 Admin can login to the system by using username and password.
 Employee can login to the system by using username and password.
3.1.5 Specification of Each Requirement

3.1.5.1 Admin Specification
Function: Log in, add information

Figure and confirm/cancel
17: Level 2 DFD ofsale.
Process 6
Description: Access to each and every section of the system.
Input: Admin input his information in his criteria.
Output: Information submits successfully.
Action: Information accepted or rejected.
Side effects: None
3.1.5.2 Employee Specification
Function: Log in, add information, manage sale.

Description: Easily use the system for his useful purpose.
Input: Employee input products, requisition and order information in his criteria
Output: Information submits successfully.
Action: Request & information accepted or rejected.
Side effects: None
15
3.2 Use Case Diagram
Figure 2: Use Case Diagram
16
Chapter 4:System Planning
17
Chapter 4 is representing the system project estimation, function oriented metrics, function
point estimation, and process based estimation, effort distribution, and task scheduling and
cost estimation. In this chapter the detail function point estimation is discussed in section
4.2.2 and process based estimation is discussed in section 4.2.3.
4.1 Functions of Proposed System
1. Login into the System [F01]

2. Manage products [F02]
3. Manage category [F03]
4. Manage orders [F04]
5. Manage customers [F05]
6. Manage supplier [F06]
7. Manage employee [F07]
8. Manage company [F08]
9. Manage requisition [F09]
10. Manage purchaseFigure 17: Level 2 DFD of Process 6 [F10]
11. Manage sales [F11]
12. Order details and report generation [ F12]
4.1.1 Functions’ Description

1. Login into the System
Input: Email and Password
Output: If login data is valid then set authorization as Super admin or admin or client to
the login person as defined in database otherwise will show error message.
Use table of the database: user, supplier.
2. Manage products
Input: Add new product, update product information, view and delete product record.
Output: List of all information of different products.
Use table of the database: product.
3. Manage category
Input: Add new category, update category information, view and delete category record.
Output: List of all information of category for different categories.
Use table of the database: category.
18
4. Manage order
Input: Add new order, update order information, view and delete order record.
Output: List of all information of order for different orders.
Use table of the database: customer_order, customer_order_details.
5. Manage customers
Input: Add new customers, update customer’s information, view and delete customer’s
record.
Output: List of all information of customers.
Use table of the database: customer.
6. Manage supplier
Input: Add new supplier, update supplier information, view and delete supplier record.
Output: List of all information of supplier for different supplier.
Use table of the database: supplier.
7. Manage employee
Input: Add new employee, update employee information, view and delete employee
record.
Output: List of all information of employee.
Use table of the database: employee.
8. Manage company
Input: Add new company, update company information, view and delete company record.
Output: List of all information of company for different companies.
Use table of the database: company.
9. Manage requisition
Input: Add new requisition, update requisition information, view and delete requisition
record.
Output: List of all information of requisition for different requisitions.
Use table of the database: requisition.
10. Manage purchase
Input: Add new purchase, update purchase information, view and delete purchase record.
Output: List of all information of purchase for different purchases.
Use table of the database: purchase.
19
11. Manage sales
Input: Add new sale, update sale information, view and delete sale record.
Output: List of all information of sale for different sales.
Use table of the database: sales.
12. Order details and report generation

Input: Generate order details report.
Output: Detailed orders information, will be generated.
Use of database table: sales.
4.2 Software Project Planning
Software project management commences with a set of activities that collectively called
software project planning. Before starting any project, it is compulsory to estimate the work
to be done, the resources that will be required, the time will elapse from start to finish and to
analyze the project to determine whether it is feasible or not.
The following activities of software project planning that have followed in this project are:
 System Project Estimation

 Function Oriented Metrics
 Process Based Estimation
 Effort Distribution
 Task Scheduling
 Project Schedule Chart
 Cost Estimation
4.2.1 System Project Estimation
The accuracy of a software project estimate predicated based on a number of things:

1. Properly estimated the size of the product to build.
2. The ability to translate the size estimation into human effort, calendar time and
money.
20
3. The degree to which the project plan reflects the abilities of the software team or
engineer.
4. The stability of the product requirements and the environment that supports the
software engineering effort.
4.2.2 Function Point Estimation

Function point based estimation focuses on information domain values rather that software
values. Function points are computed by comparing five information domain characteristics.
The Five Components of Function Points-
Data Functions
 Internal Logical Files
 External Interface Files
Transactional Functions
 External Inputs
 External Outputs
 External Inquiries
Number of external inputs –Each user input that provides distinct application-oriented data
to the software is counted inputs should be distinguished from inquires.
Number of external outputs –Each user output that provides application-oriented

information to the user is counted.
Number of external inquires –An inquiry defined as an on-line input those results in the
generation of some immediate software response in the form of an on-line output. Each
distinct inquiry counted.
Number of Internal Logical files –Each logical internal file is a logical grouping of data that
resides within the application’s boundary and is maintained via external inputs.
Numbers of external interfaces –All machine-readable interfaces that used to transmitting

formation to another system counted.
21
Identifying Complexity for Transaction Function:
Table I: Identifying Complexity for Transaction Function
Transaction Function Fields / File involvement FTRs DETs
File – User
Login (EI) Fields – Email, Password, Submit, Error 1 4
Message
File – product
Add & Update product (2*EI) Fields – Name, Image, Price, Description, 1 11
Vendor, Category, Quantity, Purchase Price,
Selling Price, Submit, Confirm / Error
File – product
View product (EO) Fields – Name, Image, Price, Description, 1 11

Vendor, Category, Quantity, Purchase Price,
Selling Price, update, delete
File – product
Delete product (EI) Fields – Product Id, Press Delete, 1 6

Confirmation Message, Press ok, Press
cancel, success/error message
File – product
Search product (EQ) Fields – Search text, Name, Image, Price, 1 12

Description, Vendor, Category, Quantity,
Purchase Price, Selling Price, update, delete
File – Category
Add & Update Category (2*EI) Fields –Name , Submit, Confirm / Error 1 3
Message
22
File – Category
View category (EO) 1 3
Fields – ID, Name , update, delete
File – Category
Delete category (EI) Fields – Category Id, Press Delete, 1 6

File – Category
Search category (EQ) Fields – Search text, ID, Name , update, 1 4
delete
File – supplier
Add & Update Supplier (2*EI) Fields –Company, Name , address, contact, 1 8
Email, Submit, Confirm / Error Message

File – supplier
View Supplier (EO) Fields –Supplier Id, Company, Name , 1 9
address, contact, Email, update, delete
File –supplier
Delete Supplier (EI) Fields – supplier Id, Press Delete, 1 6

File – Supplier
Search Supplier (EQ) Fields – Search text, Supplier Id, Company, 1 10

Name , address, contact, Email, update,
delete
File – requisition, supplier, product

Add Requisition (EI) 3 4
Fields – Supplier, product, quantity, Submit,
23
File – requisition
View Requisition (EO) Fields –Company and Supplier , product, 1 8

quantity, date, purchase status, request
action, done, delete
File –requisition
Delete Requisition (EI) Fields – requisition Id, Press Delete, 1 6

File – requisition
Search Requisition (EQ) Fields –Search Text, Company and Supplier , 1 9

product, quantity, date, purchase status,
request action, done, delete
File: requisition, purchase

Field: Requisition ID, Product ID, Product
Add purchase (EI) Code, Name, Requisition Quantity, Price, 2 9
Purchased Quantity, date, submit,

success/error message
File: purchase
View purchase (EO) Field: Purchase ID, Supplier name, company 1 6
name, date, view details, delete
File – purchase
Delete Purchase (EI) Fields – purchase Id, Press Delete, 1 6

File: purchase
Search purchase (EQ) 1 7
Field: Search text, Purchase ID, Supplier
name, company name, date, view details,
24
Delete
File: sales, customer, product
Add Sale product (EI) Field: customer, product, selling price, stock, 3 9
sales date, quantity, total price, submit,
File: sales
Field: Sales Id, customer name, customer ID,

View Sale product (EO) product code, product ID, product name, 1 12
price, quantity, total price, selling date,

update, delete
File – sales
Delete Sales product (EI) Fields – sales Id, Press Delete, Confirmation 1 6
FigureMessage,
17: LevelPress
2 DFDok,ofPress
Process 6
cancel,
File: sales
Field: Search text, Sales Id, customer name,

Search Sale product (EQ) customer ID, product code, product ID, 1 13
product name, price, quantity, total price,

selling date, update, delete
File: customer
Add & Update Customer (2*EI) Field: ID, Name, Contact, email, address, 1 7
submit, success/error message
File: customer
View Customer (EO) Field: ID, Name, Contact, email, address, sell 1 9
products, update, delete
25
File – customer
Delete Customer (EI) Fields – customer Id, Press Delete, 1 6

File: customer
Search Customer (EQ) Field: Search text, ID, Name, Contact, email, 1 10
address, sell products, update, delete
File –order
Place Order (EI) Fields – Customer, Product Name, Quantity, 1 7

date , add new item, Submit, Confirm / Error
Message
File – Order
View Order Details (EO) FigureFields – Order

17: Level ID, of
2 DFD Customer
Process Name,
6 1 6
Customer ID, Order date, view details,
delete.
File – Order
Search Order Details (EQ) Fields – Search text, Order ID, Customer 1 7
Name, Customer ID, Order date, view
details, delete.
File – Order
Delete Order details (EI) Fields – order Id, Press Delete, Confirmation 1 6
Message, Press ok, Press cancel,
File – Customer, product, sales

Generate Report (EO) 3 10
Fields – Sales Id, Customer Name, Customer
Id, Product Id, Product Code, Product Name,
26
Price, Quantity, Total price, Selling date
Identifying Complexity for Data Function
Table II: Identifying Complexity for Data Function

Data Function Fields / File involvement RETs DETs
Fields – Id, Email, Password, Name,

User (ILF) 1 6
Designation, Role
Fields – Id, Name, Company Name, Address,

Supplier (ILF) 1 6
Contact, Email
Category (ILF) Fields – Id, Name 1 2
Fields –Id, Product Code, Category, Name,

Product (ILF) Photo, Description, Purchase Price, Selling 3 10
FigurePrice,
17: Level 2 DFD
Quantity, of Process 6
Vendor
Fields – Product Name, Quantity, Supplier

Requisition (ILF) 3 4
Name, Date
Fields – Product Name, Quantity, Supplier

Purchase (ILF) 3 4
Name, Date
Fields – Product Name, Quantity, Customer

Order (ILF) 3 4
Name, Date
Fields – Id, Customer Name, Product Name,

Sales (ILF) 2 6
Quantity, Total Price, Date
27
Unadjusted Function Point Contribution for Transaction Function:
Table III: Unadjusted Function Point Contribution for Transaction Function

Transaction Functions FTRs DETs Complexity UFP
Login (EI) 1 4 Low 3
Add & Update product (2*EI) 1 11 Low 6
View product (EO) 1 11 Low 3
Delete Item (EI) 1 6 Low 3
Search Item(EQ) 1 12 Low 3
Manage Category (EI) 1 3 Low 3
Manage Supplier (EI) 1 8 Low 3
Add Requisition (EI) 3 4 Average 4
View Requisition (EO) 1 8 Low 4
Add purchase (EI) 2 9 Average 4
View purchase (EO) 1 6 Low 4
Add Sale product (EI) 2 9 Average 4
View Sale product (EO) 1 12 Low 4
Manage Customer (EI) 1 7 Low 3
Place Order (EI) 1 7 Low 3
View Order Details (EO) 1 6 Low 4
Generate Report (EQ) 3 10 Average 4
Total = 64
28
Unadjusted Function Point Contribution for Data Function:
Table IV: Unadjusted Function Point Contribution for Data Function

Data Functions RETs DETs Complexity UFP
User (ILF) 1 6 Low 7
Supplier (ILF) 1 6 Low 7
Category (ILF) 1 2 Low 7
Product (ILF) 3 10 Low 7
Requisition (ILF) 3 4 Low 7
Purchase (ILF) 3 4 Low 7
Order (ILF) 3 4 Low 7
Sales (ILF) 2 6 Low 7
Total = 56
Performance and Environment Impact:

Table V: Performance and Environment Impact
GSC DI
1. Data Communications 2
2. Distributed Data Processing 3
3. Performance 3
4. Heavily Used Configuration 2
5. Transaction Rate 1
6. Online Data Entry 2
7. End-user Efficiency 3
8. Online Update 0
9. Complex Processing 2
10. Reusability 1
11. Installation Ease 2
29
12. Operational Ease 1
13. Multiple Site 0
14. Facilitate Change 2
Total Degree of Influence (TDI) = 24
Value Adjustment Factor (VAF) = 0.65 + (0.01 * TDI)

= 0.65 + (0.01 * 24)
= 0.89 [0.65 ≤ VAF ≤ 1.35]
UFP = UFP (Transaction Function) + UFP (Data Function)

= 64 + 56 = 120
Adjustment Function Point Count (AFP) = UFP * VAF

= 120* 0.89
= 106.8
Effort for PHP = AFP * Productivity
= 106.8 * 15.5 [PHP productivity = 15.5]
= 1655.4 person hours / 8 hours
= 206.9 person days / 26 days
= 7.96 person months / 2 persons
= 3.98 months
Approximate 4 months for 2 persons.
4.2.3 Process Based Estimation
In process-based estimation, process is decomposed into a relatively small set of tasks and
the effort required to accomplish each task is estimated. Process based estimation begins
with a delineation of software functions obtained from the project scope. A series of
software process activities must be performed for each function.
30
Table VI: Process Based Estimation
Function Pre-requisite Engineering Construction & CE Total
Release
Data Collection Anal Design Code Test
ysis
F1 0.02 0.10 0.03 0.15 0.08 N/A 0.38
F2 0.08 0.23 0.18 0.37 0.05 N/A 0.91
F3 0.03 0.10 0.07 0.17 0.05 N/A 0.42
F4 0.06 0.25 0.19 0.39 0.10 N/A 0.99
F5 0.05 0.11 0.06 0.21 0.05 N/A 0.48
F6 0.03 0.10 0.05 0.20 0.05 N/A 0.43
F7 0.02 0.10 0.06 0.20 0.05 N/A 0.43
F8 0.03 0.10 0.08 0.20 0.06 N/A 0.47
F9 0.04 0.26 0.22 0.38 0.08 N/A 0.98
F10 0.03 0.24 0.19 0.28 0.07 N/A 0.91
F11 0.03 0.25 0.19 0.30 0.06 N/A 0.83
F12 0.03 Figure 17:
0.24Level 20.20
DFD of Process
0.35 6 0.05 N/A 0.87
Total 0.45 2.08 1.52 3.2 0.75 N/A 8
Effort 5.57% 26% 19% 40% 9.43% N/A 100%
4.2.4 Effort Distribution
The project estimation technique leads to estimates of work units required to complete the
software development. A recommended distribution of effort across the definition and
development phases referred as the 40-20-40 rule. Forty percent of all effort allocated to
front-end analysis and design, twenty percent allocated to coding and the remaining forty
percent allocated to back-end testing. This rule used as a guideline only.
In this project, 5.57% has been allocated for data collection, 45% has been allocated to
analysis and design, 40% has allocated to coding and 9.43% is allocated to software testing
and support.
31
4.2.5 Effort Based Estimation
Figure
Figure17:
3: Level
Effort2Based
DFD Estimation
of Process 6
Description:
 1 (6% - Data Collection)

 2 (26% - Analysis)
 3 (19% - Design)
 4 (40% - Code)
 5 (9% - Testing).
4.2.6 Task Scheduling
Project scheduling is an activity of distributing the estimated efforts within the planned
project duration. There are some basic rules for project scheduling. They are as follows –
Compartmentalization – The project must compartmentalize into a number of manageable
activities and tasks.
Interdependency – The interdependency of each compartmentalized activity or task must be
determined. Some tasks must occur in sequence while others can occur in parallel.
32
Time allocation – Each task to be scheduled must allocated some number of work units.
Effort validation – Every project has a defined number of staff members. It should ensure
that no more than the allocated number of people has scheduled at any given time.
Defined responsibilities – Every task that is scheduled should assign to a specific team
member.
Defined outcomes – Every task that is scheduled should have a defined outcome. The
outcome is normally a work product or a part of a work product.
4.2.7 Project Scheduling Chart
System development is combination of some tasks. These tasks should done sequentially and
timely. Project schedule works as the guideline of the system developer. The schedule chart
of this project is following:
Figure 4: Project Scheduling Chart
4.2.8 Cost Estimation
1. Personnel Cost
2. Software Cost
3. Hardware Cost
33
Personnel cost:
Table VII: Personnel Cost

Type No. of Members Months Salary
System Analyst 1 4 30,000

Developer 1 4 26,000
Tester 1 4 25,000
Total 81,000 TK
Hardware cost:
Cost of a Laptop = 45000

Computer life = 1.5 years
Computer usage = 16 weeks = 4 months
Computer cost = (45000/18) x 4 x 2 = 20000BDT
Software cost:
Table VIII: Software cost
Name Price
Sublime Text PHP Storm No cost
Windows 10 No cost
Total No cost was needed as the software were available free of cost.
34
Total Cost:
Table IX: Total Cost
Purpose Amount
Salary 81,000
Hardware 20000
Software No cost
Total 101000 BDT
35
Chapter 5: Risk Engineering
36
Chapter 5 is representing the risk management, risk identification, risk classification, risk
assessment, risk analysis, technical risks, business risks, risk mitigation, risk monitoring, risk
management and project risk. In section 5.1 and 5.2, the detail risk management is discussed
along with the RMMM plan.
5.1 Risk Management
A risk is a potential problem that might or might not happen. It is necessary to analyze the
potential risks in a project. If the risks of a software project are not properly analyzed and
estimated, many problems can plague the software project. Risk analysis and management are
a series of steps that help a software team to understand and manage uncertainty.
To establish a risk management model the following phases are followed:
 Risk identification is the process of detecting potential risks or hazards through data
collection. A range of data collection and manipulation tools and techniques exists. The
team is using both automated and manual techniques to collect data and begin to
Figure
characterize potential risks to 17:
Web Level 2 DFD Web
resources. of Process 6 is one effective way to
crawling
collect information about the state of Web pages and sites.
 Risk classification is the process of developing a structured model to categorize risk and
fitting observable risk attributes and events into the model. The team combines
quantitative and qualitative methods to characterize and classify the risks to Web pages,
Web sites, and the hosting servers.
 Risk assessment is the process of defining relevant risk scenarios or sequences of events
that could result in damage or loss and the probability of these events. Many sources
focus on risk assessment. Rosenthal describes the characteristics of a generic standard for
risk assessment as "transparent, coherent, consistent, complete, comprehensive, impartial,
uniform, balanced, defensible, sustainable, flexible, and accompanied by suitable and
sufficient guidance.
 Risk analysis determines the potential impact of risk patterns or scenarios, the possible
extent of loss, and the direct and indirect costs of recovery. This step identifies
vulnerabilities, considers the willingness of the organization to accept risk given potential
consequences, and develops mitigation responses.
 Risk management implementation defines policies, procedures, and mechanisms to
manage. The implemented program should balance the value of assets and the direct and
37
indirect costs of preventing or recovering from damage or loss. To take comprehensive
care of a web based system we must consider the following points.
 Hardware and software environment, including any upgrades to the operating system and
Web server, the installation of security patches, the removal of insecure services, use of
firewalls, etc.
 Administrative procedures, such as contracting with reputable service providers,
renewing domain name registration, etc.
 Network configuration and maintenance, including load balancing, traffic management,
and usage monitoring.
 Backup and archiving policies and procedures, including the choice of backup media,
media replacement interval, number of backups made and storage location.
 Physical location of the server and its vulnerability to fire, flood, earthquake, electric
power anomalies, power interruption, temperature fluctuations, theft, and vandalism. [6]
There are different categories of risks that should be considered in any software project. The
following categories of risks have been considered in this software project:
5.1.1 Project Risks
These risks threaten the project plan. If these risks become real, it is likely that the project
schedule will slip and that costs will increase. Project risks identify potential budgetary,
schedule, personnel, resource, customer and requirement problems and their impact on the
software project.
5.1.2 Technical Risks
These risks threaten the quality and timeliness of the software to be produced. If a technical
risk becomes a reality, implementation may become difficult or impossible. Technical risks
identify potential design, implementation, interface, verification and maintenance problems.
Moreover, specification ambiguity, technical uncertainty, technical obsolescence are also risk
factors.
38
5.1.3 Business Risks
These risks threaten the viability of the software to be built. The business risks can be –
a. Building a system that no one really wants – market risks.

b. Building a system that no longer fits into the overall business strategy for the
company – strategic risks.
c. Building a system whose business needs have been changed.
d. Losing the support of senior management due to a change in focus or a change
in people – management risks.
e. Losing budgetary or personnel commitment – budget risks.
5.2 The RMMM Plan

5.2.1 Risk Identification
Table X: Risk Identification

Risk type Possible risks
1. Security of the system

Technology
2. Reusable software components may contain
defects and cannot be reused as planned.
3. Key staff is ill and unavailable at critical

People
times.
4. Required training for staff is not available.
5. Organizational financial problems force

Organizational
reductions in the project budget.
Requirement 6. Changes to requirements that require major

design rework are proposed.
39
5.2.2 Risk Analysis
Table XI: Risk Analysis
Risk Probability Effects
Organizational financial problems

force reductions in the project
Low Catastrophic
budget.
Security of the system.

High Serious
Reusable software components Moderate

contain defects that mean they cannot Serious
be reused as planned.
Changes to requirements that require

major design rework are proposed. Moderate Serious
Required training for staff is not

available. Moderate Tolerable
Customers fail to understand the

impact of requirements changes. Moderate Tolerable
40
5.2.3 Risk Planning
Table XII: Risk Planning
Risk Strategy
Security Investigate the possible security leaks and

measurements
Organizational financial Prepare briefing documents for senior

problems management showing how the project is
making a very important contribution to the
goals of business and presenting reasons
why cuts to the project budget would not be
cost-effective.
Requirements problem Alerts customer to potential difficulties and
possibility of delays; investigate buying in
component.
Staff illness Reorganize them so that there is more
overlap work and people therefore
understand each other jobs.
Defective component Replace defective potential component with
bought in component of know reliability.
Requirements changes Replace defective potential component with

bought in component of know reliability.
Requirements changes Derive traceability information to access

requirements change impact; maximizing
information hiding in the design.
41
5.2.4 Risk Monitoring
 A re-planning of the project occurs. New task schedule and milestones are defined. Staffs
work on their assigned jobs within the new timeframe.
 In order to prevent this from happening, the software will develop with the end user in
mind.
 The user-interface will design in a way to make use of the program convenient and
pleasurable.
 Meetings (formal and informal) will be held with the stakeholders regularly. This insures
that the product we are producing solves a problem.
 The development cost of the software may increase by 20%.Consult with the System
Analyst during the system analysis, design and testing phase of the software project.
 Proper coding grammar is followed to make sure that the codes are easily understandable
and reusable.

Table XIII: Project Risk (P01)
Project Risk (P01) Date: 15-02-2019
Name Changes the requirements
Probability Low (18%)
Impact Marginal (2)
Description Company may change their requirements
Mitigation & Monitoring Requirements are redefined by the company due to time or business
needs. Meeting will be held with the company regularly. This
insures that the product we are producing solves a problem.
Management Emergency meeting between both parties to identify new project

requirements and goals.
Status Not occur
42
Table XIV: Business Risk (B01)
Business Risk (B01) Date: 02-07-2019
Name Insufficient Budget
Probability Moderate (35%)
Impact Marginal (2)
Description If the budget is low project may not complete.
Mitigation & Monitoring The project needs server that is costly to set-up.
We find several alternative streaming services to reduce the budget
risk.
Management Refinement in project goal. A new plan for regulate the budget.
Status Problem resolved.
Table XV: Business Risk (B01)

Business Risk (B02) Date: 20-07-2019
Name Figure
End17: Level
Users 2 DFD
Accept of Process 6
System
Impact Critical (4)
Description The system fails to gain user’s faith
Mitigation & Monitoring In order to prevent this from happening, the software will develop
with the end user in mind. The user-interface will design in a way
to make use of the program convenient and pleasurable.
Management Training the users to familiarize them with the new system.
Releasing patches/bug fixes for greater user satisfaction.
Status The risk has not been arisen yet.
43
Table XVI: Technical Risk (T01)
Technical Risk (T01) Date: 25-07-2019
Name Lack of Experience
Impact Tolerable (3)
Description Lack of members experience
Mitigation & Monitoring The development cost of the software may increase by 20%.
Consult with the System Analyst during the system analysis,
design and testing phase of the software project.
Management Though the development cost is increased by 20%, the project is
still feasible. Set appointment for formal meeting with the System
Analyst to solve different problems of each of the phases.
Status The risk has not been arisen yet.
Table XVII: Technical Risk Figure

(T02) 17: Level 2 DFD of Process 6
Technical Risk (T03) Date: 31-07-2019
Name Computer Crash
Probability High (60%)
Impact Tolerable (3)
Description Computer can be crash.

Mitigation & Monitoring We should take proper follow up of computers. We also take regular
data backup every day, We can use IPS to stop unexpected shutdown.
Management If our computer has been crashed then we will restore backup.
Status The risk has not been faced yet.
44
Chapter 6:Analysis and Design
45
This chapter is representing the diagrams and interface design of project. In system analysis a
study of the system as detailed as possible will occur with the help of some diagrams i.e.
Activity Diagram, Swim Lane Diagram, ER Diagram, DFD etc.
6.1 Activity Diagram
An activity diagram visually presents a series of actions or flow of control in a system similar
to a flowchart or a data flow diagram. Activity diagrams are often used in business process
modeling. They can also describe the steps in a use case diagram. Activities modeled can be
sequential and concurrent. In both cases an activity diagram will have a beginning (an initial
state) and an end (a final state).
46
Activity Diagram for Admin:
Figure 5: Admin Activity Diagram
47
Activity Diagram for Employee:
Figure 6: Employee Activity Diagram
48
6.2 Swim Lane Diagram
A swim lane diagram is a type of flowchart that delineates who does what in a
process. Using the metaphor of lanes in a pool, a swim lane diagram provides clarity and
accountability by placing process steps within the horizontal or vertical “swim lanes” of a
particular employee, work group or department. It shows connections, communication and
handoffs between these lanes, and it can serve to highlight waste, redundancy and
inefficiency in a process.
Swim Lane Diagram for Managing Products:
Figure 7: Swim Lane Diagram for Managing Products
49
Swim Lane Diagram for Managing Employee:
Figure 8: Swim Lane Diagram for Managing Employee
50
Swim lane Diagram for Order Management:
Figure 9: Swim lane Diagram for Order Management
51
6.3 Entity Relationship Diagram
An Entity Relationship (ER) Diagram is a type of flowchart that illustrates how “entities”
such as people, objects or concepts relate to each other within a system. ER Diagrams are
most often used to design or debug relational databases in the fields of software engineering,
business information systems, education and research. Also known as ERDs or ER Models,
they use a defined set of symbols such as rectangles, diamonds, ovals and connecting lines to
52
depict the interconnectedness of entities, relationships and their attributes. They mirror
grammatical structure, with entities as nouns and relationships as verbs.
Figure 10: Entity Relationship Diagram
53
6.4 Data Flow Diagram
A data-flow diagram (DFD) is a way of representing a flow of a data of a process or a system

(usually an information system) The DFD also provides information about the outputs and
inputs of each entity and the process itself. A data-flow diagram has no control flow, there are
no decision rules and no loops. Specific operations based on the data can be represented by
a flowchart.
Context Level Diagram:
A System Context Diagram (SCD) in software engineering and systems engineering is a

diagram that defines the boundary between the system, or part of a system, and its
environment, showing the entities that interact with it. Context level diagram of my system is
given below-
Figure 11: Context Level diagram
54
Level 1 Diagram:
The Level 1 DFD shows how the system is divided into sub-systems (processes), each of
which deals with one or more of the data flows to or from an external agent, and which
together provide all of the functionality of the system as a whole.
55
Figure 12: Level 1 Diagram
56
Level 2 DFD of Process 1 (Admin / Users Login):
Level 2 DFD of Process 2 (Manage Employee):

57
Level 2 DFD of Process 3 (Manage Category):
Figure
Figure17:
15:Level
Level 2 DFD
DFDofofProcess
Process3 6
Level 2 DFD of Process 4 (Manage Product):
59
Level 2 DFD of Process 6 (Manage Report):
60
Level 2 DFD of Process 8 (Manage Order):
61
6.5 Interface Design
Figure 25: Log in Page
Figure 26: Dashboard
Figure 27: Add Category Page
62
Figure 28: Add Company Page
Figure 29: View Company page
63
Figure 30: Product Add Page
Figure 31: Product View Page
64
Figure 32: Supplier Add Page
Figure 33: View Supplier Page
65
Figure 34: Customer Add Page
Figure 35: Customer View Page
66
Figure 36: Order Add Page
Figure 37: Order View Page
67
Figure 38: Requisition Add Page
Figure 39: Requisition View Page
68
Figure 40: Purchase Add Page
Figure 41: Purchase Details Page
69
Figure 42: Sold Product Details
Figure 43: Sales Product Page
70
Figure 44: Report Generation
6.6 Database Design
Figure 45: Company Table
71
FigureFigure
17: Level 2 DFD ofTable
46: Category Process 6
Figure 47: Product Table
72
Figure 48: Supplier Table
Figure 49: Customer Table
Figure 50: Customer Order Table
Figure 51: Purchase Table
73
Figure 52: Requisition Table

Figure 53: Sales Table
Figure 54: User Table
74
Chapter 7:System Quality &
Testing
77
Chapter 7 is representing the system testing, software testing strategy, system testing
methodology and testing design. In this chapter the detail system testing is discussed along
with the black box testing and white box testing.
7.1 System Testing
System testing is a method of monitoring and assessing the behavior of the complete and
fully-integrated software product or system, on the basis of pre-decided specifications and
functional requirements. It is a solution to the question "whether the complete system
functions in accordance to its pre-defined requirements?"
It's comes under black box testing i.e. only external working features of the software are
evaluated during this testing. It does not requires any internal knowledge of the coding,
programming, design, etc., and is completely based on users-perspective.
7.1.1 Reasons for Performing System Testing:
System testing is performed by professional or individual testers for various reasons. From
evaluating the system to ensuring
Figureits17:
compliance withofthe
Level 2 DFD specified
Process 6 requirements, this type of
testing offers great aid to the testing team as well as the other stakeholders of the project. Few
of the other reasons for performing this testing are:
 It ensure that the product meets the quality standards.
 Verifies that the software system meets the functional, technical and business
requirements requested by the customer/client.
 Performs end to end testing of the software product, which prevents system failures
and crashes during it implementation to the live environment.
 It is performed in an environment that is similar to the production environment, which
enables the developers as well as the concerned stakeholders to get an idea of the
user’s reaction to the product.
 It plays a significant role in delivering a quality product to the end users.
 It is during this stage of software testing life cycle (STLC) that the Application
Architecture and Business Requirements are tested.
 Ensures that the input provided to the system offers expected output/result [7]
78
7.1.2 Characteristics of System Testing:
A black box testing type, system testing is the first testing technique that carries out the task
of testing a software product as a whole. This System testing tests the integrated system and
validates whether it meets the specified requirements of the client. Other characteristics of
system testing are:
 In Software Development Life Cycle (SDLC), it is the first testing, that carries out the
task of testing the software or system, as a whole.
 Evaluates the functioning of the complete system, as per the pre-decided functional
requirement.
 Along with functional requirements, it also verifies and validates the business
requirements and software's architecture.
 Staging server may act as an environment, for carrying out the testing.
 A type of black-box testing.
 It may include, both functional and non-functional testing.
 Reduces the troubleshooting and maintenance issue, after deployment.
 Demands dedicated team
Figure
of 17: Level
testers, 2 DFD of Process
independent 6
of development team.
7.1.3 When to Perform System Testing
As stated earlier, software testing life cycle consists of various levels of testing, it’s crucial to
understand when, in STLC, is system testing is executed by the testers. Here are the scenarios
when a tester can perform system testing, either manually or with the assistance of testing
tools.
 After the completion of unit & integration testing.
 Before the beginning of acceptance testing
 On complete integration of modules.
 On the completion of software development process, based on software requirement
specification (SRS).
 On the availability of test environment.
79
7.1.4 Key Areas of System Testing:
Some of the aspects, on which system testing focuses are

Performance: It makes sure that the software system performs as per requirements of the
user, without depicting any defects or issues.
Security: Protects the product from any security breaches, data theft, etc., which can sacrifice
critical data & information of the organization.
Recovery: Ensures that the recovery of the system is as per expectations and in an accurate
condition.
Interface: System testing also focuses on the interface of the product and ensure that all
requirements are met accurately and no issues occur when two components of the system are
integrated together.
Install-ability: Here, the focus of system testing is to make sure that the product installed and
implemented to the production environment without any difficulty and issue.
Usability: This is another important aspect that is covered by system testing. It ensures
optimum user experience of the system.
Documentation: The accuracy of the document is also tested and monitored by this type of
testing.
Load/Stress: System testing also makes sure that the system performs and functions
accurately under different and extreme load and stress.
7.2 System Testing Methodology
A software product is termed ready only after going through various stages of software
testing. From its internal structure and code to its basic features, functionality, performance,
and more, every major and minor component of the software is tested to guarantee its quality
as well as its effectiveness. There are different methods for system testing. Among them
black box testing and white box testing are used more.
80
Figure 55: System testing methodology
7.2.1 Black Box Testing
Black box testing is a software testing type, wherein the testers have no knowledge of the
internal structure, design, and code of the software. The sole focus during this type of testing
is to test the functionality of the 17:
Figure software
Level and ensure
2 DFD its conformance
of Process 6 with the specified
requirements. It is because of this reason that black box testing is also known as specification
based testing.
Moreover, black box testing gets its name from the concept of a black/opaque box, through
which one cannot decipher the internal contents of the box and can only visualize and
examine its external appearance and structure. In short, black box testing is used to verify and
validate the correct and smooth functioning of the intended functionalities without digging
and evaluating the internal structure of the system. [8]
7.2.1.1 Features of Black Box Testing:
Black box testing is amongst the most important software testing techniques that is performed
by the professional software testers. To signify this importance of black box testing, here are
some of its features:
 It is a type of functional testing.
 Black box testing is performed by an independent testing team during software test
life cycle.
 In this type of testing, software tester do not have in-depth programming knowledge.
81
 Here, only valid and invalid inputs are provided to get the desired and expected
outputs.
 Testers thoroughly compare the actual output with the expected output, which further
helps in reducing the number of defects in the functionality of the system.
 It is strongly related to agile methodology.
 Tests are performed from the user’s point of view.
7.2.1.2 Levels where Black Box Testing is applicable:
Unlike white box testing, which is limited to only few levels of software testing, black box
testing can be executed during each level of software testing to get accurate as well as
expected results. These levels are:
Unit Testing: During this stage of testing, the method of black box testing is used to evaluate
the interface of the software as well as the specifications offered by the client before the
commencement of the project.
Integration Testing: In integration testing, the aim of testing is to determine the issues and
errors in the interface and interactions among the integrated components of the software.
System Testing: Knowledge of inner design and code of the software is redundant in this
testing, as it evaluates the system’s compliance with the requirements specified by the client.
Acceptance Testing: The aim of testing here is to validate the acceptability of the software
by testing it in various unprecedented and unanticipated situations and circumstances.
7.2.1.3 Advantages of Black Box Testing.
The process of black box testing offers testers as well as end users numerous advantages. It
helps assess and verify the quality and functionality of the software, while maintaining its
effectiveness, reliability, and more. Few of the other benefits/advantages imparted by black
box testing are:
 Black Box testing enables smooth implementation of an application in its original
system environment.
 Fits perfectly with functional testing.
 A full knowledge of functional specifications enables a fairly quick designing of test
cases.
82
 As BBT employs a methodology, in which there is no prior knowledge of internal
structure/code, it is well suited to simulate a cyber-warfare attack, while devising
security applications.
 It does not require knowledge of programming languages as well as system
implementation.
 This is an unbiased and unprejudiced testing, as the designer and testers work
independently in isolation.
 It can be easily performed by non-technical testers, developers, as well as end users.
 Helps identify any ambiguities, vagueness, and contradictions in functional
specifications.
7.2.1.4 Disadvantages Black Box Testing.
Every object or process, whether simple or complex, has a negative side, which impacts its
efficiency as well as working. Likewise, there are few drawbacks attached to black box
testing, which hinder thorough testing of the software and prohibit it from working
exponentially. These disadvantages/drawbacks are:
 Working with a huge Sample space of test inputs can be exhaustive and put a drain on
time.
 Besides, the probability of meeting dead ends in an unspecified path during testing is
pretty high.
 It tests only a small portion of the software, as testing the software thoroughly can be
time consuming.
 Because of black box testing dependency on specifications, it is difficult to design test
cases without well defined, precise, as well as concise specifications.
 Tests in black box testing can be termed redundant if they are already executed by the
software developer or designer.
 Results offered by black box testing can often be overestimated.
 It cannot be used for testing complex codes and software.
7.2.2 White Box Testing
The term ‘White Box’ is used to refer to a transparent or glass box, through which the
internal structure of a product is visible, and which allows the team to analyze, evaluate as
well as explore the workings of an application’s internal structure. White box testing, which
83
also known as glass box testing, tests the internal structure of an application product through
the derivation of test data from the program logic. This type of software testing technique is
also known by other names, such as open box testing, structural testing, logic driven
testing and clear box testing.
7.2.2.1 Features of white box testing:
An integral part of software testing life cycle (STLC), white box testing is a method of testing
a software or application, wherein the test manager evaluates the internal structure, code, as
well as the workings of the software. It ensures that no hidden errors impact the effectiveness
and the functioning of the product, by thoroughly testing its code and other internal aspects.
In short, white box testing guarantees an error free environment by validating and testing
fragile or defect prone codes.
Few of the other important features of white box testing are:
 It is used by both, software testers and developers to validate the quality of a software
product’s internal structure.
 Helps the team determine the line of codes that are executed.
 It can be applied to Figure
various17: Levellevels,
testing 2 DFDlike
of Process 6
unit testing, integration testing, and
regression testing.
 Validates the quality as well as the accuracy of the testing data.
7.2.2.2 Levels where white box testing is applicable:
As stated above, white box testing can be executed during various software testing phases to
validate the effectiveness of the internal structure as well as to ensure the accuracy of the
written code. The three major testing stages, where white box testing is applicable are:
Unit Testing: During unit testing, white box testing tests the code to validate that it is
working as intended and is free of any defects or issues. Moreover, it detects the defects
before the code is integrated with already tested code, which further prevents any defects
from occurring in later stages of testing. White box testing in unit testing is performed in
isolation.
Integration Testing: In Integration testing, the interaction between interfaces is tested with
the assistance of white box testing. Performed in an open environment, here white box testing
ensures the correctness as well as the accuracy of the interfaces.
84
Regression Testing: At this stage of software testing, the white box test cases created during
the earlier two stages are recycled and tested again.
7.2.2.3 Advantages of White Box Testing:
 While box testing has edge over black box testing in revelation of hidden errors in the
code.
 White box testing is fairly easy to automate, allowing reduction in testing time.
 Helps spot dead codes in accordance with prevalent testing practices.
 White box testing enables easy traceability of the tests right up to the source level.
This way any future changes in software to be congruently captured for changes in the
tests.
 The white box testing can be commenced at an earlier stage of software development
life cycle (SDLC).
 This type of testing is more thorough and covers most paths and codes of the
software.
7.2.2.4 Disadvantages of White Box testing:
 Not possible to cover every possible condition for testing.

 Since this testing approach requires a thorough understanding of the software, the
testing effort requires the services of a tester having ace programming skills.
 It is time consuming, complex, as well as expensive. [9]
7.3 Testing Design
Table XVIII: Testing Scenario No 1
Scenario Admin, Employee Login testing

Input’s Email, password of admin, employee for login
Desired When valid email, password will be entered then get access to the
Output’s system otherwise not.
Actual Output’s For valid email, password, user gets access to the system.
Desired Output and Actual Output indicate that the system login works
Verdict
properly.
85
Table XIX: Testing Scenario No 2
Scenario Admin can add employee, supplier, customer, product, category,
company
Input’s Details information of Employee, supplier, customer, product, category,
company.
Desired When all basic information will be entered correctly; employee,
Output’s supplier, customer, product, category, company details will be stored
into the database and will be displayed in the system.
Actual Output’s When all basic information are entered correctly; employee, supplier,
customer, product, category, company details are inserted into the
database successfully and are displayed in the system.
Verdict Desired Output and Actual Output indicate that the system works
properly.
Table XX: Testing Scenario No 3
Scenario Admin can

Figure
edit 17:
andLevel
delete2employee,
DFD of Process
supplier,
6 customer, product,
category, company details.
Input’s Details information of employee, supplier, customer, product, category,
company which need to be updated and deleted.
Desired When the basic information for updating the employee, supplier,
Output’s customer, product, category, company will be provided correctly by the
admin, updated information of employee, supplier, customer, product,
category, company will be displayed. For deleting any record,
confirmation will be needed.
Actual Output’s For valid information, employee, supplier, customer, product, category,
company details are updated successfully. For deleting any record, a
confirmation message is displayed, if the ok button is pressed the record
is deleted successfully.
properly.
86
Table XXI: Testing Scenario No 4
Scenario Employee can add product.
Input’s Details information of product.
Desired When all basic info will be entered correctly, will be stored in the
Output’s database and display product details in the system.
Actual Output’s For valid information, product details are inserted into database
successfully and displayed in the system.
properly.
Table XXII: Testing Scenario No 5
Scenario Employee can create a requisition to the admin for new product and
after the approval go for purchase.
Input’s Details information of requisition.
Desired For valid information, requisition details will be stored into the database
Output’s and afterFigure 17: of
approval Level 2 DFD
admin, will of
goProcess 6
for purchase.
Actual Output’s For valid information requisition is stored successfully and after
approval of the admin, employee can go for purchase
properly.
Table XXIII: Testing Scenario No 6
Scenario Admin can create, edit and delete the customer order.
Input’s Details information for order creating, updating, deleting.
Desired For valid information, order details will be stored and updated into the
Output’s database, the order details will be displayed in the system. For deleting
any record, confirmation will be needed.
Actual Output’s For valid information, order details are inserted and updated
successfully. For deleting any record, a confirmation message is
displayed, if the ok button is pressed the record is deleted successfully.
properly.
87
Table XXIV: Testing Scenario No 7
Scenario Employee can create order.
Input’s Details information for order creating.
Desired For valid information, order details will be stored into the database, the
Output’s order details will be displayed in the system
Actual Output’s For valid information, order details are stored into the database, the
order details are displayed in the system
properly.
Table XXV: Testing Scenario No 8
Scenario Admin can manage purchase.

Input’s Details information of purchase.
Desired For valid information, purchase details will be stored and updated into
Output’s the database and display in the system. . For deleting any record,
confirmation will
Figure 17:beLevel
needed.
2 DFD of Process 6
Actual Output’s For valid information, purchase details are stored and updated into the
database and display in the system. . For deleting any record,
confirmation will be needed.
properly.
88
Chapter 8:Conclusion
89
8.1 Conclusion
As now it’s a technological era, most of the organizations use computerized system for
business purpose. Inventory and Point of Sale Management System is a software that’s used
for tracking inventory levels, orders, sales and deliveries. Inventory or stock is the goods and
materials that a business holds for the ultimate goal of sale. The Inventory and Point of Sale
Management System for Caveman international Ltd. is developed using PHP and MySQL
meets the objectives of the system for which it has been developed. The system has reached a
steady state where all bugs have been eliminated. The system is operated at high level of
efficiency and all the employee and admin associated with the system understands its
advantage.
This Web Application provides facility to manage inventory system. The system keeps many
types of information like products information and their category, customer information,
vendor’s information and their contact details, Supplier Company and products etc. It saves
time as it allow to handle the product, customer, sales, and order in a computerized system.
8.2 Limitation of the project

The customer and supplier has no access to the system. So they can’t get any update of the
inventory or sales.
8.3 Future Scope
In future the system will be modified so that

 Customer can access the system, view the inventory items, create own order, update
the order.
 Supplier can access the system. When any requisition is approved, supplier can get
the requisition, and see the purchase status for the requisition.
90
References
1. https://research-methodology.net/research-methods/data-collection/
2. https://www.toolsqa.com/software-testing/waterfall-model/
3. https://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm
4. https://www.unitechbdsoft.com/
5. https://www.geeksforgeeks.org/software-engineering-requirements-engineering-
process/
6. https://www.docsity.com/en/risk-and-change-management-risk-management-
concepts-software-project-management-lecture-notes/169982/
7. http://www.professionalqa.com/system-testing
8. http://www.professionalqa.com/black-box-testing
9. http://www.professionalqa.com/white-box-testing
91

Development of Inventory and Point of Sale Management System For Caveman Int LTD

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Development of Inventory and Point of Sale Management System For Caveman Int LTD

Caricato da

Copyright:

Formati disponibili

Development of Inventory and Point of Sale

Management System for Caveman Int Ltd.

A practicum report submitted in partial fulfillment of the requirements

Figure 17: Level 2 DFD of Process 6

Department of Computer Science and Engineering

Md. Tayeb Adnan

The practicum has been examined and approved,

Prof Dr Md Abdul Haque

Prof Dr. Utpal Kanti Das

M.M Rakibul Hasan

Department of Computer Science and Engineering

On behalf of the Department of Computer Science and Engineering of International University of

M.M Rakibul Hasan

Prof. Dr. Utpal Kanti Das

Prof. Dr. Md. Abdul Haque

Subject: Letter of Transmittal.

It was undoubtedly a splendid opportunity for me to work on this project to actualize my

Subject: Letter of Authorization.

Dear Md. Tayeb Adnan,

For any kind of assistance don’t hesitate to contact with us.

Co- Supervisor Practicum Supervisor

Prof. Dr. Utpal Kanti Das M.M Rakibul Hasan

M.M Rakibul Hasan

-----------------------------------Figure 17: Level 2 DFD of Process 6

Figure 17: Level 2 DFD of Process 6

Figure 17: Level 2 DFD of Process 6

1.4 System benefits

1.5 Methodology and Data Collection

1.5.2 Secondary Data

1.6 Feasibility Study

1.6.1 Technical Feasibility

1.6.3 Operational Feasibility

1.7 Software Process Model

Figure 1: Incremental Process Model

1.7.2 Phases of Incremental Model in Software Engineering

Some of the major advantages of the Incremental Model are as follows −

1.7.4 Disadvantages of Incremental process model

The major disadvantages of the Incremental Model are as follows −

2.1 Organization Overview

CAVEMAN INTERNATIONAL LTD. (CIL) is a professional Website & Software

The services UBSL offers

 TLD Domain Registration

3.1 Requirement Engineering

Requirement engineering refers to the process of defining, documenting and maintaining

 User RequirementsFigure 17: Level 2 DFD of Process 6

3.1.1 User Requirements

The system has two user types: admin, employee.

3.1.2 System Requirements

 Admin can login and logout in the system.

 Admin can manage requisition.

 Admin can manage sale.

3.1.3 Functional Requirements

3.1.4 Non-Functional Requirements

 System will need all username and password to store in database.

3.1.5 Specification of Each Requirement

Function: Log in, add information

3.1.5.2 Employee Specification

Function: Log in, add information, manage sale.

Figure 17: Level 2 DFD of Process 6

Figure 2: Use Case Diagram

Chapter 4:System Planning

4.1 Functions of Proposed System

1. Login into the System [F01]