KWAME NKRUMAH UNIVERSITY OF SCIENCE AND TECHNOLOGY

KUMASI – GHANA

COLLEGE OF SCIENCE

DEPARTMENT OF COMPUTER SCIENCE

TOPIC:

AN INCIDENT REPORTING AND MANAGEMENT SYSTEM.

A THESIS SUBMITTED TO THE DEPARTMENT OF COMPUTER SCIENCE,

FACULTY OF PHYSICAL SCIENCES, KWAME NKRUMAH UNIVERSITY OF
SCIENCE AND TECHNOLOGY, IN PARTIAL FULFILMENT OF THE
REQUIREMENTS FOR THE AWARD OF B.Sc. (HONS) COMPUTER SCIENCE.

BY

AGYAPONG PRINCE: 4603218

ARYEE PHILIP NII ARMAH: 4607118

OCTOBER, 2022

SUPERVISOR: DR. DOMINIC ASAMOAH

i
 DECLARATION

We declare that we have wholly undertaken the study and reported herein submitted it under
the supervision of our lecturer and supervisor Dr. Dominic Asamoah.

NAME

……………………………………. …..……………....................

AGYAPONG PRINCE DATE

………………………………………. ……………………………...

ARYEE PHILIP NII ARMAH DATE

SUPERVISOR

……………………………………… ……...……………………...

Dr. DOMINIC ASAMOAH DATE

ii
 DEDICATION

We dedicate this work to the almighty God for his grace, guidance, and knowledge from the
beginning to the completion of this work. To our loving parents who have never stopped
believing in us and supported us all through, we also dedicate this work.
Finally, we dedicate this work to all lecturers of the computer science department, Mr.
Emmanuel Baah and especially Dr. Dominic Asamoah, who supervised this work.

iii
 ACKNOWLEDGEMENT

Our first acknowledgment goes to the Almighty God who makes great men out of little men,
and who inspired us from the day we decided to work on this project. Undeniably, the
attainment of this work would not have happened without supervision. We are indebted to all
who invested countless hours correcting and giving ideas to the content of the incident
reporting system.

We would like to express our profound gratitude to Mr. Emmanuel Baah who coached using
throughout this project. And we also express special thanks of gratitude to the project
supervisor Dr. Dominic Asamoah who gave us this golden opportunity to work on this project
which also helped us in a lot of research work and to use all that we have studied in bringing
this project up. Lastly, we thank our parents and friends who helped a lot in finalizing this
project within the limited time frame.

iv
 ABSTRACT

The purpose of this study was to develop a computerized incident report system for students.
The system was developed to provide a convenient way for students to report incidents and
store the data in a central location. The system was designed to be user-friendly and easy to
use. The system will be used to track and record student incidents such as theft, near misses,
sexual assaults, etc.

The purpose of this system is to also manage incident reports. It will store information about
the incident, the people involved, and the investigation. This system will be used by the incident
management team to track and manage incidents.

v
 SUMMARY

Our project (code-named AIM clone and dos) is a mobile application incident reporting system
that provides users the opportunity to report incidents to the DOS. It also provides the admin
the opportunity to view and manage incident reports sent in by students.

vi
 TABLE OF CONTENT

DECLARATION......................................................................................................................ii
DEDICATION........................................................................................................................ iii
ACKNOWLEDGEMENT ...................................................................................................... iv
ABSTRACT .............................................................................................................................. v
SUMMARY ............................................................................................................................. vi
CHAPTER ONE ...................................................................................................................... 1
INTRODUCTION................................................................................................................ 1
1.0 OVERVIEW OF THE PROJECT ........................................................................... 1
1.1 INTRODUCTION ................................................................................................. 1
1.2 MOTIVATION ...................................................................................................... 2
1.3 PROBLEM DEFINITION .................................................................................... 2
1.4 AIM AND OBJECTIVES ..................................................................................... 3
1.5 DEVELOPMENT TOOLS ................................................................................... 3
1.6 PROJECT BENEFICIARIES .............................................................................. 4
1.7 PROJECT SCOPE ................................................................................................ 4
1.8 DELIVERABLES .................................................................................................. 4
CHAPTER TWO ..................................................................................................................... 5
REVIEW OF RELATED SYSTEMS ................................................................................ 5
2.0 OVERVIEW ............................................................................................................... 5
2.1 KNUST DEAN OF STUDENT INCIDENT REPORTING SYSTEM ................. 5
2.2 The University of South Alabama (USA) Incident Reporting System. ................. 6
2.3 PROPOSED SOLUTIONS ....................................................................................... 6
CHAPTER THREE ................................................................................................................. 7
REQUIREMENT SPECIFICATION AND METHODOLOGY .................................... 7
3.1 REQUIREMENT SPECIFICATION .................................................................. 7
3.2 FUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS ......................... 7
3.3 USER AND SYSTEM REQUIREMENTS .............................................................. 9
3.4 UML DIAGRAMS ..................................................................................................... 9
3.5 METHODOLOGY .................................................................................................. 17

