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.

Nguyễn Anh Hào Khoa CNTT2

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)

(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

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)

Đặ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

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

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 Validation

16

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.

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: traceabiliy

 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: 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 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 = Designspecification

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)

 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á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.

được sử dụng.

 Các vai trò

30