-
Notifications
You must be signed in to change notification settings - Fork 1
[OLD] Milestone Report
NutriHub is a web + mobile platform that enables users to
- compare grocery prices at nearby markets;
- create cost-effective, balanced meal plans;
- explore a nutrition-scored database of multiple food items;
- exchange recipes and dietary advice in a community forum.
| Deliverable | Status |
|---|---|
| Requirements Specification | ✅ Complete |
| Use-Case Diagrams | ✅ Complete |
| Class Diagrams | ✅ Complete |
| Sequence Diagrams | ✅ Complete |
| Live Demo | ✅ Complete |
| Demonstration Video (3–5 min) | ✅ Complete |
- Technology Stack: React (web), React Native (mobile), Django REST, MySQL
- Nutrition-Score Algorithm: 0–10 = 0.30 × protein + 0.30 × carb-quality + 0.40 × nutrient-balance
- Data Source: FatSecret API (scraped & manually validated);
- DevOps: GitFlow branching, Docker Compose, GitHub Actions CI, DigitalOcean for production preview
- Collaboration: Issue templates, Github Project, weekly asynchronous stand-ups, minutes archived in Wiki
| Challenge | Mitigation |
|---|---|
| Academic Boycott | Our regular progress and meetings were halted for almost 3 weeks due to the academic boycott that started in mid-March, which tightened our timeline. After the boycott ended, we quickly assessed remaining tasks, reorganized our schedule, and increased productivity to compensate for lost time. |
| Istanbul Earthquake (April 23) | Several team members had to relocate and experienced decreased motivation following this traumatic event. We postponed our deadline and modified deliverables—sharing a report instead of conducting a live meeting—allowing team members to prioritize wellbeing while maintaining project momentum. |
| Lack of Experience | Some of the team members lacked experience with projects of this scale and were unfamiliar with the required tech stack. We divided into three sub-teams (frontend, backend, mobile), each led by a member with relevant prior experience who distributed tasks and provided guidance through tutorials and example implementations. This mentorship system allowed efficient progress through the learning stage without losing focus. |
| Limited Implementation Time | When starting implementation, we faced significant time constraints. We developed a phased approach that prioritized frontend development first with more team members assigned to it, letting mobile development follow behind. This reduced development complexity when adapting features, as we only needed to focus on frontend changes. Once frontend reached desired quality, we redistributed team members to mobile development, maintaining progress across all fronts despite the compressed timeline. |
Check out our project roadmap for a chronological view of all scheduled issues.
Milestone 1 (April 25, 2025)
Present the requirements and initial design of the application to the customer. Demonstrate a basic version of the application with partial feature implementation to gather early feedback.
- Complete requirements and design related documentation
- Learn the basics of backend, frontend and mobile development
- Set up the skeleton of the implementation
- Requirements Specification Document
- Scenarios
- Use Case Diagrams
- Class Diagrams
- Sequence Diagrams
Achievements
Visit [Milestone 1](https://github.com/bounswe/bounswe2025group9/milestone/1?closed=1) to view related issues and PRS. - Formulated and conducted **elicitation questions** to understand stakeholder needs. - Researched and selected appropriate communication platforms for team collaboration. - Established a **contribution guide** detailing coding standards and workflow processes. - Documented detailed functional and non-functional requirements for the system. - Developed a comprehensive **glossary** of project-specific terms and definitions. - Created a complete **Software Requirements Specification (SRS)** document. - Designed comprehensive **use case diagrams** illustrating system interactions. - Designed **class diagrams** representing the system's architecture and relationships. - Created **visual mockups** of the user interface for key application screens. - Developed detailed **scenarios** describing typical user interactions with the system. - Designed and implemented **initial frontend page** layouts and components. - Set up the **basic mobile application environment** and development workflow. - Implemented a **testing structure for frontend components** and functionality. - Created and documented **mock APIs** for development and testing purposes. - Completed the **MySQL database migration** for persistent data storage. - Established the base structure for the **backend API architecture**. - Implemented core **login and signup** functionality in the backend. - **Researched containerization** methods and deployment strategies using Docker.Milestone 1.5 (May 11, 2025)
Speed up implementations and retain momentum lost due to unexpected events. Implement the selected subset of requirements planned for Milestone 2.
- Determine and implement backend endpoints required for milestone requirements
- Start integration of endpoints to frontend and mobile
- Research deployment of website and mobile APK release
Achievements
Visit [Milestone 1.5](https://github.com/bounswe/bounswe2025group9/milestone/3?closed=1) to view related issues and PRS. - Bootstrapped the backend forum application with essential structure and core functionality. - Implemented **common API endpoints** and established connections with the frontend application. - Added a comprehensive **nutrition scoring system to the database** for food item evaluation. - Developed backend support for tagging posts with relevant categories and keywords. - Instantiated the native Django **administrative panel** for system management and content moderation. - Implemented **backend pagination** to improve performance when displaying large data sets.Milestone 2 (May 14, 2025)
Final stage of the project for the semester. Implement selected requirements and present a populated, functional demo to demonstrate system capabilities.
- Implement any missing endpoints and integrate with frontend and mobile
- Deploy the application and release mobile APK
- Populate the database with real-world data
- Final Milestone Report
- Project Repository (including Issues, Wiki, and implementation)
- Live Demo with Sample Data
Achievements
Visit [Milestone 2](https://github.com/bounswe/bounswe2025group9/milestone/2) to view related issues and PRS. - **Refactored** the entire codebase to improve structure, enhance reusability, and maintain consistency. - Successfully **integrated backend endpoints** with both frontend and mobile applications. - **Populated the food database** with comprehensive and accurate nutritional information. - Created a Dockerfile for **containerized deployment** to simplify installation and scaling. - Developed** recipe models** in the backend and integrated recipe functionality with the frontend. - Generated and tested a deployable **APK package** for the mobile application. - Established **consistent styling** guidelines and implementation across web frontend and mobile interfaces. - Ensured functional consistency and feature parity between web and mobile platforms.1.1. Food Database
- 1.1.1 The system shall include a list of at least 500 common food items with nutritional details, including protein, fat, and caloric content.
-
1.1.3 The system shall calculate and display a nutrition score (scale of 0.00-10.00) for each food item based on:
- Protein content (30% of score)
- Carbohydrate quality (30% of score, favoring complex carbs over simple sugars)
- Nutrient balance (40% of score, representing the overall balance of macro and micronutrients)
-
1.1.4 (If possible, a subset) The system shall support the following dietary options:
- a) Low-fat
- b) High-protein
- c) Vegetarian
- d) Vegan
- e) Celiac-friendly
- f) Gluten-free
- g) Lactose-free
1.4. Forum & Nutrition Tips
- 1.4.1 Posts shall have tags, and the post owners shall be able to edit those tags.
- 1.4.2 Users shall be able to write free-text forum posts.
- 1.4.3 Nutrition tips shall be provided to guide users on healthy eating habits.
- 1.4.4 Users shall be able to browse forum posts.
- 1.4.5 Users shall be able to filter posts by tags and sort them by rating.
-
1.4.6 Users shall be able to interact with forum posts by:
- a) Liking posts
- b) Commenting on posts
- c) Sharing posts via a link
- d) Unliking liked posts
-
1.4.7 Posts can have tags that could be used for filtering:
- a) Dietary tip
- b) Recipe
- c) Meal plan
1.7. Account Management
- 1.7.1 Users shall be able to sign up by giving their email address, choosing a unique username and a secure password.
- 1.7.2 Users shall be able to log in using their username and password.
- 1.7.3 Users shall be able to log out of their account.
| Member | Wiki Page for Personal Contributions |
|---|---|
| Yusuf Akın | Personal Contribution: Yusuf Akın |
| Arda Saygan | Personal Contribution : Arda Saygan |
| Fatih Furkan Bilsel | Personal Contribution Report : Fatih Furkan Bilsel |
| Berk Göktaş | Personal Contribution Report: Berk GOKTAS |
| Berkay Bilen | Personal Contribution: Berkay Bilen |
| Yusuf Anıl Yazıcı | Personal Contribution: Yusuf Anıl Yazıcı |
| Taha Topaloğlu | Personal Contribution: Taha Topaloglu |
| Nuri Başar | Personal Contribution: Nuri Başar |
| Onur Küçük | Personal Contribution: Onur Küçük |
| Hasancan Keleş | Personal Contribution: Hasancan Keles |
| Mete Damar | Personal Contribution: Mete Damar |
We adopted a structured and consistent development process, utilizing GitHub infrastructure, Docker, and pre-commit tooling to manage our team project effectively.
We followed a strict Git strategy:
- No direct pushes to main: All changes were made through feature branches and Pull Requests (PRs).
- Atomic PRs: Each PR addressed a single issue or feature and linked to a corresponding GitHub Issue using Fixes #<issue_number>.
- Linear commit history: Merges used squash or rebase to keep history clean and readable.
- Mandatory PR reviews: Every PR required at least one reviewer familiar with the related module.
Additional conventions we used:
- Branch naming: feat/, fix/, chore/
- Semantic commit messages: feat:, fix:, docs:, refactor:, etc.
- Deleting stale branches after merge
- Well-defined issues: Included deadline, estimated effort, clear description, reproduction steps if applicable, acceptance criteria, single assignee, and appropriate labels (pri:, effort:)
- We used GitHub Issues with templates to standardize and organize tasks and bug reports.
- We used GitHub Discussions to coordinate and record architecture and design decisions.
This allowed for async communication and clearer project direction.
- Pre-commit hook with black for auto-formatting ensured consistent style across the team.
- Postman collection was maintained to document and test backend endpoints.
- Modularized backend using Django REST Framework with separate apps (forum, accounts, foods).
- Fully dockerized backend with a standalone docker-compose file integrating:
- Backend
- Frontend build
- Nginx reverse proxy
This enabled a consistent and reproducible local development setup.
- Frontend used React with TypeScript, bundled via Vite.
- Mobile app was developed using Expo and React Native with TypeScript, simplifying development and testing on mobile devices.
- Git discipline, issue templates, and atomic PRs significantly improved code quality and collaboration.
- Auto-formatting via black reduced noise in commits and kept reviews focused on logic, not style.
- Docker simplified onboarding and local development.
- Maintaining the Postman collection helped backend/frontend integration.
- GitHub Discussions provided a central place for design decisions.
These practices were effective and will be retained, with minor refinements in task tracking and CI planned for future work.
| Artefact | Location |
|---|---|
| Communication Plan | We initially used the GitHub Discussions section to communicate, but soon realized that WhatsApp was more efficient for staying in touch, so we switched to it. For our meetings, we used Slack until our free usage limit was reached, and then we switched to Google Meet |
| Requirements | Requirements |
| Elicitation Questions | Elicitation Questions |
| UML Use Case Diagrams | Use Case Diagrams |
| Class Diagrams | Class Diagrams |
| Sequence Diagrams | Sequence Diagrams |
| Mock-ups & Scenarios | Scenarios |
| Research Notes | Researches Notes |
| Meeting notes | Meetings |
| Web app |
/frontend – live demo at nutrihub.fit
|
| Mobile app |
/mobile – React-Native |
| Backend API |
/backend – Django |
| Demo video | Website and Mobile |
| API Documentation | Swagger API Docs |
Prepared by Group 9 – CMPE 352 Software Engineering, Spring 2025.