vii
 3.6 PROJECT METHOD .............................................................................................. 17
3.7 MODEL ADAPTED AND JUSTIFICATION ...................................................... 19
3.8 PROJECT DESIGN................................................................................................. 20
CHAPTER FOUR.................................................................................................................. 33
SYSTEM IMPLEMENTATION AND TESTING ......................................................... 33
4.0 INTRODUCTION.................................................................................................... 33
4.2 DEVELOPMENT .................................................................................................... 33
4.3 TESTING ...................................................................................................................... 33
4.3.1 TEST PLAN .......................................................................................................... 33
CHAPTER FIVE ................................................................................................................... 35
CONCLUSION AND RECOMMENDATION ............................................................... 35
5.0 INTRODUCTION........................................................................................................ 35
5.1 SUMMARY .............................................................................................................. 35
5.2 FINDINGS ................................................................................................................ 35
5.3 CONCLUSION ........................................................................................................ 36
5.4 RECOMMENDATIONS......................................................................................... 36
REFERENCES................................................................................................................... 37
APPENDIX ..................................................................................................................... 38

viii
 TABLE OF FIGURES

Figure 1 USE CASE DIAGRAM .............................................................................................. 10

Figure 2: LOGIN ACTIVITY DIAGRAM ................................................................................. 11
Figure 3: USER ACTIVITY DIAGRAM ................................................................................... 12
Figure 4: ADMIN ACTIVITY DIAGRAM ................................................................................ 13
Figure 5: ADMIN LOGIN SEQUENCE DIAGRAM ............................................................... 14
Figure 6: USER INCIDENT REPORT DETAILS .................................................................... 15
Figure 7: ARCHITECTURAL DESIGN ................................................................................... 16
Figure 8: WATERFALL MODEL ............................................................................................ 17
Figure 9: SPIRAL MODEL ...................................................................................................... 18
Figure 10: INCREMENTAL MODEL ...................................................................................... 19
Figure 11: USER SPLASH SCREEN ....................................................................................... 20
Figure 12: USER LOGIN PAGE ............................................................................................. 21
Figure 13: USER HOME PAGE .............................................................................................. 22
Figure 14: INCIDENT REPORT PAGE .................................................................................. 23
Figure 15: INCIDENT REPORT PAGE ................................................................................. 24
Figure 16: REPORT HISTORY AND PROGRESS TRACKER................................................ 25
Figure 17 REPORT HISTORY AND PROGRESS TACKER ................................................... 26
Figure 18: ADMIN LOGIN ...................................................................................................... 27
Figure 19: ADMIN HOMEPAGE ............................................................................................ 28
Figure 20: ADMIN REPORTS PAGE...................................................................................... 29
Figure 21: ADMIN OFFICE AUTOMATION ......................................................................... 30
Figure 22: ADMIN REPORT MANAGEMENT PAGE ............................................................ 31
Figure 23: ADMIN REPORT MANAGEMENT PAGE ............................................................ 32

ix
 CHAPTER ONE
INTRODUCTION

1.0 OVERVIEW OF THE PROJECT

The project code-named AIM clone is a mobile application that will allow users who are
students to report incidents that happen to the designated school administration via the internet.
Students will be able to report incidents and the designated school administrator in charge of
incident reports will engage students in the incident management process. AIM clone will help
students far away from campus take advantage of the internet's opportunity to make reports in
the comfort and convenience of their homes.

1.1 INTRODUCTION
Incident Reporting is the process of capturing, recording, and managing an incident that occurs
such as an injury, property damage, or, security incident. Incident reporting is an organizational
management practice that allows users of facilities in the organization to report all accidents
that occur within the organization. Incident reporting system software is vital to nearly every
organization. Some of these organizations can be schools, health centers, construction services,
transport services, and anywhere hazards may occur.

This project focuses on the creation of a digital incident reporting system for students of
Kwame Nkrumah University of Science and Technology (KNUST). This platform will provide
students the opportunity to make reports of incidents anytime from anywhere easily through
the help of the internet.

1.1.0 BACKGROUND STUDY

Over the past few years, the internet has caused an evolution in the way data or information is
processed. Do you remember having to go through stress and inconveniences just to send and
receive information?

