SOFTWARE ENGINEERING PROJECT REPORT

Student

Course

Date
 Part I – PROJECT

1. Introduction

1.1 Background

The growing integration between environmental conservation and technology has made it

possible to improve digital participation in sustainable programs. However, the majority of

conservation efforts are fragmented and lack a successful digital infrastructure to guarantee

partnership and funding. The Komodo Hub project fills this gap by proposing an information

platform that is supposed to connect the environmental organizations, donors and volunteers

using an app within the cloud. The portal can monitor the projects in real time basis, community

facilitation and provide transparent management of donations.

In the case of Beck et al. (2017), the application of agile software plans, such as Scrum, may be a

flexible and iterative process of carrying out intricate projects developing through teamwork and

step-by-step advancements. With a further extension of Scrum to Komodo Hub, the team will be

agile and, at the same time, respond to the changing requirements of the users, being fully

focused on the performance of conservation programs.

1.2 Problem Statement

Traditional conservation initiatives are more inclined to use individual-level communication,

fragmented data format, and insignificant instruments of engagement among people. It leads to

coordination efficiencies, duplication of data, and slowness, as well as the loss of coordination

(Pressman and Maxim, 2020). Lack of integrated software tools also affects accountability and

transparency, especially in the aspect of donations and project reports monitoring. Therefore,

there is a need to have centralized platform which is built-in and easy to navigate to make the
most out of the smoother operations of the community-based animal conservation and to create a

better interaction of the stakeholders.

1.3 Project Objectives

Within the context of Komodo Hub project, the most important objective is the development of a

web-enabled, cloud-based platform, which, in its turn, would facilitate work with conservation

participants. The specific objectives are:

1. To offer a spiked mechanism linking volunteers, donors, as well as organizations.

2. To facilitate real time project tracking, events and donation transparency.

3. To make the systems scaled and available in a responsive design.

4. To ensure the upholding of ethical and safe data management by ensuring privacy of the

users is taken seriously.

These objectives can be considered in line with the idea of Sommerville (2016) that successful

software engineering is a combination of technical excellence, social and ethical responsibility.

1.4 Scope and Limitations

The scope of the project is development, design and testing of inspirational web-based

conservation management system. The key requirements in these features will be user

registration, project lists, donation tracking, and volunteer management. At this moment, there is

no scope of mobile app integration and third-party payment gateway APIs. Incremental growth is

made possible so as to permit adapting agilely and extend in the future (Schwaber and

Sutherland, 2020). The first one will be a web interface that is cloud-based, and, possibly, it will

be extended further and will also cover mobile applications and payment network issues.
1.5 Methodology

Scrum was implemented to control the software development scope since it is an iterative project

that focuses on collaborative efforts (Sutherland and Schwaber, 2017). Five sprints, one week,

were used in the project to come up with incremental and functional aspects. Constant feedback

and adaptation to the requirements of stakeholders was provided by scrum ceremonies, including

sprint planning, daily stand-ups, sprint reviews, and retrospectives, which is consistent with the

agile principles of transparency, inspection, and adaptation (Beck et al., 2017).

1.6 Report Structure

This report is structured around the three major components defined in the assignment brief:

 Part I – Project, describing project management, Scrum practices, and governance.

 Part II – Process, detailing requirement analysis, design, development, and testing

activities.

 Part III – Product, focusing on the final system, evaluation, and reflection on learning

outcomes.

2. Scrum Framework and Management

2.1 Overview of Scrum Implementation

The primary agile model that has been introduced in order to enable agile delivery and flexibility

is Scrum. The project involved an eight-week development cycle that was divided into five main

sprints and after the complete development cycle, the project would be finished by integrating

and documenting it (Schwaber and Sutherland, 2020). Every sprint was supposed to create an

incremental functionality of the Komodo Hub system. Sprint reviews and retrospectives were
made to evaluate the results and the continual feedback loops were made to adapt to emerging

needs.

2.2 Composition and Roles

I did this project, and I described the roles that I was supposed to be doing on a weekly basis

which included Product Owner, Scrum Master, and Developer (System Architect, Database

Engineer, Web Developer or Cloud Engineer). This weekly switch of roles gave equal

