- Kiểm chứng chương trình một cách hình thức chứng minh tính đúng đắn và bảo đảm chất lượng phần mềm thống kê hợp lại với nhau cho ta ta một kỹ thuật cải thiện chất lượng sản phẩm, được
Trang 1Mục lục
Mục lục 1
CÂU HỎI ÔN TẬP KỸ NGHỆ PHẦN MỀM NÂNG CAO 7
1 Chất lượng và đảm bảo chất lượng phần mềm 7
1.1 Khái niệm về đảm bảo chất lượng 7
Câu 1: Chất lượng của một sản phẩm phần được sản xuất là gì? Đối với phần mềm định nghĩa này có đúng không? Làm thế nào để áp dụng định nghĩa đó 7
Câu2: Cái gì được dùng làm cơ sở để kiểm định chất lượng phần mềm: 7
Câu 3: Để làm cơ sở cho việc kiểm định chất lượng, đặc tả các yêu cầu phần mềm cần thoả mãn các điều kiện gì? Nêu một vài ví dụ về điều kiện đưa ra 8
Câu 4: Các nhân tố ảnh hưởng lên chất lượng phần mềm có mấy mức độ? Những loại nhân tố nào ảnh hưởng đến chất lượng? 8
Câu 5: Nêu các đặc trưng ảnh hưởng lên chất lượng của mỗi loại nhân tố: đặc trưng chức năng, khả năng thích nghi với thay đổi, khả năng thích nghi với môi trường 8
Câu 6: Có thể đo trực tiếp chất lượng phần mềm không? Tại sao? Vậy phải đo bằng cách nào? 12
Câu 7: Kể ra các độ đo đặc trưng chất lượng chính của McCall? Giải thích nội dung của nó? 12
Câu 8: Giải thích nội dung các thuộc tính chất lượng phần mềm sau đây và nêu ra các độ đo liên quan được sử dụng để đo thuộc tính đó: 13
Câu 9: Nêu các đặc trưng chất lượng theo Hawlett? Giải thích nội dung mỗi loại 15
1.2 Tiến hóa của hoạt động đảm bảo chất lượng 16
Câu 10: Đảm bảo chất lượng phần mềm xuất phát từ đâu? Tiến triển của nó như thế nào 16
Câu 11:Tại sao cần đảm bảo chất lượng phần mềm? Nó đóng vai trò gì trong một doanh nghiệp phát triển phần mềm? 16
Câu 12: Khi nào cần thực hiện các hoạt động đảm bảo chất lượng phần mềm: 17
Câu 13: Trong một tổ chức ai là người tham gia vào hoạt động đảm bảo chất lượng? Vai trò và trách nhiệm của mỗi đối tượng đó là gì? 17
Câu 14: Mục tiêu của SQA là gì? Các hoạt động chính đảm bảo chất lượng phần mềm là những hoạt động nào? 17
Câu 15: Giải thích nội dung tóm tắt của mỗi hoạt động chính đảm bảo chất lượng? 17
1.3 Rà soát phần mềm 19
Câu 16: Rà soát phần mềm được hiểu là gì (khái niệm, mục tiêu, cách thức áp dụng)? Nêu các lợi ích của việc ra soát? 19
Trang 2Câu 17: Các hình thức của hoạt động rà soát? trình bày khái niệm, mục tiêu của rà soát kỹ thuật chính thức? 19
Câu 19: Trình bày nội dung cơ bản một cuộc họp rà soát: thành phần, thời gian, công việc cần làm, phương châm , sản phẩm? 20
Câu 20 Các sản phẩm của cuộc họp rà soát là gì? Nội dung, vai trò của mỗi sản phẩm đó? 22
Câu 21 Khi nào tiến hành rà soát? Cần rà soát những sản phẩm gì 22
Câu 22: Trình bày nội dung danh mục rà soát của? 22
Trình bày những nội dung cơ bản (mục tiêu, nội dung, danh mục) của 23
2 Các độ đo đặc trưng chất lượng phần mềm 27
2.1 Các độ đo chỉ số chất lượng chương trình 27
23 Nêu các ký hiệu và giải thích các độ đo: s1,s2,s3,s4,s5,s6,s7 và D1=1&0, (D2=1-s2/s1), (D3=1-s3/s1), (D4=1-s5/s4), (D5=1-s6/s4), (D6=1-s7/s1)? 28
24 Sử dụng công thức wiDi với wi = 1 như thế nào và để làm gì? 28
25 Giải thích nội dung các thành phần và ý nghĩa độ đo SMI = và cách sử dụng nó? 28
26.Số đo độ phức tạp của McCabedựa trên cái gì và những đại lượng cụ thể nào? 30
- Số đo dựa trên độ phức tạp chu trình trong đồ thị chương trình của một modun 30
+ Số chu trình có chu trình lồng nhau 30
+ Số chu trình trong một chu trình 30
- Người ta cũng dùng các miền phẳng của đồ thị phẳng để biểu diễn đồ thị chương trình 30
27.đảm bảo chất lượng phần mềm dựa trên thống kê nghĩa là gì?Nó gồm những công việc gì? Kể ít nhất năm nguyên nhân của những khuyết điểm trong phần mềm? 30
Là bảo đảm chất lượng thống kê phản ánh một xu thế ngày càng tăng trong công nghiệp 30
Công việc bao gồm: 30
- Thu thập và phân loại thông tin khiếm khuyết phần mềm 30
- Cố gắng lần vết để tìm ra nguyên nhân 30
- Dùng nguyên lý Pare cô lập 20% khiếm khuyết 30
- Sau khi tìm được nguyên nhân sẽ chỉnh sửa các nguyên nhân của khiếm khuyết 30
Các nguyên nhân gây ra khiếm khuyết có thể là: 30
- Đặc tả không đầy đủ hoặc sai sót (IES) 30
- Hiểu nhầm khi giao tiếp với khách hàng (MCC) 30
Trang 3- Lệch hướng dự định khi đặc tả (IDS) 30
- Vi phạm các chuẩn lập trình (VPS) 30
- Sai trong biểu diễn dữ liệu (EDR) 30
- Không phù hợp với giao diện modun (IMI) 30
- Sai trong logic thiết kế (EDL) 30
- Thử nghiệm sai hoặc không đầy đủ (IET) .30
28 Nêu công thức khiếm khuyết của một sản phẩm ở một pha phát triển? và công thức tính khiếm khuyết của sản phẩm cuối cùng? Giải thích ý nghĩa của nó? 30
- Người phát triển cần phải tính chỉ số khiếm khuyết cho mỗi bước chính phát triển phần mềm 30
- Các thông tin để tính mức độ khiếm khuyết 30
+ Di= tổng số các khiếm khuyết 30
+ Si= số các khiếm khuyết nghiêm trọng 30
+ Mi= Số các khiếm khuyết vừa phải 30
+ Ti =số các khiếm khuyết nhỏ 30
- Với mỗi bước chính trong phát triển phần mềm cần tính chỉ số pha PIi: 30
PIi=w1(Si/Di) + w2(Mi/Di) + w3(Ti/Di) 30
Trong đó w1, w2, w3 là trọng số tương ứng với các khiếm khuyết nghiêm trọng, vừa phải và nhỏ 30
Trọng số này ước lượng mức thiệt hại mà loại đó mang lại 31
- Chỉ số khiếm khuyết DI được tính như sau: 31
DI= (PI1 + 2PI2 + .+iPIi)/PS 31
Trong đó PS là kích cỡ của sản phẩm (là LOC = số dòng mã, hoặc số tuyên bố thiết kế, hoặc số trang tài liệu) tuỳ theo từng bước 31
Theo công thức: các khiếm khuyết càng về sau càng về sau càng nhân với hệ số lớn 31
29 Tiếp cận hình thức cho SQA nghĩa là gì? Quá trình phòng sạch là gì? Phương châm của kỹ thuật này là gì? 31
Người ta nhận thấy cần phải dùng một cách tiếp cận hình thức hơn trong việc bảo đảm chất lượng phần mềm, cách tiếp cận này sẽ bổ sung cho các hoạt động mô tả ở trên 31
Tiếp cận hình thức hoá: đặc tả hình thức cho phép chứng minh tính đúng đắn, kiểm tra lỗi, chuyển tự động thành chương trình làm tăng chất lượng 31
Trang 4- Kiểm chứng chương trình một cách hình thức (chứng minh tính đúng đắn) và bảo đảm chất lượng phần mềm thống kê hợp
lại với nhau cho ta ta một kỹ thuật cải thiện chất lượng sản phẩm, được gọi là quá trình phòng sạch 31
- Phương châm của kỹ thuật này là: Phòng khiếm khuyết hơn là trừ khiếm khuyết 31
2.2 Các độ đo về sự tin cậy và an toàn 31
31 Thế nào là thất bại của phần mềm? Có mấy thang bậc? là những thang bậc nào? 31
32 Nêu chỉ tiêu để tính độ tin cậy? Nêu công thức tính độ sẵn sàng? Giải thích ý nghĩa của nó? 32
33 Có những mô hình độ tin cậy nào? Nó dựa trên tham biến nào và trên giả thiết nào? Mô hình độ tin cậy gieo hạt dựa trên ý tưởng nào? Mục tiêu để làm gì 32
34 Độ an toàn phần mềm là cái gì?Có những phương pháp nào để phân tích độ an toàn? 33
35 Khảo sát nhu cầu SQA gồm những nội dung gì? nhằm trả lời các câu hỏi gì?nếu có nhu cầu thì mình làm gì? 33
36 Có những vấn đề gì đạt ra khi triển khai SQA? Lợi íchcủa SQA là gì? Nguyên tắc chi phí hiệu quả của SQA là gì? 34
3 Kiểm thử phần mềm 34
3.1 Khái niệm về kiểm thử 34
37 Tại sao phải kiểm thử phần mềm? Mục tiêu kiểm thử là gì? Từ đó có quan niệm già sai về kiểm thử phần mềm? 34
38 Thế nào là một ca kiểm thử tốt? ca kiểm thử thành công? Lợi ích phụ kiểm thử là gì 35
39 Biểu đồ dòng thông tin kiểm thử mô tả cái gì? vẽ biểu đồ của nó? 36
40 Kể các đối tượng và phương pháp kiểm thử phần mềm? Mỗi phương pháp đó thường được sử dụng vào giai đọan nào của quá trình phát triển? 36
41 Một ca kiểm thử là cái gì? Mục tiêu thiết kế ca kiểm thử? các bước để xây dựng một ca kiểm thử? 37
42 Kiểm thử hộp trắng là cái gì? Nó nhằm kiểm tra những nội dung nào? 37
43 Kiểm thử hộp đen là cái gì? Nó giúp kiểm tra những nội dung nào của đối tượng kiểm thử? 37
44 Chiến lược kiểm thử phần mềm là cái gì? Nêu các nguyên tắc trong chiến lược kiểm thử phần mềm? 37
45 Nêu các bước của chiến lược kiểm thử thời gian thực và giải thích nội dung của mỗi bước 38
46 Có những loại công cụ tự động nào trợ giúp kiểm thử, mô tả nội dung của mỗi loại 39
47 Ai là người phải tham gia kiểm thử phần mềm? Nêu vai trò và trách nhiệm của mối đối tượng? 39
3.2 Các phương pháp kiểm thử 40
a Kiểm thử hộp trắng 40
48 Kiểm thử hộp trắng dựa trên cơ sơ nào để thiết kế ca kiểm thử? Thiết kế ca kiểm thử phải đảm bảo điều kiện gì? 40
49 Đồ thị dòng gồm những yếu tố nào? Xây dựng nó dựa vào đâu? Nó có đặc trưng gì, Đồ thị dòng dùng để làm gì? 40
Trang 550 Con đường cơ bản trong đồ thị dòng là cái gì? Độ phức tạp của chu trình là gì? Nêu các công thức tính độ phức tạp? 40
51 Ma trận thử nghiệm được cấu trúc như thế nào? Nó được dùng để làm gì? 42
52 Nêu các loại điều khiển trong cấu trúc điều khiển và cho ví dụ? Có những loại sai nào trong điều kiện khi kiểm thử 42
53 Chiến lược kiểm thử phân nhánh nghĩa là gì? Yêu cầu đặt ra cho kiểm thử phân nhánh là gì? 42
54 Chiến lược kiểm thử miền là cái gì? Nó dựa trên tư tưởng nào? 43
55 Chiến lược kiểm thử BRO là cái gì? Nó dựa trên tư tưởng nào? 43
57 Kiểm thử điều khiển dòng dữ liệu nghĩa là gì? Cho ví dụ? 43
58 Kiểm thử điều khiển vòng lặp nghĩa là gì? Cho ví dụ? 45
59 Mô hình của kiểm thử hộp đen quan tâm đến những nhân tố nào của phần mềm? Nó nhằm tìm ra các loại sai nào? Nêu các phương pháp áp dụng cho nó? 46
60 Trình bày phương pháp phân hoach: nguyên tắc, mục tiêu và thiết kế ca kiểm thử? Phương châm xác định lớp tương đương là gi? 46
61 Phân tích giá trị biên nghĩa là gì? Phương châm phân tích giá trị biên là gì? 47
62 Kỹ thuật nhân quả nghĩa là gì? Nêu các bước của ký thuật đó? 47
63 Chiến lươc kiểm thử thời gian thực gồm mấy bước? là những bước nào? Giải thích nội dung cơ bản mỗi bước? 47
64 Kiểm thử đơn vị là gì? Quan hệ của nó với hoạt động mã hóa như thế nào? 48
65 Nội dung cụ thể của hoạt động kiểm thử đơn vị liên quan đến những vấn đề gì (tham số, vào ra, dữ liệu cục bộ, thủ tục tính toán, các dòng điều khiển)? 48
66 Kỹ thuật kiểm thử đơn vị sử dụng là gì? vì sao phải sử dụng ký thuật đó? Có những khó khăn thuận lợi gì? 50
67 Kiểm thử tích hợp thực hiện khi nào? Tại sao phải kiểm thử tích hợp? 50
68 Có những phương pháp gì được áp dụng cho kiểm thử tích hợp? mô tả tóm tắt nội dung mỗi phương pháp? 50
69 Nêu các bước kiểm thử tích hợp từ trên xuống? Ưu nhược điểm của cách tiếp cận này? 51
70 Nêu các bước kiểm thử tích hợp từ dưới lên? Ưu nhược điểm của cách tiếp cận này? 51
71 Các tài liệu kiểm thử tích hợp gồm những loại gì? 51
72 Kiểm thử Beta là cái gì? Kiểm thử Alpha là cái gì? Giữa chúng khác nhau cơ bản ở chỗ nào ? 52
73 Nội dung chính của kiểm thử hệ thống ? Nêu một số câu hởi đặt ra cho kiểm thử hệ thống ? 53
74 Kiểm thử phục hồi là gì ? 53
75 Kiểm thử an ninh là gì ? 54
76 Kiểm thử áp lực là gì 54
Trang 677 Kiểm thử thi hành là gì? 55
78 Gỡ rối được hiểu là gì ? Nó thực hiện khi nào ? Khó khăn của việc gỡ rối là gì ? 55
79 Trình bày tiến trình gỡ rối ? Cách thức gỡ rối ? ưu nhược điểm của chúng 55
80 Quản lý cấu hình phần mềm là cái gì? Nội dung của hoạt động quản lý cấu hình gồm những công việc gì? 57
81 Cấu hình phần mềm là cái gì? Nội dung các khoản mục chính trong cấu hình phần mềm gồm những gì? 58
82 Quản lý cấu hình nhằm mục tiêu gì?Năm nhiệm vụ của quản lý cấu hình là gì 59
83 Phương pháp gì được áp dụng cho việc quản lý cấu hình? Mốc giới là cái gì? Sử dụng mốc giới để kiểm soát sự thay đổi như thế nào? 59
84 Trình bày tiến trình kiểm soát sự thay đổi? 59
85 Phiên bản là cái gì? Làm thế nào để kiểm soát các phiên bản 60
86.Kiểm toán cấu hình phần mềm nghĩa là gì? Hoạt động kiểm toán cần trả lời những câu hỏi gì? 60
11 Báo cáo hiện trạng nghĩa là gì? Nó cần trả lời được những câu hỏi gì? Đầu ra của báo cáo hiện trang dành cho ai? mục tiêu của nó là gì? 61
Trang 7ÂU HỎI ÔN TẬP KỸ NGHỆ PHẦN MỀM NÂNG CAO
1 Chất lượng và đảm bảo chất lượng phần mềm
1.1 Khái niệm về đảm bảo chất lượng
Câu 1: Chất lượng của một sản phẩm phần được sản xuất là gì? Đối với phần mềm
định nghĩa này có đúng không? Làm thế nào để áp dụng định nghĩa đó
- Chất lượng của sản phẩm được thể hiện bằng các đặc trưng phù hợp với các đặc tả củanó
- Định nghĩa này là chung cho mọi sản phẩm Với phần mềm có một số vấn đề:
Phần mềm có yêu cầu mà chưa có đặc tả
Phần mềm có đặc tả nhưng lại mù mờ
Có những yêu cầu tự nhiên nên không được đặc tả
- Chất lượng phần mềm là:
- việc tuân thủ các yêu cầu chức năng và sự hoàn thiện đã được phát biểu tường minh
- các chuẩn phát triển đã được tư liệu hoá tường minh
- các đặc trưng không tường minh được trông đợi từ tất cả các phần mềm đã đượcphát triển theo cách chuyên nghiệp:
Theo quan điểm của người phát triển thì một phần mềm tốt là một phần mềm ít lỗi
Đó chính là chất lượng của chương trình Vấn đề là làm thế nào để chương trình chạygiống như thiết kế Chất lượng của phần mềm theo quan điểm này chính là quan điểmchất lượng theo kiểu lập trình Nguời ta cũng gọi chất luợng này là chất lượng theo nghĩa cần thiết vì nó phản ánh cái bắt buộc phải làm có tính nguyên tắc mặc dù nói chungnguời ta không đạt được
Đã có một sự thay đổi lớn trong cách quan niệm chất lượng của phần mềm Theoquan điểm của khách hàng, phần mềm tốt là phần mềm đáp ứng tốt yêu cầu của kháchhàng và dễ dùng, dễ bảo trì Đó là chất lượng theo quan điểm thiết kế Vấn đề là làm thếnào để thiết kế đáp ứng đúng nhu cầu của người sử dụng Người ta cũng nói đó là chất lượng theo nghĩa hấp dẫn vì nó hướng tới người dùng
Còn một khía cạnh mới trong quan niệm chất lượng của phần mềm đó là độ tin cậy,được hiểu là tính chính xác, tính ổn định, tính an toàn của phần mềm Kể từ khi máy tínhtrở thành hạ tầng mới của xã hội, độ tin cậy của phần mềm trở nên hết sức quan trọng đốivới các hoạt động xã hội Đây là chất lượng theo nghĩa xã hội đo mức độ ảnh hưởng củasản phấm tới mọi người (không kể chính người phát triển và NSD trực tiếp)
Một phần mềm tốt không những phải đáp ứng nhu cầu của người phát triển mà phải
thoả mãn người sử dụng và có độ tin cậy cao Vậy có thể định nghĩa: Chất lượng là mức
độ thoả mãn của NSD đối với sản phẩm hay dịch vụ
Câu2: Cái gì được dùng làm cơ sở để kiểm định chất lượng phần mềm:
Để đánh giá chất lượng phần mềm người ta dựa vào quan điểm chính sau:
Yêu cầu phần mềm là cơ sở để đo chất lượng:
Trang 8 Sự phù hợp với yêu cầu là có chất lượng
Phù hợp yêu cầu cả về số lượng và chất lượng
Yêu cầu thể hiện bằng đặc tả - đặc tả phải có chuẩn của nó mới kiểm tra được
Các chuẩn đặc tả xác định một bộ các tiêu chuẩn phát triển, các tiêu chuẩn này hướngdẫn cách thức làm ra phần mềm: nếu không tuân thủ các tiêu chuẩn đó thì hầu nhưchắc chắn là chất lượng sẽ kém
Luôn có một tập các yêu cầu ngầm thường ít được nhắc đến
Quá thông dụng, hiển nhiên (sử dụng cửa số)
Không thể hiện ra ngoài (quy tắc nghiệp vụ)
Nếu phần mềm chỉ phù hợp với các yêu cầu đã hiển thị mà chưa phù hợp với yêu cầungầm thì chất lượng phần mềm là đáng nghi ngờ
Cần làm rõ yêu cầu và đưa vào đặc tả càng nhiều càng tốt
Câu 3: Để làm cơ sở cho việc kiểm định chất lượng, đặc tả các yêu cầu phần mềm cần
thoả mãn các điều kiện gì? Nêu một vài ví dụ về điều kiện đưa ra.
Yêu cầu phần mềm là cơ sở để đo chất lượng Yêu cầu thể hiện ra bằng đặc tả vàđặc tả phải có chuẩn của nó mới kiểm tra được Các chuẩn đặc tả xác định một bộ cáctiêu chuẩn phát triển, các tiêu chuẩn này hướng dẫn cách thức làm ra phần mềm: nếukhông tuân thủ các tiêu chuẩn đó thì hầu chắc chắn là chất lượng sẽ thiếu sót
Câu 4: Các nhân tố ảnh hưởng lên chất lượng phần mềm có mấy mức độ? Những loại
nhân tố nào ảnh hưởng đến chất lượng?
- Có 2 loại mức độ ảnh hưởng
Nhân tố trực tiếp
Nhân tố gián tiếp
- Có 3 loại nhân tố ảnh hưởng đến chất lượng
Đặc trưng chức năng
Khả năng đương đầu với những thay đổi
khả năng thích nghi với môi trường mới
Câu 5: Nêu các đặc trưng ảnh hưởng lên chất lượng của mỗi loại nhân tố: đặc trưng
chức năng, khả năng thích nghi với thay đổi, khả năng thích nghi với môi trường
McCall đề xuất 11 nhân tố và phân thành 3 loại:
(1) đặc trưng chức năng
(2) khả năng đương đầu với những thay đổi
(3) khả năng thích nghi với môi trường mới
Trang 9 Loại 1: Các đặc trưng chức năng - (5)
Tính đúng đắn
- Có làm đúng với cái tôi muốn hay không?
- Có thỏa mãn những điều đã được đặc tả chưa?
- Có thực hiện được những mục tiêu nhiệm vụ của khách hàng chưa?
o Độ đày đủ
o Độ hòa hợp
o Độ lần vết được
Tính tin tưởng được
- mức hy vọng vào sự thực hiện các chức năng dự kiến
- mức chính xác được đòi hỏi
o Độ chính xác
o Độ phức tạp
o Độ hòa hợp
o Độ dung thứ lỗi
o Độ đo mođun hoá
o Độ đơn giản – dễ hiểu
o Độ đo khả năng huấn luyện
Loại 2: khả năng đương đầu với những thay đổi - (3)
Tính bảo trì được: nỗ lực đòi hỏi để định vị và xác định được một sai trongchương trình
o Độ súc tích
o Độ hoà hợp
o Trang bị đồ nghề đủ
Trang 10o Độ đo mođun hoá
o Độ tự cấp tài liệu
o Độ đơn giản - dễ hiểu
Tính mềm dẻo: nỗ lực đòi hỏi để cải biên một chương trình
o Độ đơn giản - dễ hiểu
Tính thử nghiệm được: nỗ lực đòi hỏi để thử nghiệm một chương trình và bảođảm rằng nó thực hiện chức năng được dự định cho nó
o Độ kiểm toán được
o Độ phức tạp
o Trang bị đồ nghề đủ
o Độ đo mođun hoá
o Độ tự cấp tài liệu
o Độ đơn giản - dễ hiểu
Loại 3: khả năng thích nghi với môi trường mới - (3)
Tính mang chuyển được: nỗ lực đòi hỏi để chuyển nó từ một môi trường phầncứng/phần mềm này sang một môi trường phần cứng/phần mềm khác
o Độ đo mođun hoá
o Độ tự tạo tài liệu
Trang 11o Độ tương đồng dữ liệu
o Độ khái quát
o Độ đo mođun hoá
Có hai mức độ ảnh hưởng
Nhân tố trực tiếp: có thể thực tiếp đo như lỗi/KLOC/ đơn vị thời gian
Nhân tố gián tiếp: nhân tố chỉ có thể đo được một cách gián tiếp như tính bảo trì
Nhân tố
Độ đo Đúngđắn Tin cậyđược Hiệuquả Toànvẹn dụngKhả Bảo trìđược Mềmdẻo Thử nghiệmđược
Trang 12Câu 6: Có thể đo trực tiếp chất lượng phần mềm không? Tại sao? Vậy phải đo bằng
cách nào?
Nhân tố trực tiếp: có thể trực tiếp đo như lỗi/KLOC/ đơn vị thời gian
Câu 7: Kể ra các độ đo đặc trưng chất lượng chính của McCall? Giải thích nội dung
của nó?
McCall đề xuất 22 độ đo sau:
(1) Độ kiểm toán được: có thể kiểm tra dễ dàng về việc tuân thủ các chuẩn
(2) Độ chính xác: Độ chính xác của tính toán và điều khiển
(3) Độ tương đồng giao tiếp: mức độ sử dụng các giao diện, giao thức và giải thôngchuẩn
(4) Độ đầy đủ: mức độ theo đó các việc cài đặt đầy đủ cho các chức năng yêu cầu đãđược đạt tới
(5) Độ phức tạp: tránh dùng chương trình có độ phức tạp cao
(6) Độ súc tích (conciseness): độ gọn của chương trình dưới dạng số dòng mã
(7) Độ hoà hợp (consistancy): việc dùng kỹ thuật thiết kế và tư liệu thống nhất trongtoàn bộ chương trình
(8) Độ tương đồng dữ liệu: việc dùng các cấu trúc và kiểu dữ liệu chuẩn trong toàn bộchương trình
(9) Độ dung thứ lỗi: những hỏng hóc xuất hiện khi chương trình gặp phải một lỗiđược chấp nhận
(10) Độ hiệu qủa thực hiện: hiệu năng khi chạy của chương trình
(11) Độ khuếch trương được:Mức độ theo đó thiết kế kiến trúc, dữ liệu hay thủ tục cóthể được mở rộng
(12) Độ khái quát: độ rộng rãi của ứng dụng tiềm năng của các thành phần chươngtrình
(13) Độ độc lập phần cứng: mức độ theo đó phần mềm tách biệt được với phần cứng
(17) Độ an ninh: có sẵn cơ chế kiển soát hay bảo vệ chương trình và dữ liệu
(18) Độ tự tạo tài liệu (self-doccumentation): mức độ theo đó mã gốc cung cấp tài liệu
có ý nghĩa
(19) Độ đơn giản - dễ hiểu: mức độ theo đó người ta có thể hiểu được chương trìnhkhông khó khăn
Trang 13(20) Độ độc lập hệ thống phần mềm: mức độ theo đó chương trình được độc lập vớicác tính năng ngôn ngữ lập trình, các đặc trưng hệ điều hành và những ràng buộcmôi trường không chuẩn khác.
(21) Độ lần vết được: khả năng theo dõi các dấu vết của một biểu diễn thiết kế haythành phần của chương trình thực hiện so với yêu cầu
(22) Độ đo khả năng huấn luyện: Mức độ theo đó phần mềm trợ giúp làm cho ngườidùng mới dùng được hệ thống
Câu 8: Giải thích nội dung các thuộc tính chất lượng phần mềm sau đây và nêu ra các
độ đo liên quan được sử dụng để đo thuộc tính đó:
Tính đúng đắn
- Làm đúng với khách hàng mong muốn
- Có thỏa mãn những điều đã được đặc tả (những yêu cầu của đối tượng khác)
o Độ đày đủ
o Độ hòa hợp
o Độ lần vết được
Tính tin cậy được
- Có thể trông đợi vào sự thực hiện các chức năng dự kiến
- mức chính xác được đòi hỏi
o Độ chính xác
o Độ phức tạp
o Độ hòa hợp
o Độ dung thứ lỗi
o Độ đo mođun hoá
o Độ đơn giản – dễ hiểu
Trang 14o Độ đo khả năng huấn luyện
Tính bảo trì được: nỗ lực cần để định vị và xác định được một lỗi trong chươngtrình là chấp nhận được
o Độ đơn giản - dễ hiểu
Tính mềm dẻo: nỗ lực cần để cải biên một chương trình là chấp nhận được
o Độ đơn giản - dễ hiểu
Tính thử nghiệm được: nỗ lực cần để thử nghiệm một chương trình và bảo đảmrằng nó thực hiện đúng chức năng dự định là chấp nhận được
o Độ kiểm toán được
o Độ phức tạp
o Trang bị đồ nghề đủ
o Độ đo mođun hoá
o Độ tự cấp tài liệu
o Độ đơn giản - dễ hiểu
Tính mang chuyển được: nỗ lực đòi hỏi để chuyển nó từ một môi trường phầncứng/phần mềm này sang một môi trường phần cứng/phần mềm khác là chấpnhận được
Trang 15o Độ đo mođun hoá
o Độ tự tạo tài liệu
o Độ đo mođun hoá
Câu 9: Nêu các đặc trưng chất lượng theo Hawlett? Giải thích nội dung mỗi loại
+ Thời gian trung bình giữa hai thất bại kề nhau
+ Khả năng phục hồi sau thất bại
+ Khả năng đoán trước được thất bại của chương trình
+ Năng suất và hiệu năng
- Nhân tố mang chuyển
Trang 16+ Cấu hình được (khả năng tổ chức và khống chế các yếu tố của cấu hình phầnmềm, để dễ dàng cài đặt hệ thống và dễ dàng định vị các chỗ có vấn đề)
1.2 Tiến hóa của hoạt động đảm bảo chất lượng
Câu 10: Đảm bảo chất lượng phần mềm xuất phát từ đâu? Tiến triển của nó như thế
nào
- Khi phần mềm trở thành sản phẩm có nhu cầu và đòi hỏi đảm bảo chất lượng:
• Từ nhu cầu của khách hàng
• Từ nhà sản xuất: đảm bảo tính đồng đều của sản phẩm, cải thiện chất lượngthường xuyên
- Sự phát triển của SQA
• Bảo đảm chất lượng là một hoạt động cốt yếu trong bất kỳ một doanh nghiệp nàolàm ra sản phẩm được người khác dùng
• Lịch sử bảo đảm chất lượng phần mềm (SQA) diễn ra song song với bảo đảm chấtlượng trong chế tạo phần cứng
• Các chuẩn bảo đảm chất lượng phần mềm đầu tiên được đưa ra trong quân sự, thờinhững năm 70 và nhanh chóng lan ra lĩnh vực thương mại
Câu 11:Tại sao cần đảm bảo chất lượng phần mềm? Nó đóng vai trò gì trong một
doanh nghiệp phát triển phần mềm?
Đảm bảo chất lượng phần mềm là các hoạt động nhằm mục tiêu là sản xuất ra phần mềm có chất lượng cao.
Phải đảm bảo chất lượng phần mềm vì
• Từ nhu cầu của khách hàng
• Từ nhà sản xuất: đảm bảo tính đồng đều của sản phẩm làm ra
• Giúp nhà phân tích có được đặc tả chất lượng cao
• Giúp nhà thiết kế có được thiết kế chất lượng cao
• Theo dõi chất lượng phần mềm
• Đánh giá ảnh hưởng của thay đổi về phương pháp luận và thủ tục lên chất lượngphần mềm
• SQA có những lợi ích sau:
- phần mềm có ít các khiếm khuyết tiềm ẩn hơn và do đó mất ít công sức và thờigian thử nghiệm và bảo trì
- Độ tin cậy cao hơn và do đó khách hàng thoả mãn hơn
- Giảm phí tổn bảo trì
- Giảm phí tổn tổng thể toàn bộ vòng đời của phần mềm
nó đóng vai trò trong một doanh nghiệp phát triển phần mềm
Trang 17• Bảo đảm chất lượng là một hoạt động cốt yếu trong bất kỳ một doanh nghiệp nàolàm ra sản phẩm được người khác dùng
Câu 12: Khi nào cần thực hiện các hoạt động đảm bảo chất lượng phần mềm:
Chất lượng phần mềm được thiết kế bên trong sản phẩm hay hệ thống do đó nó được bắtđầu ngay từ khi phân tích và nó giúp người phân tích đạt tới đặc tả chất lượng cao vàngười thiết kế thì phát triển thiết kế với chất lượng cao
Câu 13: Trong một tổ chức ai là người tham gia vào hoạt động đảm bảo chất lượng?
Vai trò và trách nhiệm của mỗi đối tượng đó là gì?
Những người trong tổ chức có trách nhiệm bảo đảm chất lượng phần mềm:
- các kỹ sư phần mềm,
- các nhà quản lý dự án,
- khách hàng,
- người bán hàng,
- các cá nhân trong nhóm SQA
• Nhóm SQA đóng vai trò như đại diện của khách hàng - để xem chất lượng phầnmềm với quan điểm khách hàng
• Có đáp ứng được các nhân tố chất lượng không?
• Có tuân theo các chuẩn dự định trước không?
• Các thủ tục phương pháp kỹ thuật có thực sự đóng vai trò của chúng tronghoạt động SQA?
Câu 14: Mục tiêu của SQA là gì? Các hoạt động chính đảm bảo chất lượng phần mềm
là những hoạt động nào?
Đảm bảo chất lượng phần mềm là các hoạt động nhằm mục tiêu là sản xuất ra phần mềm có chất lượng cao.
Có 7 hoạt động chính:
1 Áp dụng các phương pháp kỹ thuật tiến bộ
2 Tiến hành rà soát kỹ thuật chính thức
3 Thử nghiệm phần mềm
4 Tuân theo các chuẩn
5 Khống chế các thay đổi
6 Đo lường
7 Báo cáo và bảo quản các báo cáo
Câu 15: Giải thích nội dung tóm tắt của mỗi hoạt động chính đảm bảo chất lượng?
1 Áp dụng các phương pháp kỹ thuật: giúp cho
- người phân tích có được đặc tả chất lượng cao
- người thiết kế có được thiết kế với chất lượng cao
Trang 182 Tiến hành rà soát kỹ thuật chính thức: được nhóm kỹ thuật tiến hành với mục đích
là phát hiện ra vấn đề chất lượng
3 Kiểm thử phần mềm: là một chiến lược nhiều bước với một loạt các phương phápthiết kế các trường hợp kiểm thử giúp đảm bảo phát hiện ra các lỗi một cách hiệuquả
4 Bắt tuân theo các chuẩn: Là hình thức được áp dụng cho tiến trình kỹ nghệ phầnmềm thay đổi tuỳ theo công ty
5 Khống chế các thay đổi: đóng góp trực tiếp vào chất lượng phần mềm nhờ
+ Chính thức hoá các yêu cầu đổi thay
+ Đánh giá bản chất của sự đổi thay
+ Khống chế các ảnh hưởng của sự đổi thay
+ Đe doạ chủ yếu của chất lượng đến từ sự thay đổi, thay đổi là bản chất củaphần mềm
+ thay đổi tạo ra tiềm năng sinh ra sai và tạo ra hiệu ứng phụ lan truyền
Áp dụng trong suốt quá trình phát triển và trong quá trình bảo trì
6 Đo lường: dùng để theo dõi chất lượng phần mềm và thẩm định tác dụng của nhữngthay đổi phương pháp luận và thủ tục lên chất lượng phần mềm đã được cải tiến
7 Báo cáo và bảo quản các báo cáo: Kết quả của các cuộc họp xét duyệt , kiểm toán,kiểm soát thay đổi, kiểm thử phải trở thành một phần của bản ghi lịch sử cho một
dự án và phải được phân phát cho nhóm phát triển trên cơ sở điều-cần - phải- biết
Trang 191.3 Rà soát phần mềm
Câu 16: Rà soát phần mềm được hiểu là gì (khái niệm, mục tiêu, cách thức áp dụng)?
Nêu các lợi ích của việc ra soát?
Khái niệm: Rà soát là việc xem xét, đánh giá sản phẩm được tiến hành mỗi giai đoạn
để phát hiện ra những khiếm khuyết cần sửa chữa trước khi sang giai đoạn sau
Mục tiêu:
• Chỉ ra các chỗ khiếm khuyết cần phải cải thiện
• Khẳng định những sản phẩm đạt yêu cầu
• Kiểm soát việc đạt chất lượng kỹ thuật tối thiểu của sản phẩm
Cách thức áp dụng: Rà soát được áp dụng tại các thời điểm khác nhau trong quá trình phát triển phầm mềm
Có nhiều kiểu rà soát khác nhau:
• Các cuộc họp xét duyệt không chính thức
• Cuộc trình bày chính thức trước cử tọa gồm khách hàng, nhà quản lý, nhân viên kỹthuật (chỉ tập trung vào các rà soát kỹ thuật chính thức FTR-Format TechnicalReview)
Các lợi ích của việc ra soát
Lợi ích hiển nhiên của FTR là sớm phát hiện các “khiếm khuyết” phần mềm để
có thể chỉnh sửa từng khiếm khuyết một trước khi bước sang bước tiếp theo củaquá trình phần mềm
Các nghiên cứu của công nghiệp phần mềm đã chỉ ra rằng: các hoạt động thiết kếtạo ra đến 50%-60% tổng số các khiểm khuyết tạo ra trong phát triển phần mềm
Chi phí chỉnh sửa một khiếm khuyết tăng lên nhanh chóng sau mỗi giai đoạn.VD: Lỗi không được phát hiện trong thiết kế tốn phí 1.0 để sửa chữa, trước kiểmthử nghiệm: 6.5; trong thử nghiệm: 15 và sau khi phân phát sẽ là từ 60.0 đến100.0
Câu 17: Các hình thức của hoạt động rà soát? trình bày khái niệm, mục tiêu của rà
soát kỹ thuật chính thức?
Có nhiều kiểu rà soát khác nhau:
• Các cuộc họp xét duyệt không chính thức
• Cuộc trình bày chính thức trước khách hàng, nhà quản lý, thành viên kỹ thuật
Rà soát do các kỹ sư phần mềm thực hiện, là một phương tiện hiệu quả để cải thiệnchất lượng phần mềm
Rà soát kỹ thuật chính thức(FTR):
- Khái niệm: là hoạt động đảm bảo chất lượng phần mềm do những người đang
tham gia phát triển phần mềm thực hiện
- Mục tiêu:
Trang 20(1)Phát hiện các lỗi trong chức năng, trong logic, trong triển khai.
(2)Kiểm thử sự phù hợp của phần mềm với yêu cầu
(3)Bảo đảm rằng phần mềm phù hợp với các chuẩn đã định sẵn
(4)Đảm bảo “ phần mềm đã được phát triển theo một cách thức nhất quán
(5)Làm cho dự án dễ quản lý hơn
(6)Ngoài ra dùng để làm cơ sở huấn luyện các kỹ sư trẻ và có ích ngay cảcho những kỹ sư đã có kinh nghiệm
Câu 18: Vẽ sơ đồ tiến trình hoạt động rà soát va giải thích sơ bộ nội dung mỗi bước?
Giải thích:
- Mỗi cá nhân phát triển phải thông báo cho lãnh đạo dự án biết rằng sản phẩm
đã hoàn tất và cần phải rà soát
- Lãnh đạo dự án thông báo cho người chịu trách nhiệm rà soát biết
- Người chịu trách nhiệm lãnh đạo rà soát:
o Xem xét sản phẩm để đọc, rà soát
o Tạo ra các bản sao của sản phẩm , phân cho 2,3 người ra soát
o Thiết lập chương trình họp rà soát
- Những thực hiện rà soát: thường tốn 1-2 giờ để rà soát viết các bản ghi chú :tham gia cuộc họp rà soát
Câu 19: Trình bày nội dung cơ bản một cuộc họp rà soát: thành phần, thời gian, công
việc cần làm, phương châm , sản phẩm?
Bất kể thế nào, mọi cuộc họp rà soát phải:
Thành phần: Có từ 3 đến 5 người liên quan tới việc rà soát, gồm có:
• lãnh đạo rà soát
• tất cả các cá nhân rà soát
• người tạo ra sản phẩm được rà soát
Thời gian:
Trang 21• Phải có sự chuẩn bị trước, tuy nhiên mỗi người không quá 2 giờ chuẩn bị.
• Cuộc họp nên ít hơn 2 giờ Mỗi cuộc họp rà soát chỉ hạn chế trong một phần nhỏ,
cụ thể
Công việc cần làm:
• Trọng tâm của các cuộc họp rà soát là về sản phẩm: một thành phần (một thànhphần của đặc tả yêu cầu, một thiết kế modul chi tiết, một danh sách mã nguồn chomột modul)
• Phải đưa ra một trong 3 quyết định sau đây:
- Chấp nhận sản phẩm không cần chỉnh sửa
- Khước từ sản phẩm vì những lỗi nghiêm trọng
- Chấp nhận cho chỉnh sửa sản phẩm, sau khi chỉnh sửa phải có cuộc họp rà soátlại
• Mọi thành viên tham gia cuộc họp phải ký vào quyết định
Phương châm rà soát:
• Cần thiết lập trước phương châm rà soát, phân phát cho những người làm nhiệm
vụ rà soát, thống nhất tán thành và tuân thủ Một rà soát mà không khống chế đượcthì có thể còn xấu hơn là không rà soát
• 10 điều tối thiểu trong phương châm rà soát kỹ thuật chính thức:
(1) rà soát sản phẩm, không rà soát người làm nó
(5) Nên có ghi chú trên bảng tường
(6) Giới hạn số người tham dự và kiên trì các dự kiến
(7) Lập một danh sách các kiểm tra cho từng sản phẩm sẽ được rà soát:
Giúp nhà lãnh đạo rà soát cấu trúc các cuộc họp FTR
Giúp người rà soát tập trung vào các vấn đề quan trọng
Danh sách kiểm tra lập cho từng loại sản phẩm:ành cho việc phân tích, thiết
kế, mã hoá kiểm tra và bảo trì
Một tập thể các đại diện sẽ xem lại danh sách này để trình
(8) Cấp phát nguồn lực và thời biểu cho các FTR: xem nó là một nhiệm vụ trongquá trình phát triển phần mềm, và cũng phải dự tính các cải biên cần thiết cho
sự kiện chưa dự đoán được
(9) Cần phải tiến hành huấn luyện chính thức cho các cá nhân ra soát
(10) Rà soát lại các rà soát trước đây
Trang 22Câu 20 Các sản phẩm của cuộc họp rà soát là gì? Nội dung, vai trò của mỗi sản phẩm
đó?
Sản phẩm của cuộc họp rà soát là:
• Báo cáo các vấn đề nảy sinh do các cá nhân rà soát nêu ra
• Một danh sách các vấn đề cần giải quyết do cuộc họp thống nhất
để nhận ra vùng có vấn đề trong sản phẩm được rà soát
dùng như một danh sách các khoản mục hành động để chỉ cho người làm rasản phẩm cần chỉnh sửa
Cần thiết lập một thủ tục để bảo đảm rằng các khoản mục trong danh sách
đó sẽ được chỉnh sửa thực sự
• Một văn bản tổng kết cuộc họp rà soát đó, văn bản này phải chỉ rõ
Rà soát cái gì
Ai rà soát
Tìm thấy cái gì? và kết luận
Câu 21 Khi nào tiến hành rà soát? Cần rà soát những sản phẩm gì
- Mọi sản phẩm tạo ra ở mỗi bước đều được rà soát (không chỉ sản phẩm cuốicùng)
- Rà soát được tiến hành suốt quá trình phát triển
- Tiến trình phát triển chung nhất gồm 4-5 giai đoạn:
Rà soát bám theo các sản phẩm của rà soát này
Câu 22: Trình bày nội dung danh mục rà soát của?
Danh mục rà soát trong kỹ nghệ hệ thống:
Bảo đảm chất lượng mức này là đánh giá yêu cầu thẩm duyệt ở mức hệ thống: Một cuộc họp lớn gồm đại diện các đơn vị liên quan
(1)Các chức năng chủ yếu đã được xác định đủ và rõ ràng(không mơ hồ)?
(2)Các giao diện giữa các hệ con của hệ thống đã được xác định đủ và đúng hay chưa?
(3)Các ràng buộc thực thi đã được thiết lập cho toàn hệ thống và cho từng phần tử haychưa?
Trang 23(4)Các ràng buộc thiết kế đã được thiết lập cho từng phần tử hay chưa?
(5)khả năng chọn đã là đã tốt nhất chưa?
(6)Giải pháp này có khả thi kỹ thuật không?
(7)Cơ chế kiểm chứng và thẩm duyệt đã đwợc thiết lập hay chưa?
(8)Có sự hoà hợp giữa các phần tử của hệ thống hay chưa?
Rà soát việc lập kế hoạch
Lập kế hoạch dự án phần mềm dựa trên sản phẩm của kỹ nghệ hệ thống để đưa ra các nộidung chủ yếu:
+ Phạm vi công việc kiểm tra thực hiện
+ ước lượng nguồn lực, giá cả, thời gian công việc
+ Lịch biểu thực hiện
+ Tổ chức, nhân sự, cơ chế triển khai
+ đánh giá rủi ro và kế hoạch khác
Danh mục
(1) Phạm vi của phần mềm đã xác định đúng đắn chưa? có bị hạn chế hay không?
(2) Thuật ngữ có trong sáng không?
(3) Các nguồn lực (người, chi phí, thời gian): có đủ tương xứng với phạm vi đókhông? Các nguồn lực đã có sẵn sàng chưa?cơ sở dự đoán giá cả có hợp lý không?
dữ liệu năng xuất và chất lượng trước đây có được sử dụng không? Sự khác biệtcủa ước lượng đã được sử lý chưa?
(4) Các công việc lên lịch biểu đã: xác định thích hợp chưa? Sắp xếp trình tự thực hiệnđúng logic chưa? bố trí song song có phù hợp với các nguồn lực đã sẵn có haykhông?
(5) Phương án tổ chức và nhân sự đã hợp lý chưa?
(6) Các rủi ro trong tất cả các hạng mục quan trọng đã: xác định và đánh giá đầy đủchưa? Lập kế hoạch quản lý và kế hoạch thích hợp chưa?
(7) Các nhiệm vụ đã thật sự được xác định và sắp xếp tuần tự chưa?, tính song song
có hợp lý đối với các nguồn lực đã sẵn có hay chưa?
(8) Ngân sách và giới hạn chót được dự kiến: có hiện thực hay không? có phù hợp vớilịch biểu không?
Trình bày những nội dung cơ bản (mục tiêu, nội dung, danh mục) của
- rà soát phân tích yêu cầu phần mềm
- rà soát thiết kế phần mềm ( tương ứng với từng giai đoạn thiết kế)
- rà soát lập mã phần mềm
- rà soát kiểm thử phần mềm (tương ứng với kế hoạch và thủ tục kiểm thử)
- rà soát bảo trì phần mềm (ứng với kế hoạch và thủ tục kiểm thử)
TL
rà soát phân tích yêu cầu phần mềm
Mục tiêu: thẩm định và xác minh yêu cầu phần mềm
Trang 24 phải chỉ ra các nhu cầu của người dùng là được thoả mãn
Các yêu cầu phải nhất quán, nghĩa là không mâu thuẫn nhau
Các yêu cầu phải đầy đủ: chúng phải chứa mọi chức năng và mọi ràng buộc mà
sự phù hợp và tính đúng đắn của mô hình phân tích
Với các hệ thống lớn cần tăng cường:
Các rà soát kỹ thuật chính thứcviệc đánh giá các nguyên mẫu cũng như các cuộc họp với khách hàng
Danh mục: xem xét các chủ đề sau:
(1)Phân hoạch vấn đề (hệ con) có đầy đủ hay không?
(2)Các giao diện trong và ngoài đã thực sự được xác định chưa?
(3)Phân tích lĩnh vực thông tin có đầy đủ, phi mâu thuẫn và chính xác hay ko?
(4)Mô hình dữ liệu đã thực sự phản ánh các đối tượng dữ liệu, các thuộc tính và các
quan hệ?
(5)Tất cả các yêu cầu có thể lần vết được ở mức hệ thống không?
(6)Đã làm bản mẫu dành cho người sử dụng (khách hàng) chưa?
(7)Liệu có thực hiện được với những ràng buộc quy định bởi các phần tử hệ thống
khác hay không?
(8)Các yêu cầu có phù hợp với lịch biểu, nguồn lực và kinh phí hay không?
(9)Các chuẩn thẩm định có đầy đủ hay không?
rà soát thiết kế phần mềm ( t ươ ng ứng với từng giai đ oạn thiết kế)
Mục tiêu: Hướng đến thiết kế đảm bảo hai yêu cầu
Cấu trúc tốt (phân hoạch, giao diện, modul hoá)
Thuật toán tốt (ít phức tạp, tốc độ cao, dễ hiểu)
Dữ liệu tốt (cấu trúc, biểu diễn)
Có thể lần vết được (dễ hiểu, dễ kiểm tra)
Nội dung:
Rà soát kỹ thuật chính thức cho khâu thiết kế tập trung vào:
Trang 25 thiết kế dữ liệu
thiết kế kiến trúc
thiết kế thủ tục
Có 2 kiểu rà soát thiết kế (phù hợp với bước triển khai):
rà soát thiết kế sơ bộ - preliminary design review (đánh giá việc dịch các yêu cầu thành thiết kế dữ liệu và thiết kế kiến trúc),
rà soát thiết kế trọn vẹn - design walkthrough (tập trung vào tính đúng đắn củathuật toán)
Danh mục
Rà soát thiết kế sơ bộ
(1) Các yêu cầu phần mềm có được phản ánh trong kiến trúc phần mềm hay không?(2) Có đạt được sự môđun hoá hiệu quả không? Các môđun có độc lập chức năng hay không
(3) Kiến trúc chơng trình có được phân tách không?
(4) Các giao diện đã được xác định cho các môđun và các phần tử hệ thống ngoại lai chưa?
(5) Cấu trúc dữ liệu có phù hợp với lĩnh vực thông tin chưa?
(6) Cấu trúc dữ liệu có phù hợp với yêu cầu phần mềm chưa?
(7) Khả năng bảo trì đã được xem xét chưa?
(8) Các nhân tố chất lượng đã được đánh giá rõ ràng chưa?
Rà soát thiết kế toàn bộ
(1) Thuật toán có hoàn thành chức năng mong muốn không?
(2) Thuật toán có đúng đắn logic không?
(3) Giao diện có phù hợp với thiết kế kiến trúc không?
(4) Độ phức tạp logic có phải chăng hay không?
(5) Sử lý sai đã được đặc tả chưa?
(6) Cấu trúc dữ liệu cục bộ có thật sự đã được xác định?
(7) Kiến tạo lập trình cấu trúc đã xuyên suốt chưa?
(8) Các chi tiết thiết kế đã tuân theo ngôn ngữ thực hiện chưa?
(9) Dùng các đặc điểm hệ điều hành hay là phụ thuộc ngôn ngữ?
(10)Đó dùng logic compound hoặc logic inverse?
(11)Khả năng bảo trì đã được xét tới chưa
rà soát lập mã phần mềm
Mục tiêu: rà soát hướng đến mã nguồn đạt được
phản ánh đầy đủ, phù hợp với thiết kế
phù hợp với ngôn ngữ sử dụng (chuẩn, cú pháp, khai báo dữ liệu )
Văn bản chương trình tốt (không lỗi chính tả, có cấu trúc, nhất quán )
Nội dung
Trang 26 Danh mục
(1) Thiết kế có thực sự được dịch thành mã chưa?
(2) Có các sai sót chính tả hoặc in ấn nào không?
(3) Có thực sự dùng các quy ước ngôn ngữ hay không?
(4) Có phục tùng về các chuẩn mẫu lập mã đối với phong cách ngôn ngữ, ghi chú (5) Có ghi chú nào không đúng đắn hoặc mơ hồ?
(6) Kiểu dữ liệu và khai báo dữ liệu có chính xác hay không?
Đánh giá một cách phê phán các kế hoạch kiểm thử và các thủ tục kiểm thử
hướng đến đảm bảo các phương pháp, các chiến lược và các kỹ thuật được sử dụng và kế hoạch tốt
Thời gian, địa điểm
Tài liệu kiểm thử: các ca kiểm thử, tiến trình, lịch trình
Điều kiện
Các yêu cầu: phần cứng, phần mềm, nhân sự
Kiểm soát quá trình kiểm thử
Trang 27(3) Các chức năng chủ yếu có được trình diễn sớm không?
(4) Kế hoạch thử nghiệm có phù hợp với kế hoạch dự án tổng thể hay không?
(5) Lịch trình thử nghiệm có được xác định rõ ràng hay không?
(6) Nguồn lực và công cụ thử nghiệm đã đợc minh định và đã sẵn sànghay chưa?(7) Đã thiết lập cơ chế lưu trữ các báo cáo chưa?
(8) Các bộ lái (driver) và các cuống (stub) thử nghiệm đã được minh định chưa?; công việc phát triển chúng đã được lập lịch chưa?
(9) Thử nghiệm cường độ chịu áp lực cho phần mềm đã được đặc tả chưa?
(10)Cả hai loại thử nghiệm hộp trắng và hộp đen đã được đặc tả chưa?
(11)Có phải tất cả các đường logic độc lập đều được thử nghiệm?
(12)Có phải tất cả các ca thử nghiệm đều đã được minh định và lập danh sách với đủcác kết qủa chờ mong?
(13)Việc xử lý sai có được thử nghiệm?
(14)Các giá trị biên có được thử nghiệm?
(15)Các yêu cầu thời gian và sự diễn tiến có được thử nghiệm?
(16)Các biến thể chấp nhận được của kết quả thử nghiệm mong đợi đã được đặc tả chưa?
rà soát bảo trì phần mềm (ứng với kế hoạch và thủ tục kiểm thử)
(1) Đã xét đến các hiệu ứng phụ gắn với các đổi thay hay chưa?
(2) Xem xét yêu cầu đổi thay đã được lập tài liệu, được đánh giá và được chấp thuận hay chưa?
(3) Báo cáo xem xét sự đổi thay cho tất cả các bên quan tâm hay chưa?
(4) Các rà soát kỹ thuật chính thức thích hợp đã được tiến hành hay chưa?
(5) Một rà soát chấp thuận cuối cùng đã được thực hiện để bảo đảm rằng toàn bộ phầnmềm đã thực sự được cập nhật, được thử nghiệm và được thay thế hay chưa?
2 Các độ đo đặc trưng chất lượng phần mềm
2.1 Các độ đo chỉ số chất lượng chương trình
a Các độ đo về kiến trúc chương trình (DSQI)
Trang 2823 Nêu các ký hiệu và giải thích các độ đo: s1,s2,s3,s4,s5,s6,s7 và D1=1&0, (D2=1-s2/
s1), (D3=1-s3/s1), (D4=1-s5/s4), (D5=1-s6/s4), (D6=1-s7/s1)?
Ký hiệu
S1: tổng số các mô dun được xác định trong kiến trúc chương trình
S2: số các mô đun mà chức năng đúng đắn của nó phụ thuộc vào nguồn dữliệu đầu vào hay các thủ tục sinh ra dữ liệu được dùng ở ngoài module
S3: số các môđun có chức năng phụ thuộc vào xử lý trước đó
S4: số các khoản mục cơ sở dữ liệu (Bao gồm các đối tượng dữ liệu và tất cảcác tính chất xác định các đối tượng đó)
S5: Tổng số các khoản mục dữ liệu đáng chú ý
S6: số các các khúc dữ liệu(các bản ghi khác nhau hay các đối tượng riêng lẻ)
S7: số các môđun với lối vào và lối ra duy nhất (xử lý ngoại lệ không đượcxem là lối ra bội)
D5: Độ phân chia cơ sở dữ liệu D5=1-s6/s4
D6: Đặc trưng vào/ra của mô dun D6=1-s7/s1
24 Sử dụng công thức w i D i với w i = 1 như thế nào và để làm gì?
Công thức tính chỉ số chất lượng cấu trúc thiết kế
DSQI= wiDi với i=1tới 6, wi là trọng số tương đối của tầm quan trọng của từng giátrị trung gian Di và wi = 1 (Nếu tất cả các Di có trọng số bằng nhau thì wi=0,167)
Cần ghi lại DSQI của các thiết kế thành công trước đây, tính trung bình của chúng
Và từ đó so sánh giá trị trung bình đó với thiết kế hiện đang phát triển
Nếu chỉ số DSQI lần này thấp hơn nhiều so với giá trị trung bình đó thì cần phảitiếp tục công việc thiết kế và rà soát
Tương tự nếu tiến hành một số thay đổi chính với thiết kế hiện có thì có thể tínhtoán được hiệu quả của những thay đổi này lên DSQI
25 Giải thích nội dung các thành phần và ý nghĩa độ đo SMI =
Trang 29SMI là chỉ số trưởng thành phần mềm (Software Multinity Index) Nó chỉ ra tính ổn địnhcủa sản phẩm phần mềm (dựa trên những thay đổi xuất hiện cho từng lần đưa ra sảnphẩm)
- MT: số các mô đun phát hành lần này
- Fc: số các môdun có thay đổi trong lần phát hành này
- Fa: số các môdun được thêm vào trong lần này
- Fd: số các môdun của lần phát hành trước mà bị bỏ đi trong lần phát hành này
Khi SMI tiến tới 1 thì sản phẩm bắt đầu ổn định SMI cũng có thể được dùng:
- như độ đo cho các hoạt động bảo trì phần mềm theo kế hoạch
- thời gian trung bình để tạo ra lần phát hành sản phẩm phần mềm
- các mô hình kinh nghiệm cho nỗ lực bảo trì có thể được phát triển
Trang 3026.Số đo độ phức tạp của McCabedựa trên cái gì và những đại lượng cụ thể nào?
- Số đo dựa trên độ phức tạp chu trình trong đồ thị chương trình của một modun+ Số chu trình có chu trình lồng nhau
+ Số chu trình trong một chu trình
- Người ta cũng dùng các miền phẳng của đồ thị phẳng để biểu diễn đồ thị chươngtrình
27.đảm bảo chất lượng phần mềm dựa trên thống kê nghĩa là gì?Nó gồm những công việc gì? Kể ít nhất năm nguyên nhân của những khuyết điểm trong phần mềm?
Là bảo đảm chất lượng thống kê phản ánh một xu thế ngày càng tăng trong côngnghiệp
Công việc bao gồm:
- Thu thập và phân loại thông tin khiếm khuyết phần mềm
- Cố gắng lần vết để tìm ra nguyên nhân
- Dùng nguyên lý Pare cô lập 20% khiếm khuyết
- Sau khi tìm được nguyên nhân sẽ chỉnh sửa các nguyên nhân của khiếm khuyếtCác nguyên nhân gây ra khiếm khuyết có thể là:
- Đặc tả không đầy đủ hoặc sai sót (IES)
- Hiểu nhầm khi giao tiếp với khách hàng (MCC)
- Lệch hướng dự định khi đặc tả (IDS)
- Vi phạm các chuẩn lập trình (VPS)
- Sai trong biểu diễn dữ liệu (EDR)
- Không phù hợp với giao diện modun (IMI)
- Sai trong logic thiết kế (EDL)
- Thử nghiệm sai hoặc không đầy đủ (IET)
28 Nêu công thức khiếm khuyết của một sản phẩm ở một pha phát triển? và công thức tính khiếm khuyết của sản phẩm cuối cùng? Giải thích ý nghĩa của nó?
- Người phát triển cần phải tính chỉ số khiếm khuyết cho mỗi bước chính phát triểnphần mềm
- Các thông tin để tính mức độ khiếm khuyết
+ Di= tổng số các khiếm khuyết
+ Si= số các khiếm khuyết nghiêm trọng
+ Mi= Số các khiếm khuyết vừa phải
