Skip to content
Cindy19970928 edited this page Jul 10, 2018 · 64 revisions

Welcome to the AdvenShare wiki!

1.0 Iteration

1.1 Iteration Goals

WHAT: Design a travel software that can be designed and completed to meet different needs of different people, so that travelers can remember the purpose of each trip.

WHO: All the people who want to travel.

  • First, determine the characteristics of different travel groups. Secondly, it is determined that 18-30 years old young people are the mainstream group. Then, through the analysis of the characteristics of the mainstream group, the software function design is carried out.

WHY: Better travel experience and complete travel memory.

  • First of all, there is a certain degree of blindness in the current travel. People are leaving without a careful strategy, which makes travel experience greatly reduced. Second, travel is timeliness, and many of the things in the journey may be forgotten at the end of the trip, but perhaps the forgotten things may be good memories. Then, people's quality of life continues to improve, and the prices of all kinds of transportation are also declining. People are in urgent need of higher quality travel experience. So, our ideas came into being.

WHERE: Everywhere, including places where there is no network or signal.

  • People often want to view their own attacks and cached maps anywhere, but so far, many software needs to connect with their orders, information, etc., and do not support the caching function, but our software will avoid the emergence and occurrence of this problem to the maximum extent.

WHEN: Whenever they want to use it, they can get a good experience and service.

HOW:

  • Determining the target group.
  • Understanding the needs of the target group.
  • Collecting and collating the main needs of the user.
  • Identifying what we can do to meet the needs of users.
  • Designing the functional modules of APP.
  • The drawing of module function diagram after determination.
  • Software development.
  • Constantly analyzing problems and solving problems at design stage.
  • Testing after software development is completed.
  • Looking for people to experience software experience, ask for feelings and opinions, and improve them.

1.2 Team Roles

Role Allocation Description
Manager Connor Cashman Chiefly responsible for the project schedule and project plan and how progress compares to the plan.
System Architect Edward Southall Understands the overall structure of the software system. Must ensure a modular system and keeps an eye on the bigger picture.
Requirements Analyst Hannah Jury Understanding and communication the system requirements (which define the functional behaviour and qualities). Identifies the stakeholders, eliciting requirements, establishing priorities and documenting progress.
Quality Control Danny Ensures that quality goals are being met. Produces a good iteration and test plan and ensures it is executed at a high standard. Must establish standard practices and expectations.
Technical Documentation Samuel Eadie Documentation written for developers and maintainers of a system. Includes formal requirements, design documents, README files and comments in code. Also coordinates work of several people to ensure it is consistent.
User Documentation Cindy Creates documentation for the users of the software system (end users and administration). Documentation may include user manuals, online help, web based documents and FAQs and information.
User Interface Adrian Usability expert who takes usability into consideration. Responsible for ensuring that usability decisions are not overlooked.
Programmer Connor Cashman The programmer is responsible for turning the need for system capabilities into something a computer with actually run. Responsible for realising, as closely as possible, the requirements and designs developed by the team. This helps ensure that what the programmer produces is what the stakeholders actually want.
Configuration Control Edward Southall As with other roles, part of the build-master's job is to establish practices for others, and part is to administer the version and configuration system.

1.3 Task Management

  1. Documentation (Complete before COB 10/07/18)
  • Iteration 1
  • Project inception/ planning phase
  • Software design specification
  • Software requirements specification
  • SRS review summary
  • Team
  • User manual
  1. User Interface (Complete before COB 10/07/18)
  • Login/ sign up screen
  • Icons
  • Plan
  • info
  • My diary
  • Discover
  • Chat
  • My profile screen
  • My diary screen
  • info screen
  • Discover screen
  • Chat screen
  • Calls
  • Status update
  • Message
  1. Programming
  • Manual and automatic creation of diaries
  • Server data storage
  • Client-Server networking for: - Chat functionality - Discover feed data retrieval - User data storage - Retrieval of basic information
  1. Task Scheduling: https://trello.com/b/xyeUdv1l/advenshare

1.4 Documentation

  • Iteration 1.0 Document
  • Project Inception and Planning Phase Description
  • Software Design Spec
  • Software Requirements Spec
  • Software Requirements Review Summary
  • Team Principles
  • User Manual

1.5 Meeting Summaries

