Ian Mburu

CHUKA UNIVERSITY
FACULTY OF SCIENCE, ENGINEERING AND TECHNOLOGY

DEPARTMENT OF COMPUTER SCIENCE & ICT
COURSE UNIT: COSC 483

COURSE TITLE: COMPUTER SYSTEMS PROJECT 2
TOPIC: RETAIL MOVIE STORE MANAGEMENT SYSTEM
IAN MBURU - EB1/28018/16

SUPERVISOR: MS JANE KIRUKI
SUBMITTED BY IAN MBURU TO CHUKA UNIVERSITY, IN PARTIAL

FULFILMENT OF THE REQUIREMENTS FOR THE DEGREE OF
BACHELOR OF SCIENCE (COMPUTER SCIENCE)
DATE OF SUBMISSION
13/10/2020
1
TABLE OF CONTENTS
LIST OF ACRONYMS.............................................................................................................................6
ABSTRACT...............................................................................................................................................7
CHAPTER ONE........................................................................................................................................8
1.0 INTRODUCTION.....................................................................................................................8
1.1 BACKGROUND INFORMATION................................................................................................8
1.2 PROBLEM STATEMENT.............................................................................................................9
1.3 PROPOSED SOLUTION..............................................................................................................10
1.3.1. GENERAL AIM OF PROJECT...........................................................................................10
1.3.2 SPECIFIC OBJECTIVES......................................................................................................10
1.4 JUSTIFICATION/SIGNIFICANCE OF THE PROJECT.........................................................10
CHAPTER TWO.....................................................................................................................................11
2.0 LITERATURE REVIEW.................................................................................................................11
2.1 INTRODUCTION.........................................................................................................................11
2.2 SEARCH........................................................................................................................................11
2.3 BACKGROUND REVIEW...........................................................................................................12
2.4 EXISTING SYSTEMS..................................................................................................................12
2.5 THE PROPOSED SYSTEM.........................................................................................................13
CHAPTER THREE.................................................................................................................................14
3.0 METHODOLOGY............................................................................................................................14
3.1 APPLICATION ANALYSIS........................................................................................................14
3.1.1 Feasibility Study......................................................................................................................14
3.1.2 Requirements Feasibility........................................................................................................14
3.1.3 Technical Feasibility...............................................................................................................14
3.1.4 Economic feasibility................................................................................................................14
3.1.5 Operational feasibility............................................................................................................14
3.1.6 System Analysis Tools............................................................................................................14
3.2 APPLICATION DESIGN.............................................................................................................15
3.2.1 Use Case Diagram...................................................................................................................15
3.2.2 Flow Chart Diagram...............................................................................................................15
3.2.3 Database design.......................................................................................................................15
3.3 APPLICATION IMPLEMENTATION.......................................................................................15
3.4 SYSTEM IMPLEMENTATION TOOLS...................................................................................16
2
3.5 APPLICATION TESTING...........................................................................................................16
3.6 APPLICATION DEPLOYMENT AND MAINTENANCE.......................................................17
SYSTEM ANALYSIS AND REQUIREMENTS SPECIFICATION...................................................18
4.0 INTRODUCTION.........................................................................................................................18
4.1 PURPOSE......................................................................................................................................18
4.2 SCOPE OF THE SYSTEM...........................................................................................................18
4.3 ASSUMPTIONS............................................................................................................................18
4.4 OVERVIEW OF THE DOCUMENTS........................................................................................18
4.5 FUNCTIONAL REQUIREMENTS.............................................................................................19
a) Registration..............................................................................................................................19
b) Login.........................................................................................................................................19
c) Profile Account........................................................................................................................19
d) Inventory..................................................................................................................................19
e) Sales..........................................................................................................................................19
f) Reports.....................................................................................................................................19
g) Schedules..................................................................................................................................20
h) Profile Exit...............................................................................................................................20
i) Profile Deletion........................................................................................................................20
j) Dashboard................................................................................................................................20
Use Case Diagram of the System........................................................................................................21
4.6 System Requirements....................................................................................................................22
4.6.1 Operating System....................................................................................................................22
4.8 Design Constraints.........................................................................................................................22
4.8.1 Standard Development Tools.................................................................................................22
4.8.2 Java Based Product................................................................................................................22
4.8.3 On-line User Documentation and Help System Requirements............................................22
4.8.4 Development Tool...................................................................................................................22
4.9 Non-Functional Requirements......................................................................................................22
4.9.1 Graphical User Interface........................................................................................................22
4.9.2 Security....................................................................................................................................22
4.9.3 Performance relationship.......................................................................................................22
CHAPTER FIVE: DESIGN....................................................................................................................23
5.1 Introduction...................................................................................................................................23
3
5.2 Purpose...........................................................................................................................................23
5.3 Assumptions...................................................................................................................................23
5.4 Constraints.....................................................................................................................................23
5.5 System Environment.....................................................................................................................23
5.6 Process Design................................................................................................................................24
5.6.1 Product dataflow.....................................................................................................................24
5.6.2 User characteristics.................................................................................................................24
5.6.3 Operating environment..............................................................................................................25
5.7 USER INTERFACE DESIGN......................................................................................................28
5.7.1 Introduction............................................................................................................................28
5.7.2 State of Controls.....................................................................................................................28
5.7.3 Error Handling.......................................................................................................................28
5.7.4 Dimensions and Constraints..................................................................................................28
5.7.5 Functionality Representation.................................................................................................28
5.7.6 Dashboard Interface...............................................................................................................29
5.7.7 Account Registration..............................................................................................................29
5.7.8 User Login...............................................................................................................................30
5.7.9 Enter sales...............................................................................................................................30
5.7.11 Display Sales..........................................................................................................................32
5.7.12 Show Reports........................................................................................................................32
5.8 Database Design.............................................................................................................................33
5.8.1 Client-Server Architecture.....................................................................................................33
5.8.2 Database Entities....................................................................................................................34
5.8.3: Entity Relation Diagram:......................................................................................................37
5.9 Security Features...........................................................................................................................37
CHAPTER 6: SYSTEM IMPLEMENTATION...................................................................................38
6.1 User Interfaces...............................................................................................................................39
6.1.0 Homepage................................................................................................................................39
6.1.1 Sign in interface of the staff and admin................................................................................43
6.1.2 Administrator (admin)...........................................................................................................44
6.1.3 Manager (mgr)........................................................................................................................47
6.1.3 Employee.................................................................................................................................48
CHAPTER 7: SYSTEM TESTING.......................................................................................................52
4
7.0 Introduction...................................................................................................................................52
7.1 Participants....................................................................................................................................52
7.2 Features to be tested......................................................................................................................52
7.3 Testing Procedures........................................................................................................................52
7.4 Test Tools:......................................................................................................................................53
7.5 Test Cases.......................................................................................................................................53
7.5.1 Developer Unit Testing...........................................................................................................53
7.5.2 Developer Functional Testing................................................................................................53
7.6 Test Summary Reports..................................................................................................................54
7.6.1 Unit testing..............................................................................................................................54
7.6.2 Integration Testing.................................................................................................................56
7.6.3 System Testing........................................................................................................................56
CHAPTER EIGHT:...................................................................................................................................58
CONCLUSION AND RECOMMENDATIONS.......................................................................................58
CONCLUSION.....................................................................................................................................58
RECOMMENDATIONS.......................................................................................................................58
CHALLENGES.....................................................................................................................................58
APPENDICES.........................................................................................................................................59
Appendix I: Estimated budget for the project...................................................................................59
Appendix II: Time Plan.......................................................................................................................61
Appendix III: Questions asked for Data Collection..........................................................................62
References................................................................................................................................................63
5
LIST OF FIGURES
Figure 1 Use Case Diagram...........................................................................................................22
Figure 2 Data Flow Diagram.........................................................................................................25
Figure 3. System Environment Overview.....................................................................................26
Figure 4. Activity diagram for admin management activities.......................................................27
Figure 5. Simple Activity diagram for secondary account management.......................................28
Figure 6. Simple Activity Diagram for the Employee Account....................................................28
Figure 7 ERD Diagram..................................................................................................................38
Figure 8. Implementation Stages...................................................................................................39
Figure 9. Isolated home menu.......................................................................................................42
Figure 10. Homepage as a whole...................................................................................................44
Figure 11. Login page....................................................................................................................45
Figure 12. Log report as generated by the admin..........................................................................46
Figure 13. Media Purchases Records as invoked by admin..........................................................47
Figure 14. Successful insertion of employee (user).......................................................................48
Figure 15. Error as manager attempts to delete admin..................................................................49
Figure 16. Error as employee attempts to read log reports............................................................50
Figure 17. Employee successfully goes on recording a sale.........................................................50
Figure 18 Inventory page...............................................................................................................51
Figure 19. Purchase page...............................................................................................................51
Figure 20 Sale Page.......................................................................................................................52
Figure 24 Developer Testing Methodology...................................................................................54
Figure 21. Customer Management Logic Test..............................................................................55
Figure 22. Media Purchase Logic Test..........................................................................................56
Figure 23. Main Logic Test...........................................................................................................57
Figure 25 Budget...........................................................................................................................61
Figure 26 Time Plan......................................................................................................................62
6
LIST OF ACRONYMS
1 SQL – standard query language
2 ERD – Entity Relationship Diagram
3 XAMPP – Cross-platform(X), Apache(A), MySQL(M), PHP(P) and Perl(P)
4 IDE – Integrated Development Environment
5 SRS – System Requirements Specification
6 P.K – Primary Key
7
ABSTRACT
In day to day activity there arises a need for entertainment to unwind and be ready to resume
official duty. In recent times, youth in Kenya have undertaken such roles as to provide
entertainment products including audio files, video files and other media items using peripheral
devices such as CDs and Flash drives. This business paradigm has eliminated the previous
system of larger enterprises such as cinemas that charged extravagant prices to access their
services; a system that could not be sustained by the lower social classes (middle and lower
class). While this new system tends to all people in the community, it is faced by a challenge of
inadequate or even total absence of a system that can be able to serve such smaller enterprises
and enable proper record keeping and transparency. Thus a thought to develop a system devoted
to promote proper book keeping and also offer some accurate statistics into the customer tastes
and preferences.
The retail movie management system is a system based on the two levels of users; the proprietor
and the consumer, with an employee being an abstraction of the proprietor. In simple illustration,
the proprietor interacts with the system and enters the consumer (also known as the customer) as
needed; granted their level of interaction with the customer as per their business acumen. Thus
the proprietor monitors the sale and distribution of their media items including the sale statistics
based on consumer requests. He/she also benefits via categorization of the media items sold such
that they can easily predict what a particular consumer in the system is likely to consume or may
have consumed before. In doing so they offer better customer service.
8
CHAPTER ONE
1.0 INTRODUCTION
In today’s modern world everyone is striving to use technology to either access goods and
services or materials for learning, selling and so much more. In relation to that, thousands of
management systems have been developed and thoroughly tested for use in various enterprises.
These systems have become of large assistance to institutions and entrepreneurs; assisting them
in their everyday operations as they are often specialized to serve in their respective domains. In
essence they have become so essential that they have formed part of the basic functionality and
overtaken previously used inefficient methods of undertaking operations such the pen-and-paper
systems.
Pertaining the use of such technologies, most systems have been adapted or specialized from the
initial stages to serve larger systems. These have been deemed to be “more viable” by most
developers and as such even in the entertainment industries most software is used for large scale
production, distribution and selling. Most software developed either serves the individual or is
directly scaled to a massive production structure often overlooking smaller subsystems that when
put together develop into a substantial demography of the entertainment industry. Thus these
smaller individual enterprises do not have reliable systems through which they can undertake
their operations and become even more efficient beyond the memory of the proprietor and a
couple of heuristic guesses in the service of their customers.
Therefore, there became a thought of a system that is specifically tailored to meet the needs of
these enterprises. The system aids in monitoring of sales and available content/material. It also
allows for creation of consumer profiles so as to keep record of individual consumption which
forms the basis for recommendation of future products for consumption based on previous tastes
of media items. This will also help in accounting, transparency and reliability of the enterprise as
an autonomous system since the operations logged can be used in further decision making of the
enterprise. This is in disregard of the physical or economical size of the system and is not
dependent on these factors.
1.1 BACKGROUND INFORMATION

