Phần mềm

Quy trình phát triển phần mềm theo yêu cầu từ A–Z

7 giai đoạn của một dự án phần mềm theo yêu cầu, kết quả bàn giao ở mỗi bước và việc doanh nghiệp cần làm để dự án không trễ, không vượt ngân sách.

14/10/20268 phút đọcDTCSoft

Quy trình phát triển phần mềm theo yêu cầu thường gồm 7 giai đoạn: khảo sát, phân tích nghiệp vụ, thiết kế, lập trình, kiểm thử, triển khai và vận hành. Điều quyết định thành bại không nằm ở việc gọi tên đủ các bước, mà ở chỗ doanh nghiệp tham gia đúng lúc, đúng việc ở mỗi bước. Bài này đi qua từng giai đoạn: mục tiêu, kết quả bàn giao và việc doanh nghiệp cần làm.

Tổng quan 7 giai đoạn

Giai đoạn Kết quả bàn giao Doanh nghiệp cần làm
1. Khảo sát Mục tiêu, phạm vi sơ bộ, ước tính ban đầu Nêu rõ vấn đề cần giải quyết, người dùng chính
2. Phân tích nghiệp vụ Tài liệu đặc tả yêu cầu, danh sách chức năng có ưu tiên Cung cấp quy trình, mẫu biểu, báo cáo đang dùng
3. Thiết kế Bản mẫu giao diện (prototype), thiết kế dữ liệu và kiến trúc Duyệt luồng thao tác trên bản mẫu
4. Lập trình Các phiên bản chạy được sau mỗi vòng phát triển Xem demo định kỳ, phản hồi sớm
5. Kiểm thử Biên bản kiểm thử, danh sách lỗi đã xử lý Kiểm thử chấp nhận (UAT) với dữ liệu thật
6. Triển khai Hệ thống chạy thật, dữ liệu đã chuyển đổi, tài liệu hướng dẫn Cử người tham gia đào tạo, chốt ngày chuyển đổi
7. Vận hành Giám sát, sửa lỗi, các bản cập nhật Ghi nhận góp ý, ưu tiên các thay đổi tiếp theo

Giai đoạn 1: Khảo sát và làm rõ mục tiêu

Mục tiêu của giai đoạn này là trả lời câu hỏi “phần mềm này giải quyết vấn đề gì, cho ai, đo bằng gì”. Ví dụ: giảm thời gian tổng hợp báo cáo cuối tháng, bỏ việc nhập lại dữ liệu giữa kho và kế toán, hay để quản lý xem được doanh số theo ngày thay vì theo tháng.

Kết quả là phạm vi sơ bộ và một khoảng ước tính chi phí, thời gian. Ở bước này con số chỉ mang tính định hướng, vì chưa đủ chi tiết để báo giá chính xác. Bài Chi phí làm phần mềm theo yêu cầu giải thích các yếu tố làm khoảng ước tính này rộng hay hẹp.

Giai đoạn 2: Phân tích nghiệp vụ và đặc tả yêu cầu

Đây là giai đoạn hay bị rút ngắn nhất và cũng gây tốn kém nhất về sau nếu làm sơ sài. Người phân tích nghiệp vụ làm việc với từng bộ phận để mô tả:

  • Các quy trình hiện tại và quy trình mong muốn sau khi có phần mềm.
  • Các loại người dùng và quyền hạn của từng loại.
  • Quy tắc nghiệp vụ: cách tính giá, chiết khấu, công nợ, phê duyệt, tính lương…
  • Dữ liệu đầu vào, đầu ra, mẫu chứng từ và báo cáo.
  • Các hệ thống cần kết nối: kế toán, hóa đơn điện tử, cổng thanh toán, sàn thương mại điện tử.

Kết quả là tài liệu đặc tả yêu cầu (SRS) và danh sách chức năng được xếp theo mức ưu tiên: cần có cho phiên bản đầu, nên có, và để sau. Danh sách này là căn cứ để chốt phạm vi và báo giá.

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

Thiết kế trải nghiệm và giao diện

