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

Chia sẻ: _ _ | Ngày: | Loại File: PDF | Số trang:30

Thêm vào BST

Báo xấu

19
lượt xem 4
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: 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

1 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
2 A.Cách làm phần mềm, nhìn từ SE Yêu cầu Yêu cầu 1 •Cách làm phải •Phối hợp các được chi tiết bước như thế 2 thành từng bước nào để tạo ra để kiểm soát. phần mềm ? 3 Phần mềm Phần mềm 1. Cách làm có gây ra errors, faults ? hạn chế bằng cách nào ? 2. 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 là một khuông mẫu cho một tập hợp các công đoạn (từng bước) liên kết nhau để hướng dẫn cho người phát triễn xác định được cách làm ra phần mềm (kế hoạch) có kiểm soát (hạn chế sai sót).  Phần mềm không dùng một lần; nó phải được sử dụng lâu dài, và phải phát triễn theo yêu cầu của người sử dụng, đo đó cách làm PM phải hổ trợ cho các thay đổi * lên PM.  Như vậy, có 2 mục tiêu chính mà các mô hình hướng đến: 1. Chuyễn giao PM đạt chất lượng (thoả mãn yêu cầu) 2. Tạo điều kiện thuận lợi cho phần mềm phát triễn liên tục sau khi chuyển giao (ie, làm thêm, không làm lại)
* Hổ trợ thay đổi trong cách làm PM  Sự thay đổi của PM là sự sửa đổi trên các phiên bản ấn phẩm của 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 là quá trình nhận biết và thực hiện các thay đổi cần thiết cho các ấn phẩm đang sử dụng; trong đó, một dự định thay đổi cần được xem xét từ nhiều khía cạnh để hướng đến chất lượng, ví dụ: 1. Nó gây ra sự khác biệt gì so với mong đợi ? (ie, vai trò) 2. Nó có đáng làm hay không ? (lợi ích/thiệt hại) 3. Nó được hiện thực vào PM như thế nào ? (khó hay dể)  Sự xem xét để thực hiện các thay đổi đưa đến nhu cầu trao đổi thông tin để chia sẽ kiến thức hoặc kinh nghiệm, và 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 các loại nguồn lực này.
1970 Mô hình thác nước (tuyến tính) (Users) Có ấn phẩm sau từng công đoạn do người phát triễn tạo ra và (Developers) chuyển giao. Khảo sát Người sử dụng chỉ tiếp cận được với ấn phẩm Phân tích cuối cùng sau khi nó đã được làm theo yêu cầu Thiết kế ban đầu. Hiện thực kiểm thử Sửa lại (rework) Bảo trì (Users)
1960 Mô hình làm mẫu thử (mô hình lặp) Yêu cầu Tạo mẫu (User) (Developer) Mẫu ban Mẫu đã cải tiến đầu Người sử dụng điều kiểm thử mẫu Cải tiến mẫu khiển quá trình phát (User) (Developer) triễn mẫu, dựa trên yêu Mẫu cầu và kết quả thực hoàn hiện yêu cầu (mẫu). chỉnh Yêu cầu cải tiến mẫu Ứng dụng Mô hình không yêu cầu mẫu tạo ra các bản đặc tả cho PM để bảo trì sau này.
1986 Mô hình xoắn ốc (mô hình tiến hóa)  Planning  Customer  Risks Lập kế hoạch Communication Yêu cầu & các thay đổi Ước lượng rủi ro Tạo mẫu thử Kiểm tra Đánh giá Xây dựng Thiết kế  Customer  Design Evaluation Cài đặt  Construction
Đặc điểm của mô hình xoắn ốc  Kết hợp giữa thác nước và 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 cùng làm việc chung với nhau trên các 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 quá trình phát triễn sản phẩm.  Hổ trợ cho nhận thức từ bản 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ủa mỗi công đoạn ở chu kỳ trước, thay vì phải tạo mới Cho phép tiếp tục phát triễn phần mềm trong giai đoạn ứng dụng.
2000~ Mô hình hợp nhất (UP/RUP) 2003 Tài liệu chuyển giao từ chu kỳ trước Introduction to RUP. pdf
10 Các giai đoạn của mô hình UP/RUP  Có 4 giai đoạn chính để tạo ra 1 phiên bản PM Inception : xác định vai trò của PM Elaboration: đặc tả chi tiết (yêu cầu) cho PM Construction: thiết kế giải pháp & hiện thực PM Transistion : chuyển giao sử dụng phiên bản đã làm  Mỗi giai đoạn gồm có một vài chu kỳ phát triễn Mỗi chu kỳ là một chuổi hành động củng cố cho những đặc tả về PM bằng cách liên kết chúng với thực tế. Mỗi chu kỳ có thể dùng mô hình thác nước/mẫu thử/hướng đối tượng,… ; kết thúc bằng một mẫu thử (hoặc phần mềm) cho những người sử dụng (hoặc stack-holders) cùng nhau đánh giá hoặc sử dụng.
11 Các luồng công việc trong UP/RUP  UP có 2 loại luồng công việc (work-flow): tạo ấn phẩm (6 luồng đầu) và hổ trợ tạo ấn phẩm (3 luồng cuối).  Mỗi luồng công việc là một chuỗi hành động nhận thức, hiệu chỉnh, xây dựng và chuyễn giao cho mỗi công đoạn làm phần mềm (6 luồng đầu), hoặc hổ trợ (3 luồng cuối)  Mỗi luồng công việc không nằm gọn trong một giai đoạn, mà nó trãi rộng suốt quá trình phát triễn 1 version hoặc sản phẩm  Mỗi chu kỳ phát triễn sẽ hổ trợ cho chu kỳ sau bằng cách bổ sung thêm nhận định mới hoặc hiệu chỉnh nhận định củ qua 9 luồng công việc trong RUP.
12 Đặc điểm của UP/RUP  UP là sự cải tiến linh hoạt của mô hình xoắn ốc 4 giai đoạn hổ trợ từ nhận thức đến thực tiễn 9 luồng công việc cùng phát triễn // qua mỗi chu kỳ Dựa trên tiếp cận hướng đối tượng  Môhình này giúp nhận thức sớm được nhiều vấn đề phát triễn hệ thống để chuẩn bị trước Bằng cách phân tích nguyên nhân-hậu quả của từng vấn đề thực tế và minh họa giải pháp bằng mẫu thử để xem xét (trực quan), từ đó rút ra nhận định mới để điều khiển chu kỳ kế tiếp. Ví dụ: trong chu kỳ khởi động (khảo sát hiện trạng), mô hình yêu cầu làm demo để stack-holders nhìn ra được các vấn đề về thiết kế, cài đặt, vận hành,… sẽ phải giải quyết trong tương lai, để chuẩn bị trước.
13 B. Verification (kiểm soát cách làm)  Mỗi bước thực hiện trong mô hình phát triễn phải tạo ra được ấn phẩm đúng theo yêu cầu.  Ấn phẩm không đúng là ấn phẩm: Không thoả mãn hết yêu cầu (hoặc mong muốn) Có chứa vài mâu thuẩn với yêu cầu (lỗi) Không hiện thực được thành sản phẩm  Dođó, SE đưa ra 2 hành động để đảm bảo cho ấn phẩm đúng: Xem xét cách làm để tin rằng nó đúng (chứng minh cho cách làm là đúng, verification) Xem xét sản phẩm để tin rằng nó thoả mãn cho nhu cầu sử dụng (validation)
14 Verification & Validation  Verification: “Are we building the product right ?” Implementation against its specifications is correct ?  Validation: “Are we building the right product?” The expected functions or features are present ? GUIDELINES FOR VERIFYING AND VALIDATING SOFTWARE.PDF
15 Ví dụ về các hành động V&V 1. Verification (chứng minh cho cách làm) Xem xét mẫu thử để dẫn ra các đặc tả Xem xét mối quan hệ giữa các tài liệu phân tích, thiết kế và mã nguồn, để khẳng định rằng PM sẽ thoả mãn các yêu cầu ban đầu. 2. Validation (chứng minh cho sản phẩm) Xem xét mẫu thử minh hoạ cho yêu cầu để phát hiện thiếu sót trong tài liệu đặc tả yêu cầu (yêu cầu bị thiếu so với mong muốn). Đối chiếu khả năng của PM so với yêu cầu đã được cam kết, để phát hiện lỗi của sản phẩm PM (kiểm thử).
16 Verification vs Validation Criteria Verification Validation DefinitionThe process of evaluating work-products The process of evaluating software during (not the actual final product) of a or at the end of the development process to development phase to determine whether determine whether it satisfies specified they meet the specified requirements for business requirements. that phase. ObjectiveTo ensure that the product is being built To ensure that the product actually meets according to the requirements and design the user’s needs, and that the specifications specifications. In other words, to ensure were correct in the first place. In other that work products meet their specified words, to demonstrate that the product requirements. fulfills its intended use when placed in its intended environment. EvaluationPlans, Requirement Specs, Design Specs, The actual product/software. Code, Test Cases Activities•Reviews •Testing •Walkthroughs •Inspections softwaretestingfundamentals.com
17 Verification & Validation: đặc tính 1. Phản biện cho cách làm: khẳng định cách làm không đúng (verification) hoặc sản phẩm đã bị khuyết điểm (validation). 2. Các hành động kiểm thử (validation) cũng phải được bảo đảm là đúng (verification). Vd: việc tạo ra test-case & test-plan phải được chứng minh là đúng (verification) trước khi kiểm thử (validation). 3. Có 4 đặc tính chất lượng: Completeness, Consistency, Feasibility, Testability.
18 1.Completeness: tính hoàn chỉnh  Nội dung thực hiện V&V phải thỏa mãn đầy đủ cho vấn đề đã biết.  Tính coverage trong tracing.  Đây là phần biện luận của cách làm: Xem xét tất cả các tình huống cần giải quyết.  Những lỗi không hoàn chỉnh trong bản thiết kế: • Tham chiếu đến hàm, tham số không tồn tại • Thiếu chức năng xử lý cho yêu cầu • Thiếu hổ trợ cho kiểm thử (test case, …) GUIDELINES FOR VERIFYING AND VALIDATING SOFTWARE.PDF
19 Nhắc lại: SE: traceabiliy Coverage Coverage Derivation analysis Impact analysis Derivation Impact
20 SE:Traceability  Yêu cầu đối với PM được thể hiện thành đặc tả cho PM ngày càng chi tiết ở 2 khía cạnh: đặc tả cho sản phẩm, và đặc tả cho yêu cầu (chi tiết thành các test-cases).  Quá trình này được xem xét từ 3 khía cạnh: 1. Toàn diện (coverage): các đặc tả được đưa ra ở mức thấp có diễn tả trọn vẹn đặc tả ở mức cao; và mỗi đặc tả có được test đầy đủ ? 2. Tác động (impact): sự phát sinh hoặc thay đổi một đặc tả sẽ làm thay đổi những đặc tả nào ở mức chi tiết hơn ? • Để loại bỏ đặc tả dư thừa 3. Dẫn xuất (derivation): một đặc tả ở mức thấp có thực sự cần thiết cho một đặc tả nào đó ở mức cao ? và tại sao nó lại ở mức này ?