Phân hệ PM Study
  • Tình huốngTình huống thực chiến
  • Kịch bảnRa quyết định tình huống
  • Biểu mẫuKho biểu mẫu tải về
  • Thẻ ghi nhớHọc thuật ngữ PMP
  • Công cụMáy tính EVM, PERT, dự phòng
  • Hỏi đápHỏi đáp & thảo luận
  • Thử tháchMỗi ngày một câu hỏi PMP
  • Lý thuyếtBài học PMBOK 8 & ECO 2026
  • Luyện thiThi thử & ôn tập PMP
  • Bài viếtThư viện bài viết PMP
PM Study
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đáp
6 chuyên mụcXem tất cả bài viết →
  • Quản lý các bên liên quanTình huống về kỳ vọng, giao tiếp và gắn kết stakeholder.
  • Lãnh đạo & đội nhómXây dựng, dẫn dắt và giải quyết xung đột trong đội dự án.
  • Kế hoạch & tiến độLập kế hoạch, ước lượng, nén tiến độ và kiểm soát baseline.
  • Rủi ro & thay đổiNhận diện, ứng phó rủi ro và kiểm soát thay đổi phạm vi.
  • Agile & HybridLựa chọn và vận hành cách tiếp cận Agile, Predictive, Hybrid.
  • Luyện thi PMPChiến lược ôn tập và mẹo xử lý câu hỏi tình huống PMP.
Công cụBài viết
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đápChuyên mụcCông cụBài viết
/
PM Study

Học quản lý dự án và ôn thi PMP bằng tiếng Việt: lý thuyết PMBOK® Guide 8, tình huống thực tế và đề luyện thi theo ECO 2026.

Chuyên mục

  • Quản lý các bên liên quan
  • Lãnh đạo & đội nhóm
  • Kế hoạch & tiến độ
  • Rủi ro & thay đổi
  • Agile & Hybrid
  • Luyện thi PMP

Tài nguyên

  • Project Management Institute (PMI)
  • PMP Exam Content Outline
  • The Scrum Guide
  • PMI Vietnam Chapter

PM Study

  • Tất cả bài viết
  • Bài viết nổi bật
© 2026 PM StudyPMP® và PMBOK® là nhãn hiệu đã đăng ký của Project Management Institute.Phiên bản 1.12.1
  1. /Kế hoạch & tiến độ
  2. /Đo phần mềm bằng "bao nhiêu chức năng" thay vì "…
Kế hoạch & tiến độ· Domain: Lập kế hoạch

Đo phần mềm bằng "bao nhiêu chức năng" thay vì "bao nhiêu dòng mã": ước lượng quy mô bằng điểm chức năng

Hai nhà thầu báo giá cùng một phần mềm chênh nhau gấp đôi, mỗi bên tính bằng một đơn vị khác. Điểm chức năng (function point) đo quy mô theo chức năng người dùng nhìn thấy, độc lập với ngôn ngữ lập trình — nền cho ước lượng, so sánh báo giá và đo năng suất.

HP
Nguyễn Thu Hà, PMP
24/10/2025
6 phút đọc 0 0
Đo phần mềm bằng "bao nhiêu chức năng" thay vì "bao nhiêu dòng mã": ước lượng quy mô bằng điểm chức năng

Tình huống minh hoạ

Tình huống và số liệu dưới đây là giả định, dùng để minh hoạ.

Một sở ngành địa phương mua phần mềm quản lý hồ sơ cấp phép. Hai nhà thầu gửi báo giá: nhà thầu A tính theo "số màn hình" (64 màn hình), nhà thầu B tính theo "tháng công" (96 tháng công). Hai báo giá chênh nhau gần gấp đôi. Tổ chuyên gia không có cách nào so sánh: "64 màn hình" và "96 tháng công" là hai thứ khác nhau, và không bên nào cho biết họ hiểu phạm vi rộng hẹp ra sao.

Vấn đề cốt lõi: không có thước đo quy mô chung. Muốn ước lượng chi phí hay thời gian, trước hết phải ước lượng được "phần mềm này lớn cỡ nào".

Vì sao không dùng số dòng mã

Số dòng mã (lines of code – LOC) là thước đo quy mô lâu đời nhất, được dùng trong các mô hình như COCOMO của Barry Boehm (1981). Nhưng LOC có ba hạn chế lớn khi ước lượng:

  • Chỉ biết sau khi viết mã — trong khi ta cần ước lượng từ trước.
  • Phụ thuộc ngôn ngữ và phong cách — cùng chức năng, mỗi ngôn ngữ cho số dòng rất khác.
  • Không phản ánh giá trị với người dùng — viết nhiều dòng hơn không có nghĩa là làm được nhiều hơn.

Điểm chức năng là gì

Allan Albrecht ở IBM giới thiệu điểm chức năng (function point – FP) năm 1979 như một đơn vị đo lượng chức năng nghiệp vụ mà hệ thống cung cấp cho người dùng. Phương pháp hiện do Hiệp hội người dùng điểm chức năng quốc tế (IFPUG) quản lý và đã được chuẩn hoá thành ISO/IEC 20926; một phương pháp khác cùng họ là COSMIC (ISO/IEC 19761).

