Skip to content

MVP Report

mustafaozturkmen edited this page Apr 11, 2026 · 3 revisions

MVP Report

This page gathers all the artifacts delivered for the MVP milestone of the Local History Story Map project.


Software Requirements Specification


Software Design (UML Diagrams)

Class Diagram

Use Case Diagrams

Sequence Diagrams


Scenarios and Mockups


Project Plan, Communication Plan, Responsibility Assignment Matrix

Responsibility Assignment Matrix

Team Member Frontend Backend DevOps
Akif Emre Biçen X
Furkan Kaan Biçer X X
Beyza Nur Deniz X
İbrahim İlter X
Muhammed Efe Özavcı X
Muhammed Mustafa Öztürkmen X X
Enes Hamza Üstün X
Alper Vural X

Pre-release Version of Software


D6. Milestone Review

D6.1 Project Status

All requirements planned for the MVP milestone were successfully implemented and delivered on time. The team was able to cover the full scope of the MVP without dropping any planned features.

Key reflections from the milestone review:

  • Communication within the team had gaps, progress updates and blockers were not always shared promptly, which created coordination overhead.
  • Implementation was started relatively late in the sprint, which added unnecessary pressure toward the deadline. The team managed to deliver, but the late start increased stress and left less room for testing and refinement.

D6.2 Deliverables

# Requirement Deliverable Status
1 1.1.1 Media upload from device gallery (photo, video, audio) Completed
2 1.1.2 Location pinning on interactive map Completed
3 1.1.3 Story creation workflow (post button, location, time range, text, submission, confirmation) Completed
4 1.1.4 User registration and login Completed
5 1.1.6.1 Search stories by place name Completed
6 1.2.2.1, 1.2.2.3, 1.2.2.4 Stories mapped to coordinates, marker info preview, zoom controls Completed
7 1.2.4.1, 1.2.4.1.1, 1.2.4.2 Secure auth mechanism, unique email addresses, auth/unauth differentiation Completed
8 1.2.4.1.2 Email confirmation Not Implemented
9 1.2.5 Content upload restricted to authenticated users only Completed
10 1.2.6 Unauthenticated users blocked from interactions Completed
11 1.2.7 Post data persistence and cloud media storage (MinIO) Completed
12 2.1.1 Responsive UI layout Completed
13 2.2.1 Web (Chrome) and Android platform compatibility Completed
14 Containerized deployment (Docker / docker-compose) Completed
15 CI/CD pipeline (GitHub Actions) Completed

Reflection:

All planned MVP deliverables were completed and the demo was successful. The pre-MVP (Demo Review) milestone revealed that the frontend was not fully wired to the backend at that point, which created a compressed push in the final stretch. The team managed to close all gaps before the MVP demo, but the late start on implementation left limited time for thorough testing. Going forward, starting integration work earlier will help avoid this pattern.

D6.3 Requirements

The following requirements were addressed in the MVP milestone.

Functional — User Requirements

Requirement Description Status
1.1.1 Media Recording & Ingestion — upload pre-recorded photos, videos, and audio from device gallery Addressed
1.1.2 Geospatial-Temporal Mapping — drag and interact with map to pin story location Addressed
1.1.3 Workflow & Moderation — create post via button, fill location/time/text, submit, see confirmation Addressed
1.1.4 Authentication & Authorization — register with username/email/password, login Addressed
1.1.6.1 Filtering Results — search places by name Addressed

Functional — System Requirements

Requirement Description Status
1.2.2.1 Map every story to a geospatial coordinate (lat/lng) Addressed
1.2.2.3 Display a preview of information associated with a map marker Addressed
1.2.2.4 Support zoom-in and zoom-out on the map Addressed
1.2.4.1 Provide a secure user authentication mechanism (register & login) Addressed
1.2.4.1.1 Email addresses shall be unique Addressed
1.2.4.1.2 Email addresses shall be confirmed Not Addressed
1.2.4.2 Differentiate between authenticated and unauthenticated users Addressed
1.2.5 Allow only authenticated users to upload content; block unauthenticated uploads Addressed
1.2.6 Prevent unauthenticated users from posting comments or liking content Addressed
1.2.7 Store posts with creator identity, enforce required fields, persist to database, store media in cloud Addressed

Non-Functional Requirements

Requirement Description Status
2.1.1.1 UI must automatically adjust to device screen size and orientation Addressed
2.2.1.1 Responsive web app (Chrome) and Android mobile app Addressed

D6.4 Testing

D6.4.1 Test Plan & Strategy

