Quy trình phát triển phần mềm gồm những bước nào? Bản đồ bàn giao

Quy trình phát triển phần mềm gồm sáu bước: khám phá, đặc tả, thiết kế, xây dựng, kiểm thử và bàn giao. Mỗi bước có việc phải làm, đầu ra cụ thể và điểm kiểm tra trước khi chuyển bước — thiếu đầu ra, bước sau sẽ làm lại phần trước.

Tóm tắt nhanh

• Sáu bước nối tiếp nhau bằng đầu ra, không bằng lịch. Bước sau chỉ bắt đầu khi đầu ra của bước trước được chấp nhận.
• Ba bước đầu chiếm ít thời gian nhưng quyết định phần lớn chi phí về sau, vì chúng chốt phạm vi và tiêu chí nghiệm thu.
• Khách hàng chỉ nghiệm thu ở ba mốc nhìn thấy được: chốt đặc tả, nghiệm thu từng đợt bàn giao, và bàn giao vận hành. Các bước còn lại là công việc nội bộ của đội thực hiện.
• Mỗi bước có một điểm kiểm tra dạng câu hỏi. Nếu không trả lời được, đừng chuyển bước.

Bản đồ sáu bước trong một trang

Bảng này là bản đồ. Phần còn lại của bài đi vào từng bước: việc phải làm, đầu ra, và điểm kiểm tra. Lý do sáu bước này quyết định chi phí được trình bày riêng trong quy trình phát triển phần mềm là gì.

Bước 1: Khám phá và chốt vấn đề

Việc phải làm

Quan sát quy trình đang chạy, không chỉ nghe mô tả. Xem người dùng thật thao tác, đếm số bước họ phải làm, ghi lại chỗ họ phải chuyển sang công cụ khác. Thu thập mẫu dữ liệu thật, kèm số lượng và nguồn gốc.

Sau khi quan sát, viết lại vấn đề thành một câu có dữ kiện. "Bộ phận kho mất nhiều thời gian kiểm kê" là cảm nhận. "Mỗi kỳ kiểm kê, hai nhân viên phải đối chiếu thủ công ba tệp dữ liệu từ ba hệ thống, và chênh lệch được phát hiện sau khi đã chốt số" là vấn đề.

Đầu ra

• Báo cáo khám phá mô tả hiện trạng, có số liệu về khối lượng và tần suất;
• Phạm vi sơ bộ, gồm cả danh sách hạng mục không nằm trong phạm vi;
• Danh sách giả định, mỗi giả định có cách kiểm chứng và người xác nhận;
• Danh sách hệ thống liên quan và người phụ trách từng hệ thống.

Điểm kiểm tra

Trả lời được ba câu: vấn đề được mô tả bằng dữ kiện nào; ai xác nhận vấn đề này là đúng; nếu không làm gì thì điều gì xảy ra. Câu thứ ba quan trọng vì nó phân biệt dự án cần thiết với dự án chỉ nên làm.

Bước 2: Đặc tả yêu cầu và tiêu chí nghiệm thu

Việc phải làm

Chuyển phạm vi thành danh sách yêu cầu có mã. Mỗi yêu cầu gồm: mã, mô tả, mức ưu tiên (bắt buộc, nên có, có thể có), và tiêu chí kiểm chứng. Mỗi yêu cầu phi chức năng phải có ngưỡng đo, không chỉ tính từ.

Viết kịch bản kiểm thử ngay ở bước này, trước khi có bất kỳ dòng mã nào. Lý do: kịch bản kiểm thử viết sau khi có sản phẩm thường được viết để khớp sản phẩm, không để khớp nhu cầu.

Đầu ra

• Tài liệu đặc tả có phiên bản, có lịch sử thay đổi;
• Bảng yêu cầu chức năng có mã và mức ưu tiên;
• Bảng yêu cầu phi chức năng có ngưỡng đo;
• Bảng kịch bản kiểm thử sơ bộ, tham chiếu mã yêu cầu;
• Biên bản chốt đặc tả có chữ ký của người có thẩm quyền phía sử dụng.

Điểm kiểm tra

Chọn ngẫu nhiên ba yêu cầu và hỏi: một người không tham gia dự án có thể kiểm tra đạt hay không đạt chỉ bằng cách đọc yêu cầu này không. Nếu không, yêu cầu cần viết lại. Cấu trúc tám phần của tài liệu đặc tả được trình bày trong tài liệu đặc tả yêu cầu phần mềm.

Bước 3: Thiết kế kỹ thuật

Việc phải làm

Chuyển yêu cầu thành cấu trúc: mô hình dữ liệu, phân rã thành phần, giao diện tích hợp, phương án xác thực và phân quyền, chiến lược triển khai. Với dự án nhỏ, phần này có thể gói trong vài trang; với dự án lớn, đây là tài liệu riêng.

