Quy Trình Phát Triển Phần Mềm: 7 Giai Đoạn Và 5 Mô Hình Phổ Biến

Cập nhật ngày 19/10/2026

Tóm tắt nhanh

Quy trình phát triển phần mềm, hay vòng đời phát triển phần mềm (SDLC), gồm 7 giai đoạn: phân tích và lập kế hoạch, xác định yêu cầu, thiết kế và tạo mẫu thử, lập trình, kiểm thử, triển khai, bảo trì và cập nhật. Thứ tự các giai đoạn thay đổi theo mô hình áp dụng như thác nước, chữ V, Agile, xoắn ốc hay lặp. Với doanh nghiệp đặt làm phần mềm, hai giai đoạn đầu quyết định phần lớn chi phí và tiến độ của cả dự án (các yếu tố làm dự án nhanh hay chậm có trong bài làm phần mềm theo yêu cầu mất bao lâu).

1. Quy trình phát triển phần mềm là gì?

Quy trình phát triển phần mềm là chuỗi giai đoạn có thứ tự để đưa ý tưởng thành phần mềm vận hành được, từ phân tích nhu cầu đến bảo trì sau bàn giao. Quy trình này còn gọi là vòng đời phát triển phần mềm (SDLC), giúp các bên thống nhất việc cần làm và đầu ra của từng giai đoạn.

Một vòng đời phát triển phần mềm thông thường gồm 7 giai đoạn:

1. Phân tích và lập kế hoạch
2. Xác định yêu cầu
3. Thiết kế và tạo mẫu thử
4. Lập trình
5. Kiểm thử
6. Triển khai
7. Bảo trì và cập nhật

Các giai đoạn này về cơ bản giống nhau dù dự án áp dụng phương pháp nào; điều khác nhau là thứ tự, mức độ lặp lại và việc một số giai đoạn có chạy song song hay không, như phần 3 sẽ trình bày.

2. 7 giai đoạn trong vòng đời phát triển phần mềm

Mỗi giai đoạn dưới đây được mô tả theo ba ý: mục tiêu, đầu ra cần có và việc doanh nghiệp, với vai trò bên đặt hàng, cần chuẩn bị. Đầu ra rõ ràng ở từng giai đoạn là cách đơn giản nhất để biết dự án có đang đi đúng hướng hay không.

2.1. Phân tích và lập kế hoạch

Giai đoạn đầu tiên trả lời câu hỏi dự án có đáng làm hay không và làm trong điều kiện nào. Đội dự án xem xét mức độ gắn kết với mục tiêu kinh doanh, nguồn lực sẵn có (tự làm hay thuê ngoài), mốc thời gian dự kiến và ngân sách theo từng khoản mục.

• Đầu ra: mục tiêu đo được, phạm vi sơ bộ, ước lượng ngân sách theo dải, kế hoạch mốc chính.
• Người tham gia: Product Owner, quản lý dự án, chuyên viên phân tích nghiệp vụ (BA), kiến trúc sư giải pháp hoặc CTO.
• Doanh nghiệp cần chuẩn bị: người ra quyết định có thẩm quyền, số liệu hiện trạng và tiêu chí thế nào là “thành công”.

2.2. Xác định yêu cầu

Giai đoạn này chuyển nhu cầu kinh doanh thành yêu cầu cụ thể mà đội kỹ thuật có thể ước lượng và kiểm thử. Các câu hỏi cần trả lời gồm: phần mềm giải quyết vấn đề gì, ai sử dụng và trong bối cảnh nào, dữ liệu đầu vào và đầu ra ra sao, cần kết nối với hệ thống hoặc API nào, yêu cầu bảo mật và quyền riêng tư thế nào.

• Đầu ra: tài liệu đặc tả yêu cầu (SRS) hoặc product backlog có tiêu chí nghiệm thu, kịch bản kiểm thử chính, lựa chọn công nghệ (tech stack), phạm vi công việc (SOW).
• Doanh nghiệp cần chuẩn bị: người dùng thật để phỏng vấn, quy trình nghiệp vụ đang chạy và danh sách hệ thống cần tích hợp.

