Quy trình xây dựng phần mềm

Quy trình xây dựng phần mềm (phương pháp phát triển phần mềm) là một hệ thống bao gồm các bước và kết quả liên quan được áp dụng để tạo ra hoặc phát triển một sản phẩm phần mềm. Các thuật ngữ tương đương bao gồm vòng đời phần mềm và quy trình phần mềm, thường được xem là một phần của vòng đời phát triển hệ thống. Có nhiều mô hình được sử dụng để xây dựng các quy trình này, mỗi mô hình mô tả các phương pháp và nhiệm vụ cần thực hiện trong toàn bộ quá trình. Ví dụ, nhiều quy trình phát triển phần mềm tuân theo mô hình vòng đời xoắn ốc. Tiêu chuẩn ISO/IEC 12207 cung cấp định nghĩa quốc tế về các quy trình vòng đời phần mềm, với mục tiêu định hình các công việc cần thiết để xây dựng và duy trì sản phẩm phần mềm.

Tổng quan

Tiêu chuẩn quốc tế ISO/IEC 12207 mô tả các phương pháp để chọn, triển khai và giám sát vòng đời phần mềm.

Quá trình kéo dài hàng thập kỷ nhằm tìm ra các quy trình có thể lặp lại và dự đoán được để cải thiện hiệu suất và chất lượng sản phẩm. Nhiều người đã cố gắng hệ thống hóa các nhiệm vụ phát triển phần mềm không theo quy tắc cụ thể, trong khi một số khác áp dụng kỹ thuật quản lý dự án. Thiếu quản lý dự án có thể dẫn đến việc dự án bị chậm trễ hoặc vượt ngân sách. Việc nhiều dự án phần mềm không đạt yêu cầu về chức năng, chi phí, hoặc kế hoạch chuyển giao cho thấy sự cần thiết phải có phương pháp quản lý dự án hiệu quả.

Bốn bước cơ bản trong hầu hết các quy trình phát triển phần mềm bao gồm:

1. Định nghĩa yêu cầu phần mềm: Cần xác định rõ các chức năng và điều kiện hoạt động của phần mềm.
2. Phát triển phần mềm: Quy trình phát triển được thiết kế để phần mềm đáp ứng các yêu cầu đã định nghĩa.
3. Đánh giá phần mềm: Phần mềm phải được kiểm tra để đảm bảo rằng nó thực hiện đúng các yêu cầu của người dùng.
4. Cải tiến phần mềm: Phần mềm cần được điều chỉnh để đáp ứng những thay đổi trong yêu cầu của khách hàng.

Các mô hình phát triển phần mềm

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

Mô hình phát triển phần mềm Waterfall là quy trình phát triển từ phân tích yêu cầu đến phát hành sản phẩm mà không quay lại các bước trước. Quy trình này đi theo một hướng tuần tự với các bước sau:

1. Phân tích yêu cầu và định nghĩa: Xác định hệ thống dịch vụ, thách thức và mục tiêu với sự hỗ trợ từ người dùng. Sau đó, các yếu tố này được mô tả rõ ràng để cả người phát triển và người tiêu dùng đều hiểu được.
2. Thiết kế phần mềm và hệ thống: Tạo ra thiết kế cho các quy trình, bộ phận, và yêu cầu cả về phần mềm và phần cứng. Hoàn thiện gần như toàn bộ kiến trúc hệ thống. Thiết kế phần mềm cũng liên quan đến việc mô tả các chức năng của phần mềm, có thể chuyển đổi thành một hoặc nhiều chương trình khả thi.
3. Thực hiện và kiểm tra các đơn vị: Trong giai đoạn này, thiết kế phần mềm được kiểm tra dưới dạng tập hợp các chương trình hoặc đơn vị nhỏ. Kiểm tra bao gồm việc xác minh rằng mỗi đơn vị đáp ứng yêu cầu đã định nghĩa.
4. Tích hợp và kiểm tra toàn bộ hệ thống: Các chương trình riêng lẻ hoặc các đơn vị được kết hợp và kiểm tra như một hệ thống hoàn chỉnh để đảm bảo rằng các yêu cầu phần mềm được đáp ứng. Sau khi kiểm tra, phần mềm sẽ được cung cấp cho người tiêu dùng.
5. Sản xuất và bảo trì: Đây thường là giai đoạn dài nhất trong vòng đời sản phẩm. Phần mềm được triển khai và sử dụng thực tế. Bảo trì bao gồm việc sửa lỗi chưa phát hiện trong các giai đoạn trước, nâng cấp hiệu suất hệ thống và cải thiện dịch vụ theo yêu cầu mới.

Nhược điểm của mô hình này là tính không linh hoạt. Các phần của dự án được chia thành các giai đoạn riêng biệt. Hệ thống phân phối đôi khi không đáp ứng yêu cầu của khách hàng. Tuy nhiên, mô hình này phản ánh thực tế công nghệ và vẫn là cơ sở cho nhiều hệ thống phát triển phần mềm - phần cứng.

Mô hình phát triển tiến hóa

• Phân loại phát triển tiến hóa
  1. Lập trình thăm dò: Quy trình làm việc với khách hàng để khám phá yêu cầu và phát hành phần mềm hoàn chỉnh. Phát triển nên bắt đầu với các phần đã được hiểu rõ. Phần mềm sẽ được bổ sung chức năng mới theo yêu cầu của khách hàng (và phản hồi nhận được).
  2. Mẫu thăm dò: Mục tiêu của phát triển tiến hóa là hiểu rõ yêu cầu của khách hàng và từ đó cải thiện các định nghĩa yêu cầu cho phần mềm. Các mẫu tập trung vào việc thử nghiệm những phần yêu cầu có thể gây khó hiểu hoặc nhầm lẫn.

