Kingston University, BSc (Hons) (Top-up)

CI6125 Software Development Practice – 2023/24

Esoft Module Leader: Dr Lochandaka Ranatunga

Submission deadline: 21st of December 2023 – before 3.55pm via ELMS and before 3:55pm via Canvas

Software Development Practice Coursework (assessment element 1 -

Group coursework and assessment element 2 - Individual artefacts)

Overall system requirements:

You are required to produce a solution using appropriate process, methodology to analyse, design,
implement and test the software for the scenario described below:

Scenario

Your software firm was assigned to develop a software system to facilitate general public to
make complaints against environmental crime incidents through online and mobile based
applications with evidence directly to two institutions, namely Wildlife conservations and Forest
conservations. The two institutions should be able utilise these complaints to take preventive,
protective and legal actions for the conservation of wildlife, forestry and environmental
resources. Further the system should provide necessary facilities for incident progress
monitoring and reporting for key stakeholders. The intended system should be able to satisfy
the following key top-level objectives:

i|Page
  To enable public to submit complaints against wildlife, forestry and environmental crime
activities through the application system using online web system and/or mobile application.
 To take wildlife conservation and forestry conservations institutes under a one network of
communication and complaints management.
 To facilitate each institution under the system to manage the procedural workflow of
investigations triggered through a complaint directed to them and report the status of the
investigation with greater accountability with respective to their responsibilities.
 To provide divisional, institutional, national level dashboards for wildlife, forestry and
environmental crime incident monitoring, reporting and decision support mechanism.

It is also noted that the intended software should facilitate the following features,

 Facilitate with multiple user roles and their privileges within the system to match with the user
levels available in each institutional framework while providing the facilities for the user role and
privilege customisation capabilities.
 Software should be able to capture the actions taken by each responsible officer related to
directed complaints with evidence of the investigations. This includes the reporting of progress
of incident investigations with locations, photos, time frame etc.
 Software should facilitate the incident management workflow appropriately (logically) for each
institution into the system with their divisions, branches, beat offices and different roles and
officers etc.
 Software should be designed to empower necessary security measures to provide officers’
mobile applications with relevant device-based authentication.
 There should be a disaster recovery mechanism for the entire system to keep up with high
availability.
 The availability of audit trail for all actions on the system where the highest-level system
administrator should be able to review the records when needed.
 The officers should be able to indicate the actions that have been taken and update the status
complainer to be kept informed all times. You are required to design a web and mobile apps to
achieve above objectives. High-level system component requirement are as follows.
1. The system should have two components.
a. Back-end server application with appropriate persistence storage.
b. Front-end client application with responsive features.
2. The complainers should be able to register in the system and multiple registrations per
identity should be prevented.
3. Administrators should be able to manage all users and their levels.
4. Field / beat officers should be able to mark the status of the reservation upon customer
activities accordingly.

ii | P a g e
 5. The complaints should be directed to the relevant area office and the institutions based on
the characteristics of the complaint automatically as much as possible, otherwise, they
should be allocated manually.
By considering the brief outline requirements given above, you should try to derive and justify the
hidden and implicit requirements.

THIS COURSEWORK HAS TO BE COMPLETED IN GROUPS OF FOUR TO FIVE STUDENTS. Please form the
groups within your batch only.

Note: The security mechanisms should be considered as Top priority in this application system.

Deliverables:

There are two major submissions; a group submission covering the overall product design and
development done at group level (assessment element 1), and an individual submission covering
component level work carried out by you as a member of the team (assessment element 2).

A. Group submission (30% of the module mark)

Supply professional standard product documentation presenting the evidence for completing
the following aspects of the system development tasks and the associated artefacts.
1. Introduction and background – introduce the overarching need for the system, and your
overall approach.
2. Software requirements specification, including discussions on system analysis tasks and
their outcomes.
3. Software design including the system architecture design, and the system specification.
Here you should present how individual components and services have been designed to
meet the underlying requirements of the system. There should be sufficient discussion on
the separation of concerns, how component communications are taking place, and security
concerns you have considered.

iii | P a g e
 4. Implementation – development of the system using appropriate programming language,
tools, frameworks etc.

5. Software quality approaches adopted, including testing strategies, validation and

verification approaches and evaluate their effectiveness in producing quality software.
6. Clarification on the use of software tools for the project implementation including
collaboration tools. Each group should demonstrate the use of software development tools
and collaboration tools during the demonstration, which is a key component. In this case,
Cloud tools are to be used such as Git, Bitbucket, JIRA, selenium, etc., based on the
purposes.
7. Product presentation covering the system design, development and evaluation processes
and the product demonstration. A video of the working product should also be provided.

The final submission to Kingston Canvas should be a group submission, presented as a group report
along with the necessary resources (such as software code and libraries) provided in a zipped folder.
This submission should be made by the team's designated manager, which means there should be
one submission per group. The report must prominently display the list of team members and their
respective contributions, expressed as percentages, for each of the seven tasks that were
collectively agreed upon through consensus. The overall group mark will be distributed to individual
group members according to their individual contributions to the tasks. If this detailed information
is not provided, a statement should be included, indicating that all team members contributed
equally. In such a case, all team members will receive the same group mark.

B. Individual submission (30% of the module mark)

Each member of the group must implement a part (two or more components) of the software. i.e.
functions such as the login, complaint recording, incident monitoring, daily report service and so on.
The components you are responsible for should be clearly indicated, referring to the overall
architecture diagram (provided as part of task 3 of the group work).
The individual submission should include a report, associated software elements (code, libraries
etc.) and an individual presentation.
The individual report submission should cover the below.
1. Introduction to the components you were responsible for, functional features covered by
each of those components, their scope, and boundaries, and how they communicate within
the system.
2. Presentation of each component with suitable diagrams, discussions etc. covering its
interface, workflow design, and development. This should contain the appropriate code
snippets, and clear indication on the underlying workflow, any algorithms involved.

iv | P a g e
 3. Test plan and test outcomes for the respective components. Each member of the group
must test your implemented software components, while following the overall testing
strategy agreed at the team level.
For example, if you were responsible for two components, your individual report should contain the
overall introduction (element 1 above), component-1 presentation, component-1 testing,
component-2 presentation, component-2 testing (i.e., elements 2 and 3 should be repeated for
each component).
4. An individual presentation demonstrating the components you were responsible for. Here,
you need to also present the approach and tools you adopted to complete the allocated
tasks, how you collaborated at team level, any challenges faced, outcomes and your
reflections on the overall experience.

Marking criteria
Group submission (30% of the module mark)
Element Marks available
1. System introduction and background – a clear description of the 10
problem domain being tackled, clear indication on the problem
understanding, and the overall approach taken by the team to
understand the problem at holistic, and functional levels. Evidence
additional research.
2. Software requirements specification – clear list of functional and 10
non-functional requirements, with suitable discussions on the
requirement elicitation tasks.
3. Software design – system design process, and design models 15
including the system architecture; architecture diagram, interface

v|Page
 models, DFD, UML models etc
