You are on page 1of 50

GREAT ZIMBABWE UNIVERSITY

MUNHUMUTAPA SCHOOL OF COMMERCE


DEPARTMENT OF ACCOUNTING AND INFORMATION SYSTEMS

MANZINI TAKAVINGOFA
M141885
MANZLEE RETAIL MANAGEMENT SYSTEM

This project was submitted in partial fulfilment of the requirements of the


bachelor of commerce honours degree in Information Systems

24 MAY 2016

1|Page
Declaration
I, MANZINI TAKAVINGOFA declare that this project is the original work specifically
undertaken by me for the fulfilment of the BACHELOR OF COMMERCE HONOURS
DEGREE IN INFORMATION SYSTEMS (LEVEL 2.2) and all references are
acknowledged.

Student......................................................

Signature………………….......................

Date………………......

Supervisor............................................

Signature……………...........................

Date…......……………

2|Page
ACKNOELEDGEMENTS

First of all, I want to thank God for all I have. I want to thank my lecturers who taught me all
about information system and it motivated me to take a step further on the subject. I want to
thank my colleagues who motivated me to give it my best in developing this system.

Contents
APPROVAL FORM .............................................................................. Error! Bookmark not defined.
1.0 CHAPTER 1: INTRODUCTION ......................................................................................................... 5
1.1 BACKGROUND INFORMATION ...................................................................................................... 5
1.2 PROBLEM DEFINITION................................................................................................................... 5
1.3 AIM OF THE SYSTEM ..................................................................................................................... 6
1.4 OBJECTIVES ................................................................................................................................... 6
1.5 SCOPE ............................................................................................................................................ 7
1.6 Design tools ................................................................................................................................... 7
1.8 Justification ................................................................................................................................... 8
1.9 Conclusion ..................................................................................................................................... 8
Chapter 2: THE PLANNING PHASE..................................................................................................... 9
2.1 WHY THIS SYSTEM ........................................................................................................................ 9
2.2 FEASIBILITY STUDY ........................................................................................................................ 9

3|Page
2.3 DEVELOPING A WOK PLAN.......................................................................................................... 13
2.4 GANTT CHART OF THE RETAIL MANAGEMENT SYSTEM ............................................................. 13
CHAPTER 3: ANALYSIS ....................................................................................................................... 14
3.1 INFORMATION GATHERING METHODOLOGIES .......................................................................... 14
3.2 ANALYSIS OF EXISTING SYSTEM ............................................................................................ 15
3.2.1 THE DISCRIPTION OF THE CURENT SYSTEM ...................................................................... 15
3.2 PROCESS ANALYSIS...................................................................................................................... 15
3.2.1 ACTIVITY DIAGRAM OF THE SYSTEM ....................................................................................... 15
3.3 DATA ANALYSIS ........................................................................................................................... 16
3.5 ALTERNATIVES EVALUATION ...................................................................................................... 19
3.5.1 Conclusions and expectations.................................................................................................. 21
3.6 REQUIREMENTS ANALYSIS .......................................................................................................... 21
3.7 CONCLUSION ............................................................................................................................... 24
CHAPTER 4: DESIGN .......................................................................................................................... 25
4.0 Introduction ................................................................................................................................. 25
4.1 SYSTEM DESIGN .......................................................................................................................... 25
4.2 Architecture Design .................................................................................................................. 26
4.3 Physical Design .......................................................................................................................... 27
4.4 DATABASE DESIGN ...................................................................................................................... 28
4.4.2 EER [ENHENCED- ENTITY RELATION DIAGRAM] ...................................................................... 30
4.5 PROGRAM DESIGN ...................................................................................................................... 30
CLASS DIAGRAM OF THE SYSTEM ..................................................................................................... 30
THE SEQUENCE DIAGRAM OF THE SYSTEM ...................................................................................... 31
4.6 INTERFACE DESIGN ..................................................................................................................... 32
4.7 CONCLUSION ............................................................................................................................... 36
5.0 CHAPTER 5: IMPLEMENTATION .................................................................................................. 36
5.1 INTRODUCTION ........................................................................................................................... 36
5.2 CODING ....................................................................................................................................... 36
5.3 SYSTEM TESTING ......................................................................................................................... 39
5.3.1 Unit testing .............................................................................................................................. 39
5.3.2 Module Testing ............................................................................................................. 40
5.3.3 Acceptance testing ................................................................................................................... 40
5.4 Test strategies ............................................................................................................................. 41
5.5. Verification ................................................................................................................................. 41
5.6 Validation .................................................................................................................................... 41
5.7 Verification .................................................................................................................................. 42

4|Page
5.7.1 System Security Testing .................................................................................................... 42
5.8 Installation .................................................................................................................................. 43
5.8.1 Hardware installation............................................................................................................... 43
5.8.2 User training............................................................................................................................. 44
5.9 File conversion ............................................................................................................................ 44
5.9.1 Advantages of parallel conversion ........................................................................................... 44
5.9.2 CONCLUSION ........................................................................................................................... 45
6.0 CHAPTER 6: MAINTAINANCE ..................................................................................................... 45
6.1 USER MANUAL ............................................................................................................................ 45
7.0 APPENDIX .................................................................................................................................... 48
7.1 BIBLIOGRAPHY ............................................................................................................................ 50
REFERENCES ..................................................................................................................................... 50

1.0 CHAPTER 1: INTRODUCTION


1.1 BACKGROUND INFORMATION

