Các phương pháp ước tính chi phí phần mềm

1. Tổng quan

A. Định nghĩa

Ước tính chi phí phần mềm (Software Cost Estimation) là hoạt động dự báo công sức (Man-Month), thời gian và chi phí cần thiết cho việc phát triển trước khi bắt đầu dự án, làm căn cứ định lượng cho việc lập kế hoạch dự án, ngân sách, tiến độ cũng như đặt hàng và ký kết hợp đồng.

Lý do ước tính chi phí vừa khó vừa quan trọng nằm ở mâu thuẫn bản chất "phải đoán trước giá trị của thứ không nhìn thấy được". Phần mềm không có thực thể vật lý, và trước khi hoàn thành thì khó biết chính xác quy mô và độ phức tạp. Thế nhưng ngân sách và tiến độ phải được chốt trước khi khởi động, và ngân sách một khi đã định sẽ ràng buộc suốt toàn bộ dự án. Nếu ước tính quá lạc quan, dự án vượt ngân sách và thời hạn, rơi vào khủng hoảng, dẫn đến làm thêm giờ, suy giảm chất lượng và tranh chấp; nếu quá thận trọng, sẽ thua trong cạnh tranh đấu thầu. Vì nghịch lý này, ước tính cần được hiểu không phải là phép tính đơn thuần mà là hành vi ra quyết định quản lý rủi ro trong điều kiện bất định.

Để giảm bớt khó khăn này, nhiều phương pháp ước tính đã được phát triển. Nhìn chung, chúng chia thành từ trên xuống (Top-Down) — dựa vào kinh nghiệm và trực giác của con người như đánh giá chuyên gia, Delphi; từ dưới lên (Bottom-Up) — chia nhỏ các thành phần rồi cộng dồn dựa trên WBS; và mô hình toán học (Algorithmic) — dùng phương trình hồi quy và hệ số xây dựng từ dữ liệu dự án quá khứ như COCOMO dựa trên LOC và điểm chức năng (FP) dựa trên chức năng. Ba phương thức có sự đánh đổi khác nhau về độ chính xác, tính khách quan và thời điểm có thể ước tính. Từ trên xuống cho câu trả lời nhanh ngay ở giai đoạn cực sớm nhưng mang tính chủ quan; từ dưới lên chính xác nhưng cần thiết kế đã được xác định ở mức độ nhất định và có nguy cơ bỏ sót; dựa trên mô hình thì định lượng và có thể kiểm chứng, nhưng kết quả phụ thuộc vào độ chính xác khi dự đoán giá trị đầu vào (LOC, quy mô chức năng). Không phương pháp nào hoàn hảo, vì vậy khôn ngoan là dùng song song nhiều phương pháp để kiểm chứng chéo (triangulation) và diễn giải độ chênh lệch như một tín hiệu rủi ro.

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

Vào thập niên 1960~70, khi các dự án phần mềm lớn liên tiếp vượt ngân sách và thời hạn, "khủng hoảng phần mềm (software crisis)" nổi lên, làm tăng nhu cầu về kỹ thuật ước tính khách quan, có thể lặp lại để thay thế cách báo giá tùy tiện. Ước tính thiếu chính xác là nguyên nhân gốc rễ của vượt ngân sách, chậm tiến độ, suy giảm chất lượng và tranh chấp giữa các bên liên quan; đặc biệt trong các dự án tin học hóa khu vực công, tính hợp lý của ngân sách và tính minh bạch của đặt hàng trở thành vấn đề trọng tâm của kiểm toán và giám sát. Kết quả là tại Hàn Quốc đã hình thành hệ thống tính giá chuẩn dựa trên điểm chức năng, còn trên thế giới là các mô hình định lượng như COCOMO, điểm chức năng (IFPUG/ISO).

C. Những tính chất mà một ước tính tốt cần có

Một ước tính chi phí tốt phải có: thứ nhất là tính khách quan (ai làm cũng cho kết quả tương tự), thứ hai là khả năng truy vết (tài liệu hóa căn cứ và giả định ước tính), thứ ba là tính kịp thời (cung cấp câu trả lời đúng thời điểm cần ra quyết định), thứ tư là tinh chỉnh dần dần (phản ánh "hình nón bất định (cone of uncertainty)" — sai số thu hẹp dần khi các giai đoạn tiến triển). Với tiền đề là mức bất định lên tới ±100% ở giai đoạn đầu sẽ thu hẹp khi thiết kế và cài đặt tiến triển, ước tính không phải thực hiện một lần mà phải được ước tính lại lặp đi lặp lại.