In the being of a scholarship in the field of technology there became an inspiration to think of
how to use technology to ease consumption of media items and keep smaller enterprises going
beyond initial capital investment both for:
i. the consumers; who collectively from the community in which we live,
ii. and the youth; who have often rose beyond the face of adversity to create employment
opportunities for themselves.
Due to the importance accorded to larger and highly scaled applications, little or no attention is
given to medium and small enterprises that are forced instead to rely on the entrepreneur even for
9
small tasks that can easily be accomplished with the use of a simple system such as schedules as
well as important tasks such as inventory and sales that are useful in decision making of matter
affecting the business. Additionally, the business models based on the operator rather than
accurate statistics open up the small businesses for funds misappropriation and “cooking” of
business records by unscrupulous employees and workmen.
Therefore, by using this system, the proprietor will be able to get sales records and in aggregate
maintain clean books of accounts albeit electronically. They shall also be able to have reliable
data which they can use for making important decisions concerning the business in terms of sales
and customer preference records obtained from the sales. This will also come in handy when
projecting growth of the business over certain fiscal periods e.g. quarters of the year. In addition,
the proprietor will also have a more accurate measure of predicting material that can be
consumed by certain customers of their choosing, ideally, loyal customers and therefore offer
better customer service in general.
1.2 PROBLEM STATEMENT
Due to the unavailability of sufficient software to help in the management of small and medium
scale retail stores, there has been a problem of maintaining proper records of sales and inventory
resulting in unsustainable business models and high odds of business failure. In addition to this
you may find that the whole system relies upon the memory of the proprietor to remember the
materials already consumed by customers or they are forced to initiate a question and answer
interview for any spontaneous session that the customer has walked in to purchase fresh material
to determine whether or not such a customer has viewed such content.
This extends even to simple routines such as replacement or addition of content such that the
whole model is based solely on the proprietor’s state of mind rather than the customer service
delivery. Additionally, in a bid to remember past events such as when last they restocked their
content with fresh material, the operator loses consciousness of important upcoming matters such
as what material has been requested as a pre-order by existing loyal clients.
The consequence is that basically even when help in the form of employment has been sourced it
is very hard to run the business in absence of the proprietor and often the new operator has to
acquaint himself/herself with all the material in order to offer suitable suggestions for viewing as
well majority of customer tastes; leaving no room for further improvement.
One other major repercussion is that without proper book keeping and the time spent learning
and re-learning as well as a non-optimized environment based on the operator’s memory, most
businesses tend to fail before operating a full year. All these factors inspired me to come up with
this project.
10
1.3 PROPOSED SOLUTION
1.3.1. GENERAL AIM OF PROJECT
The aim of this project is to develop a retail movie store management system that fits into the
needs of the smaller movie store enterprises in terms of record keeping and business
accountability.
1.3.2 SPECIFIC OBJECTIVES
I. To enable the retail movie stores to maintain proper sales records of the business
II. To enable retail movie stores to maintain a proper inventory of their business
III. To enable retail movie stores to focus more on customer delivery based on more accurate
consumption records than a generalized view based on stereotypes
IV. To enable proprietors to focus more on capital management than easier but more intense
tasks like material preferred by specific customers
V. To enable movie stores to predict more accurately consumption preferences of various
customers
1.4 JUSTIFICATION/SIGNIFICANCE OF THE PROJECT
Retail movie store management system is set to enable the businesspeople who have long been
intimidated by complex and tedious book-keeping procedures to attain an easy system of records
maintenance away from individual dependence. This system also encourages a more serious
approach towards the business operations as an enterprise as opposed to the common perception
of an informal establishment that is temporary and short-lived due to poor planning and decision-
making (mostly attributed to poor record-keeping and lack of necessary data).
11
CHAPTER TWO
2.0 LITERATURE REVIEW

