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. /Tình huống
  2. /Quản lý Chất lượng
  3. /Boeing Starliner OFT (12/2019): bộ đếm thời gian…
Số 199Quản lý Chất lượng

Boeing Starliner OFT (12/2019): bộ đếm thời gian lệch 11 giờ và kiểm thử phần mềm chỉ chạy theo từng đoạn

Chuyến bay thử không người lái đầu tiên của Starliner phải bỏ kế hoạch cập bến ISS vì đồng hồ nhiệm vụ lệch khoảng 11 giờ; hơn nữa một lỗi thứ hai được phát hiện chỉ vài giờ trước khi hạ cánh. Nhóm xem xét độc lập đưa ra 61 khuyến nghị về kiểm thử phần mềm, trọng tâm là kiểm thử đầu cuối. Bài học về đảm bảo chất lượng, phạm vi kiểm thử và kiểm tra tích hợp trước khi bay.

HP
Nguyễn Thu Hà, PMP
30/08/2026
4 phút đọc 0 lượt xem
Bình luận0

Bối cảnh thực tế

Ngày 20–22/12/2019, Boeing thực hiện chuyến bay thử không người lái (Orbital Flight Test, OFT) của tàu Starliner theo chương trình Commercial Crew của NASA. Tàu hạ cánh an toàn xuống White Sands, New Mexico, nhưng chỉ vào quỹ đạo sau khi dùng nhiên liệu nhiều hơn dự kiến nên không thể cập bến Trạm vũ trụ quốc tế (ISS).

Theo bài tổng hợp của SpacePolicyOnline từ buổi họp báo của NASA:

  • Lỗi thứ nhất: Mission Elapsed Timer (bộ đếm thời gian nhiệm vụ) bị đặt lệch khoảng 11 giờ. Hệ thống tự động tưởng rằng lần đốt đưa tàu vào quỹ đạo đã xảy ra nên động cơ không hoạt động đúng.
  • Lỗi thứ hai: được phát hiện vài giờ trước khi hạ cánh; nếu không sửa kịp có thể khiến khoang phục vụ và khoang phi hành đoàn va chạm khi tách rời, làm hỏng tấm chắn nhiệt hoặc dù.
  • Boeing cho rằng các lỗi phần mềm xuất phát từ quy trình kiểm thử chưa đủ.
  • Có 37 lần mất liên lạc trong hai ngày; chỉ một lần được hiểu nguyên nhân tại thời điểm đó.

Boeing lập Nhóm xem xét độc lập (IRT) và mời NASA tham gia. Nhóm đưa ra 61 khuyến nghị liên quan đến kiểm thử phần mềm; một khuyến nghị chính là chuyển từ kiểm thử theo từng đoạn sang kiểm thử đầu cuối. Lỗi đồng hồ lọt qua vì mô phỏng kết thúc ngay tại thời điểm phóng, không chạy tiếp qua bước tách tên lửa. Boeing lên kế hoạch kiểm thử đầu cuối từ phóng đến cập bến và từ rời bến đến hạ cánh. NASA xếp sự việc vào mức “high visibility close call”, và việc có bay lại hay không còn đang được xem xét; Boeing ghi nhận khoản chi phí 410 triệu USD trong quý 4/2019 phòng khi phải bay lại.

Phân tích nguyên nhân theo chuẩn PMP

  • Phạm vi kiểm thử không phủ hết luồng thực tế (Plan Quality Management)

    Mô phỏng dừng tại lúc phóng nên không bao giờ tái hiện được bước đồng bộ giờ sau khi tách tên lửa. Kế hoạch chất lượng phải xuất phát từ kịch bản vận hành thật từ đầu đến cuối, không chỉ từng thành phần được kiểm riêng lẻ.

  • Kiểm thử chia đoạn che khuất lỗi giao diện (Manage Quality)

