Quy trình phát triển phần mềm là gì? Vì sao 6 giai đoạn quyết định chi phí

Quy trình phát triển phần mềm là chuỗi giai đoạn biến một yêu cầu kinh doanh thành hệ thống đang chạy và được đo lường. Sáu giai đoạn kỹ thuật — khám phá, đặc tả, thiết kế, xây dựng, kiểm thử, bàn giao — nằm trong bốn chặng bàn giao, và mỗi giai đoạn tạo ra một tài liệu dùng được.

Tóm tắt nhanh

• Sáu giai đoạn kỹ thuật không phải sáu bước thủ tục; mỗi giai đoạn tạo ra một đầu ra mà giai đoạn sau dùng làm đầu vào.
• Bốn chặng bàn giao của WinSell — Khám phá, Đặc tả, Xây dựng, Bàn giao và đo lường — bao trùm sáu giai đoạn này, không thay thế chúng.
• Sai sót ở giai đoạn sớm rẻ hơn sai sót ở giai đoạn muộn, vì chi phí sửa không nằm ở việc sửa mà ở việc làm lại phần đã dựa trên giả định sai.
• Không có phương pháp nào đúng cho mọi dự án. Việc chọn nhịp triển khai phụ thuộc mức độ chắc chắn của yêu cầu và mức độ chấp nhận rủi ro của tổ chức.

Sáu giai đoạn nằm ở đâu trong bốn chặng bàn giao

Nhiều tài liệu trình bày quy trình phát triển phần mềm bằng năm, sáu hoặc bảy giai đoạn khác nhau. Sự khác biệt chủ yếu nằm ở cách gộp: có nơi gộp thiết kế vào xây dựng, có nơi tách kiểm thử ra khỏi xây dựng, có nơi thêm giai đoạn bảo trì.

Cách đọc hữu ích là phân biệt hai lớp. Lớp thứ nhất là các chặng bàn giao — những mốc mà khách hàng nhìn thấy và nghiệm thu. Lớp thứ hai là các giai đoạn kỹ thuật — những bước mà đội thực hiện đi qua bên trong mỗi chặng.

Cách ánh xạ này quan trọng vì hai lý do. Thứ nhất, nó giữ cho hợp đồng mô tả đúng thứ khách hàng nghiệm thu — bốn chặng — trong khi đội kỹ thuật vẫn có đủ cấu trúc bên trong. Thứ hai, nó ngăn một lỗi phổ biến: biến giai đoạn kỹ thuật thành mốc thanh toán. Khách hàng không nên trả tiền cho "đã thiết kế xong"; họ trả tiền cho một đầu ra kiểm chứng được.

Giai đoạn 1: Khám phá

Khám phá trả lời ba câu hỏi: vấn đề thật là gì, ai đang chịu ảnh hưởng, và phần mềm có phải cách giải quyết phù hợp.

Đây là giai đoạn hay bị rút ngắn nhất, và cũng là giai đoạn rẻ nhất để phát hiện rằng dự án không nên làm theo cách đang hình dung. Một buổi khám phá kỹ có thể kết luận rằng vấn đề nằm ở quy trình chứ không ở công cụ — trong trường hợp đó, viết phần mềm chỉ làm quy trình sai chạy nhanh hơn.

Đầu vào, đầu ra, câu hỏi phải trả lời

Đầu vào: người dùng thực tế, dữ liệu hiện có, quy trình đang chạy, các hệ thống liên quan.

Câu hỏi phải trả lời: quy trình hiện tại gồm những bước nào; bước nào tốn thời gian nhất; dữ liệu đang nằm ở đâu và ai sở hữu; nếu hệ thống mới ra đời thì bước nào biến mất.

Đầu ra: báo cáo khám phá mô tả hiện trạng, danh sách vấn đề có ưu tiên, phạm vi sơ bộ, và các giả định cần kiểm chứng.

Artefact: phiếu khám phá một trang

