← Về danh sách
Kỹ nghệ & Quản lý phần mềm
#규모산정#기능점수#LoC#공공SW#대가산정#132회#131회
Cập nhật lần cuối · 2026-07-07

Các phương pháp ước lượng quy mô phần mềm và phương án cải tiến cho phần mềm khu vực công

1. Tổng quan

A. Định nghĩa

Là phương pháp ước lượng định lượng quy mô (kích thước) cần thiết để phát triển phần mềm, là điểm xuất phát cho việc ước tính chi phí phát triển, công sức đầu tư (M/M) và tiến độ.

Ước lượng quy mô là công việc quy đổi thành con số "xây dựng phần mềm lớn đến mức nào". Chỉ khi quy mô được xác định mới có thể nhân với năng suất (công sức trên một đơn vị quy mô) để rút ra công sức, chi phí, tiến độ, vì vậy ước lượng quy mô là điểm chuẩn cao nhất của mọi báo giá phần mềm. Các phương pháp ước lượng phân nhánh tùy theo việc lấy gì làm đơn vị kích thước, và mỗi phương pháp có sự đánh đổi rõ rệt về thời điểm đo, độ chính xác, tính khách quan.

B. Bối cảnh ra đời và sự cần thiết

Trước đây, giá phần mềm được tính dựa trên đầu vào (input) như số nhân lực, thời gian nên căn cứ yếu, dẫn tới tranh chấp phạm vi công việc giữa bên đặt hàng và bên thực hiện cũng như suy giảm chất lượng sau khi trúng thầu giá thấp. Phần mềm không có thực thể vật lý nên khó thống nhất khách quan "đáng giá bao nhiêu", do đó cần thước đo quy mô chuẩn hóa dựa trên sản phẩm đầu ra (output). Đặc biệt, khu vực công đòi hỏi tính minh bạch và công bằng trong chi tiêu ngân sách, nên đã chọn phương pháp ước lượng độc lập với ngôn ngữ, công nghệ và được chuẩn hóa làm tiêu chuẩn tính giá.

2. Các loại phương pháp ước lượng quy mô và đặc điểm

flowchart TB
  S[Ước lượng quy mô] --> L[LoC<br/>dòng mã]
  S --> F[Điểm chức năng FP<br/>dựa trên chức năng]
  S --> U[Điểm use case]
  S --> ST[Story point<br/>Agile]

Bốn phương pháp được chia lớn thành "dựa trên mã (LoC)" và "dựa trên chức năng (FP·UCP·SP)". LoC đếm số dòng của mã nguồn hoàn chỉnh nên trực quan, nhưng cùng một chức năng mà số dòng khác nhau nhiều tùy ngôn ngữ và phong cách của nhà phát triển, và phải phát triển xong mới đếm chính xác được nên không phù hợp cho báo giá ban đầu. Ngược lại, điểm chức năng (FP) lấy "chức năng được cung cấp cho người dùng" làm đơn vị nên có thể ước lượng ở giai đoạn phân tích yêu cầu bất kể ngôn ngữ hiện thực, và được xác lập thành chuẩn quốc tế (ISO/IEC 20926 v.v.) nên tính khách quan và khả năng tái hiện cao. Điểm use case tận dụng độ phức tạp của use case UML nên phù hợp với dự án hướng đối tượng, còn story point là phương pháp đội Agile ước lượng theo kích thước tương đối, hữu ích trong nội bộ đội nhưng khó dùng để so sánh giữa các đội.

Phương pháp Đơn vị kích thước Ưu điểm Nhược điểm
LoC (dòng mã) Số dòng mã nguồn Đơn giản·trực quan Phụ thuộc ngôn ngữ·phong cách, khó ước lượng ban đầu
Điểm chức năng (FP) Chức năng người dùng Độc lập ngôn ngữ, chuẩn quốc tế, ước lượng được từ đầu Việc đo cần chuyên môn·công sức
Điểm use case Độ phức tạp use case Phù hợp dự án hướng đối tượng·UML Phụ thuộc chất lượng viết use case
Story point Quy mô tương đối Hữu ích cho ước lượng lặp của Agile Phụ thuộc đội, khó so sánh giữa các đội

Vì những đặc tính này, các dự án phần mềm khu vực công tại Hàn Quốc chọn điểm chức năng (FP) làm chuẩn tính giá.

3. Ước lượng điểm chức năng (FP)

FP định lượng các chức năng mà phần mềm cung cấp cho người dùng bằng cách chia thành chức năng dữ liệu và chức năng giao dịch. Chức năng dữ liệu là tập dữ liệu logic mà hệ thống duy trì, tham chiếu; chức năng giao dịch là đơn vị xử lý mà người dùng thực hiện. Gán trọng số theo độ phức tạp của từng chức năng (đơn giản/trung bình/phức tạp) rồi cộng dồn.

