csc436_g14_edulearn_report.md

SOFTWARE DEVELOPMENT PROJECT REPORT

CSC 436 Group Project

EduLearn: A Learning Management System for Nigerian Universities

---

Group Number: 14

Student Name	Matriculation Number
Adebowale Hassanat Adebisi	230805521
Opadeji Abdullah Ololade	210805095
Oluwaleye Akinloluwa David	210805089
Okewunmi Adesola Arebecca	210805040
Odutona Onaolapo Alex	210805157
Oselukwue Charles Nonso	210805157
Akinbayo Okanmoyisioluwa Clinton	210805025

Department:
Computer Science

University:
University of Lagos

Supervisor:
Dr. Rukayat Koleoso

Date of Submission:
March 2026

---

ABSTRACT

This report presents the comprehensive software development documentation for EduLearn, a Learning Management System (LMS) designed to address the growing need for accessible, user-friendly online education platforms in Nigerian universities. The project was conceived to bridge the technological gap in higher education by providing a robust platform that enables students to access course materials, submit assignments, and track their academic progress, while empowering lecturers to manage content, grade assignments, and monitor student engagement effectively.

The development process followed the Agile methodology, specifically the Scrum framework, allowing for iterative development and continuous stakeholder feedback. The system was built using modern web technologies including Laravel for the backend API, React.js for the frontend interface, and MySQL for database management. The project was executed within a three-month timeline (January 1 to March 31) with a budget of ₦5 million and a team comprising five developers, one project manager, and one UI/UX designer.

Key features implemented include secure user authentication with role-based access control, comprehensive course management, assignment submission and grading workflows, discussion forums for collaborative learning, and real-time notification systems. The report documents the complete software development lifecycle, from initial requirements gathering and system analysis through design, implementation, testing, and deployment.

Risk management strategies were employed to address challenges including potential API integration delays, scope creep, developer unavailability, and budget constraints. The project successfully delivered a functional LMS that meets the core requirements within the specified constraints, demonstrating effective project management practices and sound software engineering principles.

Keywords: Learning Management System, Agile Development, Software Engineering, Educational Technology, Web Application Development

---

TABLE OF CONTENTS

1. CHAPTER ONE: INTRODUCTION

   • 1.1 Background of the Study
   • 1.2 Problem Statement
   • 1.3 Aim and Objectives
   • 1.4 Scope of the Project
   • 1.5 Significance of the Project
   • 1.6 Project Constraints

2. CHAPTER TWO: LITERATURE REVIEW

   • 2.1 Overview of Learning Management Systems
   • 2.2 Existing LMS Platforms
   • 2.3 Challenges of LMS in Developing Countries

3. CHAPTER THREE: SYSTEM ANALYSIS

   • 3.1 Stakeholder Analysis
   • 3.2 Functional Requirements
   • 3.3 Non-Functional Requirements
   • 3.4 Use Case Descriptions
   • 3.5 Risk Analysis and Mitigation Strategies

4. CHAPTER FOUR: SYSTEM DESIGN

   • 4.1 System Architecture
   • 4.2 Technology Stack Justification
   • 4.3 Database Design
   • 4.4 User Interface Design Overview

5. CHAPTER FIVE: IMPLEMENTATION

   • 5.1 Agile Methodology Explanation
   • 5.2 Sprint Planning
   • 5.3 Development Tools and Environment
   • 5.4 Version Control Strategy

6. CHAPTER SIX: TESTING AND DEPLOYMENT

   • 6.1 Types of Testing Conducted
   • 6.2 Testing Tools
   • 6.3 Deployment Process
   • 6.4 Hosting Environment

7. CHAPTER SEVEN: PROJECT MANAGEMENT

   • 7.1 Work Breakdown Structure
   • 7.2 Gantt Chart
   • 7.3 Risk Management Plan
   • 7.4 Resource Management
   • 7.5 Budget Management and Client Communication

8. CHAPTER EIGHT: CONCLUSION AND RECOMMENDATIONS

   • 8.1 Summary of Achievements
   • 8.2 Limitations
   • 8.3 Future Enhancements

9. REFERENCES

---

CHAPTER ONE: INTRODUCTION

1.1 Background of the Study

The global landscape of education has undergone a significant transformation in recent decades, driven largely by advances in information and communication technology (ICT). The emergence of electronic learning (e-learning) has revolutionised the traditional classroom paradigm, offering new possibilities for knowledge dissemination, student engagement, and educational accessibility. At the heart of this digital education revolution lies the Learning Management System (LMS), a software application designed to facilitate the administration, documentation, tracking, reporting, and delivery of educational courses and training programmes.

In Nigeria, the higher education sector has witnessed substantial growth, with over 170 universities serving millions of students across the country. However, this expansion has not been matched by a corresponding development in educational technology infrastructure. Many Nigerian universities continue to rely on traditional face-to-face teaching methods, with limited adoption of digital learning tools. This situation was brought into sharp focus during the COVID-19 pandemic, which exposed the critical need for robust online learning platforms that could ensure educational continuity during periods of disruption.

The concept of Learning Management Systems dates back to the late 1990s, with platforms such as Blackboard and WebCT pioneering the field. Since then, the LMS market has grown exponentially, with both proprietary and open-source solutions competing for adoption. Modern LMS platforms offer a wide range of features including course content management, assessment tools, communication facilities, progress tracking, and analytics. Despite the availability of these solutions, many institutions in developing countries, including Nigeria, face significant barriers to adoption, including cost, infrastructure limitations, and lack of technical expertise.

EduLearn emerged as a response to these challenges, conceived as a purpose-built LMS tailored to the specific needs and constraints of Nigerian universities. The platform aims to provide an affordable, user-friendly, and feature-rich solution that can be deployed with minimal infrastructure requirements while still delivering a comprehensive e-learning experience.

1.2 Problem Statement

Nigerian universities face numerous challenges in adopting and implementing effective Learning Management Systems. These challenges can be categorised into several key areas:

Technological Infrastructure Limitations: Many Nigerian institutions lack the robust IT infrastructure necessary to support enterprise-level LMS platforms. Unreliable internet connectivity, inadequate server capacity, and limited access to computing devices among students create significant barriers to e-learning adoption.

Cost Constraints: Commercial LMS platforms such as Blackboard, Canvas, and D2L Brightspace carry substantial licensing fees that are often beyond the budgetary capacity of Nigerian universities. Even open-source alternatives like Moodle require significant investment in hosting, customisation, and technical support.

User Experience Challenges: Existing LMS platforms are often designed with Western educational contexts in mind, resulting in interfaces and workflows that may not align with the pedagogical practices and user expectations prevalent in Nigerian institutions. Complex navigation, overwhelming feature sets, and inadequate localisation contribute to low adoption rates among both lecturers and students.

Limited Integration Capabilities: Many universities operate legacy systems for student information management, examination processing, and administrative functions. The lack of seamless integration between these systems and available LMS platforms creates data silos and increases administrative burden.

Insufficient Training and Support: The successful implementation of any LMS requires comprehensive training for all user categories and ongoing technical support. Many Nigerian institutions lack the resources to provide adequate training, leading to underutilisation of LMS capabilities.

These challenges highlight the need for a purpose-built solution that addresses the specific requirements of Nigerian universities while operating within the constraints of available resources and infrastructure.

1.3 Aim and Objectives

Aim

The primary aim of this project is to develop a comprehensive, user-friendly Learning Management System (EduLearn) that enables Nigerian universities to effectively deliver online education, manage academic content, and facilitate meaningful interaction between students and lecturers.

Objectives

The specific objectives of the EduLearn project are as follows:

1. To design and implement a secure user authentication system that supports multiple user roles (students, lecturers, and administrators) with appropriate access controls and permissions.

2. To develop a comprehensive course management module that enables lecturers to create, organise, and deliver course content including text materials, multimedia resources, and external links.

3. To create an assignment submission and grading workflow that allows students to submit assignments electronically and enables lecturers to grade submissions, provide feedback, and manage grades efficiently.

4. To implement discussion forums that facilitate collaborative learning and enable asynchronous communication between students and lecturers within the context of specific courses.

5. To develop a real-time notification system that keeps users informed of important events such as new assignments, grade postings, forum responses, and announcements.

6. To ensure the system is responsive, accessible, and optimised for use across various devices and network conditions prevalent in Nigeria.

7. To deliver the project within the specified timeline and budget while maintaining high standards of code quality and system reliability.

1.4 Scope of the Project

The EduLearn Learning Management System encompasses the following functional areas:

In Scope

User Management:

• User registration and account management
• Secure authentication with email verification
• Role-based access control (Student, Lecturer, Administrator)
• Profile management and password recovery

Course Management:

• Course creation and configuration
• Course enrolment (manual and self-enrolment)
• Content organisation using modules and lessons
• Support for various content types (text, PDF, video, links)
• Course progress tracking

Assignment Management:

• Assignment creation with due dates and instructions
• File upload submission
• Online grading with feedback
• Grade management and grade book

Discussion Forums:

• Course-specific discussion boards
• Thread creation and replies
• Moderation capabilities
• Search functionality

Notifications:

• Real-time in-app notifications
• Email notifications for critical events
• Notification preferences management

Reporting and Analytics:

• Student progress reports
• Course engagement analytics
• Basic administrative reports

Out of Scope

The following features are explicitly excluded from the initial release of EduLearn:

• Video conferencing and live streaming capabilities
• Mobile native applications (iOS/Android)
• Integration with external payment gateways
• Advanced proctoring for online examinations
• Artificial intelligence-based learning recommendations
• SCORM/xAPI content package support
• Multi-tenancy for multiple institutions

1.5 Significance of the Project

The EduLearn project holds significant value for multiple stakeholders and contributes to the broader goals of educational advancement in Nigeria:

For Students: EduLearn provides students with flexible access to learning materials, enabling them to study at their own pace and convenience. The platform reduces the barriers imposed by physical distance, transportation challenges, and rigid scheduling, making education more accessible to a wider population. Students can track their progress, receive timely feedback on assignments, and engage with peers and instructors through discussion forums.

For Lecturers: The platform empowers lecturers with tools to efficiently manage their courses, reducing the administrative burden associated with traditional teaching methods. Features such as electronic assignment submission, online grading, and automated grade calculation save significant time while improving accuracy. Discussion forums extend the learning conversation beyond the classroom, enabling richer academic discourse.

For Universities: Institutions benefit from improved operational efficiency, reduced paper-based processes, and enhanced ability to monitor educational delivery. The platform provides valuable analytics that can inform pedagogical decisions and institutional planning. Additionally, a modern LMS enhances the institution's competitive positioning in attracting students who increasingly expect technology-enabled learning experiences.

For Nigerian Higher Education: At a national level, EduLearn contributes to the digital transformation of Nigerian higher education. The project demonstrates that locally developed solutions can address the unique challenges faced by Nigerian institutions, potentially reducing dependence on foreign software and retaining intellectual capital within the country. The platform also supports educational continuity during disruptions, as demonstrated by the COVID-19 pandemic's impact on traditional education delivery.

For the Software Development Community: This project serves as a case study in applying professional software engineering practices to address real-world challenges. The documentation and methodologies employed can serve as a reference for future software development projects in the educational technology sector.

1.6 Project Constraints

The EduLearn project operates within several constraints that have influenced technical and managerial decisions throughout the development lifecycle:

Budget Constraint

The project has a fixed budget of ₦5,000,000 (Five Million Naira). This budget must cover all project costs including:

• Personnel costs (salaries/stipends for team members)
• Software licenses and subscriptions
• Cloud hosting and infrastructure
• Development tools and resources
• Testing and quality assurance
• Contingency allowance

The limited budget necessitates careful resource allocation and prioritisation of core features over nice-to-have enhancements. Open-source technologies were favoured where possible to minimise licensing costs.

Timeline Constraint

The project must be completed within a three-month window (January 1 to March 31). This timeline includes all phases of the software development lifecycle:

• Requirements gathering and analysis
• System design
• Implementation and coding
• Testing and quality assurance
• Deployment and documentation

The compressed timeline requires efficient project management, parallel task execution where possible, and disciplined scope management to avoid delays.

Resource Constraint

The project team consists of:

• 5 Developers
• 1 Project Manager
• 1 UI/UX Designer

This team size limits the amount of work that can be undertaken concurrently and requires careful task allocation to balance workload and avoid bottlenecks. The absence of dedicated roles such as business analyst, quality assurance engineer, or DevOps specialist means team members must assume multiple responsibilities.

Technical Constraints

• The system must operate efficiently on moderate bandwidth connections
• The platform must support major web browsers (Chrome, Firefox, Safari, Edge)
• The solution must be deployable on affordable cloud hosting platforms
• The backend must be scalable to support potential growth in user base

Risk Factors

Two significant risks were identified at project inception:

1. API Integration Delays: Third-party API integrations (email services, cloud storage) may experience delays due to documentation issues, rate limiting, or service disruptions.

2. Scope Creep: Stakeholders may request additional features during development, potentially impacting the timeline and budget.

These constraints collectively shaped the project approach, influencing technology choices, feature prioritisation, and risk management strategies.

---

CHAPTER TWO: LITERATURE REVIEW

2.1 Overview of Learning Management Systems

A Learning Management System (LMS) is a software application or web-based technology used to plan, implement, and assess a specific learning process (Turnbull, Chugh, & Luck, 2019). The core purpose of an LMS is to provide educators and learners with a centralised platform for managing educational content, delivering instruction, tracking student progress, and facilitating communication.

Historical Development

The evolution of Learning Management Systems can be traced through several distinct generations (Pappas, 2019):

First Generation (1990s): Early LMS platforms emerged primarily as content repositories, allowing instructors to upload and organise course materials for student access. These systems offered limited interactivity and were largely one-directional in their communication model. Notable early platforms included PLATO (Programmed Logic for Automatic Teaching Operations) and FirstClass.

Second Generation (Late 1990s - 2000s): This era saw the emergence of commercial LMS platforms such as Blackboard and WebCT, as well as open-source alternatives like Moodle. These systems introduced more sophisticated features including discussion forums, assessment tools, and grade management. The Learning Technology Standards Committee (LTSC) and Advanced Distributed Learning (ADL) initiative established standards such as SCORM to enable content interoperability.

Third Generation (2010s): Cloud computing transformed the LMS landscape, enabling Software-as-a-Service (SaaS) deployment models that reduced the burden of on-premise infrastructure. Platforms such as Canvas, Schoology, and Google Classroom emerged, offering improved user experiences and mobile accessibility. This generation also saw increased emphasis on learning analytics and personalised learning pathways.

Fourth Generation (2020s - Present): Contemporary LMS development is characterised by the integration of artificial intelligence, adaptive learning technologies, and immersive experiences including virtual and augmented reality. The COVID-19 pandemic accelerated LMS adoption globally, driving innovation in areas such as video conferencing integration, proctored assessments, and engagement analytics.

Core Components of an LMS

Modern Learning Management Systems typically comprise the following functional components (Aldiab et al., 2019):

Component	Description
User Management	Registration, authentication, role assignment, and profile management
Course Management	Creation, organisation, and delivery of course content
Content Authoring	Tools for creating and editing learning materials
Assessment Engine	Quizzes, assignments, rubrics, and grade management
Communication Tools	Discussion forums, messaging, announcements
Tracking & Reporting	Progress monitoring, completion tracking, analytics
Integration Layer	APIs for connecting with external systems

Theoretical Framework

The design of effective Learning Management Systems is informed by several educational theories:

Constructivism: This theory posits that learners actively construct knowledge through interaction with their environment. LMS features such as discussion forums, collaborative projects, and peer review support constructivist learning approaches (Jonassen, 1999).

Social Learning Theory: Bandura's social learning theory emphasises the importance of observation, imitation, and modeling in the learning process. LMS platforms support social learning through features that enable peer interaction and collaborative knowledge construction (Bandura, 1977).

Self-Regulated Learning: Zimmerman's model of self-regulated learning emphasises learner autonomy and metacognitive skills. LMS features such as progress tracking, goal setting, and self-paced modules support the development of self-regulation skills (Zimmerman, 2002).

2.2 Existing LMS Platforms

The LMS market comprises a diverse ecosystem of proprietary and open-source platforms. This section provides a comparative analysis of leading platforms relevant to the Nigerian higher education context.

Comparison of Major LMS Platforms

Feature	Moodle	Canvas	Blackboard	Google Classroom
Licensing	Open Source (GPL)	Proprietary (SaaS)	Proprietary	Free (with Google account)
Cost	Free (hosting costs apply)	Subscription-based	Subscription-based	Free
Customisation	Highly customisable	Limited	Moderate	Very limited
Learning Curve	Steep	Moderate	Moderate	Easy
Mobile App	Available	Available	Available	Available
Offline Access	Limited	Limited	Limited	Limited
SCORM Support	Yes	Yes	Yes	No
Video Conferencing	Plugin required	Integrated	Integrated	Google Meet
Analytics	Basic (plugins available)	Advanced	Advanced	Basic

Platform Analysis

Moodle: Moodle (Modular Object-Oriented Dynamic Learning Environment) is the world's most widely used open-source LMS, with over 300 million users across 240+ countries (Moodle, 2023). Its open-source nature makes it attractive to budget-constrained institutions. However, Moodle's complexity and steep learning curve have been cited as barriers to adoption. The platform requires significant technical expertise for installation, customisation, and maintenance. User interface criticisms are common, with many finding the default design dated and unintuitive.

Canvas: Canvas by Instructure has gained significant market share in higher education due to its modern interface and robust API ecosystem. The platform is praised for its intuitive design and comprehensive feature set. However, its subscription-based pricing model places it beyond the reach of many Nigerian institutions. Canvas excels in areas such as analytics and mobile experience, setting a high benchmark for user expectations.

Blackboard Learn: Blackboard has been a dominant player in the LMS market for over two decades. The platform offers comprehensive functionality and is widely used in universities globally. However, Blackboard has faced criticism for its complex interface and high total cost of ownership. Recent corporate changes and platform transitions have created uncertainty among some users.

Google Classroom: Google Classroom has emerged as a popular option, particularly for institutions already using Google Workspace. Its simplicity and zero licensing cost are attractive. However, Google Classroom lacks the depth of features found in dedicated LMS platforms, particularly in areas such as advanced assessment options, SCORM compliance, and detailed analytics.

Implications for EduLearn

The analysis of existing platforms reveals several opportunities for EduLearn:

1. User Experience Focus: Complex interfaces are a common criticism of established platforms. EduLearn can differentiate by prioritising simplicity and intuitive design.