Ba câu hỏi phải trả lời ở bước này: dữ liệu được lưu theo cấu trúc nào; hệ thống mới giao tiếp với hệ thống cũ ra sao; và khi cần thay đổi một quy tắc nghiệp vụ, phải sửa ở bao nhiêu chỗ.

Đầu ra

• Mô hình dữ liệu có mô tả trường, quan hệ, quy tắc ràng buộc;
• Sơ đồ thành phần và luồng dữ liệu giữa các thành phần;
• Danh mục tích hợp: hệ thống nào, giao thức nào, chiều dữ liệu, tần suất;
• Bản ghi quyết định kiến trúc cho các lựa chọn lớn;
• Kế hoạch môi trường: môi trường kiểm thử, môi trường vận hành, sao lưu.

Điểm kiểm tra

Hỏi đội vận hành: từ tài liệu này, họ có triển khai được hệ thống lên môi trường mới mà không cần hỏi người viết mã không. Nếu không, tài liệu triển khai còn thiếu.

Bước 4: Xây dựng theo mốc

Việc phải làm

Chia việc thành các mốc có đầu ra chạy được. Mỗi mốc nên gồm một nhóm chức năng mà người dùng có thể thực hiện trọn vẹn một công việc — ví dụ tạo đơn, duyệt đơn, in phiếu — thay vì chia theo tầng kỹ thuật như "xong cơ sở dữ liệu", "xong giao diện".

Theo dõi tiến độ bằng bảng hạng mục có trạng thái, không bằng phần trăm. Mỗi hạng mục mang mã yêu cầu, để khi nghiệm thu có thể đối chiếu ngược về đặc tả.

Đầu ra

• Bản chạy được ở từng mốc, có môi trường để khách hàng truy cập;
• Bảng theo dõi hạng mục có trạng thái và mã yêu cầu;
• Nhật ký thay đổi: yêu cầu nào phát sinh, ai yêu cầu, ảnh hưởng đến mốc nào;
• Tài liệu kỹ thuật cập nhật theo từng mốc, không để cuối dự án.

Điểm kiểm tra

Mỗi mốc phải trả lời được: khách hàng làm được việc gì mới mà trước đó chưa làm được. Nếu câu trả lời là "đã xong phần nền", mốc đó chưa phải mốc bàn giao.

Bước 5: Kiểm thử và nghiệm thu

Việc phải làm

Ba lớp kiểm thử chạy theo thứ tự: kiểm thử chức năng theo kịch bản đã viết ở bước 2; kiểm thử dữ liệu và tích hợp với dữ liệu thật; kiểm thử nghiệm thu do khách hàng thực hiện trong thời hạn đã thống nhất.

Lỗi phát hiện được ghi vào danh mục lỗi có mã, mức nghiêm trọng, ngày phát hiện và ngày đóng. Biên bản nghiệm thu phải tham chiếu mã kịch bản, không chỉ ghi "đã kiểm thử đạt".

Đầu ra

• Bảng kịch bản kiểm thử đã chạy, có kết quả thực tế;
• Danh mục lỗi kèm trạng thái đóng;
• Biên bản nghiệm thu theo từng mốc, có chữ ký hai bên;
• Danh sách hạng mục ghi nhận ngoài phạm vi, nếu có, để xử lý ở bước sau.

Điểm kiểm tra

Trước khi ký nghiệm thu, trả lời: còn lỗi mức nghiêm trọng nào mở không; những lỗi còn lại đã được ghi nhận bằng văn bản chưa; các hạng mục ngoài phạm vi đã được tách khỏi biên bản chưa. Câu cuối quan trọng, vì biên bản ghi "đạt" cho một phạm vi có hạng mục ngoài phạm vi sẽ tạo tranh chấp về sau.

Bước 6: Bàn giao, chuyển vận hành, đo lường

Việc phải làm

Bàn giao theo danh mục, mỗi hạng mục có artefact. Chuyển giao vận hành gồm: chuyển quyền truy cập, đổi mật khẩu tài khoản quản trị, xác nhận quy trình sao lưu, và chạy thử một sự cố giả định để đội vận hành biết xử lý.

Sau bàn giao, đo lường trong 30 ngày đầu theo ba chỉ số: mức độ sử dụng thực tế, chất lượng dữ liệu phát sinh, và sự cố theo mức nghiêm trọng. Báo cáo đo lường là đầu vào cho hợp đồng vận hành.

Đầu ra

• Biên bản bàn giao mã nguồn, ghi rõ kho, nhánh, phiên bản, danh mục thành phần bên thứ ba;
• Bộ tài liệu: kiến trúc, triển khai, cấu hình, hướng dẫn sử dụng theo vai trò;
• Biên bản chuyển dữ liệu, có đối chiếu số bản ghi trước và sau;
• Danh sách tài khoản quản trị đã chuyển giao và đã đổi mật khẩu;
• Báo cáo đo lường 30 ngày sau bàn giao.

Điểm kiểm tra

