-
Notifications
You must be signed in to change notification settings - Fork 1
Home
John Tang, David McClarty, Fredrik Forsell, Ivar Sandvik.
Scruff is a social media and marketplace hybrid, which facilitates the relocation, adoption, and selling of pet animals using social media features. Scruff aims to help seekers find their perfect pet by offering the ability for the end-user to frequently check on their favourite animals; like the workings of social media. The application aims to keep the two parties connected over long distances, so that the user will be able to discover the personalities further and narrow down their choices when selecting an animal to bring home.
The purpose of this app is to give users more insight into an animal's life and personality before bringing them into their life. This insight is achieved via a social media feed, where the owner(s) of the animal will post regular updates on their animal's. Traditionally, those wishing to adopt must visit a shelter to visit the animals. This interaction between each animal and the buyer often lasts a few minutes, which is an insufficient amount when compared to the commitment and compatibility requirements for long-term adoption.
Scruff functions by allowing users to search for animals to adopt. Scruff differentiates itself by offering the added ability for the user to “follow” animals, making their posts show up in your “feed”. As the owners of the animal post more, the user will understand the personalities, likes, and dislikes of animals; thus, narrowing down and improving the chances of a perfect match.
As for the marketplace aspect, Scruff will require comprehensive information from all the listed animals including verified medical history. This will allow the user to be certain that the animal they find on Scruff is up to date on its vaccinations. The individual animal pages will be laid out so that the seeker can seamlessly go from browsing an animal’s posts, to discovering more about it from its profile, to finally contacting the owner to arrange a deal. Scruff functions as a competitive marketplace, giving all users the ability to find the same animals, however the owner will still be able to refuse those deemed incompatible.
Scruff intends to compete against the current marketplaces such as Gumtree, and RSPCA. These offer social media capabilities, or a marketplace, but not both. Scruff intends to offer the entertainment of social media, with the added benefit of being able to adopt the animals. Competition analysis will be elaborated further.
Scruff targets four primary demographics of users:
- Owners of pets or strays that wish to give/sell the animal
- Shelters, pet stores, and other organizations that also wish to relocate the animal
- People who wish to buy/own pets or strays
- People who enjoy animals and like following them on social media
Scruff aims to fullfil these three kinds of users’ needs in the respective following way: 1 & 2. The app provides a platform that allows owners of pets or shelters to properly showcase their animal’s skills and qualities, which will increase the likelihood of them being able to give the animal away. 3. The application provides a wide selection of pets that cover a wide range of breeds that will satisfy the user. 4. Many users will use this application to view cute animals, which is why the social media app functions can be used exclusively.
Scruff is an application to help find homes for shelter animals, store animals, and private owned animals seeking relocation. The traditional method of this process is to create an ad on popular websites such as gumtree, post flyers on telephone poles, or to send it to a shelter. This however does not provide potential adopters with a great understanding of the animal’s lifestyle. Scruff’s purpose is to give users more insight into each animal’s lives, essentially providing a timeline of its activities. It does so by incorporating a social media system; which provides additional methods of pet discovery.
Rather than spending time walking through the shelter, users of Scruff can choose to follow animals they find appealing, to better understand their personalities, likes, and dislikes -- which would otherwise not be possible with a 10-minute meeting in the shelter. Once followed, the user can then observe the animal through posts made by the owner/organisation.
Scruff differentiates itself from other online platforms by focusing solely on animals wishing to relocate. It functions like social media in the sense that users of the app can regularly check in on their “followed” animals. This continued activity helps potential adopters narrow down their perfect pet. As owners are trying to relocate the animal to another home, they are incentivised to post regularly, enticing users on the other end to contact them. Scruff isn’t an alternative to going to shelters and stores, but rather a tool to interact with animals digitally.
As the market lacked any application that could connect animals and adopters long term, Scruff was established to bridge the gap. With Scruff, users can find their perfect pet by researching through many animals with easy, and animal owners are able to find the perfect owner and reach a bigger audience.
Sketches and explainations are coming soon.. (It is available in the original pdf)
The following are a list of user stories pertaining to the application Scruff, and the indented points are each user stories’ acceptance criteria:
- As the manager of a dog shelter, I want to be able to show that the animals I sell need a home so that people who want to keep a stray dog will know to buy my animals. a. If the animal being presented belongs to an animal shelter or similar organization, it will be indicated in the profile of the animal and can be indicated to the user in the results page of a search.
- As an owner, I want to be able to showcase my pet off properly so that people might be more interested in buying my pet off me. a. The profile for the animal will allow the owner to input data about the dog, such as type, breed, age, weight, etc. b. More general information can be elaborated on in a large “About” text box. c. The profile can be updated with images, gifs, and short videos, in a similar design to Instagram.
- As a customer, I want a page to view more information of an animal, so I can make a better judgement as to whether this is the animal I want to have. a. There is a profile for each animal filled in by the owner that elaborates more about the pet, including type, breed, age, weight, other attributes, and an “About” section that goes into more detail. b. The profile will often be regularly updated with images, gifs, and short videos, like an Instagram profile.
- As an owner, I want to be able to utilize images of my pet in my pet’s profile so that people will know what to expect and maybe find the pet good-looking and purchase it off me. a. Multiple images of the animal are supported in the pet’s profile.
- As an owner, I want to be able to utilize gifs of my pet in my pet’s profile so that I would be able to showcase off what my pet can do (tricks, etc.), without needing a full-length video. a. Multiple gifs of the animal are supported in the pet’s profile.
- As an owner, I want to be able to utilize videos of my pet in my pet’s profile so that I would be able to showcase off what my pet can do (tricks, etc.) that cannot be properly shown in a short gif or single image. a. Multiple videos of the animal are supported in the pet’s profile via embedding on YouTube or another video platform.
- As a customer with a specific type of animal in mind, I want to be able to search for a specific animal with specific attributes (type, breed, age, weight, housebroken), so that I get the perfect animal. a. Users can search via a text bar, where they can search by exact name of the animal, or breed, or other attributes. b. Users can also utilise an advanced search tool where they can specify multiple attributes covering a wide range of aspects.
- As a fan of pets, I want to be able to follow specific pets that I like and have a feed, so that I can sate my love of pets. a. There is an option to ‘follow’ a specific animal. b. There is a “feed” page which is regularly updated with any updated media posted on each followed animal’s profile.
- As a customer sympathetic to stray animals without owners, I want to be able to find animals based on whether their owners are part of an organization like animal shelter or a private person, so that I can own a stray animal and make a more positive impact to that animal’s life. a. See 1.’s acceptance criteria. b. There is an option to limit a search to “shelters only” in the Search Page, meaning all the results of the search in the Search Page would come from shelters and other similar organizations.
- As a user, I want the overall design of the app to be simple, incorporating only a few colours and fonts, so that I won’t be distracted or disgusted by how the app looks whenever I use it. a. No more than three primary colours are used, and only one overarching font is used throughout the UI wherever applicable.
- As a user, I want to login to my account, so that I can have access to it and use it. a. Users can login to an account using the login page, by entering their username and intended password.
- As a user, I want to create an account with Scruff, so that I can do the actions that having an account allows you to do. a. Users can create a new account using the registration page, by entering their username, password, retyping their password, and entering their email address and phone number.
- As a user, I want the option to logout, so that I can secure my account. a. Users can log out anytime they like in the user menu.
- As a user, I want the app to be easily navigable so that I don’t get lost or frustrated. a. The buttons to access the main pages will be located at the bottom of the screen in iOS, or on a left-side hamburger menu that can be opened in the top-left corner in Android.
- As a customer, I want the results page of the application to be simple and well-laid out when I make a search, so that I can navigate through the results more easily. a. The results page will dedicate a large space in the vertical feed to each animal. All the results will contain a photo, name, breed, and location. Optionally the user will also be able to click on arrows located on the photos to browse through the animal’s profile photos.
- As a user, I want to be able to change my password, so that I can keep my account secure even when my password is made known. a. Users can change their password in the Settings page by clicking a link. b. The user must type their old password, new password, and confirm their new password by typing it again.
Available in the original pdf
We want to let our app have the ability to send and receive pictures and videos to a database. Users will be able see other people’s content, and also be able to upload their own. Users will either upload a file or take a picture/video directly through the application. To make sure that the advertisements are following the rules, we will have to implement an administrative service so that we can easily remove unwanted content from the database.
In some cases, the application will ask the user for access to their GPS device. These coordinates will be used to calculate the approximate distance between the seller and user.
The application will also let the user communicate directly through their email and phone number shared on their advertisement page. We are looking into the possibility of creating a direct messaging method within the application.
To make sure that users don’t break the rules of our application we will implement an admin application that will have access to the main database. This way we can have a reporting system, giving us the ability to edit or delete advertisement and manage user accounts.
We have decided to follow the best practices for our system architecture. We reviewed the technical requirements to enable our application to work as intended: Our requirements for the system was the following:
- Security: we needed to secure our data and authorization process from unwanted access.
- Data and business logic: Our application requires communication with a external database and external logic (unknown to the end user)
- API: We wanted to seperate the presentation (the UI/application) from most of our logic. This means that our application will need to fetch data from our database. This functionality will be enabled through API’s. The API’s will be the only interface in which our application communicates with our database and logic.
- We also wanted to separate our business logic from our database. This requires a backend server with a interface to clients (the API) and a “external connection” to our database.
After these considerations we decided to go with the multi tiered system architecture, with 3 tiers.
The reason behind this is to meet the requirements state above. Tier 1: Is what a normal user sees, it contains the presentation layer. That's the app that the users use to interact with the system. Tier 2: This tier contains three layers:
- The service interface layer. This is will be the API that the presentation layer interacts with by making requests to this layer. The requests accepted will be defined here in order to limit access to our data and business logic. It will also interact with the service layer.
- The service layer contains is were our logic happens, like calculations done on the backend. And prepare data for delivery to the client. The service layer communicates with both the Service interface layer and the data abstraction layer.
- The data abstraction layers handles communication with our database. And delivers data to the business logic layer. It also takes requests/orders from the service layer and returns results. Tier 3: This tier contains our database system. Its seperated from the other layers. Separation of the database from our tier 2 layers may help with security because we can define a set of accepted requests from the Abstraction logic. This will make a malicious request from the client to go through two different verifications before any data is changed or delivered.
Thanks to Xamarin, Scruff will be able to perform well on the main phone software technologies: Android, iOS, and Windows Phone. It will be functional up to fairly late versions of each OS (Android Oreo 8.1, iOS 11.4.1, Windows Phone 10), and will be functional with earlier versions as it isn’t a complex application. It will be functional on the vast majority of devices running any of the above OS’s, although the application makes use of camera and location sensors, none of these sensors are essential to the application’s basic operations.
Scruff will be able to support major changes in features. The coding principle of encapsulation will be enforced, so all functions will be seperated in their different classes, and there is less chance of the change of one method negatively clashing with another method somehow. The UI will be contained within one class, and based on a single point-of-entry, so that any changes to the UI will not reflect badly on the rest of the application.
Scruff is somewhat flexible logically. The search page and settings page can be accessed anywhere, and its access can change without affecting navigation significantly. However, the results page is only generated as a result of search page, and the ad/individual animal page can only be accessed via the results page. The fonts and colours are minimal and can be changed with ease.
Although the app is aimed at selling dogs, it can be extended to cats, birds, rodents, fish, and other animals. The only attributes that would need to be changed is different “breeds”, most other attributes are applicable to all animals. Some attributes, however, will have to be skipped depending on the animal’s species, as they may not be applicable to all animals (e.g ‘housebroken’ or the concept of a stray animal. Can a fish be ‘housebroken’ or ‘stray’?)
Probably the most inflexible portion of Scruff is having to load gifs and videos in the ad pages/individual animal pages; not every phone necessarily has the processing power to play gifs and videos, and this can be taxing for people with weak phones that desire to view the ads for each animal.
Scruff supports being integrated with new technologies, and would probably end up relying on these technologies if the app were ever to go for a public, wider release.
Scruff can be easily integrated into a web service. The app shares similar qualities and has similar objectives to certain websites that are also focused on giving animals a good home (refer to “Mobile Application Reviews”, especially “RSPCA Adopt A Pet”), and all of the aspects of the app could be easily converted to a website format that devices other than mobile phones can access. A website could be used to branch out the application’s possibilities, allowing PCs and laptops to partake in the application, and allowing for more complex functionalities that websites can support and phone applications cannot.
An application like Scruff can easily rely on a cloud service to host the mass of media, profiles, and other information, since the application wouldn’t rely on a specific, local server, and can be easily pushed to several remote servers hosting a cloud. Having to physically host, wire, and program a multitude of servers to host the architecture of the application as well as the data collected can be troubling, difficult, and expensive, so a cloud solution would be preferable.
Scruff is designed to support comprehensive testing, including unit tests, integration tests, system tests, and acceptance tests.
Since encapsulation will be implemented throughout the system, and each method and function are more-or-less isolated from one another, each function will be independently tested on its own.
Using Nunit, Scruff will be capable of UI, or “whitebox” testing, as well as general “blackbox” code testing and user experience testing.
There are many challenges when it comes to mobile app testing, most of which can be summarized in the four following sets:
- Connectivity
- Device Constraints
- Device Diversity
- Installation and Maintenance
The design of the application will address any problem in all of these sets: ● None of the unit tests will rely on connectivity as it will not be launched online at the moment. ● Xamarin allows testing over a wide, diverse range of OS’s. ● As specified in “Flexibility and Maintainability”, the app is simple enough to be run on most phones, even a phone without good sensors. ● With the way the application architecture is structured, there will rarely be a unit test that will become redundant thanks to an update.
The first thing we considered was how the application would operate. We would like to have the opportunity to add more features in the future without adding too much complexity to our codebase and avoid common bugs. Avoiding bugs and keep information accurate
Since our software will have many classes and methods we will have to encapsulate classes and methods in the classes. This means that we will restrict access to objects methods and variables. For example where we can we will avoid having public variables or static methods that modifies objects. We will have to discuss these considerations during development. When our classes and methods are finished with strong encapsulation, it will pay off since it limits potential mistakes when connecting everything together.
We will enforce this setup of classes and methods in order to avoid problems with unintended changes of objects or method runs. We will also encapsulate classes whenever possible.
We will also use façade to an extent when we have multiple classes which tries use the same features. For example when communicating with our backend, file system, sensors. We are considering having for example one class for communications with our backend. This class will act as a single point of contact for the classes/objects/methods that want to communicate with the backend server. So when we are developing or troubleshooting we won’t have to look in multiple classes for methods relating to backend communication.
We have decided use a model-view-controller implementation in our structure. We will have three main types of classes.
- View classes (for example one per view in our app), this will be our user interface related classes. These will have no direct connection to our actual objects and object properties that we will display on the screen. They will be connected a controller which sends the data from our model (objects) to the view class.
- Controller classes will be responsible for transferring data from our objects/classes to the UI (views) and the other way around when submitting data from the view to Models.
- Our Model classes will be classes and instances of these will, contain the actual data in the application will use. For example when we have loaded content from our backend we will create objects of these classes which then in turn can be read by the Controller and transferred to the View.
This is our data model for the application. It has been designed with upgradeability in mind. Here are some of the important design decisions we have made:
- In the future we want to have the ability to add new animal types. We will start with only dogs in mind. If you look at the animal class/table, you can see that it will support new animals just by adding data in AnimalType class/table.
- We have also enabled “follow an ad” functionality where users can follow ads in order to keep updated.
- We also support many “ad types”, this can range from adoption, sale etc.
- We will also be able to store relevant facts about the animal such as Vaccinations, gender, breed/race etc.
- We support posts on each ad in form of pictures. So if you make a ad, you can post images of the animal after the ad has been created.
Scruff is an application to connect potential pet owners with animals digitally. It facilitates the “seeking” process by allowing users to follow animals which require re-homing. By using Scruff, users will be able to experience more of the animal’s personality over a long-term duration, before pulling the plug and committing. On the other end, current pet owners, businesses, and shelters can utilise Scruff as another marketing form for their animals. By taking advantage of the social media side of Scruff, they can keep followers up to date on the animal’s life, which has a greater chance of adoption by the followers.
Scruff is a hybrid social media platform and marketplace for animals. By researching the current line up of applications already existing, we found that there were no applications which combined the two services. While it is the main function of Scruff, users will also be able to browse as normal, similar to Instagram or Facebook. This allows the platform to remain open as social media, rather than devolving into a marketplace only service.
The first viable release of Scruff will include the major features such as the ability to post and view animals, search and filter through them, and the ability to follow certain animals and owners. These features represent the core of the Scruff platform and will provide the most complete picture of the goals Scruff aims to achieve.
Due to time considerations, budget, and technology requirements, some extraneous features will not be implemented in this release such as the in-app messaging, post commenting, cloud storage integration, and other network required functionality, Wide device compatibility will not be fully reached (especially on Android) as it will require extensive testing and the
To be able to market Scruff, all the distinguishing features must be developed. Following are the key features that will be developed in the minimum viable product.
- Accounts functionality: (registering, logging in, logging out, creating animal listings, creating user profiles). This will allow the user to save posts, follow animals/shelters, and contact owners. For owners, this will allow them to be contacted, manage multiple animals, and post content. This is an essential feature for Scruff.
- Home feed: This will give each user a personalised feed based on who they’re following. It will contain photos/videos/gifs.This is the core of the social experience.
- Following/unfollowing: Users will be able to personalise their feeds by following and unfollowing animals/users/businesses/shelters. Future releases will use the follower patterns to better suggest animals.This creates per-user personalisation.
- Posting content: Animal owners will be able to post photos (not videos or gifs) about their animals.
- Searching and filtering animals: To facilitate discovery, users will be able to search keywords such as names, locations, and breeds to find animals. This along with extensive filters will allow the user to narrow down searches if needed. A core part of the marketplace experience.
- Individual animal page: This page will display the animal’s gallery, its details, and the contact information. As users will want to know more about the animal before adoption, this page is of high importance.
The features that will not be implemented in the first release are as follows:
- Post commenting/sharing/liking: In future releases, users will be able to like, share, and comment on images posted by an animals profile. This feature has been saved for later releases due to time constraints.
- Saving posts: Saving will make posts appear in a special page exclusive for saved posts. This gives users a page where they can find posts dating back long periods of time. Other features were prioritised over this one.
- In-app messaging: This feature was considered as it would help relate each message recipient back to their animal. Rather than traditional email or phone, Scruff’s messaging will show which animal prompted the user to message this owner.
- Group messaging may also be implemented.
- In-app payment features: This app will also be integrated with payment services such as Visa, Mastercard, and Paypal to facilitate the transfer of the animal. Included in later releases due to network requirements.
- Animal buying guides / lifestyle blogs: There will be documentation which will help users when finding an animal. Things such as FAQs, tutorials, blog posts regarding health, lifestyle, and similar commitments will also be present. This would require additional time, and therefore will not be in the MVP.
- Sponsored posts / animal of the day: Animals owners can pay to get the animal to the top of the page, increasing the chances of adoption. This would require payment functionality, and therefore will not be in the MVP.
- Posting advanced content: Animal owners will be able to post videos and gifs alongside images of their animals.
Task priority levels: High (top priority), Medium (average priority), Low (bottom priority)
Task estimates: Measured in points, by ratio of how much time it would take to complete the task compared to the time it would take to complete a task estimated at one point (for example, a task that would take four times as long as a one-point task would be estimated at four points).
Although not specified, unit testing is included implicitly in each task.
The following features will be completed for the application Scruff by its Release 1. This release will be the minimum viable product (MVP) of Scruff.
T1. Feature that allows the owner to input data about their animal, such as type, breed, age, weight, general information, etc. Pertains to use case 2, 3. Priority: High. Estimated points: 4
T2. Feature that allows the profile to be updated with images. Pertains to use case 2, 3, 4. Priority: High. Estimated points: 2
T3. Feature that allows users to search via a text bar. Pertains to use case 7. Priority: High. Estimated points: 2
T4. Feature that allows users to search via an advanced search tool where they can specify multiple attributes covering a wide range of aspects. Pertains to use case 7, 9. Priority: Medium. Estimated points: 4
T5. Feature that allows users to login. Pertains to use case 11. Priority: High. Estimated points: 2
T6. Feature that allows users to register. Pertains to use case 12. Priority: High. Estimated points: 2
T7. Feature that allows users to logout. Pertains to use case 13. Priority: High. Estimated points: 1
T8. Feature that places links to all the at the bottom of the screen in iOS, or on a left-side hamburger menu that can be opened in the top-left corner in Android. Pertains to use case 14. Priority: Low. Estimated points: 2
T9. Feature that allows the user to change their password if necessary. Pertains to use case 16. Priority: High. Estimated points: 2
T10. Feature that allows users to search via distance from the home of the owner to their home. Pertains to use case 7. Priority: Medium. Estimated points: 4
T11. Feature that allows app notifications. Priority: Medium. Estimated points: 2
T12. Feature that allows access to a user’s gallery. Priority: Medium. Estimated points: 4
T13. Feature that allows use of the camera in-app. Priority: Low. Estimated points: 4
T14. Feature that allows users to follow specific animals via a “feed” page which is regularly updated with any media posted on each followed animal’s profile. Pertains to use case 8. Priority: Low. Estimated points: 4
The following features will be completed for the application Scruff in future releases:
T15. Feature that will allow animals that belong to an animal shelter or similar organization, to be indicated as such in their profile. Pertains to use case 1, 9. Priority: Medium. Estimated points: 2
T16. Feature that allows users to search via a “shelters only” option. Pertains to use case 7, 9. Priority: Medium. Estimated points: 4
T17. Feature that will allow animals that belong to an animal shelter or similar organization, to be indicated as such in the results page of a search. Pertains to use case 1, 9. Priority: Medium. Estimated points: 2
T18. Feature that allows the profile to be updated with gifs and short videos. Pertains to use case 2, 3, 5, 6. Priority: Low. Estimated points: 2
T19. Feature that allows users to like media from an animal’s profile. Priority: Low. Estimated points: 2
T20. Feature that allows users to comment on media from an animal’s profile. Priority: Low. Estimated points: 2
T21. Feature that allows users (with animal profiles) to share media from other animal’s profile. The post would be shared on the profiles’ own feed so anyone following the profile that shared would see the shared post. Priority: Low. Estimated points: 2
T22. Feature that allows users to save media from an animal’s profile. The saved posts will be in their own separate page. Priority: Low. Estimated points: 4
T23. Feature that allows users to message other users in-app. Priority: Low. Estimated points: 8
T24. Feature that allows users to pay other users in-app. Priority: Medium. Estimated points: 8
T25. Feature that allows users to message other users in-app. Priority: Low. Estimated points: 8 DUPLICATE^^^^ with T23
T26. Feature that allows users to access a FAQ/blog related to the application’s use, looking after pets, and animals as a whole. Priority: Low. Estimated points: 2
T27. Feature that allows users to pay money to prioritize and advertise their for-sale pet. Priority: Low. Estimated points: 4
- Bitbucket
- Xamarin
- Gmaps API
- Android/iOS/UWP (Testing)
- MarvelApp (High fidelity Mockups)
- Lucidchart (UML, ERD)
- Nunit (TDD)
When developing Scruff we have a set of security and privacy requirements that we want to implement. We want to make sure that our users will feel comfortable with how their sensitive information is being handled by our system. This includes private information as phone numbers, emails, home addresses and passwords. However, since a lot of this information is stored and handled by the back-end server, the users won’t be able to know how secure and private the data really is. For this reason, we must consider the ethical issue about how we should handle the security infrastructure.
In the first version of our app the users will be able to communicate directly to the sellers via email and phone number. To make this possible, the contact details must be available on the advertisement page for the animal. However, this increases the risk of spammers and cybercriminals collecting this information through an Email Address Harvesting process (also known as an email scraper). These emails are then put into a list used to send bulk emails or spam. To prevent this from happening to our uses, we will implement a method that will request contact details from the server only when needed. This way we can monitor users and see the amount of requests that happens within a certain timeframe. There will be 2 control mechanisms for detecting abuse:
- If the requests happen faster than humanly possible, we will blacklist the account from sending more requests. The only way to get removed from the blacklist will be by contacting the support team.
- If the requests happen more than what is reasonable, we will give the user a warning (3 request’s left). Reaching the limit will put the user in timeout before being able to send more requests. Multiple violations will increase the timeout. This mechanism will be made to lock out smarter email scrapers that acts like they are human to bypass control mechanisms as the one above.
We will implement a Role-based access control, were privilege and rights will given to users depending on their role. We will have 4 different user roles:
- Unregistered: a. Will be able to look/search for ads
- Users: (same rights as Unregistered) a. Save/like/follow ads b. Request contact details from sellers c. Upgrade account to “Seller”
- Seller: (same rights as Users) a. Post/edit their own ads
- Admin a. Enforcing rules by editing or deleting advertisements. b. Able to demote users roles. c. Able to blacklist/whitelist users from specific features. (ex: request phone number)
We want our users to have a set of options of what information they want to have associated with their account. For instance, we will be giving them the possibility to choose their preferred communication methods. If they don’t want to publicly share their phone number, they can use their email instead. Our database will be based on the Need-to-Know principle, which means that we will only store information that is necessary for our app to function as intended. For instance, to be able to search for ads in different areas we need a home address. To enforce privacy for our users we will only include the street name in the ads. If a seller and buyer schedule a meetup they will have to give the rest of the information through their choice communication method.
We have an ethical responsibility to secure password in case of a security breach. Since people tend to use the same password multiple times, we have to make sure that potential attackers wont get access to their password. To prevent this from happening we will store all passwords in the database as salted PBKDF2 hash values. Salting the hash values with a unique identifier (such as their userID) will make sure that all passwords stored in the database has a unique value, even if it is the exact same password. This is because a minor change to the text that's being hashed will cause a major change in the output hash value. If it was not salted, a data leak may show that 10+ users were using the same passwords. The attacker could then try to bruteforce the hash value and get access to multiple plain text passwords in one attack.
Another potential threat is network sniffing. If the transmission of data isn’t properly secured an attacker can monitor the local network and get access to unencrypted data. This can be enough for a hacker to gain access to the data being transferred. If the password is sent to the server in plain text this can also easily be picked up by network sniffers. We will implement SSL to encrypt the communication in our app.
We are planning to use a small variety of development and support tools. We have taken in consideration many tools we could potentially use to assist us during development such as third party tools. We need tools for the following tasks:
- Creating the structure of the application, including files and managing versions when working in team.
- A development environment for the application, which supports the tool above.
- Tools for efficient debugging when there are errors in the code (usually logical errors, since we will detect syntax errors during compilation).
- Tools for efficient testing of the application on mobile devices (emulated and physical), to detect errors.
- Tools for testing back end logic/code.
- Tools for UI testing and testing on multiple device brands and models.
In a open source development situation we would be using Github for managing our codebase and collaboration. In order to not have to spend money on a Github premium subscription for private codebase we opted for a similar product called Bitbucket. This is a software project development platform where we can store our files and repositories. It connects right into our development platform mentioned underneath. It supports forks, branches and access control which in turn makes our project structure and files nice and tidy.
We choose to use Visual studio xamarin edition for development of our application, since we think this IDE suits our needs best. We will be using the tools that Microsoft has provided in this IDE for testing. The tool includes access to online emulators, local emulators, UI testing, server code emulation, and many other features. In addition this tool is recommended to use in our course.
When we are developing the application we can use the emulators available in the IDE. These are actually the stock android emulator and iOS xcode emulator. With multiple versions of the operating system available. We can use the online emulators as well provided so we don’t have to download all the different versions of the OS to our computers. This will save us some time on the android platform, since the android versions that users use is pretty segmented.
We are planning to use “App service helpers” which is a tool provided by Microsoft connecting your application to the backend with very little effort. We will most likely use this as our backend. We have considered other measures for connecting our application to the backend such as java, php. But since Microsoft has made it easy for us to set up the communication channel with Xamarin we opted for that option.
We will be using xamarin automated UI testing on our application. It's pretty easy to set up and we feel like it will handle some of our more simple use cases. We also plan to use xamarin test cloud which tests our application on real devices in a physical location. This will accelerate our testing process and we will find problems faster. For example errors related to other OS versions and devices. We will also do some manual testing for specific use cases that are faster to manually than to record.
We have concluded that we will need a solid testing strategy including the following testing progress:
- We will start by creating test cases. This defines the actual operation we are going to test. In simpler words it means what we are going to do with the app. We can use our User stories here for common sequences that the actual users will preform.
- Control of the result of the test case. This will be our control of the result from the operation performed above. In simple terms control that the operation achieved the desired output/result. In example that a login test with correct credentials resulted in a successful login.
- Testing with different kind of user inputs. For example a space in a text box intended for int data type can result in a application exception. So we have to test to ensure that exceptions do not happen often and make tests within our logic. So we have to test with both correct and incorrect inputs and make sure the expected result is correct for the context.
- We will try to imagine and find all possible indirect results from incorrect and correct operations, then verify that the results (what happens after/during operations) does not hurt our application: crashes, exceptions, incorrect data sent to backend etc.
As well as our testing strategy we need a quality assurance strategy. We have discussed and made directions for ourself to ensure that our software has a good quality level. Our strategy is as follows:
- When we planned how the application should operate, we first thought about use cases and user stories. The user stories represented the most common user actions when using the application. After that we designed and settled on a final UI design that compliments the actual goals the end user might have.
- In order to respond to user needs, we have taken in consideration what potential dog buyers and sellers want when they are selling/giving away their dog. This includes a clear story in the application aimed towards the action of selling/buying/adopting a dog.
- The functionality in the application is clearly aimed for animal sellers/and buyers. The application is made just for this purpose. There is a social media aspect to the application as well that can compliment user interaction and returns (returning to use app).
- Our software should be reliable and behave in ways the user expects. We want to achieve this with extensive testing before we publish the application for users. This includes UI testing and looking for errors within the application (see testing strategy above for details).
- The software should be easy to learn, we have used as few activities (screens in application) as possible without cramping the screen with too much information. We might also add a small user guide when opening the app the first time).
- When we planned the design (technical) of our application, including backend, database and front end we will focus on security. See our security and privacy requirements.
- Efficiency is also important in our app development progress. We will try to minimize unnecessary processor usage and often more important the cellular data.
- As mentioned in our use of development tools, we will be using Bitbucket when we develop the application and maintain our structure there by using functions like forks and branches. This will help us when we have deployed the application because our structure will be maintained.