opportunity of learning and building skills on the entire system. As a Product Owner, I managed

product backlog and priorities of requirements. I was the head of the meeting and the clearance

of impediments as the Scrum Master and the writer, testing, and documentation creator as the

Developer. According to Hoda et al. (2013), rotation of roles in an agile team enhances team

ownership and functional learning within the team.

2.3 Scrum Artifacts

I developed and maintained the following artifacts in order to have effective process control:

 Product Backlog: Prioritized list of features, user stories, and enhancements.

 Sprint Backlog: Specific subset of tasks targeted for completion in each sprint.

 Burndown Chart: Monitored progress and visualized task completion over time.

 Increment: A working and tested product version produced after each sprint.

They served the purpose of transparency and gave progress indicators that could be measured,

which is in line with the principles of agile documentation (Cohn, 2010).

2.4 Scrum Events

  Sprint Planning: Defined sprint objectives, selected backlog items, and estimated

workload.

 Daily Stand-Ups: 15-minute sessions for reviewing progress and blockers.

 Sprint Review: Presented completed increments and collected feedback.

 Sprint Retrospective: Analyzed each phase performance, identifying strengths and

improvement areas.

2.5 Tools and Collaboration Platforms

In this project, I employed different tools in its collaboration and consistencies which varied

across sprints:

 Jira – for sprint and backlog management.

 GitHub – for source control and version management.

 Slack – for effective communication.

 Miro and Figma – for collaborative UI/UX design.

.2.6 Collaboration and Communication Management

I also made sure that the project was checked on a weekly basis through the meetings to discuss

the progress and respond to the challenges. These meetings were handled on Slack and the sprint

backlog was handled using Jira boards. This hybrid system was capable of synchronous and

asynchronous collaboration and this increased team coordination. Moe et al. (2010) point out that

communication is very important in agile project success. The weekly reviews organized were
useful in making this project successful as such open communication channel allowed the

collaboration process to go well and achieve more cohesion in the team.

3. Project Planning and Management Artifacts.

3.1 Project Schedule

The Komodo Hub project could be divided into five sprints that took one week each and an

integration and reporting week. The project milestones, such as gathering requirements, system

design, programming, testing and documentation, were drawn on a Gantt chart. Jira dashboards

made sure that everything was accomplished within the scheduled time and in an open manner

(Cohn, 2010).

3.2 Risk Management Plan

Risk Impact Likelihood Mitigation Strategy

Delayed task completion High Medium Regular progress tracking via Jira;

reallocation of tasks during sprint

 review

Version control conflicts Medium Medium Strict Git branching policy and pull

request reviews

Miscommunication during High Medium Handover documentation and shared

role rotation meeting notes

Data loss or corruption High Low Cloud-based versioning and regular

backups

Scope creep due to added Medium Medium Product Owner enforces backlog

features prioritization
3.3 Configuration and Version Control

The management of the documentation and the source code was provided with GitHub. To fulfill

the different development and testing environments, a branching strategy was adopted to reduce

the chances of conflict, and a seamless integration was facilitated. At the conclusion of every

sprint, version tags were implemented to monitor the work done and to impose a distinct

versioning of the product, reducing the likelihood of a conflict arising in the course of merging

(Loeliger and McCullough, 2012).

3.4 Resource Allocation

The way the resources were distributed was to make sure that very little investment was done

and as much benefit was received. [Link] was used in frontend development, whereas [Link]

and MySQL were used as the backend. AWS Free Tier was utilized to host cloud testing

environments in order to cut down on the cost that was not necessary. The allocation of resources

was also periodically revised to meet the sprint targets (Pressman and Maxim, 2020).

3.5 Ethical, Legal, and Professional Considerations.

The Code of Conduct of the British Computer Society (BCS, 2021) informed the ethical

approach chosen and focused on the privacy of the users and responsible usage of the open-

source technologies. Test data were made anonymous to avoid privacy breaches and licenses

were properly attributed. The project was safe to the WCAG 2.1 requirements to make it

accessible (W3C, 2018).

3.6 Project Governance

The project had a flexible governance which could be changed at any point so that the success of

the project can be achieved. The decisions made during the initial stages were extended all