Trước khi viết mã, đội ngũ dựng bản mẫu (prototype) các màn hình chính để người dùng thật bấm thử. Sửa một luồng thao tác trên bản mẫu tốn ít công hơn rất nhiều so với sửa trên phần mềm đã lập trình xong.

Thiết kế dữ liệu và kiến trúc

Song song, đội kỹ thuật thiết kế cơ sở dữ liệu, cách phân quyền, cách tích hợp với hệ thống khác, và lựa chọn hạ tầng (máy chủ riêng hay cloud). Những quyết định này ảnh hưởng đến khả năng mở rộng và chi phí vận hành nhiều năm sau, nên cần được ghi lại thành tài liệu.

Giai đoạn 4: Lập trình theo từng vòng ngắn

Thay vì làm liền một mạch rồi bàn giao một lần, phần lớn dự án hiện nay chia việc lập trình thành các vòng ngắn (thường 1–3 tuần). Cuối mỗi vòng có một phiên bản chạy được để doanh nghiệp xem và phản hồi.

Cách làm này giúp phát hiện sớm những chỗ “hiểu khác nhau” giữa hai bên. Một chức năng bị hiểu sai được phát hiện sau hai tuần thì chỉ mất hai tuần, còn phát hiện khi nghiệm thu thì có thể phải làm lại cả phân hệ.

Ở giai đoạn này doanh nghiệp nên có một đầu mối đủ thẩm quyền để trả lời câu hỏi nghiệp vụ và quyết định ưu tiên. Thiếu đầu mối, đội phát triển phải tự đoán hoặc chờ, cả hai đều làm chậm dự án.

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

Kiểm thử gồm hai lớp:

  • Kiểm thử của đội phát triển: kiểm thử chức năng, kiểm thử tích hợp, kiểm thử hiệu năng và bảo mật ở mức phù hợp với hệ thống.
  • Kiểm thử chấp nhận (UAT): người dùng của doanh nghiệp chạy thử các nghiệp vụ thật trên môi trường thử nghiệm (staging), với dữ liệu gần giống thật.

UAT là bước doanh nghiệp không nên giao hết cho nhà cung cấp. Chỉ người làm nghiệp vụ hằng ngày mới nhận ra những trường hợp đặc biệt: đơn hàng trả một phần, nhân viên đổi ca giữa tháng, khách hàng có hai mã số thuế.

Giai đoạn 6: Triển khai và chuyển đổi

Đưa phần mềm vào dùng thật gồm nhiều việc hơn là “cài lên máy chủ”:

  1. Chuyển đổi dữ liệu: làm sạch và nhập dữ liệu từ Excel hoặc phần mềm cũ (danh mục khách hàng, hàng hóa, số dư công nợ, tồn kho đầu kỳ).
  2. Đào tạo: hướng dẫn theo từng vai trò, kèm tài liệu hoặc video ngắn.
  3. Chọn cách chuyển đổi: chạy song song hệ thống cũ một thời gian, triển khai thí điểm tại một bộ phận hoặc chi nhánh, hoặc chuyển hẳn từ một ngày cố định.
  4. Hỗ trợ sát giai đoạn đầu: những tuần đầu sau khi chạy thật là lúc phát sinh nhiều câu hỏi và yêu cầu chỉnh sửa nhỏ nhất.

Với doanh nghiệp đang thay một hệ thống cũ, có thể tham khảo cách tiếp cận trong dự án hiện đại hóa hệ thống cũ.

Giai đoạn 7: Vận hành, bảo trì và phát triển tiếp

Phần mềm theo yêu cầu không “xong” sau khi bàn giao. Quy trình doanh nghiệp thay đổi, quy định thuế và hóa đơn thay đổi, người dùng đề xuất cải tiến. Cần thống nhất trước:

  • Ai giám sát hệ thống, sao lưu dữ liệu, cập nhật bảo mật.
  • Thời gian phản hồi khi có lỗi, phân theo mức độ nghiêm trọng.
  • Cách tiếp nhận và báo giá các yêu cầu thay đổi.
  • Bàn giao mã nguồn và tài liệu kỹ thuật, để doanh nghiệp không phụ thuộc vào một đơn vị duy nhất.