2. Phân loại các phương pháp ước tính chi phí — Cấu trúc tổng thể

Các kỹ thuật ước tính chi phí được chia thành từ trên xuống, từ dưới lên và mô hình toán học tùy theo hướng đi và căn cứ của thông tin; trong thực tiễn chúng được kết hợp bổ trợ lẫn nhau.

flowchart TB
  C["Ước tính chi phí phần mềm"] --> TD["Từ trên xuống (Top-Down)<br/>ước tính tổng thể trước rồi phân bổ"]
  C --> BU["Từ dưới lên (Bottom-Up)<br/>cộng dồn các thành phần"]
  C --> AL["Mô hình toán học (Algorithmic)<br/>công thức định lượng từ dữ liệu quá khứ"]
  TD --> TD1["Đánh giá chuyên gia"]
  TD --> TD2["Delphi"]
  BU --> BU1["Cộng công sức theo tác vụ dựa trên WBS"]
  AL --> AL1["COCOMO dựa trên LOC"]
  AL --> AL2["Điểm chức năng (FP)"]
  style AL fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
  style AL2 fill:#fff3e0,stroke:#e8890c,stroke-width:2px

Phương thức từ trên xuống ước tính trước quy mô toàn dự án dựa trên kinh nghiệm rồi phân bổ cho các tác vụ cấp dưới. Nó có thể đưa ra báo giá sơ bộ nhanh ngay ở giai đoạn cực sớm khi yêu cầu còn mờ nhạt, nên hữu ích ở bước xem xét tính khả thi của dự án hoặc giai đoạn đề xuất. Tuy nhiên, nó phụ thuộc vào kinh nghiệm cá nhân nên thiên lệch lớn, và có giới hạn là không phát hiện được sự bỏ sót các tác vụ chi tiết. Để giảm thiên lệch này, kỹ thuật Delphi — thu thập ý kiến ẩn danh của nhiều chuyên gia qua nhiều vòng — được sử dụng.

Ngược lại, phương thức từ dưới lên phân rã dự án thành các phần nhỏ bằng cấu trúc phân chia công việc (WBS), ước tính công sức cho từng tác vụ rồi cộng lại. Căn cứ chi tiết rõ ràng và độ chính xác cao, nhưng chỉ áp dụng được khi thiết kế đã được xác định ở mức độ nhất định, và dễ bỏ sót các chi phí "không nhìn thấy" như tích hợp, quản lý. Vì vậy thông lệ là hiệu chỉnh bằng cách cộng thêm một tỷ lệ nhất định dự phòng tích hợp và rủi ro vào tổng từ dưới lên.

Mô hình toán học dùng phương trình hồi quy và hệ số rút ra từ các dự án quá khứ để quy đổi quy mô (LOC hoặc FP) thành công sức và chi phí. Nó khách quan và có thể kiểm chứng căn cứ nên đã trở thành chuẩn mực cho các dự án quy mô lớn và khu vực công, nhưng mang rủi ro "rác vào – rác ra": nếu dự đoán giá trị đầu vào sai thì toàn bộ kết quả sai lệch.

3. Chi tiết mô hình định lượng chính — COCOMO

COCOMO (Constructive Cost Model) là mô hình toán học tiêu biểu dựa trên LOC do Barry Boehm đề xuất năm 1981, tính công sức dựa trên quy mô mã dự kiến (KLOC) và đặc tính dự án. Ý tưởng cơ bản là "công sức là hàm phi tuyến của quy mô", công thức hóa quy luật kinh nghiệm rằng quy mô càng lớn thì do chi phí giao tiếp và tích hợp, công sức tăng nhanh hơn quy mô (số mũ lớn hơn 1). Dạng cơ bản xấp xỉ công sức = a × (KLOC)^b, trong đó hệ số a, b thay đổi theo loại dự án.

COCOMO chia dự án thành ba chế độ: Organic (hữu cơ) — quy mô nhỏ, lĩnh vực quen thuộc; Semi-detached (bán tách rời) — quy mô trung bình, kinh nghiệm hỗn hợp; Embedded (nhúng) — quy mô lớn, ràng buộc nghiêm ngặt (thời gian thực, gắn với phần cứng). Dù cùng quy mô, chế độ nhúng có số mũ b lớn hơn chế độ hữu cơ nên tốn công sức hơn nhiều. Điều này phản ánh việc "phi kinh tế theo quy mô (diseconomy of scale)" tác động khác nhau tùy tính chất dự án — một nhận thức không thể nắm bắt bằng phép nhân người-tháng đơn thuần.

