Một phần của loạt bài về |
Phát triển phần mềm |
---|
Quy trình phát triển phần mềm (software development methodology) là một cấu trúc bao gồm tập hợp các thao tác và các kết quả tương quan sử dụng trong việc phát triển để sản xuất hay phát triển ra một sản phẩm phần mềm. Các thuật ngữ tương tự là vòng đời phần mềm và quy trình phần mềm. Đây được coi là một thành phần tập con của vòng đời phát triển hệ thống. Có một số mô hình cho việc xây dựng các quy trình này, mỗi mô hình mô tả các phương thức cũng như các nhiệm vụ hoặc thao tác cần được thực hiện trong cả quá trình. Nhiều người coi mô hình vòng đời "Software Development Life Cycle" là một phần trong quy trình phát triển phần mềm "Software development methodology". Ví dụ, có rất 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. ISO/IEC 12207 là một tiêu chuẩn quốc tế cho các quy trình vòng đời phần mềm, mục đích là trở thành một tiêu chuẩn định nghĩa tất cả các công việc cần thực hiện để xây dựng và bảo trì sản phẩm phần mềm.
Tiêu chuẩn quốc tế miêu tả các phương pháp cho việc lựa chọn, triển khai và giám sát vòng đời cho phần mềm là ISO/IEC 12207.
Một quá trình kéo dài hàng thập kỷ với mục tiêu tìm ra được các quy trình có tính lặp lại và có thể dự đoán trước được để cải thiện hiệu suất lao động và chất lượng sản phẩm. Một số người đã cố gắng hệ thống hóa hoặc hình thức hóa các nhiệm vụ viết phần mềm vốn không tuân theo quy tắc nào cả. Một số khác áp dụng các kỹ thuật quản lý dự án để viết phần mềm. Nếu như không có quản lý dự án, thì các dự án phần mềm có thể sẽ dễ bị chuyển giao chậm hoặc vượt quá ngân sách. Với một số lượng lớn các dự án phần mềm không đáp ứng được kỳ vọng về chức năng, chi phí hoặc kế hoạch chuyển giao đã cho thấy một thực tế là do đang thiếu các phương thức quản lý dự án hiệu quả.
Có 4 thao tác là nền tảng của hầu hết các quy trình phần mềm là:
Mô hình phát triển phần mềm Waterfall là quy trình phát triển phần mềm từ phân tích yêu cầu cho tới khi phát hành sản phẩm mà không quay về bước trước đó. Các bước phát triển phần mềm theo một chiều các bước sau:
Chỗ yếu của mô hình này là nó không linh hoạt. Các bộ phận của đề án chia ra thành những phần riêng của các giai đoạn. Hệ thống phân phối đôi khi không dùng được vì không thỏa mãn được yêu cầu của khách hàng. Mặc dù vậy mô hình này phản ảnh thực tế công nghệ. Như là một hệ quả đây vẫn là mô hình cơ sở cho đa số các hệ thống phát triển phần mềm - phần cứng.
Đây là mô hình phát triển từ mô hình thác nước cho thấy mức độ tổng quát hơn của các pha sản xuất của một sản phẩm. Mô hình được đề nghị bởi Boehm vào năm 1988. Mô hình này có thể chỉ ra các rủi ro có thể hình thành trên căn bản của mô hình quy trình (sản xuất) tổng quát.
Mô hình Boehm có dạng xoắn ốc. Mỗi vòng lặp đại diện cho một pha của quy trình phần mềm. Vòng trong cùng tập trung về tính khả thi, vòng kế lo về định nghĩa các yêu cầu, kế đến là thiết kế,...
Không có một pha nào được xem là cố định trong vòng xoắn. Mỗi vòng có 4 phần tương ứng với một pha.
Là quy trình mà trong đó cấu trúc khởi động sẽ nhỏ nhưng linh động và lớn dần của các đề án phần mềm nhằm tìm ra các khó khăn trước khi nó trở thành vấn đề có thể dẫn tới những hủy hoại. quy trình này nhấn mạnh sự gọn nhẹ và tập trung hơn là các phương pháp truyền thống. Các quy trình linh hoạt dùng các thông tin phản hồi thay vì dùng các kế hoạch, như là một cơ chế diều khiển chính. Các thông tin phản hồi có được từ các thử nghiệm và các phiên bản phát hành của phần mềm tham gia.
Các quy trình linh hoạt thưòng có hiệu quả hơn các phương pháp cũ, nó dùng ít thời gian lập trình để sản xuất ra nhiều chức năng hơn, chất lượng cao hơn, nhưng nó không cung cấp một khả năng kế hoạch lâu dài.
Một cách ngắn gọn các phương pháp này cung ứng hiệu quả cao nhất cho vốn đầu tư, nhưng lại không định rõ hiệu quả gì.
Lập trình cực hạn, gọi tắt là XP, là loại quy trình linh hoạt được biết đến nhiều nhất. Trong XP, các pha được xúc tiến trong các bước cực nhỏ (hay liên tục) nếu so với các quy trình kiểu cũ, gọi là các "toán" xử lý. Bước đầu tiên (với chủ định là không hoàn tất) cho đến các bước có thể chỉ tốn một ngày hay một tuần, thay vì phải tốn nhiều tháng như trong phương pháp thác nước. Đầu tiên, một người viết các thử nghiệm tự động để cung cấp các mục tiêu cụ thể cho sự phát triển. Kế đến là giai đoạn viết mã (bởi một cặp lập trình viên); giai đoạn này hoàn tất khi mà các mã viết qua được tất cả các thử nghiệm và những người lập trình không tìm ra thêm được thử nghiệm cần thiết nào nữa. Thiết kế và kiến trúc được điều chỉnh và nâng cao ngay sau giai đoạn viết mã này bởi người đã viết mã trong giai đoạn trước. Hệ thống chưa hoàn tất nhưng hoạt động được này được khai thác hay được đem ra minh họa cho (một phần) người tiêu dùng mà trong số đó có người trong đội phát triển phần mềm. Thời điểm này những người thực nghiệm lại bắt đầu viết các thử nghiệm cho những phần quan trọng kế tiếp của hệ thống.
Do bản chất không thể nắm bắt cụ thể của các hệ thống phần mềm, các nhà quản lý quy trình phần mềm cần các báo cáo, các hồ sơ và xem xét để theo dõi tiến độ cũng như những gì xảy ra của công việc. Hầu hết các tổ chức phát triển các phần mềm lớn dùng kiểu quy trình "định hướng chuyển giao được". Mỗi thao tác phải kết thúc bằng một hồ sơ hay báo cáo nhằm làm cho quy trình phần mềm trở nên cụ thể hơn.