
/ 5 min read
Group Decision Support System for Retail Product Sales
Project Metadata
Overview of the project context, scope, and tech choices.
Overview
- Role
- Full Stack Developer
- Client
- Undergraduate Final Project
- Type
- Web Application
- Industry
- Retail / Decision Science
- Platform
- Web
- Duration
- -
Description
A web-based decision support system using Fuzzy Logic, EDAS, and Borda methods to assist minimarket operators in evaluating, ranking, and grouping retail product alternatives based on defined criteria.
Key Features
- • Multi-method Decision Analysis (Fuzzy Logic + EDAS + Borda)
- • Product Alternative Ranking
- • Group Decision Aggregation
- • Export to PDF & Excel
- • Print-ready Report View
- • Method Accuracy Testing
Tech Stack
This was my undergraduate thesis, the point where academic research and practical engineering had to meet. The challenge was unique: not just building something that works, but building something that is scientifically accountable, with validated methods and results that can be empirically tested for accuracy.
Problem Domain: Group Decision-Making in Retail
Minimarket owners frequently face a classic dilemma: which products are worth stocking, which should be reduced, and how should that decision be made when multiple stakeholders, such as the owner, operations manager, and warehouse lead, each have different preferences?
A Group Decision Support System (GDSS) addresses this by aggregating preferences from multiple decision-makers into a single objective, structured recommendation. The academic novelty of this project is the combination of three methods: Fuzzy Logic to handle preference ambiguity, EDAS for alternative evaluation, and Borda for group decision aggregation.
Why Three Methods Combined?
This question is the intellectual core of the thesis contribution.
Fuzzy Logic addresses the fact that human preferences are rarely binary. When a manager says a product’s sales are “decent,” that’s an inherently ambiguous linguistic statement. Fuzzy Logic converts these linguistic assessments into numeric values using membership functions:
Membership function for "Sales Performance": - Very Poor → [0, 0, 1, 2] - Poor → [1, 2, 3, 4] - Fair → [3, 4, 5, 6] - Good → [5, 6, 7, 8] - Very Good → [7, 8, 10, 10]Once preferences are fuzzified, EDAS (Evaluation based on Distance from Average Solution) calculates a score for each product alternative. EDAS considers both positive and negative distances from the average solution per criterion, making it more nuanced than simpler methods like SAW that only sum weighted scores.
Borda then aggregates the individual rankings from each decision-maker into a single group ranking. The Borda method is simple but proven: each decision-maker assigns points based on their preference order, and points are summed to produce a group consensus.
Implementing the Algorithms in PHP
Translating mathematical algorithms into PHP without a numerical library like NumPy was a genuinely interesting constraint. All calculations are done manually: matrix operations, normalization, and weighted summation, all written as pure PHP methods.
// EDAS calculationpublic function calculateEdas($matrix, $weights, $types){ $averageSolution = $this->calculateAverageSolution($matrix); $pda = []; $nda = [];
foreach ($matrix as $i => $alternative) { foreach ($alternative as $j => $value) { $avg = $averageSolution[$j]; if ($types[$j] === 'benefit') { $pda[$i][$j] = max(0, ($value - $avg) / $avg); $nda[$i][$j] = max(0, ($avg - $value) / $avg); } else { // cost criterion $pda[$i][$j] = max(0, ($avg - $value) / $avg); $nda[$i][$j] = max(0, ($value - $avg) / $avg); } } }
// Weighted sum → normalization → final score return $this->computeFinalScore($pda, $nda, $weights);}Each method is implemented as a separate class with a consistent interface, making individual testing straightforward and integration into the overall pipeline clean.
CodeIgniter MVC Architecture
The project uses CodeIgniter 3 with a strict MVC pattern. Choosing this classic PHP framework wasn’t arbitrary. In an academic environment, available hosting infrastructure is often limited to shared hosting with standard PHP, with no support for modern runtimes like Node.js.
application/ ├── controllers/ │ ├── Dashboard.php │ ├── Alternative.php → CRUD product alternatives │ ├── Criteria.php → Manage evaluation criteria │ ├── Assessment.php → Input scores per decision-maker │ └── Calculation.php → Trigger & display method results ├── models/ │ ├── Fuzzy_model.php │ ├── Edas_model.php │ └── Borda_model.php └── views/ └── (Server-side rendering with Bootstrap)CodeIgniter Views with Bootstrap produce responsive pages by default with no separate frontend build step, a sensible trade-off for an academic project with time constraints.
Export & Reporting Features
A practical requirement of this system is the ability to generate reports suitable for meetings or archiving. I implemented three output modes:
- PDF via DOMPDF: Renders an HTML view to PDF entirely on the server, with no client-side library dependency
- Excel via PHPSpreadsheet: Exports calculation results in a tabular format that stakeholders can process further
- Print view: An HTML version optimized for printing with
@media printCSS rules
DOMPDF has limitations with complex CSS, so I built a dedicated PDF template using inline CSS and table-based layout, an old approach but one that remains reliably consistent across rendering environments.
Accuracy Testing of the Methods
One of the academic requirements that sets this apart from a standard web application is empirical accuracy testing. The system’s output must be compared against a ground truth, in this case, actual sales data from a partner minimarket used as a benchmark.
Testing methodology:
- Collect 6 months of historical sales data
- Run the data through the system
- Compare the system’s product ranking against rankings derived from actual sales figures
- Calculate agreement using Spearman Rank Correlation
Results showed a significant correlation between the system’s recommendations and actual product performance, providing empirical validation that the chosen combination of methods is relevant and applicable to this domain.
Reflections
This project taught something that can’t be measured in lines of code: the ability to translate mathematical concepts into a system that real people can actually use. The gap between a formula in an academic paper and a working implementation in a browser is enormous, and bridging that gap was where most of the time went.
I also learned that user research is part of engineering. Several times I had to change how the system presented its results because users, particularly minimarket owners, were unfamiliar with technical terminology like “EDAS score.” They just needed to know: which product is recommended, and why?
This project shaped my belief that good software isn’t only software with correct algorithms, it’s software that can be understood and used by the people who actually need it.