Phân tích yêu cầu phần mềm Lecture 12: Kiểm tra Kiểm chứng (Verification and Validation) Khái niệm: Định nghĩa V&V Các kỹ thuật kiểm chứng Lập mẫu (Prototyping) Phân tích mơ hình (Model Analysis) (e.g Model Checking) Kiểm duyệt (Inspection) Các kỹ thuật kiểm tra (Verification Techniques) Thực lưu vết đặc tả (Specifications Traceable) (Bài 19) Kiểm thử (Testing) Kiểm duyệt mã lệnh (Code Inspection) Phân tích mã lệnh (Code analysis) V&V độc lập Phân tích yêu cầu phần mềm Verification and Validation “Chúng ta xây dựng hệ thống ?” Khai báo vấn đề thực nắm bắt vấn đề thực tế? Hệ thống đáp ứng nhu cầu tất đối tác? “Chúng ta xây dựng hệ thống đúng?” Thiết kế đáp ứng đặc tả? Cài đặc đáp ứng đặc tả? Hệ thống phân phối thực điều mà phải làm? Các mơ hình u cầu thống với mơ hình khác? Verificatio n Kiểm tra (Verification) Problem Statement Validatio n Problem Situation Kiểm chứng (Validation) Implementation Statement System Phân tích yêu cầu phần mềm Khái niệm: Tiêu chuẩnV&V Application Domain Source: Adapted from Jackson, 1995, p170-171 Machine Domain Sự khác biệt: Domain Properties: điều luôn lĩnh vực ứng dụng Requirements: điều mong lĩnh vực ứng dụng Specification: mô tả hành vi mà chương trình cần thực để đáp ứng với yêu cầu Hai tiêu chuẩn kiểm tra (verification) Chương trình (Program) thực máy tính (Computer) cụ thể đáp ứng với đặc tả (Specification) Đặc tả (Specification) cho thuộc tính lĩnh vực (Domain properties) thỏa mãn yêu cầu (Requirements) Hai tiêu chuẩn kiểm chứng (validation) Chúng ta xem xét (và hiểu) tất yêu cầu (Requirements) quan trọng? Chúng ta xem xét (và hiểu) tất thuộc tính lĩnh vực(Domain properties) liên quan Phân tích yêu cầu phần mềm Ví dụ V&V Ví dụ Requirement R: “Phản lực xảy máy bay chạy đường băng” Domain Properties D: Xung lực bánh xe xảy bánh xe bật Các bánh xe bật chạy đường băng Specification S: Phản lực xảy có xung lực bánh xe Kiểm tra Phần mềm cho máy bay, P, thực thi máy tính buồng lái máy bay, C, có hồn tồn xác đặc tả, S? S, ngữ cảnh giả thuyết D, có đáp ứng R? Kiểm chứng Giả thuyết chúng ta, D, lĩnh vực có thật xác? Có thiếu sót khơng? u cầu, R, có thật cần thiết? Có thiếu sót khơng? Phân tích yêu cầu phần mềm Chu trình điều tra Lưu ý : Tương tự tiến trình khảo sát khoa học : Kiến thức có trước (e.g Phản hồi từ khách hàng) Giả thiết ban đầu Quan sát (Điều sai hệ thống tại?) Can thiệp (Thay hệ thống cũ) Thực thử nghiệm (Thao tác thơng số) Tìm kiếm bất thường – Cái khơng thể giải thích lý thuyết tại? Thiết kế thử nghiệm để kiểm thử lý thuyết Thiết kế (Sáng chế hệ thống tốt hơn) Các mơ hình u cầu lý thuyết thực tế; Thiết kế kiểm thử lý thuyết Mơ hình (Mơ tả/Giải thích vấn đề quan sát) Tạo ra/ Tinh chế lý thuyết tốt Phân tích yêu cầu phần mềm Chu trình điều tra nhanh Kiến thức có trước (e.g Phản hồi từ khách hàng) Quan sát (Cái sai hệ thống tại?) Kiểm tra đặc tính mơ hình Cho người dùng thử Mơ hình ((Mơ tả/Giải thích vấn đề) Phân tích mơ hình Lập mẫu Phân tích u cầu phần mềm Lập mẫu “Một mẫu phần mềm kiến trúc cài đặt cụ thể trước để khách hàng, người dùng nhà phát triển hiểu rõ thêm vấn đề hay giải pháp nó.” [Davis 1990] “Lập mẫu tiến trình xây dựng mơ hình làm việc hệ thống”[Agresti 1986] Hướng tiếp cận lập mẫu Bản mẫu trình diễn Dùng để chứng minh khái niệm; giải thích đặc tính thiết kế; etc Giải thích, minh họa thơng báo – sau bỏ Bản mẫu thăm dò Dùng để xác định vấn đề, thu thập nhu cầu, làm rõ mục tiêu, so sánh lựa chọn thiết kế Khơng hình thức, khơng cấu trúc bỏ Bản mẫu thử nghiệm Khai thác đặc tính kỹ thuật; kiểm tra thích hợp kỹ thuật Thông thường không bao gồm người dùng/khách hàng Bản mẫu tiến triển (e.g “bản mẫu vận hành”, “hệ thống lái máy bay”): Được phát triển thấy tiến trình tiếp diễn tương thích với hệ thống “Bản mẫu (Prototype)” phân phối sớm, để tiếp tục cải tiến Phân tích yêu cầu phần mềm Dùng lần hay tiếp tục phát triển ? Bản mẫu dùng thử Mục đích: để nghiên cứu nhiều vấn đề giải pháp nó… bỏ thu kiến thức mong muốn Cách dùng: sớm trễ Hướng tiếp cận: theo chiều ngang (horizontal) – thiết kế tầng (e.g UI) “quick and dirty” Thuận lợi: Phương tiên nghiên cứu cho hội tụ tốt Phân phối sớm → kiểm thử sớm → chi phí thấp Thành cơng bị thất bại! Bất lợi: Nổ lực bị lãng phí yêu cầu thay đổi cách nhanh chóng Thường dùng thay cách hợp lý tài liệu yêu cầu Có thể mong muốn khách hàng cao Có thể phát triển thành sản phảm cuối Bản mẫu tiến hóa Mục đích để nghiên cứu nhiều vấn đề giải pháp nó… …và giảm rủi ro cách xây dựng sớm phận Cách dùng: phát triển dần; làm tiến hóa Hướng tiếp cận: theo chiều dọc (vertical) – cài đặt phần tất tầng; thiết kế để mở rộng/thích ứng Thuận lợi: Các yêu cầu không thiết cố định Trả phiên sau phát lỗi Linh động(?) Bất lợi: Có thể kết thúc với hệ thống phức tạp, khơng cấu trúc – khó để bảo trì Kiến trúc lựa chọn sớm Các giải pháp tối ưu khơng bảo đảm Thiếu kiểm soát phương hướng Brooks: “Kế hoạch để bỏ mẫu – luôn làm” Phân tích yêu cầu phần mềm Phân tích mơ hình (Model Analysis) Kiểm tra: “Mơ hình có định dạng chuẩn?” Các thành phần mơ hình thống với khác? Kiểm chứng: Dựng hoạt cảnh mơ hình ví dụ nhỏ Các thay đổi hình thức Các câu hỏi ‘Cái xảy …?’ (‘What if’): nguyên nhân hậu yêu cầu ngoại lệ; nguyên nhân tác động thay đổi “hệ thống có thực sau ” Khảo sát trạng thái E.g sử dụng kiểm tra mơ hình để phát đáp ứng số đặc tính Phân tích yêu cầu phần mềm Cơ sở kiểm tra chéo với UML Biểu đồ Use Case Mỗi use case có người dùng? Mỗi người dùng có use case? Biểu đồ chuyển trạng (StateChart) Mỗi biểu đồ chuyển trạng có nắm bắt (các trạng thái của) lớp khơng? Có tài liệu cho use case khơng? Sử dụng sơ đồ trình tự tương tự Biểu đồ lớp (Class Diagrams) Lớp có biểu đồ lớp khơng? Mỗi bước chuyển (transition) có kiện kích hoạt (trigger event) khơng? Có rõ ràng đối tượng khởi tạo kiện? Mỗi kiện có liệt kê phương thức thuộc lớp đối tượng sơ đồ lớp? Sơ đồ lớp có nắm bắt tất lớp đề cập đến sơ đồ khác khơng? Mỗi trạng thái có biểu diễn kết Mỗi lớp có phương pháp để lấy/đặt hợp phân biệt giá trị thuộc tính? thuộc tính khơng? Có rõ ràng kết hợp với giá trị Biểu đồ trình tự (Sequence Diagrams) Mỗi lớp có sơ đồ lớp khơng? Mỗi thơng điệp gửi khơng? Có quan hệ kết hợp lớp người gửi lớp người nhận biểu đồ lớp khơng? Có phương pháp gọi lớp gửi cho thông điệp gửi không? Có phương pháp gọi lớp nhận cho thơng điệp nhận khơng? thuộc tính? Tất thuộc tính biểu đồ lớp? Có phương pháp gọi biểu đồ lớp cho bước chuyển không? …một phương pháp gọi cập nhật giá trị thuộc tính cho trạng thái mới? …phương pháp gọi kiểm tra điều kiện bước chuyển? …phương pháp gọi thực hoạt động bước chuyển? 10 Phân tích yêu cầu phần mềm Reviews, Walkthroughs, Inspections… “Management reviews” E.g preliminary design review (PDR), critical design review (CDR), … Dùng để nêu chắn mà thiết kế báo hiệu Tham gia nhà quản trị nhà bảo trợ (khách hàng) Thường “dog-and-pony show” “Walkthroughs” Kỹ thuật người phát triển (thường khơng hình thức) Được sử dụng đội ngũ phát triển để cải tiến chất lượng sản phẩm Tập trung vào việc tìm kiếm khuyết điểm “(Fagan) Inspections” Một cơng cụ quản lý tiến trình (ln hình thức) Dùng để cải tiến chất lượng tiến trình phát triển Thu thập liệu lỗi để phân tích chất lượng tiến trình Viết output quan trọng Đóng vai trị việc huấn luyện đội ngũ kế thừa truyền tải kinh nghiệm Các định nghĩa khơng thống chung! Các thuật ngữ khác dùng: Formal Technical Reviews (FTRs) Formal Inspections “Cách thức” đa dạng: Khơng hình thức: Gặp gỡ (over coffee), Họp mặt nhóm thơng thường, etc Hình thức: Lập lịch hội thảo, Chuẩn bị thành viên tham dự, Xác định thời gian, Mô tả cách thức, Lập tài liệu kết 11 Phân tích yêu cầu phần mề Lợi ích kiểm duyệt hình thức (formal inspection) Source: Adapted from Blum, 1992, Freedman and Weinberg, 1990, & notes from Philip Johnson Formal inspection tác động tốt việc lập trình: Đối với lập trình ứng dụng: Hiệu kiểm thử Hầu hết chương trình reviewed thực xác lần So sánh: 10-50 lần thử kiểm tra/gặp lỗi Dữ liệu từ dự án lớn Giảm lỗi nguyên nhân : 5; (10 số báo cáo) Cải thiện hiệu : 14% đến 25% Phần trăm lỗi đươc phát kiểm duyệt: 58% đến 82% Giảm chi phí 50%-80% cho V&V (bao gồm chi phí kiểm duyệt) Hiệu thu nhập nhân viên: Tăng tinh thần, giảm thay đổi nhân Lập lịch biểu đánh giá tốt (nhiều kiến thức sơ lược khuyết điểm) Quản lý tốt việc nhận định lực nhân viên Các lợi ích ứng dụng vào kiểm duyệt yêu cầu Nhiều khảo sát theo lối kinh nghiệm phát tiến trình kiểm duyệt đa dạng Các kết hòa lẫn lợi ích liên quan tiến trình khác 12 Phân tích yêu cầu phần mềm Các vai trò (Roles) Source: Adapted from Blum, 1992, pp369-373 Formal Walkthrough Lãnh đạo Review Chủ trì họp Bảo đảm chuẩn bị Giữ tập trung review Báo cáo kết Người ghi chép Giữ vết kết công bố Reader Tổng kết mẫu sản phẩm mẫu suốt trình review Tác giả Người tham dự cách tích cực (e.g reader) Fagan Inspection Người điều tiết (Moderator) Phải lập trình viên thành thạo Cần huấn luyện đặc biệt Có thể đến từ dự án khác Người thiết kế Các lập trình viên – người phát sinh thiết kế thông qua kiểm duyệt Người viết code/cài đặt Các lập trình viên có trách nhiệm dịch từ thiết kế sang mã lệnh Người kiểm thử Người có trách nhiệm viết/thực thi tình kiểm thử Các Reviewers khác Cơng việc tìm viết báo cáo 13 Phân tích yêu cầu phần mềm Lập cấu trúc kiểm duyệt Checklist Dùng danh sách câu hỏi kiểm tra/vấn đề review cấu trúc vấn đề danh sách Walkthough Một người phải có mặt bước kiểm tra sản phẩm review cấu trúc sản phẩm Round Robin Mỗi reviewer vấn đề review cấu trúc đội review Tốc độ Review Mỗi reviewer có phút để xem xét lại vấn đề, sau chuyển sang cho người Tốt cho việc đánh giá khả hiểu thấu vấn đề! 14 Phân tích yêu cầu phần mềm Tại dùng kiểm duyệt? Sự kiểm duyệt hiệu Kiểm duyệt mã lệnh tốt việc kiểm thử để tìm khuyết điểm Đối với đặc tả (Specifications), kiểm duyệt có sẵn (bạn “kiểm thử” đặc tả!) Các khóa: Chuẩn bị: người kiểm duyệt thực riêng lẻ trước Tập hợp họp mặt: người kiểm duyệt họp lại để kết hợp danh sách khuyết điểm lại với Phân tích khuyết điểm, khơng tốn thời gian cố gắng sửa Buổi họp đóng vai trò quan trọng: Người kiểm duyệt học hỏi từ người khác họ so sánh danh sách họ Bổ sung thêm khuyết điểm chưa thấy Các hồ sơ có khuyết điểm khâu kiểm duyệt quan trọng cho tiến trình cải tiến Mở rộng việc lựa chọn kỹ thuật kiểm duyệt: Đóng vai trị buổi họp? Cấu trúc buổi họp nào? Loại danh sách kiểm tra dùng? 15 Phân tích yêu cầu phần mềm V&V độc lập V&V thực nhà thầu riêng Để đáp ứng V&V độc lập cần quan điểm kỹ thuật độc lập Chi phí khoảng 5% đến 15% chi phí phát triển Các khảo sát tăng gấp lần lợi nhuận vốn đầu tư: Lỗi phát sớm, rẻ để sửa, rẻ để thử lại Đặc tả rõ Các nhà phát triển thích dùng thực nghiệm tốt kiểu độc lập: Độc lập quản lý: Phân chia trách nhiện từ việc phát triển phần mềm Có thể định đâu cần tập trung nổ lực V&V Độc lập tài chánh: Phân chia chi phí nguồn tài Khơng mạo hiểm phân phối nguồn tài nguyên sửa gặp khó khăn Độc lập kỹ thuật: Tổ chưc nhân riêng biệt, để tránh thành kiến nhà phân tích Dùng cơng cụ kỹ thuật khác 16 Phân tích yêu cầu phần mềm Kết luận Kiểm chứng (Validation) bạn giải vấn đề Prototyping – cho phản hồi khách hàng sớm Inspection – chuyên gia lĩnh vực đọc đặc tả cách kỹ lưỡng Formal Analysis – phân tích tốn học mơ hình bạn …cộng thêm buổi họp & giao tiếp thường xuyên với đối tác Kiểm tra (Verification) bước công nghệ Kiểm tra tính qn – mơ hình có thống với khác? Khả lưu vết – làm cho việc thiết kế/viết mã lệnh/kiểm thử phản ánh u cầu? Sử dụng V&V thích hợp : Lấy thơng tin phản hồi từ khách hàng sớm mơ hình phác thảo Phân tích kiểm tra tính qn mơ hình đặc tả V&V độc lập hệ thống cần an toàn nghiêm ngặt 17 ... Các mơ hình u cầu thống với mơ hình khác? Verificatio n Kiểm tra (Verification) Problem Statement Validatio n Problem Situation Kiểm chứng (Validation) Implementation Statement System Phân tích... phần mềm Tại dùng kiểm duyệt? Sự kiểm duyệt hiệu Kiểm duyệt mã lệnh tốt việc kiểm thử để tìm khuyết điểm Đối với đặc tả (Specifications), kiểm duyệt có sẵn (bạn khơng thể ? ?kiểm thử” đặc tả!)... tiếp thường xuyên với đối tác Kiểm tra (Verification) bước công nghệ Kiểm tra tính qn – mơ hình có thống với khác? Khả lưu vết – làm cho việc thiết kế/viết mã lệnh /kiểm thử phản ánh yêu cầu? Sử