Giải thích mô hình COCOMO: Công thức, Phân loại và Ước tính Chi phí Phần mềm

Bạn đã bao giờ được hỏi một dự án phần mềm sẽ mất bao lâu và nhận ra câu trả lời tốt nhất của mình về cơ bản chỉ là phỏng đoán?

Đó là cách hầu hết các nhóm tiếp cận việc ước tính chi phí kỹ thuật phần mềm vào những năm 1970. Dự án thường xuyên đội chi phí và trễ hạn, và các phương pháp được sử dụng khi đó—chủ yếu là phán đoán chuyên gia và so sánh sơ bộ—không còn hiệu quả khi hệ thống trở nên lớn hơn và phức tạp hơn.

COCOMO được xây dựng để khắc phục điều đó. Nó là viết tắt của COnstructive COst MOdel. Barry W. Boehm giới thiệu trong cuốn sách năm 1981 Software Engineering Economics, dựa các công thức trên dữ liệu dự án thực tế thay vì trực giác. Nó trở thành một trong những mô hình ước tính thuật toán được giảng dạy rộng rãi nhất trong lĩnh vực này. Boehm, người qua đời vào tháng 8/2022, đã dành hàng thập kỷ để tinh chỉnh các ý tưởng đằng sau mô hình.

Trong hướng dẫn này, tôi sẽ giải thích cách mô hình hoạt động, ý nghĩa các loại và cấp độ khác nhau, và chạy một ví dụ số đầy đủ để các con số có ý nghĩa trong thực tế.

Mô hình COCOMO trong Kỹ thuật Phần mềm là gì?

COCOMO là mô hình tham số để ước tính chi phí phần mềm. Nó nhận một đầu vào chính, cụ thể là kích thước ước tính của dự án phần mềm đo bằng Hàng Nghìn Dòng Mã (KLOC), và dùng nó để dự đoán ba điều: tổng công sức tính bằng người-tháng (PM), thời gian phát triển tính bằng tháng, và số người cần thiết.

Mô hình giả định rằng kích thước dự án là yếu tố dự báo chính của công sức. Boehm xây dựng các hằng số của mô hình bằng cách chạy phân tích hồi quy trên dữ liệu dự án lịch sử thực tế.

Tuy vậy, COCOMO không ước tính trực tiếp chi phí tiền tệ. Nó ước tính công sức. Để chuyển người-tháng thành đô la, bạn nhân với chi phí lao động trung bình cho mỗi người-tháng tại tổ chức của bạn. Mô hình cung cấp công sức; bạn cung cấp đơn giá.

Vì sao mô hình COCOMO được phát triển

Boehm làm Giám đốc Nghiên cứu và Công nghệ Phần mềm tại TRW Aerospace, và sự bức xúc là trực tiếp và thực tế. Theo một bài tri ân sau này do Viện Hàn lâm Kỹ thuật Quốc gia công bố, một phó chủ tịch của TRW đã nói với Boehm sau khi xem xét một hồ sơ thầu phần mềm cạnh tranh: "Tôi không bao giờ muốn phải ký duyệt một hồ sơ thầu phần mềm chỉ dựa trên niềm tin nữa. Hãy đi và phát minh ra một cách ước tính đáng tin cậy chi phí phát triển một sản phẩm phần mềm."

Yêu cầu đó trở thành COCOMO. Boehm nghiên cứu 63 dự án đã hoàn thành tại TRW, bao phủ phần mềm từ 2.000 đến 100.000 dòng mã, viết bằng các ngôn ngữ từ hợp ngữ đến PL/I, tất cả được xây dựng theo mô hình thác nước. Phân tích hồi quy trên bộ dữ liệu đó tạo ra các hằng số dùng trong COCOMO I, và mô hình được công bố vào năm 1981.

Công thức mô hình COCOMO và cách hoạt động

Toán học đằng sau COCOMO I Cơ bản khá đơn giản khi bạn hiểu ý nghĩa từng thành phần.