Một phiếu khám phá dùng được có sáu dòng:

1. Vấn đề: một câu, mô tả tình trạng hiện tại bằng dữ kiện, không bằng tính từ.
2. Người chịu ảnh hưởng: nhóm người dùng và số người trong nhóm.
3. Quy trình hiện tại: các bước, kèm bước nào đang gây chậm hoặc gây lỗi.
4. Dữ liệu liên quan: nguồn, khối lượng, ai chịu trách nhiệm.
5. Phạm vi đề xuất: những gì nằm trong và những gì nằm ngoài.
6. Giả định cần kiểm chứng: mỗi giả định ghi rõ cách kiểm chứng và người xác nhận.

Dòng thứ sáu là dòng quyết định chất lượng các giai đoạn sau. Giả định không được ghi ra sẽ trở thành tranh chấp ở giai đoạn nghiệm thu, khi việc sửa đã tốn kém.

Giai đoạn 2: Đặc tả

Đặc tả chuyển phạm vi thành yêu cầu kiểm chứng được. Đây là giai đoạn có tỷ lệ ảnh hưởng lớn nhất đến chi phí cuối cùng, vì mọi giai đoạn sau đều dựa trên nó.

Từ yêu cầu mơ hồ sang yêu cầu kiểm thử được

Bảng dưới đây là ví dụ thật về cách viết lại. Cột trái là câu thường gặp trong yêu cầu; cột phải là câu cùng nội dung nhưng kiểm chứng được.

Nguyên tắc viết lại: mỗi yêu cầu phải trả lời được ba câu — ai làm, làm gì, kết quả quan sát được là gì. Nếu thiếu một trong ba, yêu cầu chưa sẵn sàng để xây dựng.

Artefact: khung đặc tả

Một tài liệu đặc tả dùng được thường có tám phần: bối cảnh và mục tiêu, phạm vi, đối tượng sử dụng và vai trò, luồng nghiệp vụ chính, yêu cầu chức năng có mã, yêu cầu phi chức năng có ngưỡng đo, quy tắc dữ liệu, và tiêu chí nghiệm thu. Cấu trúc chi tiết của tám phần này được trình bày trong tài liệu đặc tả yêu cầu phần mềm.

Điểm cần nhấn mạnh: yêu cầu phi chức năng là phần hay bị bỏ trống nhất, và cũng là phần gây tranh chấp nhiều nhất khi nghiệm thu. "Hệ thống phải ổn định" không kiểm chứng được; "hệ thống chịu được 200 người dùng đồng thời, thời gian phản hồi trung bình dưới 1 giây" thì kiểm chứng được.

Giai đoạn 3: Thiết kế

Thiết kế biến yêu cầu thành cấu trúc kỹ thuật: dữ liệu lưu thế nào, thành phần nào giao tiếp với thành phần nào, xác thực ra sao, triển khai ở đâu.

Với dự án nhỏ, thiết kế có thể chỉ là vài trang. Với dự án lớn, thiết kế là tài liệu riêng. Nhưng trong mọi trường hợp, có ba quyết định ảnh hưởng trực tiếp đến chi phí về sau.

Ba quyết định thiết kế ảnh hưởng chi phí

Một là mô hình dữ liệu. Mô hình sai khiến mọi báo cáo phải tính lại bằng thủ tục phức tạp, và sửa mô hình sau khi có dữ liệu thật là việc tốn kém nhất trong toàn bộ dự án. Câu hỏi kiểm tra: mô hình này trả lời được những báo cáo nào mà tổ chức sẽ cần trong hai năm tới.

Hai là ranh giới tích hợp. Hệ thống mới giao tiếp với hệ thống cũ qua API, qua cơ sở dữ liệu dùng chung, hay qua tệp trao đổi. Mỗi lựa chọn có chi phí vận hành khác nhau, và lựa chọn "dùng chung cơ sở dữ liệu" thường rẻ lúc đầu nhưng đắt khi một trong hai hệ thống thay đổi.