4. Implementation – evidence for working prototype or built system 30
versions, with justification for the selected methodology
5. Software quality assurance - software-test design, test 15
implementation and test report, evidence of the testing with
prepared test data as specified in the requirements specification,
justification for the selected methodology. Acceptance testing is a
must.
6. Use of collaborative tools – good evidence for the use of 10
appropriate collaborative tools and automating tools
7. Group presentation – group’s presentation of the overall system 10
development process, system demonstration, system evaluation
outcomes, and overall reflections.
Total 100

vi | P a g e
Individual submission (30% of the module mark)

Element Marks available

1. Introduction to components – presentation of the components

10
covered by the individual work, referencing to the architecture
diagram of the system. Clear description of the functional
requirements or services covered by respective components,
scope of the service, component boundaries, and communication
mechanisms in place. Appropriate focus on cohesion and coupling
aspects. User stories covered should be elaborated.
2. Component presentations – comprehensive introduction to
50
components, clear indication of the functions covered, their
dependencies with other components, design of the components
work-flow, interfacing, data flow etc. Suitable discussion on the
development steps, challenges faced, solutions adopted, evidence
for interactions. Limitations or future work associated with any
failed or incomplete components. Preparation of cost estimation
for the individual component with the approach.
3. Component level quality assurance – Test plan and test outcomes
20
for each of the components, with clear evidence (e.g. screen
captures, log files). Evidence for Test driven development and/or
test automation where appropriate. Discussions on other quality
assurance methods adopted/recommended.
4. Individual presentation – Comprehensive presentation of the
20
component development process. Demonstration of software
development and quality assurance skills and awareness. Evidence
for good collaborative work practices, use of appropriate tools.
Ability to answer questions on the tools, process followed,
implementation outcomes and future work.

Total 100

vii | P a g e
Level of work expected:
This is a major piece of work, and it is expected that you will need to do some very thorough research
and that ideally your research will be as up to date as possible given that this is a very rapidly moving
field. Work containing vague descriptions or unsupported assertions will be penalised.

Feedback:
You can invite the module-staff to review your progress and provide formative-feedback.

Academic Integrity:
Academic integrity means demonstrating honest, moral behaviours when producing academic work.
This involves acknowledging the work of others, giving appropriate credit to others where their ideas are
presented as part of your work and the importance of producing work in your own voice. Contributions
by artificial intelligence (AI) tools must be properly acknowledged. As part of a learning community
students share ideas and develop new ones - you need to be able to interpret and present other
people's ideas and combine these with your own when producing work.

Plagiarism (including copying, self-plagiarism and collusion)

The act of presenting the work of another person (or people) and/or content generated by
artificial intelligence (AI) tools as your own without proper acknowledgement. This includes
copying the work of another student or other students.

The University expects students to take responsibility for the security of their work (i.e. with
written work, to ensure that other students do not get access to electronic or hard copy of the
work). Failure to keep work secure may allow others to cheat, and could result in an allegation
of academic misconduct for students whose work have been copied, particularly if the origin of
the work is in doubt.

Self-plagiarism
The act of presenting part or all of your work that has been previously submitted to meet the
requirements of a different assessment, except where the nature of the assessment makes this
permissible.
viii | P a g e
 Collusion
The act, by two or more students, of presenting a piece of work jointly without acknowledging
the collaboration. This could include permitting or assisting another to present work that has
been copied or paraphrased from your own work.
The University also defines collusion as the act of one student presenting a piece of work as
their own independent work when the work was undertaken by a group. With group work,
where individual members submit parts of the total assignment, each member of a group must
take responsibility for checking the legitimacy of the work submitted in his/her name. If even
part of the work is found to contain academic misconduct, penalties will normally be imposed
on all group members equally.

Purchasing or Commissioning
The act of attempting to purchase or purchasing work for an assessment including, for example
from the internet, or attempting to commission, or commissioning someone else to complete an
assessment on your behalf.

The procedures for investigating suspected cases of academic misconduct are set out in
Academic Regulations 6 Academic Integrity - Taught Courses 2023/24

You must meet all deadlines set. Failure to do so will result in a penalty.
Work submitted late but within a week of the deadline will be capped at 40% and receive a grade of LP
(Late Pass) unless it is not of a passing standard in which case it will receive a grade of LF (Late Fail).
Work submitted beyond a week of the deadline without approval will get 0% with a grade of F0. If,
however, you have a serious problem, which prevents you from, meeting the deadline you may be able
to negotiate an extension in advance. In the first instance you should contact the module team for
advice. However any extension will need to be formally agreed by the Faculty via the Mitigating
Circumstances process, your work will then be marked without penalty.

Acknowledgement

ix | P a g e
First and foremost, we would like to express our sincere thanks to our team members who demonstrated
unwavering commitment and worked tirelessly to bring this report to fruition. Each member's unique
skills and perspectives significantly contributed to the depth and quality of our work.

We are indebted to our lecturer Dr Lochandaka Ranatunga, whose invaluable insights and guidance
provided the necessary direction and inspiration throughout the project. Your guidance and
encouragement have been instrumental in shaping the outcome of our efforts.

Thank You,
Ahnaf Ahamed

Abstract

x|Page
This is report was created as a documentation for the application developed for the Wildlife conservations
and Forest conservations to gather/track complaints from the public for any illegal activities related to
wildlife and environment. The product was developed by 5 group members, namely, Ahnaf Ahamed,
Fazloon Farook, Diyan Hadgie, Mihit Roshan and Muhammad Akram.

The team chose kanban methodology of agile software development methodology to implement this
software product. Further justifications and reasons for the above decision has been mentioned in depth in
the upcoming sections of the report. Moreover, a system architecture design has also been developed for
the application.

During the requirements gathering and analysis phase of the project, a Software Requirement
Specification report has been created which includes the software requirements and analysis specification.
The system design phase has delivered the report which consists for a software design document, which
compromises of various diagrams, including Data Flow Diagram (DFD), OOAD using UML diagrams
(i.e activity and sequence diagrams), ER-Diagram and so on.

The application is implemented has three main components the backend API, which is built using
Laravel, the public can use a mobile app which is built using Flutter or a Web App and the Admin panel
and Public facing Web App is built using Angular.

For the testing phase, unit testing and acceptance testing has been conducted to make sure that the system
fulfils all business requirements and is less prone to errors and bugs.

Collaboration tools like Jira, Google Meet and Bitbucket was used to make teamwork a lot easier and
more
manageable. With the help of these collaborative tools, managing the workload was much easier as
everyone has visibility and a sense of the project progress.

Contents
xi | P a g e
Acknowledgement.........................................................................................................................................x

Abstract.........................................................................................................................................................xi

Glossary of Terms.......................................................................................................................................xvi

Introduction....................................................................................................................................................1

Background................................................................................................................................................1

Problem in Brief.............................................................................................................................................2

Aim & Objectives..........................................................................................................................................3

Software Requirements Specification............................................................................................................4

1. Introduction............................................................................................................................................4

1.1 Purpose.......................................................................................................................................4

1.2 Scope................................................................................................................................................4