1|Page
An incident reporting system is a system that allows users to report all facts related to incidents
in the workplace over the internet.
Incidents of all sorts and sizes occur, from property damage in the organization, theft, and rape
to accidents, injuries, or illnesses. It is critical that in all organizations, people there are
empowered to report incidents that happen using an incident report form. When people report
incidents, they are directly contributing to potentially preventing a future incident from
happening again. It allows the organization to properly investigate and establish checks, and
procedures and implement risk controls in response to what has happened. No matter how small
an incident is, everything should be reported.
Technology, which is the internet, the web, and mobile applications, provides the platform for
organizations to gather incidents that are reported and be able to work to resolve those
incidents.
In addition to the internet providing a platform for reporting incidents, mobile devices have
been given the capabilities and functionalities which were previously known to be for only
computers. Therefore now, mobile devices can be used to access the internet as well as perform
most of the functionalities known to computers. The use of mobile devices makes it easier to
report incidents since it is handheld and very portable than computer.

1.2 MOTIVATION
Information technology has evolved in a way the internet is playing a major role in making
access to systems remotely. By this means, people find it very convenient to access these
systems anywhere at any time.

When incidents occur, it is much better to report them instantly than to wait a little while to
report the incident. Vital information may not be captured in the incident report if it takes some
time before the incident is reported.

AIM Clone has the advantage of allowing its users to be able to report incidents remotely and
know the various stages of the incident they have reported.

1.3 PROBLEM DEFINITION

The uneasy access to getting students’ reports resolved on time is a major challenge hence this
reporting system. The stress of forming long queues to make a report or follow up on a reported
issue has been a major challenge as it seems unfruitful sometimes. The current incident

2|Page
reporting system is not a digital system which makes its accessibility sometimes challenging.
Students are not able to track the progress of their report and give up on the report as procedures
seem tiring. So, in an organization like the Kwame Nkrumah University of Science and
Technology (KNUST), there is an incident reporting system for students but it is not
digitalized. This is a system that helps student report cases such as theft, rape, fire outbreaks,
and many other incidents to the school through the Dean of Students office.

1.4 AIM AND OBJECTIVES

This project aims at developing an incident reporting system mobile application for students to
assist them to report incidents from anywhere at any time.

1.4.1 SPECIFIC OBJECTIVES

This project aims at developing a mobile application that enables students of KNUST to report
incidents to the school through the internet. To achieve this, there is a need to

• Create mobile app user interfaces

• Link the pages of the mobile app user interfaces
• Create Database
• Connect a database to a mobile app
• Test Application

1.5 DEVELOPMENT TOOLS

The development tools to be used for the proposed system will include the following:

• FLUTTER: Client-side framework tool for the development of the application. Codes
would be written in dart language.
• FIGMA: The tool for the initial design of the user interface of the application.
• FIREBASE: Server-side tool for the development of database and backend
automation.

3|Page
1.6 PROJECT BENEFICIARIES
Students are the main beneficiaries of this project. They have the advantage to send reports of
incidents at their convenience.

They have the liberty to know the various stages of their reports to keep them involved in the
resolution process.

1.7 PROJECT SCOPE

Primarily, the scope pertains to two mobile applications for making this incident reporting
system project live. It focuses on the students and the department involved in the reporting of
cases and the resolution or management of cases respectively. The system being developed is
called the KNUST Student Incident Reporting System.

The system mainly comprises two mobile applications. The student application is known as the
AIM CLONE, which will allow students to log in, make a report and monitor the progress of
the report made. The other application is for the department responsible for incident
management and this is known as Dean of Student (DOS), which will allow the department to
log in, view incident reports, and inform the students about the various stages of their report.
After the student logs in to the system, the system will allow the student to select what kind of
incident he/she wants to report according to the available categories, fill out the form stating
the correct details of the incident and finally send it. Later, students will be able to view the
progress timeline of their respective incidents. This process will keep students involved in the
resolution process of the incident hence making it effective and efficient.

The application for the department will allow them to view all reports made and also view
reports based on the various categories to reduce the stress of having to sort the reports
manually.

1.8 DELIVERABLES
• Functionality in student app for reporting incidents
• A mobile application for the administrator
• Project documentation

4|Page
 CHAPTER TWO

REVIEW OF RELATED SYSTEMS

2.0 OVERVIEW
To provide an effective and efficient system, we took it upon ourselves to evaluate already
existing systems providing services similar to our system. This chapter talks about an already
system known as KNUST DOS, which provides a manual system through which students
report their incidents. Therefore, since our project is mainly incident reporting, we will
concentrate on the incident reporting part of KNUST DOS.

