Sprint 1 ‐ MVP - JeanCarloLondo/SpectRA GitHub Wiki

Section 1. Executive Summary

Business Model Canvas – SpectRA

Key Partners Key Activities Value Propositions
• University (campus access & building data)
• AR/ML libraries (Unity, TensorFlow Lite)
• Cloud providers (for data hosting)
• Development team (students)
• Develop AR recognition system
• Train ML model on campus buildings
• Build mobile Unity app (Android/iOS)
• Test and improve accuracy
• Maintain dataset of buildings
• Recognize campus buildings in <3s
• Accuracy target >90% (continuous improvement)
• Real-time overlays with building info
• Interactive learning and navigation experience
• Foundation for future AR expansion (3D models, metadata)
Customer Relationships Customer Segments Key Resources
• Intuitive and easy-to-use UI
• Feedback loop for students to report errors
• Continuous updates with new buildings and features
• University visitors (new students, parents, guests)
• Current students exploring campus
• Academic staff (research, teaching tools)
• Unity + C# codebase
• Trained ML model
• Mobile devices with camera
• Building dataset (starting with Block 19)
• GitHub repo & CI/CD pipeline
Channels
• Mobile app (APK distribution initially, later Play Store/App Store)
• University website or internal portals
• Word of mouth within campus community
Section Description
Business Description SpectRA is an innovative project that leverages Augmented Reality (AR) to enhance the university campus experience. By combining AR visualization with real-time information from Firebase, SpectRA allows students and visitors to interact with historical, cultural, and academic points of interest in a dynamic and engaging way. The value proposition lies in making learning and campus exploration both educational and interactive.
Founders / Management Team Although the team does not yet have direct experience with the specific tools being used (Unity, Firebase, ARCore), we bring together diverse strengths and talents that allow us to grow and tackle the challenge effectively. - Scrum Master: Strong leadership skills and ability to work under pressure. - UX Designer: Solid design skills with a focus on usability and user experience. - Programmers: Dedicated and technically capable, committed to learning and applying new technologies. - Beta Tester: Ensures objectivity during testing, avoiding bias and providing valuable feedback. We are students, but we leverage our motivation and capacity to learn as our biggest advantage.
Products / Services The service is an AR-based mobile application that provides: - Real-time visualization of buildings, historical content, and cultural assets. - Authentication and user customization through Firebase. - A unique combination of Unity, ARCore, and Firebase to deliver a seamless and innovative campus AR experience. Differentiator: Unlike static apps, SpectRA brings interactive and immersive AR into everyday academic life.
Target Market The initial market focus is the university community (students, professors, staff, and visitors). Strengths: Innovative AR approach, mobile-first solution, cloud scalability. Weaknesses: High dependency on AR-compatible devices and Firebase services.
Competition There are well-known AR applications in the market, such as Google Lens, Pokémon Go, or IKEA Place, which have shown the potential of AR in different contexts (information retrieval, entertainment, and interior design). However, none are designed specifically for academic campus experiences. SpectRA differentiates itself by integrating cultural, historical, and academic content directly into the student’s environment.
Short-term Objectives Sprint 1 is focused on delivering a functional MVP. The goal is to showcase a working prototype aligned with the defined backlog for Sprint 1, proving the feasibility of our approach and setting the foundation for future iterations.
Long-term Objectives - Expand the app to multiple campuses and universities. - Integrate AI-driven recommendations and adaptive learning experiences. - Establish SpectRA as a benchmark tool for immersive learning in higher education.

Section 2. Business Description

Section Description
History and Background The project originated under the guidance of Professor Juan Carlos Arbeláez, who challenged us to explore the potential of Augmented Reality (AR) as a solution to everyday problems. Thanks to the inspiration of Professor Liliana, our team decided to focus on bringing AR to the EAFIT University campus. The core idea was to allow people to enjoy AR experiences without the need for complex devices, simply by using their smartphones. Key milestones so far include: - Establishing AR as the technological foundation of the project. - Defining EAFIT as the initial implementation context. - Structuring the team and assigning clear roles. - Designing the first MVP to validate feasibility.
Mission and Vision Mission: To enhance the academic and cultural experience of the university community through interactive and accessible AR experiences, making learning and campus exploration engaging and immersive. Vision: To position SpectRA as a pioneering tool in higher education, expanding its scope to multiple campuses and becoming a benchmark in AR-driven immersive learning.
Values - Accessibility: AR experiences should be available to anyone with a smartphone, without the need for expensive or complex devices. - Innovation: Constantly exploring creative uses of AR to improve learning and exploration. - Collaboration: Building a product shaped by teamwork, professors’ input, and students’ creativity. - Learning-by-doing: As students, we value growth, experimentation, and the opportunity to learn through challenges. These values are deeply embedded in our team culture, guiding not only how we build the solution but also how we collaborate and evolve as a group.