2. Requirements.........................................................................................................................................6

Functional Requirements.......................................................................................................................6

Non-Functional Requirements...............................................................................................................6

System Architecture Diagram........................................................................................................................8

ER Diagram.................................................................................................................................................10

Use Case Diagram........................................................................................................................................11

Activity Diagram.........................................................................................................................................12

Software Development Methodology..........................................................................................................13

Software Development Methodology Selected.......................................................................................14

Agile Software Development Methodology............................................................................................14

Justification for using Kanban Framework in Agile............................................................................15

Implementation............................................................................................................................................19

Important Code Snippets..........................................................................................................................21

Backend....................................................................................................................................................21

User Registration.................................................................................................................................21

Create a Complaint..............................................................................................................................22

xii | P a g e
 Get User Data.......................................................................................................................................23

Get All Complaints..............................................................................................................................24

Mobile App..............................................................................................................................................25

Dashboard............................................................................................................................................25

Function to Get All Complaints...........................................................................................................27

Function to Get User Details................................................................................................................28

Web Application......................................................................................................................................29

Account Service...................................................................................................................................29

Complaint Service................................................................................................................................30

Making a Complaint............................................................................................................................31

Database...................................................................................................................................................32

Use of Collaborative Tools..........................................................................................................................33

Jira - Agile Kanban Project Management................................................................................................33

Git and Bitbucket - Version Control........................................................................................................35

Google Meet – Virtual Collaboration......................................................................................................36

Testing..........................................................................................................................................................37

Critical Review and Conclusion....................................................................................................................7

References......................................................................................................................................................9

Appendices...................................................................................................................................................10

Group Members.......................................................................................................................................10

List of Figures
xiii | P a g e
Figure 1 - High Level Architecture Diagram.................................................................................................8
Figure 2 - ER Diagram.................................................................................................................................10
Figure 3 - Use Case Diagram.......................................................................................................................11
Figure 4 - Activity Diagram.........................................................................................................................12
Figure 5 - Kanban Framework.....................................................................................................................15
Figure 6 - Kanban Board..............................................................................................................................16
Figure 7 - Product Backlog..........................................................................................................................16
Figure 8 - Function for User Registration....................................................................................................21
Figure 9 - Function for Creating a Complaint.............................................................................................22
Figure 10 - Function to get User Data.........................................................................................................23
Figure 11 - Function to get user data based on ID.......................................................................................23
Figure 12 - Function to get all complaints...................................................................................................24
Figure 13 - Mobile - Dashboard Code - I....................................................................................................25
Figure 14 - Mobile - Dashboard Code - II...................................................................................................26
Figure 15 - Mobile - Get All Complaints Code...........................................................................................27
Figure 16 - Mobile - Function to get User Details.......................................................................................28
Figure 17 - Account Service........................................................................................................................29
Figure 18 - Complaint Service.....................................................................................................................30
Figure 19 - Making a Complaint..................................................................................................................31
Figure 20: Database Structure......................................................................................................................32
Figure 21 - Kanban Board............................................................................................................................34
Figure 22 - Backlog Board...........................................................................................................................34
Figure 23- Repositories in Bitbucket...........................................................................................................35

List of Tables
xiv | P a g e
Table 1: Test case mobile user registration....................................................................................................3
Table 2: Test case for mobile user login........................................................................................................5
Table 3: Test case for mobile user dashboard................................................................................................8
Table 4: Test case for mobile user make complaint....................................................................................10
Table 5: Test case for mobile user change details.......................................................................................12

xv | P a g e
Glossary of Terms

UML – Unified Modelling Language

DFD – Data Flow Diagram

ERD / ER-Diagram – Entity Relationship Diagram

SDLC – Software Development Life Cycle

SAFe – Scaled Agile Frameworks

xvi | P a g e
Introduction

This initiative marks a stride towards innovation, geared at designing a state-of-the-art software solution
to confront pressing environmental challenges. Entrusted with this significant responsibility, our software
firm is dedicated to constructing a robust system that enables effortless reporting of environmental crimes
via online and mobile applications. This system acts as a direct conduit, linking concerned citizens to two
pivotal institutions: Wildlife Conservation and Forestry Conservation. Our primary objective is to
catalyze swift and decisive actions for safeguarding and conserving wildlife, forestry, and our invaluable
environmental assets.
Our envisioned system strives to bridge the gap between public complaints and institutional actions,
facilitating a cohesive approach towards environmental crime management. By harnessing technology,
our goal is to empower institutions and the public alike in preserving and protecting our wildlife, forestry,
and environmental resources.

Background
As environmental crimes affecting wildlife and forests become more serious, it's clear that we need a
better way to handle these issues. That's why our software company is working hard to create a complete
software solution. This system will change how we report and deal with environmental crimes.
This system is designed to help the public report incidents easily while also improving how conservation
institutions work. We want to make reporting simple using websites and apps, encouraging people to take
responsibility and work together on these important environmental problems. Plus, it sets up a smooth
way for Wildlife Conservation and Forestry Conservation institutes to handle and keep track of
complaints.
The system is all about efficiency and making sure everyone involved is accountable. It helps each
institution handle investigations prompted by complaints really well, making the process transparent and
responsible. Plus, it comes with detailed dashboards that cover different levels – from local to national –
improving how incidents are watched, reported, and decisions are made.
This project has lots of useful features, like different user roles with customizable access, smart ways to
track incidents with proof, and organized workflows that fit each institution's structure and tasks.
It's made of a strong back-end server linked with the right storage and a user-friendly front-end
application. It stops multiple registrations from the same person, makes it easy for administrators to
manage users, and sends complaints straight to the right offices based on what the complaint is about.

1|Page
This whole thing is a mix of new technology and standing up for conservation. It creates a solid place for
reporting, dealing with, and acting on environmental crimes.

Problem in Brief

In response to the escalating challenges associated with environmental crimes, our software firm has been
tasked with developing an extensive software system aimed at encouraging public engagement in
reporting incidents related to wildlife, forestry, and environmental violations. The primary goal is to
establish a robust system enabling the public to submit complaints, supported by evidence, through online
web systems and mobile applications. These complaints are directed to two pivotal institutions, Wildlife
Conservation and Forest Conservation, which play a crucial role in leveraging this information to initiate
preventive, protective, and legal actions for the conservation of wildlife, forestry, and environmental
resources.

i. Lack of fitting security and upkeep of the complaint record in the system that make avenue for
disappointment and control of information.
ii. Lack of accurate, concise data regarding wildlife incidents, regulations, and behavioural patterns
poses a significant challenge in the effective management of public complaints within the
wildlife and Environmental Conservations.
iii. Poor performance of the manual system may lead into the missing or exploitative of the
complaint by the staff or any member of the management,
This is a circumstance where there is no avenue made for survey of the complaint. This obstructs
satisfactory upkeep of the system.
iv. There is no unified system or central database set up to screen transfer of complaint submitted on
paper or as verbal representation.

2|Page
Aim & Objectives
Aims
 Enable the public to actively contribute to wildlife and forest conservation efforts by