2.1 KNUST DEAN OF STUDENT INCIDENT REPORTING SYSTEM

KNUST DOS is a manual incident reporting system for students in KNUST to assist them to
report issues or incidents to the Dean of Students office of the school. Upon the observation of
its incident reporting system, these were some of the problems found:

1. Non-digital system
This part of their system renders it difficult in reporting incidents at a goal. It is
inefficient since reports can be sent only to the office of the DOS. This also makes it
difficult to report issues that happen outside the working hours of the DOS. Students
find it difficult to report incidents at go since some students are distant from the office.
2. Reporting problem
There is a problem with making reports. Upon a visit to the premises of the department,
this challenge was recorded as the is mostly a long queue at the premises. This
discourages students since they have to wait a long while before they can lodge a report.
This renders the system ineffective since it is not able to deliver its services as desired.
3. Poor incident progress tracking
In this system, students find it challenging to track the progress of their reports. Even
when followed up on students are unable to get access to know the stage of their report.
This is ineffective as students end up giving up on the report they have made. This is a
major setback in the resolution process.

5|Page
2.2 The University of South Alabama (USA) Incident Reporting System.
The USA incident reporting system is a system that is made available for students and
employees of the institution. This system is web-based and helps them report incidents to the
school. Upon observation of this system, was a problem found:

Poor incident progress tracking:

Incidents reported to the school authority cannot be tracked to know whether the incident is
being resolved or not. There is no progress tracker on the incident reporting website to assist
reporters who report incidents to the school. Reporters seem to be only involved when making
reports.

2.3 PROPOSED SOLUTIONS

The proposed solution incorporates the remedies to be developed and implemented to
address the problems identified with the existing system:

1. Develop a digital system

The development of a digital system or application will help resolve the issue of
students having to only report incidents at the office of DOS. The student will be
able to make use of the internet available to report incidents remotely. This is an
effective way of reporting incidents since reports will not take a while before they
are made, hence the incidents maintain their originality with full details.
Students would not need to join long queues before they make their reports as this
seems very tiring and frustrating.

2. Progress tracker
This functionality will be made available in the system to enable users or students
who report issues know the various stages and the progress of the report they have
made. It allows students to draw the attention of DOS if their reports are taking
very long to attend to since they are aware of the incident progress and the history
of incidents they have made.
3. Improved Performance
The developers of this mobile application will make sure that the application is
developed very well to improve the performance of the system. Also, regular updates
will be done to improve its performance.

6|Page
 CHAPTER THREE
REQUIREMENT SPECIFICATION AND METHODOLOGY

3.1 REQUIREMENT SPECIFICATION

This chapter begins by taking a look at the requirement specification review and specification
that discusses all the functionalities and non-functionalities required to design the system. This
chapter also discusses the methodology employed in the system design and development
process.
It will also list all the diagrams (Use case diagram, activity diagram, and sequence diagram).

3.2 FUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS

3.2.1 FUNCTIONAL REQUIREMENT
The functional requirement outlines the way the system is to function or work. The behavior
or function may be expressed as services, tasks, or functions the system is expected to perform.
The system should be able to:

• Allow a student who wants to make a report, to log in to the system by entering a valid
username and password.
• After the student login, make a report by filling out the incident report form and sending
it.
• Allow students who have made reports to view the history of reports they have made.
• Allow students to track their reports’ progress by viewing a progress timeline controlled
by the administrator.
• Allow administrators responsible for resolving the incidents login to the system.
• After login, the system should allow administrators to view student incident reports.
• Allow administrators to inform users about the various stages of their incident reports
by controlling the progress timeline.

3.2.2 NON-FUNCTIONAL REQUIREMENTS

The Non-Functional requirements are requirements that are not concerned with the functions
performed by the system. They may relate to emergent system properties such as reliability,
response time, etc. These requirements also portray the general qualities of the system. Their
malfunctions affect the system as a whole and are very vital.

7|Page
The non-functional requirements of the system are as follows:
• Usability
The design of this incident reporting system is such that it is easy to use and can be
used by all users of the system. The system has a very comprehensive user interface
and is easy for users to interact with. No extensive training is required to be able to
use this system.
• Maintainability
Maintaining and sustaining this system can be ensured by allowing programmers who
were not involved in the development of the system, later add new and more features
due to the availability of the accompanying documentation.
• Compatibility
The online shopping system was developed using Flutter, a cross-platform framework
to allow mobile applications for android and iOS using a single code base. Therefore,
this system can run on both Android and iOS operating systems.
• Reliability
The system should be able to deliver the various functionalities required by the user.
The system should also be able to achieve its main objective or overall purpose. thus,
allowing users to report incidents and track them and also allowing administrators to
view and process incidents.
• Performance
The various functionalities provided by this system require high performance.
Performance such as responsiveness to user requests, processing time, interaction, etc.
can be vital in the system’s overall performance.
• Availability
The main objective of this project is to help students make reports remotely from
anywhere. This system shall be available to the users 24 hours a day.