Ba là chiến lược triển khai. Chạy trên hạ tầng của tổ chức hay trên đám mây; một môi trường hay nhiều môi trường; sao lưu thế nào. Những quyết định này ảnh hưởng đến chi phí hằng tháng, không chỉ chi phí ban đầu.

Artefact: bản ghi quyết định kiến trúc

Một bản ghi quyết định kiến trúc ngắn gọn gồm bốn phần: bối cảnh, quyết định, các phương án đã cân nhắc, và hệ quả. Mỗi quyết định một trang, đánh số thứ tự.

Giá trị của artefact này không nằm ở hiện tại mà ở hai năm sau, khi một người mới hỏi "vì sao lại làm như vậy". Không có bản ghi, câu trả lời là "không ai nhớ", và mọi thay đổi trở thành rủi ro không đo được.

Giai đoạn 4: Xây dựng

Xây dựng là giai đoạn dài nhất và cũng là giai đoạn dễ mất kiểm soát nhất, vì tiến độ không đo được bằng cảm giác.

Đo tiến độ bằng hạng mục, không bằng phần trăm

Báo cáo "đã xong 70%" là báo cáo không kiểm chứng được. Cách thay thế là theo dõi theo danh sách hạng mục, mỗi hạng mục có trạng thái rõ ràng: chưa bắt đầu, đang làm, chờ kiểm thử, đã kiểm thử đạt, đã nghiệm thu.

Bảng theo dõi hạng mục dùng được có sáu cột: mã hạng mục, mô tả, mức ưu tiên, trạng thái, người phụ trách, mốc bàn giao dự kiến. Mã hạng mục phải khớp với mã yêu cầu trong tài liệu đặc tả — nếu không khớp, không ai đối chiếu được phạm vi với công việc thực tế.

Nhịp bàn giao

Với dự án kéo dài, nên có nhịp bàn giao đều — mỗi hai tuần hoặc mỗi tháng một lần — để khách hàng nhìn thấy sản phẩm chạy được thay vì đọc báo cáo. Nhịp này có hai tác dụng: phát hiện hiểu nhầm sớm, và tạo chứng từ nghiệm thu từng phần.

Với dự án ngắn hoặc có phạm vi rất chắc, nhịp bàn giao có thể thưa hơn. Việc chọn nhịp nào phụ thuộc mức độ chắc chắn của yêu cầu, và được trình bày trong quy trình phát triển phần mềm Agile Scrum cùng quy trình phát triển phần mềm Waterfall.

Giai đoạn 5: Kiểm thử

Kiểm thử không phải bước cuối trước khi bàn giao. Đây là hoạt động chạy song song với xây dựng, và có ba lớp tối thiểu.

Ba lớp kiểm thử tối thiểu

Lớp 1 — kiểm thử chức năng. Mỗi yêu cầu có mã, mỗi mã có ít nhất một kịch bản kiểm thử với dữ liệu đầu vào, bước thực hiện và kết quả mong đợi. Kịch bản phải viết trước khi lập trình xong, không phải sau.

Lớp 2 — kiểm thử dữ liệu và tích hợp. Hệ thống chạy đúng với dữ liệu mẫu chưa chắc chạy đúng với dữ liệu thật. Lớp này kiểm tra dữ liệu biên — trường trống, ký tự đặc biệt, số âm, bản ghi trùng — và kiểm tra luồng dữ liệu giữa các hệ thống.

Lớp 3 — kiểm thử nghiệm thu do khách hàng thực hiện. Đây là lớp duy nhất có giá trị pháp lý, vì nó tạo ra biên bản. Khách hàng kiểm thử theo kịch bản đã thống nhất, trong thời hạn đã thống nhất, và kết quả được ghi thành biên bản.

Artefact: bảng kịch bản kiểm thử