2. Cost Effectiveness: By developing a custom solution within a controlled budget, EduLearn can offer an affordable alternative to expensive commercial platforms.

3. Local Context: EduLearn can be designed with Nigerian educational practices in mind, avoiding the cultural mismatches that can occur with foreign platforms.

4. Appropriate Feature Set: Rather than attempting to match the comprehensive feature sets of mature platforms, EduLearn can focus on core functionality that addresses immediate needs.

2.3 Challenges of LMS in Developing Countries

The adoption and effective utilisation of Learning Management Systems in developing countries face unique challenges that differ significantly from the experiences of institutions in developed nations (Mtebe, 2015).

Infrastructure Challenges

Internet Connectivity: Reliable, high-speed internet access remains a significant challenge across many developing countries. In Nigeria, while internet penetration has grown substantially, quality of service varies widely. Many students rely on mobile data connections, which may be expensive, unreliable, or subject to bandwidth limitations. LMS platforms designed for high-bandwidth environments may perform poorly under these conditions.

Power Supply: Inconsistent electricity supply affects both institutional infrastructure and individual student access. Universities may struggle to maintain server uptime, while students may find their study schedule constrained by power availability.

Device Access: While smartphone penetration has increased, access to computers remains limited for many students. LMS platforms must be optimised for mobile devices and should function effectively on lower-specification hardware.

Financial Constraints

Many institutions in developing countries operate under severe budgetary constraints. Allocating funds for educational technology competes with other pressing needs such as physical infrastructure, staffing, and basic educational resources. This constraint affects not only software licensing but also hardware procurement, bandwidth provision, and technical support.

Human Capacity Challenges

Digital Literacy: Varying levels of digital literacy among both students and faculty present challenges for LMS adoption. While digital native students may adapt quickly, mature students and some faculty members may struggle with technology-mediated learning.

Technical Support: Maintaining an LMS requires technical expertise that may be scarce in developing country contexts. Institutions may lack dedicated IT staff with the skills necessary for system administration, troubleshooting, and user support.

Change Management: Resistance to change can impede LMS adoption. Faculty accustomed to traditional teaching methods may be reluctant to invest time in learning new technologies, particularly if the benefits are not clearly demonstrated.

Pedagogical Considerations

Teaching Tradition: Educational practices in many developing countries emphasise teacher-centred, lecture-based instruction. Shifting to the learner-centred approaches enabled by LMS platforms requires not just technical change but pedagogical transformation.

Content Development: Creating high-quality digital learning content is resource-intensive. Many institutions lack the capacity to develop the content necessary to fully exploit LMS capabilities, resulting in underutilisation of platform features.

Addressing the Challenges

Successful LMS implementation in developing countries requires strategies tailored to these challenges:

• Low-bandwidth optimisation: Minimising page sizes, supporting offline access, and avoiding heavy multimedia
• Mobile-first design: Ensuring full functionality on smartphone browsers
• Progressive complexity: Introducing features gradually to avoid overwhelming users
• Comprehensive training: Investing in user education and ongoing support
• Strong change management: Engaging stakeholders and demonstrating value

EduLearn's development was informed by these considerations, with architectural and design decisions specifically intended to address the challenges of the Nigerian context.

---

CHAPTER THREE: SYSTEM ANALYSIS

3.1 Stakeholder Analysis

Stakeholder analysis is a critical component of requirements engineering, identifying all parties with an interest in the system and understanding their needs, expectations, and potential influence on the project (Alexander & Beus-Dukic, 2009).

Stakeholder Identification

Stakeholder	Role	Interest Level	Influence Level
Students	Primary End Users	High	Medium
Lecturers	Primary End Users	High	High
University Administrators	System Managers	High	High
IT Department	Technical Support	Medium	Medium
University Management	Strategic Oversight	Medium	High
Parents/Guardians	Indirect Stakeholders	Low	Low
Accreditation Bodies	Regulatory Oversight	Low	Medium

Detailed Stakeholder Profiles

Students: Students represent the largest user group and are the primary beneficiaries of the system. Their key needs include easy access to course materials, clear assignment submission processes, timely feedback on their work, and effective communication channels with lecturers and peers. Students expect a modern, intuitive interface that works well on mobile devices. They are particularly sensitive to system reliability and ease of use.

Lecturers: Lecturers are critical stakeholders whose adoption of the system will determine its success. Their primary needs include efficient course content management, streamlined assignment collection and grading, and tools for monitoring student progress. Lecturers often have limited time for learning new systems, making ease of use particularly important. They require confidence that their content is secure and that the system will be reliable.

University Administrators: Administrative staff use the system to manage user accounts, oversee course offerings, and generate reports. They need tools for bulk user management, course allocation, and system monitoring. Administrators are concerned with policy compliance, data integrity, and the ability to respond to user support requests.

IT Department: IT staff are responsible for system deployment, maintenance, and technical support. They require clear documentation, straightforward deployment procedures, and effective monitoring tools. The IT department is concerned with system security, integration with existing infrastructure, and manageable support burden.

University Management: Senior university leadership has indirect but significant influence over the project. They are interested in the strategic benefits of the LMS, including institutional reputation, operational efficiency, and return on investment. Their support is essential for resource allocation and policy decisions.

Stakeholder Communication Plan

Stakeholder Group	Communication Method	Frequency	Responsible Party
Students	In-app announcements, Email	As needed	Project Manager
Lecturers	Training sessions, Email	Weekly during development	Project Manager, UI/UX Designer
Administrators	Status meetings	Bi-weekly	Project Manager
IT Department	Technical documentation, Meetings	Weekly	Lead Developer
Management	Executive summary reports	Monthly	Project Manager

3.2 Functional Requirements

Functional requirements describe what the system must do, specifying the behaviours and functions that the software must provide (Sommerville, 2016).

User Authentication and Authorisation

ID	Requirement	Priority
FR-AUTH-01	The system shall allow users to register using email and password	High
FR-AUTH-02	The system shall send email verification upon registration	High
FR-AUTH-03	The system shall authenticate users using email and password credentials	High
FR-AUTH-04	The system shall support password reset via email	High
FR-AUTH-05	The system shall enforce role-based access control (Student, Lecturer, Admin)	High
FR-AUTH-06	The system shall maintain user session with configurable timeout	Medium
FR-AUTH-07	The system shall log all authentication events	Medium

Course Management

ID	Requirement	Priority
FR-CRS-01	Lecturers shall be able to create new courses with title, description, and code	High
FR-CRS-02	Lecturers shall be able to organise course content into modules and lessons	High
FR-CRS-03	The system shall support upload of various content types (PDF, DOC, video links)	High
FR-CRS-04	Students shall be able to browse and enrol in available courses	High
FR-CRS-05	Lecturers shall be able to manually enrol students in courses	High
FR-CRS-06	The system shall track student progress through course content	Medium
FR-CRS-07	Lecturers shall be able to archive completed courses	Low

Assignment Management

ID	Requirement	Priority
FR-ASN-01	Lecturers shall be able to create assignments with title, instructions, and due date	High
FR-ASN-02	Students shall be able to submit files for assignments	High
FR-ASN-03	The system shall prevent submissions after the due date (configurable)	High
FR-ASN-04	Lecturers shall be able to view and download student submissions	High
FR-ASN-05	Lecturers shall be able to assign grades and provide feedback	High
FR-ASN-06	Students shall be able to view their grades and feedback	High
FR-ASN-07	The system shall maintain a gradebook with calculated totals/averages	Medium

Discussion Forums

ID	Requirement	Priority
FR-FOR-01	The system shall provide course-specific discussion forums	High
FR-FOR-02	Users shall be able to create new discussion threads	High
FR-FOR-03	Users shall be able to reply to existing threads	High
FR-FOR-04	Lecturers shall have moderation capabilities (edit, delete, pin threads)	Medium
FR-FOR-05	Users shall be able to search forum content	Low

Notifications

ID	Requirement	Priority
FR-NOT-01	The system shall send real-time notifications for new assignments	High
FR-NOT-02	The system shall notify students when grades are posted	High
FR-NOT-03	The system shall notify users of new forum replies	Medium
FR-NOT-04	The system shall send email notifications for critical events	Medium
FR-NOT-05	Users shall be able to configure notification preferences	Low

Administration

ID	Requirement	Priority
FR-ADM-01	Administrators shall be able to manage user accounts	High
FR-ADM-02	Administrators shall be able to assign and modify user roles	High
FR-ADM-03	The system shall provide system-wide announcements capability	Medium
FR-ADM-04	The system shall generate usage and activity reports	Low

3.3 Non-Functional Requirements

Non-functional requirements specify criteria for judging the operation of a system rather than specific behaviours (ISO/IEC 25010, 2011).

Performance Requirements

ID	Requirement
NFR-PERF-01	Page load time shall not exceed 3 seconds under normal conditions
NFR-PERF-02	The system shall support at least 500 concurrent users
NFR-PERF-03	API response time shall not exceed 500 milliseconds for standard operations
NFR-PERF-04	File uploads of up to 50MB shall be supported

Security Requirements

ID	Requirement
NFR-SEC-01	All data transmission shall be encrypted using HTTPS/TLS
NFR-SEC-02	Passwords shall be hashed using industry-standard algorithms (bcrypt)
NFR-SEC-03	The system shall implement protection against common vulnerabilities (SQL injection, XSS, CSRF)
NFR-SEC-04	User sessions shall timeout after 30 minutes of inactivity
NFR-SEC-05	Failed login attempts shall be rate-limited to prevent brute force attacks