Date Description Evidence
26/06/18 Team member description and ice breaking PICTURRRRE-WATER
26/06/18 Team formulation and name creation (Wolf pack: stay hungry) PICTURRRRE-WATER
27/06/18 Industry Selection (tourism) and breakdown PICTURRRRE-WATER
29/06/18 Idea selection using the 6 thinking hats strategy (The lucky ones, high quality photo app, travel diary). PICTURRRRE-WATER
29/06/18 Travel Diary idea selection and expansion. PICTURRRRE-WATER

1.6 Retrospective

  1. Process
  • Innovation Type
  • Mind Mapping
  • Six Thinking Hats
  • Lateral Thinking
  • Design Thinking
  • Overview of Team Facilitation
  • Project Overview
  1. Methods
  • Brainstorming
  1. Tools
  • Mind Mapping
  • Six Thinking Hats

1.7 Process methods and tools

  • MIERUKA: Task Board (Using Trello)
  • Daily Scrum / Standup Meeting
  • Github Collaborative Development
  • Google Docs shared documentation

1.8 Next iteration planning

  • UI
  • Basic Information
  • Diary Builder
  • Net working
  • Gen
  • Testing
  • Research

2.0 Project Inception and Planning Phase

2.1 Process

We are using a hybrid of waterfall and scrum processes.

  1. Waterfall Process PICTURRRRE-WATER The process used for the project looks similar to the waterfall design Week 1: System engineering, Analysis Week 2: Design, Code Week 3: Code, Testing, Maintenance Week 4: Maintenance

  2. SCRUM Process PICTURRRRE-WATER Product backlog: “To do list” Sprint planning: occuring during the first half an hour of each session in the morning Sprint backlog: “To do today” Daily scrum: “Doing” Sprint review and retrospective: “Done” -> discuss at the end of each work day

Figure 1: Example of process used in trello PICTURRRRE-WATER

2.2 Initial Feature List

  1. Diary Representations
  • Make printable diaries
  • Export diary as a video
  1. Information
  • Low price tickets or current itineraries
  • Local culture activity reminders
  • Find food, information
  • Statistics about tourists, hobbies, destinations
  • Souvenir ideas
  • Information about appropriateness of bargaining at specific shops
  • Finding local guides
  • Information about local hospitals and emergency information
  1. Recommendations
  • Centralised place to find advice from like-minded people
  • Statistics high rated accommodation
  • Shopping malls recommendations (high quality, low price, variety, nice food)
  • Local interesting places or food recommendations
  • Local people’s ideas and advice
  • Recommended recent stations and airports
  • Suggest trips for generic person based on popular itineraries (recommender system improves based on user’s itineraries, linked people and liked discover itineraries)
  • Discover feed recommender
  • Recommend big events (either real time while travelling, or events to plan a holiday around)
  1. Diary Creation
  • Take photo date range
  • Filter photos
  • Automatically create personal story
  • Aggregate location and time date from photos and phone to automatically create diary
  • Manual entry into diary
  • Journal templates
  • Keyword shorthands
  • Timestamped speech to text got memoirs/reflections
  • Make a timetable
  • Prompt for photo input
  1. Premium Subscription
  • Act as a travel agent
  • Premium subscription allows tourism providers to filter all itineraries based on their product/service
  • Premium subscription allows local governments to filter itineraries based on their region and provides statistics for planning/sustainability
  • Tourism providers can pay to create a tour based on a popular itinerary. This will add a link to the itinerary which allows users to book entire itinerary in one click
  • Tourism providers can pay to bump itineraries that encourage their product/service
  • Advertise professional photographer services
  • Give statistics to travel insurance companies
  1. Connect
  • Contact other travellers in the same area as you
  • Allow travellers to share a car for mutual sightseeing
  1. Safety
  • Tourist tracker
  • Location tracking hidden from all except QR scanned people, location made available after diary is published (for safety/stalking)
  • Assign an ICE contact, and enable them to ping local police with traveller’s location
  1. Other
  • Language translation
  • Find the nearest mosque, find the Qibla, daily five prayer reminders
  • Heat map to locate busiest areas in the place you are in (helpful for both travellers and locals)
  • Cache map for offline use
  • Can link credit card/wechat to itinerary to stick to budget

In order to best demonstrate the features of our product to investors as quickly as possible, we have developed a set of basic features to achieve within a week. This list of features includes but is not necessarily limited to:

  • Login and sign up page
  • Manual text and photo input to create diary
  • Location tracking
  • About me section and profile
  • Basic info
  • Fundamental planning capacity
  • Chat demonstration
  • Demonstration of Discover Feed
  • A server to demonstrate proof of concept for user profile storage