Công thức công sức là:

Ở đây, công sức được đo bằng người-tháng, KLOC là kích thước phần mềm ước tính tính bằng nghìn dòng mã, và a và b là các hằng số phụ thuộc vào loại dự án bạn đang thực hiện.

Công thức thời gian phát triển được suy ra từ ước tính công sức:

Hằng số d thay đổi theo chế độ, trong khi c cố định ở 2,5 cho cả ba. Nhiều hướng dẫn viết sai khi ám chỉ cả bốn hằng số đều thay đổi. Khi bạn có cả Effort và , bạn có thể ước tính số người trung bình cần thiết:

Bảng dưới đây cho thấy các hằng số đã được kiểm chứng cho COCOMO I Cơ bản:

Biến then chốt ở đây là b. Với dự án Organic, b = 1,05, nghĩa là công sức tăng gần tuyến tính theo kích thước dự án. Với dự án Embedded, b = 1,20, tạo ra hiện tượng phi kinh tế theo quy mô đáng kể: gấp đôi kích thước dự án embedded sẽ cần hơn gấp đôi công sức.

Các loại mô hình COCOMO (COCOMO I)

COCOMO I phân loại dự án phần mềm thành ba chế độ phát triển. Mỗi chế độ phản ánh sự kết hợp khác nhau giữa kinh nghiệm của đội ngũ, độ phức tạp của dự án và các ràng buộc vận hành. Chế độ bạn chọn quyết định các hằng số sẽ dùng trong công thức.

Cần lưu ý trước: ba chế độ này chỉ áp dụng cho COCOMO I. COCOMO II, bản cập nhật năm 2000, đã thay thế chúng bằng một cách tiếp cận khác.

Ba chế độ COCOMO I được trực quan hóa. Ảnh do Tác giả thực hiện.

Ba chế độ nằm trên một thang đo với độ phức tạp và ràng buộc tăng dần. Loại dự án và bối cảnh đội ngũ của bạn thường sẽ làm rõ chế độ nào phù hợp.

Chế độ Organic

Chế độ Organic bao phủ các dự án nhỏ đến trung bình nơi đội ngũ có kinh nghiệm tốt với miền ứng dụng, yêu cầu tương đối rõ ràng, và không có áp lực bên ngoài đáng kể từ ràng buộc phần cứng hoặc yêu cầu quy định. Một hệ thống tính lương, ứng dụng xử lý dữ liệu, hoặc công cụ quản lý tồn kho thường thuộc nhóm này.

Vì đội ngũ có kinh nghiệm và miền quen thuộc, chi phí giao tiếp vẫn thấp ngay cả khi dự án mở rộng. Đó là lý do số mũ b là nhỏ nhất trong ba chế độ.

Chế độ Semi-detached

Chế độ Semi-detached nằm ở giữa. Các đội trong nhóm này có kinh nghiệm hỗn hợp: một số thành viên hiểu rõ miền, số khác thì không. Dự án có độ phức tạp vừa phải, và có thể có tương tác với phần cứng mới hoặc hệ thống bên ngoài.

Phát triển trình biên dịch, hệ thống xử lý giao dịch, và ứng dụng doanh nghiệp tầng trung là các ví dụ phổ biến. Hiện tượng phi kinh tế theo quy mô rõ rệt hơn ở đây, với b = 1,12.

Chế độ Embedded

Chế độ Embedded áp dụng cho các dự án có ràng buộc vận hành chặt chẽ: yêu cầu phần cứng nghiêm ngặt, đòi hỏi xử lý thời gian thực, tiêu chuẩn quy định, hoặc yêu cầu hàng không vũ trụ và quốc phòng. Đội ngũ có thể lớn và giỏi kỹ thuật, nhưng độ phức tạp của tích hợp, kiểm thử và thẩm định làm công sức tăng mạnh khi quy mô dự án tăng.