• Security
Since this system is an interactive application and will be used by the users for
reporting confidential issues, there is a need for the system to be secure.

8|Page
3.3 USER AND SYSTEM REQUIREMENTS
3.3.1 USER REQUIREMENTS
There are some requirements on the part of the users and they are:

• Provide Report History: The feature should allow users access to all other incidents
they have reported to the DOS.
• Provide Progress Timeline: The feature should enable users to track the progress of
their reports to keep the administrators and the users interactive.
• Detailed Incident Categorization: The feature should allow the incident reports to be
grouped into categories based on the type of incident to aid in fast and easy navigation.
• Provide Comprehensive Report Detail: The feature should provide the various
information that the administrators may require from the reports to aid them in
identification and processing.

3.3.2 SYSTEM REQUIREMENTS

For the system to be built and function properly and efficiently, the proposed system needs an
android smartphone preferably with the following specifications.

Some hardware specifications requirements are:

• A smartphone
• An Android 4.4 or higher operating system is required
• RAM with 2GB or higher capacity
• Disk space 2GB and/or above
• Internet access

3.4 UML DIAGRAMS

Unified Modelling Language Diagrams are a way of visualizing a software program using a
collection of diagrams. There are several diagrams in the UML diagrams. These are class
diagrams, activity diagrams, sequence diagrams, object diagrams, package diagrams, and use
case diagrams.

9|Page
3.4.1 Use Case Representation of the System

The various actors involved with the system include User/Student and Admin/DOS. The use
case diagram below describes the various functionalities provided by the system to the various
actors who interact with the system.

User/Student: this actor represents the main target and beneficiary of the system. The main
person enjoys most of the benefits of this incident reporting system. The activities of this actor
may include making reports, tracking reports, and viewing reports made.

Admin/DOS: This actor is the main manager of the system. The person who controls all the
affairs of the incident report system. Activities performed by this actor include viewing reports,
managing reports, and informing the user about the stages of a report.

FIGURE 1 USE CASE DIAGRAM

10 | P a g e
 LOGIN: This feature allows a student/ user to have access to his/her account.

CREATE REPORT: This feature of the system allows the user to report and add to
his/her history of reports.

REVIEW REPORT: This feature allows the admin to view and start processing the users’
incident reports.

UPDATE TRACKER/PROGRESS: This feature allows the admin to inform the user
about the stage a report is in.

3.4.2 ACTIVITY DIAGRAMS

The following activity diagrams show the individual processes that take place in the incident
report mobile application. These processes begin with the login activity. After the login
activity, the activities of the actors (the user and the admin) follow.

THE LOGIN ACTIVITY DIAGRAM

The login activity is the activity that allows users to log in to the application. Students already
have login credentials that are provided by the school. when a user wants to use the
application, he/she logs in and the user's details are validated to check if the user is in the
system before access is granted to the user to continue using the application.

FIGURE 2: LOGIN ACTIVITY DIAGRAM

11 | P a g e
USER ACTIVITY DIAGRAM

This user activity diagram gives us an idea of the individual activities available to the user.
After the user logs in he/s, he can get the opportunity to create a report and submit it. The user
is also able to view the history of reports made and track the progress.

FIGURE 3: USER ACTIVITY DIAGRAM

12 | P a g e
ADMIN ACTIVITY DIAGRAM

This admin activity diagram helps us know the individual processes that the admin (DOS) has
the power to operate. The admin being the administrator needs an account. The admin has a
full mandate to view and manage reports and also change the state of the progress indicator
depending on the stage/state of the report.

FIGURE 4: ADMIN ACTIVITY DIAGRAM

13 | P a g e
3.4.3 SEQUENCE DIAGRAM
The sequence diagram gives a full step-by-step activity of what goes on during an individual
process.

ADMINISTRATOR LOGIN SEQUENCE DIAGRAM

The administration login sequence diagram shows the full sequence of the activity of the
admin(manager) during login.

FIGURE 5: ADMIN LOGIN SEQUENCE DIAGRAM

14 | P a g e
USER REPORT INCIDENT DETAILS

This sequence diagram shows the step-by-step activity that a user goes through to
successfully make a report.

FIGURE 6: USER INCIDENT REPORT DETAILS

3.4.4 ARCHITECTURAL DESIGN