Manzlee is a new small retail in the suburbs of Masvingo city which sales groceries,
domestic utensils, and butchery. Retail is the process of selling consumer goods and/or
services to customers through multiple channels of distribution to earn a profit.

The retail wants to open a large scale branch in the city so, they require a computer based
system to manage the retail.

1.2 PROBLEM DEFINITION


 Difficulties in controlling sales and purchases.

5|Page
Tracking the sales of the day would be cumbersome with the absence of a computer
based management. Even the purchases of new orders would take hours recording
and pricing.

 Low productivity and production cost are inefficiently high.

Evaluating the sales per week or per month is difficult, thus low productivity and
cost a lot of time to process the accounting information given that it is needed.

 Slow vending processes.

Due to the increased number of customers, the vending process would be slow due
to the need to record every sale in a book.

 Books are being used for records.

These produce redundancy, since the sales records would be repeatedly recorded in
a book. As such books have no backing up of data

 Pilferages and breakages are hard to control at the moment


The stock is difficult to track even if breakages occur they might not be noticed and
this causes pilferages or theft.

1.3 AIM OF THE SYSTEM


 TO MANAGE THE DAY TO DAY BUSINESS OPERATIONS OF THE MANZLEE
RETAIL.

1.4 OBJECTIVES
THE SYSTEM SHOULD BE ABLE TO:

1. Bill the new stock ordered.


2. Track the stock.
3. Bill the customer’s orders.
4. Display the recorded total sales per week to process sales graphs.

6|Page
1.5 SCOPE
The project has these following capabilities:
 Setting the rates and taxes on the stock price and product information
including the expiry date.
 Searching, displaying details, adding, and editing the stock records stored in
the database
 Showing the price of ordered items, and accounting for the currency of the
money paid and calculate the change.
 Show the sales graph and the weeks’ profit.
 Report a bug.
 Update.
 Manage the cash counter.
 Invoice printing.
 Vendor management.
 Inventory tracking.
 Bar code generation.

The database can only be accessed by the administrator so it will be password


protected and only the administrator can add the product information.

The system might not be a complete end-user application, but for all intense
purposes it could be.

1.6 Design tools

Microsoft Visual studio 2015 will be the development software I will use.

The coding language will be Visual C# , SQL.

The Microsoft Access or SQL SERVER will be used for the database.

7|Page
StarUml or smart draw OR EDRAW or Visio 2007 OR HIGHER are software to use for UML
diagrams.

Microsoft word will be used for documentation.

1.8 Justification
The system will:

 Save managers’ time –the system analyze the data and information from sales
process and presents all information through tables, charts, or graphs.
 Sales management has a better control throughout the system since the system
will send out all the all the updates, order information, product knowledge.
 The system can setup to statistical representation for:
1. The sales manager
2. The market research results.
3. Other departments.
In conclusion productivity, profits can be increased and as well as
reducing production cost.

1.9 Conclusion
The Manzlee Retail Management System is a management information system which
can also be used by other retails also. This system will be an absolute solution for any
retail since it covers all main system requirements any retail has.

Since one of the main goals of any retail is to make profit, the computer based system
will make that happen without any complex setups like preparing books and so on. As
such, the system will be of supreme importance in the Manzlee Retail day to day
business since other departments can rely on it.

8|Page
Chapter 2: THE PLANNING PHASE
2.1 WHY THIS SYSTEM
 BUSINESS VALUE
The system is required because there is need to increase efficiency.
There is need to improve decision making for a change and development.
The management’s view is to strategically improve services i.e. customer flexibility
for bulk buying.
This would enable the retail to cope up with the competitive environment.

2.2 FEASIBILITY STUDY


 TECHNICAL FEASIBILITY
The resources required to work with the system are already available.

9|Page
The I.T. department is already available for support and troubleshooting and they
are well skilled.
The database handling should be simple and clear as well as the graphical user
interface. It would be easy to maintain.
There is room for expansion of the system to cater for payroll and other operations.
The required computers should have at least 1 gigabyte of RAM, more than 1.6
gigahertz processor speed, and more than 10 gigabyte free memory.
Bar code reader would be required also as secondary resource. A cash drawer is
required also and a receipt printer
In Conclusion
It is not much of a problem for the retail to acquire even better platform than the
one noted above, that is, it is feasible technically for the system to be operated on
the platform yet to be acquired available.

 ECONOMIC FEASIBILITY
The projected benefits will outweigh the costs of maintenance and support
since the system will enable the full potential of the retail.

Cost Benefit Analysis Projection


COST BENEFIT ANALYSIS

[k==1000]

YEAR 2015 MID 2016 2016

BENEFITS USD(K) USD(K) USD(K)

ESTIMATED CASH 12.00 13.00 14.00


INFLOWS

REDUCED PAPERWORK 4.00 4.00 5.50

REDUCED LABOUR 5.00 6.00 6.50


COSTS

TOTAL 21.00 23.00 26.00

OPERATIONAL COSTS:
USD(K) 2015 USD(K)MID 2O16 USD(K)2016

10 | P a g e
STATIONERY AND COMPUTER 3.00 5.00 4.00
CONSUMABLES

HARDWARE MATAINANCE 2.00 3.00 4.50

SOFTWARE MANTAINANCE 1.00 3.00 3.50

TOTAL 6.00 11.00 12.00

DEVELOPMENT COSTS:
USD(K)2015 USD(K)MID 2016 USD(K)2016

NEW HARDWARE 2.00 0 0

SOFTWARE LICENSING 2.00 0 0

USER TRAINING 3.00 0 0