Với b = 1,20, dự án embedded có mức phi kinh tế theo quy mô dốc nhất trong ba chế độ. Chế độ Embedded cũng không phụ thuộc vào kích thước dự án: ngay cả một hệ thống nhúng tương đối nhỏ cũng thuộc nhóm này nếu hoạt động dưới các ràng buộc nghiêm ngặt.

COCOMO Cơ bản so với Trung gian và Chi tiết

Ngoài ba chế độ dự án, COCOMO I có ba cấp độ chi tiết ước tính. Các chế độ cho bạn biết dùng hằng số nào; các cấp độ cho bạn biết mô hình hóa dự án sâu đến đâu. Mỗi cấp độ xây dựng trên cấp trước bằng cách thêm nhiều yếu tố vào phép tính, từ đó tăng độ chính xác nhưng đòi hỏi nhiều dữ liệu đầu vào hơn.

Hãy coi đó như một phổ liên tục: COCOMO Cơ bản cho bạn con số ước lượng nhanh, còn COCOMO Chi tiết cho phép bạn lập kế hoạch chính xác ở cấp độ pha.

Các cấp COCOMO I theo độ sâu chi tiết ước tính. Ảnh do Tác giả thực hiện.

Đi xuống phía đáy kim tự tháp là thêm nhiều yếu tố vào phép tính, làm tăng độ chính xác nhưng cũng yêu cầu nhiều dữ liệu đầu vào hơn để bắt đầu.

COCOMO Cơ bản

COCOMO Cơ bản chỉ dùng kích thước dự án tính bằng KLOC và chế độ dự án. Bạn điền KLOC, áp dụng các hằng số cho chế độ đã chọn, và nhận được ước tính công sức. Điều này hữu ích cho đánh giá tính khả thi sớm khi bạn chưa có thông tin chi tiết về đội ngũ hay môi trường phát triển.

COCOMO Trung gian

COCOMO Trung gian đưa vào Hệ số Điều chỉnh Công sức, thường viết là EAF. Danh sách đầy đủ các hệ số nhân trình điều khiển chi phí được ghi trong Sổ tay Định nghĩa Mô hình COCOMO II. Công thức công sức trở thành:

EAF là tích của 15 trình điều khiển chi phí, mỗi cái được chấm từ Rất Thấp đến Rất Cao. Các trình điều khiển thuộc bốn nhóm: thuộc tính sản phẩm (độ tin cậy, độ phức tạp, kích thước cơ sở dữ liệu), thuộc tính phần cứng (ràng buộc thời gian chạy và lưu trữ), thuộc tính nhân sự (kinh nghiệm và năng lực đội ngũ), và thuộc tính dự án (công cụ, áp lực tiến độ, và thực hành phát triển).

Một điều cần biết về COCOMO Trung gian: hằng số a thay đổi so với giá trị trong Cơ bản. Với chế độ Organic, a trở thành 3,2 (không phải 2,4). Với chế độ semi-detached, nó giữ ở 3,0. Với chế độ Embedded, nó giảm còn 2,8. Các số mũ b, c và d giữ nguyên giữa hai cấp Cơ bản và Trung gian.

Các trình điều khiển chi phí về nhân sự có hướng ngược lại: năng lực cao hơn nghĩa là hệ số nhân nhỏ hơn, từ đó giảm ước tính công sức. Một đội ngũ lập trình viên giàu kinh nghiệm đơn giản là không cần nhiều người-tháng như một đội ngũ mới vào nghề để hoàn thành dự án.

COCOMO Chi tiết

COCOMO Chi tiết, đôi khi gọi là COCOMO Nâng cao, áp dụng các hệ số nhân công sức ở cấp độ từng pha thay vì trên toàn bộ dự án. Điều này có nghĩa là các trình điều khiển chi phí cho phân tích yêu cầu, thiết kế chi tiết, lập trình, và tích hợp & kiểm thử được đánh giá riêng biệt.