Section 3. Market Analysis

Section Description
Market Research The global Augmented Reality (AR) in education market is growing rapidly. According to a report by MarketsandMarkets (2023), the AR education sector is projected to reach $13.8 billion by 2028, with a CAGR of 16.2%. This reflects the increasing adoption of immersive learning technologies by universities and schools worldwide. Locally, Colombian universities are actively investing in digital transformation to improve student experiences. EAFIT, for example, has embraced innovation as a core value, which aligns perfectly with SpectRA’s vision.
Market Segmentation Our solution is designed for different user groups within the university ecosystem: - New students: Need orientation to navigate campus and understand available services. - Visitors: Require quick and simple information about buildings, events, and history. - Staff & faculty: Benefit from administrative and informational features. Future segmentation could include other universities and educational institutions in Colombia and Latin America.
Target Customers The primary target customers are students and visitors of EAFIT University, who will directly interact with SpectRA for campus navigation, historical content, and building information. Key insights: - Students value speed, accessibility, and interactivity in digital tools. - Visitors prioritize clarity and simplicity when exploring the campus. - Both groups prefer using mobile-based solutions over specialized AR devices due to convenience and cost.
Competitive Analysis Several global AR solutions provide inspiration and competition: - Google Lens: Strength in powerful recognition and wide adoption, but lacks tailored academic experiences. - IKEA Place: Demonstrates high-quality AR visualization, but focuses on retail rather than education. - ZapWorks / ARLOOPA: Provide AR content creation platforms, but require higher technical knowledge and do not focus on campus experiences. SpectRA’s advantage: A context-specific AR solution for universities, starting with EAFIT, with a strong emphasis on accessibility, usability, and campus-specific content. Weakness at this stage: being an MVP, scalability and content variety are still under development.

Section 4. Product or service

Section Description
Product / Service Description SpectRA is a mobile-based Augmented Reality (AR) application designed for university campuses. By simply pointing the smartphone camera at specific buildings, locations, or markers, users receive real-time digital overlays with information such as: - Campus navigation: AR guidance to classrooms, offices, and facilities. - Informational overlays: History, purpose, and services of each building. - Interactive learning experiences: Access to academic and cultural content. - Event highlights: Real-time event markers and campus activities. Key benefits: accessibility, improved orientation, and a more engaging way to explore and learn about the campus.
Value Proposition SpectRA’s unique value lies in bringing Augmented Reality directly to students and visitors without requiring specialized devices—just a mobile phone. Unlike generic AR platforms, SpectRA is designed exclusively for campus life, solving challenges such as: - Difficulty navigating campus (especially for new students/visitors). - Limited interactive information about facilities and events. - Lack of engaging digital experiences connecting users to the university’s culture. By combining navigation, information, and interactivity in a single platform, SpectRA enhances the university experience while remaining simple and cost-effective.
Product Life Cycle SpectRA will follow a typical digital product life cycle, with clear strategies for each stage: - Introduction (MVP – Sprint 1): Deliver a functional prototype focused on core navigation and informational overlays for EAFIT. - Growth: Expand features (events integration, cultural content, gamification) and scale to other universities. Marketing efforts will focus on adoption by students and institutional stakeholders. - Maturity: Establish SpectRA as a standard AR solution for academic institutions across Colombia and potentially Latin America. Partnerships and customizations for universities will be key. - Decline (Long-term): Adapt by introducing new technologies (VR, mixed reality) or pivoting to other educational markets if AR adoption patterns shift.

Section 5. Implementation

Section Description
Timeline The implementation will follow an Agile methodology with Sprints of 2 weeks each. This ensures flexibility, fast iterations, and constant feedback. Sprint 0 (Preparation): Team formation, tool setup, backlog definition. Sprint 1 (MVP): Deliver a functional prototype with AR navigation and building information overlays at EAFIT. Sprint 2: Improve AR interactions, add event markers, refine UI/UX. Sprint 3: Expand database integration, implement Firebase authentication, test with pilot users. Sprint 4: Final refinements, usability testing, and preparation for presentation.
Key Milestones - Sprint 0 completed: Team roles defined, backlog created, architecture designed. - Sprint 1 (MVP): First functional demo of AR navigation and overlays. - Sprint 2: Integration of event system and UI/UX improvements. - Sprint 3: Firebase integration (database + authentication). - Sprint 4: Usability testing, bug fixes, and final release.
Required Resources - Human Resources: - Scrum Master & Architect (leadership, coordination, technical vision). - 2 Developers (Unity, AR SDKs, Firebase integration). - UX Designer (interfaces, accessibility, usability). - Product Designer & Tester (quality assurance, unbiased testing). - Technological Resources: - Unity 3D (development environment). - AR Foundation / ARCore / ARKit (AR support). - Firebase (database + authentication). - GitHub (version control and collaboration). - Mobile Devices (testing on Android/iOS). - Other Resources: - Time allocation for weekly meetings. - Access to EAFIT campus for real-world testing.

