-
Notifications
You must be signed in to change notification settings - Fork 1
Release Plan
At this point, the application is completed and all of the following requirements have been implemented:
- Task Basics
- Task Details
- User Profile
- Task Bidding
- Elastic Search
- Task Assignment
- Task Done
- Photographs
- Geolocation
- Searching
- Offline Behaviour
- Reviews
With that in mind, there is no "structured" (formatted in a table) release plan to provide, as is seen below for older release plans. Instead, we provide here some ideas for future planning.
This would allow users to communicate over the application, potentially improving user information security. For instance, users then would not be required to provide their e-mail or phone numbers for others to see. Instead, they could use the messaging system to talk with other requesters/providers to coordinate meeting times or payments.
This would allow users to conveniently integrate their banking accounts to provide secure payments. Moreover, payments could be set up prior to completing a task. This way, providers would not fear potentially not receiving a payment from he requester. As well, it would provide users with a way to log their transactions with other individuals using the app.
The app could be improved further by also expanding to multiple platforms. For instance, we could write web applications or desktop applications for windows. Likewise, an iOS version could be created. By doing this, we would reach a broader range of individuals, increasing the number of people who use the app.
Groupings could be added for providers. This way, a "Group Manager" could manage a number of Task Providers and assign tasks to them. This would increase productivity and overall organization for businesses who operate through the application. For instance, if a plumbing company often uses the app, their tasks could be organized, scheduled, and assigned to employees through the app.
A way to increase the organization of the tasks put onto the app is to have pre-defined categories. In this way, users could increase the quality of their search results by searching or filtering tasks by categories. For example, all trades type tasks (plumbing, woodworking) could be categorized together. Likewise, all tasks involving animals/pets could be categorized.
### Revised Release Plan (OLD)
Completed User Story Categories
- Task Basics
- Task Details
- User Profile
- Task Bidding - Except Notifications
- Elastic Search
- Task Assignment
- Task Done
- Photographs
Project Part | Week | Modules to Complete | Internal Deadline |
---|---|---|---|
Part 5 | 4 | Searching, Geolocation, Task Bidding Notifications, Offline Behaviour | Mar. 22 |
Part 5 | 5 | "Wow" Factor | Mar. 29 |
Part 5 | 6 | User Interface Overhaul | Apr. 05 |
Project Part | Week | Modules to Complete | Internal Deadline |
---|---|---|---|
Part 4 | 0 | XML | Feb. 22 |
Part 4 | 1 | Task Basics, Task Details, User Profile | Mar. 01 |
Part 4 | 2 | Task Basics, Searching, Elastic Search | Mar. 08 |
Part 4 | 3 | Offline Behaviour, Task Bidding | Mar. 15 |
Part 5 | 4 | Task Assignment, Photographs, Geolocation | Mar. 22 |
Part 5 | 5 | Task Done, Wow Factor | Mar. 29 |
Part 5 | 6 | Wow Factor | Apr. 05 |
Note: Each internal deadline is a Thursday.
Each week has a number of modules to be completed. Modules that take two weeks to complete will be reviewed by the team at the end of the first week, and revisions will be made in the second week. Each module has potentially many use cases. You can find associated use cases for each module in the requirements table below. Please note the direct mapping between requirements to release plan deadlines. The idea is to have all uses cases for any module implemented and working by the end of the respective weekly deadlines. That is, by each deadline, there will be working software to be presented to our mentor.
Work directly related to application implementation has been split into "modules". That is, the release plan refers directly to, and only to, code-dependent portions of the project. For the purpose of this release plan, components like code documentation or test cases are not included as we consider them principle to each module, and should not be an independent component of the release plan.
Modules that were regarded as being of higher importance to the functionality of the app are assigned to be worked on first and foremost. We found that the most "risky" components of the application were those that were cornerstones of the user experience, and so they have been prioritized to be completed by the Project Part 4 deadline. Notably, in coordination with the Project Part 4 requirements, ElasticSearch and Offline Behaviour will also have been implemented by the deadline to facilitate server connectivity.
An image of the release plan with a more sophisticated view of the timeline has been provided here for your convenience.