LABOUR 1.00 0 0

TOTAL 8.00 0 0

TOTAL COSTS 14.00 11.00 0

NET BENEFITS/LOSS 10.00 12.00 14.00

Return on investments
Return on investments measures the profitability to the project by comparing net monetary benefits to
its net monetary costs.
Year 2015
ROI = (total benefits –total costs)/total costs *100
$ (21.00 -14.00 ) * 100 %
$14.00
50 %
Mid Year 2015
ROI = (total benefits –total costs)/total costs *100
$ (23.00 -11.00 ) * 100 %
$11.00
109 %
Year 2016
ROI = (total benefits –total costs)/total costs *100
$ (26.00-12.00 ) * 100 %
$12.00

11 | P a g e
116.67 %
After calculating the ROI that is the return on investment, it has been realised that it starts with a
return of 50 % and increases to 116.67% in two years time..
The rise in the return on Investments from the first year shows that it is economically feasible to
embark on the project

Tangible costs would be money, and the benefits are speed, better inventory
management.

Intangible benefits would be job satisfaction of employees and better


marketing decisions.
To further illustrate the feasibility consider the following:
NET PRESENT VALUE
The present investment is $1 600 and the interest rate is at 5% the net
present value will be:
The present value is at -$1 600;
Money in $1 700 next year is:
$1 700/ (1+0.05)1 =1 700/1.05
=$1619.05
The net present value:
1619.05-1600=19.05
In conclusion
The retail management system is much feasible economically as shown by
the cost-benefit analysis above. The benefits outweighs the costs.
 OPERATIONAL FEASIBILITY
The system will be designed using graphical user interface for it to be user
friendly as they required it to be. All requirements would have to be satisfied
and tests are to be conducted with a given operational conditions upon the
willingness of the management to support the systems development.
Training will be required before the actual intend.
User involvement will enable the system to be successfully operational.
The system will cause diverse changes to customer services.

12 | P a g e
Legal and ethical issues are seriously considered since the system ensures the
secure of money.
In conclusion
There is no fear or doubt among the top management which means the
system will be successful and operational as soon as possible.

 ORGANISATIONAL FEASIBILITY
The legal and corporate structure are to be well defined in the system proposed.
An IT department with skilled personnel are required for troubleshooting and
maintenance. The management would have to rely on the system to make
effective decisions.
The system will give a sense of progress in their operations.
In conclusion
The organizational feasibility on the system is possible.
Overall conclusion
The feasibility study show that the system’s success probability is high and the
system will be a strategic tool for the retail.

2.3 DEVELOPING A WOK PLAN


 WORK SCHEDULE
The schedule includes estimated values of time, and the numbers are the
order in which each activity is to be finished:

2.4 GANTT CHART OF THE RETAIL MANAGEMENT SYSTEM

13 | P a g e
Title

Dec 2015 Jan 2016 Feb 2016 Mar 2016


ID Task Name Start Finish Duration
3-1 7-2 6-3

1 Problem id and proposal 2015-11-23 2015-11-30 6d

2 Planning. 2015-11-30 2015-12-31 24d


3 Analysis. 2016-01-01 2016-01-22 16d
4 Design. 2016-01-22 2016-02-02 8d
5 Implementation. 2016-01-26 2016-03-25 44d
6 Maintenance manual. 2016-03-25 2016-03-31 5d

February 29, 2016 Page 1

CHAPTER 3: ANALYSIS
3.1 INFORMATION GATHERING METHODOLOGIES
A) OBSERVATIONS

Examining the operation of a system on a particular day appointed.

 This technique proves reliability of data collected


 It would be easy to understand complex tasks of a system
 It is usually cheap

B) JAD SESSIONS

Users participate in the systems development process.

14 | P a g e
 It make the users to feel a sense of ownership in the results and support for the
new system
 When properly used, it can result in a more accurate statement of systems
requirements and a stronger commitment to the success of the new system

3.2 ANALYSIS OF EXISTING SYSTEM


3.2.1 THE DISCRIPTION OF THE CURENT SYSTEM
The retail management system is used as a point of sale and record storage of all the
Manzlee retail’s day to day operations. The administrator only is allowed to record and bill
the all the purchased goods, employee details and modify the prices with the aid of a
database functions. The goods are arranged in categories in the database.

When a customer wants to buy goods, the till operator enter product number and the price
of the item will show up then the customer pays the amount required. If there is need for
change after confirmed payment, it will be show on the system interface. The receipt will be
printed for all the vending. The sales details are saved to the database per transaction.

For all the transaction which are done, the system warns if a certain level of stock is
reached. The items are searched in the database in the event of availability.

3.2 PROCESS ANALYSIS


3.2.1 ACTIVITY DIAGRAM OF THE SYSTEM

15 | P a g e
LOGIN

YES IS IT VALID

PURCHASE ITEMS

BILL ITEMS
NO

ENTER EMPLOYEES DETAILS

BILL CUSTOMER

RECEIVE PAYMENT

GIVE RECEIPT AND CHANGE CHECK AVAILABILITY

NO AVAILABLE? YES

3.3 DATA ANALYSIS


 CONTEXT DIAGRAM OF MANZLEE RETAIL SYSTEM

16 | P a g e
ENTER CATEGORY
ADMINISTRATOR SHOW DATABASE

PURCHASE DETAILS

PASSWORD

BILL NEW ITEMS 1 PRICE CUSTOMER


