MÔ HÌNH TĂNG DẦN (INCREMENTAL MODEL)

Một phần của tài liệu QUY TRÌNH LÀM CÔNG NGHỆ PHẦN MỀM - software engineering (Trang 28)

CHƯƠNG 3 CÁC MÔ HÌNH VÒNG ĐỜI PHẦN MỀM

3.4. MÔ HÌNH TĂNG DẦN (INCREMENTAL MODEL)

Phần mềm được xây dựng từng bước, cũng như xây một ngôi nhà vậy. Nếu như khi xây dựng ngôi nhà có lúc người ta phải phá đi xây lại một bức tường không vừa ý thì khi làm phần mềm chúng ta cũng có thể sửa đổi thậm chí bỏ đi những module chương trình không phù hợp...Một phần mềm ra đời, được đưa vào sử dụng. Trong quá trình sử dụng ngoài việc phát hiện và sửa chữa sai sót, người ta thấy cần nâng cấp chất lượng bằng cách cải tiến một vài thuật toán, thêm một số chức năng... Ví dụ như khi làm phần mềm soạn thảo văn bản chẳng hạn. Phiên bản đầu có thể chưa có chức năng kiểm tra chính tả, chưa có chức năng chèn hình ảnh...Người ta nâng cấp phiên bản này bằng cách bổ sung các chức năng này. Sau khi hoàn thành công việc này người ta lại thấy nên thêm chức năng vẽ đồ thị, thêm khả năng tính toán trong bảng. Mỗi lần nâng cấp như vậy người ta lại dựa trên nền tảng phần mềm đã có và xem xét sửa đổi lại tài liệu các pha.

Từ nhận xét rằng phần mềm có thể được xây dựng từng bước đã đưa đến việc ra đời một mô hình mới là mô hình tăng dần.

Trong mô hình tăng dần, người ta xem phần mềm bao gồm nhiều thành phần (build) tương đối độc lập nhau. Với hệ điều hành chẳng hạn, đó là thành phần scheduler, thành phần file management system,.. Mỗi thành phần như vậy được coi như một phần mềm nhỏ, được thiết kế, lập trình, kiểm thử và đưa cho khách hàng sử dụng theo mô hình thác đổ rồi kết hợp dần thành phần mềm hoàn chỉnh thỏa mãn tất cả các yêu cầu của khách hàng. Ban đầu người ta chưa chú ý đến toàn bộ các yêu cầu của phần mềm mà chỉ chú ý đến những nét đặc trưng nhất và xây dựng phiên bản đầu tiên của phần mềm bao gồm các đặc trưng này rồi đưa cho khách hàng sử dụng. Chương trình được hiệu chỉnh theo ý kiến phản hồi của khách hàng. Tiếp theo người ta lại xây dựng phần mềm thứ hai thỏa mãn các đặc trưng quan trọng thứ hai và lại đưa cho khách hàng sử dụng và có ý kiến. Phần mềm thứ hai này sau khi hiệu chỉnh lại được tích hợp vào phần mềm đầu tiên thành một phần mềm lớn hơn. Phần mềm tích hợp này lại được kiểm thử để bảo đảm việc ghép nối thành công và chương trình chạy tốt. Cứ như vậy, thay vì xây dựng phần mềm hoàn chỉnh, người ta xây dựng các phần mềm con rồi tích hợp dần cho tới khi đạt được sản phẩm mong muốn. Sơ đồ sau mô tả mô hình tăng dần.

Hình 3.5. Mô hình tăng dần (incremental model)

Nhận xét mô hình tăng dần

Với mô hình thác đổ hoặc bản mẫu, sản phẩm được chuyển giao cho khách hàng chính là phiên bản hoàn chỉnh thỏa mãn tất cả các yêu cầu của khách hàng và có thể sử dụng ngay. Thời gian hoàn thành

phần mềm được quy định trong hợp đồng và có thể sớm hoặc muộn hơn. Với mô hình tăng dần thì phần mềm được chia ra nhiều phần (thường là từ 5 đến 25 phần). Phần đầu tiên chứa đựng những đặc trưng quan trọng nhất được nhanh chóng xây dựng và chuyển giao cho khách hàng sử dụng. Thời gian hoàn thành phần đầu tiên này thường rất ngắn so với thời gian xây dựng toàn bộ phần mềm hoàn chỉnh. Như vậy khách hàng được sử dụng sản phẩm trong thời gian ngắn nhất và họ có thể được hưởng lợi từ việc sử dụng phần mềm. Khi mỗi phần sau được hoàn thành và được tích hợp thì họ được sử dụng ngay. Như vậy họ được làm quen từng bước với sản phẩm và sẽ ít bỡ ngỡ khi sản phẩm chứa đựng những công nghệ mới. Nhờ theo sát từng bước phát triển của phần mềm mà khách hàng có thể có những ý kiến xác đáng, giúp cho nhà phát triển đi đúng hướng và sản phẩm cuối cùng sẽ thỏa mãn được các yêu cầu đặt ra, thậm chí qua việc sử dụng một số phần đầu, khách hàng nhận thấy rằng không nên phát triển tiếp vì sẽ không mang lại lợi ích kinh tế.

Khó khăn trong việc sử dụng mô hình tăng dần chính là sự tích hợp phần mới phát triển với phần chương trình đã có. Thiết kế của mô hình này do vậy phải có tính mở và tính mềm dẻo để thích nghi với việc mở rộng dần. Ta có thể nhận thấy rằng, trong mô hình tăng dần không có sự khác biệt giữa sự phát triển phần mềm và bảo trì cập nhật (nâng cao). Nếu vận dụng không hợp lý, mô hình này có thể suy thoái thành mô hình xây dựng-và-hiệu chỉnh. Sự điều khiển toàn bộ quy trình phát triển phần mềm có thể bị mất và sản phẩm nhận được thay vì có tính mở lại là nỗi kinh hoàng cho những người bảo trì. Để tránh được điều này, người phát triển ngay từ đầu phải có cách nhìn toàn cục về sản phẩm, phải đưa ra thiết kế tổng thể của sản phẩm và sự phân chia các thành phần để phát triển sau này cũng phải trên cơ sở thiết kế toàn cục đó. Như sơ đồ 3.5. chỉ ra, các pha yêu cầu, đặc tả và thiết kế kiến trúc phải được thực hiện trước khi các thành phần nhỏ hơn được bắt đầu xây dựng. Nếu không có những nhà chuyên môn trình độ cao thì sản phẩm phát triển theo mô hình này có thể trở thành sản phẩm kém chất lượng.

Khi nào nên sử dụng mô hình tăng dần?

Nếu phần mềm có thể phân chia thành những thành phần tương đối độc lập nhau thì có thể áp dụng mô hình này. Với những bài toán như xây dựng phần mềm quản lý dịch vụ bay ở các công ty hàng không, chương trình quản lý tín dụng ở ngân hàng chẳng hạn, tính liên kết giữa các thành phần khá cao nên không nên áp dụng mô hình này.

Một phần của tài liệu QUY TRÌNH LÀM CÔNG NGHỆ PHẦN MỀM - software engineering (Trang 28)

Tải bản đầy đủ (DOCX)

(49 trang)
w