2.1 INTRODUCTION
Most small businesses in Kenya and the sub-Saharan region are vastly dependent on the
proprietor for all operations and are not ICT enabled. They are extremely dependent on the
capability of the operator as something analogous to a memory chip cum business person rather
than be propelled to success based on the business acumen of the individual or collective
entrepreneur(s). Nevertheless a few efforts have been made to improve upon this model by
introducing the use of computers.
Technology is advancing very fast and due to these advancements, there is need to cope up with
them. ICT plays a key role in every country’s economic development and thus every industry.
Over the last decade, Kenya has experienced substantial growth in ICT and the priority accorded
to this field increasing, with the period between 2013 and 2014 seeing up to 8.4 percent
improvement in this sector (Ogutu, 2015).
“Since 2000, Kenya’s economy has grown at an average of 3.7 percent. Without ICT, this
growth would have been at 2.8% and per capita income would have stagnated” (Ogutu, 2015).
During the first decade of the 21st century, ICT was responsible for the growth of approximately
one-quarter of Kenya’s GDP, this shows the impact of ICT influence on the country.
Kenya has been ranked among the top 5 African countries with the fastest growth in
telecommunications, infrastructure and mobile money innovations (Ogutu, 2015). The engine
behind the rapid growth has been mobile telephony which has caused a mobile revolution in the
country. Mobile penetration in Kenya is currently at 82.6 per cent with 33.6 million subscribers,
proving that the mobile phone is an important tool in transforming lives.
ICT plays a large role in our day-to-day lives, addressing challenges facing Kenyans in general.
Particular sectors such as finance, health, education, agriculture and the government are quickly
embracing technology for dissemination of information, enhancement of service delivery and to
reach their customers more effectively and efficiently. (Mugambi & Theuri, 2014)
2.2 SEARCH
Over the internet, I came across a lot of articles that were written by various software developers.
The articles were describing the different management systems that had been developed and
deployed. I saw what I am supposed to change or make improvements in my system that I will
be developing. I also learnt some details that were a must to be included in my system. Reading
through the articles and scholarly materials widened my mind and gave me a better
understanding of my system. In short, the literature review has a positive impact on the
expectations of my system.
12
It is important to go through journals and several other sources of information so as to widen
ones’ understanding of system development and how better I can make my system to be. I can
see what I can improve or add to my project idea.
2.3 BACKGROUND REVIEW
During the movie industry’s first century, movie theatres represented the first release retail
market for the film industry. Until movies were first broadcasted on television in the 1950s and
later became available on video, they could only be viewed in a movie theatre. Moreover, until
the recent introduction of alternative digital delivery technologies and big screen televisions, the
primary medium for watching movies has been in movie theatres (McDonnell & Sliver, 2007).
The cinema suffered a considerable decline with the development of the television from the
1950s. The introduction of new competing technologies broadly corresponds to declining movie
theater attendance over time. It also indicates that the mass movie-going audience fragmented as
more TV substitutes emerged over time to provide alternative entertainment options.
Owing to the relatively recent, dynamic growth of the home video market current release
between videos and movie theaters have been shrinking. Thus most existing systems seen over
the time have long been pegged on massive enterprises showcasing various visual content. Such
systems include management systems that have long incorporated characteristics of large
enterprises into their working, such as ticket management. These may not be applicable for the
modern day retail ship that allows viewers to pick their desired content and view it at their own
discretion and comfort. As a result, a lot of these systems and especially software systems have
found little or no use when it comes to smaller enterprises that are more downscaled and whose
management is viewed as relatively “unprofitable” as compare to systems of larger enterprises.
(Funk, 2006)
2.4 EXISTING SYSTEMS
One of the existing systems is the Video Rental Plus which is a video store software for video
rental and DVD stores. It has an interface system that is optimized for both rentals and sales. It
allows to keep track of all sales and rentals, keeps a history of customer information and
provides reports for the business. It is easy-to-use, reliable and cost effective. It however lacks
any predictive abilities based on previous user data.
Secondly, there is the Gatekeeper Systems. It is a management system that is used to keep a
record account of products, employees, assets and customers. It is also used to record customer
experiences. Its main advantages are cart retention and management, push out prevention (loss of
prevention with a focus on customer experience). It also produces some statistics of the sales for
user analysis. However, it is not cost effective and does not optimize use of available resources.
Third was the Blockbuster video, simply called the Blockbuster. It is an American-based
provider of home movie and video game rental services. It also rents via cinema theatre. The
statistics were calculated for use in future decision-making by the concerned enterprises.
However, it was scaled to big stores and cinemas and could not offer personalized statistics for
13
increased sales. As a result, the system was quickly phased out to being obsolete, especially
when coupled with equally obsolete technology such as DVD-by-mail routines. (Mohan, 2013)
2.5 THE PROPOSED SYSTEM
Retail movie store management system is a management system aims at solving the management
issues and deficiencies using local solutions. It works towards filling the gaps left by existing
systems which are either very inefficient or non-existent at all:
a) It is a responsive optimized system that can easy be dependent on existing resources such
as personal computers which are used in the enterprise’s main operations hence already
available
b) It aims at reducing use of stereotypes and inaccurate guesses at a client’s expectations
and general experience
c) Storing, searching and retrieval of records will be simple and efficient thus eliminating
unneeded complexity
d) Customer service shall be enhanced by categorizing content and predicting more closely
based on these divisions what a consumer intends to purchase
14
CHAPTER THREE
3.0 METHODOLOGY
In daily basis more enterprises are being opened to serve the niche of reliable entertainment
means by providing quality, affordable, and readily available visual content. Therefore, the
demography targeted to implement the system for advancement is increasing by the day. This
has made it possible for this system to work as intended.
The proposed system will be developed using incremental process model. This is because it
allows gradual development, as mistakes are being corrected and evaluation can be done at initial
stages of development, and new functionalities can be defined for later increments.
3.1 APPLICATION ANALYSIS
3.1.1 Feasibility Study.
The feasibility study was done during my attachment period and also shared with my fellows
about having a system to manage retail movie stores.
3.1.2 Requirements Feasibility.
Retail movie store management system will be easy to use for the operator regardless of whether
they are the business proprietor or an operator operating on voluntary or employment status with
authority of the proprietor.
3.1.3 Technical Feasibility.
Under this feasibility this system will be able to give a user friendly feedback in any case of any
error that may result from either user activity within the system.
3.1.4 Economic feasibility
Retail movie store management system will be cost efficient since there shall be no more
complimentary products needed for purchase. The installation will consist of a simple setup that
can be installed and ready for use.
3.1.5 Operational feasibility
This system is straight forward that is very easy to use as a first time user and also easy to
manage and maintain.
3.1.6 System Analysis Tools
a) Interviewing and Online Questionnaire:
Interviewing will be used as the data collection technique since the it will enable for
information collection about the challenges encountered during the management process
from the professionals in the industry.
b) Observation:
Observation will help to learn the intricacies of the current system on a superficial level;
to be complimented by informal interviewing.
15
3.2 APPLICATION DESIGN
3.2.1 Use Case Diagram
Shows representation of a user's interaction with the system, depicting specification and
association relationships. A use case diagram can portray the different types of users of a system
and the various ways that they interact with the system. This type of diagram is typically used in
conjunction with the textual use case and will often be accompanied by other types of diagrams
as well.
3.2.2 Flow Chart Diagram
Flow charts will be used to show the flow of data within the system. Flow charts are easy to draw
and interpret because they are straight forward. They can be used to model the flow of data as the
user key in data. Though, flowcharts are useful in efficient coding, debugging and analysis of a
program, drawing flowchart in very complicated in case of complex programs and often ignored.
3.2.3 Database design
My database design exists of identifying areas that need persistent data storage and the type of
database most suitable; whether relational, non-relational or less often the disk storage.
3.3 APPLICATION IMPLEMENTATION