EMPLOYEE DETAILS
PAYMENT
SALES REPORTS
THE RETAIL
GIVE ITEM AND RECEIPT
MANAGEMENT SYSTEM
SALE ITEM
DETAILS
PRICE

TILL OPERATER

 THE DATAFLOW DIAGRAM OF THE SYSTEM

17 | P a g e
PROFILE DETAILS
ADMNINISTRATOR EMPLOYEE DETAILS

PASSWORD

ACCESS
1 2 7

PURCHASE LOGIN ADD EMPLOYEES VIEW EMPLOYEES


DETAILS

PROFILE INFORMATION
ITEM
DETAILS
D1
EMPLOYEES PROFILE DETAILS
3

ADD PURCHASE 8
ITEM AND SUPPLIER
DETAILS DETAILS VIEW PURCHASES
PURCHASE INFROMATION PURCHASE DETAILS
AND SUPPLIERS

CATEGORY PURCHASE
NAME AND INFORMATION
NUMBER
ADMNINISTRATOR
4 PURCHASES AND
D2

SUPPLIERS STOCK DETAILS


9
ADD NEW ITEM TO
STOCK
STOCK DETAILS VIEW STOCK
SALES REPORT
ITEM
INFORMATION
D3

PRODUCT STOCK
5
UPDATE TILL OPERATOR
DETAILS 10
UPDATE ITEMS
SALES VIEW SALES
REPORT REPORT
CATEGORY
D4

SALES
INFORMATION

ITEM NUMBER

ITEM
6 PRICE CUSTOMER
11
ITEM DETAILS
SALES
ADD CATEGORY DETAILS SALE ITEMS

PAYMENT

12
TRANSACTION
DETAILS
PRINT RECEIPT
18 | P a g e
3.4 WEAKNESSES OF THE CURRENT SYSTEM

The system does not support touchscreen computers given that the competitors possess such
technology.

The system would not allow payment through debit cards and master cards.

The systems database alone cannot contain all the records of the store so the paper work is
used to some extend like purchase invoice payments.

3.5 ALTERNATIVES EVALUATION


 OUTSOUCING

Advantages.

 Outsourcing provides quick implementation of the system since it comes as a


complete package. This saves time since the project needs to be delivered to
the users immediately.

 Users have adequate time to understand the functionality of the system since they
can be trained to familiarize with the system before installed.

 Outsourcing is very cheap as compared to developing the system within the


organization since no expensive budget for systems analysts, database designers
and programmers is required.

Disadvantages.

 Lack of independence for future adjustments and developments resulting in


the system being user unfriendly, expansion restriction and inflexible.

 Software vendors can be very expensive leading to the straining of


Organization’s budget.

 Purchasing of new hardware that has compatibility with the outsourced


software will be done and it is very costly to the organization.

 Installation of new software requires specialists, which is expensive.

 IMPROVEMENT

19 | P a g e
The functionalities of the current system will be improved so as to incorporate them
on the existing resources available.

Advantages

 Purchasing of new hardware and software is not involved hence very cheap.

 Involvement of staff using the system during improvements enables the staff
to familiarize with the system operations and functionality.

 Improvements also help the organization to understand the current system


operations so that when later there is a need for the system to be computerized,
problems involved will be truly identified.

Disadvantages

 Upgrading the existing system does not make the system more effective since
the problems with the system will remain a challenge.

 More time is needed in locating a record hence this makes the system
inefficient.

 Upgrading the existing system does not make the system more effective and
efficient since the problems with the system will remain a challenge.

 DEVELOPMENT

It is a very convenient method of developing a system since it is developed within the


organization. The organization will be in total control of development of the system. In house
development produces a flexible, effective and efficient system that meets the requirements
of the organization. Flexibility means the organization will be able to change the functionality
of the system at any time to suit the present requirements or changes

Advantages

 It meets the organization’s long term goals and objectives since they are directly
working with the system.

 The system will have the ability to be flexible in today’s changing technology.

20 | P a g e
 It will be easier to develop in-house because the organization can negotiate salaries
paid to the developer hence this allows resources not to be wasted.

Disadvantages

 It is time consuming since all other business activities may be left unattended to or
at halt when the whole management team will be concentrating and participating
on the contribution of how the new system will be working.

 There is need for experienced personnel in order for the system to be efficient and
meet the organization objectives.

 It requires all individuals to work together so that the system will be fully
operational and on time both agreed by both parties.

3.5.1 Conclusions and expectations


 The developer is going to consider the in-house development as an alternative
amongst the other alternatives mentioned above. In-house development is very
convenient as it is flexible and can be adjusted at any time to meet the requirements
of the users.
 However, there are challenges associated with the in-house development. The
developer is very much inexperienced so there are fears that the system might not
meet the actual requirements of the client. The fears will be mitigated through the
use of the internet and help from the supervisor.

3.6 REQUIREMENTS ANALYSIS


 FUNCTIONAL REQUIREMENTS
THE USE CASE DIAGRAM FOR THE RETAIL MANAGEMENT SYSTEM

21 | P a g e
USE CASE DIAGRAM FOR RETAIL MANAGEMENT SYSTEM

LOGIN

ADD PURCHASED ITEM

ADMINISTRATOR

ADD STOCK

ADD EMPLOYEE

CHECK
VIEW DATABASE
INVENTIRY
>
E>
UD
L
INC
<<

TILL OPERATOR
CHECKOUT

<< i
ncl
ud
e>>

CALCULATE PRICE
CUSTOMER
PAYMENT

<<include> CALCULATE
>
CHANGE
22 | P a g e
 NON FUNCTIONAL REQUIREMENTS

