Đang tải... (xem toàn văn)
Bài giảng Phân tích yêu cầu phần mềm - Lecture 10: Yêu cầu phi chức năng Non-Functional Requirements (NFRs) cung cấp cho người học các kiến thức: Tiền khái niệm, yêu cầu phi chức năng (NFRs) là gì, tiếp cận hướng sản phẩm (Product-oriented) với NFRs, tiếp cận hướng tiến trình (Process-oriented) với NFRs. Mời các bạn cùng tham khảo nội dung chi tiết.
Phân tích yêu cầu phần mềm Lecture 10: Yêu cầu phi chức Non-Functional Requirements (NFRs) Tiền khái niệm: Các dạng ký pháp mơ hình hóa mà biết Yêu cầu phi chức (NFRs) ? Các hệ số chất lượng, tiêu chuẩn thiết kế; độ đo Ví dụ NFRs Tiếp cận hướng sản phẩm (Product-oriented) với NFRs Tạo đặc tả hệ số chất lượng Ví dụ: Sự tin cậy Tiếp cận hướng tiến trình (Process-oriented) với NFRs Phân tích mục tiêu linh động (softgoal) cho thỏa hiệp thiết kế Phân tích yêu cầu phần mềm Các dạng biểu đồ UML… Use Cases Biểu đồ trình tự Khía cạnh từ người dùng Kịch cụ thể Liệt kê trực quan giao tiếp người dùng hệ thống Trình tự việc trao đổi thông báo chức tổng quan yêu cầu Biểu đồ hoạt động Tiến trình hoạt động đồng thời đồng phụ thuộc công việc Biểu đồ chuyển trạng thái Các đáp ứng theo kiện đối tượng, mơ hình hóa hành vi lớp giao diện Biểu đồ lớp Cấu trúc thông tin quan hệ lớp, giao diện, hợp tác Thể mặt tĩnh hệ thống Phân tích u cầu phần mềm …và biểu đồ khơng thuộc - UML: Mơ hình mục tiêu (Goal Models) Nắm bắt mục tiêu chiến lược đối tác Tốt cho việc khảo sát câu hỏi ‘how’ ‘why’ với đối tác Tốt để phân tích thỏa hiệp trade-offs, đặc biệt chọn lựa thiết kế Mơ hình Cây bắt lỗi (Fault Tree Models) - ví dụ kỹ thuật phân tích rủi ro Nắm bắt lỗi tiềm ẩn hệ thống nguồn gốc nguyên nhân Tốt cho phân tích rủi ro, đặc biệt ứng dụng với tiêu chuẩn an tồn Mơ hình chiến lược phụ thuộc (Strategic Dependency Models (i*)) Nắm bắt quan hệ tác nhân tổ chức Hữu ích cho quan hệ mục tiêu đối tác với tổ chức thiết lập chúng Tốt cho việc thấu hiểu tổ chức thay đổi Mơ hình quan hệ - thực thể (Enntity-Relationship Models) Nắm bắt quan hệ cấu trúc thông tin lưu trữ Tốt cho việc hiểu ràng buộc giả thiết phạm vi chủ thể Lập tảng tốt cho thiết kế CSDL Các kiểu bảng lớp (Class Tables), bảng kiện (Event Tables) bảng điều kiện (Condition Tables (SCR)) Nắm bắt hành vi động hệ thống phản ứng thực tế Tốt cho việc biểu diễn chức kết hợp từ inputs đến outputs Tốt cho việc tạo mô hình hành vi xác, suy diễn tự động Phân tích yêu cầu phần mềm Yêu cầu phi chức gì? Chức vs Phi chức Các yêu cầu chức mô tả hệ thống làm Các chức nắm bắt use cases Các hành vi phân tích việc vẽ biểu đồ trình tự, biểu đồ trạng thái, etc … khả lần vết để giải vấn đề rắc rối chương trình Các yêu cầu phi chức ràng buộc tồn thể hệ thống phần mềm e.g chi phí phát triển, chi phí vận hành, khả thực thi, độ tin cậy, khả bảo trì, tính khả chuyển, tính thiết thực, etc Thường biết chất lượng phần mềm, “các khả năng” (“ilities”) Thường không cài đặt mô-đun chương trình Những trở ngại NFRs Khó để mơ hình Thường trạng thái khơng hình thức, mà: Thường mâu thuẫn, Khó thực suốt q trình phát triển Khó đánh giá khách hàng ưu tiên để phân phối Khó tạo tiêu chuẩn để đo lường chúng Chúng ta muốn ổn định chúng theo cách đo lường đáp ứng chúng Phân tích yêu cầu phần mềm Ví dụ NFRs Yêu cầu giao diện Giao diện hệ thống mơi trường nó? Giao diện người dùng “thân thiện” Giao diện hệ thống khác Yêu cầu thực thi Giới hạn thời gian / không gian Thời gian tải nạp, thời gian đáp ứng, kích thước liệu nhập khơng gian lưu trữ e.g ”hệ thống phải kiểm soát 1000 giao dịch giây" Độ tin cậy Tính sẵn dùng thành phần Sự nguyên vẹn thông tin dùng trì cung cấp cho hệ thống e.g "hệ thống phải có đình trệ hoạt động thángs" Tính bảo mật E.g Cho phép thơng tin lưu hành, phân quyền người dùng Khả chịu lỗi E.g Hệ thống cần lực tồn tại, chịu đựng cố tự nhiên, etc Yêu cầu vận hành Các ràng buộc vật lý (kích thước, trọng lượng), Mức kỹ & khả nhân Dễ bảo trì Các điều kiện mơi trường etc Yêu cầu chu trình sống “Future-proofing” Khả bảo trì Khả mở rộng Tính khả chuyển Thị trường mong đợi vòng đời sản phẩm Những giới hạn phát triển E.g giới hạn thời gian phát triển, Tài nguyên sẵn dùng Các chuẩn phương pháp etc Yêu cầu kinh tế e.g giới hạn nghiêm ngặt thời gian và/hoặc vốn dài hạn Phân tích yêu cầu phần mềm Tiếp cận NFRs Sản phẩm vs Tiến trình? Tiếp cận hướng sản phẩm (Product-oriented Approaches) Tập trung vào chất lượng hệ thống (hoặc phần mềm) Nắm bắt tiểu chuẩn thiết lập yêu cầu … đo lường chúng sản phẩm thiết kế Tiếp cận hướng tiến trình (process-oriented Approaches) Tập trung vào yêu cầu phi chức (NFRs) dùng tiến trình thiết kế Phân tích tương tác NFRs chọn lựa thiết kế … đưa định thiết kế phù hợp Định lượng (Quantitative) vs Định tính (Qualitative)? Tiếp cận định lượng Tìm thang đo thuộc tính chất lượng Tính tốn mức độ cho thiết kế đáp ứng với mục tiêu chất lượng Tiếp cận định tính Nghiên cứu dạng quan hệ mục tiêu chất lượng Lý thỏa hiệp (trade-offs), etc Phân tích yêu cầu phần mềm Chất lượng phần mềm Nghĩ đến đồ vật thông thường e.g Một ghế – bạn đo “chất lượng” nào? Chất lượng kết cấu? (e.g độ mối nối,…) Giá trị thẩm mỹ? (e.g tính lịch,…) Đáp ứng mục tiêu? (e.g thoải mái,…) Tất độ đo chất lượng có quan hệ Khơng có thang đo tuyệt đối Đơi nói A tốt B… … thường khó để nói tốt ! Đối với phần mềm : Chất lượng kết cấu? Phần mềm khơng chế tạo (mà phát triển) Giá trị thẩm mỹ? hầu hết phần mềm trực quan giá trị thẩm mỹ quan tâm bên lề Đáp ứng mục tiêu? Cần phải hiểu rõ mục tiêu Phân tích yêu cầu phần mềm Sự đáp ứng (Fitness) Source: Budgen, 1994, pp58-9 Chất lượng phần mềm đáp ứng với mục tiêu Nó có thực điều cần thực hiện? Nó có thực theo cách người dùng cần thực hiện? Nó có đủ tin cậy? Đủ nhanh? Đủ an tồn? Đủ bảo mật? Nó có khả thực hiện? Nó ln sẵn sàng người dùng cần đến nó? Nó thay đổi nhu cầu thay đổi? Chất lượng độ đo cho riêng phần mềm Nó đo lường quan hệ phần mềm lĩnh vực ứng dụng khơng thể đo lường điều trước bạn đặt phần mềm vào mơi trường nó… …và chất lượng khác môi trường khác nhau! Trong thiết kế, cần dự đoán phần mềm đáp ứng với mục tiêu tốt cần người dự đoán chất lượng tốt (người phân tích thiết kế) Trong phân tích yêu cầu, cần hiểu rõ việc đáp ứng với mục tiêu đo lường Mục tiêu dự định gì? Các yếu tố chất lượng quan trọng đối tác? Những yếu tố tổ chức nào? Phân tích yêu cầu phần mềm Các yêu tố vs Tiêu chuẩn Các yếu tố chất lượng Điều liên quan đến quan hệ khách hàng (customer-related) Ví dụ: hiệu năng, tính tồn vẹn, độ tin cậy, tính xác, khả chịu lỗi, tiện dụng, Tiêu chuẩn thiết kế Điều liên quan tới kỹ thuật (hướng phát triển) chẳng hạn quản lý bất thường, tính hồn thiện, tính ổn định, khả lưu vết, tính trực quan, Yếu tố chất lượng tiêu chuẩn thiết kế có liên quan: Mỗi yếu tố phụ thuộc vào số tiêu chuẩn liên quan: E.g Tính xác phụ thuộc vào tính hồn thiện, tính ổn định, khả lưu vết, E.g Tính khả thi phụ thuộc vào mơ-đun hóa, tính linh động tính đơn giản Có thể có số chuẩn kết hợp để giúp bạn… Trong q trình phân tích: Xác định quan hệ quan trọng yếu tố chất lượng Từ quan điểm khách hàng! Xác định tiêu chuẩn thiết kế mà yếu tố phụ thuộc Thiết lập độ đo lường yêu cầu Tiêu chuẩn thiết kế Boehm’s NFR list Độc lập thiết bị Source: See Blum, 1992, p176 Khả chuyển Tin cậy Đặc tính chung Hiệu Tự lưu trữ Chính xác Hồn thiện Thiết thực/tồn vẹn Ổn định Dễ giải trình Tiện ích Sẵn dùng Hiệu suất thiết bị Dể truy xuất Dễ kiểm thử Dễ giao tiếp Linh hoạt Khả bảo trì Dễ hiểu Có cấu trúc Cơ đọng Các yếu tố chất lượng Dễ sửa đổi Hợp lệ Có thể mở rộng 10 Tiêu chuẩn thiết kế Dễ vận hành McCall’s NFR list Source: See van Vliet 2000, pp111-3 Dễ huấn luyện Sẵn dùng Toàn vẹn Vận hành sản phẩm Hiệu Chính xác Các yếu tố chất lượng Dễ giao tiếp Dung lượng I/O Tốc độ I/O Quản lý truy xuất Kiểm soát truy xuất Lưu trữ hiệu Thực thi hiệu Khả lưu vết Hồn thiện Tin cậy Chính xác Khả chịu lỗi Dễ bảo trì Bảo dưỡng sản phẩm Nhất quán Đơn giản Dễ kiểm thử Cơ đọng Phương tiên hóa Linh động Tái sử dụng Chuyển giao sản phẩm Khả chuyển Liên vận hành Dễ mở rộng Tổng quát hóa Linh động Mơ-đun hóa Độc lập thiết bị Độc lập hệ thống s/w Giao tiếp tương đồng Dữ liệu tương đồng 11 Phân tích yêu cầu phần mềm Thiết lập độ đo yêu cầu Source: Budgen, 1994, pp60-1 Chúng ta phải đổi khái niệm không rõ ràng chất lượng thành độ đo lường Các yếu tố chất lượng (các khái niệm trừu tượng đặc tính chất lượng) Các ví dụ Độ tin cậy Tiêu chuẩn đo lường (định nghĩa số độ đo) Trung bình số lần gặp lỗi? Đếm số lần từ kết hiển thị thiết kế (hiện thực hóa độ đo) Thực đếm số lỗi giờ??? Độ phức tạp Thông tin truyền nhận thủ tục? Đếm số lần gọi thủ tục??? Dễ sử dụng Thời gian cần để học cách sử dụng? Số phút cần cho số thao tác người dùng??? 12 Phân tích yêu cầu phần mềm Ví dụ : Đo độ tin cậy Định nghĩa ví dụ: Khả hệ thống hành xử cách thống theo phương cách người dùng chấp nhận hệ thống vận hành bên mơi trường mà dự định thực Các thích: Độ tin cậy xác định dạng giá trị phần trăm (như, 99.999%) Điều mang ý nghĩa khác ứng dụng khác nhau: Mạng điện thoại: mạng tồn cục bị lỗi khơng nhiều hơn, trung bình khoảng 1hr năm, lỗi chuyển mạng cá nhân xuất thường xuyên nhiều Hệ thống kiểm tra bệnh nhân: hệ thống bị lỗi đến khoảng 1hr/year, trường hợp này, bác sĩ/ y tá báo động lỗi Lỗi thường xuyên phận cá thể khơng thể chấp nhận Tốt nhất, thực số việc sau: " Khơng có nhiều X lỗi 10KLOC (line of code) phát suốt q trình tích hợp kiểm thử; khơng có nhiều Y lỗi 10KLOC tồn hệ thống sau phân phối, theo tính tốn Monte Carlo dùng kỹ thuật tìm kiếm nhân lỗi phụ lục Z; hệ thống phải vận hành 99.9% 100% khả vận hành theo lịch suốt năm vận hành " 13 Phân tích yêu cầu phần mềm Đo độ tin cậy… Ví dụ - yêu cầu độ tin cậy: “Phần mềm có khơng nhiều X lỗi ngàn dịng mã lệnh” Nhưng đo lỗi thời điểm phân phối sản phẩm không? Dùng trình gỡ lỗi (Debuging) Đo lường hiệu tiến trình kiểm thử Một số nhân lỗi nêu cho hệ thống phần mềm sau thực kiểm thử sửa lỗi khơng tồn Ước lượng số lỗi hệ thống = # nhân lỗi x # lỗi phát # nhân lỗi phát .NHƯNG, tất lỗi quan trọng nhau! 14 Phân tích u cầu phần mềm Mơ hình ví dụ: Gia tăng độ tin cậy Source: Adapted from Pfleeger 1998, p359 Mơ hình kiểm thử Motorola’s Zero-failure Dự đốn kiểm thử cần thiết thiết lập mục tiêu độ tin cậy cho trước Mơ hình sở: số kinh nghiệm (empirical constants) failures = ae-b(t) thời gian kiểm thử (testing time) Tiến trình đánh giá độ tin cậy Inputs cần thiết: fd = mật độ lỗi sau (e.g 0.03 lỗi 1000 LOC) tf = tổng số lỗi kiểm thử quan sát đến lúc th = tổng số kiểm thử đến lỗi cuối Tính số kiểm thử cần thiết dùng thêm: ln(fd/(0.5 + fd)) x th ln((0.5 + fd)/(tf + fd)) Kết cho biết số lỗi phát sinh thêm mà không cần thực số kiểm thử cần thiết để thiết lập mật độ lỗi mong muốn lỗi xuất vào thời gian này, bạn dừng đồng hồ tính lại Chú ý: mơ hình bỏ qua lịch sử vận hành hệ thống! 15 Phân tích yêu cầu phần mềm Thiết lập độ đo yêu cầu Xác định ‘tiêu chuẩn đáp ứng’ cho yêu cầu Đặt ‘tiêu chuẩn đáp ứng’ bên cạnh yêu cầu E.g Đối với phần mềm ATM Yêu cầu: “Phần mềm phải trực quan rõ ràng (khơng cần giải thích thêm)” Tiêu chuẩn đáp ứng: “95% khách hàng có ngân hàng rút tiền gửi séc vòng phút sử dụng sản phẩm lần đầu tiên” Chọn tiêu chuẩn đáp ứng tốt Các đối tác thường mô tả điều Các tiêu chuẩn không rõ ràng: Những thứ dễ dàng đo thứ mà đối tác mong muốn Các độ đo chuẩn khơng phải thứ mà đối tác mong muốn Làm việc với đối tác để tìm tiêu chuẩn đáp ứng tốt Sự thay Đôi khi, chất lượng đo lường trực tiếp Tìm định danh thay thế: E.g “Một vài liệu nhập bị lỗi” cho Tính dễ sử dụng E.g “Liên kết khơng chặt chẽ” cho Tính dễ bảo trì 16 Phân tích u cầu phần mềm Sử dụng phân tích softgoal Source: Chung, Nixon, Yu & Mylopoulos, 1999 Các dạng goals: Non-functional Requirement Satisficing Technique e.g lựa chọn thiết kế Claim Hỗ trợ/ giải thích lựa chọn Các kiểu cấu tạo Liên kết AND (hợp thành) Liên kết OR (lựa chọn) Liên kết Sup (hỗ trợ) Liên kết Sub (subgoal cần thiết) Đánh giá mục tiêu Thỏa (Satisficed) Không chấp nhận (Denied) Mâu thuẫn (Conflicting) Không xác định (Undetermined) 17 Phân tích yêu cầu phần mềm Danh mục NFR Source: Cysneiros & Yu, 2004 Danh mục định nghĩa sẵn phân tích NFR Cung cấp kiến thức để kiểm tra độ bao phủ NFR Cung cấp cơng cụ làm rõ NFRs Ví dụ: 18 ... hành hệ thống! 15 Phân tích yêu cầu phần mềm Thiết lập độ đo yêu cầu Xác định ‘tiêu chuẩn đáp ứng’ cho yêu cầu Đặt ‘tiêu chuẩn đáp ứng’ bên cạnh yêu cầu E.g Đối với phần mềm ATM Yêu cầu: “Phần mềm... Linh động M? ?-? ?un hóa Độc lập thiết bị Độc lập hệ thống s/w Giao tiếp tương đồng Dữ liệu tương đồng 11 Phân tích yêu cầu phần mềm Thiết lập độ đo yêu cầu Source: Budgen, 1994, pp6 0-1 Chúng ta... nhân lỗi phụ lục Z; hệ thống phải vận hành 99.9% 100 % khả vận hành theo lịch suốt năm vận hành " 13 Phân tích yêu cầu phần mềm Đo độ tin cậy… Ví dụ - yêu cầu độ tin cậy: “Phần mềm có khơng nhiều