reporting incidents of environmental crimes, illegal activities, and threats to biodiversity.
 Implement a seamless communication channel between the public and conservation
authorities to ensure timely reporting and resolution of conservation-related issues.
 Involving the public in identifying and addressing environmental concerns promotes a shared
responsibility for conservation.
 Optimize the use of resources, including staff and equipment, by prioritizing and addressing
reported incidents based on their urgency and severity.

Objectives
· Create a user-friendly online and mobile interface for the public to report wildlife and
environmental crimes effortlessly, with an option to attach evidence.
· Establish a unified network for communication and complaint management, connecting
wildlife and forestry institutions to enhance collaboration and information sharing
· Provide dashboards for wildlife, forestry, and environmental incidents at divisional,
institutional, and national levels, ensuring real-time reporting, data analysis, and decision-
making support.
· Allow multiple user roles in the system to match the structures of wildlife and forestry
institutions, with customization options to align with different responsibilities.
· Capture specific actions taken by officers in response to complaints, including progress
reports with location details, photos, and time frames.
· Allow officers to provide updates on actions taken and inform complainants of the status of
their complaints, ensuring transparency throughout the process.

3|Page
Software Requirements Specification
1. Introduction

The aim of this document is to gather and analyse and give an in-depth insight of the complete
software system for Wildlife conservations and Forest conservations, by defining the problem
statement in detail. Nevertheless, it also concentrates on the capabilities required by stakeholders
and their needs while defining high-level product features. The detailed requirements of the
software system are provided in this document.

1.1 Purpose

The purpose of the document is to collect and analyze all assorted ideas that have come up to define the
system, its requirements with respect to consumers. Also, we shall predict and sort out how we hope this
product will be used in order to gain a better understanding of the project, outline concepts that may be
developed later, and document ideas that are being considered, but may be discarded as the product
develops.

In short, the purpose of this SRS document is to provide a detailed overview of our software product, its
parameters, and goals. This document describes the project's target audience and its user interface,
hardware and software requirements. It defines how our client, team and audience see the product and its
functionality. Nonetheless, it helps any designer and developer to assist in building the product
successfully.

1.2 Scope

This report aims to comprehensively outline the design and development of a software system dedicated
to facilitating public engagement in reporting environmental crimes. The system is designed for both
online web and mobile applications, enabling users to submit complaints along with evidence directly to
Wildlife Conservation and Forest Conservation institutions. The primary objectives include empowering
these institutions to take preventive, protective, and legal actions for wildlife, forestry, and environmental
conservation.

4|Page
The report's scope encompasses the following key areas:

User Interaction and Complaint Submission:

Designing an intuitive and user-friendly interface for the public to submit complaints against wildlife,
forestry, and environmental crimes through both online web and mobile applications.

Institutional Integration and Communication:

Establishing a unified network of communication and complaints management between Wildlife
Conservation and Forest Conservation institutions, ensuring seamless collaboration.

Procedural Workflow Management:

Facilitating each institution's management of procedural workflows triggered by complaints, with a focus
on accountability and transparent reporting of investigation statuses.

Dashboard Development:
Developing divisional, institutional, and national-level dashboards for effective monitoring, reporting,
and decision support mechanisms related to wildlife, forestry, and environmental crime incidents.

User Role Customization:

Implementing multiple user roles with customizable privileges, aligning with the unique user levels
present in each institutional level.

Security Measures and Authentication:

Empowering the system with robust security measures to provide users with standard authentication,
ensuring secure access.

Disaster Recovery Mechanism:

Implementing a disaster recovery mechanism for the entire system to maintain high availability and
ensure continuity in case of unforeseen events.

Tracking Progress:
Enabling officers to indicate actions taken and update complainants on the status, ensuring continuous
and informed status update throughout the process.
5|Page
2. Requirements

Functional Requirements

Public
 Ability to public to create and register accounts.
 Ability to submit a complaint with pictures to a relevant conservation.
 Ability to see submitted complaints and progress.

Admin
 Ability to create/update/delete users(admin/officers).
 Ability to assign complaints to relevant beat officers.
 Ability to view complaints.
 Ability to update complaints.

Officers
 Ability to update user’s profile.
 Ability to view complaints.
 Ability to update complaints.

Non-Functional Requirements

Security
 Ability to restrict user access based on roles and permissions.
 Ability to monitor system activity and generate audit trails.

Scalability
 Ability to handle increasing volumes of data and users.
 Ability to support multiple locations and divisions.

Performance
6|Page
 Ability to handle concurrent user sessions and transactions.
 Ability to generate reports and analytics in a timely manner.
 Ability to maintain system uptime and minimize downtime.

Usability
 Ability to provide a user-friendly interface with intuitive navigation.
 Ability to customize system settings and preferences.
 Ability to provide online help and user guides for system users.

7|Page
System Architecture Diagram

The proposed architecture is a streamlined and efficient system that comprises a backend, a web service,
and a MySQL database, fostering seamless communication between these components. The architecture
caters to both web and app clients, facilitating interaction via a well-defined API’s

Figure 1 - High Level Architecture Diagram

Backend:

The backbone of the architecture, the backend, serves as the central processing unit responsible for
handling business logic and data processing. It acts as the intermediary between the client applications
and the MySQL database, orchestrating data flow and ensuring efficient communication.

8|Page
Web Service:

The web service is a critical component of the backend, providing a standardized interface for
communication. Functioning as an API endpoint, it enables web and app clients to send requests and
receive responses, creating a decoupled and scalable system.

MySQL Database:

The MySQL database serves as the persistent storage layer, efficiently storing and retrieving data
requested by the web service. It is designed to handle data in a structured manner, ensuring data integrity
and reliability for the entire system.

Web and App Clients:

The architecture accommodates both web and app clients, offering a flexible and accessible user
experience.
Clients interact with the backend through the API, allowing for a consistent and uniform communication
channel irrespective of the client type.

API Communication:

The API acts as a bridge between the clients and the web service, facilitating secure and standardized
communication. It supports various endpoints to enable different functionalities, such as data retrieval,
submission, and updates, catering to the diverse needs of the clients.

Benefits and Considerations:

 This architecture promotes modularity and scalability, allowing for easy expansion of
functionalities and accommodating a growing user base.

 The separation of concerns between the backend, web service, and database enhances
maintainability, making it easier to update and optimize individual components.

9|Page
  The API-driven communication ensures a consistent user experience across web and app clients,
promoting interoperability and ease of development.
In summary, this architecture establishes a robust foundation for building a responsive and scalable
system. By leveraging a well-defined API, it enables seamless communication between clients and
backend components, ensuring a cohesive and efficient user experience for both web and app users.

ER Diagram

Figure 2 - ER Diagram

10 | P a g e
Use Case Diagram

Figure 3 - Use Case Diagram

11 | P a g e
Activity Diagram

Figure 4 - Activity Diagram

12 | P a g e
Software Development Methodology

In the information and technology industry, various software development methodologies are being used
to analyse, design, develop, test, and deploy a software product. These methods are developed by
professionals and organizations as to ease the process of developing a software product.