The project follows a layered testing strategy across backend and frontend. Tests are run automatically on every push and pull request via GitHub Actions CI.

Backend — pytest (Python)

Three layers run sequentially in CI, each layer depends on the previous passing:

Layer Location What is tested
Unit backend/tests/unit/ JWT token creation, password hashing, password strength validation, request/response schemas (user register, login, story date validation, date range filter), story service logic (list, search, upload media, get detail, create, update)
Integration backend/tests/integration/ End-to-end auth flow (register → login → token use), story time filter flow against a real PostgreSQL database
API backend/tests/api/ HTTP-level tests for registration, login, token verification, story listing, media upload, story detail, story creation, and story update endpoints

CI pipeline order: health check (DB + MinIO + backend) → unit tests → integration tests → API tests.

Frontend — Jest (JavaScript, jsdom)

Unit tests cover the auth utility module and key page logic:

Test file What is tested
auth.test.js Token storage/retrieval, isLoggedIn, logout, authFetch with/without token, requireAuth redirect
login.test.js handleLogin success/failure/empty-fields, redirect to map, form setup
profile.test.js loadProfile unauthenticated guard, 401 handling, DOM population
edit-profile.test.js loadEditProfile unauthenticated guard, form population, submit handler, setup

Note: Frontend unit tests are not yet wired into the CI pipeline — the CI step is a placeholder (echo "test"). Tests pass locally via npm test.

Mobile (Android)

Only Capacitor boilerplate tests exist (ExampleUnitTest, ExampleInstrumentedTest). No application-level tests have been written for the mobile app yet. The CI pipeline builds and uploads the Android debug APK but does not run tests.

D6.4.2 Test Execution Reports

Backend API: HTML Report | XML

Web App: HTML Report | XML

Mobile App: Not Implemented

D6.4.3 Impact Analysis

Coverage:

  • Backend coverage is solid across the three layers — auth and story are the two core resources and both have unit, integration, and API-level tests. Factory classes (user, story, media file) are also unit-tested.
  • Frontend coverage is partial — auth utility and login/profile pages are tested, but story creation, map, and search pages have no tests yet.
  • Mobile has no meaningful test coverage beyond the Capacitor boilerplate.

Bug Detection:

  1. Integration tests run against a real PostgreSQL database, which catches SQL query and schema issues that unit tests with mocks would miss.
  2. API-level tests exercise the full request/response cycle including serialization, validation errors, and auth guards, which catches contract bugs early.

Readiness:

Backend is at a reasonable level of test readiness for MVP. Frontend test coverage is insufficient — key user-facing flows (story creation, map interaction, search) are untested. Mobile has no coverage. For the next milestone, frontend tests should be wired into CI and coverage should be extended to the remaining pages.

D6.5 Planning and Team Process

Process description:

The team held weekly meetings every Saturday at 12:00 via Google Meet. Each meeting followed a fixed agenda: reviewing the previous week, unblocking carry-over tasks, collecting availability from each member, planning the upcoming week based on that availability, and an open discussion slot. Task assignments were tracked via GitHub Issues.

Communication ran on two levels: a WhatsApp main group for day-to-day updates across the whole team, and separate subgroup chats (Frontend, Backend, DevOps) for focused technical discussion. A key norm was that whenever a team member made a change to the codebase, they shared a brief update in the main group so everyone stayed informed.

Evaluation:

  • What went well: The communication structure worked — day-to-day WhatsApp updates and weekly meetings kept the team in sync, and documenting changes in the group made handoffs easier. All MVP requirements were ultimately delivered on time.
  • What needs improvement: Progress updates and blockers were not always raised promptly; some members waited until the weekly meeting rather than posting when an issue arose. Implementation also started later than ideal, which compressed the workload toward the deadline and increased stress — the team finished, but with less time for testing and polish than intended. The previous milestone also surfaced that exam periods were not factored into task planning, which should be corrected going forward.

Action items for the next milestone:

  • Raise blockers and progress updates in the WhatsApp group immediately — do not hold them for the weekly meeting.
  • Start implementation tasks earlier in the sprint to keep the workload evenly distributed.
  • Estimate each member's exam and coursework load before assigning tasks so that heavy exam weeks are accounted for in the plan.

Links:


D7. Individual Contributions

See the full breakdown on the Individual Contributions page.

Team Members

Milestones


Lab Reports


Weekly Meetings

Other Meetings


Templates

Scenarios

Use Case Diagrams

Class Diagram

Sequence Diagrams

Requirements


Implementation

Clone this wiki locally