Usability Requirements

ID	Requirement
NFR-USE-01	The interface shall be responsive and functional on devices from 320px width
NFR-USE-02	New users shall be able to perform basic tasks without training
NFR-USE-03	The system shall conform to WCAG 2.1 Level AA accessibility guidelines
NFR-USE-04	Error messages shall be clear and actionable

Reliability Requirements

ID	Requirement
NFR-REL-01	System availability shall be at least 99% during academic periods
NFR-REL-02	Data shall be backed up daily with 30-day retention
NFR-REL-03	The system shall recover from failures within 4 hours

Scalability Requirements

ID	Requirement
NFR-SCA-01	The architecture shall support horizontal scaling
NFR-SCA-02	The system shall be designed to accommodate future feature additions

3.4 Use Case Descriptions

Use cases describe the functional requirements of a system from the user's perspective, detailing the interactions between actors and the system to achieve specific goals.

Use Case 1: User Authentication

Element	Description
Use Case ID	UC-01
Use Case Name	User Login
Actor(s)	Student, Lecturer, Administrator
Description	User authenticates to access the system
Preconditions	User has a registered, verified account
Main Flow	1. User navigates to login page
	2. User enters email and password
	3. System validates credentials
	4. System creates session and redirects to dashboard
Alternative Flow	3a. Invalid credentials: System displays error message
	3b. Account locked: System displays lockout message
Postconditions	User is authenticated and has access to role-appropriate features

Use Case 2: Create Course

Element	Description
Use Case ID	UC-02
Use Case Name	Create Course
Actor(s)	Lecturer
Description	Lecturer creates a new course
Preconditions	Lecturer is authenticated
Main Flow	1. Lecturer navigates to course management
	2. Lecturer clicks "Create New Course"
	3. Lecturer enters course details (title, code, description)
	4. Lecturer configures course settings
	5. Lecturer clicks "Create"
	6. System creates course and displays confirmation
Alternative Flow	4a. Duplicate course code: System prompts for different code
Postconditions	New course exists in the system

Use Case 3: Submit Assignment

Element	Description
Use Case ID	UC-03
Use Case Name	Submit Assignment
Actor(s)	Student
Description	Student submits work for an assignment
Preconditions	Student is enrolled in course; Assignment is open for submission
Main Flow	1. Student navigates to assignment
	2. Student views assignment instructions
	3. Student clicks "Submit"
	4. Student uploads file(s)
	5. Student clicks "Confirm Submission"
	6. System records submission with timestamp
	7. System displays confirmation
Alternative Flow	4a. File too large: System displays error
	4b. Past due date and late submissions disabled: System denies submission
Postconditions	Assignment submission is recorded; Lecturer can view submission

Use Case 4: Grade Assignment

Element	Description
Use Case ID	UC-04
Use Case Name	Grade Assignment
Actor(s)	Lecturer
Description	Lecturer grades a student's assignment submission
Preconditions	Student has submitted assignment; Lecturer is course instructor
Main Flow	1. Lecturer navigates to assignment submissions
	2. Lecturer selects a submission to grade
	3. Lecturer downloads/views submitted file
	4. Lecturer enters grade (numerical score)
	5. Lecturer enters feedback comments
	6. Lecturer clicks "Save Grade"
	7. System records grade and notifies student
Alternative Flow	None
Postconditions	Grade is recorded; Student receives notification

Use Case 5: Participate in Discussion

Element	Description
Use Case ID	UC-05
Use Case Name	Post Forum Reply
Actor(s)	Student, Lecturer
Description	User responds to a discussion thread
Preconditions	User is enrolled in course; Thread exists
Main Flow	1. User navigates to course discussion forum
	2. User opens existing thread
	3. User types reply in text field
	4. User clicks "Post Reply"
	5. System saves reply with timestamp
	6. System notifies thread participants
Alternative Flow	4a. Empty reply: System prompts user to enter content
Postconditions	Reply is visible in thread; Participants are notified

3.5 Risk Analysis and Mitigation Strategies

Risk management is essential for software project success, involving the identification, assessment, and prioritisation of risks followed by coordinated effort to minimise, monitor, and control their probability or impact (PMI, 2017).

Risk Identification and Assessment

Risk ID	Risk Description	Probability	Impact	Risk Level
R-01	Third-party API integration delays	High	Medium	High
R-02	Scope creep from stakeholder requests	High	High	Critical
R-03	Developer illness or unavailability	Medium	High	High
R-04	Budget cuts or funding issues	Medium	High	High
R-05	Technical complexity underestimation	Medium	Medium	Medium
R-06	Security vulnerability discovery	Low	High	Medium
R-07	Key personnel departure	Low	High	Medium
R-08	Infrastructure or hosting issues	Medium	Medium	Medium

Risk Mitigation Strategies

R-01: API Integration Delays

The integration of third-party services such as email delivery (SendGrid, Mailgun) or cloud storage may face delays due to documentation issues, rate limiting, or service disruptions.

Mitigation Strategies:

• Begin API integration early in the development cycle
• Implement abstraction layers to allow easy switching between providers
• Develop fallback mechanisms (e.g., queue emails for retry)
• Maintain relationships with alternative service providers
• Build in buffer time for integration testing

R-02: Scope Creep

Stakeholders may request additional features during development. For example, a request for video conferencing functionality emerged during the project.

Mitigation Strategies:

• Clearly document and communicate initial scope
• Implement formal change request process
• Evaluate all requests against timeline and budget impact
• Prioritise requests using MoSCoW method
• Educate stakeholders on trade-offs between scope, time, and cost
• Maintain a backlog for post-release enhancements

Specific Case - Video Conferencing Request: When stakeholders requested video conferencing functionality, the following response was provided:

"Video conferencing is a valuable feature that would enhance the platform significantly. However, implementing this feature would require approximately 4-6 additional weeks of development time, additional budget for real-time communication infrastructure, and expertise in WebRTC or similar technologies. We recommend documenting this as a Phase 2 enhancement for the next release cycle while ensuring the current architecture can accommodate future integration (e.g., embedding third-party solutions like Zoom or Google Meet)."

R-03: Developer Illness or Unavailability

The loss of a team member, even temporarily, can significantly impact project progress.

Mitigation Strategies:

• Cross-train team members on different components
• Maintain comprehensive documentation
• Use pair programming for critical features
• Ensure code is well-commented and follows standards
• Maintain a resource buffer in project schedule

Resource Adjustment Plan: If a developer becomes unavailable, the following adjustments will be made:

1. Immediately assess impact on current sprint tasks
2. Redistribute urgent tasks among remaining developers
3. Prioritise critical path items
4. Consider extending working hours temporarily (with compensation)
5. Evaluate option of engaging a contract developer if absence extends beyond one week
6. Adjust sprint scope and communicate revised timeline to stakeholders

R-04: Budget Cuts

Financial constraints may necessitate a reduction in project budget.

Mitigation Strategies:

• Identify must-have vs. nice-to-have features
• Maintain cost tracking and forecasting
• Develop contingency scenarios for different budget levels
• Communicate regularly with stakeholders on budget status

See Section 7.5 for detailed handling of 20% budget cut scenario.

R-05: Technical Complexity

Certain features may prove more complex to implement than initially estimated.

Mitigation Strategies:

• Conduct technical spikes early for uncertain areas
• Include contingency in estimates
• Use proven technologies and patterns
• Seek external expertise when needed

R-06: Security Vulnerabilities

Security issues discovered during development or testing could require significant rework.

Mitigation Strategies:

• Follow security best practices from project start
• Conduct regular security reviews
• Use automated security scanning tools
• Plan for security testing in project schedule

---

CHAPTER FOUR: SYSTEM DESIGN

4.1 System Architecture

The EduLearn system employs a modern three-tier architecture that separates concerns between presentation, business logic, and data management layers. This architectural approach provides scalability, maintainability, and flexibility for future enhancements.

High-Level Architecture Diagram Description

The system architecture consists of the following primary components:

Client Layer (Presentation Tier):

• Web browsers (Chrome, Firefox, Safari, Edge) accessing the React.js single-page application
• Responsive design serving both desktop and mobile users
• Progressive Web App (PWA) capabilities for improved mobile experience

Application Layer (Business Logic Tier):

• Laravel PHP framework providing RESTful API endpoints
• Authentication middleware handling security
• Business logic controllers processing user requests
• Queue workers handling background jobs (email sending, notifications)

Data Layer (Data Tier):

• MySQL database server for persistent data storage
• Redis cache for session management and performance optimisation
• File storage system for uploaded documents and media

External Services:

• Email service provider (SendGrid) for transactional emails
• Cloud storage (optional) for file backup
• CDN (optional) for static asset delivery

Component Interaction

The system follows a client-server model where:

1. Client browser sends HTTPS requests to the load balancer
2. Load balancer distributes requests to web server (Nginx)
3. Nginx forwards dynamic requests to Laravel Application Server
4. Application server interacts with MySQL database, Redis cache, and file storage
5. Background jobs are processed by queue workers
6. Email notifications are sent through external email service

API Design

The RESTful API follows standard conventions with the following endpoint structure:

