CHƯƠNG 3 CÁC MÔ HÌNH VÒNG ĐỜI PHẦN MỀM
3.3. MÔ HÌNH BẢN MẪU (RAPID PROTOTYPING MODEL)
MODEL)
Mô hình bản mẫu thực chất cũng là mô hình thác đổ, nhưng phần xác định yêu cầu được thay bằng bản mẫu. Mô hình này có thể biểu diễn bởi sơ đồ sau:
Hình 3.3. Mô hình bản mẫu (rapid prototyping model)
Cũng như mô hình thác đổ, các pha từ bản mẫu đến thiết kế đều có kiểm tra (verify), các pha cài đặt và tích hợp có kiểm thử (test).
Thông thường khách hàng đã xác định được một tập các mục tiêu tổng quát cho phần mềm, nhưng còn chưa nhận diện được đầu vào, đầu ra, những cái cần xử lý. Trong các trường hợp khác người phát triển có thể không chắc về tính hiệu quả của thuật toán, việc thích nghi hệ điều hành hay dạng màn hình giao diện cần có. Trong trường hợp này và nhiều trường hợp khác, cách làm bản mẫu có thể đưa ra cách tiếp cận tốt nhất.
Để làm bản mẫu, đầu tiên người ta thu thập yêu cầu khách hàng. Người phát triển và khách hàng cùng ngồi lại với nhau để xác định các mục tiêu tổng thể cho phần mềm, xác định xem yêu cầu nào đã rõ ràng, yêu cầu nào còn phải xác định thêm. Tiếp theo là việc "thiết kế nhanh". Thiết kế nhanh chỉ tập trung vào việc biểu diễn các khía cạnh của phần mềm thấy được đối với người dùng, ví dụ màn hình nhập dữ liệu, các chức năng tìm kiếm, truy xuất thông tin, các báo cáo. Người phát triển có thể kết hợp để thử nghiệm một thuật toán. Tuy nhiên mục đích chính là thể hiện được các yêu cầu của khách hàng trong phần mềm mà chưa để ý đến tính tối ưu, tốc độ, sự hợp lý... Thiết kế nhanh dẫn tới việc xây dựng một bản mẫu. Bản mẫu được giới thiệu với khách hàng và có thể để họ dùng thử và đánh giá, góp ý kiến. Trên cơ sở ý kiến khách, hàng người phát triển làm mịn dần bản mẫu cho đến khi khách hàng thấy vừa ý (chủ yếu là cái vào, cái ra, giao diện...). Căn cứ vào bản mẫu người phát triển cũng hiểu rõ hơn yêu cầu khách hàng, những yêu cầu về cấu hình, về các thuật toán, cấu trúc dữ liệu, ngôn ngữ lập trình phù hợp...
Hình 3.4. Mô thức làm bản mẫu
Một câu hỏi đặt ra là: bản mẫu được hiệu chỉnh cho đến khi khách hàng vừa ý, vậy có nên sử dụng ngay bản mẫu này hoặc hoàn thiện thêm để thành bản chính chuyển giao cho khách hàng không?
Về vấn đề này Brook đã nêu câu trả lời như sau:
Trong hầu hết các dự án, hệ thống đầu tiên hiếm khi sử dụng được. Nó có thể là quá chậm, quá lớn, cồng kềnh trong sử dụng hay tất cả những nhược điểm này. Không có cách nào khác là bắt đầu lại, đau đớn nhưng tinh khôn hơn, và xây dựng lại một phiên bản trong đó những vấn đề này đã được giải quyết.
Một cách lý tưởng, bản mẫu chỉ được xem như một cơ chế để xác định các yêu cầu của phần mềm. Khách hàng thường không biết được chất lượng thực sự của bản mẫu. Họ không biết được rằng trong khi xô đẩy để cho bản mẫu thể hiện được những yêu cầu khách hàng thì người ta không để ý đến chất lượng tổng thể hay tính bảo trì lâu dài của phần mềm. Khi được thông báo lại là sản phẩm được xây dựng lại để nó đạt tới mức độ chất lượng cao thì khách hàng thường kêu trời và đòi hỏi rằng "phải ít sửa chữa". Cách tốt nhất là ngay từ đầu nên xác định với khách hàng là bản mẫu chỉ sử dụng để xác định đúng yêu cầu khách hàng mà thôi.
So sánh mô hình thác đổ và mô hình bản mẫu
Trong mô hình thác đổ, mục đích của pha xác định yêu cầu là làm sao nắm bắt được những yêu cầu của khách hàng. Tuy nhiên việc này thường gặp khó khăn do khách hàng đôi khi không diễn đạt được chính xác yêu cầu của mình và có thể người phát triển đôi khi hiểu sai ý của khách hàng. Việc sử dụng bản mẫu trong pha xác định yêu cầu sẽ khắc phục được phần nào tình trạng này. Khách hàng dễ kiểm tra lại các yêu cầu của mình qua việc chạy thử các chức năng của phần mềm bản mẫu. Thực chất thì mô
hình bản mẫu cũng là mô hình thác đổ nhưng kỹ thuật khảo sát được sử dụng là bản mẫu. Việc sử dụng bản mẫu còn có điểm lợi là giúp các nhà phát triển có cơ hội áp dụng thử và đánh giá những công nghệ và kỹ thuật mới và có thể giảm thiểu những rủi ro khi sử dụng những công nghệ mới này.