Đây là cấp độ chính xác nhất, đồng thời tốn thời gian nhất để sử dụng. Nó phù hợp cho các dự án lớn nơi các đội khác nhau phụ trách các pha khác nhau và phân bổ công sức theo pha quan trọng cho việc lập kế hoạch.

COCOMO II: Phiên bản hiện đại

Đến giữa thập niên 1990, COCOMO I bộc lộ hạn chế. Phát triển phần mềm đã chuyển từ các dự án thác nước trên máy lớn sang lập trình hướng đối tượng, thư viện thành phần tái sử dụng, tạo mẫu nhanh, và hệ thống phân tán trên máy tính để bàn. Áp dụng dữ liệu dự án của thập niên 1970 cho môi trường phần mềm những năm 1990 cho ra các ước tính thiếu tin cậy.

Boehm và các đồng nghiệp tại USC Center for Software Engineering đã dành vài năm xây dựng lại mô hình từ đầu. Kết quả là COCOMO II, được công bố vào năm 2000 trong cuốn Software Cost Estimation with COCOMO II, được hiệu chỉnh dựa trên bộ dữ liệu 161 dự án, hơn gấp đôi 63 dự án của mô hình gốc.

Các động lực đằng sau COCOMO II là phát triển hướng đối tượng và dựa trên thành phần, tái sử dụng phần mềm và tích hợp giải pháp thương mại sẵn có, các mô hình phát triển lặp và xoắn ốc, cùng công cụ hiện đại. Một ngộ nhận phổ biến cần làm rõ: COCOMO II không được xây dựng cho Agile. Agile như chúng ta biết ngày nay hầu như chưa tồn tại khi mô hình được phát triển từ 1995 đến 2000.

Ba mô hình con của COCOMO II

COCOMO II cung cấp ba mô hình con, mỗi mô hình phù hợp với một giai đoạn khác nhau trong vòng đời dự án.

Application Composition Model được thiết kế cho giai đoạn tạo mẫu sớm, đặc biệt khi các đội dùng công cụ xây dựng GUI và thư viện thành phần. Thay vì KLOC, nó dùng Object Points: màn hình, báo cáo, và các thành phần ngôn ngữ thế hệ thứ ba được trọng số theo độ phức tạp và điều chỉnh theo mức tái sử dụng dự kiến. Đây là mô hình tuyến tính, không có yếu tố quy mô hay điều chỉnh số mũ.

Early Design Model dùng trước khi kiến trúc được xác lập. Nó nhận Function Points chưa điều chỉnh làm đầu vào, chuyển đổi sang số dòng mã nguồn tương đương bằng các bảng theo ngôn ngữ, và áp dụng bảy trình điều khiển chi phí. Nó đưa ra ước tính hợp lý khi bạn biết hệ thống cần làm gì nhưng chưa biết sẽ xây dựng thế nào.

Post-Architecture Model là nghiêm ngặt nhất trong ba mô hình. Nó được sử dụng sau khi kiến trúc phần mềm đã ổn định, dùng Hàng Nghìn Dòng Mã Nguồn (KSLOC) hoặc function points làm đầu vào, 17 trình điều khiển chi phí, và năm yếu tố quy mô. Công thức công sức là:

Trong đó E là số mũ động được tính như sau:

Và công thức tiến độ là:

Trong đó:

Các hằng số 2,94, 0,91, 3,67, và 0,28 đến từ hiệu chỉnh COCOMO II.2000. Một số nguồn cũ ghi 2,5 thay vì 2,94; đó là giá trị hiệu chỉnh trước năm 2000 và không nên dùng với mô hình hiện tại. Công cụ Web COCOMO II của USC tại softwarecost.org là một triển khai miễn phí, trực tuyến của mô hình Hậu Kiến trúc nếu bạn muốn chạy ước tính mà không cần tự tính toán.

Trình điều khiển chi phí và Yếu tố quy mô trong COCOMO

