SDS
This document defines the design of the JCE-Indoor-Nav project. It contains information
about the structure of the various components in the project, as well as the interaction between them, various UML diagrams are used in this document in order to provide a full understanding of the system.
This document also contains a risk management table in order to reduce or avoid risks that can affect the project during development.
The Risk Management is discussed under the section Risk Managment and it defines how risks are associated with the application. The risks will be identified, analyzed, and managed.
- Show and explain the internal architecture of the application.
- Assure that the application will meet the requirements listed in the SRS document.
- Assure that no problems would arise during development time.
- List all possible risks and the retaliation for each of them.
-
Navigation: allow user to navigate to a specific destination through the college campus.
-
Multi-Language: allow user to change application language at any time during usage, language will be stored locally for each user. Risk: changing between left to right languages such as English to right to left language such as Hebrew and Arabic may cause unwanted behavior in the program, such as unaligned text and boxes.
-
List and search destinations: display all available destinations and allow user to search for a specific destination either by name or by service provided.
- Map class fetches tileset data of the building map from Google Maps API.
- The Locator class fetches the data of all available destinations from JSON file sitting in the server and provide it to the Map and Menu class, it also translates geographical co-ordinates to tileset co-ordinates.
- The RoutingService gets the tileset data from the Map class and can provide the Map with a Route(list of way points) for the map to draw.
- The LanguageService updates Menu and Map with the selected language.
The three nodes (client device , web server and Google API servers) communicate with eachother as shown in the diagram.
The client uses the web browser component to fetch the application from the web server using HTTP.
The application fetches the map tileset data from Google servers using Google API.
The application has 4 components, the locator component fetches destinations data from JSON file, this makes it easy to change the destinations information in the future.(if an office changed its location/name/hours , simply update the JSON file), the RoutingService component also fetches way points data from a different JSON file.
These diagrams shows the user interaction in the application and how the different components communicate with eachother to provide the user his needs.
- The application will store user's selected language in the web browser's local storage.
- The map of the college campus will be stored in Google servers and fetched using Google Maps API.
- The list of all destinations and information for each destination(location, hours, name etc.) are stored in a JSON file in the server.
- Way points (tileset co-ordinates representing where a person can move in the map) are stored in a JSON file in the webserver.
- Intuitive design: the application needs to be usable by any college visitor, without needing a manual, while being able to access at least 60% of the application functionality at the first time of use.
- Speed: the application needs to be usable by any college visitor, without needing a manual, and in a time period less than 5 minutes for more than 70% of users.
- Ease of use: about 80% of people using the program need to be able to use it without feeling that it is difficult to use.
- Tidiness: the menus and screen elements needs to be relatively stable, and not keep jumping around while the user is using the program.
Spreading the search,change language,and navigation features -instead of combining them into one- helps in accomplishing those non functional requirements, as on one hand they give the user the ability to reach different parts of the program more efficiently, and on the other hand gives the program more leverage in handling user's request.
This Risk Managment Table discusses all the risks that could have an effect on the JCE-Indoor-Nav project.
| Risk | Severity | chance of happening | Response | mitigation |
|---|---|---|---|---|
| Lack of knowledge | HIGH | HIGH | Research and study needed materials, request help when needed | use simpler algorithms and features |
| Difficulty knowing current floor | MEDIUM | HIGH | Manual floor selection option | always start from the floor that the user most likely to enter from |
| Users not using our product after deployment | HIGH | LOW | Simple, intuitive, and fast GUI designed for the user | redesign the GUI to fit the user |
| Combining the project components not successful | HIGH | LOW | We shouldn't force the programmers to program to change their way of programming | adding adapter classes to link between different componenets |
| User take a lot of time using the program | MEDIUM | MEDIUM | Using the most simple and intuitive design possible | Changing the design of the GUI to fit the user |
| Google Maps services take long time to create floor plan | HIGH | MEDIUM | Research other API's | Use other API's |
| College does not give us permission to put our link on the website | LOW | LOW | Out of our hands | College will have to advertise our product |
| The project owner can change the project requirements any time | MEDIUM | MEDIUM | Using Agile programming | integrating changes into the current version instead of starting over |
https://github.com/alkerr/JCE-Indoor-Nav/wiki/Product
A prototype for our application has been made, which helped us in identifying the optimal way of testing the program.
At first we will focus the our testing to the navigation API - which is the heart of the program - in order to find the best method to integrate it.
After testing the navigation API will we move to connecting it to our user's interface, and then to testing those elements together. At the same time we will begin testing the language conversion page, checking it's results. Then we will move to connecting the college offices' data to the language page, in order to be able to change the language. At this point all that is left to test is the combination of all the elements that has been tested, which means testing the program in terms of compatibility between those elements. Considering that the program should be usable at this point, now we can test user's interaction with the program, seeing their's reaction will help us in optimizing the product towards a user-friendly experience,
In case of failure in testing one of the components of our program, we will mainly try to do two things, the first being the simplification of the failed unit as to provide a partially working unit to work with, and the second being replacing the failed unit as to avoid the unnecessarily spending of resources, and to increase the efficiency of making the product helping in reaching a better product for the costumer.
We are experimenting with using google indoor API for navigation, in case of failure and to ensure that we use the best tools for this job, we are also testing with different APIs and services, such as Indoor Atlas.