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ì thì đếm RET=1.
Đếm transaction: Có 3 loại transaction như sau:
- 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 một template có sẵn, chỉ cần count xong các item đã mô tả ở trên ta sẽ ra con số UFP (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 một hệ số VAF.
Cuối cùng ta sẽ có Final FP = UFP * VAF.
Cách tính toán thế nào chúng ta không cần quan tâm lắm vì trong Excel đã hỗ trợ.
Vậy phương pháp 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 mới làm xong ra estimate thử để kiểm chứng thì 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ố man-month (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.
Estimation theo FP khó nhất là công đoạn đếm. Nếu đếm sai, không đúng thì sẽ ra lệch rất nhiều, cộng với việc 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,… cũng không được 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ẽ khiến cho đội FP lên khá cao.
Tỉ lệ các công đoạn theo %MM:
- Basic Design 20%
- Detail Design 30%
- Coding+UT 30%
- CT1 8%
- CT2 6%
- ST 6%
Một số dự án thì 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ến:
- Java: 16
- ASP.NET:19.34722
- C:11
- C++:16
- C#:16.20831
- VB:19.06237
- PHP:16
- Python:16
Khó khăn khi đếm FTRs:
- EIF: mỗi lần đụng vào 1 table, đếm +1 FTR
- ILF: mỗi lần đụng vào 1 table, đế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 post phía trên là không hợp lý với thực tế (dự đ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 tầm 7-8, gần đây hot trend low code thì năng suất low code outsystem tầm 14. Team ở VN est thì ghi tầm 10-12 (tùy ngôn ngữ) (tùy công ty, quốc gia thì số khác nhau).
- 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.
- 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.
- Cuối cùng là các công thức cần ghi nhớ:
- 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
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 đó.
Theo Trần Hồ Lê Nguyên's Blog