Hai cơ chế khiến COCOMO II hoạt động khác COCOMO I: yếu tố quy mô và trình điều khiển chi phí. Dưới đây là vai trò của từng cơ chế.

Trong COCOMO I, số mũ b cố định theo chế độ: bạn chọn Organic, semi-detached, hoặc Embedded, và nhận một con số định sẵn. COCOMO II thay thế bằng năm yếu tố quy mô được chấm liên tục, tính số mũ dựa trên cách bạn đánh giá từng yếu tố.

Năm yếu tố quy mô trong COCOMO II là tính tiền lệ (PREC), linh hoạt phát triển (FLEX), kiến trúc và xử lý rủi ro (RESL), gắn kết đội ngũ (TEAM), và trưởng thành quy trình (PMAT). Mỗi yếu tố được chấm từ Rất Thấp đến Rất Cao, và tổng của chúng quyết định E trong công thức công sức. Tổng cao hơn nghĩa là dự án kém trưởng thành, ít quen thuộc, rủi ro hơn—tức số mũ cao hơn và cần nhiều công sức hơn.

Yếu tố quy mô ảnh hưởng đến hình dạng đường cong công sức. Ngược lại, trình điều khiển chi phí là các điều chỉnh nhân lên áp dụng cho công sức cơ sở. COCOMO II có 17 trình điều khiển chi phí trong mô hình Hậu Kiến trúc, so với 15 trong COCOMO I Trung gian. Các bổ sung trong COCOMO II gồm các yếu tố về yêu cầu tái sử dụng (RUSE), yêu cầu tài liệu (DOCU), biến động nền tảng (PVOL), tính liên tục nhân sự (PCON), kinh nghiệm ứng dụng (APEX), kinh nghiệm nền tảng (PLEX), kinh nghiệm ngôn ngữ và công cụ (LTEX), và phát triển đa địa điểm (SITE).

Một trình điều khiển chi phí đáng chú ý là SCED, bao quát tiến độ phát triển yêu cầu. Nếu bạn nén tiến độ một cách đáng kể, hệ số nhân công sức tăng trên 1,0, nghĩa là bạn thực sự cần nhiều người-tháng hơn để hoàn thành nhanh hơn. Điều này phù hợp với trải nghiệm của đa số kỹ sư: ép đội ngũ chạy nước rút dẫn đến chi phí điều phối, lỗi, và làm lại—thường tốn kém hơn thời gian tiết kiệm được.

Ưu điểm của mô hình COCOMO

Điểm mạnh chính của mô hình là tính minh bạch. Không giống công cụ ước tính độc quyền, COCOMO công bố toàn bộ phương trình, hằng số và phương pháp hiệu chỉnh. Bất kỳ ai cũng có thể kiểm tra đầu vào và xác minh đầu ra. Điều này hữu ích trong mua sắm của chính phủ, quốc phòng và hàng không vũ trụ, nơi khả năng kiểm toán toán học thường là yêu cầu pháp lý hoặc hợp đồng.

Mô hình cũng có thể được hiệu chỉnh lại. Các tổ chức thu thập dữ liệu lịch sử dự án riêng có thể điều chỉnh các hằng số để phản ánh môi trường, thành phần đội ngũ và công nghệ cụ thể của họ. Điều này quan trọng vì các hằng số mặc định xuất phát từ các bộ dữ liệu đã có từ hàng thập kỷ trước.

Cấu trúc ba cấp (Cơ bản → Trung gian → Chi tiết) là một lợi ích thực tế khác. Ở giai đoạn đầu dự án, khi biết rất ít, bạn dùng Cơ bản để có ước tính sơ bộ. Khi dự án trưởng thành và hiểu rõ hơn về đội ngũ và môi trường, bạn chuyển sang Trung gian hoặc Chi tiết để lập kế hoạch tinh hơn.

Hạn chế của mô hình COCOMO

