Skip to content

Release Plan

Z-Red edited this page Apr 7, 2018 · 55 revisions

Completed Release Plan / Future Planning

At this point, the application is completed and all of the following requirements have been implemented:

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.

Messaging system

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.

Payment System

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.

Expanding Platforms

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.

Task Provider Groups

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.

Task Categories

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

TODO

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

Release Plan (OLD)

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.

Requirements

Use Case Category Use Case Number Use Case Name Use Case Dependencies
Task Basics UC 01.01.01 AddTask
Task Basics UC 01.02.01 ViewTaskList UC 01.01.01
Task Basics UC 01.03.01 EditTask UC 01.01.01, UC 01.02.01
Task Basics UC 01.04.01 DeleteTask UC 01.01.01
Task Details UC 02.01.01 ViewTaskDetails UC 01.01.01
User Profile UC 03.01.01 MakeProfile
User Profile UC 03.02.01 EditProfile UC 03.01.01
User Profile UC 03.03.01 ViewProfile UC 03.01.01
Searching UC 04.01.01 SearchTasks UC 01.01.01
Task Bidding UC 05.01.01 BidOnTask UC 01.01.01, UC 02.01.01
Task Bidding UC 05.02.01 ViewProviderBiddedTasks UC 05.01.01
Task Bidding UC 05.03.01 TaskBidNotification UC 05.01.01
Task Bidding UC 05.04.01 ViewRequesterBiddedTasks UC 05.01.01
Task Bidding UC 05.05.01 ViewRequestedTaskBids UC 05.01.01
Task Bidding UC 05.06.01 AcceptBid UC 05.05.01
Task Bidding UC 05.07.01 DeclineBid UC 05.05.01
Task Assigned UC 06.01.01 ViewProviderAssignedTaskList UC 05.06.01
Task Assigned UC 06.02.01 ViewRequesterAssignedTaskList UC 05.06.01
Task Done UC 07.01.01 SetTaskDone UC 05.06.01
Task Done UC 07.02.01 RepostTask UC 05.06.01
Photographs UC 09.01.01 AddTaskPhotograph UC 01.01.01
Photographs UC 09.02.01 ViewTaskPhotograph UC 02.01.01
Geolocation UC 10.01.01 SpecifyTaskLocation UC 01.01.01
Geolocation UC 10.02.01 ViewTaskLocation UC 02.01.01
Geolocation UC 10.03.01 RecentTaskMapView UC 10.02.01