Bài giảng Đảm bảo chất lượng phần mềm: Kiểm soát cách làm - Nguyễn Anh Hào

Bài giảng Đảm bảo chất lượng phần mềm: Kiểm soát cách làm trình bày nội dung về cách làm phần mềm, nhìn từ SE, Mô hình phát triển phần mềm, Mô hình thác nước (tuyến tính), Mô hình làm mẫu thử (mô hình lặp), Mô hình xoắn ốc (mô hình tiến hóa), Mô hình hợp nhất (UP/RUP). Mời các bạn tham khảo nội dung chi tiết.

SW Quality Assurance 04 Verification (kiểm soát cách làm)  Nguyễn Anh Hào Khoa CNTT2 Học viện CNBCVT – Cs Tp.HCM A.Cách làm phần mềm, nhìn từ SE Yêu cầu Yêu cầu •Cách làm tiết thành bước để kiểm soát Phần mềm •Phối hợp bước để tạo phần mềm ? Phần mềm Cách làm có gây errors, faults ? hạn chế cách ? Sản phẩm có thỏa mãn yêu cầu ? Mơ hình phát triễn PM  Mơ hình phát triễn phần mềm khuông mẫu cho tập hợp công đoạn (từng bước) liên kết để hướng dẫn cho người phát triễn xác định cách làm phần mềm (kế hoạch) có kiểm sốt (hạn chế sai sót)  Phần mềm khơng dùng lần; phải sử dụng lâu dài, phải phát triễn theo yêu cầu người sử dụng, đo cách làm PM phải hổ trợ cho thay đổi * lên PM  Như vậy, có mục tiêu mà mơ hình hướng đến: Chuyễn giao PM đạt chất lượng (thoả mãn yêu cầu) Tạo điều kiện thuận lợi cho phần mềm phát triễn liên tục sau chuyển giao (ie, làm thêm, không làm lại) * Hổ trợ thay đổi cách làm PM  Sự thay đổi PM sửa đổi phiên ấn phẩm phần mềm (bản đặc tả yêu cầu, thiết kế, mã nguồn,…)  Quá trình phát triễn PM thực chất trình nhận biết thực thay đổi cần thiết cho ấn phẩm sử dụng; đó, dự định thay đổi cần xem xét từ nhiều khía cạnh để hướng đến chất lượng, ví dụ: Nó gây khác biệt so với mong đợi ? (ie, vai trị) Nó có đáng làm hay khơng ? (lợi ích/thiệt hại) Nó thực vào PM ? (khó hay dể)  Sự xem xét để thực thay đổi đưa đến nhu cầu trao đổi thông tin để chia kiến thức kinh nghiệm, cần có cơng nghệ (cơng cụ) hổ trợ Các mơ hình làm phần mềm hướng đến hổ trợ sử dụng loại nguồn lực Mơ hình thác nước (tuyến tính) 1970 (Users) (Developers) Khảo sát Phân tích Thiết kế Có ấn phẩm sau công đoạn người phát triễn tạo chuyển giao Người sử dụng tiếp cận với ấn phẩm cuối sau làm theo yêu cầu ban đầu Hiện thực Sửa lại (rework) kiểm thử Bảo trì (Users) 1960 Mơ hình làm mẫu thử (mơ hình lặp) u cầu (User) Tạo mẫu (Developer) Mẫu ban đầu Người sử dụng điều khiển trình phát triễn mẫu, dựa yêu cầu kết thực u cầu (mẫu) Mơ hình khơng u cầu tạo đặc tả cho PM để bảo trì sau Mẫu cải tiến kiểm thử mẫu (User) Mẫu hoàn chỉnh Cải tiến mẫu (Developer) Yêu cầu cải tiến mẫu Ứng dụng mẫu 1986 Mơ hình xoắn ốc (mơ hình tiến hóa)  Planning  Customer Communication Lập kế hoạch Yêu cầu & thay đổi Kiểm tra Đánh giá  Customer Evaluation  Risks Ước lượng rủi ro Tạo mẫu thử Xây dựng Cài đặt  Construction Thiết kế  Design Đặc điểm mô hình xoắn ốc  Kết hợp thác nước làm mẫu thử Mơ hình thác nước: Hổ trợ nhóm người phát triễn hệ thống làm việc chung với tài liệu đặc tả Mơ hình mẫu thử: người sử dụng tham gia tư vấn & kiểm tra cho trình phát triễn sản phẩm  Hổ trợ cho nhận thức từ chất đến chi tiết (từ bất biến đến tùy biến) Cho phép cập nhật ấn phẩm công đoạn chu kỳ trước, thay phải tạo Cho phép tiếp tục phát triễn phần mềm giai đoạn ứng dụng 2000~ 2003 Mơ hình hợp (UP/RUP) Tài liệu chuyển giao từ chu kỳ trước Introduction to RUP pdf 10 Các giai đoạn mơ hình UP/RUP  Có giai đoạn để tạo phiên PM Inception : xác định vai trò PM Elaboration: đặc tả chi tiết (yêu cầu) cho PM Construction: thiết kế giải pháp & thực PM Transistion : chuyển giao sử dụng phiên làm  Mỗi giai đoạn gồm có vài chu kỳ phát triễn Mỗi chu kỳ chuổi hành động củng cố cho đặc tả PM cách liên kết chúng với thực tế Mỗi chu kỳ dùng mơ hình thác nước/mẫu thử/hướng đối tượng,… ; kết thúc mẫu thử (hoặc phần mềm) cho người sử dụng (hoặc stack-holders) đánh giá sử dụng 16 Criteria Verification vs Validation Verification Validation DefinitionThe process of evaluating work-products (not the actual final product) of a development phase to determine whether they meet the specified requirements for that phase The process of evaluating software during or at the end of the development process to determine whether it satisfies specified business requirements ObjectiveTo ensure that the product is being built according to the requirements and design specifications In other words, to ensure that work products meet their specified requirements To ensure that the product actually meets the user’s needs, and that the specifications were correct in the first place In other words, to demonstrate that the product fulfills its intended use when placed in its intended environment EvaluationPlans, Requirement Specs, Design Specs, The actual product/software Code, Test Cases •Testing Activities•Reviews •Walkthroughs •Inspections softwaretestingfundamentals.com Verification & Validation: đặc tính 17 Phản biện cho cách làm: khẳng định cách làm không (verification) sản phẩm bị khuyết điểm (validation) Các hành động kiểm thử (validation) phải bảo đảm (verification) Vd: việc tạo test-case & test-plan phải chứng minh (verification) trước kiểm thử (validation) Có đặc tính chất lượng: Completeness, Consistency, Feasibility, Testability 1.Completeness: tính hồn chỉnh 18  Nội dung thực V&V phải thỏa mãn đầy đủ cho vấn đề biết Tính coverage tracing  Đây phần biện luận cách làm: Xem xét tất tình cần giải   Những lỗi khơng hồn chỉnh thiết kế: • • • Tham chiếu đến hàm, tham số không tồn Thiếu chức xử lý cho yêu cầu Thiếu hổ trợ cho kiểm thử (test case, …) GUIDELINES FOR VERIFYING AND VALIDATING SOFTWARE.PDF Impact analysis Coverage Coverage Nhắc lại: SE: traceabiliy Derivation analysis 19 Derivation Impact SE:Traceability 20     Yêu cầu PM thể thành đặc tả cho PM ngày chi tiết khía cạnh: đặc tả cho sản phẩm, đặc tả cho yêu cầu (chi tiết thành test-cases) Quá trình xem xét từ khía cạnh: Tồn diện (coverage): đặc tả đưa mức thấp có diễn tả trọn vẹn đặc tả mức cao; đặc tả có test đầy đủ ? Tác động (impact): phát sinh thay đổi đặc tả sẽ làm thay đổi những đặc tả ở mức chi tiết ? • Để loại bỏ đặc tả dư thừa Dẫn xuất (derivation): đặc tả mức thấp có thực cần thiết cho đặc tả mức cao ? và tại nó lại ở mức ? 2.Consistency: tính quán 21  Mỗi đặc tả tài liệu mức (phân tích, thiết kế, thực) diễn tả phân biệt cách mạch lạc & quán Mạch lạc: liên kết với mức, khơng thừa, khơng thiếu  Nhất qn: khơng có mâu thuẩn mức mức   Tracing: impact & derive đưa đặc tả vào mức (derive) loại bỏ đặc tả dư thừa (impact) để dể tìm đặc tả khơng qn 3.Feasibility: tính khả thi 22  Là khả thực yêu cầu (đặc tả) thời hạn kinh phí cho phép Đối với verification: khả chứng minh cho cách làm khả thi  Đối với validation: khả kiểm lỗi cho PM giới hạn thời gian kinh phí   Đặc tính phụ thuộc vào nguồn lực thực tế: Con người (users, devs,…), phương pháp, công cụ, kinh nghiệm  Mức độ chắn (hoặc độ tin cậy) phương pháp chọn  Testability: tính khả kiểm 23  Là khả hổ trợ đặc tả (hoặc sản phẩm PM) cho việc đánh giá sai     Verification: cách làm có phương pháp để chứng minh đúng/sai hay khơng ? Validation: sản phẩm có dể kiểm thử ? ie, từ đặc tả, ta áp dụng phương pháp, kỹ thuật, công cụ biết để kết luận PM thỏa mãn yêu cầu hay khơng ? Ví dụ tính khả kiểm đặc tả:     Đặc tả đến mức đủ chi tiết (để hiểu ý) Dựa phương pháp biết Đo (để thiết lập ngưỡng đạt/khơng đạt) Kiểm thử (có thể đưa test cases đầy đủ) Verification 24 Inputs = Requirement specification C  Verification: A Outputs = Design specification B xem xét mối quan hệ dẫn xuất từ đặc tả inputs (vd: requirement specs) sang outputs (vd: design specs) để phát sai sót  Cách làm đúng: inputs đưa đến outputs  Cách làm sai: output không nằm dự kiến (A), output dẫn từ input (B), input khơng có output (C) Dự án: Verification 25   Còn gọi kiểm thử phi thực thi Là chuổi hành động xem xét tài liệu ấn phẩm phần mềm (bản thiết kế, soure code,…) từ nhóm chuyên gia, để khẳng định chúng làm (hoặc cần phải hiệu chỉnh) Code review ← lập trình viên Pair programming ← lập trình viên Review ← nhiều chuyên gia a) Walk-through b) Inspection ...A .Cách làm phần mềm, nhìn từ SE Yêu cầu Yêu cầu ? ?Cách làm tiết thành bước để kiểm sốt Phần mềm •Phối hợp bước để tạo phần mềm ? Phần mềm Cách làm có gây errors, faults ? hạn chế cách ? Sản... cho cách làm: khẳng định cách làm không (verification) sản phẩm bị khuyết điểm (validation) Các hành động kiểm thử (validation) phải bảo đảm (verification) Vd: việc tạo test-case & test-plan... giao (ie, làm thêm, không làm lại) * Hổ trợ thay đổi cách làm PM  Sự thay đổi PM sửa đổi phiên ấn phẩm phần mềm (bản đặc tả yêu cầu, thiết kế, mã nguồn,…)  Quá trình phát triễn PM thực chất trình