Quy trình phát triển phần mềm Waterfall: khi nào vẫn nên dùng

Quy trình phát triển phần mềm Waterfall vẫn phù hợp khi phạm vi đã cố định, người dùng không thể phản hồi thường xuyên, hoặc hợp đồng buộc phải chốt ngân sách trước khi bắt đầu. Điều kiện để dùng đúng là kiểm soát thay đổi chặt và có mốc thẩm định giữa các giai đoạn.

Tóm tắt nhanh

• Waterfall không có nghĩa là "làm một lần rồi mới kiểm thử". Nó có nghĩa là các giai đoạn được chốt tuần tự, mỗi giai đoạn có mốc thẩm định.
• Bốn bối cảnh nên dùng: phạm vi cố định bởi hợp đồng hoặc hồ sơ thầu; sản phẩm phải thẩm định một lần trước khi triển khai; người dùng không thể tham gia thường xuyên; hệ thống thay thế có yêu cầu tương thích nghiêm ngặt.
• Rủi ro chính của Waterfall không nằm ở phương pháp mà ở việc chốt đặc tả khi chưa đủ hiểu người dùng.
• Có năm biện pháp giữ được lợi thế tuần tự mà không bị cứng: khảo sát kỹ, nguyên mẫu ở giai đoạn đầu, thẩm định theo cổng, kiểm soát thay đổi có ghi nhận, và nghiệm thu theo mốc.

Waterfall thực sự là gì

Cách hiểu phổ biến là Waterfall gồm các giai đoạn nối tiếp: khảo sát xong mới đặc tả, đặc tả xong mới thiết kế, thiết kế xong mới lập trình, lập trình xong mới kiểm thử, kiểm thử xong mới bàn giao. Mỗi giai đoạn chỉ bắt đầu khi giai đoạn trước kết thúc.

Cách hiểu đó đúng về hình thức nhưng thiếu một phần quan trọng: mỗi điểm chuyển giai đoạn là một cổng thẩm định. Tài liệu của giai đoạn trước được xem xét, phê duyệt, và trở thành căn cứ cho giai đoạn sau. Nếu cổng này bị bỏ qua, Waterfall trở thành việc chạy theo lịch, và mọi sai sót chỉ lộ ra ở cuối.

Vì vậy, câu hỏi không phải "Waterfall có tốt hơn lặp ngắn hay không", mà là "bối cảnh này có cho phép chốt phạm vi đủ sớm và đủ chắc hay không". Nếu có, Waterfall là lựa chọn hợp lý. Nếu không, chi phí sửa sẽ dồn về cuối dự án.

Bốn bối cảnh nên dùng Waterfall

Bối cảnh thứ nhất phổ biến trong khu vực công và trong các hợp đồng có ngân sách được duyệt trước. Bối cảnh thứ ba phổ biến ở các tổ chức mà người dùng cuối là nhân viên vận hành theo ca, khó họp định kỳ.

Một điểm nối quan trọng với hợp đồng: cách phân loại giao dịch phần mềm ảnh hưởng đến điều khoản thuế, và điều khoản thuế lại ảnh hưởng đến cách ghi giá trong hồ sơ. Phần này được trình bày trong thuế GTGT của phần mềm là bao nhiêu.

Bốn bối cảnh không nên dùng

Ngược lại, Waterfall là lựa chọn tồi trong bốn trường hợp sau.

Một, sản phẩm hướng tới thị trường chưa rõ. Nếu chưa biết người dùng sẽ dùng thế nào, chốt đặc tả trước khi làm là chốt một giả định. Giả định sai sẽ chỉ lộ ra sau khi bàn giao.

Hai, yêu cầu sẽ thay đổi vì lý do bên ngoài. Ví dụ quy định pháp lý hoặc chính sách nội bộ đang trong quá trình thay đổi. Khi đó, đặc tả chốt hôm nay có thể hết hiệu lực trước khi lập trình xong.

Ba, tổ chức cần kết quả sử dụng được sớm. Waterfall tạo ra giá trị ở cuối; nếu tổ chức cần một phần chạy được trong thời gian ngắn, cách chia nhát cắt phù hợp hơn.

Bốn, đội thực hiện chưa từng làm sản phẩm tương tự. Khi chưa có kinh nghiệm về miền nghiệp vụ, các quyết định thiết kế ở giai đoạn đầu dựa trên hiểu biết chưa đủ, và chi phí sửa sẽ cao.

Cách chạy Waterfall mà không bị cứng

Nếu bối cảnh buộc phải đi tuần tự, năm biện pháp dưới đây giữ được lợi thế của Waterfall mà giảm rủi ro dồn về cuối.

1. Khảo sát kỹ hơn bình thường

Vì không có vòng phản hồi giữa đường, giai đoạn khám phá phải bù lại. Quan sát người dùng thật, thu thập dữ liệu thật, và ghi lại mọi giả định kèm cách kiểm chứng. Thời gian đầu tư ở đây thường rẻ hơn nhiều so với việc sửa ở giai đoạn kiểm thử.

2. Dùng nguyên mẫu ở giai đoạn đầu

Một nguyên mẫu giao diện, dù chỉ là bản vẽ có thể bấm, giúp người dùng phản hồi trước khi đặc tả được chốt. Đây là cách đưa phản hồi vào quy trình tuần tự mà không phá vỡ cấu trúc giai đoạn.

