CHƯƠNG I TỔNG QUAN CÁC MÔ HÌNH PHÁT TRIỂN PHẦN MỀM Cũng nhƣ mọi ngành sản xuất khác, qui 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 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, đ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 qui trình phát triển phần mềm chung cho cấp tổ chức hay cấp dự án. Khái niệm quy trình 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: Hình 1. 1 Quy trình phát triển phần mềm 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) 9 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com Quản lý quy trình phần mềm theo mô hình CMM- Thực tiễn và ứng dụng ở Việt Nam 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. 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. 2 : Mô hình Waterfall 10 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com Quản lý quy trình phần mềm theo mô hình CMM- Thực tiễn và ứng dụng ở Việt Nam 2. SEP, ISO, CMM/CMMI (CMM/CMMI-Capability Maturity Model/Integration- Mô hình trƣởng thành khả năng) Phần 2 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 qui trình để cải thiện chất lƣợng và năng suất? Câu trả lời chính là 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 độ. PF không chỉ ra bất kỳ một qui 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 qui 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. 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 qui trình đƣợc thực hiện thông qua qui 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). 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.
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. • CMMI không phải là một tiêu chuẩn, tùy vào từng tổ chức, cách thực hiện khác 11 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com Quản lý quy trình phần mềm theo mô hình CMM- Thực tiễn và ứng dụng ở Việt Nam nhau rất nhiều. • Về nguyên tắc, ISO bao gồm (ở mức cao) hầu hết các quy trình chủ chốt của CMM/CMMI, tuy nhiên ISO đƣợc dùng cho hầu hết mọi ngành nghề, do vậy không cụ thể và gần gũi với công việc đặc thù có liên quan đến PM nhƣ CMM/CMMI.
ISO không cung cấp các ví dụ và kinh nghiệm cụ thể nhƣ CMM/CMMI. 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 chữ V (V-model) Các mô hình nhiều phiên bản (Multi-version models) 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) 12 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com Quản lý quy trình phần mềm theo mô hình CMM- Thực tiễn và ứng dụng ở Việt Nam Hình 1.1 Mô hình Thác nước (Waterfall) 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 1.
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. 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”) 13 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com Quản lý quy trình phần mềm theo mô hình CMM- Thực tiễn và ứng dụng ở Việt Nam mà khách hàng yêu cầu trong SRS.
Đây là 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. 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 hoạ trong Hình 1. Mô hình chữ V 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. 4 : Mô hình Prototype 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.
14 LUAN VAN CHAT LUONG download : add luanvanchat@agmail.com Quản lý quy trình phần mềm theo mô hình CMM- Thực tiễn và ứng dụng ở Việt Nam 3. Mô hình mẫu Mô hình mẫu (prototype) đƣợc minh hoạ trong Hình 3. 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.