2.3 Initial Planning

.|Strengths|Weaknesses |*Unique Functions |Some complex functions cannot be achieved |*Innovativeness | |*Convenient | |*Our team has a clear division of labor |

2.4 Risk Management

2.4.1 External Risks

Table 2.4.1 External Risks and Description

Risk Description
Economic When the economy is depressed, fewer people will go out to travel, and fewer people will use travel software. When the economy is developed, people who travel will increase, and people who use travel software will increase correspondingly.
Competitors Although there is no software like us at present, there has been a lot of competitive pressure in the tourism industry. Now many of the functions of the travel software are already very mature, such as the software such as The Same Journey, The Way Cattle and so on.

2.4.2 Internal Risks

Table 2.4.2 Internal Risks and Description

Risk Description
Technology There are some difficulties in the implementation of some of the functions.
Operational and strategic - Lack of team management experience.- There is no guarantee that customers will like us services enough to use them.- Entrepreneurs frequently borrow money to finance their venture in its earliest stages; there is a chance that they will not make sufficient profits to be able to pay these loans back.- As a business expands, the founders will invariably have to delegate responsibility for certain tasks to employees whom they do not know well. The employees bring uncertainty and risk related to their skills and performance.- We also have to face risks that are external to the day-to-day operations of their companies. These risks include natural disasters (earthquakes, tsunamis, volcanoes), freak accidents (plane crashes, car accidents) and long-term environmental changes (global warming, freshwater depletion, etc).
Legal Compliance: Businesses that get on the wrong side of government regulations can face fines and even prosecution. To avoid this problem, companies should ensure that they comply with all the regulations that affect their business, including business licenses, employment laws, corporate governance, and tax compliance. Depending on your chosen industry and jurisdiction, compulsory insurance might be required for certain aspects of your business. Errors and Omissions: Businesses run the risk of loss and legal liabilities resulting from inadequate or failed internal processes, fraud, human error in processing transactions, etc. These risks can be minimized by establishing standardized operating procedures and adding control steps at appropriate points in the process workflow. Furthermore, businesses should obtain a professional liability insurance that protects companies and individuals against claims made by clients for inadequate work or negligent actions. Intellectual Property: To discourage competitors from stealing your innovation, consider investing in copyrights, trademarks and patents. Very small businesses should assess whether the costs of potential litigation (including opportunity costs) justify the expense of IP protection. Work Safety: To protect your employees and avoid falling foul of Health and Safety legislation, entrepreneurs should formulate contingency plans for emergencies such as fires and explosions.
Financial - Customers can refuse to pay your invoices (credit risk).- The cost of your raw materials or suppliers could rise suddenly.- Customers may switch to a competing product and not buy your product or service any more.- A strengthening local currency can reduce the net profits from your foreign customers, or a weak currency can increase the cost of running your foreign operations (exchange rate risk).- A spike in interest rates could raise the cost of your working capital (interest rate risk).- A plunge in the value of stocks or real estate you pledged as collateral could cause your bank to cut your credit lines (asset price risk).- A slowing economy could reduce the demand for your firm’s product or service.

2.5 Development

2.5.1 Tools

In order to produce a product of the highest quality, we will be exploiting multiple sets of tools. These can be categorised into organisational tools and technical tools:

  1. Organisational tools
  • Mind Mapping - we have used and will continue to use a variety of different mind mapping techniques for planning our work
  • Trello - we are using the free online organisational software Trello to assign tasks to be completed by each member each day. This way we can ensure that people are not working on the same tasks, and we can hold each other accountable for the quality and quantity of work that we produce.
  • Github - in order to facilitate the sharing of both technical and non-technical files between team members, we have created a Github account to store our work in.
  1. Technical Tools
  • Android Studio - Used to write some android code that we can later combine with react native to program the mobile device.
  • Android Phone Emulator - Used to make it easier for the developing team to test their code without needing to flash the mobile device to frequently test the code.
  • React native - the primary programming language used to write the app’s code
  • React Navigation - Used for routing between screens
  • Moss - an external server provided by UQ including additional IP addresses used to write and test the server-client code.

2.5.2 Deployment

  • The app will be deployed to phones by USB directly in the development phase.
  • Android App store will be used to distribute the app long term.
  • Server is initially set up from a laptop

