thiết kế game quản lí nông trại trên facebook

Game quản lý nông trại được ra đời với chức năng như người dùng có thể mua thú, nuôi lớn và bán đồng thời trang hoàng nông trại, tặng quà cho bạn ..... Giúp người dùng phát triển tính sa

GAME QUẢN LÝ NÔNG



Lời nói đầu

Hiện nay người dùng đang sử dụng game trên FB một cách ồ ạt Nhằm đáp ứng nhu cầu người dùng cũng như kiếm tiền qua game trên mạng Game quản

lý nông trại được ra đời với chức năng như (người dùng có thể mua thú, nuôi lớn và bán đồng thời trang hoàng nông trại, tặng quà cho bạn .) Giúp người dùng phát triển tính sang tạo bằng cách trang trí nông trại, Thông qua forum được tích hợp trong app giúp mọi người có thể chia sẽ cảm giác tình cảm của mình với bạn bè

Mục lục

1 Giới thiệu 5

2 Phạm vi dự án 5

3 Cơ cấu tổ chức 6

3.1 Sơ đồ tổ chức 6

3.2 Mô tả cơ cấu tổ chức: 7

4 Lên kế hoạch 10

4.1 Work breakdown 10

4.2 Sơ đồ work breakdown 10

4.2.1 Chi tiết work breakdown 10

4.3 Lên kế hoạch 17

4.3.1 Cơ cấu tổ chức 17

4.3.2 Master schedule (thời gian dự tính cho từng phase hoàn thành) 18

4.3.3 Dev Phase list (Danh sách giai đoạn phát triển) 18

4.3.4 Man Power plan 19

4.3.5 Deliverable list 19

4.3.6 Communication Plan 20

4.4 Ước lượng 21

4.4.1 Project Scope Estimate 21

4.4.2 Project Size Estimation 21

4.4.3 Effort Estimation 22

4.4.4 Staff Estimation 22

4.4.5 Duration Estimation 23

4.4.6 Cost Estimation 24

4.5 Schedule 25

5 Quản lý cấu hình: 26

5.1 Email (web mail zimbra) 27

5.2 Chat (pidgin) 28

5.3 SVN/GIT contact với email 29

5.4 Mô hình Phân nhánh 33

Hệ thống TRAC 34

5.4.1 Product Road map 34

5.4.2 Milestone 34

5.5 Commit (qa tracpot) 38

5.6 Metric (Biểu đồ số lượng người truy cập game) 38

5.6.1 DAU (Daily Active User) 39

5.6.2 MAU (Monthly Active User) 39

5.7 Tool support (Putty, Jing, Win SCP …) 39

5.7.1 Putty 39

5.7.2 Jing 40

5.7.3 Win SCP 40

6 Quản lý chất lượng 42

6.1 Tickets 42

6.1.1 Bugs/Task/Test cases 42

6.1.2 Công cụ chụp ảnh (Jing) 44

7 Quản lý rủi ro 45

7.1 Quy trình quản lý rủi ro 45

7.2 Nhận diện rủi ro 45

7.3 Phân tích rủi ro 46

7.3.1 Phân tích khả năng xuất hiện của rủi ro 46

7.3.2 Phân tích mức tác động của rủi ro 46

7.3.3 Ước lượng và phân loại rủi ro 47

7.4 Kiểm/Giám soát rủi ro 47

1 Giới thiệu

Game về quản lý nông trại trên FB (cho phép người dùng có thể mua thú, nuôi lớn và bán đồng thời trang hoàng nông trại, tặng quà cho bạn ) Đây là game mang tính sáng tạo và là dạng game đang rất thịnh hành trên mạng hiện nay Trong game cũng tích hợp diễn đàn là nơi nhằm giúp mọi người chia sẻ cảm giác của mình trong game cũng như đời thường …

Một thuận lợi lớn là FB hổ trợ người phát triển ứng dụng tạo ứng dụng một cách dễ dàng Cũng vậy FB cung cấp miễn phí các hàm có sẵn - các hàm tương tác nhằm tiện lợi cho việc phát triển ứng dụng trên môi trường của FB

2 Phạm vi dự án

Game chỉ ứng dụng trên môi trường FB

