Beruflich Dokumente
Kultur Dokumente
By
Valentin Adamescu
April 2019
Abstract
“The advance of technology is based on making it fit in so that you don't really even notice it, so it's part of everyday
life.”
~ Bill Gates
In contemporary society, in a very dynamic market the stock and inventories control are a key factor for any business
in order to maintain continuity and profitability in the operations in an efficient manner. Having an automated way to
overview and manage these operations is a huge advantage compared with manually solutions (e.g. pen and paper) or
semi-automatic (e.g. excel files). However, a business environment is not just stocks and sales but also accounting,
human resources, customers suppliers and many more sections, each one of them with their micro-environment. This
project is about the development of a business management. My goal for this project is to bring all aspects of a
small/medium retail business under one umbrella by developing a generic software with a minimal cost but maximum
efficiency. The system described in this document is a modular system, working as an autonomous homogeneous system
with online/offline capabilities, assuring an intuitive and easy-to-use graphical interface.
System Demo
http://uop.cloud
Note: For login credentials please contact my supervisor Nadim Bakhshov
This project report tells the story of the development and implementation of a comprehensive retail business
management system for a client. The client is Albert Butcher Ltd.
Albert Butcher is a small/medium size business based in Portsmouth, founded in early 2017, but growing very
fast. Their main activity is divided between selling wholesale fresh meat and meat products (specially pork
and beef) to local supermarkets, hotels & restaurants and retail of meat products along with other general
groceries products (fruits, vegetables, frozen products, alcohol & non-alcohol drinks, canned products, etc.).
The current retail shop is based in Portsmouth but the business has an active plan to extend to Cosham &
Havant sometime in autumn of 2019 with two more groceries shops. For the near future they are hoping to
extend their retail activity to include clothing and digital products. Albert Butcher Ltd currently has 6 staff
members with various cultural and linguistic backgrounds. The business owner acts as general manager. With
the plan in place to open new locations the total number of employees would increase to a possible 15 with an
additional manager and a dedicated accountant.
In the first few months of the business the client used a system made from Microsoft Excel as the stock
inventory management tool and a free software for basic accounting. For a short time, this solution met the
business needs. However, the client did not anticipate the rapid development and success of the business. The
system was not properly equipped to manage the increase of stock related activity. Furthermore, he struggled
with the impact this had on the supply chain.
The current business flow management is based, as stated above, on a combination of spreadsheets (to keep
track of their in/out orders), notes in a physical notebook with conventional pen and paper and a free version
of ZipBooks accounting software (https://zipbooks.com). For the client it has become very difficult to manage
the business and keep track of all sales, suppliers, customers stock inventory and so on. Prior to my
engagement, the client tried a number of methods to simplify the processes but all of them proved to be
inefficient, overcomplicated, very expensive and/or did not have all the features and flexibility that business
required.
A basic representation of the current business workflow can be seen in Figure 1. Further information and
details about their current practice and the problems will be presented in section 1.3 of this document.
1.1 Overview
For almost any retail business having a manageable internal control system of their inventories, expenses and
income is one of the most important aspects of business workflow (Ballou, 1997). In order to meet customers’
demands in an efficient way a business must be able to manage the whole supply chain. Having an oversight
of what products are available in the warehouse at any point will help to: ensure stock rotation; lower the
costs; minimise wastage; avoiding of unnecessary stockpiling or the opposite as stockouts; reduce risks of
losing goodwill; better accounting.
These requirements are even more critical to the performance of the business if the business has multiple
locations with different stocks and separated expenses. Even for a small business is difficult to hold an
inventory with a classic pen and paper method, using spreadsheets or taking advantages of free software such
as ABC Inventory (Almyta Systems, n.d) or Odoo Inventory (Odoo, n.d.). For medium to large business these
methods would be totally inefficient. Having multiple locations (e.g. multiple stores or warehouses) is more
difficult to track the changes in inventories and have an accurate overview over the whole stock. Most of the
free solutions are coming with restrictions of usage and/or limited to only one user or covers only some aspects
of the business requirements (e.g. just stock inventory or just accounting). Maintaining the equilibrium
between supply and demand is one of the factors for a successful stock management, but having all tools
required to manage the business into the same system is the key of a successful business.
The objective of this project is to develop and implement a system that will help the business to efficiently
manage their workflow using information technology. The aim of the proposed system is to solve the problems
occurred from current manual system. A secondary aim is for this customised tool to tackle the lack of
efficiency, the mixed-up solutions and the low level of security. This solution will help the business to
maintain the productivity, efficiency and profitability.
▪ Main objective
o To design, develop and integrate a general model software suitable for any small/medium
retail business
▪ Primary objectives:
o To create a bespoke system for the client covering the required aspects of the business
In this section I will discuss in depth the business current practice and problems following the brief
introduction.
One of the main drawbacks of the current practice is the lack of efficiency, mixed up documentation and data
loss. Furthermore, for the business owner it is very difficult to keep track of the sold products at the end of the
day, week or month and calculating the remaining stock is a real challenge. Human errors are very frequent
and searching for a specific product details, past orders or a specific supplier is a time-consuming task.
Frequently, the business ended with an overstock for some products where others were understock.
Another aspect that must be highlighted as a major problem is the low level of security. Without a
computerised system protected by a user name and password in place, all the business customers and suppliers’
details are virtually accessible to any employee. Any staff member could access the details and create a copy
for their personal needs.
For a clearer understanding of the business workflow I have constructed a table that separates the purchase
process, wholesale process and in shop retail process. I have additionally included the aftersales process and
the accounting of the business.
The business deals with two aspects of sale process (wholesale and shop retail). Both sales have different
types of clients, VATs, percentage markup, purchases, expenses and income making extremely difficult for
the client to keep track of stocks, income and expenditure. The process is prone to numerous mistakes and
very time consuming. Furthermore, it leads to inconsistent data, overstocks, accounting inadvertently mistakes
and sometimes delays in orders.
*Note: Between 6 January 2019 until 5 April 2019 Albert Butcher used ZipBooks monthly paid version where
the expenses can be added and automatically deducted from total income, a feature implemented into this
project.
Please note that the following proposed solution has come out of extensive conversations and discussions with
the client and my own development with the project idea. These are covered thoroughly in the Requirements
Specifications. Here I briefly want to indicate what the nature of the proposed solution is and highlight some
of the key features. The proposed solution which I have called Retail Business Management System (RBMS)
is intended to be an all-in-one solution that should allow the management of the inventory, purchases & sales
(storing the purchase price and sale price), suppliers, customers, invoices, general accounting and HR
management. RBMS supports multiple stores (warehouses), allowing the business owner to have an overview
over entire stock and make adjustments if necessary, by replenishing the stock (ordering new items) or moving
goods between stores (e.g. if an item is in excess in location A it can be transferred to location B). For RBMS
I am intending to implement a notification system that will inform the user if any of the product/s in any of
the warehouses (shops) is below a pre-set limit. This will prevent understock and implicit overstock.
Furthermore, the RBMS system will allow the user to have access to the customers and suppliers contact
details in one place. This will keep business contact list consistent. In addition, automatically calculating the
profit/loss ratio by taking into account the expenses, employee payments, wasted products (e.g. unsold and/or
expired and including or excluding the VAT tax depending of purchase/sale requirements, will make the
accounting very easy. A variable VAT method adds flexibility to the business because the VAT should be
added to the total order or individually per product. In UK some goods have a standard VAT of 20%, others
5% where most food products have a zero rate (Gov.Uk, 2014). Therefore, the VAT calculation can be
adjusted for each product (or category of products) individually.
The system should allow the comparation between current available physical stock and digital records, with a
stock counting function. The function should allow the manager to inputs the current counted products from
store and the system will automatically calculate the stock difference (if any).
The proposed system should be able to creates several reports including the total revenue, profit/loss (gross
and net), received and sent payments making the accounting very easy.
RBMS should be available as a multilanguage system. This feature will increase end-user experience making
the system more appealing to the users where their native language is not English.
One of the key aims of the project will be to keep the development costs as low as possible. Therefore, all
used software, frameworks, packages and platforms will be free to use (MIT or GNU 3 licence) or supported
by an educational licence (MS Office 2016, Balsamiq and Axure). The only expenditures for this project will
be the purchase of live server domain and several travels to the business location.
Some of the chosen software are based on personal preference (e.g. the code editor, DB development tool)
and they can be substituted with any other suitable software (e.g. Atom). For mockups and prototyping the
chosen tools are tools used by the industry standards and they are covered by an educational licence. The
software used for images manipulation (conversion, cropping, retouching, drawing etc) is one of the most
popular free software, simple to use with a large available documentation. This project does not require
extensive images manipulation and any other software can be used (e.g. Paint). The development environment
is my personal computer setup.
The decision that lead to use of the server environment, framework and packages will be explained in the
related sections.
Below is a brief description of the used software and applications:
• Code Editor: Used for writing and developing the code with full support for all required programming
languages (SQL, HTML, CSS, JS, PHP)
o Visual Studio Code, desktop application v1.31.1 (https://code.visualstudio.com)
• Database Development: Writing the SQL from scratch will be time consuming therefore using a
software with a GUI will accelerate the database creation process.
o Devart dbForge Studio Express (https://www.devart.com) is one of the most comprehensive
database development tools.
o MySQL Workbench - as a backup (https://www.mysql.com/products/workbench).
• Images Editor: Used for editing and manipulation of images, icons and logo creation
o Gimp v2.10.8 (https://www.gimp.org)
• Diagram Design: Used to create system architecture, use case & sequential diagrams included in this
report
o Microsoft Visio 2016
• Mockups & Wireframes: Used for initial mockups and low fidelity prototyping of the user interface
for the client
o Balsamiq (https://balsamiq.com)
• Prototyping: Used for initial high fidelity prototyping with where the user had the real “feel and touch”
experience with the GUI
o Axure (https://www.axure.com)
• Server Environment: Local server used for development necessary in order to run SQL & PHP files
without delay over the internet and for efficient and quick debugging
o XAMPP PHP development environment with Apache Server 2.4.37, PHP v7.3.0 and Maria
DB v10.1
(https://www.apachefriends.org)
• Frameworks: The platforms used for the system development. The frameworks helped to save a lot
of time by eliminating the need of producing repetitive code and allowing to build applications rapidly
o Laravel v4.2 (https://laravel.com)
o Bootstrap v4.3.1 (https://getbootstrap.com)
o Vue.js v2.6.7 (https://vuejs.org)
At the initial stage of the project it was very important to enumerate and detail out the risk issues related with
this project. The table below summarises the risks like I saw them at the beginning of the project.
Description Probability Possible Countermeasures
My computer has a NAS (network-attached-storage) drive
Computer failure Low attached with a daily scheduled backup for important files. The
project folders will be added to the backup schedule.
The above solution will be suitable but instead of overwriting the
Loss/corruption of data Medium backups, for the project purpose, this will be kept until I manually
delete them.
The aim of this project is to keep the development costs near to
Technical £0. Therefore, the only software requiring a licence are MS
Software licences Very Low
Office, Balsamiq and Axure which are covered by a student
licence until 2020
The purchased server may have compatibility/configuration issues
Server setup Low with the system. I will contact the host company to find a solution,
otherwise I will purchase a new server.
Consulting technical books, forums, documentation to overcome
Coding/Development
Medium the problem. Otherwise, I will look for a compromise or
issues (lack of knowledge)
workaround solution.
I have scheduled a surgery in August 2019. If something
Illness Medium unexpected triggers this earlier, I will review the project priorities
and act accordingly.
Personal Time management is one of my soft skills. I consider that setup
Time allocation Low timeframes are realistic and achievable. However, if the scheduled
pattern suffers major changes, I will review at the time.
Family commitments Medium Some unpredicted situations may arise. I will review at the time.
Project scope change Low Looking for alternative solutions or starting a new project.
Communication with the Using alternative communication methods with the client (e.g.
Low
Organisational client emails, phone, Facebook messenger, WhatsApp).
If the project is in an advanced stage, continue the project based
Unavailability of the client Very Low
on assumptions, otherwise consider a new project.
My personal IT setup at home contains a variety of hardware.
Unavailable hardware Very Low However, if something unforeseen appears I will purchase the
Resources required hardware.
Research more, subscribe to specialised forums, visit the
Documentation, Books Medium
University’s library
Very briefly in this section I want to highlight that legal issues which may arise during the course of the project
may be related with data protection and privacy. Therefore, any personal details that may be acquired during
the data gathering or testing phases must be deleted and when is possible to use dummy date for testing phase.
In this project only beneficiary (the client) company will be included and a signed consent form will be
attached to this project.
A critical professional issue is to remain unbiased, to look impartially at the requirements, be honest and
demonstrate integrity through development process. Keeping up with the latest technologies the final artefact
should be an up to date product suitable for business.
Keeping a professional attitude during any conversation with the client or any of his employees will increase
the client confidence and trust.
Nonetheless, I decided to embrace the challenge and increased project complexity but taking into account a
potential risk of not completing the project on time. It was a calculated risk and I was focused to implement
client requests first and enhance features at a later time.
In this chapter my aim is to present an analysis of the systems/platforms already available on the market,
examining their advantages and disadvantages, to look at the aspects of programming language, databases and
other technical considerations.
One of the first problem encountered researching for similar software was the
fact that most of them, for the demo access were asking too many unnecessary
personal information, to be comfortable with, for marketing purposes. After
several demo requests attempts few software were selected for trial.
• inFlow (https://www.inflowinventory.com)
The executable was successfully downloaded but despite the fact of several
trials the installation on 2 different computers were unsuccessful due to the fact
that application could not connect to the server (Figure 4). Even a minor
downtime of the application functionality can result in financial loses for the
client.
Figure 4 - in Flow Software
• XERO (https://www.xero.com/uk) installation error [Primary Source]
XERO software (Figure 5) had a very well-integrated interface with full accounting and payroll support. The
system was easy to be used with intuitive button labelling and easy to navigate interface. The system
automatically generates invoices, adds suppliers and customers, generates different financial reports along
with profit loss ratio. The software does not have any support for inventory and stock management, suppliers
list or sales. One of the disadvantages was the fact that the system was accessed through a web browser and a
24/7 internet connection was required which would put off the client. The price for the system use was
£27.50/month with an additional cost of £5/month for each extra user added to the system and another
£5/month for any payroll employee added. This will cost the client around £70/month (adding 5 employees
and 3 users). When the client has more users/employees the price will increase in the future.
technical person, I was confused about used terminology. For a person with less technical abilities will be very
difficult to setup this system. The learning curve of how to use the software is very steep.
On a software review website, a customer with a small company left an extended review of the ZOHO
software (Figure 7) where highlighted the difficulty of use, lack of functionality and the poor customer
support.
There were other several systems tried with more or less features but the price (some of them more than
£2000/month) is a crucial decision factor for the client.
In the literature review presented in this section I will examine the issues related to the choice of the variety
of programming languages and look to their strength and weakness.
With over 250 programming and scripting languages available in the world (Diana, 2016), each one of them
with strengths and weaknesses, is never an easy decision to take for what programming/scripting language to
use. Please note that there are some differences between programming and scripting languages but both can
be used to develop full applications, individually or combined.
• Model – The level responsible with holding data and resources available as the lowest layer
• Controller – Middle level layer that controls the interaction between user view and resources
For this project 3 programming languages were identified that would fulfil the above criteria. I am considering
the following programming languages to use: ASP.Net, PHP and Node.js.
ASP.Net
PHP
Is an open-source widely used server-side scripting language implemented on 79% of websites (W3Techs,
2018), that can be embedded into HTML and web frameworks. PHP has a shorter learning curve compared
with ASP or JSP, a significant amount of documentation and a very large community support.
The latest version is 7.2 but v7.3 is scheduled for December 2018.
However, using PHP with any MVC framework additional time and
effort must be put to learn new syntaxes and concepts. This factor
will increase development time if I am not familiar with that specific Figure 10 - Global percentage of server-side
programming language (W3Techs, 2018)
framework. In a comparative study published by Concordia
University arguably is stated that “it is widely believed by the developers that PHP has a poor quality of
handling errors. PHP lacks debugging tools, which are needed to search for errors and warnings. PHP has a
smaller number of debugging tools when compared to other programming languages” (Alomari, Halimi,
Sivaprasad, & Pandit, n.d.) .
Is a JavaScript runtime environment, including all necessary resources to execute a code written in JS as
server-side. Node.js handles files request differently of PHP and ASP (Table 3) eliminating the waiting time
which is a huge advantage. However, if a long calculation is necessary the performance will decrease because
the support for multi-threaded operations are inexistent. Another disadvantage of Node.js is lack of
consistency where changes are often backward-incompatible, making long term maintenance extremely
difficult. Available library system is not so robust compared with other programming languages and scalability
of a project developed with Node.js may be a real challenge for any developer because its immature
environment, asynchronous programming model and not stable API (Malvi, n.d.).
2.3 Database
In this section my aim is to examine a number of different databases platforms that offers the features and
functions necessary to this project by presenting the selection criteria and a short description of each database
along with advantages and disadvantages. A comparison table will be presented at the end of the section and
conclusion of database analysis will be presented in Design chapter.
In recent times databases are notably surrounding us more than ever and most of the time without noticing.
Making a simple phone call will involve a database connection. Databases are at the core of the most systems
and choosing the right database is a critical step for any system to be developed.
At the time of writing DB-Engines Ranking website lists 340 (DB-Engines, 2018) actively developed and up
to date databases, each one of them with strengths and weaknesses or suitable for different purposes (e.g.
relational, search engine, document, etc.).
However, regardless of vendor the databases must satisfy the following conditions necessary for this project:
✓ Relational/Table database
✓ Free/Open Source
✓ ACID (Atomicity, Consistency, Isolation, Durability) compliance
✓ SQL compliant
✓ Scalable
✓ Support for real-time queries
✓ Support for triggers
✓ Detailed documentation
✓ Strong community support
✓ Support for the programming languages analysed in Programming Language section
Analysing the available pool of databases, the following were identified as suitable for this project:
▪ MySQL (https://www.mysql.com)
▪ PostgreSQL (https://www.postgresql.org)
▪ SQLite (https://www.sqlite.org/index.html)
MySQL
MySQL database had first public release in 1996 (1998 for Windows) and was developed by Allan Larsson
and Michael Widenius (Rieuf, 2016). Sun Microsystems acquired MySQL in 2008 which was later acquired
by Oracle in 2010 and developed since then (Oracle, 2010). MySQL is a very popular choice among
developers and most-used open-source database system in the world with a 38.9% market share (ScaleGrid,
2019). Furthermore, there are many enthusiasts and developers forming a large community to whom I could
ask for support.
Moreover, MySQL is a free, flexible open-source database with support for programming languages such as:
PHP, JAVA, C++, C# Node.js, Ruby and many more. A characteristic specific to MySQL is the scalability
and the accessibility of the applications by mirroring the workload across various nodes.
However, MySQL is not designed to support a very large number of concurrent queries very efficient
(MySQL, 2018).
PostgreSQL
PostgreSQL emerged in 1996 based on another project (Ingres) at the University of California (PostgreSQL,
n.d) and has undergone several major modifications since then.
Similar with MySQL, PostgreSQL is a comprehensive, sophisticated database system with a highly available
documentation and a strong community support. Suitable for single machine workload, web services and data
warehouse and supports various operating systems. The integrated query optimiser can handle complex
Valentin Adamescu PJE40 - RBMS Page 23 of 105
UP872413 Retail Business Management System
queries better than many others databases. However, installation and configuration can be difficult for
beginners and the learning curve may be steep. Furthermore, PostgreSQL has only one storage engine
compared with other databases.
SQLite
SQLite is a self-contained, file-based database with strong performance for low-memory systems. With a
serverless technology, SQLite is the perfect candidate for small, embedded applications (e.g. mobile phones,
electric appliances, automobile industry). With zero-configuration approach SQLite does not come with any
configuration files that need to be managed and entire SQLite database is stored in a single file (SQLite,
n.d.).Being a very lightweight software (around 600KiB) developers made a major compromise by not
integrating any security measure (e.g. authentication, privileges) in SQLite. Security measures can be
integrated additionally with various commercial support packages, each for an annual fee (SQLite,
n.d.).Another disadvantage is the fact that SQLite has a limited concurrency of connections.
MariaDB
MariaDB is a free open-source fork of the MySQL but commercially supported. This fork was created due to
concerns that Oracle will end-up free licence of MySQL (MariaDB, n.d). Sharing many features of MySQL,
MariaDB stands forward as a stable and innovative database.
The storage engines integrated in MariaDB allow users to run SQL and NoSQL in a single database system.
Additionally, MariaDB provides better monitoring through the introduction of microsecond precision and a
better query optimisation. However, increasing control writing queries is more difficult because MariaDB is
case sensitive. As many developers have different naming patterns, it may become frustrating to check all the
time table name or column name. Another disadvantage is the limited number of supported operating systems
and the hosting environment may not support MariaDB.
The table below summarises the analysed databases features based on several criteria that I consider important
for this project:
In this section I am intending to present a brief overview of the system architectures that I am considering
suitable for this project. The justification of the chosen architecture will be presented in the Design chapter.
Garlan and Shaw define the system architecture as: “The architecture of a software system defines that system
in terms of computational components and interactions among those components” (Garlan & Shaw, 1994). In
other words, system architecture is the foundation layer of the application or software which determine how
the user interacts with the system (authentication and other security mechanism), how system components
interact with each other and the services that it provides.
One of the criteria to select these architectures is following the programming language analysis. The
architecture should support MVC frameworks. For this project I found that the following system architecture
patterns would be most suitable:
Monolithic architecture
Space based architecture, sometimes called cloud architecture, is a linear architecture pattern using the tuple
space paradigm. SBA is implemented by building independent units called processing-units (Dai, Bai, & Xu,
2006). The architecture supports Java, .Net, and C++ programming languages. Most suitable for distributed
systems it has a high degree of scalability by simply adding more processing units. However, the deployment
is depended of a cloud environment and is very expensive to maintain because it involves replications and
mirroring of the system in order to avoid a single point of failure (Engelhardtsen & Gagnes, 2002).
OOA is an architecture pattern based on the division of responsibilities for an application or system into
individual reusable and self-sufficient objects (Mowbray & Malveau, 2003). One of the main advantages of
OOA is the fact that it is easy to maintain and improves the quality of the system due to program reuse. As a
disadvantage it has difficulty to determine all the necessary classes and objects required for a system. This
architecture pattern is very popular with Java, C++, C# and scripting programming languages.
In this section I will briefly discuss the possible design approaches for this project and the justification will be
provided in the Design chapter.
Software design is a creative process that based on a mix of knowledge, intuition and imaginations is perfected
with experience. The term design in software development, is not referred as drawing something but rather as
a parallel activity where conceptual ideas are analysed.
Foster defines software design activity as a critical step for the final artefact where “decisions you take now
will hit you later” (Foster, 2014). Furthermore, Foster divides design activities into 7 categories (see Table 5).
The design activity approach is divided into two categories: top-down or bottom-up. The top-down design was
firstly mentioned by IBM researchers Harlan Mills and Niklaus Wirth and is focused on general functions,
where the developer specifies ‘what, wherefore and how’ of the system (Narang, 2015). This approach
involves extensive planning and research. Bottom-up design is focused on each specific function and sub-
In this chapter I will analyse a number of key methodologies which initially seems appropriate for this type
of project. A short description of the methodology will be made along with a summary of advantages and
disadvantages of each one of them. At the end of the chapter a conclusion will be drawn and reasoning will
be provided to choose a methodology instead of other.
This model has as core principles the flexibility and the continuous improvement. Agile model is more
suitable for self-organizing group of people (teams) working on a project, embracing the changes,
collaborating and allowing modifications almost at any point in the project (Agile Alliance, n.d.). Contrary to
Waterfall model which is based more on a predictive approach, agile uses an adaptive approach. A project
following the agile conceptual framework should follow and apply the 12 principles as they are defined in the
Valentin Adamescu PJE40 - RBMS Page 29 of 105
UP872413 Retail Business Management System
Agile Manifesto (Agile Manifesto, n.d.). Agile is a broad
concept and can be implemented with other methodologies
creating hybrid methods and can include more sub-method
types such as: Scrum, Crystal Clear or Dynamic Systems
Development Model. However, agile methodology is
heavily depending on client interaction and communication
where team members are forming a cluster around the
project with a high degree of synchronisation and
coordination between members. When a member is
replaced, it may be difficult for the new member to be Figure 17 - Agile model [Primary Source]
apprised in detail of the project development due to the lack
of documentation because usually agile teams are prevailing working software over documentation. With agile
methodology each member knows exactly their position and what they need to do. Communication being one
of the key factors of agile methodology, will offer a greater client satisfaction, because the client is involved
at any point into the project and offers project transparency.
Agile model prioritises the most important features and they are implemented first therefore, the risk of full
fail of the project is minimised and allows a partial success of the project (Lee & Xia, 2010). The
implementations (or potential product functionality) are done through short cycles of development process
known as sprints.
In below table I have summarised the advantages and disadvantages of agile methodology.
The waterfall model has numerous sources of available documentation that would help me to implement it.
Unfortunately, waterfall it does not offer enough flexibility for the project I am undertaking and the client will
be involved only towards the final stage of the project. One of the aims is to develop a bespoke solution for
the client and without his continuous feedback, as well as high involvement in all phases, the project may fail.
The waterfall may be suitable for smaller clear projects but for this one I am considering that waterfall is not
the appropriate method.
Agile methodology is probably one of the most used method for software development, involving the user
almost at any stage but it is designed for collaborations where a team works together for the final goal. Agile
methodology involves long cycles and clear development goals. This project being an individual project and
the final development goals still to be determined, using agile methodology will be a drawback rather than an
advantage.
Similar with agile, RAD model is a team work but where several teams work in parallel on the same project,
creating final modules from working prototypes. For an efficient application of RAD expensive and
sophisticated tools and software were required invalidating the aim of this project to keep development costs
to a minimum.
Developing a bespoke and a generic model system for the client it extends the complexity and the risk factor
of the project failure. Using spiral model may be considered as an advantageous model but implementing a
spiral model would actually carry the risk of spiral to go on indefinitely. The time consumed by each build of
the prototypes, analysis or iteration may result in a never-ending project. Therefore, I am considering that
using spiral model would be detrimental to the project.
This project is a system built from scratch with a focus on offering a bespoke system to the client, as well as
a generic model suitable for other businesses. Allowing the client to be involved actively and to preview every
stage of the project is a critical requirement. Furthermore, a model that allows me to break down the entire
project into modules is another constraint.
Taking into account all the above, I am considering that the incremental model is the most suitable model to
be used. This will prevent a cascading effect on the project development when something needed to be
implemented/changed to a specific module. The incremental model allows me to break down the project into
small modules and regularly test them.
Another advantage using the incremental model is the fact that spotting and fixing errors in each stage is easier
than debugging a whole system. However, I am aware that if any of the core functions is modified a correction
is required in all depending modules which will be time consuming, but this is an acceptable trade off. I
consider that the key elements for this project are: frequently delivery of working software, direct
communication with the client and flexible development process.
Furthermore, using incremental model allows and encourages an iterative development (revisit parts of the
system in order to improve them or to add new functionality) an approach suggested by a research conducted
by De Lucia and Qusef (Lucia & Qusef, 2010).
Just to highlight the importance of well planning system and how incremental model can save millions of
pounds if not billions, we can examine Ford Motor system implementation failure in 2004. Ford Motors tried
to implement an Oracle-powered system, a project that costed Ford Motors $400 million (Hines, 2004). The
system aimed to bring 30 archaic systems under one core system but the problem was that the core system
was developed independent of the already in place systems with a minimum compatibility/integration testing.
In this chapter I am presenting a brief overview of the project management as well as the changes, deviations
and delays of the initial plan. Further information about project encountered difficulties and a personal view
will be presented in Conclusion chapter.
As mentioned in the Introduction chapter, my relationship with the client is a long established one and the
discussions to undertake this project had started before it was accepted as a final year project. This was an
advantage for me because gave me a longer time period to fulfil the requirements without rushing into an
incomplete system or simplifying the project in order to meet university deadlines. The below Gantt chart
shows the timeline of the entire project that includes the university deadlines, additional project tasks
excluding public holidays or half term, as they were not influencing factors.
However, the timeline of the project (Figure 21) suffered few alterations along the way. In general, the
estimations were correct. Although, the development phase was estimated to take initially around 250 days,
the duration changed due to adding more modules and continuously improving the project. These added a
degree of pressure to complete the tasks in time. This was not necessary a bad thing because it helped me to
better understand how to manage the changes and how to provide solutions to a given problem. This fact once
again demonstrates that the chosen methodology was the right one for this project.
The extra functionality added to the modules, required constant review of the system. One of the factors I did
not anticipate was the continuous improvement of the modules and this added extra time for development.
Figure 22 shows a breakdown on
tasks with an estimated number of
days per task along with planned start
date and end date. The tasks dates
were for guidance only. In general, the
scheduled pattern was followed but
occasionally the estimated time took
longer than anticipated.
However, the time was recovered by
putting more effort and prioritising
tasks.
Note: It was not possible to take a full
screenshot of the project task allocation.
Please see Appendix M for a larger
screenshot of the project total timeline.
In this chapter my aim is to present user and system requirements that emerged during the analysis.
Additionally, the requirements emerged during the different increments and user feedback are presented as
well. The mandatory requirements are crucial for the business and are the backbone of this project.
I believe that adding more functionality will increase user satisfaction and these features will make this project
viable for any retail business not only a bespoke system for the client.
Section 5.2 from this chapter describes what the applications must and should be able to do through
implementing core functions and features stated by the user and business analysis. Moreover, some functions
were added by taking into account other potential users of the system, without diminishing client requests.
These requests emerged from the discussions with the client, interviews, personal observation of the business
workflow and my personal experience.
User is defined as any person that interacts with the system regardless of user role (e.g. admin, business owner,
manger or staff).
Section 5.3 describes the system requirements where user requirements are translated in technical terms and
specifications.
Specific requirements presented in this chapter are prioritised using the MoSCoW method and they are defined
as follow:
▪ M – Must have (Mandatory requirement – this requirement is essential for the business)
▪ S – Should have (Beneficial requirement – it is not critical for the business but this is beneficial and
will increase efficiency if implemented; requirement that can be applied for a generic model)
▪ C – Could have (Optional requirement – it is not fundamental for the business. Nevertheless, if
implemented, it will increase end user satisfaction; requirement that can be applied for a generic model)
▪ W – Would not have (These requirements would not be implemented in the system but they can be
used as a reference for future development)
Note: In System Requirements section some requirements will be available only for certain users defined by
user role. The below notation will specify this requirement as:
For a better understanding of the business logistics and what are the daily activities, I spent an initial 3 working
days into the shop following the business process, taking notes of the orders and the sales workflow. Two user
types emerged from discussions, interviews and personal observation of all involved parties:
The table below containing user requirements emerged across entire project and was continuously improved.
The mandatory priority requirements were the core initial requirements. The S and C are the requirements
added along the project, following my discussions with the client and his employees.
The requirements made initially by the client are represented with green. Those in blue are my own added
requirements that are beneficial for the client as I believe they will increase the business efficiency (e.g. sale
units, categories) and/or to address issues that the client did not thought about (e.g. forgot password).
Additionally, they are suitable for a generic model.
User requirements are divided into sections, each section representing a module.
5.2.1 User registration (account)
Req. Description Priority
5.2.1.1 User must be allowed to create an account M
5.2.1.2 System should have role permission S
5.2.1.3 User account should be inactive as default S
User account should be activated only by a higher hierarchy account (e.g. admin, manager; see
5.2.1.4 S
{5.2.1.2})
5.2.1.5 User must be able to select own credentials (e.g. username, password) M
5.2.1.6 User should be allowed to register through a Facebook account W
5.2.2 User login (account)
Req. Description Priority
5.2.2.1 User must be allowed to login in a secure way using a username and password combination M
5.2.2.2 System must allow the user to reset the password (in case of forgotten password) M
5.2.3 Products
Req. Description Priority
5.2.3.1 User must be allowed to add products to the database (limitless) M
5.2.3.2 User must be able to add following details: Product Name, Brand, Product Details, Purchased Price,
M
Sale Price
5.2.3.3 User should be able to add a use by date for perishable products C
5.2.3.4 User should be able to add following details: Picture, Sale Unit (e.g. Kg, L, Bottle, Pack), Tax S
5.2.3.5 User must be able to create custom categories for products (e.g. Drinks) M
5.2.3.6 User should be able to create custom sub-categories for products (e.g. Drinks > Fizzy Drinks | Soft
S
Drinks)
5.2.3.7 User should be able to import products from a list (e.g. Excel file) C
5.2.3.8 User should be able to print barcode with price for products C
5.2.3.9 User should be able to print out the entire product list or only selected products S
5.2.3.10 Product should have expiration date S
5.2.4 Purchase Products
Req. Description Priority
5.2.4.1 User should be able to create a purchase list (e.g. selecting N products and the quantity) S
5.2.4.2 Purchased list should contain a date of creation S
5.2.4.3 Purchase list should automatically calculate the total price of the products C
5.2.5 Sale Products
Req. Description Priority
5.2.5.1 User must be able to create a sale and be recorded to the system M
5.2.5.2 User must be able to select products from products list {see 5.2.3} M
5.2.5.3 User must be able to insert customer details M
5.2.5.4 User should be able to add the VAT to the order S
5.2.5.5 System should calculate automatically the total cost C
5.2.5.6 User should be able to add custom notes to the sale S
5.2.5.7 User must be able to have and overview of sales (e.g. a list) M
5.2.5.8 User should be able to print the invoice based on the sale order C
5.2.5.9 System should be able to directly process payments with debit/credit card sales W
5.2.6 Stock Management
Req. Description Priority
5.2.6.1 User should be able to have an overview of the products quantity (see {5.2.3}) M
5.2.6.2 System should automatically add the purchased products to the total stock available into shop S
The system requirements follow the user requirement and defines the system behaviour. These requirements
will define the system functionality and a measurement method if the project was completed or not also its lay
down the path for the design and development phases.
This section will define the system general behaviour that was not covered by the functional system
requirements.
5.4.1 Security requirements
Req. Description Priority
5.4.1.1 In order to increase security, only one session per user will be allowed M
5.4.1.2 If the user is not logged in, they must not have access to any part of the system M
Registered user will be allowed to access only the system part set by the user group assigned to that user.
5.4.1.3 M
See [X] notations
5.4.1.4 The passwords must be encrypted and not stored as plain text M
In case of forgotten password, user will be provided with a link, sent to the user registered email, to
5.4.1.5 M
setup a new password rather than sending the password as a plain text.
5.4.1.6 Users are automatically logged out after 5 min of inactivity M
5.4.2 Portability requirements
Req. Description Priority
The system migration on another server must be done with a minimum effort using the phpMyAdmin
5.4.2.1 (or equivalent) for DB export/import and FTP transfer protocol for files and folders using FileZilla M
software (or equivalent).
5.4.2.2 The migration to a new server should not make the system unavailable more than 3 hours S
The system should be available on various platforms (desktop pc, mobile devices) and devices but
5.4.2.3 S
assuring the minimum dependencies (see {5.5})
5.4.2.4 The system should be optimised for mobile devices view (adaptive screen resolution) C
5.4.3 System requirements
Req. Description Priority
Under no circumstances must users be able to access any part of the physical database and/or physical
5.4.3.1 M
coded files
5.4.3.2 All aspects of the system must be accessed through a user interface M
User interface should be easy to use and natural to the end user who should be able to operate the system
5.4.3.3 S
efficiently (no more than 24hours of usage - 3 days x 8 hours)
A minimum of 20 concurrent users must be supported by the system and server without minimising the
5.4.3.4 M
performance
5.4.3.5 The system should be available without internet connection* (see {5.5}) M
This section covers the system functionality rules, based on the assumption that the user has the minimum
knowledge of the terms below and basic skills of using a web browser.
• Online Server – For installation a web server is required and must be available 24/7 without any
bandwidth limit and must have a minimum uptime of 99.5%. Online web server is required for remote
access and mobile devices.
• *Offline Server - For installation a local web server is required and must be available for users 24/7.
The offline server can be configured used XAMPP (or equivalent) on any laptop/desktop having Windows
/ Mac / Linux operating system. On localhost the system is available only on that particular server and any
updates are available only on that server. Offline web server is one location/one device access point.
• Web Browser - The system should be compatible across the IE11 (v11.0.110), Firefox (v59.0.1 or
later), Safari (v10.1.2 or later), Chrome (v 65.0.3325.146 or later), Opera (v 51.0.2830.40 or later), Edge
(v43.17763 or later) browsers.
▪ Note: Tablets/ mobile phones browser versions should work on all Android (v5.0 or later) / iOS
(v7.0 or later) devices. Previous versions of the most popular browsers could function but these
would not be tested. Lesser known browsers (e.g. Linx, Lunascape) may be suitable but these are
not guaranteed to work. BlackBerry, custom ROM/FW or OS devices are not tested.
• Internet Connection - 2MB/s connection (minimum). Recommended is 3MB/s for a better user
experience. For offline configuration, no internet connection is required.
• Operating System – All operating systems supporting one of the mentioned web browsers.
• Hardware
▪ Online access: The system should be compatible with any device that have an internet connection
and one of the mentioned web browsers.
▪ Offline access: For installation a minimum 750 MB HDD/SSD space
o 50 GB HDD/SSD space for operation system and database
o CPU - Minimum recommendation Intel Core2Duo 2.2 GHz / AMD Athlon Dual-Core 2.2 GHZ
o 4GB RAM – Minimum recommendation for a Central Server
o Monitor, mouse, keyboard
Note: Using the minimum hardware requirements guarantees that the system will be functional but it will
have overall performance impact (low response time from system).
This chapter contains the system design specifications along with the decisions and reasons that led to a
specific design.
The Design chapter is focused on how to deliver the functionality that was specified in the requirements
analysis whilst meeting non-functional requirements by making high-level decisions concerning the overall
structure of the system. System design is the most creative phase of the system development and is the first
step in moving from the problem domain to the solution domain. This section is perhaps the most critical
factor of the system development affecting the implementation and the quality of the final product.
Following the literature review analysis, I found that the appropriate design strategy for this project would be
a combination of the top-bottom and bottom-top. A research paper presented at the 7th Annual Industrial
Engineering Research Conference highlights the advantages of “blending of top-down and bottom-up”
(Terpenny, Nnaji, & Bøhn, 1998) design strategies which allow the development to be customized to a wider
range of application domains.
This strategy helps me to design and develop the functionality required by the client. Furthermore, using the
combined design strategies will simplify the process to develop a generic model. Reviewing the application
at any time will have no impact over the project.
The following sections are included in the remaining of this chapter: server architecture; programming
language; colours and style; system mockups and high-fidelity prototyping; database design; assumptions and
dependencies of this project.
In this section the chosen architecture pattern is presented and how the
project is structured at the conceptual level.
Note: The word client presented in this section is referred as a client for the
server and not the beneficiary of this project.
Following the literature review for server architectures and analysing the
advantages and disadvantages of different patterns I found that the optimal
solution for this project would be Client-Server architecture (CSA) (Figure
23).
I am considering that the CSA is the most suitable for this project because
the system needs to be accessed from various locations and devices (cross-
platform) Figure 23 – Client-server architecture
(Abstract) [Primary Source]
One of the advantages of CSA is the fact that the application files and the
database are installed on the same location (server). The system is modelled as a cluster of the different objects,
which is interacting with the database through a request handler. Using this architectural pattern, a successfully
communication between objects is a key element. None of the intermediate results, which are created through
the interaction, has to be visible to the Clients. To make an analogy, we can say that the server will act as a
“black-box”, which will return only the final results to the user (Figure 24 – For a bigger size picture please
see Appendix K).
To ensure a clear communication of the components between Client and Server, the system was divided in
four major sub-systems: Client-side Application, Server-side Application, Server Handler and Database. By
decomposing the processes on the server, followed by user interaction it leads to the integration of an object-
oriented design pattern. The Client application is separated into two subsections, the Client component
(Browser) and Client User Interface (CUI). All user inputs are taken over by the CUI and forwarded to the
server API where most of the processes are handled and the result is returned to the user through User
Interface. All data stored on client device are temporary therefore the impact on the user device is minimum.
The centralised control of the server offers the advantage of quick implementation of any future changes
without any disruption for the Client or just a minimum downtime until the new features are implemented
(usually no more than 1-2 hours).
One of the disadvantages of the Client-Server architecture is the single point of failure. If the server is not
working (e.g. hardware fault, power fault, data corruption, hacking etc.) the entire system is inaccessible.
Following my discussions with the project beneficiary he accepted this trade-off and we have agreed on a
mirroring solution to overcome this issue. However, this solution is still in the preliminary stage and would
be considered once the system is fully developed and approved by the client.
In this section I am presenting the principal system functions as Unified Modelling Language (UML) use
cases.
Use Cases are an excellent high-level (and implementation independent) starting point for describing
functionality and the relation between system and user (Narang, 2015). For this project I am using the standard
UML use case diagram, consisting of a use case diagram, with success/fail scenarios, triggers and success
measurements for each case. A brief narrative description of the flow events is held alongside the diagram for
each individual use case. The use cases are very effective because they are relatively informal, yet help to
define and capture a problem space in detail. (Foster, 2014).
The actors (admin, user/s) presented in use cases are potential users of the system, performing specific
activities. The scenario presents a theoretical response from the system to the user actions. The use case
presents the main flow of events (when no errors are signalled) and the alternative flow when user performs
abnormal actions not defined into main flow of events. Users notated with [X] are the users defined as where
user role allows defined in Requirements chapter.
Valentin Adamescu PJE40 - RBMS Page 47 of 105
UP872413 Retail Business Management System
Note: In this section only the following use cases are presented because the use cases are taking a
considerable amount of space:
Login (UC1) ● Logout (UC2) ● Registration Process (UC3)
For the complete series of use cases please see Appendix B to J where the following use cases are present:
Settings (UC4) ● Warehouse (UC5) ● Role Permission (UC6) ● Products (UC7) ● Product Purchase (UC8)
● Sale (UC9) ● Expenses (UC10) ● Accounting (UC11) ● Stock (12)
In this section I am presenting the system user interface mockups. Mockups are simple designs created with
Balsamiq software and shows at a very low level how the UI should look like and what actions could be
effectuated. The mockups were shown and discussed with the client before creating a more advanced
prototype.
The initial mockups changed slightly overtime due to different functionalities and implementations added but
the general layout structure was preserved (e.g. Left side dash board, buttons sizes and functionality etc.).
Many functions were implemented on the go creating dynamic views by coding and re-using blocks of code
rather than creating new designs.
The LOGIN and REGISTRATION screens (Figure 28) are simple forms that allow user to login and register
into the system and check the credentials against ones stored into the database.
Settings
Before adding a product to the database, a CATEGORY must be created (Figure 30) and a product will belong
to that specific category. A category may have one or more subcategories (e.g. Drinks as main category and
Soft Drinks, Fizzy Drinks Alcoholic Drinks as sub-categories). This feature will allow the user to sort products
on different criteria and there is no restriction on how many categories can be created.
Figure 30 - Products category list (LEFT); Create a new category (Right) [Primary Source]
Products
Once the category is created user can add a variety of products to the database (Figure 31). Must be noted that
adding products to the database would not be counted into the STOCK. A product quantity must be added to
the stock (see Figure 32). This is useful for the client to populate all the products he trades. The products will
be added to the stock every time when stock is changed rather than typing product details every time. A
product may be available in database as a record but can be out of stock. When product becomes available,
the client just adds the quantity of product to the stock.
Figure 31 - Products list where the user can see the entire available stock (LEFT); Add a new product to system (RIGHT) [Primary Source]
The client can find any supplier by consulting the suppliers list (Figure 33). Supplier details (name, company
email, etc.) can be exported as a PDF file or CSV. All suppliers and customers can be searched by name,
company (if available) or email address.
The system administrator has full control over group roles Figure 34. The admin role cannot be deleted and
can create unlimited additional roles each one of them with own permission. The permissions are granted
after the role is created using a simple matrix where admin just selects / deselects the permissions according
with user role.
Figure 34 - Group roles (LEFT); Group roles permissions matrix (RIGHT) [Primary Source]
Expenses
Expenses module (Figure 35) provides calculation of expenses for each warehouse and additional notes can
be added to bring clarification if required.
Figure 35 – Expenses List (LEFT); Adding a new expense (RIGHT) [Primary Source]
Figure 36 - High fidelity prototyping with Axure (Product List) [Primary Source]
Figure 37 - Current system dashboard (Left); High fidelity prototyping with Axure (Right) [Primary Source]
Note: The current system contains many other elements into the dashboard (Figure 37). Most of them were
added through reusing the code and creating new views, without having a mock-up in advance. Further
information about views can be found in Implementation chapter.
Colour scheme
The colour base of Albert Butcher LTD is white and a dark-red colour (#A1191C)
therefore the client insisted that the system will be mainly in red colour. Figure 38 - Albert Butcher front
shop [Primary Source]
General Layout
One of the aims of this project was to keep the layout as simple as possible with enough space between buttons
to be easily pressed on a touch screen device (e.g. a tablet). Using a responsive grid layout increased the
development speed without the need for multiple designs for different devices. Moreover, the layout resembles
a spreadsheet which is a familiar layout for many users. The responsive pages, are automatically adjusted to
the device screen they are accessed from.
Figure 41 - General layout of the system – User List (Left); Sale list (Right) [Primary Source]
All related menu and options are available on left hand side, clearly labelling the menu context and the user
does not need to navigate into endless options to find a specific function.
where the icon needs to be placed and dashboard is the name of the icon. An implementation into the page
can be seen in Figure 44.
In this section I am aiming to bring clarity over database selection process and the logical design.
Following the analysis of databases from section 2.3 for this project I decided to use MySQL Database.
However, at this time being no significant difference between MySQL and MariaDB in terms of design
constraints and SQL syntaxes I can say that the project supports dual database. At this point the system can
be very easy migrated/adapted MariaDB but this compatibility is not guaranteed for future versions of MySQL
and MariaDB.
For this project SQLite was not suitable because, as analyses showed, this database is suitable for low-memory
embedded devices, with no server connection. If I decide at a later point to extend the database this will be a
real issue because SQLite does not have a very good scalability.
Although the PostgreSQL has positive reviews for the queries performance, it is aimed for very complex
queries suitable for data warehouse type databases. For this project I do not consider that this amount of
complexity is necessary. Moreover, PostgreSQL contains a couple of syntaxes I am not familiar with and the
documentation seems confusing.
I will present the logical and physical design of database further in this section. dbForge software allows the
logical design to be exported to physical design producing automatically the required SQL code. Therefore,
the logical and physical design were developed simultaneously.
Before attempting the database design, I created the business logic flow as a unified modelling language
(UML) diagram (Figure 45). Creating the UML diagram, helped me to understand better how to design the
database and how entities are interconnected with each other.
Figure 45 - RBMS UML processing (Logic flow of the system) [Primary Source]
In Figure 47 and Figure 48 the system logic translated into database logic can be observed. The system was
broken down into separate entities that create the database.
The design and creation of the database was done at the same time due to dbForge powerful feature of being
able to design and create tables/attributes in the same. Furthermore, being able to test the database in real time
was another advantage.
Note: In Figure 48 the visual connections between the tables were removed for a better view of the table attributes, were in Figure
47 the connection between entities are shown along with the primary and foreign keys.
Figure 48 – Final database including PKs, FK and all attributes [Primary Source]
In this section I am presenting the chosen programming language and the MVC framework that I am
considering appropriate for this project.
In my second year I have undertaken the Web Script unit that was based on Node.js and JavaScript. I
personally struggled with Node.js programming language and considering the complexity of the project I
realised that lack of my knowledge may jeopardise this project.
Analysing the ASP.Net programming language, which has a complex page structure and unclear configuration
setting, made me aware of the time constraints for learning a new programming language in depth enough to
address the complex issues of this project.
Therefore, after a careful consideration I decided to use PHP programming language for this project as the
main programming (scripting) language without the need for exploring and learning a new programming
language (such as C# & F#) but rather to deepen the knowledge I already had. In addition of PHP, HTML,
CSS JavaScript libraries are used.
However, even with the knowledge already possessed this project was a very challenging task. A task that
concluded not only with increasing programming skills and learning of new techniques but in addition it
helped with communication and other soft skills.
Once I decided the programming language to choose an MVC framework for this project was another difficult
decision. The MVC model must support the following features:
✓ CRUD operations (Create, Read, Update, and Delete)
✓ Minimal code has maximum impact (support for code reuse)
✓ Rapid learning curve
✓ Scalable framework
✓ Actively developed and maintained by a core team
✓ Strong community support
Following my analysis among numerous frameworks for PHP 3 potential candidates remained:
▪ CodeIgniter (https://codeigniter.com)
▪ CakePHP (https://cakephp.org)
▪ Laravel (https://laravel.com)
The first eliminated was CakePHP because the syntaxes seemed
to be too complex, documentation was not easy to understand
and according to a research article, CakePHP has a very slow
response time (Botwe & Davis, 2015) for GET and POST
compared with other frameworks.
With the two remained frameworks the initial choice was
CodeIgniter due to previous experience to work with.
Unfortunately, the CodeIgniter being managed by a company is
quite slow to catch up with modern technologies (Stauffer,
2017) and features brought by industry. Therefore, the
modularity of Laravel prevailed. Laravel allows division of a
project into small modules where CodeIgniter does not have Figure 49 - Laravel test code example [Primary Source]
this flexibility.
Modular development feature was one of the main factors that led to the decision to use Laravel PHP
framework as backbone of the project, as well as the excitement to learn a new technology. The modular
In this section I am briefly highlighting the constraints of this project where the following requirements are
mandatory for system functionality. These requirements are requested by programming language and
framework presented in previous section.
System was developed and tested on a dual system with PHP v7.2.0/MySQL v5.7 and PHP v7.3.0/Maria DB
v10.1. The system should work on any server with PHP v7.0+ and MySQL v5.0.n / MariaDB v10+.
The recommended server to deploy this system on is Apache/Nginx but it can be installed on any server with
PHP/MySQL support.
Assumption: The RBMS user has the basic skills of operating a computer and how to navigate
through web pages.
Installation Constraints: Initial installation of the system must be done by an experienced user with
knowledge about server installation / configuration, upload files to a server using FTP protocol or server
management GUI, MySQL import/export procedure, editing the configuration file where the server settings
details are stored.
Server constraints: PHP version 7.0+, Mod Rewrite Enabled
Mandatory Extensions: OpenSSL; Fileinfo; Mbstring; Tokenizer; Zip Archive; PDO & PDO
MySQL driver; Curl
This chapter covers the main steps taken on the development process providing screenshots and instructions
of setting the development environment. Modules development, files structure and the tests results are
presented in this chapter as well.
For this project I have purchased a hosting server (http://uop.cloud) to allow the client to preview the
application anytime. However, for development and continuous testing I used a local server installed on my
personal computer. Using a local server eliminated the network delays and was easier to work with local files.
For the development stage the following tools were necessary: XAMMP; Visual Studio Code; Laravel
framework; Gimp; dbForge; various packs and libraries presented in section 1.5 of this document.
For this phase the main focus was to transform the static HTML pages into dynamic pages integrating the
required PHP code because the system VIEWs (details in section 7.2) were already created in high-fidelity
design phase.
In order to start the development of this project a local server was setup on a Windows based operating system.
The setup process is a straightforward process of downloading the executable available on XAMPP website
and following the install steps. Full instruction of the local server download, setup and possible
troubleshooting can be found at https://www.apachefriends.org/faq_windows.html.
The XAMPP comes with all the necessary tools preinstalled to run the MySQL/Maria DB database, HTML,
PHP, JS and JQ files.
The next step was to bring the theoretical design of the database as physical design into the server by directly
importing it from dbForge software. To import into XAMPP server we can choose one, out of two methods:
✓ Setup a direct connection between dbForge and XAMPP, where the DB is directly created.
Instructions available at https://docs.devart.com/studio-for-mysql
✓ Importing into XAMPP as SQL file http://localhost/phpmyadmin > Import.
Once the database core functions were functional the PHP framework was installed on the server. Full
installation of the Laravel PHP framework can be accessed at https://laravel.com/docs/4.2#install-laravel.
Note: Database functionality can be tested independent of PHP or Laravel
In this section I am aiming to present technical aspects of creating the connection between modules and
database in order to return results to the user. Creation of different modules will be presented in this section
as well. Due to length and complexity of PHP/HTML/CSS code only fragments of the code will be shown
(some files having over 700 lines of code).
PHP & Laravel
In order to send the request to the controller in Laravel framework a ROUTE must be defined (Figure 54). Each
route is a definition of the path to be followed by any module to interact with core functions or other modules.
Routes are placed in a file in routes folder. These routes files get loaded and generated automatically by
Laravel framework. Each module in the project is an independent piece of software adding functionality to
the whole system. The requests are notated like standard PHP with: GET, POST, PUT, DELETE.
Additionally, the route may be redirected from one module to another using:
Route::redirect('/here', '/there');
Further information and full description of routing are available on Laravel website
(https://laravel.com/docs/5.8/routing).
Note: Laravel terminology may be confusing for a beginner or for someone working for the first time with
this framework. A better description of routing is available from Chris Sevilleja
(https://scotch.io/tutorials/simple-and-easy-laravel-routing)
Figure 60 - Final models, controllers and views of the system [Primary Source]
I consider that one of the key aspects to creating modular systems is the organisation of files and folders.
Having a chaotic structure and project increasing in functionality, can soon become overwhelming. At a later
stage of development can be really difficult to figure out what is the purpose of a specific file, folder or
function.
Therefore, since the beginning I have been keeping a logical structure for the files, the file name representing
the functionality. For example, for the model all the file names are named on what model they define (e.g.
Sale.php, User.php, Warehouse.php); the controllers file contains the word controller (SettingController.php,
CustomerController.php etc.); view files contain the word blade and grouped in functionality folders
(create_sale_blade.php, profile_blade.php etc.). I am using word blade for views due to the naming convention
suggested by Laravel and the templating engine provided with the framework (Laravel, n.d.).
The business employees are English/Romanian speakers but most of them understand and speak English at a
very basic level. Therefore, I had been requested to build the system in Romanian. However, I did not consider
that to be a practical solution due to the following:
▪ ‘How the customer will understand the labels, if all the system labels are in Romanian, when an invoice
is printed out?
▪ ‘What if a non-Romanian speaker will be employed? Will the client change the system or force the
new employee to learn a system in a foreign language?’
▪ ‘What if in the future a new law will require that all systems used in UK retail market must be in
English? Will the client change the system or translate everything?’
Hence, I came with a practical solution of a multilanguage system. I already had all technological means
provided by framework. Laravel framework provides the option to place all the text labels of HTML files on
a single file inside the language folder. This technique requires to create a table in database where each
language has an ID. Furthermore, each language has its own file translated from a default language (in this
case English) then the controller changes the system language based on user preferences. For example, if the
user selects X language where language id =2 the controller simply returns the text labels for the X language.
In Figure 62 we see the example of how a multilanguage solution can be relatively simple implemented on
any system based on a PHP framework. The model has a single entry as Language (left); the function defined
in controller (middle) takes user input and returns the associated text (right) for the front-end user.
Another advantage of having a multilanguage system with English as default language, is the fact that a non-
English user may improve their English. By using the system frequently in English and being able to revert to
native language anytime if something is unclear, it could help the user.
At this point the system is available in 3 languages (English, Romanian and Turkish) (Figure 63) because
these are the languages I speak fluently. However, it can be translated virtually in any language just by adding
a translated file from English to that language.
A similar technique that was applied to multilanguage problem previously presented it was also, applied to a
multi-colour theme. The difference is that the system returns the full CSS file associated with a specific
colour.
The themed styles implemented in this project are all similar as integration and CSS files code, duplicating 5
times and each file with its own colour (Figure 64). A simple function placed in settings controller allows
the user to change a preferred colour scheme.
public function changeTheme($theme)
{
$rbms_general_setting_data = GeneralSetting::latest()->first();
$rbms_general_setting_data->theme = $theme;
$rbms_general_setting_data->save();
}
Furthermore, each CSS style is coded into view file using basic HTML code and the user is able to select a
colour (Figure 65). The function coded in controller reads the user input and saves the preference into
database.
Figure 65 - Style integration through HTML & PHP (Left); Front-end user view (Right)
In this section my aim is to present two methods applied in testing phases. First method is an automatic
integration testing technique where a software automatically tests the system against a set of predefined
parameters. The second method is visual performance testing where the system is manually inspected by
simulating various devices views.
The first method includes automated tests performed at the logical level of the system. This method will test
the code integration and any incompatibilities, error or bugs between modules. The second set of tests were
visual tests carried on the desktop screen and various viewpoint of mobile devices (mobile phone/tablet).
Automatic Integration Testing
Katalon Studio automatic test functionality is an excellent tool for writing and maintaining test scripts. The
carried tests are divided into four types:
▪ Unit Testing – analyses a small piece of code in isolation without being dependent on other function
▪ Integration Testing – built on top of unit testing and combines two or more functions/modules
▪ Functional Testing – follows the integration and tests if the results provide same output as required by
the end-user
▪ Acceptance Testing – this test checks if the output meets the requirements by checking the flow not
the functionality
For each function/module a test script is written defining what a particular function should do. The html/php
code is how the function/module will act. The script validates (or invalidates) what against how. If the test
validates all what parameters then the test will pass, otherwise will fail.
Once the script is completed, the same test would run continuously without rewriting the script. The software
provides useful feedback when a test failed making debugging very easy. A screenshot of the initial setup can
be seen in Figure 66. In Katalon I have created a logical structure of folders where the future test can be
grouped, based on modules and individual unit test of a specific function.
Figure 66 - Setting test unit with Katalon Studio – New Project (Left); Project default setup (Middle); Added test units for RBMS (Right)
[Primary Source]
The script is partially automatically generated by Katalon software and only the testing parameters need to be
specified. The script below is a unit test that checks for user name function.
Figure 68 - Test case for Settings (save and record to the database) [Primary Source]
Testing unit provides different detailed views of the test result, to be easier to debug a problem or to understand
why a test parameter was highlighted as warning.
However, a passed test does not guarantee a bug-free system, because it is impossible to cover all possible
variants of test parameters. Visual testing and continuous testing of all the functions when a new module was
added is a key factor to reduce possible errors and bugs that may appear. For example, implementing a new
module and not testing against already incremented modules can create issues at a later stage of the project
and it would be extremely difficult to trace the original issue.
For a full view of the test cases please see the test root explorer in Appendix L.
In this stage most of the tests were carried through Chrome Browser using the available option of Developer
Tools (Figure 69). This offers a wide range of pre-sets devices and creates viewpoint for each device, along
with different performance testing and simulation of online/offline environment. However, at a later stage
some tests were carried on real physical devices.
Figure 70 - Page load performance test (Left); Login View point (Right) [Primary Source]
In Figure 71 different stages of visual testing are presented, carried with a physical mobile device (iPhone
Xs). These tests required an internet connection and the system was accessed through a live server
(http://uop.cloud).
Setting up a live server was immensely valuable for me and for the client to save time. The client had the login
credentials to the live testing server and after each incrementation he directly tested the application with the
new implemented functions, providing constructive feedbacks sometimes immediately, sometimes no later
than couple of days. One of the feedbacks sent be the client can be observed in Figure 72.
In this chapter my aim is to assess the project development and critically evaluate the solution by comparing
the user requirements with the implemented features into the system. In section 8.1 a summary of system
functionality is listed. It comprises the bespoke features and those I believe are enhancing the system, as well
as applying to a generic model. A series of screenshots of the most implemented features are ending the chapter
(section 8.3)
I am aware that the system cannot be fully evaluated as a generic model with other business at this time.
However, I strongly believe that the additional implemented features are suitable as generic functionality for
other similar business. Due to the system modularity, if another business has a specific request, I am confident
that a solution can be found.
The system was primarily developed around a grocery shop and I believe when the client will extend his
business activity with clothing and digital products new issues may appear (e.g. a warranty note may need to
be added into product details or manufacturer country).
In this table
Core functionality bespoke for the business
No Description Status
Users account – functionality to register users and securely store the user name and password details into the
1 Complete
database; Password reset function.
Users Role - admin should be able to create, manage, delete other users; admin should be able to assign
2 Complete
different roles to other users.
3 Products – functionality to add a range of products to the system Complete
4 Custom Tax – functionality to add differential VAT rates to each product Complete
5 Expire date of products – functionality to alert the user when a product is about to expire Incomplete
6 Sale of products – functionality to keep track of sold products Complete
7 Invoice – functionality to automatically generate an invoice based on a customer and sold products Complete
8 Scan Sale – functionality to scan a product barcode and be automatically deducted from stock Incomplete
Stock Management – functionality to keep track of in/out products (purchased products from suppliers – sold
9 Complete
products to the customers)
10 Stock Notification – functionality to alert user when a particular product is under-stock in the system Complete
11 Email Notification - functionality to alert user when a particular product is under-stock through email. Incomplete
12 Customers/Suppliers – functionality to have lists with customer/supplier details Complete
13 Expenses – functionality to record into the system different expenses that occurred during a month Complete
14 Reports – functionality of printing out: a daily/monthly list of sales; daily/monthly list of purchases Complete
15 Multi Warehouse – functionality to have separate warehouses (shops) and stocks Complete
16 Cross-platform – functionality for the system to be accessed from a range of devices Complete
17 Online/Offline – functionality for the system to not be dependent on an internet connection Complete
18 Language – system to be available in Romanian language Complete
Additional features that enhance the system and are suitable as a generic model
No Description Status
Enhanced Product Details – product picture upload; automatic product code generator; notes; purchase
1 Complete
price and sale price in different columns;
2 Product Category – customisable categories for products Complete
Product Barcode – automatic barcode generated for print to be stick on a product (this barcode can be used
3 Complete
later on to implement a scan product function)
4 Product Sale Unit – customisable unit sale (e.g. Kg, g, Piece, Pint, Pack etc.) Complete
5 Brands – a customisable list of brands where more than one product can belong to a specific brand Complete
6 Stock Count – functionality to compare digital stock with physical stock Complete
In this section my aim is to discuss the system features that have not been implemented until this point and
the system limitations. However, some of these flaws and missing features I will address them in future
updates of the system.
Stock adjustment - One of the system flaws identified by the client during the testing phase was the fact that
there was no possibility to make stock adjustments after a stock-count was carried out. In order to address this
problem, I will be introducing a stock-adjustment module, where the user will be able to edit the current stock
and add/extract the number of products from stock.
Batch integration – Another flaw of the system identified during the development of the project, but due to
lack of knowledge it was not possible to implement until this stage, is an efficient batching system. Some
products sold by the client have different expiration dates. Therefore, the client ensures that the products near
the expiry date are sold first constantly. A batching system should permit the user to assign different expiration
dates to the same product and alert the user when a specific batch is near its expiration date. A temporary
solution of this problem was to add a note field into purchase section where the client types any relevant note
about that specific purchase for his reference.
The batch method will be useful if the same product is purchased from multiple suppliers. It will help the
client to identify which supplier provided a specific product. Moreover, I am considering that a batching
system will be very useful for a business that sells medicines (a pharmacy), where expiration dates are critical.
Automatic email notification – One of the client requests was to be notified when a particular product is in
stock below a pre-set quantity. At the current stage of the project, the client is notified through the dashboard
but the system does not send email notifications to the admin. However, during my discussion with the client,
we considered this is not a crucial factor and it can be reviewed at a later stage.
During the testing phase of the system with other employees in the store, I was asked many times ‘what does
this button do or the other’. In order to address this issue and to clarify different functionalities of the system
to a potential user I am planning to implement an interactive user manual (Figure 73). A second PDF manual
✓ Registration and Login function; Forgot Password, User List; User Role; Role Permission; Languages;
Customisable Business name; Currency; Logo; Colour Theme
Figure 74 - Login, User List, User Role, Role Permissions; Language; Settings [Primary Source]
Valentin Adamescu PJE40 - RBMS Page 80 of 105
UP872413 Retail Business Management System
✓ Products List; Product Details; Barcode generator
Figure 77 - Add a new customer (Left); Add a new supplier (Right) [Primary Source]
✓ Sales Report –
Figure 81 – Expenses List (Top); Expenses Categories (Bottom-Left); Add Expense (Bottom-Right) [Primary Source]
Figure 82 - Account (Top); Account balance sheet (Middle); Account statement (Bottom) [Primary Source]
Figure 83 – Employees List (Top); Attendance Recording (Middle); Departments (Bottom) [Primary Source]
In this chapter I would like to discuss potential features and functionality that could complement the system
to be more flexible and suitable for a larger pool of users and/or business.
The client uses the application on testing server and we created a second instance of the application where he
started to add his products to the database. He is planning to use it as the only system for his business
management once all products, customers and suppliers are added to the system. As soon as all the data is
inserted, the client will migrate the system to his own server.
Following my discussion with the client, who was delighted with the system capabilities which covers all his
requirements and many more other features, we found that the system can be further improved:
• An implementation of a POS (point of sale) screen that can be accessed through a touch screen
monitor suitable for direct sale in store (walk-in customers). This feature is in a very early
development phase at the moment of writing
• A solution for separated batches for the same product (e.g. with different expiration dates or different
manufacturer)
• Integration of a barcode scanner, where sold products to be scanned and automatically deducted from
stock, rather than typing them
• Integration of automatically debit/credit card processing on sale through Barclays payment solutions
• A mobile phone message alert when a particular product/s in understock (probably a WhatsApp
plugin integration)
• To increase security a 2-way factor authentication for online server
I have found this project really challenging and I have learnt many lessons during the development. The most
significant lesson that any programmer, project manager or software engineer should be aware of, is planning.
Planning ahead is essential as will not save only time and money but also is a decisive factor for the project
success or failure. Needless to say, I was unable to predict 100% all the challenges that the project encountered.
Hence, the communication emerged.
I have been aware since my 2nd year that for the final year an engineering project must be submitted therefore,
I was extremely pleased when Mr Ovidiu D. (the client) approached me and asked if I could help him with a
solution for his business. When he explained me the problems he was facing, I knew that creating a bespoke
system would be the ideal topic for my final year project. It was a real advantage that the client was always
available, answering all my questions at any time (sometimes we were chatting at 2am). I believe that if I had
chosen a conceptual idea without working with real client, I would not have been able to deliver a complex
system.
The Introduction to Software Engineering (INSE) unit I took it in 2nd year at the University of Portsmouth,
was a cornerstone for this project. Many methods, logic approach and ways of handling complex projects are
a result of this unit. Even if I had previous experience with handling small and medium size projects, I always
adopted a sit and do it approach, rather than an exhaustive planning.
The biggest risk I took was choosing an unfamiliar framework for development. This was the first time to
work with Laravel. Previously I opted for CodeIgniter framework, but I was determined to succeed and learn
something new at the same time. Thus, Laravel was the optimal selection. Not only that the project has evolved
beyond its initial purpose, to create a stock management system with few other functionalities, but I believe
that, it has also become a full standalone business management system yet with opportunities for further
enhancements.
My previous coding experience and probably being a mature student have enabled me to approach this project
from a different perspective than probably I would have done in my 20’s. There were a lot of new things to
learn and having some technical skills does not make me a successful developer or programmer. I have learned
that one must have the following soft skills: time management, effective communication, adaptability problem
solving and creative thinking.
Taking on an individual project, I had to wear different hats: as a designer, a coder and a student who learned
a new framework. I had to improve my technical and soft skills. It was challenging to take several crucial
decisions but also to keep up with the project timeline and other university related deadline. I maximized my
time management skills to make sure that all the tasks were getting the proper attention.
Another lesson learned during this project is the value of simplicity. One of my goals was to maintain a high
standard across the entire application and to keep it simple. I strongly believe that extensive over-engineered
systems definitely cause more unnecessary problems than under-engineering systems. Therefore, my focus
was on writing the code in a clean and elegant manner, as well as retaining conventional functions and file
naming.
However, I envisage that simplicity it is not always an option for multiple teams working together on large
projects.
Figure 92 - Use case for user Permission Matrix module [Primary Source]
Figure 94 - Use case for Purchase modules (Add to stock) [Primary Source]