3. Thẩm định theo cổng, có biên bản

Mỗi điểm chuyển giai đoạn cần một biên bản thẩm định ghi rõ: tài liệu nào được xem, ai phê duyệt, điều kiện nào còn treo. Cổng không có biên bản là cổng hình thức, và giai đoạn sau sẽ phải làm lại phần chưa được xem xét.

4. Kiểm soát thay đổi có ghi nhận

Waterfall không cấm thay đổi; nó yêu cầu thay đổi phải đi qua một quy trình. Mỗi yêu cầu thay đổi cần phiếu, đánh giá ảnh hưởng đến phạm vi, tiến độ, giá, và chữ ký hai bên. Không có phiếu, thay đổi sẽ trở thành tranh chấp ở khâu nghiệm thu.

5. Nghiệm thu theo mốc, không chỉ ở cuối

Ngay trong mô hình tuần tự, có thể chia việc bàn giao thành các mốc chức năng. Mỗi mốc có biên bản riêng. Cách này tạo ra chứng từ từng phần và giảm rủi ro một lần nghiệm thu lớn ở cuối dự án.

So sánh Waterfall và nhịp lặp ngắn

Điểm cần nhấn mạnh: bảng này không xếp hạng hai cách. Mỗi cách có loại rủi ro riêng, và việc chọn cách nào là quyết định dựa trên mức độ chắc chắn của yêu cầu, không dựa trên xu hướng.

Sai sót thường gặp khi áp Waterfall

• Bỏ cổng thẩm định để chạy kịp tiến độ. Hệ quả là các sai sót ở đặc tả chỉ lộ ra ở khâu kiểm thử, khi sửa đã tốn kém.
• Chốt đặc tả bằng tài liệu do một người viết, không qua người dùng. Tài liệu đúng hình thức nhưng mô tả quy trình không tồn tại.
• Không có mục "không bao gồm" trong phạm vi. Mọi yêu cầu phát sinh đều trở thành tranh chấp.
• Để thay đổi đi qua bằng trao đổi, không có phiếu. Cuối dự án, hai bên không đối chiếu được phần nào là thay đổi.
• Nghiệm thu một lần cho toàn bộ hệ thống. Rủi ro dồn vào một thời điểm, và không có chứng từ cho từng phần đã hoàn thành.

Câu hỏi thường gặp

Waterfall có còn được dùng trong các dự án phần mềm hiện nay không?

Có, chủ yếu ở các dự án có phạm vi cố định bởi hợp đồng hoặc hồ sơ thầu, dự án cần thẩm định một lần trước khi triển khai, và dự án thay thế hệ thống cũ có yêu cầu tương thích dữ liệu nghiêm ngặt. Điều đã thay đổi là cách chạy: cổng thẩm định chặt hơn, có nguyên mẫu ở giai đoạn đầu, và nghiệm thu chia theo mốc.

Waterfall có bắt buộc phải kiểm thử ở cuối không?

Không bắt buộc. Ngay trong mô hình tuần tự, đội thực hiện vẫn nên kiểm thử từng phần khi lập trình xong, và chạy kiểm thử hồi quy ở mỗi mốc. Điều đặc trưng của Waterfall là thứ tự chốt tài liệu, không phải thứ tự kiểm thử.

Làm sao xử lý thay đổi trong dự án Waterfall?

Bằng phiếu yêu cầu thay đổi có đánh giá ảnh hưởng và chữ ký hai bên. Mỗi phiếu ghi rõ thay đổi gì, ảnh hưởng đến phạm vi, tiến độ và giá bao nhiêu, và hạng mục nào bị điều chỉnh để bù. Thay đổi không có phiếu là thay đổi không có căn cứ thanh toán.

Waterfall có phù hợp với dự án có ngân sách nhà nước không?

Thường phù hợp hơn nhịp lặp ngắn, vì ngân sách và phạm vi phải được duyệt trước. Tuy vậy, cần bù lại bằng khảo sát kỹ, nguyên mẫu ở giai đoạn đầu và nghiệm thu theo mốc. Việc phân loại gói thầu phần mềm thành hàng hoá, dịch vụ hay gói hỗn hợp cũng ảnh hưởng đến cách lập hồ sơ.

Cập nhật và kiểm chứng

Cập nhật tháng 10/2026. Nội dung phản ánh cách WinSell tổ chức bốn chặng bàn giao — Khám phá, Đặc tả, Xây dựng, Bàn giao và đo lường — và trường hợp áp dụng tuần tự. Cấu trúc tài liệu đặc tả dùng cho mô hình tuần tự được trình bày trong tài liệu đặc tả yêu cầu phần mềm; bức tranh sáu giai đoạn nằm trong quy trình phát triển phần mềm là gì.

Bài viết mang tính tham khảo, không phải tư vấn pháp lý hay tư vấn thuế. Vui lòng đối chiếu văn bản gốc và tham khảo ý kiến chuyên gia.

WinSell xây dựng phần mềm theo yêu cầu với phạm vi chốt trước, nghiệm thu theo mốc và vận hành sau bàn giao — xem dịch vụ của WinSell. Báo giá sau khi chốt phạm vi.