These are the qualities that a software system should possess. They are needed to improve
the system performance. Non-functional requirements are mostly the same for all the
projects.

User interface and human factors

The system should allow quick and flexible means of entering information for processing and
graphic user interface (GUI) based on Windows architecture should be employed. The system
must be easy to use so as to reduce the cost for errors that might be produced.
The system must also:-

 Be simple.
 Be self-explanatory.
 Be user friendly.

Error handling

 The system should have error handling for:


 Data entry/capture
 Data/ user details analysis

Security issues

The system must have a log on screen where a username and corresponding password are
entered.
 Password should be encrypted.
 Password should be long enough

System efficiency and throughput

The proposed system is supposed to:

 Allow for quick retrieval as well as availability of data whenever needed.


 To eliminate duplication of data.
 Should have readable user-interface and reports should be always available as soon as
data is entered into the system.

Technical constraints.

23 | P a g e
In the development of the system, the following may be encountered during the different
stages of development.

 Not enough manpower to concentrate on different modules of the system.


 The company will have to hire an IT personnel to maintain the system or they can
consult from the system developer for maintenance.

3.7 CONCLUSION
 In depth analysis of the current system was done. Information gathering tools such as
interviews, observation and questionnaires were used to understand the current system
and identify requirements. Context diagrams, and Dataflow diagrams were used to
analyse the processes of the current system. A use case diagram was used to
determine the system functional requirements of the proposed system. System
requirements and user requirements will be used to determine more detailed
specifications on the functionalities of the system and how the system operates. After
the analysis of the current system, the design stage of the proposed system is going to
be looked at in the next chapter.

24 | P a g e
CHAPTER 4: DESIGN
4.0 Introduction
The design phase entails how the proposed system is going to work. It gives an outline of the
physical design, the architecture design, interface design, database design and program design.
This phase will mainly dwell on the schematic layout and structure of the proposed system,
these shall comprise of the logical and physical layer of the system. The phase seeks to
anticipate the execution process of the system under development. It can be considered as dry
running of the system to be developed. This phase is mainly concerned with the design of input
and screen output interface for the system. Relationships between entities of the system and
the overall flow of information around the entire system are shown.

4.1 SYSTEM DESIGN


This phase should produce an effective, reliable and maintainable system possessing the
following characteristics
The following are features of a well-designed system:
 Effectiveness
 Reliability
 Maintainability
All these features should be present in the proposed Retail Management System.

 Effectiveness: A well-designed system should be easy to work with and result in some
benefit or reduction of costs. Whoever is going to use the system should be involved in
designing the system so that they can operate it in the most efficient and effective way.
The users should be able to find their way round the system comfortably.
 Reliability: A well-designed system should be reliable in that it would counter
problems encountered in the existing manual system. The online section should
adequately handle errors for example input, processing, hardware or human mistakes.
 Maintainability: The system must be easy to maintain, in cases were developments
need to made or new features need to added-on to the system. The need for
developments or added on features may arise as a result of changes in the external
information technology environment or changing business needs. System must flexibly
adapt to changes, making it easy for modifications and updates.

25 | P a g e
4.2 Architecture Design
The architectural design of a system emphasizes on the design of the systems
architecture which describes the structure, behaviour and more views of that system and
analysis.
A system architecture can comprise system components, the externally visible properties of
those components, the relationships (e.g. the behaviour) between them. It can provide a plan
from which products can be procured, and systems developed, that will work together to
implement the overall system.
Advantages of explicit architecture
Stakeholder communication

 Architecture may be used as a focus of discussion by system stakeholders.


System analysis

 Means that analysis of whether the system can meet its non-functional
requirements is possible.
Large-scale reuse

 The architecture may be reusable across a range of systems


 Product-line architectures may be developed.
The generic layered architecture

The objective is to minimize bottlenecks in the system caused by hardware, software and
architectural factors. The system should run on a reliable hardware platform and measures
should be taken to reduce vulnerability of the system to hardware/software related threats. The
developer also considered measures that should also be put in place to reduce the negative
effects of power cuts on the system and this involved installation of a UPS system.

26 | P a g e
4.3 Physical Design
The system is a stand-alone system, that is, it is offline. It works on a computer attached to
other components like a bar code reader, receipt printer and other useful components.
The system uses the keyboard instead of a bar code scanner for data input and the data is
validated.
The system saves data to a SQL-client server attached to the application. All POS will be
connected using Ethernet cables to the workstation and the data warehouse.
The server data will of course be backed up to a remote location. All the terminals will be
accessing the data in the server.

27 | P a g e
RMS Ethernet LAN Diagram

POS TERMINAL 1 POS TERMINAL 2 POS TERMINAL 3

Ethernet (222,22,0,2)

10.22.59.09

MANAGER WORK STATION


Router - Firewall Department Server

Internet

4.4 DATABASE DESIGN


The system’s database design will be confided with the SQL server engine. The data stored
through the terminals or the managers’ workstation will be stored following the procedures
shown in the diagrams below.
THE ER [ENTITY RELATION] DIAGRAM

28 | P a g e
M N
PRODUCT SOLD BY VENDOR

M
1 M
M
BOUGHT BY
PURCHASED
BY M SERVES
M

CUSTOMER
1

ADMINISTRA 1 ADDS
TOR

KEY:
M MANY ALLOCATED
N ANY NUMBER DEFINED
1 ONE ALLOCATED TO

29 | P a g e
4.4.2 EER [ENHENCED- ENTITY RELATION DIAGRAM]