Code development

Functional Compliance

  • User Story #1 – Recognize Buildings: Partially implemented. The ML model is integrated with the camera input and can recognize one campus building (Building 19). However, accuracy is currently limited to ~70% (below the >90% acceptance criterion). Recognition time is within expected limits, and the app displays the correct building name when identified. Additional dataset expansion is required to achieve the planned performance. (TO IMPROVE)

  • User Story #2 – View Contextual Overlays: Only partially addressed. The current MVP provides a very basic overlay that displays the building’s name once it is recognized. Other contextual information (e.g., type, description, metadata) and dynamic updates have not yet been implemented. (TO DO)

  • User Story #3 – Visualize Structures with ML Insights: Implemented successfully. The ML model integrates with the AR overlay, and recognized buildings trigger visualization with relevant contextual information. Although 3D models are not included at this stage, the core functionality of linking recognition to dynamic AR content has been achieved. (COMPLETED)

Technical Development Management

Version Control (Git): Git was used effectively for collaboration and code tracking. Each user story and task was managed through issues and commits in the GitHub repository.

Repository Content: The repository contains the complete codebase for MVP1, including ML model integration, camera processing, and the minimal UI for recognition and overlay.

MVP Integrity: The current state of MVP1 reflects the planned scope for Sprint 1, albeit with partial fulfillment of some acceptance criteria. The baseline functionality (recognition + overlay) is in place, serving as a foundation for further iterations.


Functional Test Case Design

Evidence of Test Execution

The functional test cases designed for Sprint 1 were executed on the MVP using the Unity-built APK.

Execution steps included:

  1. Downloading and installing the APK.
  2. Opening the application.
  3. Pointing the camera towards Building 19 (the only dataset available at this stage).
  4. Verifying recognition accuracy, recognition time, and overlay behavior.

Results were documented against the predefined acceptance criteria of each User Story.


Bugs Reported

During test execution, the following issues were identified:

User Story Test Case ID Description Status Bug ID / Notes
HU #1 – Recognize Buildings CP1.1 Accuracy should be >90%. Current model achieves ~70%. ❌ Fail Bug #1 – Low ML accuracy (TO IMPROVE)
HU #1 – Recognize Buildings CP1.4 Overlay should close when user taps the close button. ✅ Pass (after fix) Bug previously found and resolved during development.
HU #2 – View Contextual Overlays CP2.3 Overlay should show name, type, and short description. Current MVP only shows building name. ❌ Fail Bug #2 – Missing metadata in overlays (TO DO)
HU #3 – Visualize Structures with ML Insights CP3.3 Overlay should remain aligned with real-world object. ✅ Pass Works for overlay; 3D alignment not implemented (out of MVP scope).

Connection HU → CP → Bugs

There is a clear logical connection between:

  • User Stories (HU) defined in Sprint 1.
  • Their Acceptance Criteria, which were converted into Functional Test Cases (CP).
  • The Bugs reported during execution, which directly reflect failures in meeting those acceptance criteria.

Thus, all test cases are requirements-driven, and no tests were performed outside the scope of the defined User Stories.


Software Quality Checklist


Naming Standards for SpectRA Project

Purpose

To ensure readability, maintainability, and consistency across the codebase, the SpectRA team follows Microsoft’s official .NET naming conventions adapted for Unity C# projects.

This allows:

  • Easier collaboration between developers.

  • Code that matches industry standards.

  • Compatibility with static analysis tools and CI pipelines.

General Rules

Use PascalCase for:

  • Classes (BuildingRecognizer, OverlayManager)

  • Methods (StartRecognition(), CloseOverlay())

  • Properties (RecognitionAccuracy, BuildingName)

  • Namespaces (SpectRA.Core, SpectRA.AR)

Use camelCase for:

  • Local variables (accuracyScore, elapsedTime)

  • Private fields (prefix with _) → _currentBuilding, _overlayUI

  • Method parameters (buildingId, frameData)

  • Use ALL_CAPS with underscores for constants:

MAX_RECOGNITION_TIME

MIN_CONFIDENCE_THRESHOLD

  • Avoid abbreviations unless widely recognized (e.g., UI, AR, ID).

  • Boolean variables should be prefixed with is, has, or can:

  • isRecognized, hasOverlay, canClose.

Unity-Specific Conventions

  • Scripts: Class name = Script filename.

BuildingRecognizer.cs → contains public class BuildingRecognizer.

  • MonoBehaviour lifecycle methods must follow Unity’s official casing:

Start(), Update(), OnTriggerEnter().

  • GameObjects and Prefabs: Use PascalCase, descriptive names.

  • MainCamera, Building19Model, AROverlayCanvas.

Folders in Assets/:

  • Use PascalCase, group by feature/module → Assets/AR, Assets/UI, Assets/Models.

Commits & Branches

  • Branching strategy: GitHub Flow.

Branch names:

  • Feature branches → feature/building-recognition

  • Bugfix branches → bugfix/overlay-close-issue

  • Hotfix branches → hotfix/ml-accuracy-threshold

  • Commit messages: Use imperative tone, English, and concise:

Add overlay UI for recognized buildings

Fix bug in recognition accuracy calculation

overlay fixed

References


Static Code Analysis for SpectRA

Purpose

To improve code quality, enforce naming standards, and detect potential bugs early, the SpectRA team integrated a static code analysis tool into the development workflow.

Tool Used: StyleCop Analyzers + SonarQube

StyleCop Analyzers: Enforces C# coding conventions (naming, spacing, readability).

SonarQube (Community Edition): Detects code smells, duplicated code, complexity issues, and potential bugs.

Configuration

  • StyleCop Analyzers

  • Integrated via NuGet package: StyleCop.Analyzers.

  • Ruleset used: Microsoft C# Guidelines (default).

  • Strict mode enabled: warnings treated as errors to enforce standards.

  • Auto-formatting enabled in IDE (Visual Studio / Rider) to fix minor style issues automatically (indentation, spacing).

SonarQube

  • Integrated with GitHub Actions workflow:

  • On every pull request, code is analyzed.

  • If quality gate fails (critical bugs, code smells), PR cannot be merged.

Configured Quality Gate:

  • Code coverage ≥ 70%

  • Zero critical bugs

  • Maintainability rating ≥ B

Workflow Integration

  • Developer workflow

  • While coding, StyleCop highlights issues in the IDE (e.g., variable naming, missing XML comments).

  • Developers fix issues before committing.

Justification

  • StyleCop: Lightweight, easy to enforce C# conventions, directly linked to our Naming Standards

  • SonarQube: Industry-standard tool, helps detect deeper issues (e.g., dead code, poor complexity) beyond style.

  • Ensures the codebase remains clean, consistent, and maintainable as the project grows.

References

Code Management & Best Practices

  • Has a branching strategy (GitFlow, GitHub Flow, Trunk Based Development) been defined and documented in the Wiki?
  • Is there a Continuous Integration (CI) pipeline configured to run tests and analysis automatically?
  • Is at least one static analysis tool (SonarQube, ESLint, Pylint, etc.) being used and its configuration documented?
  • Are naming standards followed for classes, functions, variables, and commits?

Functionality

  • Does the system allow full building scans and save the information without data loss?
  • Are the main use cases and test scenarios documented in the Wiki?
  • Are errors in the scanning process handled with clear messages for the user?

Security

  • Does the application require authentication and enforce user roles/permissions?
  • Are there access and change audit logs available?

Performance

  • Is the average scan processing time within the defined threshold (< 5 sec in tests)?
  • Were load and stress tests executed and documented in the Wiki?
  • Can the application work with limited connectivity or offline mode?

Usability

  • Is the interface intuitive and understandable for non-technical users?
  • Are accessibility criteria met (color contrast, font sizes, keyboard navigation)?
  • Was usability testing performed with end users or prototypes?
  • Are error and confirmation messages clear for each user action?

Maintainability & Documentation

  • Does the code follow clean code conventions and proper documentation?
  • Are there unit and integration tests with sufficient coverage (> 70%)?
  • Are logging and monitoring in place to detect production issues?
  • Is the system architecture documented?

Compatibility & Portability

  • Does the application run on all intended devices/OS (Android, iOS, Web, etc.)?
  • Is the system compatible with different cameras or scanning sensors (if applicable)?
  • Is it possible to migrate data between versions without loss?

Results

  • Total criteria: 23
  • Criteria met: 11
⚠️ **GitHub.com Fallback** ⚠️