The implementation will use agile method which is based on the incremental methodology which
makes it easier to focus on each module at a time, while also enabling easy detection of
functional and design bugs. In order to achieve the incremental model approach that is system
specification, development and validation. The following are some of the approaches:
a. In this section, there shall be collection of some of the application requirements.
Furthermore, there shall be the use of questionnaires, observation, reading of documentation
of existing same applications such as the Gatekeeper Systems in order to accomplish this.
This would aid me in specifying most of the application requirements.
b. Designing the App Architecture. designing most of the application high and complex
functions.
c. Coding: actual coding of the application
d. Testing: testing the application using different testing types to ensure the application works
well before deployment for use.
Importance of using incremental
 Parallel development can be planned.

 Results are obtained early and periodically.
 Progress can be measured.
 Less costly to change the scope/requirements.
 Testing and debugging during smaller iteration is easy.
16
 It supports changing requirements
 After every increment an operational app is provided.
 Working functionality can be quickly and early.
Challenges of using incremental
 The end of the project may not be known.

 Failure to properly plan and design the app may make it difficult to break down and build
the app incrementally.
Reasons of Using Incremental
 The app bugs can be fixed at an early stage.
 User can respond to each built interface and give feedback
 It lowers initial development costs.
 Gives room for future changes that the users may require.
3.4 SYSTEM IMPLEMENTATION TOOLS

i. Laptop
ii. Programming Software
a. Netbeans IDE
iii. Programming Languages and Techniques
a. Back end: Java
b. Database: SQL
c. Front End: Spring/ Javax XML
iv. Hardware Requirements: Core i3 processor, 4 GB RAM, 500 GB Hard disk
v. Databases
a. MySQL Database: this database will be used to store permanent records such as
logs and customer information
b. XAMPP server
3.5 APPLICATION TESTING

 Unit Testing
The system will be tested using the Junit framework to test the working of each app module that
is, the registration, logging and general storage of data. It also allows for checking of bugs on the
same.
 Incremental Integration Testing
The system shall be tested from an overall perspective to test the integration of every module
with each other iteratively as supported by the JUNIT framework.
17
Continuous testing of the system will be done as new functionality is added. The various aspects
of the system’s functionality will be made independent enough to work separately before all
parts of the system are completed.
 Regression Testing
This involves re-testing the system after fixes or modification are made on the system. The
developed system will be tested after new modifications are made.
 Security Testing
The system will be tested to determine how well it protects against unauthorized internal or
external access to ensure maximum security.
3.6 APPLICATION DEPLOYMENT AND MAINTENANCE

The application deployment will be offered to an existing enterprise on a bona fide basis and of
which will also serve as advanced user testing to offer user feedback on the application.
Future versions shall be installed atop the existing platforms to override the previous versions.
3.7 RESOURCES REQUIRED
The main resources required for my project completion can be broken down to individual
necessities (well summarized in Appendix (I)). The items are estimated and recorded as at the
present pricing of each item.
18
CHAPTER FOUR
SYSTEM ANALYSIS AND REQUIREMENTS SPECIFICATION

4.0 INTRODUCTION
This section provides an overview of the entire System Requirements Specification (SRS) with
purpose, scope, definitions, acronyms, abbreviations, references and overview of the SRS. The
aim of this document is to gather and analyze and give an in-depth insight of the complete
system by defining the problem statement in detail. The detailed requirements of the system are
provided in this section.
4.1 PURPOSE
The purpose of this document is to describe the features and the behavior of the system. It also
specifies the hardware, software and network requirement of the system. This section also serves
the purpose to outline both the functional and non-functional requirements of the system.
This section is intended to be analyzed by anyone interested in both the behavior and
functionality of the system. It is also meant for analysis by the supervisor for more guidance and
correction as well as the examining panel for awarding points as it is an academic project.
4.2 SCOPE OF THE SYSTEM
Retail movie store management system will be a Java-based system that manages details of a
retail movie store. More specifically, this system is designed for the small-scale movie store
which will help in various functions of the store and to track down such necessities for easier and
smooth running of the enterprise by managing inventory and sales data. Added functionality may
include reports and statistics provision based on data.
All these activities are done through filling the forms that the system will provide; this will
facilitate entering of data and its handling. The actions in the forms will be processed by Java
code. The system also contains a relational database which is used to store persistent data such as
sales, inventory and employee details from the system which may be retrieved by the system for
updates and display if needed. All this will be later used to draw useful insights to be provided to
the enterprise owner.
4.3 ASSUMPTIONS
The system works under the assumption that:
 All users are computer literate

 All users can access internet and computer, laptop or phone.
 All users are able to read and write
4.4 OVERVIEW OF THE DOCUMENTS