The enhanced entity-relation diagram of the retail management system is as follows:

4.5 PROGRAM DESIGN


The system will be designed using the following illustrations:

CLASS DIAGRAM OF THE SYSTEM


A class diagram is used to show the system’s class, attributes, operations and the
relationship among classes.

30 | P a g e
THE SEQUENCE DIAGRAM OF THE SYSTEM
The sequence diagram is to identify the behaviour of the system.

31 | P a g e
4.6 INTERFACE DESIGN
The system has a user interface that is designed by a latest version of visual studio 2015
enterprise. The screen shorts below shows how it looks like.

The main window:


Here there are links to the functions of the system. The main form is the menu with a
password to activate other function only the administrator is allowed to access.

32 | P a g e
THE POS link form
Everything is sold using that form.

33 | P a g e
THE PORCHASES FORM
All the products are added to the form.

THE STOCK MANAGEMENT FORM


All stock are priced and then prepared to be sold.

34 | P a g e
The employees form

35 | P a g e
4.7 CONCLUSION
This Chapter covered system design, description of the proposed system. The Chapter also
indicates the architecture design, physical design, database structure and the output design
of the system. The next chapter is going to describe the implementation stage of the proposed
system.

5.0 CHAPTER 5: IMPLEMENTATION

5.1 INTRODUCTION
This phase is all about how the designed system is going to be coded, tested, and installed
and system conversion.

5.2 CODING
The system code is c#.net using visual studio 2015 enterprise and the back-end language for
database connection is SQL using SQL-client database.
Code snippets for RETAIL MANAGEMENT SYSTEM

LOGIN
private void btnLogin_Click(object sender, EventArgs e)

try