• Phân tích mô hình: Mô hình phát triển tiến hóa thường hiệu quả hơn mô hình thác nước, nhưng vẫn tồn tại một số nhược điểm:
  1. Quy trình không rõ ràng: Các nhà quản lý cần thực hiện các phân phối thường xuyên để theo dõi tiến độ. Việc lập hồ sơ cho phần mềm cũng không tiết kiệm chi phí.
  2. Phần mềm có thể có cấu trúc kém: Sự thay đổi liên tục có thể làm hỏng cấu trúc phần mềm, gây khó khăn và tốn kém.
  3. Yêu cầu kỹ năng đặc biệt: Hầu hết các hệ thống theo mô hình này được thực hiện bởi các nhóm nhỏ với kỹ năng cao và các cá nhân năng động.
• Mô hình này phù hợp với:
  1. Phát triển phần mềm nhỏ
  2. Phát triển phần mềm có vòng đời ngắn
  3. Áp dụng trong các hệ thống lớn hơn ở những nơi không thể mô tả chi tiết yêu cầu trong quá trình phát triển, như hệ thống trí tuệ nhân tạo (AI) và giao diện người dùng.

Mô hình xoắn ốc của Boehm

Mô hình này mở rộng từ mô hình thác nước, cung cấp cái nhìn tổng quát hơn về các giai đoạn sản xuất sản phẩm. Được Boehm đề xuất vào năm 1988, mô hình này giúp xác định các rủi ro có thể phát sinh dựa trên quy trình sản xuất tổng quát.

Mô hình Boehm có cấu trúc xoắn ốc, với mỗi vòng lặp đại diện cho một giai đoạn trong quy trình phần mềm. Vòng lặp trong cùng tập trung vào tính khả thi, tiếp theo là định nghĩa yêu cầu, thiết kế, và các bước khác.

Không có giai đoạn nào được coi là cố định trong mô hình xoắn ốc. Mỗi vòng lặp bao gồm 4 phần tương ứng với một giai đoạn của quy trình.

1. Xác định mục tiêu: Xác định các mục tiêu của giai đoạn trong dự án. Các khó khăn và yêu cầu của quy trình cũng như sản phẩm được phân tích và lập kế hoạch chi tiết. Xác định các yếu tố rủi ro và lên kế hoạch cho các phương án dự phòng phù hợp.
2. Đánh giá và giảm rủi ro: Phân tích từng yếu tố rủi ro đã được xác định. Đưa ra các bước cụ thể để giảm thiểu các rủi ro này.
3. Phát triển và đánh giá: Sau khi phân tích rủi ro, lựa chọn mô hình phát triển phù hợp cho hệ thống.
4. Lập kế hoạch: Xem xét dự án và quyết định xem có nên tiếp tục với giai đoạn tiếp theo trong vòng lặp hay không.

Các quy trình linh hoạt

Là quy trình trong đó cấu trúc bắt đầu nhỏ nhưng có khả năng mở rộng, giúp phát hiện khó khăn trước khi chúng trở thành vấn đề nghiêm trọng. Quy trình này tập trung vào sự linh hoạt và hiệu quả hơn so với các phương pháp truyền thống, sử dụng phản hồi từ các thử nghiệm và phiên bản phát hành phần mềm thay vì kế hoạch chi tiết để điều khiển quá trình.

Các quy trình linh hoạt thường hiệu quả hơn các phương pháp truyền thống, tiết kiệm thời gian lập trình để cung cấp nhiều chức năng hơn và chất lượng tốt hơn, tuy nhiên không cung cấp khả năng lập kế hoạch dài hạn.

Tóm lại, các phương pháp linh hoạt mang lại hiệu quả cao nhất cho vốn đầu tư nhưng không rõ ràng về hiệu quả lâu dài.

Lập trình cực hạn (XP) là một trong những phương pháp linh hoạt nổi bật nhất. Trong XP, các giai đoạn được thực hiện qua các bước rất nhỏ và liên tục, thay vì các giai đoạn lớn như trong các phương pháp truyền thống. Mỗi bước có thể chỉ kéo dài từ một ngày đến một tuần, thay vì nhiều tháng như trong mô hình thác nước. Ban đầu, một lập trình viên viết các thử nghiệm tự động để đặt mục tiêu rõ ràng cho phát triển. Sau đó, giai đoạn viết mã được thực hiện bởi cặp lập trình viên, kết thúc khi mã hoàn tất các thử nghiệm và không cần thêm thử nghiệm nào. Thiết kế và kiến trúc sẽ được điều chỉnh sau khi viết mã. Hệ thống, dù chưa hoàn thiện, được sử dụng để minh họa cho một phần người tiêu dùng và đội phát triển, trong khi các thử nghiệm tiếp theo được viết cho các phần quan trọng còn lại của hệ thống.

Triển khai quy trình

Vì bản chất của các hệ thống phần mềm rất khó nắm bắt cụ thể, các nhà quản lý quy trình phần mềm cần theo dõi tiến độ qua các báo cáo và hồ sơ. Các tổ chức phát triển phần mềm lớn thường áp dụng quy trình 'định hướng chuyển giao được', trong đó mỗi giai đoạn kết thúc bằng một báo cáo hoặc hồ sơ, nhằm làm cho quy trình phần mềm trở nên rõ ràng hơn.