The system being developed is a mobile application that is internet enabled and therefore
will be implemented using the client/server architecture specifically, the 2 Tier
architecture design. This is an architecture design whereby the client is separated from
the server.
Communication between the client and the server is done through computer networks such
as WIFI, LAN, WAN, Internet, etc. The client can be an application, which uses a graphical
user interface that sends a request to a server for certain services, and the server is the
provider of the services requested by the client. With this architectural design, multiple

15 | P a g e
users can access the system at the same time within different locations. In this architecture,
the user interface runs on the client side and the database is stored on the server. The
business application logic runs on the server side. The client processes provide an interface
for the customer that gathers and presents the data on the computer of the customer. This
part of the application is known as the presentation layer. The server processes provide an
interface with the data store of the business. This part of the application is known as the
data layer. The business logic, which validates data, monitors security and permissions,
and performs other business rules, is kept on the server. The following Figure shows the
e-commerce system’s two-tier architecture diagram.

internet

SERVER DATA

FIGURE 7: ARCHITECTURAL DESIGN

16 | P a g e
3.5 METHODOLOGY
3.6 PROJECT METHOD
3.6.1 WATERFALL MODEL
In this development methodology, the project is divided into sequential phases with some
overlap and splash back acceptable between phases: initial investigation, requirement
definition, system design, coding and testing, implementation, and operation & support.
It emphasizes planning, time schedules, target dates, budgets, and implementation of the entire
system at one time. Tight control is maintained over the life of the project through the use of
extensive written documentation. The perceived advantages of the waterfall process are that it
allows for departmentalization and managerial control. A schedule is typically set with
deadlines for each stage of development and a product can proceed through the development
process. In theory, this process leads to the project being delivered on time because each phase
has been planned in detail. In practice, waterfall development often falls short of expectations
as it does not embrace the inevitable changes and revisions that become necessary with most
projects. Once an application is in the testing stage, it is very difficult to go back and change
something that was not thought of in the concept stage. This methodology is most suitable for
the following: Projects that are for the development of mainframe-based or transaction-oriented
batch systems; a project that is large, expensive, and complicated. In addition, when the project
has a clear objective and solution and there is no need for immediate implementation and lastly,
the user community is fully knowledgeable in the business and its application.

FIGURE 8: WATERFALL MODEL

17 | P a g e
3.6.2 SPIRAL MODEL
The focus is on risk assessment and on minimizing project risk by breaking a project into
smaller segments and providing more ease of change during the development process, as well
as providing the opportunity to evaluate risks and weigh consideration of project continuation
throughout the life cycle. Each trip around the spiral traverses four basic quadrants: (1)
determine objectives, alternatives, and constraints of the iteration; (2) evaluate alternatives;
identify and resolve risks; (3) develop and verify deliverables from the iteration, and (4) plan
the next iteration. (Boehm, 1986 and 1988). Begin each cycle with an identification of
stakeholders and their win conditions, and end each cycle with review and commitment
(Boehm, 2000). The spiral model has the following advantages: Risk factors are considerably
reduced, excellent for large and complex projects, allows for additional functionality later, and
is suitable for highly risky projects with varied business needs. Its limitations include: it’s a
costly model in software development; failure in the risk analysis phase may damage the whole
project; not appropriate for low-risk projects; might get continued and never finish. It is suitable
for real-time time and safety-critical system systems that have risk avoidance as a top priority
and systems where resource minimization is not an absolute priority.

FIGURE 9: SPIRAL MODEL

18 | P a g e
3.6.3 INCREMENTAL MODEL
The incremental Model is a process of software development where requirements are broken
down into multiple standalone modules of the software development cycle. Incremental
development is done in steps from analysis design, implementation, testing/verification, and
maintenance. Each iteration passes through the requirements, design, coding, and testing
phases. And each subsequent release of the system adds function to the previous release until
all designed functionality has been implemented.

FIGURE 10: INCREMENTAL MODEL

3.7 MODEL ADAPTED AND JUSTIFICATION

There are different kinds of software development models that are employed for different kinds
of software depending on the nature and functionalities of a proposed system. Amongst this
kind of model, the incremental approach to software development was adopted for this mobile
application. This approach was adopted since it is easier to change the process to reflect
changing user requirements. With this approach, the system was developed as a series of
versions with each version adding functionality over the previous version. Each version will
be then exposed to the users for them to evaluate and give comments after testing the system.
These comments were taken into consideration in developing the subsequent versions.

The incremental model was chosen over the other approaches such as the waterfall model, and
the spiral model as a result of the nature, scope, and requirements of the proposed system.

The following are some reasons why the incremental model was chosen:

19 | P a g e
 1. It is easier to get customer feedback on the development work that has been done. Users
can comment on documentation of the software and see how much has been
implemented since they find it difficult to judge progress from software design
documents
2. The cost of accommodating changing requirements is reduced. The amount of analysis
and documentation that has to be re-done is comparably less than what is required with
the waterfall model.
3. A more rapid delivery and deployment of useful software to the user is possible with
an incremental model even if not all the functionality has been included.

3.8 PROJECT DESIGN

3.8.1 USER INTERFACE DESIGN
The success and usability of many mobile applications depend greatly on user interface design
and user experience or interactivity. The AIM clone and the DOS applications have been
carefully designed and developed with a very interactive user interface and good user
experience.

USER SPLASH SCREEN

This is the first page that is displayed when the user’s application is launched.

FIGURE 11: USER SPLASH SCREEN

20 | P a g e
LOGIN PAGE

This page displays the login screen o the users’ application. It provides fields, where a user can
enter valid credentials, to gain access to the system.

FIGURE 12: USER LOGIN PAGE

21 | P a g e
HOME PAGE

The home page of the user application is shown in the figure below. Its displays the option of
incident reports and other options available for the user. Our focus will be on the incident report
option.

FIGURE 13: USER HOME PAGE

22 | P a g e
INCIDENT REPORT PAGE

The figure below displays the incident report page. This page is made up of an incident report
form that the user must fill out to lodge a case to the DOS.

FIGURE 14: INCIDENT REPORT PAGE

23 | P a g e
FIGURE 15: INCIDENT REPORT PAGE

24 | P a g e
INCIDENT REPORT HISTORY AND PROGRESS TRACKER PAGE

The figure below displays the incident history and the progress tracker for the incident as
managed by the DOS administrator application.

FIGURE 16: REPORT HISTORY AND PROGRESS TRACKER

25 | P a g e
FIGURE 17 REPORT HISTORY AND PROGRESS TACKER

26 | P a g e
ADMIN LOGIN PAGE

The figure below shows the interface of the admin login page. The admin logs in to the DOS
application with valid credentials.

FIGURE 18: ADMIN LOGIN

27 | P a g e
ADMIN HOME PAGE

The figure below shows the details of the admin home page. This displays the incident reports
sent by the users and they are grouped into categories to help in the easy sorting of reports by
the admin.

FIGURE 19: ADMIN HOMEPAGE

28 | P a g e
ADMIN REPORTS PAGE

The figure below displays the admin reports page where for each category a list of reports are
created. This model implemented the stack data structure were recently sent reports appear on
top.

FIGURE 20: ADMIN REPORTS PAGE

29 | P a g e
ADMIN OFFICE AUTOMATION PAGE

The figure below displays an office automation page for the admin in the management process.
Incidents on the page are categorized based on the stage the report is on, that is, whether
pending, under review, or completed.

F IGURE 21: ADMIN OFFICE AUTOMATION

30 | P a g e
PAGE ADMIN REPORT MANAGEMENT PAGE

The figures below display the incident reports sent by the user and under review by DOS. On
this page, the admin can manage reports as well as change the state of the progress indicator to
inform the user about the current stage of his/ her report.

FIGURE 22: ADMIN REPORT MANAGEMENT PAGE

31 | P a g e
FIGURE 23: ADMIN REPORT MANAGEMENT PAGE

32 | P a g e
 CHAPTER FOUR
SYSTEM IMPLEMENTATION AND TESTING

4.0 INTRODUCTION
This chapter describes how the entire system was developed or constructed, the stages it went
through for the project to be developed and after its development, the testing it underwent.

4.2 DEVELOPMENT
The mobile applications were developed using FLUTTER, DART, and FIREBASE as the main
language and development tools. The system development went through a series of phases
which are: Analysis, Design, Coding, Testing, and Documentation.

• Analysis: This was the first phase in the development process. The developing team
interacted with the potential stakeholders of the system to determine the system
requirements.
• Design: The design being next phase was the phase that took care of the designing of
the system. After every interaction with the various stakeholders, the system was
designed to meet the requirements specified by the stakeholders.
• Coding: The coding of this system was done using the tools and languages stated above.
The main challenge encountered by the development team at this stage was the
implementation of some changing user requirements and how to implement them. But
through consultation and research, we were able to find solutions to these challenges

4.3 TESTING
4.3.1 TEST PLAN
The system was tested to ensure it meets its stated requirements. The challenge posed at this
stage was the unavailability of some stakeholders to thoroughly test this system. The only
advantage is that, through the development stage, testing of some units was carried out. Both
unit testing and system testing were carried out during the phase.