Bảng kịch bản kiểm thử có sáu cột: mã kịch bản, mã yêu cầu, điều kiện đầu vào, bước thực hiện, kết quả mong đợi, kết quả thực tế. Cột cuối được điền trong quá trình chạy, kèm người chạy và ngày chạy.

Biên bản nghiệm thu nên tham chiếu đến mã kịch bản, không chỉ ghi "đã kiểm thử đạt". Tham chiếu mã là cách duy nhất để chứng minh phạm vi đã được kiểm tra đủ.

Giai đoạn 6: Bàn giao và đo lường

Bàn giao là giai đoạn bị xem nhẹ nhất và cũng là giai đoạn tạo ra nhiều tranh chấp nhất, vì nó là lúc chuyển trách nhiệm.

Checklist bàn giao và artefact chứng minh

Mỗi dòng trong bảng này là một câu trả lời cho câu hỏi "dựa vào đâu để nói rằng đã bàn giao". Nếu một dòng không có artefact, hạng mục đó chưa bàn giao, kể cả khi hai bên đã trao đổi bằng lời.

Đo lường sau bàn giao

Chặng thứ tư không kết thúc ở biên bản bàn giao. Nó kết thúc khi tổ chức trả lời được ba câu hỏi: hệ thống có được dùng thật không, dùng ở mức nào, và vấn đề gì xuất hiện sau khi dùng thật.

Ba chỉ số tối thiểu nên đo trong 30 ngày đầu sau bàn giao:

• Mức độ sử dụng: số người dùng thực tế so với số người dự kiến, tần suất sử dụng theo tuần.
• Chất lượng dữ liệu: tỷ lệ bản ghi thiếu trường bắt buộc, tỷ lệ bản ghi phải sửa lại.
• Sự cố: số sự cố theo mức nghiêm trọng, thời gian phản hồi và thời gian khắc phục thực tế so với cam kết.

Ba chỉ số này cũng là đầu vào để đàm phán hợp đồng vận hành sau bàn giao. Không có số liệu, cuộc đàm phán dựa trên cảm nhận của bên mạnh hơn.

Vì sao giai đoạn quyết định chi phí

Chi phí của một dự án phần mềm không tỷ lệ với số dòng mã. Nó tỷ lệ với số lần phải làm lại. Và số lần phải làm lại phụ thuộc vào việc sai sót được phát hiện ở giai đoạn nào.

Chi phí của một yêu cầu sai ở từng giai đoạn

Bảng này không có con số nhân, vì con số nhân phụ thuộc quy mô, kiến trúc và mức độ lan toả của thay đổi. Nhưng thứ tự thì ổn định: chi phí tăng theo mỗi giai đoạn, và tăng mạnh khi đã có dữ liệu thật cùng người dùng thật.

Hệ quả thực hành là đầu tư vào hai giai đoạn đầu không phải chi phí mà là giảm chi phí. Một tài liệu đặc tả kỹ tốn thời gian; một dự án làm lại vì đặc tả sơ sài tốn nhiều thời gian hơn, cộng thêm niềm tin đã mất.

Ba điểm kiểm soát chi phí

Nếu chỉ chọn ba điểm để kiểm soát trong toàn bộ quy trình, chọn ba điểm này:

1. Chốt phạm vi có mục "không bao gồm". Phạm vi không có ranh giới là phạm vi mở, và phạm vi mở là chi phí mở.
2. Chốt tiêu chí nghiệm thu trước khi xây dựng. Tiêu chí viết sau khi có sản phẩm thường được viết theo sản phẩm, không theo nhu cầu.
3. Ghi nhận thay đổi ngay khi phát sinh. Thay đổi không ghi nhận không biến mất; nó chuyển thành tranh chấp ở cuối dự án, khi hai bên không còn nhớ bối cảnh.

Chọn nhịp triển khai: không có phương pháp đúng cho mọi dự án