It would be difficult to manage the process of building a software without a proper structure or
framework. So therefore, these methodologies provide a framework to analyse a system effectively. There
are basically two types of Software Development Methodologies, Traditional and Agile Software
Development Methodology.

Traditional methodologies frequently use models like Spiral, Waterfall, and Prototyping. Common steps
included in these models are requirement gathering, system design, development/implementation, testing,
deployment, and maintenance. These phases are often carried out in the order listed above. A few
repetitions of the System Design phase may be allowed in the case of prototyping, providing that the
client and other stakeholders are happy with the given prototype.

On the other hand, the Agile Methodologies comprise, among other frameworks, Scaled Agile
Frameworks (SAFe), Extreme Programming, Lean Software Development, Rapid Application
Development, Scrum, and Kanban. These Agile frameworks approach software development in a creative
and customer-focused manner.

In the below sections, we will go into detail about the Software Development Methodology selected with
justifications to develop the complaint management system for Wildlife conservations and Forest
conservations.

13 | P a g e
Software Development Methodology Selected
The Software Development Methodology used to carry out the project has a significant impact on its
effective completion; without the right methodology in place, teamwork on a project will not be possible.
A development methodology gives us instructions on how to proceed with working on the project and
reaching the required milestones. particularly in a group.

After conducting some research on the best Software Development Methodology for the case in hand, the
author and his teammates decided to use the Agile Software Development Methodology but there are
different frameworks in Agile that can be used, so the team did some more research on the Agile
methodology and its frameworks.

Agile Software Development Methodology

The Agile methodology is a project management technique that emphasizes constant collaboration and
improvement by splitting the project into phases. Teams go through a planning, execution, and evaluation
cycle.

Agile demands cooperative cross-functional teams, in contrast to the conventional "waterfall" approach,
which has one discipline contribute to the project before "throwing it over the wall" to the next
contributor. Agile is fundamentally based on open communication, teamwork, adaptation, and trust.
While the work to be produced is usually prioritized by the project lead or product owner, the team takes
the lead in determining how the work will be completed, self-organizing around specific tasks and
responsibilities. (Anon., n.d.)

Agile as a methodology began with the release of the Agile Manifesto in 2001. Numerous agile
frameworks, including lean, kanban, scrum, and extreme programming (XP), have since been developed.
In their own unique ways, each exemplifies the fundamental ideas of frequent iteration, ongoing learning,
and high quality. Software development teams like Scrum and XP, but teams focused on providing
services, such as IT or HR, love kanban. (Anon., n.d.)

14 | P a g e
Justification for using Kanban Framework in Agile

The team opted for Kanban within the Agile framework due to its flexibility, adaptability, and emphasis
on visualizing and managing workflow. By choosing Kanban, the team sought to leverage its principles to
streamline the development process and enhance collaboration. The visual nature of Kanban boards
allows for a clear representation of tasks and their progress, providing transparency and facilitating
effective communication among team members.

Kanban's focus on Work in Progress (WIP) limits aligns well with the Agile value of delivering working
software incrementally. This approach allows the team to maintain a steady flow of work, identify and
address bottlenecks promptly, and respond agilely to changing priorities. Additionally, the team
recognized the value of Kanban's metrics, such as lead time and cycle time, as essential tools for
measuring performance and continuously improving their development processes.

The decision to integrate Kanban into the Agile methodology reflects the team's commitment to
continuous learning and adaptation. By embracing Kanban, the team aims to foster a collaborative
environment where stakeholders can easily track progress, provide timely feedback, and witness the
incremental delivery of valuable features throughout the development lifecycle. Overall, the team
believes that the combination of Agile with Kanban provides an effective framework for achieving
project goals while maintaining the flexibility necessary for responding to evolving requirements.

15 | P a g e
 Figure 5 - Kanban Framework

Kanban Board
A Kanban board is typically a physical or digital display that represents the stages of a workflow. It
consists of columns that represent different stages in your process, from the beginning to the end. The
board provides a visual representation of work items as they move through each stage.

Figure 6 - Kanban Board

16 | P a g e
Product Backlog
A product backlog in Kanban is a visual representation of the items a team may or may not deliver. It's an
ordered list of everything a team needs to work on for a product.

Figure 7 - Product Backlog

Lists
Lists, also known as swim lanes or columns, are the vertical sections on a Kanban board that represent the
different stages of your workflow. Each list corresponds to a specific phase of work. Common lists
include "To Do," "In Progress," and "Done." Lists are customizable based on the unique workflow of the
team.

Cards
Cards are visual representations of individual work items or tasks. Each task is represented by a card, and
these cards move horizontally across the board as they progress through the workflow. The card typically
contains key information about the task, such as a brief description, assignee, due date, priority, and any
other relevant details.

Epic
In the context of project management, particularly in Agile methodologies like Scrum, an Epic is a term
used to describe a large body of work that can be broken down into smaller, more manageable tasks or
user stories. Epics are essentially high-level containers that encompass a significant scope of work, and
they serve as a way to organize and structure the project backlog.

Work in Progress (WIP) Limits

17 | P a g e
Work in Progress (WIP) limits are a fundamental concept within the Kanban framework and play a
crucial role in managing and optimizing workflow. WIP limits are constraints placed on the number of
work items allowed at different stages of the process simultaneously. This constraint helps control the
flow of work, prevent overloading the team, and identify and address bottlenecks in the process.

Here are key aspects and benefits of implementing WIP limits:

 Balancing Workloads:
WIP limits ensure a balanced workload by restricting the number of tasks that can be in progress
at any given time. This prevents team members from being overwhelmed with too many
concurrent responsibilities.

 Identifying Bottlenecks:
By visualizing WIP limits on the Kanban board, teams can quickly identify bottlenecks or areas
of congestion in the workflow. If a stage consistently exceeds its WIP limit, it indicates that the
team may need to address inefficiencies or allocate more resources to that particular stage.

 Faster Cycle Times:

Implementing WIP limits often leads to faster cycle times. When teams concentrate on
completing tasks rather than starting new ones, work items move through the process more
swiftly, enabling quicker delivery of valuable increments.

WIP Limits used by the team.

The team decided to have WIP limit of 10 that is 5 people times 2 tasks, a member of the team can only
be working in a maximum of 2 tasks at a time.

18 | P a g e
Implementation

In the implementation phase of the project, the team had few online meetings to discuss the individual
skills and familiarity with the technologies, based on that a thoughtful selection of technologies was
crucial to ensure robust and efficient development across various components of the application. The
team leveraged Laravel for API development with MySQL as the database backend, Angular for the
frontend development, and Flutter for the mobile application. The administrative panel and public-facing
web application were built using Angular, while the public-facing mobile application was built using
Flutter.

1. Laravel for API Development with MySQL

Laravel, a PHP web application framework, was chosen for its elegance, simplicity, and
developer-friendly features. Its robust ecosystem and built-in tools for API development made it
an ideal choice for creating a scalable and maintainable backend. MySQL, a widely used
relational database, complements Laravel seamlessly, providing a reliable and efficient data
storage solution.