Yêu cầu không được làm rõ ở giai đoạn này thường dồn lại thành tồn đọng trong backlog: nhiều hạng mục thiếu mô tả và tiêu chí nghiệm thu, đội phát triển khó xác định việc nào cần làm trước. Savvycom từng đồng hành cùng một công ty fintech tại Úc giải quyết đúng tình huống này, bằng cách đưa chuyên gia phân tích nghiệp vụ vào rà soát backlog và tổ chức workshop thống nhất tiêu chí nghiệm thu với các bên: case fintech tại Úc tái cấu trúc backlog để bàn giao đều nhịp.

2.3. Thiết kế và tạo mẫu thử

Khi yêu cầu đã rõ, đội dự án thiết kế cách phần mềm vận hành và hiển thị: kiến trúc hệ thống, mô hình dữ liệu, luồng người dùng, wireframe và giao diện. Với ý tưởng còn nhiều giả định, đội có thể dựng mẫu thử (prototype) hoặc bản thử nghiệm khái niệm (PoC) để kiểm chứng trước khi lập trình; khác biệt giữa các khái niệm này được trình bày trong bài phân biệt PoC, prototype và MVP.

• Đầu ra: tài liệu kiến trúc, thiết kế UX/UI, mẫu thử đã được người dùng phản hồi.
• Người tham gia: kiến trúc sư hệ thống, chuyên gia UX/UI, BA.

2.4. Lập trình

Đây là giai đoạn tốn nhiều công sức và có rủi ro cao nhất, khi đội kỹ sư front-end, back-end và mobile xây dựng sản phẩm theo thiết kế và phạm vi đã thống nhất. Dù làm theo sprint của Agile, xây MVP hay theo mô hình thác nước, đội dự án cần bám sát phạm vi công việc, quản lý mã nguồn chặt chẽ và rà soát mã thường xuyên để hạn chế nợ kỹ thuật.

• Đầu ra: các bản build chạy được theo từng mốc hoặc từng sprint, kèm báo cáo tiến độ.
• Doanh nghiệp cần chuẩn bị: người đại diện duyệt kết quả định kỳ và quy trình tiếp nhận yêu cầu thay đổi, tránh để phạm vi phình ra mà không ai kiểm soát.

2.5. Kiểm thử

Kiểm thử bảo đảm phần mềm đúng yêu cầu, ổn định và an toàn trước khi đến tay người dùng. Giai đoạn này gồm kiểm thử chức năng, tích hợp, hiệu năng, bảo mật và kiểm thử chấp nhận người dùng (UAT). Phát hiện lỗi càng muộn thì chi phí sửa càng lớn, vì vậy nhiều đội đưa kiểm thử tự động vào ngay từ giai đoạn lập trình thay vì dồn đến cuối dự án.

• Đầu ra: báo cáo kiểm thử, danh sách lỗi đã xử lý, biên bản UAT.
• Doanh nghiệp cần chuẩn bị: dữ liệu thử gần với thực tế và nhóm người dùng tham gia UAT.

2.6. Triển khai

Phần mềm được đưa lên môi trường vận hành thật: cấu hình hạ tầng, chuyển đổi dữ liệu, thiết lập giám sát và kế hoạch quay lui nếu có sự cố. Đội DevOps và quản trị dữ liệu thực hiện phần kỹ thuật, còn doanh nghiệp chuẩn bị đào tạo người dùng, truyền thông nội bộ và chọn thời điểm go-live ít ảnh hưởng đến hoạt động kinh doanh nhất.

2.7. Bảo trì và cập nhật

Vòng đời phần mềm không kết thúc khi phát hành. Sau go-live, đội dự án theo dõi hiệu năng, xử lý lỗi phát sinh, cập nhật bảo mật và tiếp nhận yêu cầu mới từ người dùng. Các yêu cầu này được đưa trở lại product backlog, ưu tiên theo giá trị kinh doanh và trở thành đầu vào cho vòng phát triển tiếp theo.

3. 5 mô hình phát triển phần mềm phổ biến