This section, the overall Description section of this document gives an overview of the
functionality of the system. It describes the functional requirements and is used to establish a
19
context for the technical requirements specification in the section of System Requirements,
which is written primarily for developing and describing technical terms and the details of the
functionality of the product. Both sections of the document describe the same software product
in its entirety, but are intended for different audiences and thus use somewhat different language.
It also gives the hardware and software requirements of the system.
4.5 FUNCTIONAL REQUIREMENTS
4.5.1 USER REQUIREMENTS
a) Registration
The default login account will be the admin account; whose details will be established after
installation. They will be identified with the username “Admin” and a password which the user
provides for the purpose of login. Other accounts established by the admin shall be secondary
and mainly monitored for sales logging. Their credentials will be input by the admin and can be
used as login credentials later.
b) Login
Every user will be required to login using their correct username and password they used during
registration. If login will be successful, the user will be redirected to the dashboard. However, if
the user has forgotten the password they can change their password by providing the same details
they provided during registration; specifically answers to a set of ‘recovery’ questions. The staff
will not be able to change their password if they have forgotten they will have to consult the
admin.
c) Profile Account
Each user will have their own account which they will not be able to access before login.
The system shall allow user to update the profile information. When the user logins into their
accounts their basic details will be fetched to their profile where they can be accessed and
amended. The login credentials however will not be able to be changed.
d) Inventory
The user will be able to enter the data of media items and other products into the system and the
system can track their availability. This information will be able to be viewed at their viewing
page.
e) Sales
Once a transaction is done, the user will be able to enter the details into a form whose details are
stored for further accounting and reference.
f) Reports
The user will be able to generate reports of sales and inventory items as well as charts for easy
visualization and analysis.
20
g) Schedules
The user will be able to establish schedules which can remind them of pre-ordered items in a
disk which are to be picked later by customers to avoid physical waiting queues.
h) Profile Exit
The user will be able to log out anytime from any view as needed.
i) Profile Deletion
The admin will be able to remove any unneeded secondary profiles as per their discretion.
j) Dashboard
The “dashboard” will contain options for system operations that can be selected as needed for
use by the user.
21
Use Case Diagram of the System
Figure 1 Use Case Diagram
22
4.6 System Requirements
4.6.1 Operating System
The system will be a Java based system that will be a desktop application system. Once installed
the system can be directly applied to immediate use.
The system will have single database with several tables.
4.8 Design Constraints
4.8.1 Standard Development Tools
The system shall be built using a standard Java development tool; in particular Java IDE that
supports the various essential libraries in their relatively recent and improved versions.
4.8.2 Java Based Product
There are no exceptional memory requirements for the system beyond those of a typical
computer. The product shall be implemented in such a way that allows the user easy access to it.
A general knowledge of basic computer skills is required to use the product.
4.8.3 On-line User Documentation and Help System Requirements
The system will allow help functionality which will allow the user to send an email for
consultation purposes. Any further documentation will be provided via a link that can be
accessed through a web browser to a repository that provides the documentation.
4.8.4 Development Tool
The system will be developed using:
Java Core Language – will be used to develop backend of the system.
Java FXML – will be used to develop the graphical user interface.
4.9 Non-Functional Requirements

4.9.1 Graphical User Interface
The system shall provide a uniform look with consistency of display for similar functionality and
design.
4.9.2 Security
The system will provide a login window where every user that is intending to use the system
must be authenticated by the system as a valid user of the system. The password for all users will
be hashed.
Secondary accounts will have hashed passwords as well and will also need to be authenticated
via a password.
4.9.3 Performance relationship
The system will provide feedback to the users when or after performing a selected action.
23
CHAPTER FIVE: DESIGN
5.1 Introduction
It describes how the aims, functional and the non-functional requirements of the system stated
above will be transformed into more technical system design specification from which the
system is built. The document describes design goals and considerations, provides a high-level
overview of the system architecture, and describes the data design associated with the system, as
well as the human-machine interface and operational scenarios. The detailed design
specifications for each system component, including hardware, internal communications,
software, system integrity controls, and external interfaces. The high-level system design serves
as primary input to the Preliminary Design. It does so by clearly stipulating the functional
description of the system, user interface description of the system, the system’s database design
and the system’s procedural design. This is achieved through the use of architectural patterns,
design patterns, flow diagrams, use cases, relational models and user interfaces.
5.2 Purpose
The main purpose of the software design specification is to outline the software architecture and
design of Retail Movie Store Management System (RMS). The document will provide aid while
developing the system so as to meet client’s needs efficiently and effectively. Moreover, the
document facilitates communication and understanding of the system by providing several views
of the system design.
5.3 Assumptions
The user of the system is aware of basic operations of a computer and web pages. The user also
understands the standard terms used for operation.
5.4 Constraints
Both the front and the backend are developed from the same computer. Time is also a constraint
in the writing and documentation of the required documents before development commences.
5.5 System Environment
This is a java based system and therefore is designed to work on all operating systems. The
system is usable by any desktop and laptop.
24
5.6 Process Design
5.6.1 Product dataflow
The data will be inputted into the system via a user form and the system should be able to:
 Allow users to login using their account credentials

 Create employee account
 Send data to database
 Display details of available products
 Ideally provide a GUI for all components.
 Provide features for administrative security.
Figure 2 Data Flow Diagram
5.6.2 User characteristics

There are essentially two classes of users for the retail movie store management system: admin
and employee. The admin account is default and creates any employee account as they so desire.
Therefore, they act as the administration. All data provided by the system will be tailored for
easy evaluation and analysis and thus technical knowledge of the system such as the database
system is not a requisite for using the system. However, all the users should have basic computer
understanding and functional and behavioral procedures.
25
5.6.3 Operating environment
The system is java-based and it will be compatible with various system architectures without the
need for an internet connection.
Figure 3. System Environment Overview
26
Figure 4. Activity diagram for admin management activities
27
Figure 5. Simple Activity diagram for secondary account management
Figure 6. Simple Activity Diagram for the Employee Account
28
5.7 USER INTERFACE DESIGN
5.7.1 Introduction
A user interface describes the external view of the system. It focuses on aspects such as error
handling, the state of controls and dimensions and constraints of the system.
5.7.2 State of Controls
All controls should be visible to the users such as input fields, buttons, selection and links,
menus, submenus, textboxes, checkboxes, drop down lists, links, and tables. However, the
controls shall either be enabled or disabled (if some conditions have not been met). They shall
also change state depending on the inputs. The applied GUI components will be the only means
of access to the entire database, by all users.
5.7.3 Error Handling
If any user makes an error such as inputting wrong username and /or passwords when logging in,
they will be notified of the error appropriately through alerts controls (primarily labels) so that
they can change.
Alternatively, authorized users will be given relevant guidance on how to resolve exceptions
originating from user selection and input.
5.7.4 Dimensions and Constraints
The interface shall be dynamic in that it will be readily available for use from the installed
system. The small size occupied on the system will also play a vital role in the optimization of its
usage.
5.7.5 Functionality Representation
The system shall have input fields for entering inputs and various buttons for performing the
required functionalities on the inputs entered. It will also contain list views and links for
navigation across the application as needed.
29
5.7.6 Dashboard Interface
It is the first page that the user interacts with when they successfully login into the system. It
contains buttons to accessing the other functionalities of the system.
It is dependent on the profile in order to enforce access control; in particular, for the admin
account there’ll be an additional ‘create new account’ button for creating new secondary
accounts that will not be available on the secondary accounts.
5.7.7 Account Registration
This interface will be used by the admin of the system to add an account for an employee who is
not yet into the system and have his/her record details in the database. These profiles can be used
by other personnel other than the admin without infringing on the rights of the admin account.
This is how the form will look like:
30
5.7.8 User Login
The user is able to login to the system with their login credentials. Upon forgotten login details
he/she is prompted to enter an answer to a security question in order to recover the password. If
they cannot remember this, the admin can reset their password.
5.7.9 Enter sales

The system will allow the user to enter sales based on their organization policy; for instance, the
receipt number attribute in the database may remain blank if the organization does not implement
manual receipts that need to be entered. The ‘sale id’ and ‘profile’ elements will be entered
automatically.
31
5.7.10 Enter Inventory
Being impractical to enter inventory items one at a time, the system will depend upon the
quantity of each category to be entered into the system and saved into the database table.
5.7.11 Enter Preordered Items