through the project which ensured transparency and accountability in each stage. The strategy

encouraged continuous improvement that is crucial in successful agile governance (Moe et al.,

2010).
 Part II – PROCESS

4. Requirements Analysis

4.1 Requirements Elicitation

The initiative started by conducting requirements elicitation via simulated interviews with

stakeholders, by conducting literature reviews and analyzing the analysis of the online

conservation platform. User stories and by conducting the use case modelling to document user

expectations. Elicitation sought to make sure system requirements met functional and non-

functional needs (Robertson and Robertson, 2013). Stakeholders included volunteer

organizations, volunteers themselves, donors, and system administrators. Each contributed

unique feedback on the system's necessary aspects, including project management, fundraising

tracking, and reporting.

Elicitation process took place following Sommerville's (2016) advice that it’s effective to get

requirements through iterative validation and feedback by stakeholders. All the user stories by

the end were put together by the Product Owner in the Product Backlog that changed during

refinements in the sprint.

4.2 Functional Requirements

Functional requirements describe system behaviors and interactions that deliver specific value to

users (Pressman and Maxim, 2020). For Komodo Hub, the primary functional requirements

include:

ID Functional Requirement Description

FR1 User Registration and Users can register, log in, and manage their profiles.
 Authentication

FR2 Project Management Conservation organizations can create, edit, and

monitor projects.

FR3 Donation Tracking Donors can view financial contributions and monitor

usage reports.

FR4 Volunteer Coordination Volunteers can sign up for tasks and events.

FR5 Communication Tools Messaging and notifications between users and

project managers.

FR6 Admin Dashboard Provides metrics on active users, donations, and

project outcomes.

They were written down afterward by following the format:

“As a [role], I want [feature] so that [benefit].”

For example: “As a donor, I'd like to be able to track my donations to be able to trace the

expenditure of the funds.”

4.3 Non-Functional Requirements

Non-functional requirements secure the system's quality, reliability, and maintainability.

Complied by Sommerville (2016), these parameters are key to determining user satisfaction and

system performance. The primary non-functional requirements are:

 Performance: The system should load within three seconds for 95% of users.

 Scalability: Support up to 1,000 concurrent users.

  Security: Encrypt all data transmissions and enforce password policies.

 Usability: Provide an intuitive user interface with clear navigation.

 Availability: Ensure 99% uptime through cloud deployment.

 Maintainability: Use modular code to allow future updates.

These standards align with ISO/IEC 25010 software quality models (ISO, 2011), to ensure there

is robust performance of the platform in both its function and user experience.

4.4 Requirements Validation

I conducted validation via walk-throughs and sprint review where the user stories are passed to

check alignment with the expectations of the stakeholders. Requirement traceability matrix

(RTM) also linked user stories and system characteristics to test cases. All requirements hence

implemented and tested during the test (Cohn, 2010).

Requirement Traceability Matrix (RTM)

Requirement User Functional Test Test Description Test

ID Story/Feature Requirement Case Status

ID

FR1 As a user, I want User TC1 Test user Passed

to register and log Registration and registration,

in so that I can Authentication login, and profile

access my account. management.

FR2 As a conservation Project TC2 Test project In

 organization, I Management creation, editing, Progress

want to create, and monitoring

edit, and monitor functionality.

projects.

FR3 As a donor, I want Donation TC3 Test donation Passed

to track my Tracking tracking system

donations to see and report

how my funds are generation.

being used.

FR4 As a volunteer, I Volunteer TC4 Test volunteer Passed

want to sign up for Coordination registration, event

tasks and events so sign-up, and task

that I can tracking.

contribute to

conservation

efforts.

FR5 As a user, I want Communication TC5 Test messaging, Passed

to communicate Tools notifications, and

with project communication

managers through channels.

messaging and

notifications.
FR6 As an Admin TC6 Test the admin In

administrator, I Dashboard dashboard, data Progress

want to view reporting, and

metrics on active metrics

users, donations, functionality.

and project

outcomes.

NFR1 The system should Performance TC7 Test system Pending

load within three performance

seconds for 95% under load.

of users.

NFR2 The platform Scalability TC8 Test the Pending