Có hai cách tổ chức công việc phổ biến. Một là chia dự án thành các đợt ngắn, mỗi đợt tạo ra phần chạy được và có thể điều chỉnh ưu tiên. Hai là chốt toàn bộ yêu cầu rồi triển khai theo chuỗi tuần tự.

Cách thứ nhất phù hợp khi yêu cầu còn chưa chắc, khi người dùng chưa hình dung được sản phẩm, hoặc khi ưu tiên có thể thay đổi theo phản hồi thị trường. Cách thứ hai phù hợp khi yêu cầu đã rõ và ít thay đổi, khi cần chốt ngân sách và phạm vi trước khi bắt đầu, hoặc khi hợp đồng và hồ sơ thầu yêu cầu phạm vi cố định.

Điều không nên làm là tuyên bố một phương pháp là chuẩn mực cho mọi dự án. Mỗi cách có điểm mạnh riêng, và chọn sai cách gây ra vấn đề khác nhau: chia đợt ngắn trong một dự án có phạm vi cố định tạo ra cảm giác thiếu kế hoạch; chuỗi tuần tự trong một dự án nhiều bất định tạo ra sản phẩm đúng hợp đồng nhưng không dùng được.

Cấu trúc chi tiết của từng giai đoạn, kèm danh sách kiểm tra theo từng mốc bàn giao, được trình bày trong quy trình phát triển phần mềm gồm những bước nào. Phần ảnh hưởng của thuế đến tổng chi phí sở hữu nằm trong thuế GTGT của phần mềm là bao nhiêu.

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

Quy trình phát triển phần mềm có bắt buộc phải đủ sáu giai đoạn không?

Không có quy định bắt buộc về số giai đoạn. Số giai đoạn là cách tổ chức công việc, không phải yêu cầu pháp lý. Điều quan trọng là mỗi giai đoạn có đầu ra rõ ràng và đầu ra đó được dùng làm đầu vào cho giai đoạn sau; thiếu liên kết này thì quy trình chỉ còn là hình thức.

Giai đoạn nào quan trọng nhất trong quy trình?

Giai đoạn đặc tả có ảnh hưởng lớn nhất đến chi phí, vì nó quyết định mọi giai đoạn sau làm gì. Tuy vậy, đặc tả chỉ tốt khi khám phá đủ kỹ. Cách nhìn thực dụng là hai giai đoạn đầu tạo thành một khối: khám phá tìm ra vấn đề đúng, đặc tả mô tả giải pháp kiểm chứng được.

Dự án nhỏ có cần tài liệu đặc tả không?

Cần, nhưng độ dày khác nhau. Với dự án nhỏ, đặc tả có thể chỉ là vài trang gồm danh sách yêu cầu có mã và tiêu chí nghiệm thu. Điều không thể thiếu là yêu cầu có mã và tiêu chí kiểm chứng được, vì đó là cơ sở để nghiệm thu và để xử lý thay đổi.

Làm sao biết dự án đang chậm tiến độ thật hay chỉ là cảm giác?

So sánh số hạng mục đã nghiệm thu với số hạng mục đã cam kết trong mốc gần nhất, thay vì so sánh cảm nhận về khối lượng công việc. Nếu báo cáo chỉ có phần trăm, yêu cầu chuyển sang báo cáo theo hạng mục với trạng thái rõ ràng. Chậm tiến độ thật thường đi kèm số hạng mục ở trạng thái "chờ kiểm thử" tăng lên, không phải số hạng mục "đang làm" tăng lên.

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 mà WinSell áp dụng — Khám phá, Đặc tả, Xây dựng, Bàn giao và đo lường — cùng sáu giai đoạn kỹ thuật bên trong. Các thuật ngữ pháp lý liên quan đến nghiệm thu và sở hữu sản phẩm được đối chiếu theo Bộ luật Dân sự 91/2015/QH13 và Luật Sở hữu trí tuệ hiện hành.

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, đặc tả và tiêu chí nghiệm thu chốt trước khi triển khai, rồi 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.