2. Angular for Frontend (Admin Panel and Public-Facing Web App)

19 | P a g e
 Angular, a powerful TypeScript-based framework, was selected for developing both the admin
panel and the public-facing web application. Its modular architecture, two-way data binding, and
extensive library of pre-built components simplify the development process. Angular's ability to
create dynamic, single-page applications aligns with the project's requirements for a responsive
and user-friendly interface.

3. Flutter for Public-Facing Mobile App:

Flutter, a UI toolkit by Google, was chosen for building the public-facing mobile application due
to its ability to create natively compiled applications for mobile, web, and desktop from a single
codebase. Flutter's hot-reload feature accelerates development, while its expressive UI
components contribute to a consistent and visually appealing user experience across different
platforms.

Overall Benefits:

Code Reusability: The use of Flutter enables significant code reusability between the Android and iOS
versions of the mobile app, minimizing duplication of effort.

Consistent User Experience: By employing Angular for both web applications, the team ensures a
consistent user experience and design language across different interfaces.

Scalability and Maintainability: Laravel's modular and clean architecture, coupled with Angular's
component-based structure, contributes to the scalability and maintainability of the overall system.

Efficient Development: The combination of Laravel, Angular, and Flutter, each chosen for their specific
strengths, fosters efficient and parallel development of various components by specialized teams.

In summary, the selected technologies harmoniously align with the project's objectives, ensuring a well-
integrated, scalable, and user-friendly implementation of the application.

20 | P a g e
Important Code Snippets

Backend
Below you can find code snippets of some functionalities implemented in the backend.

User Registration

21 | P a g e
 Figure 8 - Function for User Registration

Create a Complaint

22 | P a g e
 Figure 9 - Function for Creating a Complaint

Get User Data

23 | P a g e
 Figure 10 - Function to get User Data

Figure 11 - Function to get user data based on ID

Get All Complaints

24 | P a g e
 Figure 12 - Function to get all complaints.

Mobile App
Below you can find code snippets of some functionalities implemented in the mobile app.
25 | P a g e
Dashboard

Figure 13 - Mobile - Dashboard Code - I

26 | P a g e
 Figure 14 - Mobile - Dashboard Code - II

Function to Get All Complaints

27 | P a g e
Figure 15 - Mobile - Get All Complaints Code

28 | P a g e
Function to Get User Details

Figure 16 - Mobile - Function to get User Details

29 | P a g e
Web Application

Account Service

Figure 17 - Account Service

30 | P a g e
Complaint Service

Figure 18 - Complaint Service

31 | P a g e
Making a Complaint

Figure 19 - Making a Complaint

32 | P a g e
Database

Figure 20: Database Structure

The database includes tables such as branch, complaints, complaint_process, division, failed_jobs,
institutions, migrations, officer, person, personal_access_tokens, and for each specific functionalities.
Tables like complaints and complaint_process are for managing and processing wildlife-related
complaints. Fields in the complaints table include title, description, location, and status, indicating the
nature of each complaint. The institutions table has data related to different institutions involved in
wildlife conservation and forest conservation. The officer table stores information about officers
associated with the wildlife conservation project. The users table includes entries for different user types,
representing administrators, officers, and the public.Authentication. for the security concern of the
database, the personal_access_tokens commonly used for API authentication and security. In this case,
the system uses bearer tokens, which were generated using Laravel sanctum.

33 | P a g e
Use of Collaborative Tools

In the development journey of the application, effective collaboration and communication was important
for the successful completion of the project. The team utilized a suite of collaborative and automation
tools to streamline communication, manage tasks, and enhance overall productivity. Key tools employed
include Jira for project management, Git and Bitbucket for version control, and Google Meet for virtual
collaboration.

Jira - Agile Kanban Project Management

Jira served as the central hub for project management, allowing the team to create and prioritize tasks,
track progress, and manage the overall workflow using Kanban methodologies.

How we used Jira:

 The backlog in Jira has a list of tasks that needs to be done providing a comprehensive overview
of project requirements.

 The Kanban board allowed the team to create, prioritize, and manage tasks visually, providing a
clear snapshot of work in progress, to-do items, and completed tasks.

 Work items/task were represented as cards on the Kanban board, moving through stages such as
"To Do," "In Progress," and "Done," facilitating transparency and accountability.

 The board's flexibility accommodated the Agile approach, allowing the team to adapt and
reprioritize tasks as needed during sprints.

34 | P a g e
Figure 21 - Kanban Board

Figure 22 - Backlog Board

35 | P a g e
Git and Bitbucket - Version Control

Git, combined with Bitbucket, served as the version control system for the project, ensuring collaboration,
code versioning, and effective codebase management.

How we used it:

 Developers utilized Git for version control, enabling them to create branches, merge changes, and
track modifications to the codebase.

 Bitbucket repositories provided a centralized location for hosting code, offering collaborative
features such as pull requests, code reviews, and issue tracking.

 The integration of Git and Bitbucket facilitated concurrent development, minimizing conflicts,
and ensuring code integrity.

Figure 23- Repositories in Bitbucket

36 | P a g e
Google Meet – Virtual Collaboration

Google Meet was the go-to tool for virtual meetings, enabling team members to connect, discuss
progress, and collaborate synchronously.

How we used it:

 Regular meetings were conducted on Google Meet to get updates, fostering real-time
communication and collaboration.

 Regular meetings and discussions were seamlessly facilitated through the platform, promoting
quick issue resolution, planning and knowledge sharing.

 Screen sharing capabilities aided in collaborative problem-solving and code walkthroughs.

The combination of Jira's Kanban board, Git, Bitbucket, and Google Meet played a pivotal role in
fostering efficient collaboration, ensuring version control, and enhancing overall project management.
These tools collectively contributed to the success of building this application by providing a robust
framework for collaborative software development within the Kanban methodology.

37 | P a g e
Testing
Software testing is a method of determining the functionality of a software program. The
procedure determines whether the actual software meets the expected requirements and ensures
that the software is bug-free. The goal of software testing is to uncover defects, flaws, or missing
requirements in comparison to actual requirements. Its primary goal is to assess the specification,
functionality, and performance of a software program or application.
Software testing is the process of verifying and validating whether a software or application is
bug-free, meets technical requirements as guided by its design and development, and meets user
requirements effectively and efficiently by handling all exceptional and boundary cases. The
goal of software testing is not just to uncover flaws in existing software, but also to find ways to
improve the software's efficiency, accuracy, and usefulness.
There are two stages to software testing:
 Verification: It describes the group of actions used to guarantee that a certain function is
implemented by the program accurately. "Are we building the product right?" is what it
implies.
 Validation: It indicates to an alternative set of duties meant to guarantee that the
developed software may be linked back to the needs of the client. "Are we building the
right product?" is what it means.
Importance of Software Testing
 Defects can be identified early: Software testing is essential since it allows for the early
detection and correction of issues prior to the software's release.
 Improves quality of software: Software faults are found via software testing, and when