2.5.3 Version control

As previously explained, all version control technical documents will be implemented using the created Github repository. Version control of non-technical documents will be used via a combination of Google Docs and Github.

2.5.4 Coding Convention

In order to ensure that our code is modular and can be easily built upon by others, we intend to use the conventional google style guide for our programming. Since we intend to program in React Native, this gives us the ability to combine JavaScript and Android programming languages. The full style guide we intend to follow can be found at https://google.github.io/styleguide/jsguide.html , however a summary is provided below:

  • Classes: Upper Camel Case
  • Everything else: Lower Camel Case
  • Indentation: 4 spaces = 1 indent
  • Line width: maximum 80 characters per column

2.5.5 Initial architecture

For the initial demonstration of implementation the architecture will consist of 5 basic states. These are:

  1. Discover Feed
  2. Plan
  3. My Diary
  4. Chat
  5. Me

The big picture state architecture is fairly simple, as each state is entered upon button push, and there is no restriction between the entering and exiting of each state. A state diagram is shown below: PICTURRRRE-WATER

2.5.6 Testing strategy

We intend to implement a two pronged testing strategy to ensure that our product is of high quality. This includes:

a) Developer testing - developers are required to test the code that they have written to ensure that each function meets the specification given

b) Black box testing - testing of the app by a non-developing team member, to ensure that the app is intuitive and easy to use and functions as expected. This will then be fed back to the developing team for further bug fixes.

3.0 Software Design Spec

3.1 Introduction Document Goals

This document will clearly outline and detail the software design for the AdvenShare app to facilitate its effective, efficient and timely implementation and execution.

3.2 Main product Features and Capabilities

The core functionality to be completed in the first iteration consists of:

  • User profiles
  • Automatic diary generation and manual entry
  • Basic information of current location (accommodation, weather, exchange rate and tours)
  • Social networking: chat functionality between users
  • Discover feed: travel diaries from other users

3.3 UML Modelling

3.3.1 Deployment Diagrams

The deployment for AdvenShare is outlined below. PICTURRRRE-WATER However, as a proof of concept for iteration 1, the deployment is modified accordingly. PICTURRRRE-WATER

3.3.2 CRC Cards & Class Diagrams

HARD TABLES

3.3.3 Behavior: Sequence and/or State Diagrams

A typical use sequence for AdvenShare is outlined below. PICTURRRRE-WATER

3.3.4 Persistence PICTURRRRE-WATER

3.3.5 Security

In the first iteration, security is not a primary concern. In the second iteration, where users can view other profiles, a privacy setting for profiles will be made available and passwords won’t be stored in plain text.

3.3.6 Wire Frames

PICTURRRRE-WATER

4.0 Software Requirements Spec

4.1 Introduction

This part of the document will be used to guide the development of the application. By effectively expressing the goals of what we wish to achieve for the initial prototype of our app, we can ensure that our software development is well guided and that all of work is tapered towards achieving our goals. This will provide us with the best chance of impressing our investors early.

4.1.1 Goals

he goals of the project are documented in other areas. This section details the goals of this SRS which are:

  • To establish required elements of the software
  • To highlight software aspects that will not be considered in the first iteration
  • To give detailed analysis of intended users and use cases

4.1.2 Scope

In Scope Out of Scope
  • Loading pages - Icon for chat- Icon for plan - Itinerary plan - About me page - Storage of multiple diaries - Basic info: weather, currency, tours, accommodation -> creating a method for uploading data | - Security
  • Privacy
  • Options to sign up or log in
  • Duplex communication
  • Chatting with other users
  • Allow travellers to share a car for mutual sightseeing
  • Automatically create personal story
  • Souvenir ideas

4.1.3 Glossary

Key Term Description
APP
Moss
Contiki
Influencer

4.1.4 Overview

4.2 User Cases

4.2.1 Actor and stakeholder table

4.3 User Scenario

4.4 Non-functional Requirements

4.4.1 Environmental Requirements

4.4.2 Hardware Requirements

4.5 User Interface Prototype

5.0 Team

5.1 Team Members & Roles

5.2 Client

5.3 Team Values

5.4 Team Communication

6.0 User Manual

Hi Yo
nah yes

THIS IS A SMALLER TITLE

THIS IS EVEN SMALLER

Clone this wiki locally