Hạn chế lớn nhất là sự phụ thuộc của COCOMO vào KLOC. Để dùng COCOMO, bạn cần ước tính kích thước dự án bằng số dòng mã trước khi viết mã. Ở giai đoạn đầu—khi ước tính quan trọng nhất—điều này nổi tiếng là khó chính xác.

Ngay cả khi có thể ước tính KLOC, các hằng số trong COCOMO I đến từ 63 dự án xây dựng theo mô hình thác nước giữa 1968 và 1979. Các hằng số trong COCOMO II đến từ 161 dự án của thập niên 1990. Không bộ nào bao gồm hệ thống cloud-native, ứng dụng di động, kiến trúc microservices, hay pipeline DevOps hiện đại. Áp dụng trực tiếp các hằng số này cho một dự án hiện đại mà không hiệu chỉnh cục bộ sẽ cho ước tính thiếu tin cậy.

Một nghiên cứu năm 2025 đã lượng hóa điều này. COCOMO Cơ bản không hiệu chỉnh khi áp dụng cho bộ dữ liệu dự án NASA cho ra sai số tương đối trung bình khoảng 100%, không có dự đoán nào nằm trong phạm vi 25% so với công sức thực tế. Đó không phải sai số nhỏ; nó phản ánh một mô hình được dùng ngoài điều kiện mà nó được xây dựng.

Mô hình cũng không xử lý tốt phát triển lặp. COCOMO giả định vòng đời tương đối tuần tự. Các đội Agile làm việc theo sprint ngắn với backlog biến động không phù hợp với giả định thác nước ăn sâu trong cấu trúc COCOMO.

Còn có một vấn đề sâu hơn. Một bài báo đăng trên Frontiers in Artificial Intelligence vào tháng 3/2026 lập luận rằng COCOMO II về cơ bản không phù hợp với phát triển phần mềm có hỗ trợ AI, không chỉ ở mức hiệu chỉnh mà là cấu trúc. Khi công cụ AI sinh phần lớn mã nguồn, KLOC như một đại diện cho công sức con người trở nên sai lệch. Công sức giờ tập trung vào thẩm định, quản trị kiến trúc, và rà soát bảo mật—những thứ mà khung trình điều khiển chi phí của COCOMO không được thiết kế để nắm bắt.

Mô hình COCOMO so với các kỹ thuật ước tính khác

COCOMO không phải lựa chọn duy nhất. Biết các phương án thay thế giúp bạn chọn cách tiếp cận phù hợp cho từng tình huống.

Phân tích Function Point (FPA) đo độ phức tạp hệ thống từ đầu vào/đầu ra hướng người dùng, độc lập với ngôn ngữ lập trình. Nó hoạt động tốt khi bạn có yêu cầu vững chắc nhưng chưa ước tính được KLOC. Mô hình Early Design của COCOMO II chấp nhận function points làm đầu vào, do đó có thể dùng cùng nhau.

Story Points là tiêu chuẩn trong môi trường Agile. Các đội chấm câu chuyện người dùng theo độ phức tạp tương đối, rồi theo dõi tốc độ để dự phóng tiến độ. Chúng nhanh và phụ thuộc đội ngũ, nhưng không tạo ra đường cơ sở tổng chi phí mà mua sắm và lập kế hoạch dài hạn cần. COCOMO và story points phục vụ mục đích khác nhau.

Các công cụ tham số như SEER-SEM và SLIM sử dụng cơ sở dữ liệu hiệu chỉnh độc quyền và bộ tham số rộng hơn. Nghiên cứu cho thấy chúng chính xác hơn COCOMO II không hiệu chỉnh. Lợi thế của COCOMO là tính minh bạch và khả năng truy cập mở, điều quan trọng trong bối cảnh học thuật hoặc cần kiểm toán.