Phân tích điểm chức năng nhìn hệ thống từ phía người dùng và đếm năm loại thành phần:

Thành phầnÝ nghĩaVí dụ trong hệ thống cấp phép
Đầu vào ngoài (External Input – EI)Dữ liệu đi vào làm thay đổi dữ liệu lưu trữNộp hồ sơ, cập nhật trạng thái
Đầu ra ngoài (External Output – EO)Thông tin đi ra có tính toán/xử lýBáo cáo thống kê theo quý
Truy vấn ngoài (External Inquiry – EQ)Truy xuất đơn giản, không tính toánTra cứu hồ sơ theo mã
Tệp logic nội bộ (Internal Logical File – ILF)Nhóm dữ liệu hệ thống tự duy trìHồ sơ, giấy phép, tổ chức
Tệp giao tiếp ngoài (External Interface File – EIF)Dữ liệu tham chiếu do hệ thống khác duy trì

Tình huống liên quan

Kế hoạch & tiến độLập kế hoạch

Ngày go-live "chắc chắn" chỉ đạt được 8% số lần mô phỏng: phân tích rủi ro tiến độ bằng Monte Carlo

Lịch dự án ERP ghi go-live ở ngày làm việc thứ 120, nhưng ba nhánh công việc cùng hội tụ vào một mốc. Mô phỏng Monte Carlo cho thấy ngày đó chỉ đạt được khoảng 8% số lần lặp. Cách đọc đường cong S, hiểu merge bias và chọn mức dự phòng tiến độ có căn cứ.

Ngày đăng: 04/10/2026Lượt xem: 0Bình luận: 0
Kế hoạch & tiến độLập kế hoạch

Đội kiểm thử quá tải 160% trong ba tuần: chọn resource leveling hay resource smoothing?

Lịch trình trông hợp lý cho tới khi xếp người vào: đội kiểm thử phải gánh 160% công suất trong ba tuần. Phân biệt resource leveling và resource smoothing, khi nào chấp nhận lùi mốc và khi nào chỉ dùng float.

Ngày đăng: 01/10/2026Lượt xem: 4Bình luận: 0
Kế hoạch & tiến độLập kế hoạch

40 ngày công không phải 8 ngày với 5 người: chuyển ước lượng công sang thời lượng cho đúng

Ước lượng 40 ngày công, chia cho 5 người, kế hoạch ghi 8 ngày. Thực tế mất 19 ngày. Phân biệt công (effort), thời lượng (duration) và thời gian trôi qua, tính hệ số khả dụng, và hiểu vì sao thêm người không rút ngắn tuyến tính.

Ngày đăng: 29/09/2026Lượt xem: 0Bình luận: 0
Kế hoạch & tiến độLập kế hoạch

Ước lượng ba điểm và PERT: khi đội chỉ đưa ra một con số lạc quan

Đội cam kết "28 ngày là xong" nhưng đó chỉ là kịch bản thuận lợi. Cách dùng ước lượng ba điểm, công thức PERT và độ lệch chuẩn để đưa ra mốc tiến độ có mức tin cậy.

Ngày đăng: 28/09/2026Lượt xem: 5Bình luận: 0
Danh mục hành chính dùng chung

Mỗi thành phần được xếp mức độ phức tạp (thấp/trung bình/cao) theo quy tắc của IFPUG và quy đổi ra điểm; tổng lại là quy mô chức năng của hệ thống.

Từ quy mô đến ước lượng

Điểm chức năng không phải là ước lượng chi phí. Nó là thước đo quy mô — đầu vào cho ước lượng tham số (parametric estimating):

  1. Đếm quy mô (FP) từ yêu cầu hoặc thiết kế sơ bộ.
  2. Lấy năng suất từ dữ liệu lịch sử của chính tổ chức (giờ công/FP), hoặc dữ liệu benchmark nếu chưa có.
  3. Tính công: quy mô × năng suất, điều chỉnh theo các yếu tố như độ phức tạp kỹ thuật, kinh nghiệm đội.
  4. Đối chiếu với một phương pháp khác (từ dưới lên hoặc tương tự).

Áp vào tình huống (số liệu minh hoạ): tổ chuyên gia thuê một chuyên gia đếm FP độc lập từ hồ sơ yêu cầu, được khoảng 820 FP. Từ đây, họ yêu cầu cả hai nhà thầu quy đổi báo giá ra đơn giá trên FP và nêu năng suất giả định. Lúc này mới thấy: nhà thầu A tính 64 màn hình nhưng bỏ qua phần báo cáo và tích hợp danh mục dùng chung; nhà thầu B có năng suất giả định thấp bất thường. Hai báo giá trở nên so sánh được.

Ví dụ đếm rút gọn cho một chức năng

Ví dụ minh hoạ cách tư duy, không thay cho bộ quy tắc đầy đủ của IFPUG.

