Fp (function point) là gì

Ở Nhật đợt vừa rồi đc nghỉ tết Tây nên N ngồi học/nghiên cứu phương pháp estimation này để xem lợi hại của nó thế nào, sau khi nghiên cứu xong nên muốn viết 1 bài chia sẻ cho anh em. Hi vọng giúp ích cho anh em PM trong việc estimation

Vì cái phương pháp này nói có mà cả ngày nên N sẽ cố gắng viết ngắn gọn và tóm tắt nhất có thể (hi vọng dễ hiểu T-T). Còn slide thì mọi người có thể tham khảo slide trên fsoft insight (~130 slide, chỉ dành cho người làm fsoft :D) + search thêm trên google.

Bài viết này không nhắm đến việc so sánh với các phương pháp estimation khác. Quy cho cùng estimation cũng chỉ là estimation không thể đúng chính xác 100% và mỗi phương pháp đều có 1 điểm mạnh/yếu riêng của mình.

—-

Khái quát

Như tên gọi, phương pháp Function Point (FP) cơ bản dựa vào việc đánh điểm/trọng số cho các chức năng của phần mềm để từ đó ra được số FP cuối cùng rồi convert ra con số MM dựa trên 1 số parameter như ngôn ngữ gì, fulllife cycle hay 1 phần công đoạn.

Kỹ thuật quan trọng nhất của FP chính là phải biết ĐẾM ILF, EIF, DET, RET, EI, EO, EQ, FTR (giải thích bên dưới),. Đếm có 2 đối tượng cần được đếm là Data và Transaction. Nói đơn giản data tương ứng với table/item trong DB, còn transaction là các hành động/event hay các chức năng chính của phần mềm (như thêm, xóa sửa, hiển thị,…) Đếm data: có 2 loại data

• ILF: data nội bộ application dùng để read/write. Thường là table/file.
  
• EIF: data ngoại bộ của application, chủ yếu dùng để refer/read-only. Thường là table/file.
  

Mỗi loại data sẽ có 2 khái niệm con

• DET: là các item của table mà người dùng có thể HIỂU ĐƯỢC (ví dụ item trên màn hình, ko phải item kiểu ẩn, mang tính kỹ thuật).
• RET: tương ứng với record, hiểu đơn giản là cha của DET. RET được phân loại làm 2 loại chính là Optional và Mandatory. Ví dụ: khi đăng ký acc trên web có 2 loại người dùng là: có request nhận tin thì item bắt buộc là email và không request nhận tin thì email là optional. Ví dụ này, RET này là Optional và có RET = 2. 1 ví dụ khác, khi xuất data thì có 2 loại data là plain text và HTML, với plain text thì item bắt buộc có 1 cái là encoding, với HTML thì item bắt buộc có 2 cái là encoding và HMTL version. Kiểu này là RET mandatory  có số RET = 2. trường hợp không có phân group gì cả thì cứ đếm RET=1

Đếm transaction: có 3 loại transaction

• EI: là transaction có sử dụng các file/table nội bộ. Có xử lý tính toán. Phục vụ cho xử lý bên trong.
• EO: là các transaction có tham chiếu file/table. Mục đích để export thông tin ra. Có xử lý tính toán trước khi export ra.
• EQ: là các transaction có tham chiếu file/table. Không có xử lý tính toán. Mục đích để export thông tin ra. (ví dụ chỉ select từ DB ra)

Mỗi loại transaction lại có 2 khái niệm con là FTR và DET.

• FTR: là EIF or ILF mà transaction tương ứng có sử dụng/tham chiếu
• DET: các item/field được sử dụng/tham chiếu trong transaction. Nói đơn giản là input/output/trigger của transaction đó. (ví dụ checkbox, event, textbox, listbox,…)

—

Dựa vào 1 template có sẵn (FSOFT có), chỉ cần count xong các item đã mô tả ở trên ta sẽ ra con số UFP tức Unadjusted Function Point). Sau đó tiếp tục trả lời 14 câu hỏi về đặc điểm của phần mềm được phát triển để tính toán ra 1 hệ số VAF.  

Cuối cùng ta sẽ có Final FP = UFP * VAF.

Cách tính toán thế nào mọi người không cần quan tâm lắm vì trong excel đã hỗ trợ hết (file excel chỉ dành cho người làm fsoft  :D)

—

Vậy pp FP này phù hợp cho những style dự án nào?

PP này phù hợp cho các dự án đặc thù về nghiệp vụ doanh nghiệp.
Không phù hợp cho các dự án mang nặng tính cá nhân/kỹ thuật/nghệ thuật hay phải tốn thời gian điều tra/nghiên cứu.

—
Sau khi lấy dự án TRA mới làm xong ra  estimate thử để kiểm chứng thì N thấy cũng khá ổn. Nhưng thực sự để ra con số ổn này cũng đã phải tự mình nghiền ngẩm “đếm” đi đếm lại nhiều lần vs so sánh với con số MM thực tế của dự án để hiểu đuợc mình đếm “sai” or “chưa phù hợp” chỗ nào.

Cá nhân N nghĩ, estimation theo pp FP khó nhất là vụ đếm, nếu mình đếm sai, không đúng thì sẽ ra lệch rất nhiều + nếu có quá nhiều data/table kiểu “quá đơn giản” thì FP cũng sẽ bị đội lên rất nhiều.

PP này phù hợp khi mình đã mường tượng ra 1 mức nào đó ở Basic Design sẽ gồm những table gì, item gì.Việc phân tách hóa quá nặng về hướng kỹ thuật như chia tách bảng để tối ưu,v.v… cũng không dc khuyến khích vì đó là thuộc công đoạn sau và end-user không hiểu nó là gì và cũng sẽ gây đội FP lên khá cao.

