Quy trình phát triển phần mềm SDLC là gì? So sánh với Agile

SDLC là khung vòng đời mô tả những việc phải xảy ra để đưa phần mềm vào vận hành, gồm sáu pha và các cổng kiểm soát. Agile là cách chia nhỏ và lặp lại việc giao hàng trong khung đó. SDLC trả lời phải làm gì, Agile trả lời làm theo nhịp nào.

Tóm tắt nhanh

• SDLC là khung vòng đời, không phải một phương pháp cụ thể như Scrum hay Waterfall.
• Sáu pha thường gặp: khám phá, phân tích, thiết kế, xây dựng, kiểm thử, triển khai và vận hành.
• Cổng kiểm soát là điểm dừng có tiêu chí, không phải cuộc họp báo cáo.
• Agile thay đổi cách chia việc và cách lấy phản hồi, không xoá bỏ các pha.
• Chọn cách chạy theo ràng buộc: phạm vi cố định, thời hạn cố định, hay phạm vi chưa rõ.

SDLC là khung vòng đời, không phải phương pháp

SDLC là viết tắt của software development life cycle, nghĩa là vòng đời phát triển phần mềm. Nó mô tả các loại công việc phải xảy ra để một ý tưởng trở thành phần mềm đang chạy và được duy trì.

Vì là khung vòng đời, SDLC không quy định bạn họp bao lâu, chia việc thế nào, hay giao hàng mỗi tuần một lần. Những điều đó thuộc về phương pháp. Waterfall, Scrum, Kanban đều là cách chạy trong khung SDLC, không phải phiên bản khác của SDLC.

Sự nhầm lẫn này gây ra hai lỗi thực tế. Lỗi thứ nhất là nói "chúng tôi không làm SDLC, chúng tôi làm Agile", trong khi thực tế vẫn phải khám phá yêu cầu, thiết kế, xây dựng, kiểm thử. Lỗi thứ hai là dùng SDLC như lý do để biện minh cho việc không lấy phản hồi sớm.

Cách hiểu đúng: SDLC là danh sách việc không thể bỏ, Agile là cách sắp xếp thứ tự và nhịp lặp cho danh sách đó.

Sáu pha và cổng kiểm soát

Cổng kiểm soát là phần hay bị làm hình thức nhất. Một cổng có hiệu lực cần ba thứ: tiêu chí viết trước, người có quyền quyết định, và hệ quả rõ ràng khi không đạt. Nếu cổng chỉ là cuộc họp để nghe báo cáo, nó không ngăn được việc chuyển sang pha sau với giả định sai.

Trong thực tế, các pha không nhất thiết chạy tuần tự một lần. Chúng có thể lặp lại theo từng phần sản phẩm. Điều không đổi là mỗi phần đều phải đi qua đủ sáu loại công việc, dù thời lượng khác nhau.

Agile thay đổi điều gì và không thay đổi điều gì

Agile thay đổi ba thứ. Thứ nhất là kích thước lô: thay vì gom toàn bộ yêu cầu rồi mới xây, Agile chia thành phần nhỏ giao được. Thứ hai là nhịp lấy phản hồi: thay vì chờ đến cuối dự án, Agile tạo điểm phản hồi đều đặn. Thứ ba là cách lập kế hoạch: thay vì cố định phạm vi, Agile cố định thời gian và điều chỉnh phạm vi.

Agile không thay đổi bốn thứ. Vẫn phải hiểu yêu cầu đủ sâu để xây đúng. Vẫn phải có thiết kế, dù thiết kế có thể nằm trong tài liệu ngắn thay vì tài liệu dày. Vẫn phải kiểm thử, dù kiểm thử có thể chạy tự động. Vẫn phải có người chịu trách nhiệm vận hành sau khi giao.

Điểm dễ hiểu sai là cho rằng Agile nghĩa là không cần tài liệu. Thực tế Agile giảm tài liệu không ai đọc, không giảm tài liệu cần cho người vận hành. Một hệ thống chuyển giao cho đội khác mà không có tài liệu kiến trúc và hướng dẫn triển khai sẽ tạo ra chi phí lớn hơn nhiều so với thời gian viết tài liệu.

Bảng so sánh trên sáu tiêu chí

Không có cột nào tốt hơn tuyệt đối. Cách chạy tuần tự có lợi thế khi phạm vi đã được xác định bởi yếu tố bên ngoài, ví dụ một quy định mới hoặc một quy trình đã được chuẩn hoá. Cách chạy lặp có lợi thế khi người dùng chưa biết chính xác mình cần gì, hoặc khi thị trường thay đổi nhanh.

Chọn theo ràng buộc dự án

Bảng này dùng để chọn cách chạy, không dùng để chọn tên gọi. Một dự án có thể dùng vòng lặp hai tuần nhưng vẫn phải giữ cổng kiểm soát ở các mốc pháp lý. Ngược lại, một dự án chạy tuần tự vẫn có thể lấy phản hồi sớm bằng bản mẫu giao diện.