Lấy chức năng "Nộp hồ sơ cấp phép" của hệ thống. Người đếm hỏi lần lượt:

  • Người dùng có đưa dữ liệu vào làm thay đổi dữ liệu lưu trữ không? Có — nộp hồ sơ là một EI. Việc sửa hồ sơ, rút hồ sơ là các EI riêng, vì đó là các quy trình nghiệp vụ người dùng phân biệt được.
  • Hệ thống có duy trì nhóm dữ liệu nào không? Có — "hồ sơ" và "tổ chức nộp hồ sơ" là các ILF, được đếm một lần cho toàn hệ thống dù nhiều chức năng cùng dùng.
  • Có tham chiếu dữ liệu của hệ thống khác không? Có — danh mục đơn vị hành chính dùng chung là EIF.
  • Có thông tin đi ra không? Biên nhận hồ sơ có tính hạn trả kết quả là EO; tra cứu hồ sơ theo mã không tính toán là EQ.

Điểm đáng chú ý: người đếm không hỏi dùng ngôn ngữ gì, bao nhiêu bảng cơ sở dữ liệu, bao nhiêu màn hình. Hai nhà thầu dùng hai công nghệ khác nhau vẫn phải ra cùng quy mô chức năng nếu cùng phạm vi — chính vì thế FP dùng được để so sánh báo giá.

Lợi ích ngoài ước lượng

  • Hợp đồng theo quy mô: một số tổ chức thanh toán theo FP bàn giao, giúp xử lý thay đổi phạm vi minh bạch hơn (thêm/bớt bao nhiêu FP).
  • Đo năng suất: giờ công/FP theo thời gian cho thấy đội có cải thiện không.
  • Đo chất lượng: số lỗi/FP so sánh được giữa các hệ thống khác ngôn ngữ.
  • Kiểm soát phạm vi: đếm lại FP sau mỗi đợt thay đổi yêu cầu cho thấy phạm vi "phình" bao nhiêu.

Hạn chế cần biết

  • Tốn công và cần chuyên môn: IFPUG có chứng chỉ riêng cho người đếm; đếm sai quy tắc làm kết quả lệch.
  • Có yếu tố chủ quan trong xếp mức độ phức tạp.
  • Chưa phản ánh đủ yêu cầu phi chức năng (hiệu năng, bảo mật) — IFPUG bổ sung phương pháp SNAP cho phần này.
  • Phê bình: một số nghiên cứu thấy FP tương quan mạnh với LOC, nên giá trị gia tăng có giới hạn trong một số bối cảnh.
  • Ít phù hợp với agile ước lượng ngắn hạn: đội agile thường dùng ước lượng tương đối (story point) cho sprint; FP hữu ích hơn ở cấp hợp đồng, danh mục, ngân sách.

Sai lầm thường gặp

  • Dùng năng suất "trung bình ngành" thay cho dữ liệu của chính tổ chức mà không điều chỉnh.
  • Đếm FP từ yêu cầu còn mơ hồ rồi coi như con số chính xác — FP chỉ chính xác bằng yêu cầu đầu vào.
  • Coi FP là chi phí, quên rằng cùng quy mô nhưng ràng buộc kỹ thuật khác nhau thì chi phí khác.

Góc ôn thi PMP

  • Điểm chức năng là thước đo quy mô, thường dùng làm biến đầu vào của ước lượng tham số (parametric estimating) trong Estimate Costs (7.2) và Estimate Activity Durations (6.4).
  • Ước lượng tham số = quan hệ thống kê giữa dữ liệu lịch sử và biến số (ví dụ giờ công/FP); độ chính xác phụ thuộc chất lượng dữ liệu và mô hình.
  • Trong mua sắm, khi các báo giá không so sánh được, PM/nhóm mua sắm có thể dùng ước lượng độc lập (independent estimate) làm chuẩn đối chiếu — đây là một công cụ của Conduct Procurements.

Nguồn tham khảo

  • Function point – Wikipedia
  • International Function Point Users Group (IFPUG)
  • COCOMO – Wikipedia
#function-point#ifpug#uoc-luong-quy-mo#cocomo#uoc-luong-tham-so

Trắc nghiệm tình huống PMP

Câu 1/1
Bên mua nhận ba báo giá phát triển phần mềm, mỗi nhà thầu tính chi phí theo một đơn vị khác nhau (số màn hình, tháng công, gói trọn), chênh nhau tới 80%. Bên mua chưa có ước lượng riêng. Bước tiếp theo phù hợp nhất là gì?

Bạn chọn phương án nào?

Tổ chức của bạn muốn chuyển các hợp đồng phát triển phần mềm sang thanh toán theo điểm chức năng bàn giao. Đội agile nội bộ lo rằng việc đếm FP sẽ thêm thủ tục. Nếu là PM, bạn khuyến nghị gì?

Bài viết hữu ích? Chia sẻ cho đồng nghiệp nhé!

Đánh giá bài viết

Bình luận

Mục lục

Tình huống minh hoạVì sao không dùng số dòng mãĐiểm chức năng là gìTừ quy mô đến ước lượngLợi ích ngoài ước lượngHạn chế cần biếtSai lầm thường gặpGóc ôn thi PMPNguồn tham khảoTrắc nghiệmBình chọn
Quảng cáoTemplate quản lý dự án (mẫu)
Quảng cáoBộ đề thi thử PMP (mẫu)