Thời gian: 2 tháng cho version đầu tiên

Ngôn ngữ: Python, Javascript, Template, css, flash, as …

Sử dụng môi trường linux để tương tác với dữ liệu, server …

Game Designer

Boss

SuperPoke Product Manager (PM)

Boss

SuperPoke Product Manager (PM)

Logger

Sơ đồ tổng quan mối quan hệ giữa các thành viên giai đoạn 2

3.2 Mô tả cơ cấu tổ chức:

Game designer: Người phát triển game

Hình của spec

Product Manager: Chịu trách nhiệm chính trong project, quản lý devs, qa và

contact với boss và PM khác

Logger: Quản lý những log file (trong database và trên web) khi người dùng

chơi game Đồng thời tạo log file tickets cho tất cả các products

Sau khi implement log tickets, hệ thống có thể ghi lại sử truy suất của user tới người sử dụng

Graphic designer:

4 Lên kế hoạch

4.1 Work breakdown

4.2 Sơ đồ work breakdown

4.2.1 Chi tiết work breakdown

1 Phân tích

a Phân tích yêu cầu chức năng

b Phân tích cách thức giao tiếp các chức năng với FB

2 Thiết kế

a Thiết kế cơ sở dữ liệu

b Thiết kế mạng (support từ IT ở US)

c Thiết kế chức năng

d Thiết kế giao diện

e Thiết kế tổng quan

3 Chức năng chính giai đoạn 1

a Cho phép người dùng mua con thú, cây cối, vật dụng nông trại

 Mua Ranch Expanation

b Cho phép người dùng bán con thú

c Cho phép người dùng bán vật dụng nông trại (cây, hàng rào, thùng nước )

 Bán Cây, Hàng rao, Vật dụng

f Zoom nông trại

 Cho phép dịch chuyển nông trại

 Phóng to, thu nhỏ nông trại

4 Chức năng chính giai đoạn 2

c Set up app (app đã có sẵn)

d Học cách test trên app có sẵn (contact với qa bên US)

e basic function

f test log

6 Coding

a Front end

 Common code (code xử dụng chung dựa trên nền các app khác)

 code xu ly chung (cho app quản lý nông trại)

 basic code flash

 Review base code

 Cấu hình app

 Viết test cases (qa)

 Support devs kiểm lổi code (qa)

 PM (Product manager): Giám sát và hổ trợ dev,qa đồng thời contact với game designer cho feature chính, contact với post

b Back end (code chức năng):

Cho phép người dùng mua con thú, cây cối, vật dụng nông trại

 Trang trí block items (ví dụ cây và hàng rào không được đè lên nhau)

 Trang trí non block items (ví dụ như gạch lót đường, nền cỏ )

Cho thú ăn, uống nước, dọn rác (poop), lớn và thu hoạch lấy tiền

 Cho phép dịch chuyển nông trại

 Phóng to, thu nhỏ nông trại

7 Testing

a Unit test (developer and QA tes parallel)

Cho phép người dùng mua con thú, cây cối, vật dụng nông trại

 Bán Cây, Hàng rao, Vật dụng

 Bán Thùng nước Cho phép người dùng trang trí nông trại bằng những vật dụng mình đã mua

 Trang trí block items (ví dụ cây và hàng rào không được đè lên nhau)

 Trang trí non block items (ví dụ như gạch lót đường, nền cỏ )

Cho thú ăn, uống nước, dọn rác (poop), lớn và thu hoạch lấy tiền

 Cho phép dịch chuyển nông trại

 Phóng to, thu nhỏ nông trại

b Integration test (QA test)

Cho phép người dùng mua con thú, cây cối, vật dụng nông trại

 Trang trí block items (ví dụ cây và hàng rào không được đè lên nhau)

 Trang trí non block items (ví dụ như gạch lót đường, nền cỏ )

Cho thú ăn, uống nước, dọn rác (poop), lớn và thu hoạch lấy tiền

 Cho phép dịch chuyển nông trại

 Phóng to, thu nhỏ nông trại

c System test (QA test trên đa môi trường như xp, vista với multiple browsers như IE, FF, Chrome, Safari)