Mô hình (hay phương pháp) phát triển phần mềm quyết định cách sắp xếp 7 giai đoạn ở trên: làm tuần tự một lần, lặp lại theo vòng ngắn hay tập trung vào kiểm soát rủi ro. Không có mô hình tốt nhất cho mọi dự án; lựa chọn phụ thuộc vào mức độ rõ ràng của yêu cầu, quy mô và mức độ chấp nhận thay đổi. Phân tích chi tiết hơn có trong bài các mô hình phát triển phần mềm doanh nghiệp cần biết.

3.1. Mô hình thác nước (Waterfall)

Mô hình thác nước là cách tiếp cận tuần tự: mỗi giai đoạn hoàn thành rồi mới chuyển sang giai đoạn tiếp theo, không chồng chéo. Mô hình dễ quản lý và có đầu ra rõ ràng ở cuối mỗi giai đoạn, nhưng rất khó thay đổi khi một giai đoạn đã khép lại. Thác nước phù hợp với dự án nhỏ, yêu cầu được xác định chính xác từ đầu và ít thay đổi.

3.2. Mô hình chữ V (V-Model)

Mô hình chữ V khắc phục điểm yếu lớn nhất của thác nước là dồn kiểm thử về cuối. Mỗi giai đoạn phát triển ở nhánh trái được ghép với một mức kiểm thử tương ứng ở nhánh phải: yêu cầu nghiệp vụ đi cùng kiểm thử chấp nhận, thiết kế hệ thống đi cùng kiểm thử hệ thống, thiết kế chi tiết đi cùng kiểm thử tích hợp và kiểm thử đơn vị. Mô hình phù hợp với dự án đòi hỏi độ chính xác và tuân thủ cao như tài chính, y tế, nơi yêu cầu ổn định và chi phí lỗi lớn.

3.3. Mô hình Agile

Agile, với khung làm việc phổ biến nhất là Scrum, chia dự án thành các vòng lặp ngắn (sprint) thường kéo dài 1 đến 4 tuần. Sau mỗi sprint, đội dự án bàn giao một phần sản phẩm dùng được, thu phản hồi và điều chỉnh ưu tiên cho sprint sau. Quy trình gồm: tạo product backlog, lập sprint backlog, thiết kế và phát triển trong sprint, phát hành, nhận phản hồi và lập kế hoạch sprint tiếp theo.

Agile giúp doanh nghiệp ra mắt sớm, kiểm chứng giả định với người dùng thật và giảm rủi ro so với một lần phát hành lớn. Đổi lại, mô hình đòi hỏi bên đặt hàng tham gia thường xuyên và chấp nhận phạm vi được điều chỉnh liên tục. Cách định giá dự án cũng cần phù hợp với mô hình này, như phân tích trong bài so sánh mô hình Fixed Price và Time & Material.

3.4. Mô hình xoắn ốc (Spiral)

Mô hình xoắn ốc kết hợp các vòng lặp với trình tự của thác nước và đặt phân tích rủi ro vào trung tâm. Mỗi vòng gồm lập kế hoạch, đánh giá rủi ro, phát triển và xác nhận, rồi đánh giá kết quả để lên kế hoạch cho vòng tiếp theo. Mô hình phù hợp với dự án lớn, phức tạp và nhiều rủi ro kỹ thuật, nhưng tốn kém với dự án nhỏ có phạm vi hẹp.

3.5. Mô hình lặp và tăng dần (Iterative)

Mô hình lặp chia sản phẩm thành các phần tăng dần; mỗi lần lặp tạo ra một phiên bản mới hoàn thiện hơn phiên bản trước cho đến khi đạt sản phẩm mục tiêu. Mô hình phù hợp khi phần lớn yêu cầu đã biết trước nhưng sẽ thay đổi theo thời gian, khi dự án kéo dài hoặc khi đội dự án làm việc với công nghệ hay lĩnh vực mới.

4. Khi nào doanh nghiệp nên tự phát triển phần mềm?

Doanh nghiệp nên tự phát triển, hoặc đặt làm riêng, khi phần mềm gắn với quy trình tạo khác biệt cạnh tranh, phải tích hợp sâu với hệ thống sẵn có hoặc khi phần mềm đóng gói buộc doanh nghiệp thay đổi cách vận hành quá nhiều. Ngược lại, với nghiệp vụ phổ biến như kế toán, chấm công, giải pháp có sẵn thường nhanh và tiết kiệm hơn.