should support up platform’s

to 1,000 scalability under

concurrent users. concurrent user

load.

NFR3 The platform Security TC9 Test encryption Passed

should encrypt all and password

data transmissions policies during

and enforce registration and

password policies. login.

NFR4 The user interface Usability TC10 Test UI for ease Passed
 should be intuitive of navigation and

and easy to accessibility

navigate. compliance.

NFR5 The system should Availability TC11 Test system Pending

ensure 99% uptime uptime and

through cloud reliability under

deployment. load.

NFR6 The system’s code Maintainability TC12 Test codebase In

should be modular, modularity, ease Progress

allowing future of adding features

updates. and updates.

All the sprint requirements got refined during the backlog grooming meetings — by principles of

agile best favoring the steady input (Beck et al., 2017).

5. System Design

5.1 System Architecture

I chose a three-level architecture including presentation layer, application logic layer, and

database layer as seen below:

Such architecture guarantees the separation of concern, growth scalability, and maintenance

simplicity (Pressman and Maxim, 2020).

 Frontend: Developed with [Link] to provide a dynamic, responsive interface.

 Backend: Built using [Link] and [Link], facilitating RESTful API communication.

 Database: Implemented with MySQL, chosen for its reliability and ease of integration.

 Hosting: The system was deployed on AWS Cloud to enable scalability and continuous

access.

5.2 Context Diagram

I created a context diagram to express the system's interactions with the outside world like users,

donors, and administrators.

5.3 Use Case Diagram

Use case diagram has represented key workings between the Komodo Hub system. The diagram

was responsible to:

 Register User

 Manage Project

 Track Donation

 Volunteer for Event

 View Reports
 Register Manage Track Volunteer View
User Project Donation for Event Reports

Use cases provided an organized pictorial demonstration of system action and user engagement

and met the UML 2.0 requirements (Booch, Rumbaugh, and Jacobson, 2005).

5.4 Database and Class Design

A relational database was created by an Entity-Relationship Diagram (ERD). Tables included:

Table Attributes Description / Notes

Users UserID (PK), Name, Email, Role Stores information for all users

including donors and volunteers.

Projects ProjectID (PK), Title, Description, Tracks projects created by

Status, OrganizationID (FK) organizations.

Donations DonationID (PK), Amount, DonorID Records financial contributions from

(FK), ProjectID (FK) donors to projects.

Volunteers VolunteerID (PK), UserID (FK), Tracks volunteer assignments and

ProjectID (FK), TaskStatus progress.

Note: PK = Primary Key, FK = Foreign Key

5.5 User Interface Design

The User Interface design included the following core design choices:
  Simplified navigation menus and color-coded dashboards.

 Card-based layouts for project listings.

 Clear call-to-action buttons for donations and volunteer registration.

User feedback during sprint reviews guided iterative UI refinements, improving accessibility and

responsiveness across devices.

6. Development and Testing Process

6.1 Development Strategy

The develop strategies are strategized around 5 working features/sprints:

Sprint 1: Clarification of requirements and database

Spring 2: User registration and authentication module.

Sprint 3: Modules of project management and

donation

Sprint 4: Coordination of Volunteers and

Implementation

Sprint 5: Integrating and testing

6.2 Coding Standards and Version Control

I conducted coding normally using ESLint. This ensured that they are validated as per to the

JavaScript syntax codes and Prettier to format the codes. Afterwards, I reviewed the codes to

avoid errors and ensure there is accountability in determining an agile programming discipline.

6.3 Testing Approach

The implementation of a multi-level testing strategy was as follows:

  Unit Testing: Each module was independently tested using Jest.

 Integration Testing: Ensured proper communication between modules.

 System Testing: Verified that the entire system met functional requirements.

 User Acceptance Testing (UAT): Stakeholders validated the system’s usability and

accuracy.

The result of test plans was documented in the test case matrix.

6.4 Testing Artifacts

Key artifacts produced include:

 Test Plan Document – outlining scope, objectives, and test environment.

 Test Cases – defined inputs, expected outputs, and results.

 Defect Report – tracked identified bugs and resolutions.

 Test Summary Report – documented final test coverage and outcomes.