Một dự án lai trong thực tế

Giả sử dự án có 16 tuần, ba nhóm người dùng, và một tích hợp với hệ thống kế toán của khách hàng. Cách chạy lai có thể như sau.

Tuần 1 đến 3: khám phá và phân tích. Phỏng vấn ba nhóm người dùng, vẽ luồng nghiệp vụ hiện tại, xác định phạm vi và tiêu chí thành công. Kết thúc bằng một buổi duyệt có chủ đầu tư. Đây là cổng 1.

Tuần 4 đến 6: thiết kế và chuẩn bị môi trường. Chốt kiến trúc, mô hình dữ liệu, giao diện chính, và quan trọng nhất là chốt cách tích hợp với hệ thống kế toán. Đây là cổng 2, vì tích hợp sai sẽ kéo theo toàn bộ phần sau.

Tuần 7 đến 14: xây dựng theo vòng hai tuần. Bốn vòng, mỗi vòng có bản dựng chạy được trên môi trường thử. Cuối mỗi vòng có buổi xem kết quả với người dùng đại diện. Cổng 3 đặt ở cuối tuần 10, sau hai vòng, để quyết định có điều chỉnh phạm vi hay không.

Tuần 15 đến 16: kiểm thử, chuyển giao và đo lường. Kiểm thử theo kịch bản đã viết từ tuần 12, diễn tập chuyển dữ liệu, đào tạo người dùng, và thiết lập cách đo sau khi chạy thật. Đây là cổng 4 và cũng là điểm bắt đầu giai đoạn bàn giao và đo lường.

Điểm đáng chú ý: dự án này có bốn cổng và bốn vòng lặp. Cổng kiểm soát không mâu thuẫn với vòng lặp; chúng trả lời hai câu hỏi khác nhau. Cổng hỏi "đã đủ điều kiện để đi tiếp chưa", vòng lặp hỏi "tuần này học được gì".

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

SDLC có phải là Waterfall không?

Không. SDLC là khung vòng đời gồm các loại công việc phải làm. Waterfall là một cách chạy tuần tự các công việc đó, mỗi pha hoàn thành rồi mới sang pha sau. Có thể chạy SDLC theo cách lặp, theo cách tuần tự, hoặc theo cách lai. Vì vậy không nên dùng hai từ này thay cho nhau.

Dự án nhỏ có cần đủ sáu pha không?

Có, nhưng thời lượng khác nhau. Một dự án nhỏ vẫn cần hiểu yêu cầu, chọn cách xây, kiểm tra và có người chịu trách nhiệm vận hành. Điều có thể giảm là hình thức tài liệu và số lượng cổng. Cách làm phổ biến là gộp pha phân tích và thiết kế vào một tài liệu ngắn, giữ nguyên pha kiểm thử.

Agile có thay thế được cổng kiểm soát không?

Không. Agile tạo ra các điểm phản hồi thường xuyên, nhưng không thay thế quyết định chuyển giao hay quyết định đầu tư. Các quyết định đó vẫn cần tiêu chí và người có thẩm quyền. Trong nhiều dự án, cổng kiểm soát được đặt ở cấp lãnh đạo, còn vòng lặp được đặt ở cấp đội.

Làm sao biết nên chọn cách chạy nào?

Bắt đầu từ ràng buộc chặt nhất. Nếu phạm vi bị quy định bởi bên ngoài, cách chạy tuần tự có lợi hơn. Nếu thời hạn cố định và phạm vi có thể điều chỉnh, cách chạy lặp có lợi hơn. Nếu cả hai đều cố định, cách thực tế là chia nhỏ phạm vi thành các phần bắt buộc và phần mong muốn, rồi giữ cổng ở các mốc lớn.

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

Cập nhật tháng 11/2026. Hai văn bản dưới đây được dùng để đối chiếu phần bàn giao và phần xác lập thoả thuận giữa các bên.

• Bộ luật Dân sự số 91/2015/QH13 — vanban.chinhphu.vn
• Luật Sở hữu trí tuệ số 50/2005/QH11, bản sửa đổi năm 2025 — vanban.chinhphu.vn

Đây không phải tư vấn pháp lý hay tư vấn thuế. Cách chạy phù hợp phụ thuộc vào bối cảnh từng dự án; nội dung bài viết là khung tham chiếu, không phải quy trình bắt buộc cho mọi tổ chức.

Bài viết liên quan: quy trình phát triển phần mềm xoắn ốc, quy trình phát triển phần mềm RUP, quy trình phát triển phần mềm là gì và thuế GTGT của phần mềm là bao nhiêu.

Nếu bạn cần một quy trình có cổng kiểm soát rõ ràng thay vì một chuỗi cuộc họp, WinSell xây dựng phần mềm theo yêu cầu theo bốn giai đoạn Khám phá, Đặc tả, Xây dựng, Bàn giao và đo lường — xem dịch vụ của WinSell. Báo giá sau khi chốt phạm vi.