Waterfall hay Agile: nên chọn mô hình nào

Waterfall (thác nước) đi tuần tự: phân tích xong toàn bộ mới thiết kế, thiết kế xong mới lập trình. Phù hợp khi yêu cầu rõ ràng, ít thay đổi, hoặc khi hợp đồng cần chốt phạm vi cứng.

Agile chia dự án thành các vòng ngắn, mỗi vòng ra một phần chạy được, phạm vi có thể điều chỉnh theo phản hồi. Phù hợp khi doanh nghiệp chưa hình dung hết yêu cầu, hoặc muốn đưa phần quan trọng nhất vào dùng sớm.

Trên thực tế, nhiều dự án kết hợp: phân tích và thiết kế tổng thể đủ kỹ ở đầu dự án để chốt khung phạm vi, sau đó lập trình và bàn giao theo từng vòng.

Những sai lầm thường gặp

  • Bỏ qua phân tích để “làm cho nhanh”. Thời gian tiết kiệm ở đầu thường bị trả lại gấp nhiều lần khi phải sửa ở cuối.
  • Không có người ra quyết định phía doanh nghiệp. Mỗi bộ phận yêu cầu một kiểu, phạm vi phình ra liên tục.
  • Muốn làm tất cả trong phiên bản đầu. Dự án kéo dài, đến khi xong thì nghiệp vụ đã khác.
  • Coi nhẹ chuyển đổi dữ liệu và đào tạo. Phần mềm tốt vẫn thất bại nếu nhân viên không dùng hoặc dữ liệu đầu kỳ sai.
  • Không thỏa thuận về mã nguồn và bảo trì từ đầu. Đến khi cần sửa mới phát hiện mình không có quyền hoặc không có tài liệu.

Nếu bạn còn đang cân nhắc có nên làm phần mềm riêng hay không, hãy đọc trước bài Khi nào nên xây phần mềm riêng thay vì mua sẵn?. Còn nếu đã xác định được bài toán, DTCSoft có thể cùng bạn bắt đầu từ giai đoạn khảo sát và phân tích. Xem cách chúng tôi làm việc tại trang phát triển phần mềm theo yêu cầu.

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

Phát triển một phần mềm theo yêu cầu mất bao lâu?

Phụ thuộc vào phạm vi, số tích hợp và mức độ sẵn sàng của doanh nghiệp. Cách làm hiệu quả là xác định phiên bản đầu đủ nhỏ để đưa vào dùng sớm, sau đó mở rộng theo từng giai đoạn.

Doanh nghiệp cần chuẩn bị gì trước khi làm việc với đơn vị phát triển?

Mục tiêu cụ thể, mô tả quy trình hiện tại, các mẫu biểu và báo cáo đang dùng, danh sách phần mềm đang chạy, và một người đầu mối có quyền quyết định về nghiệp vụ.

Có thể thay đổi yêu cầu khi đang phát triển không?

Có, nhưng cần quy trình rõ ràng: đánh giá ảnh hưởng đến thời gian và chi phí, rồi doanh nghiệp quyết định đưa vào vòng hiện tại, vòng sau hay bỏ qua. Làm theo vòng ngắn giúp việc thay đổi ít tốn kém hơn.

Tài liệu đặc tả yêu cầu (SRS) có bắt buộc không?

Không nhất thiết phải là một tài liệu dày, nhưng yêu cầu cần được ghi lại thành văn bản mà hai bên cùng xác nhận. Đây là căn cứ để báo giá, kiểm thử và nghiệm thu.

Sau khi bàn giao, doanh nghiệp có nhận mã nguồn không?

Điều này phụ thuộc hợp đồng, nên cần thỏa thuận ngay từ đầu. Sở hữu mã nguồn và tài liệu kỹ thuật giúp doanh nghiệp chủ động khi cần bảo trì hoặc phát triển tiếp.

Liên quan

Giải pháp liên quan

Đọc tiếp

Bài viết khác

Có một bài toán cần giải quyết?

Mô tả ngắn gọn nhu cầu — chuyên gia giải pháp của DTCSoft phản hồi trong 24 giờ làm việc.

Zalo