Khi đã quyết định làm riêng, câu hỏi tiếp theo là xây đội nội bộ hay thuê ngoài. Đội nội bộ phù hợp khi phần mềm là sản phẩm cốt lõi cần phát triển lâu dài; thuê ngoài phù hợp khi doanh nghiệp cần ra mắt nhanh, thiếu chuyên môn cụ thể hoặc muốn kiểm soát chi phí theo giai đoạn. Hai bài thuê ngoài phát triển phần mềm và viết phần mềm theo yêu cầu phân tích chi tiết từng lựa chọn.

5. Savvycom áp dụng quy trình phát triển phần mềm như thế nào?

Tại Savvycom, chúng tôi áp dụng 7 giai đoạn trên một cách linh hoạt theo đặc thù từng dự án: dự án sản phẩm mới thường đi theo Agile với các sprint ngắn, còn dự án có yêu cầu tuân thủ cao kết hợp kiểm thử theo từng mức như mô hình chữ V. Giai đoạn phân tích và xác định yêu cầu luôn có sự tham gia của chuyên gia phân tích nghiệp vụ, vì đây là nơi quyết định phần lớn chi phí và tiến độ về sau.

Hàn Quốc · Nội dung số90%+mức hài lòng của khách hàng sau khi làm mới nền tảngYES24 Channel YES: làm mới nền tảng nội dung sốPhần đã làm: xây lại giao diện và kiến trúc trong 6 tháng, không gián đoạn vận hànhXem dự án →Hàn Quốc · Logistics50%thời gian rà soát mỗi hợp đồng giảm, độ chính xác trích xuất điều khoản 95%AI rà soát hợp đồng cho tập đoàn logisticsPhần đã làm: phân tích quy trình tuân thủ, phát triển mô hình, tích hợp hệ thống tài liệuXem dự án →

Các dự án khác theo từng lĩnh vực được tổng hợp tại trang dự án tiêu biểu của Savvycom.

6. Câu hỏi thường gặp về quy trình phát triển phần mềm

1. Quy trình phát triển phần mềm gồm mấy bước?
Quy trình phát triển phần mềm phổ biến gồm 7 bước: phân tích và lập kế hoạch, xác định yêu cầu, thiết kế và tạo mẫu thử, lập trình, kiểm thử, triển khai, bảo trì và cập nhật. Một số tài liệu gộp lại còn 5 hoặc 6 bước, nhưng nội dung công việc về cơ bản tương đương nhau.

2. Vòng đời phát triển phần mềm (SDLC) là gì?
Vòng đời phát triển phần mềm (SDLC) là khung mô tả toàn bộ các giai đoạn một phần mềm trải qua, từ khi hình thành ý tưởng đến khi vận hành, bảo trì và cập nhật. SDLC giúp các bên thống nhất việc cần làm, đầu ra và trách nhiệm ở từng giai đoạn, từ đó kiểm soát chi phí, tiến độ và chất lượng.

3. Nên chọn mô hình thác nước hay Agile?
Chọn thác nước khi yêu cầu đã rõ, ít thay đổi và dự án có quy mô nhỏ. Chọn Agile khi xây sản phẩm mới, yêu cầu còn nhiều giả định cần kiểm chứng với người dùng hoặc doanh nghiệp cần ra mắt sớm. Nhiều dự án kết hợp cả hai: lập kế hoạch tổng thể theo mốc, triển khai bên trong theo sprint.

4. Khi nào doanh nghiệp nên tự phát triển phần mềm?
Doanh nghiệp nên tự phát triển hoặc đặt làm riêng khi phần mềm gắn với quy trình tạo khác biệt cạnh tranh, cần tích hợp sâu với hệ thống sẵn có hoặc khi phần mềm đóng gói không đáp ứng được cách vận hành đặc thù. Với nghiệp vụ phổ biến, giải pháp có sẵn thường nhanh và tiết kiệm hơn.