33 | P a g e
 • Unit Testing
Unit testing was carried out concurrently with the development phase. Each module or
program unit was tested to ensure that it meets its stated requirements before new ones
were added.
• System Testing
At the end of the development phase, all the various components were also integrated
and tested as a whole. Some integration errors were identified and corrected in this
phase.

4.3.2 SYSTEM VALIDATION

System validation has to do with determining whether the applications meet and satisfy the
user’s operational needs. It is the assessment of a planned and delivered system to meet and
satisfy the client's operational needs in a realistic environment achievable.

The system was first validated through code writing. At every point, the codes were accessed
and checked to eliminate bugs. The bugs were corrected and this process was done for all the
various application screens. The software that was used to code Dart languages had an error
checker. This helped us a lot in scrutinizing our lines of code and helped us correct them. Also,
we made a few friends who had ideas about coding in the languages we used to help validate
the codes for errors. They used their minds and knowledge to correct constant bugs and kept
running the pages to see if they meant what our users wanted.

Also, the fields that required information to be inputted were carefully validated. Majorly, the
field that required a user to provide information to fill out the form and user logins. These fields
were validated in such a way that a user does not get to submit his/her details if he/she has not
filled all the required fields required. Again, the system was validated to prevent wrong emails
from being entered and accepted.

34 | P a g e
 CHAPTER FIVE

CONCLUSION AND RECOMMENDATION

5.0 INTRODUCTION
In this chapter, we will have a conclusion of this project and look at some recommendations
needed for further studies to develop alike systems. We will discuss the various limitations that
were encountered in this project and can be improved upon subsequently in like systems. A
challenge posed was the unavailability of some other stakeholders of the system. The
development stage allowed the team to meet and interact with some technology professionals
and executive professionals as well. This system will be useful to KNUST in solving problems
relating to students’ affairs.

5.1 SUMMARY
An incident reporting system is a major system found in most IT support systems and
organizations. The necessity of this system is enormous as it is strategic in organizational
development.

This system has been designed and developed in a way that only the stated users have access
to the system. The admin has the freedom to work with this system since all her processes have
been made digital. Users of this system have been presented with convenience as per the goal
of designing this system. Both admin and users have to only interact with the graphical user
interface of the system. The system’s server-side will solely be managed by the IT
administrator.

5.2 FINDINGS
Upon completion of this project, we had a few findings about how beneficial an incident
reporting system is for a school and its management.

Below are some findings.

1. It is cost-effective since most paper works have been automated and especially the
office automation for the admin on managing reports

35 | P a g e
 2. There is better incident management when the admin keeps the user adequately
involved in the resolution of the incidents. This creates trust between the admin and the
user whiles the user finds the system very useful
3. There is total control of information in this system. This is due to the level of sensitivity
of the reports by the user and the confidentiality role of the admin

5.3 CONCLUSION
After studying how different incident reporting systems for students work, it is concluded that:

1. Such systems are beneficial as they help keep track of student safety and incidents
2. The systems vary in terms of features and complexity, so schools should select the one
that best suits their needs
3. The system made it easier for school administrators to track and manage incidents and
reduced the amount of time required to complete incident reports.

5.4 RECOMMENDATIONS
Incident report and management is vital to the daily operations of any organization. Security
must be a priority for future updates of this system. This prevents the leaking of confidential
information. A policy structure should be developed to manage the security matters of this
application.

In future versions of this application, an automated email sender can be integrated to send
emails to a user when the admin moves to another stage. This is a more effective and transparent
way of communication between the admin and the user.

36 | P a g e
REFERENCES

• Build apps for any screen, https://flutter.dev/

• C.W Johnson (October 2003), Failure in Safety-Critical Systems: A Handbook of
Accident and Incident Reporting, from University of Glasgow Press, Glasgow,
Scotland.
• Flutter tutorials, guides, app templates, and packages, www.fluttercampus.com
• Flutter Community – Medium, www.medium.com/flutter-community
• Ian Sommerville, Software Engineering 8th Edition, Functional and Non-Functional
Requirements, from https://libgen.me/item/detail/id/78694

• Stellman, Andrew, Greene, Jennifer (2005), Applied Software Project Management (1 st

Edition). Cambridge, MA: O’Reilly Media

37 | P a g e
APPENDIX

Admin – Administrator

DOS – Dean of Student

IT – Information Technology

LAN – Local Area Network

KNUST- Kwame Nkrumah University of Science and Technology

RAM – Random Access Memory

UML – Unified Modelling Language

USA - University of South Alabama

WAN – Wide Area Network

WIFI – Wireless Fidelity

38 | P a g e