Cho phép người dùng mua con thú, cây cối, vật dụng nông trại

 Trang trí block items (ví dụ cây và hàng rào không được đè lên nhau)

 Trang trí non block items (ví dụ như gạch lót đường, nền cỏ )

Cho thú ăn, uống nước, dọn rác (poop), lớn và thu hoạch lấy tiền

 Cho phép dịch chuyển nông trại

 Phóng to, thu nhỏ nông trại

d Live test (QA test): Môi trường người dùng

8 Delivery

4.3 Lên kế hoạch

4.3.1 Cơ cấu tổ chức

4.3.2 Master schedule (thời gian dự tính cho từng phase hoàn thành)

4.3.3 Dev Phase list (Danh sách giai đoạn phát triển)

4.3.4 Man Power plan

4.3.5 Deliverable list

4.3.6 Communication Plan

4.4 Ước lượng

4.4.1 Project Scope Estimate

4.4.2 Project Size Estimation

4.4.3 Effort Estimation

4.4.4 Staff Estimation

4.4.5 Duration Estimation

4.4.6 Cost Estimation

4.5 Schedule

5.1 Email (web mail zimbra)

Hệ thống mail (4GB) có thể tương tác với GIT, TRAC: khi có một version được tạo cũng như tình trạng của ticket thay đổi sẽ update vào hộp mail nếu đã set filter cho nó

5.2 Chat (pidgin)

Hệ thống chat (thông qua chương trình chat phổ thông Pidgin) với account là email của hộp mail trên zimbra cho phép chỉ những người trong hệ thống mail này mới thấy lẩn nhau Giao tiếp dễ dàng và thuận tiện và bảo mật

5.3 SVN/GIT contact với email

Sau khi hoàn thành một ticket thực hiện git commit hệ thống sẽ lưu lại version vừa mới thực hiện dưới dạng:

Một email sẽ được gởi tới hộp mail của những ai có nhu cầu filter nó:

Ticket sẽ được cập nhật tình trạng với commit cho nó:

Tình trạng ticket sau khi QA update: Trạng thái sẽ là:

Hình ticket bị đóng (chụp milestone có ticket đó bị đóng)

5.4 Mô hình Phân nhánh

Code bao gồm một nhánh chính sau đó chia nhiều nhánh con, mổi nhánh sẽ được tạo với một mục đích riêng (ví dụ như một chức năng nào đó) Sau khi nhánh A hoàn thành chức năng ở nhánh con sẽ merge nhánh con này xuống nhánh chính rồi đẩy lên môi trường người dùng Nếu ở môi trường người dùng có xảy ra lỗi thì sẽ revert lại version cũ

Hệ thống TRAC

5.4.1 Product Road map

Quản lý thông tin của milestone, document

5.4.2 Milestone

Khi một chức năng mới xuất hiện, PM sẽ tạo ra một milestone, tạo tickets (những tasks) assign cho một hoặc nhiều developer tùy theo độ khó của milestone và thời gian hoàn thành milestone đó

5.4.2.1 Tasks/Testcase/Bugs

Task (nhiệm vụ, công việc do PM viết assign cho dev)

QA test cases (sử dụng cho mục đích test đảm bảo cover tất cả các trường hợp):

Bugs khi qa viết và assign cho dev

5.4.2.2 Spec (tài liệu liên quan tới milestone)

Mỗi milestone thường có một hoặc nhiều file spec (.pdf) mô tả trong milestone này sẽ làm thêm chức năng nào File này do game designer tạo

5.5 Commit (qa tracpot)

Xác nhận tạo phiên bản mới (với 1 ID phân biệt) có sữa đổi chức năng nào đó

Hệ thống Git giúp chúng ta thực hiện một cách dễ dàng Đông thời cũng tương tác với tickets liên quan để xét tình trạng tickets một cách tự động xuống QA cho việc testing

5.6 Metric (Biểu đồ số lượng người truy cập game)

5.6.1 DAU (Daily Active User)

5.6.2 MAU (Monthly Active User)

5.7 Tool support (Putty, Jing, Win SCP …)

5.7.1 Putty

Một chương trình cho phép truy suất hệ thống linux từ xa

6 Quản lý chất lượng