Các dạng chính xác hơn là COCOMO trung gian (Intermediate) và chi tiết (Detailed) nhân thêm các yếu tố chi phí (cost driver) như độ tin cậy sản phẩm, quy mô cơ sở dữ liệu, năng lực đội ngũ, mức trưởng thành của công cụ phát triển để hiệu chỉnh. Ví dụ, phần mềm hàng không và y tế đòi hỏi độ tin cậy rất cao có hệ số nhân công sức lớn do gánh nặng kiểm chứng. Mô hình kế nhiệm COCOMO II (2000) phản ánh các phương thức phát triển hiện đại như tái sử dụng, hướng đối tượng, thành phần thương mại (COTS), phát triển xoắn ốc, cho phép đầu vào khác nhau theo từng giai đoạn từ giai đoạn prototype ban đầu (điểm ứng dụng) đến giai đoạn sau (FP, LOC). Giới hạn căn bản của COCOMO vẫn là khó dự đoán chính xác LOC ở giai đoạn đầu dự án, và việc phụ thuộc vào ngôn ngữ, phương thức phát triển.

4. Tiêu chuẩn tại Hàn Quốc — Điểm chức năng (FP) và tính giá dự án SW

Điểm chức năng (Function Point, FP) đo quy mô không phải bằng mã mà bằng chức năng từ góc nhìn người dùng. Các chức năng cung cấp cho người dùng được xác định theo năm loại — đầu vào ngoài (EI), đầu ra ngoài (EO), truy vấn ngoài (EQ), tệp logic nội bộ (ILF), tệp giao tiếp ngoài (EIF) — rồi gán trọng số theo độ phức tạp của từng chức năng và cộng lại. Ưu điểm quyết định của FP là độc lập với ngôn ngữ, công nghệ, nền tảng phát triển. Cùng một chức năng, dù làm bằng Java hay Python thì lượng chức năng cung cấp cho người dùng vẫn như nhau, vì vậy tránh được phần lớn vấn đề phụ thuộc ngôn ngữ và khó dự đoán sớm mà phương thức dựa trên LOC gặp phải. Ngoài ra, nó có thể áp dụng từ giai đoạn sớm khi yêu cầu được tổng hợp nên phù hợp làm căn cứ cho đặt hàng và hợp đồng.

Vì thế, các dự án tin học hóa khu vực công tại Hàn Quốc áp dụng phương thức điểm chức năng làm phương thức tính giá chuẩn. «Hướng dẫn tính giá dự án SW» do Hiệp hội Công nghiệp Phần mềm Hàn Quốc (KOSA) sửa đổi và công bố hằng năm quy định tính chi phí phát triển bằng "điểm chức năng × đơn giá mỗi điểm chức năng". Xét con số thực tế, đơn giá mỗi FP đã được điều chỉnh từ 553,114 won năm 2020 lên 605,784 won trong bản sửa đổi tháng 5/2024, tăng 9.5%, phản ánh lạm phát sau COVID-19 và sự tăng chi phí nhân công kỹ sư SW. Ngoài ra, bản sửa đổi năm 2024 quy định tính riêng chi phí bản quyền, điều chỉnh thuật toán, thu thập – tiền xử lý – huấn luyện – kiểm chứng dữ liệu của các dự án ứng dụng AI dưới dạng chi phí công việc chuyên môn theo phương thức công sức đầu vào, bắt đầu phản ánh các hình thức dự án mới của thời đại AI tạo sinh vào hệ thống tính giá.

flowchart LR
  R["Xác định yêu cầu·chức năng"] --> FP["Đo điểm chức năng<br/>EI·EO·EQ·ILF·EIF"]
  FP --> UFP["Điểm chức năng chưa hiệu chỉnh (UFP)"]
  UFP --> ADJ["Áp dụng hệ số hiệu chỉnh"]
  ADJ --> AFP["Điểm chức năng đã hiệu chỉnh"]
  AFP --> COST["Chi phí phát triển = FP × đơn giá<br/>(năm 2024: 605,784 won)"]
  COST --> ADD["Cộng chi phí trực tiếp·lợi nhuận v.v."]
  style FP fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
  style COST fill:#fff3e0,stroke:#e8890c,stroke-width:2px