they are fixed, the software's quality is raised.
 Increased customer satisfaction: Software testing guarantees great performance,
security, and dependability, which reduces expenses, saves time, and increases customer
satisfaction.
 Helps with scalability: Non-functional software testing aids in determining scalability
problems and the potential endpoint of an application's functionality.
 Saves time and money: It will be extremely difficult to track down and fix problems
once the programme has been released since doing so would cost more money and take

38 | P a g e
 more time. As a result, it is preferable to carry out software testing often while
developing software.
Types of Testing
 Functional Testing: Software systems that are validated against functional
requirements are subjected to functional testing. It is carried out to determine whether
or not the application is operating in accordance with the functional requirements of
the programme. Unit, integration, system, smoke, and other testing methods are
examples of different functional testing approaches.
 Non-Functional Testing: Software that tests for non-functional criteria such as
performance, scalability, portability, stress, etc. is known as non-functional testing.
Performance testing, stress testing, usability testing, and other forms of non-
functional testing are among them.
 Maintenance Testing: Updating, shifting and maintaining software to meet client
demands is known as maintenance testing. In order to ensure that recent code changes
haven't negatively impacted other previously functional software components,
regression testing is used.

Different Types of Software Testing Techniques

1. Black Box Testing: Black-box testing is a method of software testing where the tester
does not have access to the program's source code and performs the test at the software
interface without worrying about the program's internal logical structure.
2. White-Box Testing: White box testing is a method of testing where the tester
understands how the product functions inside, has access to the source code, and verifies
that all internal activities are carried out in compliance with the specifications.
3. Grey Box Testing: Testing using the "grey box" approach requires testers to be
somewhat knowledgeable about implementation, but not necessarily specialists.

39 | P a g e
Different Levels of Software Testing
1. Unit Testing: Individual software modules or components are tested at the unit testing
stage of the software testing process. Verifying that every software unit operates as
intended is the goal.
2. Integration Testing: A step in the software testing process called integration testing
involves combining and evaluating different components together as a group. This level
of testing aims to identify errors in the way integrated components interact with one
another.
3. System Testing: A comprehensive, integrated system and software are tested during the
system testing stage of the software testing process. This test's objective is to determine
whether the system complies with the given specifications.
4. Acceptance Testing: A system is examined for acceptability at the acceptance testing
stage of the software testing process. This test's objective is to determine whether the
system satisfies the business requirements and whether it can be delivered.

40 | P a g e
 Mobile Application
Test Case: 01
Executed by: Muhammad Akram Executed Date: 20/12/2023
Task Pre-Conditions Test-Steps Expected Results Actual Execution
results Status
Sign Up User should not been  Enter first name.  User should be shown User were able to Pass
registered already into  Enter last name. with validate message if register into the
the application.  Enter the address. he/she tries to submit any application by

 Enter the email. empty text fields. providing all the

 Enter the Mobile number.  User should be limited to required details, with a
only 10 phone number. unique email address
 Enter a password.
 User should be shown a and accurate mobile
message if the user tries number.
to register with existing
email address.
 User should be shown a
message if the password
and confirm password
doesn’t match.
 User should be able to
successfully register into
1|Page
 the application.
Test data: First name: Jhon, Last name: Doe, Email: public@wild.org.lk, Mobile: 764664949, Password: 123456, Confirm Password:
123456
EVIDENCE

2|Page
 Table 1: Test case mobile user registration

Test Case: 02
Executed by: Mihit Roshan Executed Date: 20/12/2023
Task Pre-Conditions Test-Steps Expected Result Actual Execution
results Status
Login Should login using  Enter the email. System should enter to System entered the Pass
email and  Enter the password. Dashboard. dashboard.
password  Click on login

Test data: Email: mihit@gmail.com, Password: 123456

EVIDENCE

3|Page
Table 2: Test case for mobile user login

4|Page
Test Case: 03
Executed by: Muhammad Akram Executed Date: 20/12/2023
Task Pre-Conditions Test-Steps Expected Result Actual Execution
results Status
View all Should login using  Make a new complaint  Dashboard data should  Dashboard information Pass
user made email and to see if the change dynamically based on changed dynamically
Complaints password. information in the the inputs. based on the inputs.
dashboard changes  User should be able to  User were able to
dynamically. navigate through screens. navigate through
 Click “Make screens.
Complaint” button to
see if the user is able
to navigate to Make
Complaint Screen
 Click “View” text
button to see if the
user is navigated to
Track Complaint
Screen.
 Click hamburger icon
to see if the drawer
appears allowing user
5|Page
 to logout and navigate
through screens
Test data: Complaints: Illegal tree cutting, Animal Kill
EVIDENCE

6|Page
Table 3: Test case for mobile user dashboard

7|Page
Test Case: 04
Executed by: Mihit Roshan Executed Date: 20/12/2023
Task Pre-Conditions Test-Steps Expected Result Actual Execution
results Status
Complaint Enter the details in  Enter the title System should submit the System submitted the Pass
Submission given textfields.  Enter the location. complaint. complaint

 Enter the complaint

 Upload image
 Click on submit

Test data:
EVIDENCE

8|Page
 Table 4: Test case for mobile user make complaint

Test Case: 05
9|Page
Executed by: Mihit Roshan Executed Date: 20/12/2023
Task Pre-Conditions Test-Steps Expected Result Actual Execution
results Status
View the  User should have been  Make changes to  User should be able to see  User was able to see Pass
Complaint logged in. the user should the Complaints list the complaint list.
Status  User should have been have logged in to  User should be able to see  User was able to see
navigated to the the system the status of the the complaint Status
dashboard.  complaint.
 User will Have a
option to view the
complaint list .
 User will have view
button to view the
status
Test data: Mobile number: 784646764
EVIDENCE

10 | P a g e
11 | P a g e
Test Case: 06
Executed by: Muhammad Akram Executed Date: 20/12/2023
Task Pre-Conditions Test-Steps Expected Result Actual Execution
results Status
Change  User should have been  Make changes to  User should be able to see  User was able to see Pass
User logged in. the user details in the already existing the existing registered
Details  User should have been the relevant text details. details.
navigated to Change fields.  User should be able to  User was able to make
user details screen  Check if user is make changes to the changes to the existing
through the Drawer. allowed to enter existing details. details.
 User should be able to more than 10  User should be shown  User was prevented
see all his registered numbers for phone with validate message if from submitting empty
details in the relevant number. he/she tries to submit any text fields.
text fields. empty text fields.  User is limited to 10
 Check if the user
 User should be limited to phone numbers.
is allowed to
only 10 phone number.
submit empty text
form fields.
Test data: Mobile number: 784646764
EVIDENCE

12 | P a g e
Table 5: Test case for mobile user change details

13 | P a g e
 Website
Test Case: 07
Executed by: Mihit Roshan Executed Date: 20/12/2023
Task Pre-Conditions Test-Steps Expected Result Actual Execution
results Status
Login Should login using  Enter the email. System should enter to System entered the Pass
email and  Enter the password. Dashboard. dashboard.
password  Click on login

Test data: Email: admin@wildlife.org, Password: 123456