The system shall allow the user to enter pre-ordered item; which in essence are a list of media
items that have been requested and are to be picked at a later date and/or time. This allows for
efficiency given that prior orders can be entered here and reproduced ready for when they are
needed by the consumer.
32
5.7.11 Display Sales
The interface will allow for sales to be displayed in a relational form as represented in the
respective database.
5.7.12 Show Reports

The system shall generate reports based on the selected data such as sales and inventory; which
can be printed as PDFs for further reference.
33
5.8 Database Design
5.8.1 Client-Server Architecture
In a client server architecture, the functionality of the system is organized into services, with
each service moving from the application to the middle tier to the database; thus a three-tier
model. Clients are users of these services and access servers to make use of them.
The system shall implement this model in order to ease on the computing resources given that
the records are set to cumulatively increase in the database over time and as per the system
usage.
Data Tier
The data tier maintains the application’s data such as users’ data, all application data, and the
SQL queries. It stores these data in a relational database management system (RDBMS). All the
connections with the RDBMS are managed in this tier.
All permanent information is maintained at this level.
Middle Tier
The middle tier implements the business logic, controller logic and presentation logic to control
the interaction between the applications’ clients and data. Business rules enforced by the
business logic dictate how the application processes data and any suitable/necessary calculations
and conclusions made on this data.
Client Tier
The client tier is the application’s user interface connecting data entry forms and client side
applications. It displays data to the user generated by the application as well as from the
database.
Users shall interact directly with the application through user interface. The client tier shall act as
the presentation interface for any data they shall require from the system and thus will offer
feedback for any requests made to the system. The client tier shall also provide a platform for
input by the system and communicate with the middle tier in order to maintain such information
within the system.
34
5.8.2 Database Entities
There will be a single database with four main tables: account details, sales, inventory and for
any preordered items. Additionally, there will be a table for the security questions and software
stemmed from the normalization process.
Account Details Table:
Name Type Size Null Default Other

Constraints
Username varchar 100 Not null No value P.K
Password varchar 100 Not null No value
Security int 1 Not null No value
Question Id
Answer varchar 100 Not null No value
Security Questions Table:

Constraints
Security int - Not null No value P.K
Question Id
Security varchar 100 Not null No value
Question
Software table:

Constraints
Software Id varchar 100 Not null No value P.K
Software varchar 100 Not null No value
Names
35
Sales table:

Constraints
Sale id varchar 100 Not null none P.K
Profile varchar 100 Not null No value
Number of int - Not null 0
audio
movies
TV Series
software
Software id varchar 1000 Not null ‘none’
Receipt varchar 250 Not null ‘n/a’
Number
Inventory:

Constraints
Entry ID varchar 100 Not null No value
Date Date/Time - Not null Current
Timestamp
Audio files
films
TV series
Software Id varchar 100 Not null 0
36
Preordered items:
Constraints
Customer varchar 100 Not null No value unique
Name/id
Items varchar 1000 Not null No value
Order date Date/Time - Not null Current
Timestamp
Pick-up date Date - Not null No value
Pick-up time Time - Yes No value
Device varchar 50 Not null ‘none’
37
5.8.3: Entity Relation Diagram:
Figure 7 ERD Diagram
5.9 Security Features

Some of the security features that will be incorporated into the system primarily include using of
login passwords to prevent unauthorized users from accessing the system resources.
Additionally, there shall be hashing of passwords that will be stored in the database. This will
prevent stealing of passwords in case there is a breach.
The database operations will also be implemented in a “transaction-safe” environment such that
they are atomic and this prevents data corruption from the application-database operations. The
application will also establish control measures using type-safe code and input sanctification to
prevent SQL injections.
38
CHAPTER 6: SYSTEM IMPLEMENTATION
System Implementation is the phase where all the system requirements of the system were
converted into a functioning executable program.
Implementation is simply carrying out execution of the program, or practice of a plan, a method,
or any design for doing something. As such, implementation is the action that must follow any
preliminary thinking in order for something to actually happen.
In an information technology context, implementation encompasses all the processes involved in
getting new software or hardware operating properly in its environment, including
installation, configuration, running, testing, and making necessary changes.
Figure 8. Implementation Stages
From the system requirement document, the various requirements are grouped and each group
represents a component. Thus each component was developed independent of the other.
39
The Software Component Identification activity transformed the software requirements to the
architecture of system software components. The activity provided:
 Review of the Project proposal to determine task assignment.
 Identify software components and associated interfaces.
6.1 User Interfaces

6.1.0 Homepage
This is the initial page of the system and it is the same to both the administrator (shortly referred
to as ‘admin’) as well as the respective employee accounts.
Header: At the header we have the title of the software which is RMS – Retail Movie
Software.
Top navigation has a hamburger menu with different links that redirect to different pages. The
links include;
 Logged in user – this is an inactive section that displays the username of the user
currently logged into the system
 New Sale – this is a link to the page where the user registers a new sale of the items
previously entered into the inventory of the system
 Inventory:
o Media – this is a link to input groups of items that will be sold using the system;
such as ‘movies’, ‘series’ etc.
o Software – this is a link to enter various individual software sold using the system
on a small-scale basis.
 Purchase:
o Media - this is a link to input groups of items that will be bought by the
respective user; such as ‘movies’, ‘series’ etc. In general, it records details of the
purchase including price and quantity.
o Software – this is a link to enter software purchases of the enterprise and their
details.
 To-do – this is a link to enter details of the tasks intended for each user. Each user has
their own lists which are maintained separately and are time-sensitive.
 Users – this is a link to manage users of the system; restricted only to the admin and
users with ‘manager’ status
 Customers – this is a link to customer management page including maintenance of
regular customers’ preferences
 Preorders – this is a link to the page that lists and manages orders placed by customers
requesting items that are not currently physically available; but that can be brought in the
future within a reasonable time period
40
 Log report – this is a link to the log that is a record of ‘logins’ made by the various users
as they use the system
 Change Password – this is a link to change the password by the user currently logged in.
Each user can only change their own password.
 Logout – this is a link to logout from the system from which the application can be safely
closed.
 A left-pointing arrow – indicates that on pressing the hamburger menu is restored to its
original position.
41
Figure 9. Isolated home menu
42
43
Figure 10. Homepage as a whole
The mid-lower region of the homepage contains summary statistics of:

a) Users – these are the users of the system as registered within the system
b) Customers – customers whose records are stored within the system
c) Preorders – these are unfulfilled preorders listed in the system. Unlike to-do items, these
are summed across all accounts.
The far right contains the ‘to-do’ items which are listed specifically for the user currently logged
in.
The lower region contains two charts:
a) Bar chart that contains a summary of the sales for the current year; arranged by month
b) Pie chart that contains a summary of the users as they are divided by roles
6.1.1 Sign in interface of the staff and admin

Administrator/ staff page on logging in
This is the log in page of the admin or employee; and he/she is required to input required
credential that is the username and the password.
The log in pages are similar for the staff and admin but instead of manual entering of the
username (which also increases the potential for forgetting the same), the username is selected
via a drop-down menu and only the password is entered.
There also exists an option to reset the password backed by a security question entered during
registration of the respective user.
44
Figure 11. Login page
6.1.2 Administrator (admin).

Actions that the admin can perform are;
 Add new employees – through the ‘user’ button on the home hamburger menu, the