Ước tính dựa trên máy học là một lĩnh vực nghiên cứu sôi động. Một nghiên cứu tháng 1/2026 cho thấy các mô hình tổ hợp kết hợp rừng ngẫu nhiên, hồi quy véc-tơ hỗ trợ, và mạng nơ-ron vượt trội hơn các mô hình họ COCOMO trên dữ liệu dự án Agile theo cả bốn thước đo đánh giá chuẩn. Các cách tiếp cận này thích ứng với dữ liệu huấn luyện thay vì dựa vào các hằng số đặt ra hàng thập kỷ trước.

Ví dụ mô hình COCOMO (Tính toán minh họa)

Biết vị trí của COCOMO so với các phương pháp khác là hữu ích, nhưng cách tốt nhất để hiểu nó hoạt động ra sao là chạy số liệu. Hãy cùng thực hiện trọn vẹn một phép tính COCOMO I Cơ bản sử dụng chế độ Organic và một dự án ước tính 50 KLOC.

Các hằng số cho chế độ Organic là: a = 2,4, b = 1,05, c = 2,5, d = 0,38.

Bước 1: Tính công sức

Để tính 50^1.05, hãy dùng thực tế rằng .

Bước 2: Tính thời gian phát triển

Bước 3: Tính số người cần

Tổng kết:

Có hai điều đáng lưu ý. Người-tháng và tháng theo lịch là hai đơn vị khác nhau: 145,8 người-tháng trong 16,6 tháng lịch nghĩa là khoảng 9 người làm song song. Và vì đây là COCOMO Cơ bản, nó chỉ dùng kích thước và chế độ. Thêm các đánh giá trình điều khiển chi phí thực qua EAF sẽ khiến ước tính công sức tăng hoặc giảm từ đó.

Mô hình COCOMO trong phỏng vấn Kỹ thuật Phần mềm

COCOMO xuất hiện trong các khóa học học thuật, kỳ thi đại học, và phỏng vấn cho các vai trò trong chính phủ, quốc phòng, và kỹ thuật hệ thống. Nó hiếm khi xuất hiện tại các công ty công nghệ tiêu dùng theo Agile.

Câu hỏi phổ biến nhất là COCOMO I so với COCOMO II: các chế độ cố định và hằng số định sẵn từ 63 dự án so với năm yếu tố quy mô liên tục trên bộ dữ liệu hiện đại lớn hơn. Biết sự khác biệt đó, các công thức cơ bản, và tên ba chế độ là đủ cho hầu hết tình huống. Thỉnh thoảng người phỏng vấn yêu cầu một phép tính minh họa, nên ví dụ đã thực hiện ở trên đáng để luyện tập.

Kết luận: Mô hình COCOMO còn phù hợp không?

COCOMO vẫn hữu dụng khi các giả định của nó đúng: phát triển tuần tự, mua sắm chính thức, và nghiên cứu học thuật. Ở nơi phần mềm hiện đại lệch khỏi các điều kiện đó, nó mất hiệu quả.

Dùng COCOMO Cơ bản để kiểm tra nhanh bậc độ lớn ở giai đoạn đầu dự án. Dùng COCOMO Trung gian khi bạn có dữ liệu về đội ngũ và môi trường. Hiệu chỉnh theo lịch sử dự án của chính bạn trước khi dựa vào bất kỳ đầu ra nào cho hồ sơ thầu hay kế hoạch thực. Như tôi đã đề cập trong phần Hạn chế, áp dụng các hằng số mặc định cho một dự án hiện đại mà không hiệu chỉnh sẽ tạo ra sai số quá lớn để có thể hành động.

COCOMO III đang được phát triển tại Boehm CSSE từ khoảng năm 2015, chưa có bản phát hành công khai tính đến tháng 3/2026. Bản gốc năm 1981 và bản cập nhật năm 2000 vẫn là chuẩn tham chiếu.

Muốn tiến xa hơn với phát triển phần mềm? Chúng tôi có các khóa học về Nguyên tắc Kỹ thuật Phần mềm bằng Python, Phát triển Phần mềm với Cursor, và Phát triển Phần mềm với GitHub Copilot để giúp bạn xây dựng những gì bạn đã học tại đây.