I. Tổng Quan Về Quản Lý Quy Trình Phát Triển Phần Mềm VN
Cũng như mọi ngành sản xuất khác, quy trình là một trong những yếu tố cực kỳ quan trọng đem lại sự thành công cho các nhà sản xuất phần mềm. Nó giúp cho mọi thành viên trong dự án, từ người cũ đến người mới, trong hay ngoài công ty đều có thể xử lý đồng bộ công việc tương ứng vị trí của mình thông qua cách thức chung của công ty, hay ít nhất ở cấp độ dự án. Có thể nói quy trình phát triển phần mềm (Software Development Process - SEP) có tính chất quyết định để tạo ra sản phẩm chất lượng tốt với chi phí thấp và năng suất cao. Điều này có ý nghĩa quan trọng đối với các công ty sản xuất hay gia công phần mềm củng cố và phát triển cùng với nền công nghiệp phần mềm đầy cạnh tranh. Trong chương này sẽ giới thiệu một cách tổng quát các mô hình áp dụng khi xây dựng quy trình phát triển phần mềm chung cho cấp tổ chức hay cấp dự án.
1.1. Khái niệm cơ bản về quy trình phát triển phần mềm
Quy 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 quy 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), Phát triển phần mềm (Development), Kiểm thử phần mềm (Validation/Testing), Thay đổi phần mềm (Evolution). Tùy theo mô hình phát triển phần mềm, các nhóm công việc được triển khai theo những cách khác nhau. Để sản xuất cùng một sản phẩm phần mềm người ta có thể dùng các mô hình khác nhau. Tuy nhiên không phải tất cả các mô hình đều thích hợp cho mọi ứng dụng.
1.2. Các mô hình phát triển phần mềm phổ biến hiện nay
Mô hình SEP còn được gọi là chu trình hay vòng đời phần mềm (SDLC - Software Life Cycle). SDLC 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 SDLC 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), Các mô hình nhiều phiên bản (Multi-version models). Các mô hình một phiên bản bao gồm: Mô hình Waterfall (Waterfall model), Mô hình chữ V (V-model). Các mô hình nhiều phiên bản bao gồm: Mô hình mẫu (Prototype), Mô hình tiến hóa (Evolutionary), Mô hình lặp và tăng dần (Iterative and Incremental), Mô hình phát triển ứng dụng nhanh (RAD), Mô hình xoắn (Spiral).
II. Mô Hình CMMI Giải Pháp Quản Lý Chất Lượng Phần Mềm
Phần này sẽ không đi sâu vào tìm hiểu các mô hình phát triển phần mềm mà chỉ cung cấp một cái nhìn tổng quát về chúng, cũng như mối quan hệ giữa SEP với ISO và CMM/CMMI để có thể mô tả kỹ hơn CMM ở chương sau. Vấn đề được đặt ra là làm thế nào cải tiến quy trình để cải thiện chất lượng và năng suất? Câu trả lời chính là quy trình khung (Process Framework - PF). PF sẽ chỉ ra những yêu cầu mà một quy trình phải đáp ứng tùy theo mỗi mức độ. PF không chỉ ra bất kỳ một quy trình cụ thể nào mà chỉ đưa ra những yêu cầu ở mỗi mức độ trưởng thành khác nhau của quy trình phải đạt được. Đây chính là những hướng dẫn cho các hoạt động cải tiến để nâng mức độ trưởng thành từ thấp lên cao.
2.1. So sánh CMMI với các tiêu chuẩn quản lý khác ISO
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. ISO nhắm chung đến nhiều loại tổ chức cả sản xuất lẫn dịch vụ, trong khi CMM được dành riêng cho các tổ chức phát triển phần mềm. Đối với phần mềm, ISO chỉ ra mức độ chất lượng yêu cầu tối thiểu mà một SEP phải đạt (ISO certified) và việc cải tiến quy trình được thực hiện thông qua quy trình kiểm định, trong khi CMM bao gồm những thực tiễn tốt nhất (best practices) được tập hợp rút ra từ rất nhiều tổ chức phát triển phần mềm khác nhau và chúng được tổ chức thành 5 mức độ trưởng thành khác nhau (Level 1 - Initial, Level 2 - Repeatable, Level 3 - Defined, Level 4 - Managed, Level 5 - Optimizing).
2.2. CMMI và xu hướng tích hợp hệ thống hiện đại
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 quy 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. Sự khác nhau giữa ISO 9001 và CMM/CMMI: ISO 9001 là một tiêu chuẩn quốc tế về quản lý, các điều khoản gọi là "yêu cầu" quy định những điểm cần phải làm (what to do), không chỉ ra việc đó nên làm như thế nào (how to do). CMM/CMMI là một mô hình, cung cấp các hướng dẫn và kinh nghiệm thực tế dùng để phát triển, cải tiến và đánh giá năng lực của quy trình.
III. Mô Hình Waterfall Ưu Điểm và Hạn Chế Tại Việt Nam
Mô hình này gồm các giai đoạn xử lý nối tiếp nhau như được mô tả trong hình. Phân tích yêu cầu và tài liệu đặc tả (Requirements and Specifications): là giai đoạn xác định những “đòi hỏi” (“What”) liên quan đến chức năng và phi chức năng mà hệ thống phần mềm cần có. Giai đoạn này cần sự tham gia tích cực của khách hàng và kết thúc bằng một tài liệu được gọi là “Bản đặc tả yêu cầu phần mềm” hay SRS (software requirement specification), trong đó bao gồm tập hợp các yêu cầu đã được duyệt (reviewed) và nghiệm thu (approved) bởi những người có trách nhiệm đối với dự án (từ phía khách hàng). SRS chính là nền tảng cho các hoạt động tiếp theo cho đến cuối dự án.
3.1. Phân tích hệ thống và thiết kế trong mô hình Waterfall
Phân tích hệ thống và thiết kế (System Analysis and Design): là giai đoạn định ra “làm thế nào” (“How”) để hệ thống phần mềm đáp ứng những “đòi hỏi” (“What”) mà khách hàng yêu cầu trong SRS. Đây chính là cầu nối giữa “đòi hỏi” (“What”) và mã (code) được hiện thực để đáp ứng yêu cầu đó. Hiện thực và kiểm thử từng thành phần (Coding and Unit Test): là giai đoạn hiện thực “làm thế nào” (“How”) được chỉ ra trong giai đoạn “Phân tích hệ thống và thiết kế”. Một khâu kiểm thử cuối cùng thường được thực hiện là nghiệm thu (acceptance test), với sự tham gia của khách hàng trong vai trò chính để xác định hệ thống phần mềm có đáp ứng yêu cầu của họ hay không.
3.2. Triển khai và bảo trì hệ thống phần mềm
Cài đặt và bảo trì (Deployment and Maintenance): đây là giai đoạn cài đặt, cấu hình và huấn luyện khách hàng. Giai đoạn này sửa chữa những lỗi của phần mềm (nếu có) và phát triển những thay đổi mới được khách hàng yêu cầu (như sửa đổi, thêm hay bớt chức năng/đặc điểm của hệ thống). 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. Đây chính là kiểu waterfall dạng lặp (Iterative Waterfall) và được minh họa trong hình 1.
IV. Mô Hình Chữ V Tối Ưu Kiểm Thử Trong Phát Triển Phần Mềm
Trong mô hình Waterfall, kiểm thử được thực hiện trong một giai đoạn riêng biệt. Còn với mô hình chữ V, toàn bộ qui trình được chia thành hai nhóm giai đoạn tương ứng nhau: phát triển và kiểm thử. Mỗi giai đoạn phát triển sẽ kết hợp với một giai đoạn kiểm thử tương ứng như được minh họa trong hình 2. 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.
4.1. Lập kế hoạch kiểm thử toàn hệ thống
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.
V. Mô Hình Prototype Giải Pháp Cho Yêu Cầu Không Rõ Ràng
Mô hình mẫu (prototype) được minh họa trong hình 3. Trong đó, quy 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ơ lượ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.
5.1. Thiết kế nhanh và xây dựng Prototype
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 đó.
VI. Mô Hình Agile Linh Hoạt và Thích Ứng Trong Phát Triển
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ế.
6.1. Xây dựng các phiên bản Prototype liên tiếp
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.