Từng đoạn thử đều có thể đạt, nhưng lỗi nằm ở tương tác giữa các đoạn (tên lửa và tàu, đồng hồ và trình tự bay). Kiểm thử tích hợp và đầu cuối là cách duy nhất để lộ ra loại lỗi này.

  • Lỗi thứ hai bị phát hiện muộn cho thấy quy trình kiểm tra độc lập yếu

    Việc một lỗi có thể gây va chạm chỉ được phát hiện hơn một ngày sau lỗi đầu, trong lúc rà soát khẩn, cho thấy các lớp xem xét mã và kiểm chứng trước bay chưa đủ sâu. Đây là điểm cần Control Quality bằng kiểm tra độc lập thay vì dựa vào kiểm tra của chính đội phát triển.

  • Chi phí chất lượng kém (Cost of Poor Quality)

    Không đạt mục tiêu cập bến, phải rà soát lại và có thể bay lại, khoản chi phí 410 triệu USD được ghi nhận. Chi phí đầu tư kiểm thử đầu cuối nhỏ hơn nhiều chi phí thất bại.

  • Lẽ ra PM nên làm gì

    1. 1

      Bước 1: Xây kế hoạch kiểm thử xuất phát từ kịch bản nhiệm vụ

      Lập ma trận truy vết từ từng pha nhiệm vụ đến các kiểm thử bao phủ pha đó; đặt tiêu chí chấp nhận cho cổng “sẵn sàng bay”:

      • Đạt

        Kiểm thử đầu cuối chạy liên tục từ trước phóng đến cập bến, cũng như từ rời bến đến hạ cánh, không lỗi chặn.

      • Có điều kiện

        Một đoạn chỉ kiểm chứng riêng lẻ: cần đánh giá rủi ro tại giao diện và biện pháp giám sát thay thế.

      • Không đạt

        Mô phỏng kết thúc sớm hơn nhiệm vụ thật hoặc còn lỗi chưa giải thích: không qua cổng bay.

    2. 2

      Bước 2: Bổ sung kiểm tra độc lập (IV&V) cho phần mềm bay

      Giao cho đội không tham gia viết mã rà soát yêu cầu, thiết kế và kết quả thử; mọi sai khác giữa mô phỏng và vận hành thật phải được ghi nhận và đóng.

    3. 3

      Bước 3: Phân tích nguyên nhân gốc bằng quy trình học bài học

      Sau khi lỗi lộ ra, tìm cả lỗi cùng loại (đồng bộ giờ, trình tự) ở các phần khác thay vì chỉ sửa lỗi đã thấy; phản ánh thành cải tiến quy trình.

    PM Takeaway (Bài học rút ra)

    Mọi đoạn đều đạt không có nghĩa cả chuyến bay sẽ đạt. Chất lượng của hệ thống phức tạp phải được chứng minh bằng kiểm thử đầu cuối bám sát kịch bản vận hành thật, cộng với kiểm tra độc lập. Tiết kiệm ở khâu này thường đắt hơn rất nhiều khi thất bại xảy ra.

    Nguồn tham khảo

    • SpacePolicyOnline — Loverro: No Decision Yet On Repeating Starliner OFT
    #Quản lý chất lượng#Kiểm thử đầu cuối#Boeing#NASA#Hàng không vũ trụ#Phần mềm bay

    Nguồn: SpacePolicyOnline — Loverro: No Decision Yet On Repeating Starliner OFT ↗ (mở trong thẻ mới)

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

    Câu 1/1
    Hệ thống của bạn có nhiều phân hệ, mỗi phân hệ đã vượt kiểm thử riêng. Mô phỏng tích hợp hiện dừng sau bước khởi động, chưa chạy tiếp các bước sau. Trước khi phát hành, bạn nên làm gì?

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

    Lịch phát hành chỉ còn hai tuần, kiểm thử đầu cuối cần ba tuần. Bạn chọn hướng nào?

    Tình huống này hữu ích với bạn?

    Bình luận0

    Bình luận (0)

    Đăng nhập để tham gia thảo luận.

    Tình huống cùng lĩnh vực

    Quản lý Chất lượng

    Cloudflare 02/07/2019: một quy tắc WAF được đẩy toàn cầu trong vài giây, không qua canary, làm CPU toàn mạng kịch trần

    Ngày 02/07/2019, một thay đổi nhỏ trong bộ quy tắc WAF của Cloudflare chứa biểu thức chính quy gây backtracking khủng khiếp, khiến CPU của mọi máy xử lý HTTP/HTTPS trên toàn cầu gần như 100% và khách hàng nhận lỗi 502 khoảng 27 phút. Bài học về kiểm thử hiệu năng trong CI, quy trình triển khai theo giai đoạn và việc "ngoại lệ khẩn cấp" trở thành đường tắt mặc định.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận15/10/2026
    Số 149Quản lý Chất lượng

    Facebook ngoại tuyến 04/10/2021: một lệnh bảo trì, công cụ kiểm tra có lỗi và hệ thống khôi phục phụ thuộc chính mạng đã sập

    Ngày 04/10/2021, một lệnh bảo trì định đánh giá dung lượng mạng xương sống đã ngắt toàn bộ kết nối giữa các trung tâm dữ liệu của Facebook; công cụ kiểm tra lệnh có lỗi nên không chặn được. DNS biến mất khỏi Internet, công cụ nội bộ hỏng theo và kỹ sư phải đến tận nơi. Phân tích dưới góc nhìn kiểm soát thay đổi, kiểm thử tình huống thảm hoạ và phụ thuộc vòng của công cụ khôi phục.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận11/10/2026
    Số 150Quản lý Chất lượng

    Amazon S3 ngày 28/02/2017: một tham số nhập sai trong lệnh gỡ máy chủ làm gián đoạn dịch vụ lưu trữ khoảng 4 giờ 17 phút

    Trong lúc điều tra hệ thống tính phí S3 chạy chậm, một thành viên được ủy quyền chạy lệnh trong playbook nhưng nhập sai một tham số, gỡ ra nhiều máy chủ hơn dự định ở vùng US-EAST-1. AWS sau đó sửa công cụ để gỡ chậm hơn, chặn việc đưa hệ thống xuống dưới dung lượng tối thiểu và rà soát các công cụ khác. Bài học về thiết kế công cụ vận hành chống lỗi người.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận06/10/2026

    Nội dung

    Bối cảnh thực tếPhân tích nguyên nhân theo chuẩn PMPLẽ ra PM nên làm gìPM Takeaway (Bài học rút ra)Nguồn tham khảoTrắc nghiệmBình chọn
    Quảng cáoBộ đề thi thử PMP (mẫu)