Khái niệm quy trình
Qui trình là phương pháp thực hiện hoặc sản xuất sản phẩm, trong khi SEP là phương pháp phát triển và sản xuất 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
Hướng dẫn công việc (Activity Guidelines)
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
Mô hình phát triển phần mềm ảnh hưởng đến cách thức triển khai các nhóm công việc Để tạo ra một sản phẩm phần mềm, có thể áp dụng nhiều mô hình khác nhau Tuy nhiên, không phải tất cả các mô hình đều phù hợp với mọi loại ứng dụng.
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
Trong lĩnh vực phát triển phần mềm, hai mô hình phổ biến nhất là ISO và CMM (Capability Maturity Model), được công nhận toàn cầu ISO áp dụng cho cả tổ chức sản xuất và dịch vụ, xác định mức chất lượng tối thiểu mà một tổ chức phát triển phần mềm phải đạt được (ISO certified) thông qua quy trình kiểm định Ngược lại, CMM tập trung vào các thực tiễn tốt nhất từ nhiều tổ chức khác nhau và được phân chia thành 5 mức độ trưởng thành: Level 1 - Initial, Level 2 - Repeatable, Level 3 - Defined, Level 4 - Managed, và Level 5 - Optimizing Với sự phát triển của công nghệ, phần mềm hiện nay thường là một phần của hệ thống lớn hơn, dẫn đến sự ra đời của CMMI (Capability Maturity Model Integration), nhằm cải thiện quy trình 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à tiêu chuẩn quốc tế về quản lý chất lượng, quy định các yêu cầu cụ thể về những gì cần thực hiện (what to do) mà không chỉ rõ cách thức thực hiện (how to do).
CMM/CMMI là một mô hình cung cấp hướng dẫn và kinh nghiệm thực tiễn nhằm phát triển, cải tiến và đánh giá năng lực quy trình Mô hình này hỗ trợ các tổ chức trong việc nâng cao hiệu quả và chất lượng quy trình làm việc của họ.
• 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 là những tiêu chuẩn cụ thể hơn về quản lý dự án, trong khi ISO được áp dụng rộng rãi cho hầu hết các ngành nghề Tuy nhiên, ISO không cung cấp những ví dụ và kinh nghiệm chi tiết như CMM/CMMI, do đó không gần gũi với các công việc đặc thù liên quan đến quản lý dự án.
Các mô hình SEP
Mô hình SEP, hay còn gọi là chu trình phần mềm (SLC - Software Life Cycle), là tập hợp các công việc và mối quan hệ giữa chúng trong quá trình phát triển phần mềm Trên thế giới, có nhiều mô hình SLC khác nhau, trong đó một số mô hình được ứng dụng phổ biến.
Các mô hình một phiên bản (Single-version models)
Mô hình Waterfall (Waterfall model)
Các mô hình nhiều phiên bản (Multi-version models)
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)
3.1 Mô hình Thác nước (Waterfall)
Mô hình phát triển phần mềm bao gồm các giai đoạn xử lý nối tiếp nhau, bắt đầu với giai đoạn phân tích yêu cầu và tài liệu đặc tả Giai đoạn này xác định những yêu cầu chức năng và phi chức năng của hệ thống, đòi hỏi sự tham gia tích cực từ phía khách hàng Kết quả của giai đoạn này là tài liệu "Bản đặc tả yêu cầu phần mềm" (SRS), chứa tập hợp các yêu cầu đã được duyệt và nghiệm thu bởi những người có trách nhiệm trong dự án SRS đóng vai trò quan trọng, là nền tảng cho các hoạt động tiếp theo trong suốt quá trình phát triển dự án.
Phân tích hệ thống và thiết kế (System Analysis and Design): là giai đoạn định ra
Để hệ thống phần mềm đáp ứng các yêu cầu của khách hàng trong tài liệu SRS, cần xác định rõ cách thức thực hiện những yêu cầu này Đây chính là cầu nối giữa các yêu cầu và mã nguồn được phát triển để thỏa mãn những yêu cầu đó.
Giai đoạn hiện thực và kiểm thử từng thành phần, hay còn gọi là Coding và Unit Test, là bước quan trọng trong quy trình phát triển phần mềm, thể hiện cách thức thực hiện được nêu ra trong giai đoạn phân tích hệ thống và thiết kế.
Kiểm thử là giai đoạn quan trọng trong quy trình phát triển phần mềm, bao gồm kiểm thử mã, kiểm thử tích hợp và kiểm thử toàn hệ thống Nghiệm thu, với sự tham gia của khách hàng, là bước cuối cùng nhằm xác định hệ thống có đáp ứng yêu cầu hay không Sau đó, giai đoạn cài đặt và bảo trì diễn ra, bao gồm việc cài đặt, cấu hình và huấn luyện khách hàng Giai đoạn này cũng tập trung vào việc sửa lỗi phần mềm và phát triển các thay đổi theo yêu cầu của khách hàng, bao gồm sửa đổi, thêm hoặc bớt chức năng của hệ thống.
Trong quá trình phát triển, việc nhận ra sai sót thường chỉ xảy ra ở các giai đoạn sau, buộc chúng ta phải quay lại và sửa chữa những lỗi đã mắc phải ở giai đoạn trước Điều này phản ánh mô hình waterfall dạng lặp (Iterative Waterfall), như được minh họa trong Hình 1.
Trong mô hình Waterfall, kiểm thử được thực hiện trong một giai đoạn riêng biệt, trong khi mô hình chữ V chia quy trình thành hai nhóm giai đoạn phát triển và kiểm thử tương ứng 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ư minh họa trong Hình 2.
Tinh thần chủ đạo của mô hình V là thực hiện các hoạt động kiểm thử song song với các hoạt động phát triển ngay từ đầu chu trình Cụ thể, việc lập kế hoạch kiểm thử toàn hệ thống có thể được tiến hành đồng thời với các hoạt động phân tích và thiết kế hệ thống.
Mô hình mẫu (prototype) được minh họa trong Hình 3, bắt đầu bằng quy trình thu thập yêu cầu với sự tham gia của đại diện từ cả phía phát triển và khách hàng Mục tiêu của giai đoạn này là xác định mục tiêu tổng thể cho hệ thống phần mềm, đồng thời ghi nhận tất cả các yêu cầu khả thi và phác thảo các nhóm yêu cầu cần làm rõ hơn.
Sau khi hoàn thành thiết kế nhanh, việc tạo prototype giúp khách hàng hình dung và đánh giá yêu cầu của toàn hệ thống phần mềm Điều này không chỉ giúp tinh chỉnh yêu cầu mà còn giúp đội ngũ phát triển hiểu rõ hơn về những gì cần phát triển Giai đoạn làm prototype có thể dẫn đến một chu trình phát triển theo mô hình waterfall hoặc mô hình khác.
Prototype thường được tạo ra nhanh chóng trong thời gian ngắn và không sử dụng cùng môi trường hay công cụ phát triển như giai đoạn xây dựng phần mềm thực tế sau này Mục tiêu của prototype không phải là tái sử dụng cho giai đoạn phát triển tiếp theo.
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
Mô hình tiến hóa cho thấy rằng một số thành phần của hệ thống phần mềm có thể được phát triển ngay từ giai đoạn phân tích yêu cầu và thiết kế.
Hình 1 5: Mô hình tiến hóa
3.5 Mô hình lặp và tăng dần
Mô hình lặp và tăng dần có lúc đƣợc hiểu là một Tuy nhiên, trong bài viết này, ta có thể phân biệt ít nhiều sự khác biệt
Hai mô hình này đều dựa trên tinh thần của mô hình tiến hóa, với mục tiêu cung cấp một phần hệ thống cho khách hàng sử dụng trong môi trường sản xuất thực tế mà không cần chờ hoàn thành toàn bộ hệ thống Khác với các phiên bản mẫu hay trung gian trong mô hình mẫu hay tiến hóa, mỗi phiên bản đều phải trải qua quy trình đầy đủ từ phân tích yêu cầu, thiết kế, hiện thực đến kiểm nghiệm, tạo thành các chu trình con Các chu trình con này thường áp dụng mô hình waterfall, như minh họa trong Hình 5.
Mục tiêu của phiên bản đầu tiên là phát triển phần lõi và các chức năng quan trọng Sau mỗi lần triển khai phiên bản, kết quả đánh giá sẽ được thu thập và sử dụng để lập kế hoạch cho chu trình phát triển của phiên bản tiếp theo.
Những thay đổi cho phiên bản trước đó nhằm đáp ứng nhu cầu khách hàng tốt hơn
Có thể thêm những chức năng hoặc đặc điểm bổ sung
Sự khác biệt giữa hai mô hình tăng dần và lặp có thể được hiểu đơn giản là mô hình tăng dần phát triển sản phẩm qua từng giai đoạn, trong khi mô hình lặp cho phép hoàn thiện sản phẩm qua nhiều chu trình nhỏ hơn.
Mô hình tăng dần (Incremental): thêm chức năng vào sản phẩm (xem minh hoạ Hình6)
Mô hình lặp (Iterative): thay đổi sản phẩm (xem minh họa Hình 6)
Một SEP có thể kết hợp cả hai mô hình lặp lẫn tăng dần, chẳng hạn RUP (Rational Unified-Process)
Hình 1 6: Mô hình phát triển
3.6 Mô hình phát triển nhanh
Chương này mô tả chi tiết 18 quy trình then chốt, là xương sống của mô hình CMM, tương ứng với 5 mức độ tăng trưởng Bài viết cũng nêu rõ các hành động cần thiết để tổ chức tuân thủ, từ đó có thể nâng cao mức trưởng thành của mình.
Chương này phân tích thực trạng áp dụng mô hình SW-CMM tại Việt Nam, đồng thời chia sẻ những kinh nghiệm và đánh giá về hiệu quả của nó Bên cạnh đó, bài viết cũng đề xuất các giải pháp nhằm tối ưu hóa việc triển khai CMM trong các tổ chức, giúp nâng cao chất lượng và hiệu suất trong phát triển phần mềm.