admin can add or delete any employee; including those with managerial status. However,
they cannot delete their own account.
The admin also enters the initial credentials of each employee before they can access and
configure the credentials as per their preference. This includes both junior employees as
well as managers.
 View all details of the system. No section of the system is restricted to the admin
including reports and charts. As such using any of the links on the home page they view
these records. These includes:
o Sales records
45
o Purchase records
o Inventory
o Log reports
 Edit account- this where the admin can change his/her password and log out on the home
hamburger menu.
 Enter a new sale of any item listed within the inventory of the system
 Enter a new item into the inventory as an item the enterprise is interested to deal in
 Enter a purchase record of any item listed within the inventory of the system
Figure 12. Log report as generated by the admin
46
Figure 13. Media Purchases Records as retrieved by admin
47
6.1.3 Manager (mgr).
Actions that the manager can perform are;
 Add new employees – through the ‘user’ button on the home hamburger menu, the
manager can also add or delete any junior employees. However, they cannot delete their
own account.
The manager also enters the initial credentials of the employees they register before the
employee can access and configure the credentials as per their preference.
 View various details of the system. Given their supervisory role managers are allowed to
view various system records. As such using any of the links on the home page they view
these records. These includes:
o Sales records
o Purchase records
o Inventory
However, some of the areas are restricted so they cannot be able to access them; such as
admin credential management; which is only allowed for the administrator.
 Edit account- this where the manager can change his/her password and/or log out on the
home hamburger menu.
Figure 14. Successful insertion of employee (user)
48
Figure 15. Error as manager attempts to delete admin
6.1.3 Employee
Actions that the manager can perform are;
 Edit account- this where the manager can change his/her password and log out on the
home hamburger menu.
All other areas are restricted so the employee cannot access them.
49
Figure 16. Error as employee attempts to read log reports
Figure 17. Employee successfully goes on recording a sale
50
Figure 18 Inventory page
Figure 19. Purchase page
51
Figure 20 Sale Page
Additional Security & Consistency

It is worth noting that while user accounts are protected by username-password combinations, the
program inputs are protected by checking existence of the same records or inappropriate combinations of
input. An example of is of customer checking before insertion as illustrated by the code snippet below:
52
53
CHAPTER 7: SYSTEM TESTING
7.0 Introduction.
Testing is a process of executing a program with the interest of finding an error. A good test is
one that has high probability of finding the yet undiscovered error. Testing should systematically
uncover different classes of errors in a minimum amount of time with a minimum amount of
efforts. Two classes of inputs are provided to test the process:
1. A software configuration that includes a software requirements specification, a design
specification and source code.
2. A software configuration that includes a test plan and procedure, any testing tool and test
cases and their expected results.
System Testing ensures that the system being developed satisfied the objective and requirements
of the system and that the system performs as required.
7.1 Participants
Participants in testing shall include:
 Developer (White-box testing)
7.2 Features to be tested
 Forms
This include all the forms that user inputs data that should be stored in the database
 Login
Login form enables different level of users to access their respective page. This also includes
password recovery methodologies.
 Report display
All tables that display data from the database. This also includes documents generated to
represent this data.
7.3 Testing Procedures

Case1: Use correct input in fill in forms and observe the response.
Case2: Use wrong inputs in fill in forms and observe the response.
Case3: Use null inputs in fill in forms and observe the response.
Give your result in the table questionnaire given.
54
7.4 Test Tools:
The main testing tool used for this system was JUnit Framework (version 4.12) and Spring
framework for testing database and integration functionality. However, the system was also run
independently as a normal user in order to determine the performance of the system.
In addition, several libraries were used for testing of functionalities such as pattern recognition
(Hamcrest 1.3) and database connections (MySql and MongoDb driver connectors).
7.5 Test Cases
7.5.1 Developer Unit Testing
The primary blocks leading towards integration was unit testing achieved through the use of
JUnit Java Framework that tests individual components before they are ‘plugged’ together with
other components.
This testing was extremely important in my determination of the validity and verification of each
component and to gauge their individual performance before measuring their impact on the
system as a whole.
A score of 100 per cent test pass was achieved for each component before proceeding; failure to
which further development and architectural consideration was done to improve performance
and the respective score.
7.5.2 Developer Functional Testing
Figure 21. Developer Testing Methodology
55
Description
As a developer the above test case as a guide in testing each component with respect to the
system specification and system design. It involved testing behavior of login, submission of form
inputs to database, display of reports. It also involved testing the whole PC system on different
platforms and its database.
7.5.3 Developer Integration Testing
As a developer I did integration testing against several other systems such as relational databases
and document databases as utilized by the system. This was done several times and the mean
time improved with observed time required to input and update records.
7.6 Test Summary Reports

7.6.1 Unit testing.
This is where I tested several modules of the system. This leads to verification that a given
module is fit for use. This is because the system is made up of these individual modules and thus
they have to be working correctly.
Samples of some of the results are shown below:
Figure 22. Customer Management Logic Test
56
Figure 23. Media Purchase Logic Test
Figure 24. Main Logic Test

57
7.6.2 Integration Testing.
Here, the modules are combined and tested together may be for the purpose of compatibility or
just functionality. This is done before the system validation testing. It is normally done after the
unit testing. Here the modules were tested on the local storage versus those on the permanent
storage on the database as well as data transmission and retrieval.
On average the document database (Mongo Db) implemented for sales was faster to start as
compared to its relational counterpart (Mysql). However, the space occupied by Mongo Db was
bigger for the same amount of data transmitted. Reading and writing for both database systems
was fairly constant and within reasonable limit for the working of the system.
7.6.3 System Testing.

Here the system is tested as whole and only if the previous tests were successful. Both the
software and the hardware are tested to see if they fit the required and expected standards. Here
the black box would be advisable.
Testing done here mainly focused on the system being usable and within practical usage. This
was done by assuming the role of the end user and simulating a working environment. On
average the software operated well and without difficulty. However, performance could be
improved further by developing more efficient algorithms during maintenance and/or upgrade
phases.
58
CHAPTER EIGHT:
CONCLUSION AND RECOMMENDATIONS

CONCLUSION
Based on the findings of the development process, the following conclusions were drawn within
the limitation and scope. The developed software presented features that helped small scale
enterprises in the sale of their media items as well as small scale software vending operations; in
a relevant and practical manner.
RECOMMENDATIONS
After having evaluated the findings of the study, the following recommendations were hereby
suggested:
 This system should be used to generate more accurate records of the business
 This system should be used to track and compare more accurately contrasting business
operations such as sales versus purchases
 Future researchers and developers can add modules and additional features as this system
is open for further improvements and developments because of the fast pacing changes in
technology.
 A follow up study should be conducted to determine the usefulness and effectiveness of
the developed system upon implementation. This should also include how well it works
with other systems in the market with which they complement each other.
CHALLENGES
Coming up with the system posed a lot of challenges to me of which some I had to consult as
well as researching from respective books. The challenges included;
 Inadequate time - the system required ample time to implement but due to time constrain
not all features could be implemented and enhancements made.
 Lack of enough internet facilities – the system required multiple libraries which could
only be obtained by downloads from the internet among other research materials; a
resource which is not available in a consistent setting
59
APPENDICES
Appendix I: Estimated budget for the project
The break down tentatively covers all the materials needed for the project completion:
 Iterative printing of the proposal itself in full (approximately Ksh 1000),

 Stationery needs that consists of roughly three pens and paper; part of which shall be