Bước Nội dung
Xác định chức năng Chức năng dữ liệu (tệp logic nội bộ ILF·tệp giao tiếp ngoài EIF)·chức năng giao dịch (đầu vào ngoài EI·đầu ra ngoài EO·truy vấn ngoài EQ)
Gán trọng số độ phức tạp Gán trọng số theo độ phức tạp của từng chức năng (đơn giản·trung bình·phức tạp)
Hiệu chỉnh·tổng hợp Tính tổng FP bằng phương pháp giản lược (áp dụng độ phức tạp trung bình) hoặc phương pháp chi tiết (ước lượng độ phức tạp riêng)

Trong thực tế, nâng dần độ chính xác theo từng giai đoạn: ở giai đoạn đầu khi yêu cầu chưa được xác định thì ước lượng nhanh bằng phương pháp giản lược áp dụng độ phức tạp trung bình, và sau khi thiết kế chi tiết hơn thì tinh chỉnh bằng phương pháp chi tiết phản ánh độ phức tạp riêng. Ví dụ, với dự án được ước lượng quy mô 100 FP, nhân với đơn giá trong tiêu chuẩn tính giá dự án phần mềm để rút ra chi phí phát triển.

4. Phương án cải tiến thực tế cho ước lượng quy mô phần mềm khu vực công

Vấn đề ước lượng của dự án phần mềm khu vực công phần lớn bắt nguồn từ mâu thuẫn mang tính cấu trúc "yêu cầu ở đầu dự án chưa rõ ràng mà giá lại bị cố định tại thời điểm đó". Các phương án cải tiến dưới đây hướng tới làm dịu mâu thuẫn này.

Vấn đề Nguyên nhân Phương án cải tiến
Ước lượng không chính xác khi yêu cầu chưa rõ Yêu cầu chưa xác định tại thời điểm khởi động Ước lượng lại theo giai đoạn sau khi hoàn tất phân tích (chốt sau khi chi tiết hóa yêu cầu)
Không phản ánh thay đổi phạm vi Yêu cầu tăng sau hợp đồng Hội đồng thẩm định thay đổi phạm vi, ước lượng lại giá cho phần thay đổi
Trúng thầu giá thấp Cạnh tranh giá thấp nhất Thiết lập mức sàn dựa trên giá hợp lý·giá thành, đánh giá tác động phần mềm
Gánh nặng đo FP Tốn chuyên môn·thời gian đo Công cụ tự động hóa, chuẩn hóa·đào tạo, bồi dưỡng nhân lực chuyên môn

Cốt lõi là không ấn định quy mô một lần mà thể chế hóa ước lượng lại sau phân tích (chốt theo giai đoạn) và quản lý thay đổi phạm vi. Khi yêu cầu tăng thì phải có thể ước lượng lại giá tương ứng mới ngăn được trúng thầu giá thấp và việc bổ sung phạm vi công việc vô lý (velvet).

5. Lưu ý và hàm ý

Dưới góc nhìn Kỹ sư chuyên nghiệp, ước lượng quy mô phần mềm không phải kỹ thuật báo giá đơn thuần mà phải được xem là cơ chế thể chế bảo đảm niềm tin giữa bên đặt hàng và bên thực hiện. Thứ nhất, phải kết hợp ước lượng khách quan dựa trên điểm chức năng với quản lý thay đổi phạm vi thì mới đồng thời bảo đảm được độ chính xác và tính công bằng của ước lượng. Thứ hai, liên kết với hướng dẫn tính giá dự án phần mềm và Luật Thúc đẩy Ngành Phần mềm của Hàn Quốc để bảo đảm giá hợp lý, qua đó giữ gìn sự lành mạnh của hệ sinh thái ngành. Thứ ba, khi các loại dự án khó thể hiện bằng FP truyền thống như Agile, đám mây (thuê bao SaaS), bảo trì ngày càng tăng, đa dạng hóa và bổ sung phương pháp ước lượng phản ánh story point, quy mô dịch vụ v.v. là thách thức trong tương lai.


Tóm tắt một câu: Ước lượng quy mô phần mềm được chia thành các phương pháp LoC, điểm chức năng (FP), use case, story point, trong đó khu vực công lấy FP độc lập ngôn ngữ và được chuẩn hóa làm chuẩn; ước lượng lại theo giai đoạn sau khi chi tiết hóa yêu cầu, phản ánh thay đổi phạm vi và bảo đảm giá hợp lý là hướng cải tiến cốt lõi cho ước lượng phần mềm khu vực công.