Phân tích điểm chức năng (Function Point, FP)
1. Tổng quan
A. Định nghĩa
Điểm chức năng (Function Point, FP) là phương pháp đo lường kích thước chức năng (Functional Size Measurement, FSM) nhằm định lượng lượng chức năng (functionality) mà phần mềm cung cấp cho người dùng, độc lập với ngôn ngữ·công nghệ·nền tảng triển khai. Bằng cách nhận diện yêu cầu người dùng thành chức năng dữ liệu và chức năng giao dịch rồi cộng dồn trọng số theo độ phức tạp của từng chức năng, nó quy đổi "kích thước của khối lượng công việc cần xây dựng" thành con số trước khi viết dù chỉ một dòng mã.
Điểm xuất phát của điểm chức năng là câu hỏi căn bản "đo kích thước phần mềm bằng cái gì". LOC (Lines of Code) truyền thống đếm khối lượng mã đã hoàn thành, nhưng cùng một chức năng viết bằng assembly thì tới hàng nghìn dòng, bằng ngôn ngữ bậc cao thì chỉ vài chục dòng, sinh ra nghịch lý năng suất càng cao thì kích thước trông càng nhỏ. Hơn nữa, mã chỉ có thể đếm sau khi phát triển xong, mâu thuẫn với mục đích vốn có của ước lượng là "dự báo trước khi khởi công". Điểm chức năng hóa giải nghịch lý này bằng cách dời tiêu chuẩn đo từ "mã" sang "chức năng mà người dùng cảm nhận". Ở góc độ người dùng, giá trị mà "đăng ký khách hàng", "tra cứu doanh thu theo tháng" cung cấp là như nhau dù công nghệ triển khai là gì, nên đo kích thước theo chức năng sẽ cho một thước đo trung lập về công nghệ và có thể so sánh.
Ý nghĩa của sự chuyển đổi này là lớn. Điểm chức năng không đơn thuần là công cụ hỗ trợ ước lượng mà là phép ẩn dụ để coi phần mềm như một "đối tượng kỹ thuật có thể đo lường". Nó cho phép so sánh năng suất (FP/Man-Month) hay mật độ lỗi (lỗi/FP) của hai hệ thống phát triển bằng ngôn ngữ·framework khác nhau trên cùng một thước đo, và thay thế những tranh cãi hao mòn giữa bên đặt hàng và bên thực hiện về "đây là dự án trị giá bao nhiêu" bằng ngôn ngữ chung của kích thước khách quan. Đó cũng chính là lý do các dự án tin học hóa công của Hàn Quốc đã chọn điểm chức năng làm chuẩn pháp định cho việc tính giá.
B. Bối cảnh ra đời và sự cần thiết
Điểm chức năng được Allan J. Albrecht của IBM đề xuất năm 1979. Khi đó trong nội bộ IBM không có thước đo chung để so sánh năng suất phát triển của các ứng dụng viết bằng ngôn ngữ khác nhau, và vấn đề so sánh dựa trên LOC bị nhiễu bởi khác biệt ngôn ngữ rất nghiêm trọng. Albrecht đã nghĩ ra điểm chức năng từ sự thấu hiểu rằng đo "lượng chức năng truyền tới người dùng" sẽ cho chỉ số năng suất độc lập với ngôn ngữ; sau đó năm 1986 IFPUG (International Function Point Users Group) được thành lập để chuẩn hóa·tinh chỉnh các quy tắc đếm. Hiện nay quy tắc đo của IFPUG được quản lý dưới dạng CPM (Counting Practices Manual) và đã được chuẩn hóa quốc tế thành ISO/IEC 20926.
Ở Hàn Quốc, sự cần thiết của điểm chức năng càng nổi bật khi tính thích đáng của ngân sách và tính minh bạch của việc đặt thầu trong các dự án phần mềm công trở thành vấn đề trọng tâm của kiểm toán·giám sát. Việc tính giá dựa trên công sức đầu vào (Man-Month) trước đây lấy "con người được đầu tư lâu bao nhiêu" làm căn cứ, sinh ra động lực ngược và tranh chấp khi năng suất càng thấp thì giá càng cao. Trước tình hình đó, chính phủ đã định hình việc tính chi phí phát triển theo điểm chức năng thông qua Hướng dẫn tính giá dự án SW, tạo cấu trúc tưởng thưởng cho việc nâng cao năng suất bằng cách gắn chi phí với kích thước của sản phẩm (chức năng). Nghĩa là điểm chức năng vừa là kỹ thuật đo lường kỹ thuật, vừa là hạ tầng thể chế chống đỡ trật tự giao dịch công bằng.
C. Các đặc tính bản chất của điểm chức năng
Để điểm chức năng vận hành như một thước đo kích thước tốt, nó phải có vài tính chất, và thực tế được thiết kế đúng như vậy. Thứ nhất, độc lập công nghệ — đối tượng đo là yêu cầu người dùng chứ không phải triển khai, nên không bị chi phối bởi ngôn ngữ·DBMS·kiến trúc. Thứ hai, khả năng áp dụng sớm — có thể đo ngay từ giai đoạn phân tích khi yêu cầu·đặc tả chức năng được sắp xếp, cung cấp căn cứ ở thời điểm đặt thầu·ký hợp đồng. Thứ ba, khả năng lặp lại — vì quy tắc đo được tài liệu hóa nên các người đo khác nhau dù đo độc lập vẫn hội tụ về kết quả tương tự (tuy không phải khách quan hoàn toàn, và tồn tại sai lệch theo mức thành thạo của người đo).
Mặt khác, giới hạn cũng rõ ràng. Vì điểm chức năng đo chức năng người dùng nhìn thấy, nó khó nắm bắt tốt các yêu cầu phi chức năng như hiệu năng·bảo mật·tính sẵn sàng, hay độ khó bên trong của các thuật toán phức tạp (ví dụ: nén video, giải tích số). Khi chức năng bề ngoài chỉ là "một phép tính" đơn giản nhưng công sức thuật toán bên trong lại khổng lồ, điểm chức năng sẽ đánh giá thấp công sức ấy. Để lấp khoảng trống này, các kỹ thuật bổ trợ·thay thế như SNAP (đo kích thước phi chức năng) hay COSMIC (chuyên cho thời gian thực·nhúng) được bàn ở phần sau đã ra đời.
2. Cấu trúc tổng thể của việc tính điểm chức năng và quy trình đo
Việc đo điểm chức năng tuân theo một quy trình có hệ thống: nhận diện chức năng phần mềm bằng cách chia thành chức năng dữ liệu và chức năng giao dịch, đánh giá độ phức tạp của từng loại và cộng dồn trọng số. Cấu trúc tổng thể như sau.
flowchart TB
FP["Điểm chức năng(FP)"] --> DF["Chức năng dữ liệu(Data Function)<br/>kích thước dữ liệu được lưu/duy trì"]
FP --> TF["Chức năng giao dịch(Transaction Function)<br/>kích thước tiến trình được xử lý/di chuyển"]
DF --> ILF["Tệp logic nội bộ(ILF)<br/>dữ liệu hệ thống duy trì·quản lý"]
DF --> EIF["Tệp giao tiếp ngoài(EIF)<br/>dữ liệu bên ngoài duy trì, chỉ tham chiếu"]
TF --> EI["Đầu vào ngoài(EI)<br/>đầu vào làm thay đổi dữ liệu"]
TF --> EO["Đầu ra ngoài(EO)<br/>đầu ra có gia công·tính toán"]
TF --> EQ["Truy vấn ngoài(EQ)<br/>tra cứu·tìm kiếm đơn giản"]
style DF fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
style TF fill:#fff3e0,stroke:#e8890c,stroke-width:2px
Năm loại trên là kết quả của việc phân rã phần mềm theo hai trục: "vật chứa đựng dữ liệu (tệp)" và "công việc xử lý dữ liệu đó (giao dịch)". Chức năng dữ liệu đếm các cụm dữ liệu mà hệ thống chịu trách nhiệm duy trì·quản lý. Nếu chịu trách nhiệm tạo·sửa·xóa dữ liệu đó bên trong hệ thống thì là ILF, nếu hệ thống khác quản lý còn ta chỉ đọc thì là EIF. Chức năng giao dịch đếm các đơn vị xử lý vượt ranh giới, phân biệt làm thay đổi dữ liệu là EI, gia công·tính toán rồi gửi ra là EO, trình bày nguyên trạng không tính toán là EQ. Cái hay của cách phân loại này là đã quy giản khái niệm mơ hồ "chức năng" về năm phạm trù có thể đo được.
Việc đo tiến hành theo các bước sau. Luồng tổng thể là trước tiên xác định loại đo và ranh giới, nhận diện·phân loại chức năng, rồi gán độ phức tạp để có điểm chức năng chưa điều chỉnh, và nếu cần thì áp hệ số điều chỉnh để chốt.
flowchart LR
A["quyết định loại đo·mục đích"] --> B["thiết lập ranh giới đo(Boundary)"]
B --> C["nhận diện chức năng dữ liệu·giao dịch"]
C --> D["đánh giá độ phức tạp từng chức năng<br/>(Low/Average/High)"]
D --> E["cộng trọng số = FP chưa điều chỉnh(UFP)"]
E --> F["áp hệ số điều chỉnh(VAF)"]
F --> G["chốt FP đã điều chỉnh(AFP)"]
style E fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
style G fill:#e6f4ea,stroke:#1e8e3e,stroke-width:2px
A. Quyết định loại đo và thiết lập ranh giới
Bước đầu tiên của việc đo là xác định "đo cái gì". IFPUG phân loại đo thành ba kiểu: phát triển mới (Development), cải tiến chức năng (Enhancement), ứng dụng hiện có (Application). Phát triển mới đếm toàn bộ chức năng xây lần đầu, cải tiến chỉ đếm chức năng được thêm·thay đổi·xóa, ứng dụng đếm toàn bộ chức năng mà hệ thống đang vận hành cung cấp. Vì khi xét giá bảo trì hay tính khả thi tái phát triển cần "kích thước của hệ thống hiện tại", nên đo kiểu ứng dụng được dùng rất thường xuyên trong thực tế.
Tiếp theo, thiết lập ranh giới đo (Application Boundary). Ranh giới là đường logic phân chia "hệ thống được đo" với "bên ngoài nó (người dùng·hệ thống khác)", và loại chức năng được quyết định bởi việc dữ liệu và xử lý có vượt ranh giới này hay không. Ví dụ, nếu hệ thống của ta quản lý trực tiếp một dữ liệu nào đó thì nó nằm trong ranh giới dưới dạng ILF, còn nếu chỉ tham chiếu dữ liệu do hệ thống của cơ quan khác quản lý thì thành EIF ngoài ranh giới. Vì cùng một chức năng có thể bị tính thành loại khác tùy nơi vạch ranh giới, nên thiết lập ranh giới là quyết định thiết kế quan trọng nhất chi phối kết quả đo. Ranh giới sai sẽ gây đếm trùng hoặc bỏ sót chức năng, nên phải vạch nhất quán dựa trên góc nhìn người dùng và nơi quy trách nhiệm nghiệp vụ.
Điểm khó trong thực tế của việc thiết lập ranh giới nổi rõ ở kiến trúc lấy microservice·API làm trung tâm. Khi một chức năng nghiệp vụ bị phân tán trên nhiều dịch vụ, số đếm EIF·lời gọi nội bộ sẽ thay đổi tùy vào việc xem mỗi dịch vụ là một ranh giới độc lập hay là một ứng dụng duy nhất. Khi đó, nên lấy "đơn vị được người dùng nhận thức là một ứng dụng" làm ranh giới nhưng khớp với đường phân chia trách nhiệm tổ chức·hợp đồng·vận hành, như vậy sẽ giảm tranh chấp.
B. Chức năng dữ liệu (ILF·EIF)
Chức năng dữ liệu đếm các nhóm dữ liệu logic mà hệ thống xử lý. Ở đây định ngữ "logic" là cốt lõi, nghĩa là đếm các cụm dữ liệu được nhận thức như một đơn vị ý nghĩa duy nhất ở góc nhìn người dùng, chứ không phải số bảng vật lý. Chẳng hạn, dù do chuẩn hóa mà "khách hàng" bị tách thành ba bảng khách hàng-cơ bản·khách hàng-liên lạc·khách hàng-hạng, với người dùng vẫn là một "thông tin khách hàng" nên tính là một ILF. Nhờ nguyên tắc này, điểm chức năng không bị chi phối bởi thiết kế vật lý (mức chuẩn hóa, chiến lược chỉ mục).
Tệp logic nội bộ (ILF, Internal Logical File) là nhóm dữ liệu mà hệ thống được đo tự tạo·sửa·xóa và duy trì·quản lý. "Đơn hàng", "sản phẩm", "thành viên" trong hệ thống đặt hàng là tiêu biểu. Ngược lại, tệp giao tiếp ngoài (EIF, External Interface File) là trường hợp dữ liệu do hệ thống khác duy trì·quản lý dưới dạng ILF, còn hệ thống của ta chỉ tham chiếu (đọc). Ví dụ, nếu hệ thống đặt hàng chỉ truy vấn bảng "mã công ty thẻ" của hệ thống thanh toán thì đó là EIF. Điểm quan trọng là cùng một dữ liệu nhưng tùy nơi quy trách nhiệm (ai duy trì) mà tách thành ILF và EIF. ILF của một hệ thống trở thành EIF đối với hệ thống khác tham chiếu dữ liệu đó.
Độ phức tạp của chức năng dữ liệu được quyết định bởi hai chỉ số. DET (Data Element Type) là số trường (thuộc tính) duy nhất mà người dùng nhận thức, còn RET (Record Element Type) là số nhóm con (tập con) bên trong nhóm dữ liệu đó. Ví dụ, nếu "khách hàng" có hai kiểu con là khách hàng cá nhân·khách hàng pháp nhân thì RET=2. DET càng nhiều, RET càng nhiều thì độ phức tạp càng tăng, và tổ hợp của hai yếu tố này quyết định Low/Average/High. Lý do chức năng dữ liệu được gán trọng số cao hơn (ILF 7~15) là quy tắc kinh nghiệm rằng việc duy trì·quản lý dữ liệu kéo theo công sức lớn hơn về mặt thiết kế·toàn vẹn so với xử lý đơn giản.
C. Chức năng giao dịch (EI·EO·EQ)
Chức năng giao dịch đếm các đơn vị xử lý cơ bản (Elementary Process) vượt ranh giới. Xử lý cơ bản là hoạt động trọn vẹn nhỏ nhất có ý nghĩa với người dùng, là đơn vị "nếu chỉ thực hiện một phần thì không trọn vẹn về mặt nghiệp vụ". Như "đăng ký thành viên" nếu đứt giữa chừng thì chẳng còn ý nghĩa gì, một nghiệp vụ trọn vẹn là một chức năng giao dịch.
Đầu vào ngoài (EI, External Input) là xử lý trong đó dữ liệu·thông tin điều khiển đi vào từ ngoài ranh giới và làm thay đổi ILF (tạo·sửa·xóa) hoặc thay đổi hành vi hệ thống. "Đăng ký sản phẩm", "hủy đơn hàng", "đổi mật khẩu" là các EI tiêu biểu. Đầu ra ngoài (EO, External Output) là đầu ra gửi dữ liệu ra ngoài ranh giới nhưng có chứa logic tính toán·gia công·phái sinh. Nếu tạo và gửi ra các tổng·tỉ lệ·giá trị phái sinh như "bảng tổng hợp doanh thu theo tháng", "báo cáo lãi lỗ" thì là EO. Truy vấn ngoài (EQ, External Inquiry) là xử lý tra cứu·truy vấn dữ liệu đã lưu nguyên trạng không tính toán rồi trình bày. "Xem chi tiết thông tin thành viên", "tìm kiếm danh sách sản phẩm" là EQ. Tiêu chí quyết định phân biệt EO với EQ là "có hay không có dữ liệu phái sinh hoặc logic tính toán", và khi phân biệt này mơ hồ thì sai lệch giữa các người đo phát sinh lớn nhất.
Độ phức tạp của chức năng giao dịch được quyết định bởi FTR (File Type Referenced, số tệp được tham chiếu) và DET (số phần tử dữ liệu tham gia xử lý). Một xử lý tham chiếu càng nhiều tệp và xử lý càng nhiều trường thì độ phức tạp càng cao. Ví dụ, nếu EI "tạo đơn hàng" tham chiếu bốn ILF là đơn hàng·sản phẩm·tồn kho·thành viên thì FTR=4, nghiêng về phía High. Việc trọng số của chức năng giao dịch được đặt thấp hơn chức năng dữ liệu (EI 3~6 v.v.) phản ánh triết lý thiết kế rằng duy trì·quản lý cấu trúc dữ liệu là công sức căn bản hơn so với từng mảnh logic xử lý.
3. Đánh giá độ phức tạp và tính điểm chức năng
A. Ma trận độ phức tạp và trọng số
Mỗi chức năng được nhận diện nhận trọng số sau theo độ phức tạp (Low/Average/High). Bảng này giữ các giá trị mà IFPUG đã định ra bằng phân tích hồi quy dữ liệu của vô số dự án, lượng hóa sự thật thực nghiệm rằng chức năng dữ liệu đòi hỏi công sức lớn hơn chức năng giao dịch, và High lớn hơn Low.
| Loại chức năng | Low | Average | High | Ghi chú |
|---|---|---|---|---|
| ILF (Tệp logic nội bộ) | 7 | 10 | 15 | độ phức tạp theo DET·RET |
| EIF (Tệp giao tiếp ngoài) | 5 | 7 | 10 | chỉ tham chiếu, thấp hơn ILF |
| EI (Đầu vào ngoài) | 3 | 4 | 6 | quyết định theo FTR·DET |
| EO (Đầu ra ngoài) | 4 | 5 | 7 | có tính toán·gia công |
| EQ (Truy vấn ngoài) | 3 | 4 | 6 | tra cứu đơn giản |
Bản thân độ lớn tương đối của các trọng số nói lên nhiều điều. High của ILF (15) gấp năm lần Low của EQ (3), đây là quy tắc kinh nghiệm rằng "một master phức tạp chịu trách nhiệm quản lý dữ liệu" đòi hỏi công sức gấp năm lần "một màn hình truy vấn đơn giản". Người đo áp dụng bảng này một cách máy móc, nhưng vì việc phân loại mỗi chức năng vào độ phức tạp nào chi phối kết quả, nên phải duy trì tiêu chí nhất quán trong việc tính DET·RET·FTR.
Xét thực tế của việc phán định độ phức tạp, chức năng dữ liệu được đưa vào ma trận độ phức tạp ba mức bằng tổ hợp DET và RET. Chẳng hạn ở ILF nếu DET từ 1~19 và RET là 1 thì Low, còn DET nhiều hoặc RET nhiều thì lên Average·High. Chức năng giao dịch cũng tương tự dùng bảng tổ hợp FTR và DET. Điều quan trọng không phải là thuộc lòng các giá trị ngưỡng (threshold) đó, mà là hiểu nguyên lý "độ phức tạp được quyết định bởi hai trục là phạm vi tham chiếu (tệp·bản ghi) và lượng phần tử dữ liệu". Cùng một EI "đăng ký thành viên", nếu xử lý hàng chục trường và cập nhật nhiều tệp thì là High, nếu chỉ đưa vài trường vào một tệp duy nhất thì là Low.
Lý do việc phân biệt độ phức tạp này quan trọng trong thực tế là vì một phần đáng kể tổng điểm chức năng đến từ một số ít chức năng High. Thay vì hàng chục truy vấn đơn giản (EQ Low), thường chỉ vài master nghiệp vụ cốt lõi (ILF High) chi phối kích thước và công sức. Do đó, để nâng chất lượng đo, hiệu quả hơn là tập trung năng lực kiểm chứng vào việc nhận diện·phán định các chức năng cốt lõi có độ phức tạp cao, thay vì dàn đều sự chú ý cho mọi chức năng.
B. Điểm chức năng chưa điều chỉnh (UFP) và hệ số điều chỉnh (VAF)
Giá trị cộng dồn trọng số của tất cả chức năng được nhận diện là điểm chức năng chưa điều chỉnh (UFP, Unadjusted Function Point). UFP biểu thị thuần túy kích thước chức năng, và ISO/IEC 20926 định nghĩa chính UFP này là "kích thước chức năng" chính thức.
Phương pháp IFPUG tùy chọn nhân UFP với hệ số điều chỉnh (VAF, Value Adjustment Factor) để có điểm chức năng đã điều chỉnh (AFP, Adjusted Function Point). VAF được tính bằng cách đánh giá 14 đặc tính hệ thống tổng quát (GSC) — truyền dữ liệu, xử lý phân tán, hiệu năng, cấu hình tải nặng, tốc độ giao dịch, nhập liệu trực tuyến, hiệu quả người dùng cuối, cập nhật trực tuyến, xử lý phức tạp, khả năng tái sử dụng, dễ cài đặt, dễ vận hành, đa điểm, dễ thay đổi — mỗi đặc tính từ 0~5 điểm. Công thức là VAF = 0.65 + 0.01 × ∑(điểm 14 GSC), nên nếu mọi đặc tính ở mức trung bình (mỗi cái không đáng kể) thì VAF≈1, cho phép điều chỉnh tối đa ±35%. AFP = UFP × VAF là điểm chức năng cuối cùng.
Tuy vậy VAF gây tranh cãi. 14 đặc tính được tạo ra trên tiền đề môi trường công nghệ thập niên 1980 (mainframe·batch), không phù hợp với môi trường cloud·web hiện đại, và có nhiều phê bình rằng việc "gộp 14" các yêu cầu phi chức năng lại là yếu về cơ sở khoa học. Vì thế, chuẩn ISO FSM và Hướng dẫn tính giá dự án SW của Hàn Quốc không dùng VAF mà chỉ chọn UFP (điểm chức năng chưa điều chỉnh) làm kích thước, còn các yếu tố phi chức năng được xử lý bằng hệ số điều chỉnh riêng hoặc SNAP. Trong bài thi của Kỹ sư chuyên nghiệp, việc phân biệt chính xác rằng "VAF chỉ là điều chỉnh tùy chọn của IFPUG, còn chuẩn Hàn Quốc dựa trên UFP" là quan trọng.
C. Phương pháp chính quy (chi tiết) và phương pháp giản lược
Trong thực tế, cách đo điểm chức năng tách thành hai nhánh theo độ chính xác và thời điểm đo. Khác biệt giữa hai nhánh nằm ở "đánh giá độ phức tạp của từng chức năng riêng lẻ, hay áp đồng loạt bằng giá trị trung bình".
| Phân loại | Phương pháp chính quy (chi tiết, IFPUG) | Phương pháp giản lược (tính giá Hàn Quốc) |
|---|---|---|
| Đánh giá độ phức tạp | tính Low/Avg/High riêng từng chức năng theo DET·RET·FTR | áp đồng loạt trọng số độ phức tạp trung bình |
| Độ chính xác | cao | thấp (xấp xỉ) |
| Thời điểm áp dụng | sau khi thiết kế đã cụ thể phần nào | giai đoạn sớm ở mức yêu cầu |
| Công sức·chi phí | lớn (đòi hỏi chuyên môn đo) | nhỏ (nhanh) |
| Ứng dụng tại Hàn Quốc | kiểm chứng·quyết toán chi tiết | chuẩn cho giai đoạn lập ngân sách·đặt thầu |
Phương pháp giản lược áp trọng số trung bình theo loại (ví dụ: ILF trung bình, EI trung bình) mà không xét kỹ độ phức tạp từng chức năng. Chỉ cần yêu cầu được sắp xếp là có thể ước lượng kích thước nhanh, nên nó phù hợp với giai đoạn lập ngân sách·đặt thầu dự án trước khi thiết kế chi tiết. Lý do Hướng dẫn tính giá dự án SW của Hàn Quốc chọn phương pháp giản lược làm cơ sở cho việc tính ngân sách dự án công chính là khả năng áp dụng sớm này. Ngược lại, phương pháp chính quy (chi tiết) phân tích DET·RET·FTR cho từng chức năng để phán định độ phức tạp riêng lẻ nên chính xác, nhưng chỉ đo được sau khi thiết kế đã cụ thể, tốn nhân lực chuyên môn và thời gian. Trong thực tế, vận hành hai giai đoạn là phổ biến: lập ngân sách bằng phương pháp giản lược khi đặt thầu, rồi quyết toán·kiểm chứng bằng phương pháp chính quy sau khi hoàn tất thiết kế.
Hãy nắm cảm giác bằng một ví dụ số đơn giản. Nếu đo một hệ thống bằng phương pháp giản lược và trên cơ sở trọng số trung bình nhận diện được 5 ILF (trung bình 10) = 50, 2 EIF (trung bình 7) = 14, 20 EI (trung bình 4) = 80, 10 EO (trung bình 5) = 50, 15 EQ (trung bình 4) = 60, thì UFP = 50+14+80+50+60 = 254 FP. Trong tính giá tại Hàn Quốc, 254 FP này được nhân với đơn giá trên mỗi điểm chức năng (đơn giá FP) do Hiệp hội Công nghiệp Phần mềm Hàn Quốc công bố hằng năm và với các hệ số điều chỉnh (quy mô·liên kết·hiệu năng·môi trường vận hành v.v.) để tính giá thành phát triển. Vì đơn giá được cập nhật hằng năm phản ánh biến động vật giá·tiền lương, nên trong bài thi an toàn hơn là viết "áp dụng đơn giá của năm đó do hiệp hội công bố" thay vì khẳng định một con số cụ thể.
4. So sánh và trường hợp áp dụng
Để hiểu vị thế của điểm chức năng, cần so sánh với các thước đo cạnh tranh·thay thế. So với LOC, ưu thế cốt lõi của điểm chức năng là độc lập công nghệ và khả năng áp dụng sớm. LOC chỉ đếm chính xác sau khi phát triển xong và bị nhiễu bởi ngôn ngữ·năng suất, còn FP được đo ở giai đoạn yêu cầu, độc lập với ngôn ngữ. Ngược lại, LOC dễ tổng hợp tự động và không có chủ quan của người đo xen vào, còn FP có điểm yếu là kết quả có thể dao động khoảng 10% tùy mức thành thạo của người đo. Do đó hai chỉ số bổ trợ cho nhau dưới dạng "năng suất (LOC/FP, hệ số quy đổi theo ngôn ngữ)", và bảng LOC/FP theo ngôn ngữ của Capers Jones là công cụ quy đổi tiêu biểu.
So với COCOMO (mô hình dựa trên LOC), điểm chức năng khác về vai trò giữa "đo kích thước" và "quy đổi công sức". COCOMO là mô hình nhận kích thước (KLOC) làm đầu vào và tính công sức, còn FP là phương pháp đo chính bản thân kích thước. Thực tế COCOMO II đôi khi nhận FP làm đầu vào giai đoạn sớm rồi quy đổi sang LOC (backfiring) để dùng. Nghĩa là hai thứ kết hợp không phải như đối thủ mà như một pipeline "đo kích thước bằng FP → quy đổi công sức bằng mô hình".
So với COSMIC (ISO/IEC 19761), điểm chức năng phân nhánh theo miền áp dụng. IFPUG FP mạnh với hệ thống thông tin quản lý (MIS) lấy dữ liệu làm trung tâm, nhưng COSMIC — đo kích thước chỉ bằng di chuyển dữ liệu (Entry·Exit·Read·Write) — phù hợp hơn với phần mềm thời gian thực·nhúng·điều khiển. Ở các hệ thống truyền thông·điều khiển nơi dữ liệu bề ngoài ít nhưng di chuyển dữ liệu nội bộ lại thường xuyên, IFPUG FP có xu hướng đánh giá thấp kích thước nên COSMIC được ưa chuộng.
Một trường hợp áp dụng công nghiệp cụ thể: trong xây dựng các hệ thống thế hệ mới của khu vực công Hàn Quốc, FP theo phương pháp giản lược được tính dựa trên tài liệu định nghĩa yêu cầu (RFP) để chốt ngân sách dự án, và điểm chức năng được tính lại ở thời điểm hoàn tất thiết kế để quyết toán định lượng các thay đổi phạm vi (tăng/giảm). Trong khối tài chính, các chỉ số FP chuẩn hóa như "năng suất phát triển = FP bàn giao / Man-Month đầu tư", "chất lượng = số lỗi / FP" được dùng làm KPI để đánh giá thành quả của các ngôn ngữ·đội khác nhau trên cùng một thước đo. Trong các hợp đồng thuê ngoài toàn cầu, hợp đồng dựa trên thành quả kiểu "đơn giá theo FP" (Price-per-FP) thay thế hợp đồng dựa trên công sức đầu vào, được dùng như cấu trúc khích lệ để lợi ích của việc nâng cao năng suất quay về với bên đặt hàng.
5. Chuyên sâu — Đo kích thước phi chức năng và xu hướng tự động hóa
Giới hạn căn bản nhất của điểm chức năng nằm ở chỗ nó "chỉ đo chức năng người dùng nhìn thấy". FP hầu như không nắm bắt được các yêu cầu phi chức năng như hiệu năng·bảo mật·khả năng mở rộng·tính sẵn sàng, hay công việc đòi hỏi công sức khổng lồ mà không đổi chức năng như chuyển đổi kiến trúc·tái cấu trúc quy mô lớn. Để lấp khoảng trống này, IFPUG đã công bố SNAP (Software Non-functional Assessment Process) năm 2013. SNAP đo các yêu cầu phi chức năng thuộc bốn phạm trù — vận hành dữ liệu, thiết kế giao diện, môi trường kỹ thuật, kiến trúc — bằng SP (SNAP Point), dùng như một thước đo riêng bổ trợ lẫn nhau với điểm chức năng (FP). FP đo "làm gì", còn SNAP đo "làm như thế nào·vững chắc đến đâu". Các thảo luận gần đây về tính giá tại Hàn Quốc cũng đang xem xét đưa SNAP vào làm hệ thống tưởng thưởng cho yêu cầu phi chức năng.
Tự động hóa việc đo cũng là một dòng chảy quan trọng. Việc đo FP truyền thống có vấn đề cố hữu là chi phí và sai lệch người đo lớn vì chuyên gia phải đọc đặc tả và đếm bằng tay. Để giải quyết, OMG đã lập chuẩn Automated Function Points (AFP) tự động tính điểm chức năng từ mã nguồn và cấu trúc giao dịch, với công cụ phân tích tĩnh trích ngược chức năng dữ liệu·giao dịch từ mã để tính FP. Tuy nhiên, vì đo tự động là đo "cái đã được triển khai" nên không dùng được cho ước lượng sớm ở giai đoạn yêu cầu, và không thể thay thế hoàn toàn phán đoán nghiệp vụ của người đo (nhận diện xử lý cơ bản, thiết lập ranh giới).
Thay đổi gần đây nhất là ước lượng kích thước dựa trên AI·LLM. Các nghiên cứu·công cụ đang xuất hiện nhằm phân tích tài liệu yêu cầu hay user story bằng xử lý ngôn ngữ tự nhiên để tự động nhận diện chức năng dữ liệu·giao dịch và ước lượng FP, và các mô hình học từ dữ liệu FP-công sức của dự án quá khứ được dùng để giảm sai số ước lượng. Tuy nhiên, ước lượng bằng AI mang vấn đề thiên lệch dữ liệu học và khả năng giải thích, nên trước mắt dự kiến chỉ dừng ở vai trò hỗ trợ·kiểm chứng việc đo của chuyên gia. Trong môi trường agile, điểm câu chuyện (story point) mang tính kích thước tương đối được dùng thay FP, nhưng vì ngân sách·benchmark ở cấp tổ chức vẫn cần thước đo tuyệt đối là FP, nên các cách tiếp cận lai thử quy đổi qua lại "story point ↔ FP" cũng đang xuất hiện.
6. Điều cần cân nhắc và hàm ý
Từ góc nhìn Kỹ sư chuyên nghiệp, các chiến lược và hàm ý cần cân nhắc khi áp dụng·vận hành điểm chức năng như sau.
- Vận hành hai giai đoạn về thời điểm và phương pháp đo: ở giai đoạn đặt thầu, chốt ngân sách bằng phương pháp giản lược vốn đo nhanh chỉ từ yêu cầu; sau khi hoàn tất thiết kế, tính lại bằng phương pháp chính quy để quyết toán thay đổi phạm vi — chiến lược kép này là thích hợp. Ước lượng sớm có sai số ± lớn theo "hình nón bất định", nên không nên chốt bằng một lần đo mà phải tinh luyện qua đo lại theo từng giai đoạn.
- Bảo đảm tính nhất quán·quản trị của việc đo: vì kết quả FP dao động theo mức thành thạo người đo, nên phải tài liệu hóa tiêu chí thiết lập ranh giới·phán định độ phức tạp thành chuẩn tổ chức, và đặt cơ chế kiểm chứng chéo bởi người đo được chứng nhận (CFPS) hoặc người thành thạo thì mới có được sự tin cậy. Lưu lại căn cứ đo (chi tiết nhận diện·phán định độ phức tạp) sao cho truy vết được là cốt lõi để ứng phó giám sát·tranh chấp.
- Tưởng thưởng riêng cho yêu cầu phi chức năng·độ khó cao: hiệu năng·bảo mật·độ khó thuật toán mà FP đánh giá thấp phải được bổ sung bằng SNAP hoặc hệ số điều chỉnh riêng. Đặc biệt với hệ thống thời gian thực·nhúng·AI, nếu chỉ dùng IFPUG FP để định kích thước thì công sức bị méo mó nghiêm trọng, nên cần xem xét dùng kèm thước đo phù hợp với miền như COSMIC.
- Thiết kế khích lệ của hợp đồng dựa trên thành quả: phương pháp đơn giá theo FP khiến lợi ích của việc nâng cao năng suất quay về bên đặt hàng, nhưng cũng sinh động lực ngược là bên thực hiện "thổi phồng FP bằng cách tăng chức năng không cần thiết". Do đó phải vận hành kết hợp với việc kiểm chứng sự cần thiết của chức năng (thẩm định tính thích đáng của phạm vi) thì mới giữ được sự công bằng.
- Triển vọng và công nghệ liên kết: về lâu dài, tự động hóa việc đo (OMG AFP) và ước lượng bằng AI sẽ giảm chi phí·sai lệch đo, và trong môi trường agile·DevOps, thông qua quy đổi với story point, FP sẽ được định vị lại như chỉ số benchmark·quản lý danh mục ở cấp tổ chức. Tuy nhiên, vì tự động hóa không thể thay thế hoàn toàn phán đoán nghiệp vụ của người đo, nên kết hợp "đo tự động + kiểm chứng chuyên gia" là hướng đi thực tế.
Tài liệu tham khảo
- IFPUG, "Function Point Counting Practices Manual (CPM)", https://www.ifpug.org/
- ISO/IEC 20926, "Software and systems engineering — IFPUG functional size measurement method", https://www.iso.org/standard/51717.html
- Hiệp hội Công nghiệp Phần mềm Hàn Quốc, "Hướng dẫn tính giá dự án SW", https://www.sw.or.kr/
- OMG, "Automated Function Points (AFP)", https://www.omg.org/spec/AFP/
Tóm tắt một câu: Điểm chức năng (FP) là phương pháp đo kích thước chức năng, nhận diện và cộng dồn trọng số chức năng mà phần mềm cung cấp thành chức năng dữ liệu (ILF·EIF) và chức năng giao dịch (EI·EO·EQ) để đo kích thước độc lập với công nghệ triển khai — là chuẩn cho việc tính giá dự án SW của Hàn Quốc và là thước đo kỹ thuật mở rộng tới phi chức năng (SNAP)·tự động hóa (AFP)·ước lượng bằng AI.