6.5 Quality Assurance

 Code reviews for maintainability and readability.

 Continuous integration checks to detect early build failures.

 Manual and automated regression testing after each sprint.

 Verification against non-functional requirements such as performance and accessibility.

This iterative QA did satisfy the quality and user expectations and the technological standards

(Pressman and Maxim, 2020).

6.6 Process Reflection

Iterative Scrum process functioned well to manage scope and to rank-feature. With integration

delay and time limitation, however, issues arose. Retrospectives after each sprint provided

adaptive planning and thus better forecasting of the sprint and better team coordination —

consistent with agile values to continually improve (Beck et al., 2017).

 Part III – PRODUCT

7. System Implementation and Features

7.1 Overview of Final System

In the Komodo Hub system, user stratification is given consideration whereby school users

(teachers, principals, students) are separated and community users (donors, volunteers). Teachers

and administrators, as well as any other school user, can access the detailed project data,

volunteer management, and various student contributions, which means they can track the

progress and allocate resources successfully. Conversely, the community users, which include the

volunteers and the donors, can only access non sensitive data, which includes the project updates

and donation progress. This distinction will help in ensuring that sensitive data, especially those

pertaining to students, is not exposed at the expense of enhancing transparency and engagement

to the wider community. These boundaries are imposed by role-based access control (RBAC),

which ensures the protection of the data as well as motivates people to engage in conservation

activities and be responsible.

7.2 Implemented System Architecture

In Komodo Hub, I created a three-layer architecture consisting of the presentation, application,

and data layers, with security implemented at each layer to safeguard user information. In the

presentation layer, I implemented that the access is through role-based access control (RBAC) to

give the teachers and administrators rights to view sensitive student information and deny the

community users' view to sensitive, aggregate levels. The application layer is built with [Link]

and [Link], where I implemented the encryption and data validation to secure the
information. In the data layer, I established the MySQL with foreign constraint to give both the

data integrity and the limited view to sensitive information.

7.3 Key Functional Modules

The system has six main modules which are developed and improved by successive sprints.

a) User Authentication and Role-Based Management

Users can sign up, log in, and view role-specific dashboards. JSON Web Tokens (JWT) were

used to implement session management and secure API access. Role-based access control

(RBAC) is responsible to ensure that project approval and other administrative functions are

available to only the authorized user. This use also follows secure authentication

recommendations provided by OWASP (2021) and respects data integrity and confidentiality.

Another significant aspect of the Komodo Hub system is user role management whereby various

types of users are granted access accordingly as to the school users and the community members.

Role-Based Access Control (RBAC) is deployed in order to guarantee that users with access to

the given platform can only view certain platform features.

School Users (administrators, staff) can access all the functions of the system, such as project

management, the coordination of volunteers and the monitoring of donations in detail. They are

also able to control user accounts and monitor the overall system performance.

Access is limited to Community Users (volunteers and donors) who can participate in the system

as they can view project updates, register events, donate and monitor their individual

contributions. Yet, these users lack administrative privileges and might not have access to

sensitive information and system configuration.

The system provides least privilege that makes users receive only what is needed to perform their

tasks and protect sensitive information. Also, roles of the users are associated with data access,

whereby school users will be permitted to view detailed user data, whereas the members of the

community can only view non-sensitive, aggregate data.

b) Project Management

This module enables the generation and management of projects by conservation organizations.

Each project record has descriptions, targets, fundraising targets, and related media. Tagging is

also accommodated by data structure by species and by geographic area to facilitate improved

sorting.

CRUD operations were also performed by using the application of the RESTful interfaces with

the goal to ensure data consistency and transactional consistency (Pressman and Maxim, 2020).

c) Donation Tracking

Donation module provides an on-spot visualization of the donations by the mean of dynamic

charts. Administrators get to see the payment history and the donors get to see the total raised by

each project. Although the integration of the payment gateway is not realized but can be

implemented by the APIs such us PayPal SDK or Stripe API at any future stage.

1. Komodo Hub: This offers an openness of information tracking and display of

community members contribution which ensures that financial as well as volunteer-

associated activities are seen by the relevant parties, without invading the privacy.