Hàm ý thực tiễn của sự chuẩn hóa này rất lớn. Do cơ quan đặt hàng và nhà thầu đo quy mô theo cùng một quy tắc, tính khách quan của ngân sách và tính minh bạch của đặt hàng được bảo đảm, và căn cứ tính giá có thể được kiểm chứng khi giám sát, kiểm toán. Ngược lại, việc đo FP cần nhân lực chuyên môn, và có giới hạn là khó phản ánh đầy đủ yêu cầu phi chức năng (hiệu năng, bảo mật) hay độ khó kỹ thuật vào quy mô, nên được bổ sung bằng cách dùng song song phương thức công sức đầu vào. [[sw-sizing-methods]] [[sw-operation-cost]]

5. So sánh và áp dụng thực tiễn — Logic lựa chọn phương pháp

Sự khác biệt giữa ba phương pháp rốt cuộc bắt nguồn từ "có thể đưa ra câu trả lời khi nào và dựa trên căn cứ gì". Khi gần như không có thông tin như ở giai đoạn đề xuất hay xem xét tính khả thi, phương pháp từ dưới lên chính xác là bất khả thi nên dùng đánh giá chuyên gia, Delphi để báo giá sơ bộ; khi yêu cầu đã được tổng hợp thì chốt quy mô bằng điểm chức năng; và khi thiết kế đã cụ thể thì kiểm chứng chính xác bằng phương pháp từ dưới lên dựa trên WBS. Trong các dự án lớn thực tế, chuẩn mực là chuyển đổi luân phiên ba phương pháp theo giai đoạn và ước tính lại.

Ví dụ cụ thể, giả sử trong hệ thống thế hệ mới của một cơ quan công (giả định), ở giai đoạn yêu cầu ước tính được 3,000FP bằng FP, nhân với đơn giá sẽ ra bản nháp chi phí phát triển khoảng 1,8 tỷ won. Sau đó khi thiết kế xong và ước tính lại từ dưới lên bằng WBS ra 2,2 tỷ won, thì khoản chênh 400 triệu won đó (khoảng 22%) phải được đọc như tín hiệu rủi ro báo hiệu bỏ sót yêu cầu hoặc đánh giá thấp yêu cầu phi chức năng. Như vậy, chính độ chênh lệch giữa các phương pháp trở thành thông tin cho quản lý rủi ro. Một ví dụ khác, phần mềm nhúng lấy điều khiển thời gian thực làm cốt lõi phải áp dụng hệ số chế độ nhúng của COCOMO để thừa nhận công sức lớn hơn so với chế độ hữu cơ; nếu bỏ qua điều này thì dễ trở thành dự án thua lỗ sau khi trúng thầu giá thấp.

6. Chuyên sâu — Sự tiến hóa của ước tính trong thời đại Agile và AI

Nếu ước tính truyền thống là kiểu dự đoán "đoán trúng toàn bộ một lần trước khi khởi động", thì Agile đảo ngược điều đó tận gốc. Trong Agile, không ước tính chính xác toàn bộ từ trước mà ước lượng backlog bằng story point — thể hiện kích thước tương đối — rồi mỗi sprint đo tốc độ (velocity) — năng suất xử lý thực tế — để liên tục dự báo lại tiến độ còn lại. Tức là thay "một lần dự đoán lớn" bằng "nhiều lần hiệu chỉnh ngắn dựa trên đo đạc thực tế", có ưu điểm thu hẹp nhanh hình nón bất định trong các dự án có mức bất định lớn. Tuy nhiên, nó không phù hợp cho so sánh giữa các tổ chức hay hợp đồng giá cố định, nên được dùng bổ trợ lẫn nhau với hệ thống điểm chức năng của đặt hàng công.

Gần đây, ước tính dựa trên dữ liệu và AI đang nổi lên. Đang có các thử nghiệm huấn luyện mô hình hồi quy học máy bằng dữ liệu quy mô, công sức, khiếm khuyết của các dự án đã hoàn thành để dự báo công sức của dự án tương tự, hoặc phân tích đặc tả yêu cầu bằng xử lý ngôn ngữ tự nhiên để tự động hóa việc đo điểm chức năng. Việc nâng cao năng suất phát triển nhờ AI tạo sinh (tự động sinh mã) đang làm lung lay chính tiền đề của ước tính dựa trên LOC và công sức hiện có, và như việc bổ sung chi phí công việc chuyên môn AI trong hướng dẫn tính giá năm 2024 đã thấy ở trên, hệ thống ước tính cũng đang ở giai đoạn cần định nghĩa lại. Đây là chủ đề quen thuộc trong các đề thi gần đây cùng với các chủ đề tương tự như ước tính quy mô phần mềm ([[sw-sizing-methods]]) và tính giá giai đoạn vận hành ([[sw-operation-cost]]), vì vậy trong bài làm nên trình bày liên kết theo mạch "giới hạn của mô hình truyền thống → bổ sung bằng Agile và AI".