Hỏi đội vận hành: nếu người viết mã chính không còn làm việc ở đây từ ngày mai, hệ thống có tiếp tục chạy và sửa được không. Đây là câu hỏi khắc nghiệt nhưng cần thiết, vì nó kiểm tra đúng thứ mà bàn giao phải đảm bảo.

Ba mốc khách hàng thực sự nhìn thấy

Sáu bước ở trên là cách đội thực hiện tổ chức công việc. Khách hàng chỉ nghiệm thu ở ba mốc:

Việc phân biệt hai lớp này giúp hợp đồng gọn hơn: hợp đồng mô tả ba mốc khách hàng, còn quy trình nội bộ sáu bước là cách đội thực hiện đạt ba mốc đó. Cách ánh xạ này cũng tránh một lỗi phổ biến là đưa các bước kỹ thuật vào điều kiện thanh toán, khiến khách hàng phải trả tiền cho những thứ họ không kiểm chứng được.

Ai phê duyệt cái gì

Dòng cuối là dòng hay bị bỏ. Mọi hệ thống đều còn rủi ro đã biết khi bàn giao: một tích hợp chưa kiểm thử với dữ liệu lớn, một quy trình còn làm thủ công. Rủi ro không được ghi nhận và chấp nhận bằng văn bản sẽ trở thành khiếm khuyết bị quy trách nhiệm sau này.

Sai sót theo từng bước

Mỗi dấu hiệu sớm ở cột cuối đều quan sát được từ bên ngoài, không cần đọc mã nguồn. Đó là lý do chúng hữu ích cho người phê duyệt không chuyên kỹ thuật.

Chọn cách tổ chức các bước

Sáu bước trên có thể chạy theo hai cách. Cách thứ nhất là chia thành các đợt ngắn lặp lại, mỗi đợt đi qua cả sáu bước ở quy mô nhỏ. Cách thứ hai là chạy tuần tự từng bước một lần cho toàn bộ phạm vi.

Cách thứ nhất phù hợp khi yêu cầu chưa chắc và ưu tiên có thể thay đổi. Cách thứ hai phù hợp khi phạm vi đã cố định và cần chốt ngân sách trước. Chi tiết hai cách được trình bày trong quy trình phát triển phần mềm Agile Scrum và quy trình phát triển phần mềm Waterfall.

Điều không thay đổi giữa hai cách là danh sách đầu ra của từng bước. Đầu ra là thứ biến quy trình thành thứ kiểm chứng được, thay vì một chuỗi cuộc họp.

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

Quy trình phát triển phần mềm có thể bỏ bước thiết kế không?

Với dự án rất nhỏ, phần thiết kế có thể gói trong tài liệu đặc tả, nhưng không nên bỏ hoàn toàn. Mô hình dữ liệu và ranh giới tích hợp vẫn cần được quyết định có ghi nhận, vì đây là hai yếu tố tốn kém nhất nếu phải sửa sau khi đã có dữ liệu thật.

Bước nào mất nhiều thời gian nhất?

Xây dựng thường chiếm nhiều thời gian nhất, nhưng không phải lúc nào cũng vậy. Với dự án có nhiều bên liên quan, đặc tả có thể kéo dài hơn dự kiến vì phải thống nhất giữa các phòng ban. Cách nhìn hữu ích là theo dõi thời gian ở trạng thái "chờ phê duyệt", vì đó là phần dễ mất kiểm soát nhất.

Khách hàng cần tham gia ở những bước nào?

Ít nhất ở bốn điểm: khám phá để xác nhận vấn đề, đặc tả để chốt phạm vi và tiêu chí, nghiệm thu từng đợt để xác nhận đầu ra, và bàn giao vận hành để nhận hệ thống. Nếu khách hàng chỉ xuất hiện ở bước cuối, phần lớn rủi ro đã tích tụ và không còn cách xử lý rẻ.

Làm sao xử lý khi khách hàng yêu cầu thay đổi giữa bước xây dựng?

Ghi nhận bằng phiếu yêu cầu thay đổi, xác định ảnh hưởng đến phạm vi, tiến độ và giá, rồi để hai bên ký xác nhận trước khi thực hiện. Thay đổi được thực hiện mà không có phiếu là thay đổi sẽ không được thanh toán, và cũng là thay đổi không ai đối chiếu được khi nghiệm thu.

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

Cập nhật tháng 10/2026. Nội dung phản ánh quy trình bốn chặng WinSell áp dụng — Khám phá, Đặc tả, Xây dựng, Bàn giao và đo lường — với sáu bước kỹ thuật bên trong. Các nội dung về nghiệm thu, sở hữu sản phẩm và nghĩa vụ thuế được đối chiếu theo Bộ luật Dân sự 91/2015/QH13, Luật Sở hữu trí tuệ hiện hành và thuế GTGT của phần mềm là bao nhiêu.

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 sáu bước có đầu ra rõ ràng và ba mốc nghiệm thu cho khách hàng — xem dịch vụ của WinSell. Báo giá sau khi chốt phạm vi.