Sử dụng free software TRAC nhằm lưu lại tất cả các test cases, bugs, những comments trong từng tickets giúp qa và devs có thể dễ dàng contact với nhau về tình trạng của tickets đó TRAC tự động chuyển trạng thái khi devs fix task/issue …, kết hợp với Jing tool để upload bugs’ images to server

6.1 Tickets

Nơi quản lý những công việc PM đã liệt kê cho devs viết chương trình và QA dựa theo nó mà test Đồng thời tickets cũng là những issues QA tìm ra trong quá trình test hoặc những test cases qa viết để chuẩn bị test khi nhận được document từ PM

6.1.1 Bugs/Task/Test cases

Tất cả những tickets (bugs/tasks/testcases) khi được tạo sẽ được người tạo assign tới tên của developers, thì developer đó sẽ nhận được một email thông báo nội dung của ticket Sau khi commit (hoàn thành một ticket nào đó) trên hệ thống GIT sẽ

tự động cập nhật tình trạng của ticket xuống qa Sau khi qa test sẽ manual cập nhật tình trạng của ticket (fixed, reopen tùy theo ticket đó fix hay chưa) đồng thời comment vào ticket cho rõ ràng hơn Lúc này developer sở hữu ticket nay sẽ nhận được nội dung về tình trạng của ticket này để xem có fix tiếp hay không

Task

Test case

Bugs

6.1.2 Công cụ chụp ảnh (Jing)

Công cụ được thiết kế để phục vụ QA chụp ảnh và upload ảnh lên server của mình

7 Quản lý rủi ro

Thời gian ngắn e rằng không kịp:

 Làm thêm giờ + cuối tuần

 Contact với họ ngay khi có sự cố (email, chat)

Thời gian 2 tuần không đủ cho việc học cách test hiệu quả vì không có nhiều milestone trong 2 tuần trên một ứng dụng

 Flexible bằng cách học cách test trên nhiều ứng dụng

7.1 Quy trình quản lý rủi ro

7.2 Nhận diện rủi ro

 Khi bắt đầu, trưởng dự án tổ chức buổi hợp với tất cả các thành viên trong nhóm để đề ra tất cả các rủi ro của dự án

 Trưởng dự án tổ chức các buổi họp định kỳ sáng thứ hai hàng tuần để

phát hiện rủi ro mới

 Xác định rủi ro dựa trên các nguồn sau:

 Ngân sách/ nguồn tài trợ cho dự án

 Thời gian thực hiện dự án

 Thay đổi về phạm vi yêu cầu của dự án

 Khó khăn về kỹ thuật

 Vấn đề về nhân lực

 Hợp đồng giữa hai bên trong kinh doanh

 Môi trường, pháp luật, văn hóa …

 Sử dụng phương pháp:

 Ý kiến chuyên gia (Product manager khác)

 Sử dụng lịch sử của những ứng dụng khác (đã trải qua các thời kì như thế nào)

7.3 Phân tích rủi ro

7.3.1 Phân tích khả năng xuất hiện của rủi ro

Likelihood Level table

Value Description

1 Hiếm khi xuất hiện

2 Khả năng xuất hiện thấp, chỉ xuất hiện trong những điều kiện nhất định

3 Khả năng xuất hiện trung bình

4 Khả năng xuất hiện cao, trong nhiều dự án

5 Khả năng xuất hiện rất cao trong hầu hết dự án

7.3.2 Phân tích mức tác động của rủi ro

Impact Level table

Value Description

1 Chi phí tăng và tiến độ trượt không đáng kể

7.3.3 Ước lượng và phân loại rủi ro

 Risk points = Impact * Likelihood

 Priority Rank

 Low: Risk point<=3

 Medium: 3< risk points <10

 High: risk points>=10

 Thời gian ngắn có thể không kịp -> làm thêm giờ vào thứ 7 cuối tuần

 Kĩ thuật khó-> hỏi người có kinh nghiệm (bên US) hoặc được train trực tiếp

2 Chi phí tăng dưới 5% , tiến độ trượt dưới 5%

3 Chi phí tăng: 5-10% , tiến độ trượt: 5-10%

4 Chi phí tăng: 10-20% , tiến độ trượt: 10-20%

5 Chi phi tăng và tiến độ trượt vượt 20%

 Template cho quản lý rủi ro