2. Donation Transparency: Community members (donors) can see their contributions and

receive aggregated information on the number of donations made by different community

 members on different projects. Nevertheless, the system will provide that individual

donor identities are concealed and they are not visible to other users.

3. Volunteer Tracking: Volunteers have an opportunity to monitor their personal tasks,

event registration, and completion. Nonetheless, they are not able to access the personal

data of other volunteers. Only the authorized persons (e.g., project managers) will be able

to see the entire list of volunteers in every given project and allocate tasks.

This openness will make the community members feel knowledgeable and involved in the effects

of their efforts, but also keep the sensitive user data well under control. The system monitors the

contributions and gives feedback to the participants which encourages them to work more and

remain accountable.

d) Volunteer Coordination

Volunteers can volunteer to volunteer to individual conservation events or campaigns. Provide

automated tracking of volunteers by project by the system and feedback upon completion of the

task. Calendaring uses the simple calendar view and distribution of the task is controlled by the

project manager role. This feature aligns with the objective of encouraging direct community

participation in conservation work (Sutherland and Schwaber, 2020).

e) Reporting and Analytics Dashboard

Administrators can see the dashboards of the running projects, received donations, and website

activity. Controls on data visualization were established by the employment of [Link] to

produce data visualization graphical reports. The graphical interface accommodates the aspect of

decision-making and portfolio tracking, which is critical to manage the conservation programs

effectively and efficiently (Highsmith, 2009).

f) Communication and Notification System

A simplicity messaging system is also implemented to facilitate contact between users and

project organizers. Email reminders are triggered on seminal events, i.e. approval on projects or

volunteer sign-ups. This element increases interactivity and provides real-time contact and is

aligned with agile user experience principles (Nielsen, 2012).

7.4 User Interface (UI) and Experience (UX)

While designing the Komodo Hub UI, I adhered to ISO 9241-210 guidelines, which include an

orientation for symbols and error-proof design. The interface is designed to prevent users from

committing errors, so the interaction with the system is smooth and intuitive. In the event that

errors are committed, I included functionality for undo and proper instructions to help the user

easily fix errors. The design not only facilitates user satisfaction but also adheres to ISO 9241-

210 requirements, making the system both accessible and user-friendly and encouraging a

smooth, error-free interaction.

7.5 Security and Data Protection

In order to achieve end-to-end security, Komodo Hub utilizes strong encryption and access

controls at all system layers. Any sensitive data, that is, student data is encrypted with standard

industry algorithms, for example, bcrypt to prevent it from being seen or taken without the due

authority. Furthermore, audit logs are also kept for the purposes of keeping records of individuals

accessing sensitive data, to promote accountability (Cohn, 2010). Data protection-wise, the

school library is insulated from other public areas of the platform, with the view that the access is

restricted to authorized users, for example, teachers and administrators, to always keep the

student data privacy intact (Sommerville, 2016).

7.5.1 Functionality for Student Data Privacy

Personalizing student accounts: Create features in which students are able to create avatars,

choose color schemes, or edit profiles. This can be done through adding fields within the user

profile database as well as constructing front-end options for user customization.

Content filtering: Install a content filter that checks for objectionable content in uploads to

conform to platform guidelines. Employ software such as machine learning content filtering or

keyword filtering tools.

School-specific access codes: Create a program that creates personalized access codes for school

users. The codes are then to be used to limit students' access to student records so that only

authorized individuals can access sensitive records.

Anonymizing student data: Mask data in such a way that sensitive details such as names and

contacts are not seen in publicly exposed sections of the site. It might come up with anonymized

data such as a randomly generated number or abbreviations of names.

7.5.2 User Differentiation of School and Community Features

User contributions from community: Create pages where community users can contribute blog

posts, comments, or posts. This might be seen on a user profile page or on a "contributions"

page.

School user access control: Create a system that would enable school user access to certain

areas of the site (e.g., the school library) while disabling access to confidential content like

observation report writings or learner submissions. This would entail role-based access control

(RBAC) as well as guaranteeing that sensitive information is not revealed to unauthorized users.
7.5.3 Education and Interactive Functions Management

Course content management: Install a system that can be used for teachers to choose and tailor