Resource	Endpoint	Methods
Authentication	/api/auth/*	POST (login, register, logout)
Users	/api/users/*	GET, PUT, DELETE
Courses	/api/courses/*	GET, POST, PUT, DELETE
Assignments	/api/courses/{id}/assignments/*	GET, POST, PUT, DELETE
Submissions	/api/assignments/{id}/submissions/*	GET, POST, PUT
Forums	/api/courses/{id}/forums/*	GET, POST, PUT, DELETE
Notifications	/api/notifications/*	GET, PUT

All API responses follow a consistent JSON structure with appropriate HTTP status codes.

4.2 Technology Stack Justification

Backend: Laravel (PHP Framework)

Justification:

• Mature ecosystem: Laravel is a well-established framework with extensive documentation, tutorials, and community support
• Rapid development: Built-in features such as Eloquent ORM, authentication scaffolding, and queue management accelerate development
• Security features: Laravel includes protection against common vulnerabilities (CSRF, SQL injection, XSS)
• Scalability: Laravel applications can be scaled horizontally using load balancers and queue workers
• Local expertise: PHP/Laravel developers are widely available in Nigeria, facilitating future maintenance
• Cost-effective hosting: PHP hosting is widely available and affordable compared to some alternatives

Frontend: React.js

Justification:

• Component-based architecture: Promotes code reusability and maintainability
• Virtual DOM: Provides excellent performance for dynamic user interfaces
• Large ecosystem: Extensive library of third-party components and tools
• Developer experience: Hot reloading and excellent debugging tools improve productivity
• Industry standard: React is widely used, ensuring availability of developers for future maintenance
• Mobile responsiveness: React combined with CSS frameworks enables excellent mobile experiences

Database: MySQL

Justification:

• Reliability: MySQL is a proven, stable database system used by major web applications
• Performance: Excellent performance for read-heavy workloads typical of LMS applications
• Scalability: Supports replication and clustering for scaling
• Integration: Native integration with Laravel through Eloquent ORM
• Cost: Open-source with no licensing costs
• Tooling: Extensive management tools and GUI clients available

Additional Technologies

Technology	Purpose	Justification
Redis	Caching, Sessions	High-performance in-memory store; improves response times
Nginx	Web Server	Efficient handling of static files and reverse proxy
Git	Version Control	Industry standard for collaborative development
Docker	Containerisation	Consistent development and deployment environments
PHPUnit	Testing	Laravel's native testing framework
Jest	Frontend Testing	Standard React testing framework

4.3 Database Design

Entity-Relationship Diagram Description

The EduLearn database comprises the following primary entities and their relationships:

Core Entities:

1. Users

   • Stores all user information regardless of role
   • Attributes: id, name, email, password_hash, role, email_verified_at, profile_image, created_at, updated_at
   • Relationships: One-to-Many with Courses (as instructor), Many-to-Many with Courses (as student)

2. Courses

   • Represents individual courses offered on the platform
   • Attributes: id, title, code, description, instructor_id, status, created_at, updated_at
   • Relationships: Many-to-One with Users (instructor), Many-to-Many with Users (students), One-to-Many with Modules

3. Modules

   • Organises course content into logical sections
   • Attributes: id, course_id, title, order, created_at, updated_at
   • Relationships: Many-to-One with Courses, One-to-Many with Lessons

4. Lessons

   • Individual content items within modules
   • Attributes: id, module_id, title, content_type, content, order, created_at, updated_at
   • Relationships: Many-to-One with Modules

5. Assignments

   • Assessment items created by instructors
   • Attributes: id, course_id, title, instructions, due_date, max_score, allow_late, created_at, updated_at
   • Relationships: Many-to-One with Courses, One-to-Many with Submissions

6. Submissions

   • Student assignment submissions
   • Attributes: id, assignment_id, student_id, file_path, submitted_at, grade, feedback, graded_at, graded_by
   • Relationships: Many-to-One with Assignments, Many-to-One with Users

7. Forum_Threads

   • Discussion topics within course forums
   • Attributes: id, course_id, user_id, title, content, is_pinned, created_at, updated_at
   • Relationships: Many-to-One with Courses, Many-to-One with Users, One-to-Many with Forum_Posts

8. Forum_Posts

   • Replies to forum threads
   • Attributes: id, thread_id, user_id, content, created_at, updated_at
   • Relationships: Many-to-One with Forum_Threads, Many-to-One with Users

9. Notifications

   • User notifications
   • Attributes: id, user_id, type, message, data, read_at, created_at
   • Relationships: Many-to-One with Users

10. Enrolments

    • Junction table for course-student relationships
    • Attributes: id, course_id, user_id, enrolled_at, status
    • Relationships: Many-to-One with Courses, Many-to-One with Users

Database Normalisation

The database design adheres to Third Normal Form (3NF) to minimise redundancy and ensure data integrity. Key normalisation decisions include:

• Separating user roles into a single Users table with role attribute rather than separate tables
• Using junction tables for many-to-many relationships (Enrolments)
• Storing file references (paths) rather than binary data in the database

4.4 User Interface Design Overview

Design Principles

The EduLearn user interface was designed following these core principles:

1. Simplicity: Clean, uncluttered interfaces that prioritise essential information
2. Consistency: Uniform navigation, typography, and interaction patterns throughout
3. Responsiveness: Fluid layouts that adapt seamlessly from mobile to desktop
4. Accessibility: WCAG 2.1 Level AA compliance for inclusive access
5. Feedback: Clear visual feedback for user actions and system states

Key Interface Components

Navigation Structure:

• Persistent sidebar navigation on desktop devices
• Collapsible hamburger menu on mobile devices
• Breadcrumb navigation for deep page hierarchies
• Quick action buttons for common tasks

Dashboard Design:

• Role-specific dashboards (Student, Lecturer, Admin)
• Card-based layout for course overview
• Activity feed showing recent events
• Quick access to upcoming deadlines and assignments

Course Interface:

• Module-lesson hierarchy displayed as expandable list
• Progress indicators showing completion status
• Contextual action buttons for content management
• Integrated assignment and forum access

Colour Scheme:

• Primary: Deep blue (#1E3A5F) - conveying trust and professionalism
• Secondary: Vibrant green (#28A745) - indicating success and progress
• Accent: Warm orange (#F7931E) - highlighting calls-to-action
• Background: Light grey (#F5F7FA) - reducing eye strain
• Text: Dark grey (#333333) - ensuring readability

Typography:

• Primary font: Inter (Google Fonts) - modern, highly legible
• Headings: Semi-bold weights for hierarchy
• Body: Regular weight for comfortable reading
• Code: Monospace font for technical content

---

CHAPTER FIVE: IMPLEMENTATION

5.1 Agile Methodology Explanation

The EduLearn project adopted the Agile methodology, specifically the Scrum framework, to manage the development process. Agile methodologies prioritise flexibility, collaboration, and iterative delivery, making them well-suited for projects with evolving requirements and tight timelines (Schwaber & Sutherland, 2020).

Core Agile Principles Applied

Iterative Development: Rather than attempting to deliver all functionality at once, the project was divided into two-week sprints, each delivering a working increment of the software. This approach allowed for early testing, stakeholder feedback, and course correction.

Continuous Collaboration: Daily stand-up meetings ensured team alignment and rapid problem resolution. Regular sprint reviews provided stakeholders with visibility into progress and opportunities to provide input.

Responding to Change: The sprint structure allowed for reprioritisation between sprints based on stakeholder feedback or changing circumstances. Features could be added, modified, or deferred based on project needs.

Working Software: Each sprint aimed to deliver potentially shippable functionality, ensuring that the project always had a working product that could be demonstrated or, if necessary, deployed.

Scrum Roles

Role	Person	Responsibilities
Product Owner	Project Manager	Manages backlog, defines priorities, represents stakeholders
Scrum Master	Lead Developer	Facilitates ceremonies, removes impediments, ensures process adherence
Development Team	5 Developers, 1 UI/UX Designer	Implements features, conducts testing, delivers increments

Scrum Ceremonies

Sprint Planning (Beginning of each sprint):

• Review and select backlog items for the sprint
• Break down items into tasks
• Estimate effort using story points
• Commit to sprint goal

Daily Stand-up (15 minutes each morning):

• What did you complete yesterday?
• What will you work on today?
• Are there any blockers?

Sprint Review (End of each sprint):

• Demonstrate completed work to stakeholders
• Gather feedback
• Discuss what was not completed and why

Sprint Retrospective (After each review):

• What went well?
• What could be improved?
• Action items for next sprint

User Stories

Functional requirements were captured as user stories following the format: "As a [user type], I want [functionality] so that [benefit]."

Example user stories:

• As a student, I want to view my enrolled courses on a dashboard so that I can quickly access my learning materials.
• As a lecturer, I want to create assignments with due dates so that students know when work is expected.
• As an administrator, I want to manage user accounts so that I can maintain system security.

5.2 Sprint Planning

Sprint Overview

The three-month project was organised into six two-week sprints:

Sprint	Dates	Focus Area
Sprint 1	Jan 1 - Jan 14	Foundation: Authentication, User Management
Sprint 2	Jan 15 - Jan 28	Core: Course Management, Content Structure
Sprint 3	Jan 29 - Feb 11	Features: Assignment Submission and Grading
Sprint 4	Feb 12 - Feb 25	Features: Discussion Forums, Notifications
Sprint 5	Feb 26 - Mar 11	Polish: UI Refinement, Performance Optimisation
Sprint 6	Mar 12 - Mar 31	Launch: Testing, Deployment, Documentation

Sprint 1: Foundation (January 1-14)

Sprint Goal: Establish the technical foundation and deliver a working authentication system.

User Stories:

Story ID	User Story	Points	Assignee
US-001	As a user, I want to register an account so that I can access the system	5	Dev 1
US-002	As a user, I want to verify my email so that my account is activated	3	Dev 1
US-003	As a user, I want to log in securely so that I can access my dashboard	5	Dev 2
US-004	As a user, I want to reset my password so that I can regain access if forgotten	3	Dev 2
US-005	As a user, I want to update my profile so that my information is current	2	Dev 3
US-006	As an admin, I want to manage user accounts so that I can maintain the system	5	Dev 3

Technical Tasks:

Task	Description	Assignee
T-001	Set up development environment (Docker, Laravel, React)	Dev 4
T-002	Configure CI/CD pipeline	Dev 4
T-003	Design and implement database schema (users, roles)	Dev 5
T-004	Set up email service integration	Dev 5
T-005	Design authentication UI wireframes	UI/UX Designer
T-006	Implement frontend authentication components	Dev 1, Dev 2

Sprint 1 Outcomes:

• Functional registration and login system
• Email verification working
• Password reset implemented
• Admin user management interface completed
• Development environment standardised across team

Sprint 2: Core Course Management (January 15-28)

Sprint Goal: Deliver course creation and management functionality for lecturers and course browsing/enrolment for students.

User Stories:

Story ID	User Story	Points	Assignee
US-007	As a lecturer, I want to create a new course so that I can deliver content to students	5	Dev 1
US-008	As a lecturer, I want to add modules to my course so that content is organised	3	Dev 1
US-009	As a lecturer, I want to add lessons with various content types so that students can learn	8	Dev 2
US-010	As a student, I want to browse available courses so that I can find courses to enrol in	3	Dev 3
US-011	As a student, I want to enrol in a course so that I can access its content	3	Dev 3
US-012	As a student, I want to view course content so that I can learn	5	Dev 4
US-013	As a lecturer, I want to manually enrol students so that I can control access	3	Dev 5

Technical Tasks:

Task	Description	Assignee
T-007	Design course database schema	Dev 2
T-008	Implement file upload functionality	Dev 4
T-009	Design course and module UI	UI/UX Designer
T-010	Implement course listing and search	Dev 3
T-011	Create progress tracking system	Dev 5

Sprint 2 Outcomes:

• Lecturers can create and manage courses
• Module and lesson structure implemented
• File upload for course content working
• Students can browse, enrol, and view courses
• Manual enrolment by lecturers functional

5.3 Development Tools and Environment

Development Hardware

Each developer was equipped with:

• Laptop with minimum 8GB RAM, SSD storage
• Secondary monitor for increased productivity
• Stable internet connection

Software Development Tools

Category	Tool	Purpose
IDE	Visual Studio Code	Primary code editor with Laravel and React extensions
API Testing	Postman	API endpoint testing and documentation
Database Client	TablePlus / MySQL Workbench	Database management and querying
Design	Figma	UI/UX design and prototyping
Communication	Slack	Team messaging and file sharing
Video Conferencing	Google Meet	Remote meetings and sprint ceremonies
Project Management	Jira	Backlog management, sprint tracking
Documentation	Confluence	Technical documentation

Development Environment Setup

The development environment was containerised using Docker to ensure consistency across team members:

Docker Services:

• PHP-FPM container (PHP 8.1)
• Nginx container (web server)
• MySQL container (database)
• Redis container (caching)
• Node.js container (frontend build)

Environment Configuration:

• .env files for environment-specific configuration
• Separate configurations for development, testing, and production
• Secrets managed securely, not committed to version control

5.4 Version Control Strategy

Git Workflow

The project adopted the Gitflow workflow model, which provides a structured approach to managing code changes:

Branch Structure:

Branch	Purpose
main	Production-ready code; deploys to production server
develop	Integration branch for features; deploys to staging
feature/*	Individual feature development branches
release/*	Release preparation branches
hotfix/*	Emergency production fixes

Feature Development Process:

1. Developer creates feature branch from develop: feature/US-007-create-course
2. Developer implements feature with regular commits
3. Developer opens Pull Request (PR) to develop
4. Code review by at least one other developer
5. Automated tests run on PR
6. Upon approval, PR is merged to develop
7. Feature branch is deleted

Commit Conventions:

Commits follow the conventional commits specification:

• feat: add course creation endpoint
• fix: resolve login redirect issue
• docs: update API documentation
• refactor: simplify user validation logic
• test: add unit tests for assignment submission

Code Review Guidelines:

All code changes require peer review before merging. Reviewers check for:

• Correctness and completeness of implementation
• Code quality and adherence to standards
• Test coverage
• Security considerations
• Documentation updates

---

CHAPTER SIX: TESTING AND DEPLOYMENT

6.1 Types of Testing Conducted

A comprehensive testing strategy was implemented to ensure the quality and reliability of the EduLearn system.

Unit Testing

Unit tests validate individual components in isolation, ensuring that functions and methods behave correctly.

Backend (PHPUnit):

• Model tests: Validating Eloquent model relationships and methods
• Service tests: Testing business logic in service classes
• Controller tests: Verifying controller responses and validation

Frontend (Jest):

• Component tests: Ensuring React components render correctly
• Hook tests: Validating custom React hooks
• Utility tests: Testing helper functions

Coverage Target: Minimum 70% code coverage for critical modules

Integration Testing

Integration tests verify that different components work correctly together.

API Integration Tests:

• Testing complete API request-response cycles
• Validating authentication and authorisation
• Testing database interactions through the API

Frontend-Backend Integration:

• Testing complete user flows through the API
• Validating data format consistency

End-to-End (E2E) Testing

E2E tests simulate real user interactions to validate complete user journeys.

Test Scenarios:

• User registration and login flow
• Course creation and content upload
• Student enrolment and content access
• Assignment submission and grading
• Forum posting and replies

User Acceptance Testing (UAT)

UAT involved actual users (representative students and lecturers) testing the system to validate that it meets their needs.

UAT Process:

1. Prepared test scenarios based on user stories
2. Recruited volunteer testers from target user groups
3. Conducted supervised testing sessions
4. Collected feedback through structured questionnaires
5. Prioritised and addressed feedback items

Security Testing

Security testing identified and addressed potential vulnerabilities.

Security Tests Performed:

• SQL injection testing
• Cross-Site Scripting (XSS) testing
• Cross-Site Request Forgery (CSRF) testing
• Authentication bypass attempts
• Authorisation boundary testing
• File upload security testing

Performance Testing

Performance tests ensured the system meets non-functional requirements.

Tests Conducted:

• Load testing: 500 concurrent users
• Stress testing: Identifying breaking points
• Response time measurement: Validating sub-3-second page loads
• Database query optimisation

6.2 Testing Tools

Testing Type	Tool	Description
Unit (Backend)	PHPUnit	PHP testing framework integrated with Laravel
Unit (Frontend)	Jest	JavaScript testing framework for React
API Testing	Postman, PHPUnit	API endpoint testing and automation
E2E Testing	Cypress	Browser-based end-to-end testing
Load Testing	Apache JMeter	Performance and load testing
Security	OWASP ZAP	Security vulnerability scanning
Code Analysis	PHP_CodeSniffer, ESLint	Static code analysis

6.3 Deployment Process

Continuous Integration/Continuous Deployment (CI/CD)

The project implemented CI/CD using GitHub Actions to automate testing and deployment.

CI Pipeline (On every push/PR):

1. Checkout code
2. Set up PHP and Node.js environments
3. Install dependencies (Composer, npm)
4. Run linting checks
5. Execute unit tests
6. Execute integration tests
7. Build frontend assets
8. Report results

CD Pipeline (On merge to main):

1. Execute CI pipeline
2. Build production assets
3. Create deployment package
4. Deploy to production server
5. Run database migrations
6. Clear and warm caches
7. Notify team of deployment

Deployment Procedure

Pre-Deployment:

• Complete all testing
• Obtain deployment approval
• Backup current production database
• Prepare rollback plan

Deployment Steps:

1. Enable maintenance mode on production
2. Pull latest code from repository
3. Install/update dependencies
4. Run database migrations
5. Clear application caches
6. Compile frontend assets
7. Restart queue workers
8. Disable maintenance mode
9. Verify deployment success

Post-Deployment:

• Monitor error logs
• Verify critical functionality
• Performance monitoring
• User feedback collection

6.4 Hosting Environment

Production Infrastructure

Cloud Provider: DigitalOcean (selected for cost-effectiveness and African availability)

Server Configuration:

Component	Specification
Application Server	2 vCPUs, 4GB RAM, 80GB SSD
Database Server	2 vCPUs, 4GB RAM, 50GB SSD
Operating System	Ubuntu 22.04 LTS
Web Server	Nginx 1.22
PHP Version	PHP 8.1-FPM
Database	MySQL 8.0
Cache	Redis 6.0

Domain and SSL:

• Domain registered and configured
• SSL certificate provisioned via Let's Encrypt
• Automatic certificate renewal configured

Backup Strategy:

• Daily automated database backups
• 30-day backup retention
• Weekly full server snapshots
• Backups stored in separate geographic region

Monitoring:

• Server uptime monitoring
• Application error tracking (Sentry)
• Performance monitoring
• Automated alerting for critical issues

---

CHAPTER SEVEN: PROJECT MANAGEMENT

7.1 Work Breakdown Structure (WBS)

The Work Breakdown Structure decomposes the project into manageable work packages, facilitating planning, tracking, and accountability.

1.0 EduLearn LMS Project

• 1.1 Project Management

  • 1.1.1 Project Planning
  • 1.1.2 Stakeholder Management
  • 1.1.3 Progress Monitoring
  • 1.1.4 Risk Management
  • 1.1.5 Project Closure

• 1.2 Requirements and Design

  • 1.2.1 Requirements Gathering
  • 1.2.2 Requirements Documentation
  • 1.2.3 System Architecture Design
  • 1.2.4 Database Design
  • 1.2.5 UI/UX Design

• 1.3 Development

  • 1.3.1 Backend Development
    • 1.3.1.1 Authentication Module
    • 1.3.1.2 Course Management Module
    • 1.3.1.3 Assignment Module
    • 1.3.1.4 Forum Module
    • 1.3.1.5 Notification Module
  • 1.3.2 Frontend Development
    • 1.3.2.1 Authentication UI
    • 1.3.2.2 Dashboard UI
    • 1.3.2.3 Course UI
    • 1.3.2.4 Assignment UI
    • 1.3.2.5 Forum UI

• 1.4 Testing

  • 1.4.1 Unit Testing
  • 1.4.2 Integration Testing
  • 1.4.3 User Acceptance Testing
  • 1.4.4 Performance Testing

• 1.5 Deployment

  • 1.5.1 Server Configuration
  • 1.5.2 Application Deployment
  • 1.5.3 Go-Live Support

• 1.6 Documentation

  • 1.6.1 Technical Documentation
  • 1.6.2 User Manuals
  • 1.6.3 Project Report

7.2 Gantt Chart

Gantt Chart Description

The project schedule is represented as a Gantt Chart, which provides a visual timeline of project activities showing their start dates, durations, and dependencies.

Project Timeline: January 1 - March 31 (13 weeks)

Week	Dates	Major Activities
Week 1	Jan 1-7	Project kickoff, Requirements gathering, Environment setup
Week 2	Jan 8-14	Sprint 1: Authentication development, Database design
Week 3	Jan 15-21	Sprint 2: Course management backend development
Week 4	Jan 22-28	Sprint 2: Course management frontend, Content upload
Week 5	Jan 29-Feb 4	Sprint 3: Assignment submission backend
Week 6	Feb 5-11	Sprint 3: Assignment grading, Gradebook
Week 7	Feb 12-18	Sprint 4: Discussion forums development
Week 8	Feb 19-25	Sprint 4: Notification system development
Week 9	Feb 26-Mar 4	Sprint 5: UI polish, Performance optimisation
Week 10	Mar 5-11	Sprint 5: Responsive design refinement, Bug fixes
Week 11	Mar 12-18	Sprint 6: Testing, Server setup
Week 12	Mar 19-25	Sprint 6: Deployment, UAT
Week 13	Mar 26-31	Documentation, Project handover, Closure

Critical Path:

The critical path represents the longest sequence of dependent activities that determines the minimum project duration:

Requirements → Database Design → Backend Authentication → Course Management → Assignment System → Testing → Deployment

Any delay in critical path activities directly impacts the project completion date.

Dependencies:

Activity	Depends On
Backend Development	Database Design
Frontend Development	UI/UX Wireframes
Integration Testing	Unit Testing Complete
UAT	Integration Testing Complete
Deployment	All Testing Complete

Milestones:

Milestone	Target Date	Deliverable
M1: Foundation Complete	January 14	Working authentication system
M2: Core Features Complete	January 28	Course management functional
M3: Assignment System Complete	February 11	Assignment workflow complete
M4: All Features Complete	February 25	Forums and notifications ready
M5: Testing Complete	March 18	All tests passed
M6: Go-Live	March 25	Production deployment
M7: Project Closure	March 31	Documentation complete

7.3 Risk Management Plan

Risk Register

ID	Risk	Probability	Impact	Risk Score	Owner
R-01	API integration delays	High	Medium	12	Lead Developer
R-02	Scope creep	High	High	16	Project Manager
R-03	Developer illness	Medium	High	12	Project Manager
R-04	Budget reduction	Medium	High	12	Project Manager
R-05	Technical complexity	Medium	Medium	9	Lead Developer

Risk Response Strategies

R-01: API Integration Delays

Response Strategy: Mitigation

• Start API integration early in the project
• Use abstraction layers for easy provider switching
• Identify backup service providers
• Build in buffer time for integration work

R-02: Scope Creep (Video Conferencing Request)

Response Strategy: Accept (defer)

When stakeholders requested video conferencing functionality during Sprint 3, the following process was followed:

1. Acknowledged Request: The value of video conferencing was recognised
2. Impact Analysis: Estimated 4-6 weeks additional development, additional cost for real-time infrastructure
3. Decision: Feature deferred to Phase 2
4. Communication: Stakeholders informed with explanation of trade-offs
5. Documentation: Feature added to future enhancement backlog with architecture notes

Formal Response to Stakeholder: "We appreciate this suggestion and agree that video conferencing would add significant value to EduLearn. After careful analysis, implementing this feature would require additional development time (4-6 weeks) and infrastructure investment that would extend our timeline beyond March 31. We recommend documenting this as a priority Phase 2 feature and designing the current architecture to accommodate future integration. In the interim, we can provide integration with existing tools like Zoom or Google Meet through embedded links."

R-03: Developer Illness/Unavailability

Response Strategy: Mitigation + Contingency

Preventive measures:

• Cross-training team members
• Paired programming for critical components
• Comprehensive documentation requirements
• Code review ensuring knowledge sharing

Contingency plan (if developer becomes unavailable):

1. Immediately assess impact on current sprint
2. Identify critical tasks assigned to unavailable developer
3. Redistribute tasks based on skills and capacity
4. Adjust sprint scope if necessary
5. Communicate revised expectations to stakeholders
6. For extended absence (>1 week), evaluate engaging temporary contractor

Resource Reallocation Example:

If Developer 3 becomes unavailable during Sprint 3:

Task	Original Assignee	New Assignee	Adjustment
Student dashboard	Developer 3	Developer 1	Extend by 2 days
Enrolment flow	Developer 3	Developer 4	Reduce scope
Bug fixes	Developer 3	Developer 5	Prioritise critical only

Sprint scope reduced by removing lower-priority items; stakeholders informed of impact.

R-04: Budget Cut

Response Strategy: Contingency plan prepared

See Section 7.5 for detailed handling of 20% budget reduction scenario.

Risk Monitoring

Risks were reviewed weekly during team meetings with updates to probability, impact, and mitigation status.

7.4 Resource Management

Team Structure and Allocation

Role	Name	Allocation	Primary Responsibilities
Project Manager	PM	100%	Planning, coordination, stakeholder management
Lead Developer	Dev 1	100%	Architecture, code review, backend development
Backend Developer	Dev 2	100%	Backend development, API design
Backend Developer	Dev 3	100%	Backend development, database design
Frontend Developer	Dev 4	100%	Frontend development, UI implementation
Frontend Developer	Dev 5	100%	Frontend development, testing
UI/UX Designer	Designer	100%	User interface design, user research

Resource Calendar

Standard working hours: 9:00 AM - 5:00 PM, Monday - Friday (8 hours/day) Total available hours per sprint (2 weeks): 80 hours per team member

Capacity Planning

Sprint	Total Capacity (hours)	Allocated (hours)	Buffer (hours)
Sprint 1	560	504	56 (10%)
Sprint 2	560	504	56 (10%)
Sprint 3	560	504	56 (10%)
Sprint 4	560	504	56 (10%)
Sprint 5	560	504	56 (10%)
Sprint 6	560	480	80 (14%)

Note: Sprint 6 has increased buffer to accommodate deployment uncertainties.

7.5 Budget Management and Client Communication

Budget Allocation

Total Budget: Five Million Naira

Category	Allocation	Percentage
Personnel	3,500,000	70%
Infrastructure and Hosting	600,000	12%
Software and Tools	400,000	8%
Contingency	500,000	10%
Total	5,000,000	100%

Handling 20% Budget Cut Scenario

Scenario: During Week 4 of the project, the university finance department informs the project team that due to budget constraints, the project budget will be reduced by 20% (1,000,000 Naira), leaving a remaining budget of 4,000,000 Naira.

Impact Analysis:

Category	Original	Revised	Reduction
Personnel	3,500,000	2,800,000	700,000
Infrastructure	600,000	500,000	100,000
Software	400,000	350,000	50,000
Contingency	500,000	350,000	150,000
Total	5,000,000	4,000,000	1,000,000

Response Strategy:

1. Scope Reduction:

   • Discussion forum moderation features reduced (Priority: Low → Deferred)
   • Advanced analytics deferred to Phase 2
   • Email notification preferences simplified

2. Resource Adjustment:

   • UI/UX Designer reduced to 50% allocation after Sprint 3
   • One developer assigned to 80% allocation for final sprints

3. Infrastructure Optimisation:

   • Selected smaller initial server configuration with scaling capability
   • Deferred CDN implementation to Phase 2

4. Timeline Maintained:

   • Core features and timeline preserved
   • Reduced polish and optimisation in Sprint 5

---

Professional Client Email: Budget Cut Communication

To: Vice Chancellor, [University Name]

Cc: Director of ICT, Bursar

From: [Project Manager Name], EduLearn Project Manager

Date: January 22, 2026

Subject: EduLearn LMS Project - Response to Budget Revision

---

Dear Vice Chancellor,

RE: EDULEARN LMS PROJECT - BUDGET ADJUSTMENT RESPONSE

Thank you for the communication regarding the revised budget allocation for the EduLearn Learning Management System project. We understand that institutional financial constraints necessitate careful resource management, and we are committed to delivering maximum value within the adjusted parameters.

Acknowledgement of Budget Revision

We acknowledge the budget reduction from Five Million Naira to Four Million Naira, representing a 20% decrease. We have conducted a thorough impact analysis and developed a revised project plan to accommodate this change while preserving the core objectives of the project.

Revised Project Scope

To operate within the revised budget while maintaining our commitment to delivering a functional, high-quality Learning Management System by March 31, we propose the following adjustments:

Core Features (Preserved):

• User authentication and management (Students, Lecturers, Administrators)
• Course creation, management, and enrolment
• Assignment submission and grading with feedback
• Basic discussion forums for collaborative learning
• Essential notification system (in-app and email for critical events)

Deferred Features (Phase 2):

• Advanced forum moderation tools
• Detailed analytics dashboards
• Customisable notification preferences
• Performance optimisation enhancements

Resource and Infrastructure Adjustments:

• Optimised team allocation in later project phases
• Right-sized initial infrastructure with scaling capability
• Streamlined UI polish scope

Timeline Commitment

We remain committed to the March 31 delivery date. The adjusted scope has been carefully designed to be achievable within this timeline and the revised budget.

Impact on Deliverables

The core user experience and essential functionality will be delivered as originally planned. Users will be able to access courses, submit assignments, receive grades, and participate in discussions. The deferred features, while valuable, are enhancements that can be implemented in a subsequent phase when additional funding becomes available.

Recommendation

We recommend proceeding with the revised scope as outlined above. Additionally, we suggest scheduling a Phase 2 planning session in April to prioritise the deferred features for future implementation.

We request your formal approval of this revised scope to proceed with the adjusted plan. Please do not hesitate to contact me should you require any clarification or wish to discuss alternative approaches.

We remain committed to delivering a system that will significantly enhance the learning experience for students and lecturers at [University Name].

Yours faithfully,

[Project Manager Name]

Project Manager, EduLearn LMS Project

Email: [email]

Phone: [phone number]

Attachments:

• Revised Budget Breakdown
• Adjusted Feature Matrix
• Updated Project Schedule

---

CHAPTER EIGHT: CONCLUSION AND RECOMMENDATIONS

8.1 Summary of Achievements

The EduLearn Learning Management System project has successfully achieved its primary objectives within the specified constraints of time, budget, and resources. The following summarises the key accomplishments:

Technical Achievements

Functional System Delivery: A fully functional Learning Management System was developed and deployed, incorporating all core features:

• Secure user authentication with role-based access control
• Comprehensive course management with modular content organisation
• Assignment submission and grading workflow with feedback mechanism
• Discussion forums enabling collaborative learning
• Real-time notification system for user engagement

Quality Implementation:

• Clean, maintainable codebase following industry best practices
• Comprehensive test coverage ensuring reliability
• Responsive design functioning across desktop and mobile devices
• Security measures protecting user data and system integrity

Technical Infrastructure:

• Scalable cloud-based hosting infrastructure
• Automated deployment pipeline ensuring consistent releases
• Monitoring and alerting systems for proactive issue detection

Project Management Achievements

Schedule Performance: The project was completed within the three-month timeline, meeting the March 31 deadline. All major milestones were achieved on or before their target dates.

Budget Performance: The project was delivered within the revised budget of Four Million Naira, demonstrating effective resource management and prioritisation when faced with budget constraints.

Scope Management: Core project scope was preserved despite budget reduction. Scope creep was effectively managed through formal change control processes, with enhancement requests documented for future phases.

Team Collaboration: The Agile methodology facilitated effective team collaboration, with regular communication ensuring alignment and rapid problem resolution. Knowledge sharing through pair programming and code reviews built team capability.

Stakeholder Outcomes

For Students: Students now have access to a modern, user-friendly platform for accessing learning materials, submitting assignments, and engaging with lecturers and peers.

For Lecturers: Lecturers have tools to efficiently manage courses, grade assignments, and communicate with students, reducing administrative burden.

For the Institution: The university now possesses a custom-built LMS solution tailored to its needs, positioning it as a technology-forward institution.

8.2 Limitations

While the project achieved its core objectives, several limitations should be acknowledged:

Technical Limitations

Offline Access: The current implementation requires internet connectivity for all operations. Users in areas with unreliable connectivity may experience difficulties accessing the platform.

Mobile Native Applications: The system is accessible via mobile browsers but does not include dedicated iOS or Android applications. Native apps would provide improved user experience and push notification capabilities.

Integration Limitations: The initial release does not include integration with existing university systems such as student information systems or examination management platforms.

Scalability Testing: While the architecture supports scaling, testing was limited to 500 concurrent users. Performance at higher loads remains unvalidated.

Functional Limitations

Video Conferencing: Live video conferencing was excluded from scope due to budget and timeline constraints. Users must rely on external tools for synchronous online sessions.

Advanced Assessment Types: The current assignment system supports file submission. Advanced assessment types such as quizzes, timed tests, and automated grading are not yet implemented.

Learning Path Customisation: The platform does not currently support personalised learning paths or adaptive learning based on student performance.

Process Limitations

User Training: Limited time was allocated for end-user training. Comprehensive training programmes would enhance user adoption and effective utilisation of platform features.

Documentation: While functional documentation was provided, extensive administrator and developer documentation could be improved.

8.3 Future Enhancements

Based on project experience, stakeholder feedback, and analysis of industry trends, the following enhancements are recommended for future development phases:

Priority 1: Near-Term Enhancements (Phase 2)

Enhancement	Description	Estimated Effort
Video Conferencing Integration	Embed third-party video tools (Zoom, Google Meet)	4 weeks
Advanced Analytics	Detailed engagement and performance dashboards	3 weeks
Mobile Applications	Native iOS and Android apps	8 weeks
Quiz Module	Multiple choice, true/false, short answer assessments	4 weeks
Notification Preferences	User-configurable notification settings	2 weeks

Priority 2: Medium-Term Enhancements (Phase 3)

Enhancement	Description
Student Information System Integration	Synchronise student data with university SIS
SCORM/xAPI Support	Import and track standardised e-learning content
Calendar Integration	Sync deadlines with Google Calendar, Outlook
Accessibility Improvements	WCAG 2.1 AAA compliance
Multi-language Support	Hausa, Yoruba, Igbo language options

Priority 3: Long-Term Vision

• AI-Powered Features: Automated grading assistance, plagiarism detection, personalised learning recommendations
• Virtual Reality Integration: Immersive learning experiences for practical subjects
• Blockchain Credentials: Verifiable digital certificates and transcripts
• Advanced Proctoring: Secure online examination with identity verification

Recommendations for Future Development

1. Establish Dedicated Support Team: Assign staff for ongoing maintenance, user support, and incremental improvements

2. Conduct Regular User Research: Gather feedback from students and lecturers to guide feature prioritisation

3. Maintain Technology Currency: Regularly update dependencies and frameworks to ensure security and performance

4. Expand Training Programmes: Develop comprehensive training materials and conduct regular workshops

5. Plan for Scale: Monitor usage growth and proactively scale infrastructure before capacity limits are reached

6. Security Audits: Conduct annual third-party security assessments to identify and address vulnerabilities

---

REFERENCES

Alexander, I. F., and Beus-Dukic, L. (2009). Discovering requirements: How to specify products and services. Wiley.

Aldiab, A., Chowdhury, H., Kootsookos, A., Alam, F., and Allhibi, H. (2019). Utilization of Learning Management Systems (LMSs) in higher education system: A case review for Saudi Arabia. Energy Procedia, 160, 731-737.

Bandura, A. (1977). Social learning theory. Prentice Hall.

ISO/IEC 25010. (2011). Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models. International Organization for Standardization.

Jonassen, D. H. (1999). Designing constructivist learning environments. In C. M. Reigeluth (Ed.), Instructional-design theories and models: A new paradigm of instructional theory (Vol. II, pp. 215-239). Lawrence Erlbaum Associates.

Moodle. (2023). Moodle Statistics. Retrieved from https://stats.moodle.org/

Mtebe, J. S. (2015). Learning Management System success: Increasing Learning Management System usage in higher education in sub-Saharan Africa. International Journal of Education and Development using Information and Communication Technology, 11(2), 51-64.

Pappas, C. (2019). The history and evolution of Learning Management Systems. eLearning Industry. Retrieved from https://elearningindustry.com/

PMI (Project Management Institute). (2017). A guide to the Project Management Body of Knowledge (PMBOK Guide) (6th ed.). Project Management Institute.

Schwaber, K., and Sutherland, J. (2020). The Scrum Guide: The definitive guide to Scrum: The rules of the game. Scrum.org.

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

Turnbull, D., Chugh, R., and Luck, J. (2019). Learning Management Systems: An overview. In A. Tatnall (Ed.), Encyclopedia of Education and Information Technologies. Springer.

Zimmerman, B. J. (2002). Becoming a self-regulated learner: An overview. Theory into Practice, 41(2), 64-70.

---

END OF REPORT

---

Document prepared by [Student Name]

Date: March 2026

Word Count: Approximately 12,000 words