7. Các lưu ý và hàm ý

1. Dùng song song và kiểm chứng chéo nhiều phương pháp giúp tăng độ chính xác. Mỗi phương pháp đơn lẻ có thiên lệch và sai số riêng, vì vậy cần áp dụng đồng thời từ trên xuống, từ dưới lên và dựa trên mô hình để đối chiếu kết quả, và không bỏ qua độ chênh lệch lớn giữa các phương pháp mà phải diễn giải nó như tín hiệu sớm của bỏ sót yêu cầu và rủi ro. Các giả định và căn cứ dùng khi ước tính nhất thiết phải được tài liệu hóa để bảo đảm khả năng truy vết.
2. Ước tính không phải sự kiện một lần mà là quy trình lặp. Theo hình nón bất định, mức bất định lớn ở giai đoạn đầu sẽ thu hẹp khi các giai đoạn tiến triển, nên cần quản lý dựa trên rủi ro: ước tính lại ở mỗi mốc (milestone) và dự trữ khoản dự phòng (contingency) tương xứng với quy mô và rủi ro.
3. Khu vực công tại Hàn Quốc lấy điểm chức năng làm chuẩn, và cần theo dõi các thay đổi chế độ. Hướng dẫn tính giá dự án SW được sửa đổi đơn giá và hạng mục hằng năm (ví dụ: đơn giá FP năm 2024 là 605,784 won, bổ sung chi phí công việc chuyên môn AI), vì vậy phải lấy hướng dẫn mới nhất làm căn cứ thì mới giữ được tính hợp lý của giá và sự minh bạch trong đặt hàng.
4. Không được quên phản ánh yêu cầu phi chức năng và độ khó kỹ thuật. FP và LOC tập trung vào quy mô chức năng nên không chứa đựng đầy đủ 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ó khi áp dụng công nghệ mới; do đó cần bổ sung bằng phương thức công sức đầu vào và hiệu chỉnh yếu tố chi phí, đồng thời quản lý đánh đổi một cách tường minh.
5. Triển vọng: AI vừa là đối tượng vừa là công cụ của ước tính. Khi AI tạo sinh thay đổi năng suất phát triển, tiền đề của quan hệ quy mô – công sức hiện có bị lung lay, đồng thời ước tính tự động dựa trên AI và ước lượng theo tình huống tương tự đang nâng cao độ chính xác. Dưới góc nhìn Kỹ sư chuyên nghiệp (Professional Engineer), cần có tầm nhìn tiến hóa: lấy nguyên lý của mô hình truyền thống làm nền tảng nhưng mở rộng và liên kết với Agile, dữ liệu và AI.

Tài liệu tham khảo

• Hiệp hội Công nghiệp Phần mềm Hàn Quốc (KOSA), «Hướng dẫn tính giá dự án phần mềm 2024» (13/05/2024): https://www.sw.or.kr
• "Đơn giá điểm chức năng (FP) phần mềm 605,784 won, điều chỉnh tăng 9.5%" (Byline Network, 05/2024): https://byline.network/2024/05/13-363/
• "KOSA công bố bản sửa đổi tính giá dự án SW… phản ánh cả hệ thống tính giá cho dự án AI" (Digital Today): https://www.digitaltoday.co.kr/news/articleView.html?idxno=517431
• Tổng quan COCOMO (Constructive Cost Model): https://en.wikipedia.org/wiki/COCOMO
• Tổng quan Function point: https://en.wikipedia.org/wiki/Function_point

Tóm tắt một câu: Ước tính chi phí SW là quyết định mang tính quản lý rủi ro nhằm dự báo công sức, thời gian, chi phí trước khi khởi động, trong đó từ trên xuống (chuyên gia, Delphi), từ dưới lên (WBS) và mô hình toán học (COCOMO, điểm chức năng) có sự đánh đổi về độ chính xác, tính khách quan và thời điểm; khu vực công tại Hàn Quốc dùng chuẩn điểm chức năng (năm 2024: 605,784 won/FP), và cốt lõi là dùng song song, kiểm chứng chéo nhiều phương pháp cùng sự tiến hóa sang ước tính dựa trên Agile và AI.