Trả lời nhanh: quy trình phát triển phần mềm theo yêu cầu gồm những bước nào?
Một dự án phần mềm theo yêu cầu thường đi qua 9 giai đoạn: khảo sát, xác định yêu cầu và phạm vi, thiết kế kiến trúc, xây dựng theo vòng lặp, kiểm thử chất lượng (QA), kiểm thử chấp nhận của người dùng (UAT), triển khai, bàn giao và bảo trì. Mỗi giai đoạn nên kết thúc bằng một sản phẩm bàn giao cụ thể mà hai bên cùng xác nhận.
Điều quyết định thành bại thường không nằm ở công nghệ mà ở ba việc: phạm vi viết rõ, tiêu chí nghiệm thu đo được, và quyền với mã nguồn, tài liệu được ghi trong hợp đồng. Nếu bạn còn phân vân có nên tự xây hay không, hãy đọc trước bài tự xây hay mua phần mềm.
9 giai đoạn và sản phẩm bàn giao của từng giai đoạn
Bảng dưới là khung tham chiếu. Tên gọi và độ chi tiết thay đổi theo quy mô dự án; điều quan trọng là giai đoạn nào cũng có đầu ra rõ ràng và người duyệt.
| Giai đoạn | Mục tiêu | Sản phẩm bàn giao tiêu biểu | Khách hàng tham gia |
|---|---|---|---|
| 1. Khảo sát (discovery) | Hiểu bài toán kinh doanh, người dùng, hệ thống hiện có | Báo cáo khảo sát, sơ đồ quy trình hiện tại, danh sách rủi ro | Phỏng vấn, cung cấp tài liệu, dữ liệu mẫu |
| 2. Yêu cầu và phạm vi | Chốt cái gì nằm trong và ngoài phạm vi | Tài liệu đặc tả yêu cầu (SRS) hoặc danh sách user story có ưu tiên, tiêu chí nghiệm thu | Duyệt và ký xác nhận phạm vi |
| 3. Thiết kế kiến trúc | Chọn cấu trúc hệ thống, dữ liệu, tích hợp, bảo mật | Tài liệu kiến trúc, mô hình dữ liệu, thiết kế giao diện (wireframe/prototype) | Duyệt luồng màn hình, xác nhận tích hợp |
| 4. Xây dựng theo vòng lặp | Làm từng phần chạy được, nhận phản hồi sớm | Bản phần mềm tăng dần sau mỗi vòng, ghi chú phát hành | Dự buổi demo, phản hồi, sắp xếp ưu tiên |
| 5. Kiểm thử chất lượng (QA) | Phát hiện lỗi chức năng, hiệu năng, bảo mật | Kế hoạch và kết quả kiểm thử, danh sách lỗi và trạng thái | Cung cấp dữ liệu kiểm thử thực tế |
| 6. Kiểm thử chấp nhận (UAT) | Người dùng thật xác nhận phần mềm đáp ứng yêu cầu | Kịch bản UAT, biên bản nghiệm thu hoặc danh sách điểm cần sửa | Người dùng chính chạy kịch bản và ký |
| 7. Triển khai | Đưa lên môi trường vận hành an toàn | Kế hoạch triển khai và quay lui, chuyển đổi dữ liệu, hướng dẫn sử dụng | Chuẩn bị hạ tầng/tài khoản, đào tạo người dùng |
| 8. Bàn giao | Chuyển giao những gì đã thỏa thuận | Mã nguồn, tài liệu kỹ thuật, thông tin truy cập, biên bản bàn giao (theo thỏa thuận trong hợp đồng) | Kiểm tra đủ hạng mục, nhận quyền quản trị |
| 9. Bảo trì và hỗ trợ | Giữ hệ thống chạy ổn và cập nhật | Báo cáo sự cố, bản vá, cập nhật thư viện (theo thỏa thuận trong hợp đồng) | Báo lỗi theo kênh đã thống nhất, duyệt thay đổi |
Vì sao nên làm theo vòng lặp
Ở giai đoạn xây dựng, nhiều đội dùng các vòng ngắn để sớm có phần mềm chạy được. Scrum Guide 2020 mô tả Sprint là sự kiện có độ dài cố định từ một tháng trở xuống, mỗi Sprint tạo ra phần tăng (Increment) đạt Định nghĩa Hoàn thành (Scrum Guide). Với khách hàng, lợi ích là được xem và góp ý phần mềm thật định kỳ thay vì chờ đến cuối dự án.
Giai đoạn đầu: khảo sát, yêu cầu và kiến trúc
Ba giai đoạn đầu chiếm ít thời gian hơn xây dựng nhưng quyết định phần lớn rủi ro. Một yêu cầu hiểu sai ở đây sẽ được nhân lên ở mọi bước sau.
Khảo sát
Mục tiêu là hiểu vấn đề, chưa phải chọn công nghệ. Đội phát triển nên quan sát quy trình thực tế, xem dữ liệu mẫu và nói chuyện với người dùng cuối, không chỉ với lãnh đạo. Nếu quy trình liên quan đến AI hoặc tự động hóa, bạn có thể dùng phương pháp lập bản đồ quy trình AI để tách bước nào máy làm, bước nào người duyệt.
Yêu cầu và phạm vi
Mỗi yêu cầu nên có người đề xuất, mức ưu tiên và tiêu chí nghiệm thu. Ghi rõ cả phần ngoài phạm vi, vì đây là nơi tranh chấp hay xảy ra nhất. Yêu cầu phi chức năng (số người dùng đồng thời, thời gian phản hồi, sao lưu, phân quyền, lưu vết) cần được viết ra như yêu cầu chức năng.
Kiến trúc và bảo mật từ đầu
NIST nhận xét rằng ít mô hình vòng đời phát triển phần mềm đề cập chi tiết đến bảo mật, nên các thực hành phát triển an toàn cần được bổ sung vào từng mô hình; khung SSDF (NIST SP 800-218, bản 1.1; bản 1.2 đang ở dạng dự thảo từ 12/2025) là ngôn ngữ chung để bên mua trao đổi yêu cầu với nhà cung cấp (NIST). Bạn có thể dùng khung này làm danh mục câu hỏi khi duyệt thiết kế. Nếu sản phẩm cần mở rộng lâu dài, xem thêm hệ thống SaaS chịu được tăng trưởng.
Mô hình hợp đồng: trọn gói, theo thời gian và nguồn lực, đội ngũ riêng
Mô hình hợp đồng ảnh hưởng trực tiếp đến cách quản lý thay đổi. Không có mô hình nào hợp với mọi dự án; bảng dưới so sánh theo mức độ chắc chắn của yêu cầu.
| Mô hình | Cách tính | Phù hợp khi | Điểm cần chú ý |
|---|---|---|---|
| Trọn gói theo phạm vi (fixed scope) | Phạm vi, tiến độ, giá trị chốt trước | Yêu cầu rõ, ít thay đổi, quy mô vừa phải | Mọi thay đổi đi qua quy trình yêu cầu thay đổi (change request); dễ phát sinh tranh luận về cách hiểu phạm vi |
| Theo thời gian và nguồn lực (time & materials) | Tính theo công thực tế đã làm | Yêu cầu còn thay đổi, cần linh hoạt ưu tiên | Cần báo cáo công minh bạch và người phía khách hàng quyết định ưu tiên thường xuyên |
| Đội ngũ riêng (dedicated team) | Một đội cố định làm cho bạn trong thời gian dài | Sản phẩm phát triển liên tục, cần đội hiểu sâu nghiệp vụ | Khách hàng cần năng lực quản lý sản phẩm; cần thỏa thuận rõ về thay người, chuyển giao kiến thức |
Khách hàng cần chuẩn bị gì trước khi bắt đầu
Phần lớn chậm trễ đến từ việc chờ quyết định hoặc chờ dữ liệu, không phải từ lập trình. Chuẩn bị sẵn những việc sau sẽ giúp dự án chạy đều:
- Một người ra quyết định (product owner) có thời gian và thẩm quyền duyệt phạm vi, ưu tiên, nghiệm thu.
- Mục tiêu kinh doanh đo được: phần mềm giảm việc gì, nhanh hơn ở đâu, ai dùng.
- Tài liệu và dữ liệu mẫu đang dùng, đã che thông tin nhạy cảm nếu cần.
- Danh sách hệ thống cần tích hợp (kế toán, CRM, ERP, hóa đơn điện tử) và người phụ trách.
- Yêu cầu hạ tầng và bảo mật: đám mây hay máy chủ riêng, chính sách dữ liệu cá nhân, quyền truy cập môi trường vận hành.
- Người dùng chính sẵn sàng tham gia demo và UAT theo lịch.
Tiêu chí nghiệm thu: viết sao cho đo được
Tiêu chí nghiệm thu (acceptance criteria) là điều kiện cụ thể để một yêu cầu được coi là xong. Khác với Định nghĩa Hoàn thành (Definition of Done) áp dụng chung cho mọi hạng mục về chất lượng, tiêu chí nghiệm thu gắn với từng yêu cầu. Scrum.org mô tả Definition of Done là mô tả chính thức trạng thái của phần tăng khi đạt các tiêu chuẩn chất lượng của sản phẩm (Scrum.org).
- Mỗi tiêu chí kiểm tra được bằng có/không, không dùng từ cảm tính như “dễ dùng”, “nhanh”.
- Gắn với dữ liệu thử nghiệm mà hai bên cùng có.
- Phân loại lỗi (nghiêm trọng, chính, phụ) và thống nhất mức nào thì chưa nghiệm thu.
- Ghi rõ ai ký nghiệm thu và trong thời hạn bao lâu sau khi nhận bản UAT.
Ví dụ minh họa
Ví dụ minh họa: thay vì viết “hệ thống xuất báo cáo nhanh”, hãy viết “Khi kế toán chọn kỳ tháng và bấm Xuất, hệ thống tạo file Excel đúng mẫu đính kèm, gồm tất cả đơn hàng có trạng thái Đã giao trong kỳ; với dữ liệu thử nghiệm đã thống nhất, thao tác hoàn tất trong thời gian hai bên đã ghi trong đặc tả”. Tiêu chí tốt có ngữ cảnh, hành động, kết quả mong đợi và dữ liệu để kiểm tra.
Bàn giao mã nguồn, tài liệu và bảo hành
Phần này nên được thỏa thuận ngay khi ký hợp đồng, không đợi đến cuối dự án. Các hạng mục thường được thỏa thuận gồm: mã nguồn và lịch sử phiên bản, tài liệu kiến trúc và API, hướng dẫn cài đặt và vận hành, tài khoản quản trị hạ tầng, danh sách thư viện bên thứ ba và giấy phép đi kèm. Phạm vi cụ thể, quyền sở hữu mã nguồn và thời điểm chuyển giao được xác định theo thỏa thuận trong hợp đồng.
Quyền tác giả đối với phần mềm theo pháp luật Việt Nam
Theo khoản 1 Điều 22 Luật Sở hữu trí tuệ (sửa đổi bởi Luật số 131/2025/QH15, hiệu lực 01/4/2026), chương trình máy tính được bảo hộ như tác phẩm văn học, dù ở dạng mã nguồn hay mã máy, và tác giả với chủ sở hữu quyền tác giả có thể thỏa thuận bằng văn bản về việc sửa chữa, nâng cấp. Theo khoản 2 Điều 39, bên giao kết hợp đồng với tác giả là chủ sở hữu quyền tài sản và quyền công bố tác phẩm, trừ trường hợp có thỏa thuận khác; Điều 41 cho phép chuyển giao các quyền này theo hợp đồng. Ở giai đoạn bàn giao, hãy đối chiếu danh mục bàn giao với điều khoản sở hữu trí tuệ đã ký; phân tích chi tiết về quyền sở hữu mã nguồn có trong bài tự xây hay mua phần mềm.
Bảo hành và hỗ trợ
Thời hạn bảo hành, phạm vi lỗi được sửa miễn phí, thời gian phản hồi và cam kết mức dịch vụ (SLA) đều là điều khoản theo thỏa thuận trong hợp đồng. Hãy phân biệt rõ: sửa lỗi so với đặc tả đã nghiệm thu, thay đổi hoặc tính năng mới, và vận hành hạ tầng. Ba loại này thường có cách xử lý khác nhau.
Dấu hiệu cần cân nhắc khi chọn đối tác phát triển
Các dấu hiệu dưới đây không có nghĩa đối tác kém, nhưng là lý do để hỏi thêm trước khi ký:
- Đưa ra cam kết tiến độ và phạm vi chắc chắn trước khi khảo sát.
- Không có quy trình rõ ràng cho yêu cầu thay đổi.
- Không nêu được cách kiểm thử, ai kiểm thử, kết quả lưu ở đâu.
- Điều khoản về mã nguồn, tài liệu, quyền sở hữu trí tuệ mơ hồ hoặc không có.
- Chỉ có một đầu mối kỹ thuật duy nhất, không có kế hoạch chuyển giao kiến thức.
Checklist trước khi ký hợp đồng
Khi danh sách này đầy đủ, bạn có thể so sánh các đề xuất trên cùng một mặt bằng. Nếu cần trao đổi về dự án cụ thể, bạn có thể liên hệ EYC.
- Phạm vi, phần ngoài phạm vi và tiêu chí nghiệm thu đã được viết ra.
- Mô hình hợp đồng phù hợp với mức chắc chắn của yêu cầu.
- Quy trình yêu cầu thay đổi, báo cáo tiến độ và lịch demo đã thống nhất.
- Danh mục bàn giao (mã nguồn, tài liệu, tài khoản) và quyền sở hữu được ghi trong hợp đồng.
- Điều khoản bảo hành, hỗ trợ, SLA được nêu rõ theo thỏa thuận.
- Yêu cầu bảo mật và xử lý dữ liệu cá nhân có trong đặc tả.
Câu hỏi thường gặp
Phát triển phần mềm theo yêu cầu mất bao lâu?
Thời gian phụ thuộc vào phạm vi, số hệ thống cần tích hợp và tốc độ ra quyết định của hai bên. Cách đáng tin nhất là làm giai đoạn khảo sát trước, sau đó mới ước lượng dựa trên danh sách yêu cầu đã chốt.
Nên chọn hợp đồng trọn gói hay theo thời gian và nguồn lực?
Trọn gói hợp với yêu cầu rõ và ít thay đổi. Theo thời gian và nguồn lực hợp khi yêu cầu còn đang khám phá. Nhiều dự án làm khảo sát trọn gói trước rồi chọn mô hình cho giai đoạn xây dựng.
Ai sở hữu mã nguồn phần mềm đặt làm?
Theo khoản 2 Điều 39 Luật Sở hữu trí tuệ, bên giao kết hợp đồng với tác giả là chủ sở hữu quyền tài sản và quyền công bố tác phẩm, trừ khi có thỏa thuận khác. Trong thực tế, quyền sở hữu và phạm vi bàn giao mã nguồn được xác định theo hợp đồng, nên cần ghi rõ và nhờ luật sư rà soát.
UAT khác gì với kiểm thử của đội phát triển?
Kiểm thử (QA) do đội phát triển thực hiện để tìm lỗi so với đặc tả. UAT do người dùng phía khách hàng thực hiện trên kịch bản nghiệp vụ thật để xác nhận phần mềm dùng được cho công việc của họ.
Sau khi bàn giao, ai bảo trì phần mềm?
Có thể là đội phát triển theo hợp đồng bảo trì, đội nội bộ của bạn, hoặc kết hợp. Dù chọn cách nào, cần có tài liệu, quyền truy cập và kế hoạch chuyển giao kiến thức theo thỏa thuận trong hợp đồng.