SqlConnection conn = new SqlConnection(@" Data


Source=(LocalDB)\MSSQLLocalDB;AttachDbFilename=C:\Users\Lap top\Documents\Visual Studio
2015\Projects\MANZLEE RETAIL MANAGEMENT SYSTEM\MANZLEE RETAIL MANAGEMENT
SYSTEM\PURCHAS.mdf;");

conn.Open();

string ct = "select password from PASSWORD where username='" + txtUsername.Text + "'";

SqlCommand cmd;

SqlDataReader rdr;

cmd = new SqlCommand(ct);

36 | P a g e
cmd.Connection = conn;

rdr = cmd.ExecuteReader();

while (rdr.Read ())

{ if (txtPasswd.Text==rdr[0].ToString())

MessageBox.Show("WELCOME");

this.Hide();

} else

MessageBox.Show("WRONG PASSWORD");

txtPasswd.Focus();

conn.Close();

return;

catch(Exception ee)

MessageBox.Show(ee.Message);

The code snippet for all connection to database, inserting, retrieving and
updating:

private void btnConf_Click(object sender, EventArgs e)

try

//connecting to database//
SqlConnection conn = new SqlConnection(cs.dbcon);

conn.Open();

//inserting into database//

37 | P a g e
SqlCommand cmd = new SqlCommand("insert into SALES(invoiceno, itemno, item_name, item_price,
total_amnt, quantity, DATE ) VALUES(@invo, @itno,@itnam, @itpri, @totam, @qua,@dat)", conn);

cmd.Parameters.AddWithValue("@invo", txtInvoice.Text);

cmd.Parameters.AddWithValue("@itno", txtItemno.Text);

cmd.Parameters.AddWithValue("@itnam", txtNma.Text);

cmd.Parameters.AddWithValue("@itpri", txtItempri.Text);

cmd.Parameters.AddWithValue("@totam", txtTotprice.Text);

cmd.Parameters.AddWithValue("@qua", txtQnty.Text);

cmd.Parameters.AddWithValue("@dat", dtpTime.Text);

cmd.ExecuteNonQuery();

cmd.Dispose();

conn.Close();

conn.Open();

//retrieving from database//


SqlDataAdapter sda = new SqlDataAdapter("select
invoiceno,itemno,item_name,item_price,total_amnt,quantity,DATE FROM SALES ", conn);

DataTable Dt = new DataTable();

sda.Fill(Dt);

dgvPos.DataSource = Dt;

//sda.Fill(DR);

conn = new SqlConnection(cs.dbcon);

conn.Open();

//updating the database//


string cb1 = "update STOCK set QUANTITY = QUANTITY - " +txtQnty.Text + " where Item_Id= '" +
txtItemno.Text + "'";

cmd = new SqlCommand(cb1);

cmd.Connection = conn;

cmd.ExecuteNonQuery();

clear();

conn.Close();

38 | P a g e
}

catch (Exception der)

MessageBox.Show(der.Message);

5.3 SYSTEM TESTING


This involves numerous methods of testing so that the system could meet the user specifications
and fix any uncertainties. The diagram below shows the procedure in testing.
Testing Stages to be followed:

Unit testing

Module testing

System testing

Acceptance testing

5.3.1 Unit testing


This test focuses on one unit of the program, a module or function and the objective is to
check whether each unit performs its task as specified. Unit test is done in two scenarios:

39 | P a g e
White box tests

It is a form of testing design documents and the code. Analyze and possibly manipulate the
internal state of the entity put to test. It is known as glass box testing. A security testing
method that can be used to validate whether code implementation follows intended design.
It looks at the internal structure of the system. White box testing includes analysing data flow,
control flow, information flow, coding practices, and exception and error handling within the
system, to test the intended and unintended software behaviour. However, the system is
good to go.

Black box tests

It is a form of testing in which the tester manipulate inputs and observe outputs but cannot
observe the internals of the entity being tested. This is a testing strategy, which does not
need any knowledge of internal design or code. It focuses on the testing for requirements
and functionality of the work product/software application. Another name for this is
functional testing because the tester is only concerned with the functionality and not the
implementation of the software. However, the system’s functionality is well conducted.

5.3.2 Module Testing


This method of testing combines dependent components and tests them together. A
collection of procedures and functions were tested together .A single component can be
tested without other system modules. Usually module testing is done using the set objectives;
we used objectives to measure the reliability and functionality of our modules. The system
was capable of producing the systems objectives and therefore concluded to be working
properly.

5.3.3 Acceptance testing


This was done by the users of the system. Its main purpose is to test the acceptance of the
system by the end users. This testing determines the success or failure of the system. It is
made up of beta and alpha testing.

 Beta testing:

40 | P a g e
The system is tested using actual data supplied by the manager who will be using the
system. Errors and omissions are discovered and corrected. This process continues until the
organization accepts that the delivered system is ready for usage.

 Alpha testing:
The system is delivered to the organization and the project stakeholders will have a feel of
the system and report any errors and defects which they have discovered. The errors and
defects are corrected and the system returned to the development team.

5.4 Test strategies


Test strategies are used in ensuring the correct functionality of programs and the system as
a whole. Syntax errors and logic errors were identified through the use of code reviews and
structured walkthroughs.

5.5. Verification
It checks whether the right system was developed. The system was checked to see if it was
meeting the customer specifications and requirements. A sample of data was used to test
the system and compared the results with known results. Verification can be assessed by
acceptance testing.

5.6 Validation
The system is evaluated to check for the right functionality. For example if a non-numeric
value is entered in the field of numeric text an error will appear.

For example trying to enter numbers in a product-ID field the window below pops

Security measures were also considered thus the system is able to validate user password.

41 | P a g e
5.7 Verification
This was also intensively done. This is whereby we looked at the system to see whether we had
the developed the correct system. This means that the system was checked to see if it was
meeting the user specifications and requirements. The system might be excellent (running and
fully functional) but not meeting the user requirements. Verification was also done intensively.
We managed to check and analyze system representation using static techniques to check on
requirements documents, design diagrams, program source code and inspections. We tested the
system with some data and compared the results with already known results. We used the white
box method of verification where the tests were conducted to ensure that the internal operation
of the system performed according to specifications and all the internal components had been
adequately exercised.

5.7.1 System Security Testing


Security is implemented through the use of physical and software measures. These include
passwords, security user levels, burglar bars, tags and security guards. System security aims at
protecting the system from vandalism, intentional negative incidences like fraud, theft and
accidents. The objective is to avoid the occurrence of damage to the system or minimize the
effects of an attack. These accidents can occur to hardware, software, data and the network.
We looked at how the risks may occur and then decided on ways which we can control and
protect these risks. A threat to the system is any potential adverse occurrence that can do harm
to the application or its data such as a computer virus or unexpected natural disaster or
disruption. Disruptions occur when there is power failure or user mistakes causing the network
to cut or cease functioning. Some disruptions may also be caused by destruction of data for
example a virus may destroy files and other destruction may be catastrophic such as natural.
5.7.2 Control of destruction, disruption and disaster.
 Viruses can be prevented through the use of anti-virus packages such as Norton anti-
virus and Trend Software. This checks disks and files to see if there are any viruses,
which should always be updated.
 The system shall be in the server room, which shall be locked to be only accessed by
the IT personnel (database administrator) with tags and their secret numbers that
can swipe in after punching the number.
 Disasters must be controlled through having the application and its data stored in a
separate location so that it can be retrieved on emergencies.

42 | P a g e
 Hardware can be insured.
 Having backup for data. Backup shall be done through the use of the Transmission
tape (20-40 GB) in case the system crushes. Daily backup is done and tapes can be
run for particular days on which a system would have crushed. There are also weekly
and monthly backups in order to safeguard un-eventualities following a system’s
crush. In addition backup shall also be done through the use of CDs on a weekly
basis. The backup CDs together with the flash disks are going to be kept in a strong
room that is locked all the time and can only be accessed by the IT personnel. This
strong room is located some distance away from the IT section and server room in
case some disaster occurs in the IT section.
 Update method for Network interruptions.
 Uninterrupted Power Supply devices for any loss of power supply.
 There must also be a good restart function, which makes use of program status
indicators so as to try and control errors caused by interruptions human made
destruction.
5.7.3 Software Security
The system uses passwords, security levels and contact numbers for tracking of transactions.
Each user is assigned a password by the database administrator who has super rights. The
modules and granules to view depend on the level of permissions assigned.

5.8 Installation
This section will give instructions of how to install the system and ensure it is up and running
ready to give the required services to the affected users. This will include software and
hardware configurations at the site of work. Steps for the system installation

 Hardware installation
 System installation
 User training
 File conversion

5.8.1 Hardware installation


This includes setting up of necessary hardware for the proposed system that is installation of
the servers, the user computers, the printers and all the network installations. The I.T group
for the company will be responsible for maintenance and backing up if necessary.

43 | P a g e
5.8.2 User training
The training of the user is done on a personal level as few people hence the use of the system
can be taught to the users faster and more effective.

Training is done at two levels

 Module level: this is for the particular modules that concern the particular users.
 System level. This is for management who must appreciate the development of the
system and its function.
 Users who have access rights to all modules also must be versed with the entire system
as it functions.

5.9 File conversion


File conversion had to be undertaken to ensure the old data is converted to digital data which
is easier to work with, and file conversion had to give the proposed system a chance to be
tried in the real operational environment and performing the functions in real time instead of
using test data. Parallel conversion will be the recommended strategy. It involves running the
two systems simultaneously. A parallel run is done to ensure that all users get used to the
system and that data is safely moved to the new system. Cost is relatively high as both systems
are in operation for the changeover period. Risk is relatively low due to the existence of
backup options.

Steps for parallel conversion:

 Install system to all terminals


 Train users on the use of system
 Capture data
 Process all activities using the new system along with current system

5.9.1 Advantages of parallel conversion


 It gives an overview of the old system compared with the new system.
 It allows errors to be corrected as they are discovered before the new system is made
fully operational.

44 | P a g e
 There will be no disruption of operations in the department since there old system will
still be available in case the new system encounters problems.
 The effectiveness of the new system can be evaluated since operation completion time
can be compared when the same tasks are executed with the old system and new system at
the same time.
 Data outputs can be compared easily since they will be produced from exactly the same
operational data in the same period of time, and thus the results are also more reliable.

5.9.2 CONCLUSION
The system is now complete once passed this level of testing. What is left is to produce a
user manual that aids the users on how to use the system.

6.0 CHAPTER 6: MAINTAINANCE


It is the process of monitoring, evaluating and modifying the operational information system
to make the necessary improvements. The system should be maintained to ensure that it is
still conforming to the specifications. Reviews should be done periodically and if the
specifications or environment changes then the system should be upgraded. Maintenance
of the system is an ongoing process.

6.1 USER MANUAL

USING THE MAZLEE RETAIL MANAGEMENT SYSTEM


After starting the program, if you are not the administrator, you cannot access the other
functions for modification of the products, but any appointed user can access the point of
sale part and settings.

A. LOGIN

The ADMINISTRATOR can use the default password:


12345

45 | P a g e
The password can be changed as the administrator wishes. If password is forgotten, there is
a link, forgot password:

The email address entered is the one that is stored when changing the password:

46 | P a g e
B. CATEGORY
The category can be added, deleted and updated using the form category.
As usual as all the forms require.

C. PURCHASE

Here new products is entered using the PURCHASE menu item or the manage
purchases link. A barcode reader can be used to enter new item numbers.
Category can be added using the method shown below:

Select the correct category where there is a red mark to add category to the
purchase record.

D. STOCK
To add the purchased product to the stock table for sale first select the where the
red dots are for details.

47 | P a g e
Add tax then click GET PRICE button or instead the tax value can be changed.
Click where there is red x on the form above to change the order of the grid.

E. EMPLOYEES

Employees can be recorded in the database for reference purposes. Delete, insert
and update operations can be carried out on the list.
Ensure that all details are correctly inserted in the fields because they are validated.

F. POS

The point of sale is where the products are sold. A bar code reader can be used to
enquire an item sale the click GET ITEM button to retrieve item details. Another item
can be added to a grid list.
Then confirm button prints a receipts as well as the product is saved in the SALES
database.

7.0 APPENDIX

Observations are the ones that I used for the development of this system and most of the
notes led to the interface design I used.

48 | P a g e
APPENDIX D

Observations MANZLEE RETEAIL MANAGEMNENT SYSTEM

Observation score sheet

Observation Score Sheet score sheet


Table D1: Observation
Date ……. /……. /…….

Time …………..

APPENDIX E

Sample of program code used


Observations
Login form …………………………………………………………………………………………………………
…………………………………………………………………………………………………………
<!DOCTYPE html>
…………………………………………………………………………………………………………
<html dir="ltr" lang="en-US"><head><!-- Created by Artisteer v4.1.0.60046 -->
…………………………………………………………………………………………………………
<meta charset="utf-8">
……………………………………………………………………………………………………………………………………………………………………
<title>Login</title>
………………………………………………
<meta name="viewport" content="initial-scale = 1.0, maximum-scale = 1.0, user-scalable = no,
…………………………………………………………………………………………………………
width = device-width">
…………………………………………………………………………………………………………

…………………………………………………………………………………………………………
<!--[if lt IE 9]><script
src="https://html5shiv.googlecode.com/svn/trunk/html5.js"></script><![endif]-->
…………………………………………………………………………………………………………
<link rel="stylesheet" href="style.css" media="screen">
…………………………………………………………………………………………………………
<!--[if lte IE 7]><link rel="stylesheet" href="style.ie7.css" media="screen" /><![endif]-->
…………………………………………………………………………………………………………
<link rel="stylesheet" href="style.responsive.css" media="all">

<script src="jquery.js"></script>

Conclusion

…………………………………………………………………………………………………………

…………………………………………………………………………………………………………

…………………………………………………………………………………………………………

…………………………………………………………………………………………………………

49 | P a g e
7.1 BIBLIOGRAPHY

REFERENCES
Pomberger (G). (1986). Software Engineering and Modular 2 (1st Edition), Prentice Hall,
London.
O’brien. (J). (1996). Management Information Systems (4th Edition), Prentice Hall,
London.
Lucey (T). (1997). Management Information Systems (8th Edition), Publication New,
Delhi.
Foulks (L). (1997). Information Systems, ACCA Handbook, (3rd Edition).
Henry (K). (1999). Database System Concepts, John Wiley & Sons, (3rd Edition).
Dennis (A) & Wixon (B, H). (1997) Systems Analysis and Design.

50 | P a g e

You might also like