Bài giảng Quản lý dự án phần mềm - Chương 4: Verification (Kiểm soát cách làm) - Nguyễn Anh Hào

Nguyễn Anh Hào Khoa CNTT2 Học viện CNBCVT – Cs Tp.HCM S W Q u a lit y A ss u ra n ce S W Q u a lit y A ss u ra n ce 04. Verification (kiểm soát cách làm)  1 A.Cách làm phần mềm, nhìn từ SE 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 ? •Phối hợp các bước như thế nào để tạo ra phần mềm ? Yêu cầu Phần mềm •Cách làm phải được chi tiết thành từng bước để kiểm soát. 2 1 2 3 Yêu cầu Phần mềm 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. Mô hình thác nước (tuyến tính) Khảo sát Phân tích Thiết kế Hiện thực kiểm thử Bảo trì Sửa lại (rework) (Users) (Users) (Developers) Có ấn phẩm sau từng công đoạn do người phát triễn tạo ra và chuyển giao. Người sử dụng chỉ tiếp cận được với ấn phẩm cuối cùng sau khi nó đã được làm theo yêu cầu ban đầu. 1970 Mô hình làm mẫu thử (mô hình lặp) Yêu cầu cải tiến mẫu Mẫu đã cải tiến Tạo mẫu (Developer) Mẫu ban đầu Ứng dụng mẫu Mẫu hoàn chỉnh kiểm thử mẫu (User) Cải tiến mẫu (Developer) Yêu cầu (User) Người sử dụng điều khiển quá trình phát triễn mẫu, dựa trên yêu cầu và kết quả thực hiện yêu cầu (mẫu). Mô hình không yêu cầu tạo ra các bản đặc tả cho PM để bảo trì sau này. 1960 Mô hình xoắn ốc (mô hình tiến hóa)  Customer Communication  Planning  Customer Evaluation Ước lượng rủi ro Kiểm tra Đánh giá Lập kế hoạch Xây dựng  Risks  Construction Yêu cầu & các thay đổi Tạo mẫu thử Cài đặt Thiết kế  Design 1986 Đặ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. Tài liệu chuyển giao từ chu kỳ trước Introduction to RUP. pdf Mô hình hợp nhất (UP/RUP)2000~ 2003 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. 10 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. 11 Đặ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. 12 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) 13 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 14 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ử). 15 Verification vs Validation16 Criteria 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, Code, Test Cases The actual product/software. Activities•Reviews •Walkthroughs •Inspections •Testing softwaretestingfundamentals.com 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. 17 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, ) 18 GUIDELINES FOR VERIFYING AND VALIDATING SOFTWARE.PDF Nhắc lại: SE: traceabiliy19 Im p act an alysis D er iv at io n an al ys isCoverage C o ve ra ge Impact Derivation SE:Traceability20  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ả sẽ là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 ? và tại sao nó lại ở mức này ? 2.Consistency: tính nhất quán  Mỗi đặc tả trong các tài liệu ở các mức (phân tích, thiết kế, hiện thực) được diễn tả và phân biệt nhau một cách mạch lạc & nhất quán.  Mạch lạc: được liên kết với nhau giữa các mức, không thừa, không thiếu  Nhất quán: không có mâu thuẩn nhau trong cùng 1 mức và giữa các mức  Tracing: impact & derive đưa các đặc tả vào đúng mức của nó (derive) và loại bỏ đặc tả dư thừa (impact) để dể tìm các đặc tả không nhất quán. 21 3.Feasibility: tính khả thi  Là khả năng thực hiện được các yêu cầu (đặc tả) trong thời hạn và kinh phí cho phép  Đối với verification: là khả năng chứng minh được cho cách làm là khả thi.  Đối với validation: là khả năng kiểm lỗi được cho PM trong giới hạn thời gian và kinh phí.  Đặc tính này 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ắc chắn (hoặc độ tin cậy) của phương pháp được chọn. 22 4. Testability: tính khả kiểm  Là khả năng hổ trợ của đặc tả (hoặc sản phẩm PM) cho việc đánh giá đúng sai  Verification: cách làm có phương pháp để chứng minh là đúng/sai hay không ?  Validation: sản phẩm có dể kiểm thử ?  ie, từ đặc tả, ta có thể áp dụng được các phương pháp, kỹ thuật, công cụ đã biết để kết luận rằng PM sẽ thỏa mãn yêu cầu hay không ?  Ví dụ về tính khả kiểm của đặc tả:  Đặc tả đến mức đủ chi tiết (để hiểu đúng ý)  Dựa trên phương pháp đã biết  Đo được (để thiết lập ngưỡng đạt/không đạt)  Kiểm thử được (có thể đưa ra được các test cases đúng và đầy đủ) 23 Verification Verification: xem xét mối quan hệ dẫn xuất từ đặc tả của inputs (vd: requirement specs) sang outputs (vd: design specs) để phát hiện sai sót. Cách làm đúng: mọi inputs đều đưa đến outputs Cách làm sai: output không nằm trong dự kiến (A), output không thể dẫn ra được từ bất kỳ input nào (B), input không có output (C). 24 Inputs = Requirement specification Outputs = Design specification A B C Dự án: Verification  Còn gọi là kiểm thử phi thực thi  Là chuổi hành động cùng nhau xem xét tài liệu về các ấn phẩm của phần mềm (bản thiết kế, soure code,) từ một nhóm chuyên gia, để khẳng định rằng chúng đã được làm đúng (hoặc cần phải hiệu chỉnh). 1. Code review ← 1 lập trình viên 2. Pair programming ← 2 lập trình viên 3. Review ← nhiều chuyên gia a) Walk-through b) Inspection 25 Review (rà soát)  Nội dung họp được chuẩn bị trước  Có trình tự thực hiện cuộc họp  Có nhiều vai trò cùng tham gia  Có 2 loại: Formal (inspection) & Informal (walk- through) FORMAL INFORMAL  Có người ra quyết định sau cùng (chủ tịch)  Có kết luận hoặc phê duyệt sau khi họp, để chính thức sử dụng tài liệu đã phê duyệt  Không có người quyết định, chỉ hợp tác để tìm giải pháp tốt nhất  Chỉ có khuyến nghị sau khi họp 26 a) Kỹ thuật walk-through  Là cuộc họp rà soát tài liệu đặc tả nhằm làm gia tăng sự hiểu biết về cách làm ra PM.  Mục đích: để cải tiến cách làm  Nội dung: chia sẽ quan điểm về cách tiếp cận làm PM, cách áp dụng kỹ thuật-công nghệ, xem xét tính hoàn chỉnh & tính đúng đắn của phương pháp và quy tắc làm ra SP PM.  “Cách làm này sẽ đưa đến kết quả gì ?”  Đặc điểm: tìm sự đồng thuận về quan điểm làm cho phần mềm trở nên tốt hơn. Handbook of Software Quality Assurance.pdf, Page151 27 b) Kỹ thuật Inspection  Là cuộc họp xem xét các đặc tả của ấn phẩm để khẳng định mức độ thỏa mãn của ấn phẩm đối với các yêu cầu đầu vào của công đoạn tạo ra ấn phẩm này.  Còn được gọi là static verification (≠ testing)  Mục đích: để sử dụng được ấn phẩm  Nội dung: Đưa ra đánh giá nghiêm túc về chất lượng của ấn phẩm từ cách thức tạo ra nó.  “Với cách làm này thì PM có đạt chất lượng ?”  Đặc điểm: Phân tich, đánh giá chuyên sâu về sản phẩm & cách làm ra sản phẩm 28 Inspection : đặc tính Cần nhiều chuyên gia ở nhiều lĩnh vực khác nhau để xem xét ấn phẩm một cách toàn diện ở mọi khía cạnh. Có thể áp dụng inspection cho mọi ấn phẩm (yêu cầu, thiết kế, source code, test cases, test data, dữ liệu cấu hình,).  vì nó không cần PM chạy được. Được dùng để phát hiện ra lỗi sớm, trước khi lỗi được hiện thực vào ấn phẩm. Vì chi phí thấp hơn kiễm thử. 29 Cuộc họp Inspection (M.Fagan, 1972) Ấn phẩm: có phương pháp làm, có chứng cớ thực tế, và mọi thành viên đều đọc được. Có phương tiện truyền đạt hiệu quả (vd: forum) Các tiêu chí: được chuẩn bị sẵn để đánh giá ấn phẩm đạt/không đạt/cần sửa, dựa trên chuẩn chất lượng đã được công nhận. Ấn phẩm phải thoả mãn các tiêu chí này trước khi nó được sử dụng. Diễn tả thành check list (pass/fail). Các vai trò Tác giả: kiểm soát sự hiệu chỉnh ấn phẩm Người kiễm thử: kiễm chứng các nhận định Người tư vấn: gợi ý & đánh giá Người điều khiển cuộc họp (moderator) Chủ trì và Thư ký : lập biên bản cuộc họp. 30