Để thầu dự án phần mềm, bạn cần viết bản thầu dự án phần mềm bằng tiếng Anh và gửi cho khách hàng. Tài liệu này là mẫu thầu bằng tiếng Anh, gồm có các phần: Mục đích và mô tả hệ thống Thiết kế sơ bộ hệ thống Ước lượng chi phí Giới thiệu nhóm triển khai Kế hoạch thực thi và hoàn thiện.
[Project Name] Business Proposal This document is a proposed business plan for Easy Journey project, written by [Team Name] Team The Team operates in Agile Methodology, meaning tasks will be reevaluated and re-prioritized after each sprint All numbers given in this document is to provide a tentative, but not 100% accurate of the project plan Hanoi, December 15, 2014 Easy Journey Table of Contents Innovation Hub Team Easy Journey TERMINOLOGY No Name Admin Important points/Pole s User Reputation Report Reliability Favorite Route table Current Description Who manage the website - These terms are used interchangeably - Before the software is deployed, admin MANUALLY creates “important points”/poles (most of the time, the crossroads) and connect the points to makes lines As a result, we have a map of traffic Who use the apps Note By default, all the lines are green, indicating that the traffic is good Should congestion arise (reported by users) in certain area, the corresponding lines will AUTOMATICALLY change to yellow/red/dark red They are user and reporter at the same time (using the app and receiving notification from the system) The reputation of users - If the user use the app frequently and give true report frequently, he will gain reputation (Score) - If he was reported and verified that he reported false message, he will lose score The message users send to server types: – Congestion 2– Ambulance – Fire Server uses function to determine the reliability of a The function is not defined yet hypothesis: “From A to B currently has a We must calculate based on: congestion”; and then to determine the level of 1) Number of users reported congestion in the same route congestion (Very high, normal, low) 2) Reputation of the reporters *** When reporting: Reporters only report whether congestion is happening or not They not have to report it is strong/normal/small congestion; because people have different standard and we cannot rely on that A table (on backend) detailing: Favorite route maybe the route from home to office or - User ID office to home - Device ID - Their favorite routes A table (on backend) detailing: When user tap on “Navigate Me” (from point A to point Innovation Hub Team Easy Journey Route table Congestion Table Traffic Map 10 Notificatio n - User ID Device ID Their current routes B), the suggested route on smartphone will be sent and saved in backend as current route of that user When he reaches the destination, the corresponding record in Current Route Table will be deleted It is saved in server side, specifying: - Every time users report on the system, congestion - The beginning point of congestion table may be updated - The end point of congestion - Every 10 mins, the table will be updated (the - Level of congestion reliability score reduce by a certain amount – - Reliability Congestion does not last forever – they only last for several hours If no more users report on the congestion, the congestion might have ended.) - Every time the Congestion table is updated, it will be compared with Favorite Route table and Current Route table to send notifications to users if there are matches The map on the server side, managed by admin, On server, although the traffic map is updated displaying the current traffic status (green, yellow, AUTOMATICALLY, the admin can still modified it red, dark red) manually (Correction) The map on the app that displays current traffic status Any messages sending to users Notification for congestion: - Type 0: Start_Route_Notif: When you user choose route starting point A to destination B, if there is congestion on the route, he will receive an alert to choose another route - Type 1: Current_Route_Notif and Fav_Route_Notif When there is a match between Congestion Table and Favorite Route table or Current Route table, users will receive notification type - Type 2: Location_Notif: When user is near a congestion, he will receive notification type Innovation Hub Team I Requirement The Client has a running system including a website (front end + back end) and an iOS application The main purpose of the system is to provide end-users to have an overview of traffic status in his area Furthermore, the system is able to navigate him from one starting location to his chosen destination, avoiding congestion (traffic jam) in his route To achieve this, users must be able to report congestion by his smart phone, and the server must be able to record the report, calculating the reliability of the report to decide whether to verify/confirm it is a true report and update other users accordingly so that they can avoid congestion Finally, users can also report about fire and accidence The Client wants to: • • • Revamp the website Revamp iOS app Develop Android app from the scratch The new features include: • • • • • • Live traffic data Navigation from starting point to destination along with updated travel routes depending on traffic conditions Notifications - Favourite/recurring routes can be saved by the user and they are notified of any changes to those streets/routes within a specified time period For example, my route to work everyday is saved and if there are any changes between 6am-9am and 3pm-5pm when I travel on that route I am notified through a push notification Push notifications to users within a certain radius of a location* Scoring system for reports and data from our users Automatically populate road markers for each street and in each direction placed within a certain range from each other Innovation Hub Team II Envision of complete system Main flow: Reporting & Notification Mechanism Figure 1: Main flow - Reporting & Notification Mechanism of complete (to-do) system Explanation • The system provides a way for admin to MANUALLY create “important points”/poles (most of the time, the crossroad) and connect the points to makes lines As a result, we have a map of traffic By default, all the lines are green, indicating that the traffic is good Should congestion arise (reported by users) in certain area, the corresponding lines will AUTOMATICALLY change to yellow/red/dark red ***Note: Admin must manually create “important points”/poles because different cities have different poles If this software is run in Hanoi, admin will spend Innovation Hub Team • • • • • • one day to pin poles in the map, then connect them and then save it He will have a default traffic map of Hanoi (all is green by default) in just day and it will be used forever Users can send report (congestion, accidence, fire) to server Server records the report on “Report” table (Currently named “Emergency”, but should be changed to “Report”) Server finds starting point (A) and ending point (B) of congestion automatically Server calculates the reliability of hypothesis H: “There is congestion from A to B” based on all report of users near that area If H is true, server calculate the level of congestion and choose the color (yellow, red, dark red) to update Congestion table and on the Traffic Map H = true means there is a new record on Congestion table If Congestion table has no record, then in the area has no congestion Server notifies users on types: Route-based (Type 1) and Location-based (Type 2): o If user x registered a favorite route or a current route to server, the information will be recorded in Favorite Route table and Current Route table o Server compares Congestion table with Favorite Route table and Current table If there is a match, then it means a user is going to take a congested route Server will send notification to that user o The user receive the notification: If he changes the route and tap on “Update new route” then new route will be updated to Current Route table and the flow goes as normal If the changes the route (he actually drives to other route to avoid congestion) but not tapping on “Updating new route” (because he is busy), he will continue to receive Notification Type (Location-based notification) If he does not change the route and does not update information to the system, he will continue to receive Notification Type + *** Suggestion: In future we could implement new function: Report could a “Broken car” type and we will connect with Mechanic Store in this business This is a way to monetizing the app Innovation Hub Team III Envision of current system Main flow: Reporting & Notification Mechanism Figure 2: Main flow - Reporting & Notification Mechanism of current system Explanation • • • • Text with black color: The current system currently supports Text with orange color: The current system is very likely not supporting Text with red color: The current system is for sure not supporting The map is painted with green lines, but we don’t know where the data of points and lines are store Currently there are main tabs: Home, Emergency, Map Control, Send Messages, Logout We can see the green map in “Map Control”, but not see a table storing locations of the point Innovation Hub Team • • • • THERE IS HIGH POSSIBILITY THAT LOCATIONS OF POINTS ARE HARD-CODED, MEANING YOU CANNOT BRING THIS SOFTWARE TO OTHER CITIES Users can send report (congestion, accidence, fire) to server Server records the report on “Report” table (Currently named “Emergency”, but should be changed to “Report”) Admin read the reports by himself and manually paint red on the congested lines The system notifies users when they are near congested lines (Not sure if current system supports this) Innovation Hub Team IV Scope • • Based on the envision of the complete system and the current system, we defined what is done and what will be added as well as improved As detailed in Easy_Journey_Scope_Budget_Timeline_20141215_v1.0.xlsx V Budget • • • • VI Total development effort: 100 man-days Total effort: 130 man-days (including development, user acceptance test, system integration and project management effort) Total cost: $15,600 As detailed in Easy_Journey_Scope_Budget_Timeline_20141215_v1.0.xlsx Timeline • • • • • VII From Dec 16 to Dec 20, 2014: Signing NDA and contract Project starts on: Dec 22, 2014 Project finishes on: Mar 8, 2015 Project takes: sprints (each sprint: weeks) As detailed in Easy_Journey_Scope_Budget_Timeline_20141215_v1.0.xlsx Payment term • • • • VIII Upfront payment: 20% on Dec 22, 2014 After Sprint 2: 30% on Jan 18, 2015 After Sprint 3: 30% on Feb 15, 2015 After UAT release: 20% on Mar 8, 2015 Team structure • • • • • IX 01 Project Manager (Scrum Master + Project Owner) 01 Web Developer 01 iOS Developer 01 Android Developer 01 Graphic Designer (Part-time) Management & Communication Management & Collaboration tool • • Trello, using Kanban board for better vision on the progress of the project Reason: We run in agile/Scrum software development methodology Trello adapt to agile by using the Kanban board as below: Innovation Hub Team 10 Figure 3: Kanban Board in Trello • • Each task will go through To-do, Develop, Test and then Approve Each task detail will be as following (Who will it, when is due date, What is the task): Figure 4: Detailed task in Trello Innovation Hub Team 11 • The Client can look at the Kanban board and task detail to see the real-time progress of the project Communication • • X Daily meeting over Skype (10 mins between Abdul and Thomas) Thomas will report on: o What has been done yesterday o What will be done today and be available tomorrow o What is the current difficulty Daily meeting over Skype (30 mins between Vietnamese team) The team reports the same to Thomas, following with discussion of the solution Partnership choice • • • • Upon completing the project and seeing our capability, you could choose to: Have us as remote development team Invest in us as a software development company The team to help you rollout Easy Journey in Asia! Innovation Hub Team 12