Qui trình phát triển/xây dựng phần mềm (Software Development/Engineering Process – SEP) có tính chất quyết định để tạo ra sản phẩm chất luợng tốt với chi phí thấp và năng suất cao. Qui trình là gì?  Qui trình có thể hiểu là phương pháp thực hiện hoặc sản xuất ra sản phẩm. Tương tự như vậy, SEP chính là phương pháp phát triển hay sản xuất ra sản phẩm phần mềm Thông thường một qui trình bao gồm những yếu tố cơ bản sau: • Thủ tục (Procedures) • Hướng dẫn công việc (Activity Guidelines) • Biểu mẫu (Forms/templates) • Danh sách kiểm định (Checklists) • Công cụ hỗ trợ (Tools) Với các nhóm công việc chính: • Đặc tả yêu cầu (Requirements Specification): chỉ ra những “đòi hỏi” cho cả các yêu cầu chức năng và phi chức năng. • Phát triển phần mềm (Development): tạo ra phần mềm thỏa mãn các yêu cầu được chỉ ra trong “Đặc tả yêu cầu”. • Kiểm thử phần mềm (Validation/Testing): để bảo đảm phần mềm sản xuất ra đáp ứng những “đòi hỏi” được chỉ ra trong “Đặc tả yêu cầu”. • Thay đổi phần mềm (Evolution): đáp ứng nhu cầu thay đổi của khách hàng. SEP, ISO, CMM/CMMI Qui trình khung (Process Framework – PF). PF sẽ chỉ ra những yêu cầu mà một qui trình phải đáp ứng tùy theo mỗi mức độ. Có nhiều PF, nhưng phổ biến nhất là ISO và CMM (Capability Maturity Model) được các tổ chức thế giới công nhận
Ngày nay, phần mềm không đứng riêng một mình mà thường là một bộ phận trong hệ thống hoàn chỉnh. Do đó, CMMI (Capability Maturity Model Integration) ra đời hướng đến các qui trình cho việc xây dựng cả hệ thống, bao gồm cả việc tích hợp để xây dựng và bảo trì toàn bộ hệ thống. CÁC MÔ HÌNH SEP Mô hình SEP còn được gọi là chu trình hay vòng đời phần mềm (SLC – Software Life Cycle). SLC là tập hợp các công việc và quan hệ giữa chúng với nhau diễn ra trong quá trình phát triển phần mềm. Có khá nhiều mô hình SLC khác nhau, trong đó một số được ứng dụng khá phổ biến trên thế giới:Các mô hình một phiên bản (Single-version models) • Mô hình Waterfall (Waterfall model) Mô hình này bao gồm các giai đoạn xử lý nối tiếp nhau. Thực tế cho thấy đến những giai đoạn sau mới có khả năng nhận ra sai sót trong những giai đoạn trước và phải quay lại để sửa chữa. Hình 1: Mô hình Waterfall • Mô hình chữ V (V-model) Tinh thần chủ đạo của V-model là các hoạt động kiểm thử phải được tiến hành song song (theo khả năng có thể) ngay từ đầu chu trình cùng với các hoạt động phát triển. Ví dụ, các hoạt động cho việc lập kế hoạch kiểm thử toàn hệ thống có thể được thực hiện song song với các hoạt động phân tích và thiết kế hệ thống. Hình 2: V-model • Các mô hình nhiều phiên bản (Multi-version models) • Mô hình mẫu (Prototype) Hình 3: Mô hình Prototype Trong đó, qui trình được bắt đầu bằng việc thu thập yêu cầu với sự có mặt của đại diện của cả phía phát triển lẫn khách hàng nhằm định ra mục tiêu tổng thể của hệ thống phần mềm sau này, đồng thời ghi nhận tất cả những yêu cầu có thể biết được và sơ luợc những nhóm yêu cầu nào cần phải được làm rõ.Sau đó, thực hiện thiết kế nhanh tập trung chuyển tải những khía cạnh thông qua prototype để khách hàng có thể hình dung, đánh giá giúp hoàn chỉnh yêu cầu cho toàn hệ thống phần mềm. Việc này không những giúp tinh chỉnh yêu cầu, mà đồng thời giúp cho đội ngũ phát triển thông hiểu hơn những gì cần được phát triển. Tiếp theo sau giai đoạn làm prototype này có thể là một chu trình theo mô hình waterfall hay cũng có thể là mô hình khác.Chú ý, prototype thường được làm thật nhanh trong thời gian ngắn nên không được xây dựng trên cùng môi trường và công cụ phát triển của giai đoạn xây dựng phần mềm thực sự sau này. Prototype không đặt ra mục tiêu tái sử dụng cho giai đoạn phát triển thực sự sau đó. • Mô hình tiến hóa (Evolutionary) Hình 4: Mô hình tiến hóa Mô hình này thực sự cũng là một dạng dựa trên mô hình mẫu, tuy nhiên có sự khác biệt:• mô hình tiến hóa xây dựng nhiều phiên bản prototype liên tiếp nhau.• những phiên bản prototype trước sẽ được xây dựng với mục tiêu có thể tái sử dụng trong những phiên bản sau. Hình 4 minh họa mô hình tiến hóa, cho thấy một số phần của hệ thống phần mềm có thể đuợc xây dựng sớm ngay từ giai đoạn thực hiện phân tích yêu cầu và thiết kế. • Mô hình tăng trưởng (Incremental) Mô hình tăng trưởng kết hợp những ưu điểm của mô hình thác nước và mô hình tiến hóa. Ý tưởng của mô hình này là phân chia phần mềm thành những phần tăng trưởng (được gọi là các increments) và phát triển, bàn giao chúng lần lượt cho khách hàng theo mức độ quan trọng. Phần tăng trưởng nào đến lượt được phát triển thì những yêu cầu tương ứng sẽ được phân tích. Chỉ những thay đổi từ phía khách hàng cho những phần chưa được phát triển mới được chấp nhận. – Rút ngắn thời gian chờ đợi của khách hàng. – Tăng chất lượng phần mềm. – Giảm bớt những yêu cầu không cần thiết từ khách hàng. – Tăng năng suất lao động. • Mô hình phát triển ứng dụng nhanh (RAD) Mô hình phát triển nhanh (RAD – Rapid Application Development) chính là mô hình tăng dần với chu kỳ phát triển cực ngắn. Để đạt được mục tiêu này, RAD dựa trên phương pháp phát triển trên cơ sở thành phần hóa hệ thống cùng với việc tái sử dụng các thành phần thích hợp. RAD thích hợp cho những hệ thống quản lý thông tin. • Mô hình xoắn (Spiral) Mô hình này được xây dựng bởi Barry Boehm, đặt trọng tâm phân tích rủi ro và xem xét kế hoạch để giải quyết chúng, thông qua nhiều chu kỳ con nối tiếp được lặp liên tiếp dựa trên bản chất của mô hình lặp.Trong mô hình này, việc phân tích và giải quyết những vấn đề có rủi ro cao tập trung vào thiết kế từng khía cạnh cụ thể chứ không dựa vào việc xử lý các vấn đề một cách chung chung. 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 quá 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 quá 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. Cài đặt đối tượng: Chỉ ra các đối tượng của pha trong đề án. Những khó khăn hay cưỡng bức của quá trình và của sản phẩm được xác định và được lên kế hoạch chi tiết. Xác định các yếu tố rủi ro của đề án. Các phương án thay thế tùy theo các rủi ro này có thể được dự trù. Lượng định và giảm thiểu rủi ro. Tiến hành phân tích mỗi yếu tố rủi ro đã xác định. Các bước đặt ra để giảm thiểu rủi ro. Phát triển và đánh giá: Sau khi đánh giá các yếu tố rủi ro, một mô hình phát triển cho hệ thống được chọn. |