learning content such as games as well as other resources. This can be through incorporating

content management systems (CMS) or enabling teachers to upload materials themselves and

manage them.

Student activity tracking: Incorporate functionality that would allow teachers to record student

as well as assignment activities and achievements. This would entail fashioning a task tracking

module through which teachers can develop assignments as well as monitor assignments tracking

revisions.

Teacher-student communication: Develop communication tools like messaging, email

programs, or task notes to ensure direct communication is undertaken across teachers and

students. This will help open up feedback and keep communication open for good educational

results.

7.5.4. Scrum Practice and Item Management Facts

Daily Stop Log: Have a template for each sprint that team members enter what was

accomplished, blockers that occurred, and resolution. This can be written in a common document

or in-line within Jira.

Sprint Review Report: The sprint review report should be prepared after every sprint with

details of the finished work, difficulties experienced, and recommendations for subsequent

stages. It is used in finding the improvement regions.

Project Management Artifacts: Make sure that detailed records of risk management as well as

resources are on board. There should be a risk response plan that is updated regularly in every

sprint, and resources are monitored over the course of a project.

7.5.1 Data Privacy and Data Management

To safeguard student privacy, Komodo Hub applies data anonymization and masking to sensitive

information. Personal identifiable information (PII) like student names and contact information is

pseudonymized when it is presented outside the secure areas of the program, so that only the

authorized users are able to view the complete information (Robertson and Robertson, 2013).

Like, the identities of the donors and the volunteers are not disclosed, but the system displays

only the nonsensitive information like the total donations and the progress toward the projects.

The system is thus able to preserve the student confidentiality and the privacy of the date, yet

remain transparent and accessible to the whole community, for it to be ISO/IEC 27001 compliant

(ISO, 2013).

7.6 Deployment

The system is running on AWS EC2 instances, with a scalable and dependable infrastructure,

offering 99% uptime for worldwide accessibility. The cloud deployment enables the system to

support growing traffic and scale up or down accordingly (Humble and Farley, 2010). CI/CD

pipelines with GitHub Actions were introduced to facilitate the development process. The

automation enables quick feedback loops, detects integration problems early, and reduces risk

through the auto-deployment of the code following successful test runs. The practice is

compliant with DevOps best practices, facilitating efficient and dependable updates with the

system performing with performance and security intact (Beck et al., 2017).
8. Evaluation and Reflection

8.1 Evaluation of System Objectives

The Komodo Hub system achieved its major goals, especially user stratification. The privacy of

student data was well handled through role-based access control (RBAC), where only accredited

users, for example, teachers and administrators, were able to gain access to sensitive student

information. The community users (volunteers and donors) were, however, restricted to the view

of non-sensitive information such as project reports and progress toward donations. Through this

methodology, the website remained open and at the same time guarded the sensitive information.

The architecture and the security attributes of the system struck a balance, where privacy for the

data and involvement for the stakeholders were ensured.

8.2 Functional and Non-Functional Assessment

With respect to performance testing, the system for the Komodo Hub system satisfied ISO/IEC

25010 quality assurance standards. Through testing, penetration testing ensured that all sensitive

information, especially student data, remained encrypted securely with bcrypt, thus not

accessible to anyone without proper authority. Such testing also consisted of SQL injection and

cross-site scripting (XSS) checks for vulnerabilities, to confirm that the system protection for the

data worked well. The site survived these security tests, demonstrating protection to common

cyber-attacks with the maintenance of performance thresholds such as a 2.3-second response

time under load.

8.3 User Comments

User feedback played a crucial role in enhancing accessibility with both the school and the

community user groups. The administrators and instructors gave important feedback regarding
refinements of the UI, calling specifically for easier navigation and more effective presentation

of data to support the management of projects and volunteering. The users from the broader

community, comprising volunteers and donors, called for easier tracking of donations and event

registrations. Data privacy feedback also resulted from this, with student records being encrypted

to remain secure yet not retaining any identifiable information from donors for the public-facing

areas. The continuous process ensured that the site remained inaccessible yet highly secure for

each user.

8.4 Performance Testing

The Komodo Hub system also went through stress testing to simulate extreme user traffic,