EVIDENCE

14 | P a g e
15 | P a g e
Table 6 Test case 7

16 | P a g e
Test Case: 08
Executed by: Mihit Roshan Executed Date: 20/12/2023
Task Pre-Conditions Test-Steps Expected Result Actual Execution
results Status
View User  User should have been  Click the Users to  User should be able to  User was be able to Pass
management logged in. view user see the User see the User
 User should have been management management management
navigated to the And edit.  And edit.
dashboard.
 User will Have a
option to view the
Users

Test data: Mobile number: 784646764

EVIDENCE

17 | P a g e
18 | P a g e
Test Case: 09
Executed by: Muhammad Akram Executed Date: 20/12/2023
Task Pre-Conditions Test-Steps Expected Result Actual Execution
results Status
Admin –  Admin should have  Add a new  Complaint should be  Complaint was visible Pass
view all been logged in. complaint visible
complaints  Admin should have
been routed to
Complaints page.

Test data: Mobile number: 784646764

EVIDENCE

19 | P a g e
20 | P a g e
Test Case: 10
Executed by: Muhammad Akram Executed Date: 20/12/2023
Task Pre-Conditions Test-Steps Expected Result Actual Execution
results Status
Register  Admin should have  Add a new user  The new user should be  The user was added Pass
new been logged in. will all the added and have access to and have access to the
account  Admin should have required details. the system system
for staff been routed to User
page

Test data: Mobile number: 784646764

EVIDENCE

21 | P a g e
Test Case: 11
22 | P a g e
Executed by: Muhammad Akram Executed Date: 20/12/2023
Task Pre-Conditions Test-Steps Expected Result Actual Execution
results Status
View and  User should have been  Edit the user  User should be able to  User was able to Pass
Edit logged in. details edit the details of update the details of
Amin/Use him/her. him/her
r profile

Test data: Mobile number: 784646764

EVIDENCE

23 | P a g e
Test Case: 12
Executed by: Muhammad Akram Executed Date: 20/12/2023
Task Pre-Conditions Test-Steps Expected Result Actual Execution
results Status

24 | P a g e
Track  User should have been  Add a new update  The made update on the  Complainant was able Pass
complain logged in. to the complaint to complaint should be to see the update
t  User should have been see if it visible to the complainant
routed to Complaints dynamically
page. shows the user

Test data: Mobile number: 784646764

EVIDENCE

25 | P a g e
Web Application UI

26 | P a g e
27 | P a g e
28 | P a g e
29 | P a g e
30 | P a g e
31 | P a g e
32 | P a g e
33 | P a g e
34 | P a g e
35 | P a g e
36 | P a g e
User acceptance testing

1|Page
2|Page
Critical Review and Analysis:

3|Page
4|Page
5|Page
6|Page
Critical Review and Conclusion

As a summary, we would like to provide a critical review on the built system and its outcomes in relation
to its initial aim and objectives. In recent years, we could see a rapid concern for the preservation of
wildlife and forest, this has prompted the necessity of developing a complaint system to engage the
conservation authorities and public regarding the matter. The aim or the goal of the project was to build a
web and mobile based system to facilitate public to make complaints against environmental crime
incidents through the mobile and web application with relevant information directly to two constitutions,
namely Wildlife conservation and Forest conservation. Administrators of relevant conservation will be
able to view the complaints through the web application and manage the procedural workflow of
investigations triggered through a complaint and report the status of the investigation. Also, a dashboard
is provided to the administrators to view and monitor the triggered complaints and status. The
complainants are also facilitated with a dashboard to view their complaints and its status.

In-order to achieve this aim, as a group we had an organized plan on how to achieve our project
objectives and meet the timelines. We identified the tasks to be done and efficiently assigned the tasks
between group members to get the best from each member within the deadline.

The built system is accessible through various platforms, including web and mobile applications
promoting wider participants and flexibility. When evaluating the success of the built system, the key
criteria is the user friendliness. The system provides a user-friendly interface allowing the user to
efficiently interact with the system. The inclusion of multimedia such as attaching image, enhances the
system functionality and facilitates more comprehensive report. Most importantly, the system has played
a important role in engaging and raising awareness about wildlife and forest conservation. Through status
tracking, users are informed about the outcome of their complaint.

While talking about the several positive aspects, it is not without the challenges. We faced many obstacles
during the project requirement analysis, planning, designing and development phases.

One noticeable concern is meeting the deadline of the project. However, together as a team we were able
to stick together and find solutions to the problem we faced and overcome them. Obstacles didn’t stop the
momentum, each night from the project was taken, we had a group meeting to discuss the progress and
7|Page
identify the areas to improve. These meetings helped us to identify the strength and weaknesses of each
member, so that gave us an insight on which objectives can be fulfilled by which member. Furthermore,
we had a project management system to track each member’s progress where all the tasks with assigned
members were displayed using Kanban board. The tasks status is also shown as to-do, in progress and
completed which provided an organized manner to keep the members on track. Also, each member had
access to a collaboration tool with separated repositories to add their source codes and get the review
from the members.

During the design phase of the project, many diagrams were adopted so that we could get a clear and
proper understanding of the system and how it works. We each member designed a diagram such as class
diagram to understand the classes and objects of the system, ER diagram to understand data of the system,
use case diagram to understand how user each users interact with the system, sequence diagram to
understand the interactions of the system and activity diagram to understand the workflow of the activities
and actions of the system.

Once the design phase was done, with the proper understanding the development phase began. We built a
web and mobile application. Web application was built using angular for front-end and PHP for backend.
Mobile application was built using flutter framework which used dart programming language for frontend
and backend. Laravel API was used to interact and exchange data from MySQL database to throughout
the system.

As the final phase of the software development lifecycle, we started on testing the build application
manually and automatically. Test cases were designed to test the basic functionalities of the system as per
the requirements. At the end of the testing phase, we made sure that the built application works as
intended and meets the requirements and standards.

In conclusion, the wildlife and forest conservation complaint system has proven to be a valuable resource
in preventing damages done to the environment and promoting community involvement. As we move
forward, the built system highlights the strategies and collaboration community and the authorities to
create a sensitive ecosystem.

8|Page
References
Anon., n.d. Atlassian. [Online]
Available at: https://www.atlassian.com/agile
[Accessed 11 12 2023].
GeeksforGeeks, 2018. GeeksforGeeks. [Online]
Available at: https://www.geeksforgeeks.org/software-testing-basics/

9|Page
Appendices

Group Members

Student ID Student Name

E030078 R. A. Ahnaf Ahamed
E190705 Fazloon Farook
E190103 E Diyan Hadgie
E181491 N.M. Mihit Roshan
E032388 Muhammad Akram Sheriff

All team members contributed equally.

Links to the bitbucket repositories.

Front-End - https://bitbucket.org/tyrantx3/wilderconnect.client/src/master/
Mobile - https://bitbucket.org/tyrantx3/wilderconnect.mobile/src/master/
Backend - https://bitbucket.org/tyrantx3/wilderconnect.api/src/main/

10 | P a g e