– Tỉ lệ các công đoạn theo %MM (copy trên mạng)

• Basic Design 20%
• Detail Design 30%
• Coding+UT 30%
• CT1 8%
• CT2 6%
• ST 6%

1 số dự án thì mình dùng tỉ lệ khác như bên dưới

• Requirement/Define specs+basic design:  25%
• Detail Design 15%
• Coding+UT 35%
• IT: 20%
• ST 5%

–

FP/MM theo 1 số ngôn ngữ phổ biết

(năng suất trung bình của thế giới thì phải, không rõ scope)

• Java: 16
• ASP.NET:19.34722
• C:11
• C++:16
• C#:16.20831
• VB:19.06237
• PHP:16
• Python:16

–

Update ngày 2021/07/04

Thật sự bất ngờ vì không nghĩ bài viết này của mình được nhiều người tham khảo thế, ngay cả trong công ty cũng rất nhiều bạn đã search ra bài viết này và hỏi mình nhiều câu hỏi. Sẵn dạo gần đây mình cũng đang phải est 1 số dự án bằng function point cho khách nên sẵn update thêm một số thông tin mình nghĩ là có ích cho mọi người.

• Khó khăn khi đếm FTRs, 
• EIF: mỗi lần đụng vào 1 table cứ đếm +1 FTR
• ILF: mỗi lần đụng vào 1 table cứ đếm +1 FTR
• Với EO thì chỉ count EIF, ILF 1 lần duy nhất (không cộng vào cho nhiều lần gọi, ví dụ select nhiều lần)
• Với EQ thì count input và ouput độc lập (cho dù có trùng nhau)
• Khó khăn không biết đếm RETs thế nào, hình minh họa bên dưới là chân kinh, ai lười thì cứ đếm chính table đang đếm là 1 + số table mà nó refer tới bằng khóa ngoại, cách đếm nhanh này cũng cho độ chính xác tầm 80%, số DETS thì là số columns của bảng

• Năng suất trung bình FP/MM mình post phía trên là không hợp lý với thực tế (mình đoán số đó không phải full life cycle), số full life cycle thị trường Mỹ tầm 10 (search 1 bài post trong công ty có info này),  thị trường Nhật thì mình nghĩ tầm 7-8 thôi , dạo này hot trend low code thì năng suất low code outsystem tầm 14. Anh em VN est thì cứ ghi tầm 10-12 chắc ổn (tùy ngôn ngữ) (tùy công ty, quốc gia thì số khác nhau nha)
• Dự án migration thường nên est theo số LOC nhưng nếu bị khách yêu cầu est theo FP thì cũng không vấn đề, vẫn đề nằm ở chỗ tỉ lệ các công đoạn. Ví dụ migration 1:1 thì bạn không phải viết requirement viết specs hay thậm chí base design nên % là 0, giai đoạn test UT, IT, ST thì vì là test compare nên create test case là 1 nhưng excute là x2 nên cần phải tính lại % tương ứng. Ví dụ CT 20% cho dev mới thì migration có thể là 32% (=20%*60%*2+ 20% *40%, giả sử  tỉ lệ create là 40%, test là 60%). Vì vậy số % tổng có thể bé hay lớn hơn 100% của final FP tính ra. Lưu ý nữa làm migration thì năng suất phải cao hơn code mới là điều hiển nhiên nhé.
• Khi est FP việc trả lời list câu hỏi GSC để tính điểm là tối quan trọng để tính toán độ phức tạp của hệ thống từ đó sẽ có thay đổi trong số FP final rất lớn. Do đó hãy nhớ đọc hiểu và trả lời thật kỹ và chính xác list 14 câu hỏi này.
• Nốt luôn các công thức cho mọi người
• AFP = UFP * VAF
• UFP＝FPs of ILF/EIF＋FPs of EI/EO/EQ
• VAF = (TDI * 0.01) + 0.65
• ILF, ELF, EI, EO,  EQ point table thì bà con google nhé

Một số checklist khi est bằng FPT

• Không đếm duplication (ví dụ: màn hình khởi tạo search all + màn hình search là 1 or tái sử dụng >80%, chức năng export ra csv tái sử dụng phần lớn logic chức năng search,…)
• Không đếm double (dễ nhầm, ví dụ màn hình cha có hyperlink, click vào ra màn hình con, màn hình cha coi chừng đếm double)
• Cân nhắc tính tái sử dụng, common (layout, same function,…) để loại bỏ FP cho các chức năng trùng.
• Các chức năng quản lý DB master thường rất dễ, cần hạ FP thấp nhất, nếu không số lượng nhiều sẽ đội số FP rất lớn
• Đảm bảo mỗi loại transaction (EI/EO/EQ) của mỗi chức năng (1 chức năng con của màn hình) chỉ có duy nhất 1 xử lý
• Verify thật kỹ các chức năng có FP >10 (vì khi breakdown ra đến level function như thêm xóa sửa thì chỉ trường hợp cực khó FP mới đội >10)
• Khi count data ILF cho loại file, chỉ nên count cho các chức năng nghiệp vụ để xử lý data nghiệp vụ và liên kết file giữa các chức năng.
• List function trên excel có thể khác với list file vật lý or thiếu sót chức năng trong nội bộ file vật lý. Tóm lại cần mapping kĩ số lượng function cha, function con trong list function so với số lượng file function vật lý và function con trong đó.