highlighting potential points of bottle neck, especially with the database layer. With growing

community users, it became evident that load balancing and scalability will be important for

keeping the system responsive. Future releases will remedy these issues with the addition of

Redis caching to minimize database load and quicken the turn-around time. NGINX load

balancing will also be integrated to divert user traffic effectively, keeping the system responsive

under heavy traffic. With these enhancements, the platform will be able to support 1,000+ users

at a time without losing speed, handling the increasing demand with growing community

engagement.

8.6 Reflection on Scrum Effectiveness

The iterative Scrum process was the foundation for ongoing Komodo Hub system improvements.

The team, through frequent retrospectives, fine-tuned essential functionality, including the Role-

Based Access Control system and privacy for sensitive data. The opportunity to fix problems that

arose came with each sprint, especially relating to securing sensitive data and proper access. The
frequent feedback loop incorporated the opportunity for the team to continually improve security

functionality, enabling student information to be kept safe and that users of the community

proper levels of access were provided. The Scrum process lent itself to flexibility, enabling the

team to respond to stakeholder feedback to ensure that the system serviced functional needs, as

well as security needs.

9. Future Work

Future enhancements to Komodo Hub include increasing the functionality of the platform and

increasing the power of the data protection capabilities. Adding payment gateways, for example,

PayPal and Stripe, will help process donations in real time, increasing the convenience for the

donors. Increasing role-based masking for data will also help to tightly control sensitive student

information, keeping it private. Increasing the controls for accessing the data will also be a point

of focus to help meet international levels for the protection for the data, for example, the GDPR,

to increase the privacy controls. These upgrades will keep the platform functional, scalable, and

able to support growing demand from users, all the while keeping sensitive information secure.
 References

Beck, K., Beedle, M., Van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., ... and

Thomas, D. (2017). Manifesto for Agile Software Development. Agile Alliance.

Booch, G., Rumbaugh, J., and Jacobson, I. (2005). The Unified Modeling Language User Guide

(2nd ed.). Addison-Wesley.

British Computer Society (BCS). (2021). Code of Conduct. BCS.

Cohn, M. (2010). Succeeding with Agile: Software Development Using Scrum. Addison-Wesley.

Fowler, M. (2010). Patterns of Enterprise Application Architecture. Addison-Wesley.

Highsmith, J. (2009). Agile Project Management: Creating Innovative Products. Addison-

Wesley.

Hoda, R., Noble, J., and Marshall, S. (2013). Self-organizing roles on agile software

development teams. IEEE Transactions on Software Engineering, 39(3), 422–444.

Humble, J., and Farley, D. (2010). Continuous Delivery: Reliable Software Releases through

Build, Test, and Deployment Automation. Addison-Wesley.

ISO. (2011). ISO/IEC 25010: Systems and Software Engineering—System and Software Quality

Models. ISO.

ISO. (2013). ISO/IEC 27001: Information Security Management Systems. ISO.

Loeliger, J., and McCullough, M. (2012). Version Control with Git (2nd ed.). O’Reilly Media.
Moe, N. B., Dingsøyr, T., and Dybå, T. (2010). A teamwork model for understanding an agile

team: A case study of a Scrum project. Information and Software Technology, 52(5), 480–

491.

Nielsen, J. (2012). Usability Engineering. Morgan Kaufmann.

OWASP. (2021). OWASP Top 10: The Ten Most Critical Web Application Security Risks.

OWASP Foundation.

Pressman, R. S., and Maxim, B. R. (2020). Software Engineering: A Practitioner’s Approach

(9th ed.). McGraw-Hill.

Robertson, S., and Robertson, J. (2013). Mastering the Requirements Process (3rd ed.). Addison-

Wesley.

Schwaber, K., and Sutherland, J. (2020). The Scrum Guide: The Definitive Guide to Scrum.

[Link].

Sommerville, I. (2016). Software Engineering (10th ed.). Pearson Education.

Sutherland, J., and Schwaber, K. (2017). The Scrum Guide: The Definitive Guide to Scrum.

[Link].

W3C. (2018). Web Content Accessibility Guidelines (WCAG) 2.1. World Wide Web Consortium.