Welcome to the documentation pages of the Campus NAV of openCX!
You can find here detailed about the (sub)product, hereby mentioned as module, from a high-level vision to low-level implementation decisions, a kind of Software Development Report (see template), organized by discipline (as of RUP):
- Business Modelling
- Requirements
- Architecture and Design
- Implementation
- Test
- Configuration and change management
- Project Management
So far, contributions are exclusively made by the initial team, but we hope to open them to the community, in all areas and topics: requirements, technologies, development, experimentation, testing, etc.
Please contact us! Thank you!
Project developed by:
🎓 Francisco Gonçalves (kiko-g)
🎓 João Mota (jppm99)
🎓 Luís Ramos (luispvramos)
🎓 Martim Silva (motapinto)
⏳ Navigation app designed to help attendees find key areas inside a conference building.
📱 What is the most annoying thing when going to a conference meeting?
Definitely finding the places where you want to go inside a building you have never been to before.
Campus NAV provides you with information you need about the conference building you're in. You have access to all the details about any conference taking place there (path, room, speakers, duration, ...), as well as information about the routes to bathrooms, coffee machines, vending machines and even bars nearby.
This way you can focus on the important things, which are connecting and learning.
📶 The application should give the user a realiable realtime location and provide up to date information about conference schedules.
Hence the application needs to keep a stable connection with the various beacons scaterred through the buildings.
Both connection with the various beacons and the user location will be achieved using bluetooth in conjuction with open source APIs.
An online database will need to be used to store conferences. To be maintained there must be a website to allow staff and developers change the information.
- Go to Conference
Actor: Attendee
Description: After an attendee has arrived at a conference location, and has selected the option to be directed to a conference, the application will guide him to the conference room.
Preconditions: Attendee has selected the conference that he would like to go to and has internet and gps connection turned on.
Post-conditions: App will search for optimal route. Attendee will be directed to the conference room.Normal Flow:
- The attendee turns internet and gps connection on.
- The attendee will indicate he wants to be guided to a conference he has selected.
- The system will search for optimal route.
- The attendee will follow directions given by the application.
- The attendee will reach the conference location.
- The application will issue a notification warning the user that he has arrived at the conference.
Alternate Flows and Exceptions: The user goes off route -> The application must calculate new route. The user is not in FEUP -> The application must give a warning and not calcute. The user does not have internet and gps connection turned on -> The application needs to warn the user.
- Visualize map
Actor: Attendee
Description: The attendee presses the map button and the map will pop up and show his location on the map.
Preconditions: Attendee is in FEUP. Attendee has internet and gps connection turned on.
Post-conditions: Attendee will know where he is.Normal Flow:
- The attendee turns internet and gps connection on.
- The attendee presses map button.
- The application acquires his position.
- The application shows the map.
- The attendee knows their position.
Alternate Flows and Exceptions: The user is not in FEUP -> The application must give a warning and show map without position. The user does not have internet and gps connection turned on -> The application needs to warn the user.
- Go to places of interest
Actor: Attendee
Description: After an attendee has arrived at a conference location, and has selected a point of interest (bathroom, coffee machine, bar, etc.), the application will guide him to it.
Preconditions: Attendee has selected a point of interest that he would like to go to and has bluetooth turned on.
Post-conditions: App will search for optimal route. Attendee will be directed to the point of interest.Normal Flow:
- The attendee turns internet and gps connection on.
- The attendee will indicate that he wants to be guided to a point of interest he has selected.
- The application will search for optimal route.
- The attendee will follow directions given by the application.
- The attendee will reach the point of interest location.
- The application will issue a notification warning the user that he has arrived at the point of interest.
Alternate Flows and Exceptions: The user goes off route -> The application must calculate new route. The user is not in FEUP -> The application must give a warning and not calcute a route. The user does not have internet and gps connection turned on -> The application needs to warn the user.
- Check conference data
Actor: Attendee
Description: After an attendee has opened the application he will go to homepage and see all conferences, when he presses the one he wants to know more about it will show him all available information about it.
Preconditions: Attendee has internet connection.
Post-conditions: App will acquire data from the online database. App will show all conferences returned from the database.Normal Flow:
- The attendee connects to the internet.
- The attendee opens the application.
- The application will acquire data from online database.
- The application will show all conference data returned from database.
- The attendee will choose conference that he wishes to see more about.
- The application will show all data related to that conference.
Alternate Flows and Exceptions: The user does not have internet connection -> The application needs to warn the user.
- Modify Conferences
Actor: Staff
Description: A staff member changes conferences listed on the database.
Preconditions: Staff has internet connection and is on the website.
Post-conditions: Website communicates with database and updates it.Normal Flow:
- The staff connects to the internet.
- The staff goes to the database website.
- The webiste will acquire data from database.
- The staff will change conferences listed, possibly adding or removing some.
- The attendee will submit changes to database.
- The website transmits changes to database.
Alternate Flows and Exceptions: The information is not correct -> The website needs to warn the staff.
🏢
💎 In the initial prototype phase, we only had a sketch of the app and not many user stories had their implementations met. The main concerns were around what tecnologies and programming languages we would be using to develop the app itself, which led to realizing the best option available was Flutter/Dart.
In addition to this, we spent some time discussing what would be the general logical architecture of the app as well as what external devices and technologies were going to be put to use in aid of the smartphone, which then led to the decision of using bluetooth beacons (with the purpose of helping with the campus navigation).
In terms of the status of the app we had an initial sketch of the main page and navigation side bar, showcasing buttons to select each of the conference's available.
💻 ℹ️ The aplication is currently being implemented using a MVC model coupled with a Router that changes the pages. This allows a better team management overall due to the fragmentation of the code in smaller sections and making different pages independent from one another. The map view is currently being developed with GoogleMaps.
The section below describes each product iteration alongside with the user stories associated with them.
In addition to the description of each product iteration we are going to leave links to the user stories associated with each iteration. Please note that our trello board highlights which User Stories refer to each Release. Also, we added release tags to our github repository in order to simplify the task of browsing each iteration in depth. This way allows for easier access to the status of the project by the end of each iteration/release.
On the first iteration we dedicated some time to learning Flutter/Dart and built the core and barebones of our application. We focused on developping:
- The home page interface, which contains dropdowns of the available conferences.
- The side bar to work essentially as a navigation tool for the app.
- The option to switch between dark and light theme on the settings page.
Release 1 User Stories
#1 - Easy access menu
#2 - Theme color
#3 - Scheduled conferences
#4 - Conference details
On this iteration we focused on implementing:
- The favorites section, which will allow the user to store their favorite conferences of the ones available (user story #1 below)
- Settings saving upon user input, for instance favoriting a conference, changing profile username, etc. (user story #2 below)
- The search engine, which allows the user to search for an existing conference via string input (user story #3 below)
- The profile page, which allows the user to have their own section with their preferences (user stories #4, #5 and #6 below)
Release 2 User Stories
#1 - Favorite conferences
#2 - Save settings
#3 - Search engine
#4 - Profile page
#5 - Interests in profile page
#6 - Changing Profile picture
On the third iteration our main focuses were:
- Help and About Page (user story #1)
- Implementing the map system (user stories #2 to #5 below)
User stories between #2 and #5 could not be finished until the due date of the iteration 3 so they are also a work in progress in iteration 4
Release 3 User Stories
#1 - About Page
#2 - Map guiding to conference
#3 - Map guiding to vending machines
#4 - Map guiding to bar
#5 - Map guiding to bathroom
In the fourth and final iteration of our project (for the purpose of ESOF) we focused on finishing what we had projected for iteration 3 and left some user stories in the backlog section of our trello board, to save some features we would like to implement in the future.
Release 4 User Stories
#1 - Map guiding to conference
#2 - Map guiding to vending machines
#3 - Map guiding to bar
#4 - Map guiding to bathroom
#5 - Path to location
After this iteration, and for the purpose of ESOF, our app had reached its final state. Below you can find some screenshots of the application in action.
Backlog user stories
#1 - Information provided about changes in conferences
#2 - Automatic testing for every feature
Iteration 5 was different from the previous releases since it was not about developping Campus NAV. Instead we contributed towards an open source project (Open CX) with a unique feature of the Campus NAV app.
☑️
We have defined some acceptance tests, which can be found in our Trello board.
They are located in the description of each user story.
For now they are only defined. The ultimate goal would be to have them all automated in our app.
📘 The main focus of testing was to become more familiar with the concept of acceptance testing using Gherkin. Hence, we decided to choose a feature and created tests for it, so that we could be sure it was working properly. These tests are all executed automatically. The feature we chose for testing was the Main Page Drawer using multiple test cases, where we test a variety of outcomes after opening the drawer and tapping buttons on it.
💯 Main Page Drawer: We decided to create a test case for each selectable option in the main page drawer (Home Page, Map, Profile, Favorites, Settings and Help).
Every test, opens the drawer, taps the option of that test case and checks if the title of the final screen is correct. This way we know for sure whether it corresponds to the expected page or not.
You can find the test folder here.
For the purpose of ESOF, we use a very simple approach, just to manage feature requests, bug fixes, and improvements, using GitHub issues and following the GitHub flow.
- Use of branches for every new feature/change to the code, using easy-to-understand names
- Use of pull requests when a certain branch was ready to be added to the master branch
- Use of releases for each product iteration
- Revision, discussion and testing of the code for those pull requests, in order to make sure that the pretended functionality was achieved
- Controlled merge of branches to the master branch, so that everything that is implemented in the master branch is final and working correctly
The project management is done using Trello with the following structure:
BackLog: User stories planned for the project that are not yet done.
To Do: User stories to be done in the upcoming weeks.
Doing: User stories that are currently being worked on.
Done: User stories that have already been done and successfully tested.