used in construction of data collection techniques such as that for questionnaires. This
costs approximately Ksh 200,
 Photocopying costs of the documents including that of other documentation such as the
software specification and requirements definition (approximately Ksh 200),
 1 flash disk and 5 compact disks (shortly labelled as CDs): these shall be important in
display and movement of the code and other soft copy materials during development and
deployment of the resultant program being developed at an approximate cost of Ksh 700,
 Modem; this is the hardware used to access the internet via broadband and will be
paramount in obtaining relevant software, libraries and other useful material from the
internet for use during the project; it would be acquired at a projected cost of Ksh 2000,
 Internet bundles projected to cost Ksh 2000; which used with the modem will grant me
access to the internet to obtain needed materials such as software libraries,
 Laptop machine which with the previously mentioned specs (core i3, 4gb RAM, 500 GB
HDD space) is costing approximately Ksh 45000,
 Miscellaneous expenses projected at Ksh 52 100.
When summed the total cost is estimated to be Ksh 52,100 as a comprehensive cost of
developing and completing this project successfully.
60
ITEM COST(KES)
Printing (Proposal) 1000.00

Stationery 200.00
Photocopying cost 200.00
1 Flash Disk and 5 CDs 700.00
Modem 2000.00
Bundles 2000.00
Laptop 45,000.00
Miscellaneous 1000.00
TOTALS 52,100.00
Figure 25 Budget
61
Appendix II: Time Plan
Time duration 12 -19 20 – 26 - 29 - 1-2 3-4 5-25 26 21 27- 01 15
Sep 25 28 31 Oct Oct Oct Oct- Nov 28 Jan Mar
Sept Sept Sept 20 Nov – -
Nov 15 05
Mar Apr
Background of
the
study ,problem
statement draft
Proposed
solution, aims of
the objectives
and significance
of the project
analysis
Literature review
and research of
the industry
Methodology
deliberation and
drafting
Budget draft,
analysis and
preparation
Proposal
consolidation
and submission
System analysis
and requirements
specification
System Design
Submission of
project document
Oral presentation
Coding (System
implementation)
Testing and
maintenance
Figure 26 Time Plan
62
Appendix III: Questions asked for Data Collection
(https://docs.google.com/forms/d/1ky-DKv2dEQJo-_TL2lveMklQrLwPSDjTYZ_uEnY4FDA/edit )
1. What is your name?
2. What challenges do you face in your business operations?
3. What solution would you propose to solve such problems?
4. Can you please enter your contact information?
63
References
Capterra. (2019). Point of Sale Software. Retrieved from Capterra: www.capterra.com
Connolly, T. M., & Begg, C. E. (2005). Database Systems & Practical Approach to Design
Implementation and Management . Addison-Wesley.
Daft, R. L. (2012). Open System Design Elements. In R. L. Daft, Organization Theory and Design (pp.
198-199). Cengage Learning.
Elmasri, & Navathe. (2001). Fundamentals of Database Systems. Addison-Wesley.
Funk, T. P. (2006, November 02). Increasing ,Americans prefer Going to the Movies at Home. Retrieved
from Pews Research: www.pewsresearch.org/social/pack.php?PackID=13
IEEE. (1998). IEEE Recommened Practice for Software Requirements Specifications. IEEE STD 830-
1998.
Liang, k., & Cao, S. (2016). Design and Implementation of Micro Cinema Management System based on
OTO. 2nd IEEE International Conference on Computer and Communications (ICCC).
Madden, S. (2012). From Databases to Big Data. IEEE Internet Computing, 4-6.
McDonnell, & Sliver. (2007). Movie Technologies.
Meskele, H. (2019). Online Cinema Movies Booking Management System. Adama Science and
Technology University, Ethiopia.
Mohan, V. (2013). IT Asset Management Benefits & Best Practices.
Moon, S., Bergey, K. P., & Iacobucci, D. (2010). Dynamic Effects Among Movie Ratings , Movie
Revenues and View.
Mugambi, K. W., & Theuri, F. S. (2014). The Challenges encountered by County Governments in Kenya.
Ogutu, J. (2015). How ICT drives Kenya's Economic Growth.
Robinson, L., Webber, J., & Eifrem, E. (2015). Graph Databses: New Opportunities for Connected Data.
O'Reilly Media .
Roy-Hubara, Noa and Rakach, Lior and Shapira, Bracha and Shoval, & Peretz. (2017). Modeling Graph
Database Schema. IT Professional, 34-43.
Roy-Hubara, Noa, & Sturm. (2018). Exploring the Design Needs for the New Database Era. 276-290.
Sreejesh, P. V., Rameez , E. A., Yaseen, A. U., & Nijin, R. A. (2014). Multiplex Theater Online Booking
System. Kochi: COCHIN UNIVERSITY OF SCIENCE & TECHNOLOGY.
Vend HQ. (2019, Feb 26). The Future of Inventory Management. Retrieved from www.vendhq.com
W, Z.-S. (2008). Implementation of Security Mnagement System in Digital CInema System.
64

Ian Mburu

Uploaded by

Copyright:

Available Formats

Ian Mburu

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ian Mburu

Uploaded by

Copyright:

Available Formats

CHUKA UNIVERSITY

FACULTY OF SCIENCE, ENGINEERING AND TECHNOLOGY

COURSE UNIT: COSC 483

IAN MBURU - EB1/28018/16

SUBMITTED BY IAN MBURU TO CHUKA UNIVERSITY, IN PARTIAL

1.1 BACKGROUND INFORMATION

2.0 LITERATURE REVIEW

3.3 APPLICATION IMPLEMENTATION

 Parallel development can be planned.

 The end of the project may not be known.

3.4 SYSTEM IMPLEMENTATION TOOLS

3.5 APPLICATION TESTING

 Incremental Integration Testing

3.6 APPLICATION DEPLOYMENT AND MAINTENANCE

SYSTEM ANALYSIS AND REQUIREMENTS SPECIFICATION

 All users are computer literate

4.4 OVERVIEW OF THE DOCUMENTS

Figure 1 Use Case Diagram

4.9 Non-Functional Requirements

 Allow users to login using their account credentials

Figure 2 Data Flow Diagram

5.6.2 User characteristics

Figure 3. System Environment Overview

Figure 6. Simple Activity Diagram for the Employee Account

5.7.9 Enter sales

5.7.11 Enter Preordered Items

5.7.12 Show Reports

Name Type Size Null Default Other

Security Questions Table:

Name Type Size Null Default Other

Name Type Size Null Default Other

Name Type Size Null Default Other

Name Type Size Null Default Other

Figure 7 ERD Diagram

5.9 Security Features

Figure 8. Implementation Stages

6.1 User Interfaces

The mid-lower region of the homepage contains summary statistics of:

6.1.1 Sign in interface of the staff and admin

6.1.2 Administrator (admin).

Figure 12. Log report as generated by the admin

Figure 14. Successful insertion of employee (user)

Figure 17. Employee successfully goes on recording a sale

Figure 19. Purchase page

Additional Security & Consistency

7.3 Testing Procedures

Figure 21. Developer Testing Methodology

7.6 Test Summary Reports

Figure 22. Customer Management Logic Test

Figure 24. Main Logic Test

7.6.3 System Testing.

CONCLUSION AND RECOMMENDATIONS

 Iterative printing of the proposal itself in full (approximately Ksh 1000),

Printing (Proposal) 1000.00

You might also like