Bài giảng Nhập môn công nghệ phần mềm (Introduction to software engineering): Chương 9 - Nguyễn Nhất Hải

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

Thêm vào BST

Báo xấu

38
lượt xem 3
download

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

Chương 9 cung cấp cho người học những kiến thức cơ bản về quản lý chất lượng phần mềm như: Mô hình V & V, khái niệm kiểm thử phần mềm, phương pháp kiểm thử, kỹ thuật thiết kế trường hợp thử và các phương pháp kiểm thử, kiểm thử module, kiểm thử hệ thống, kiểm thử chấp nhận, bảo trì phần mềm.

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 Nhập môn công nghệ phần mềm (Introduction to software engineering): Chương 9 - Nguyễn Nhất Hải

Chương 8: Quản lý chất lượng phần mềm NHẬP MÔN • Mô hình V & V CÔNG NGHỆ PHẦN MỀM • Kiểm thử (INTRODUCTION TO SOFTWARE • Bảo trì om ENGINEERING) .c ng co 1 2 an 1 2 th 1. Mô hình V & V o ng 1. Mô hình V & V du • Mô hình V cũng được gọi là • Mô hình V – Xác minh (verification) : Xác minh là một kỹ thuật – Xác minh (verification) : Xác minh là một kỹ thuật phân tích tĩnh. Trong kiểm thử, kỹ thuật này được phân tích tĩnh. Trong kiểm thử, kỹ thuật này được u thực hiện mà không phải chạy code. Nó bao gồm một thực hiện mà không phải chạy code. Nó bao gồm một cu số hoạt đông như xem lại (review), kiểm tra số hoạt đông như xem lại (review), kiểm tra (inspection) và kiểm tra từ đầu tới cuối (walkthrough). (inspection) và kiểm tra từ đầu tới cuối (walkthrough). – Xác nhận (validation): Xác nhận là một kỹ thuật phân – Xác nhận (validation): Xác nhận là một kỹ thuật phân tích động, trong đó việc kiểm thử được thực hiện tích động, trong đó việc kiểm thử được thực hiện bằng cách thực hiện code. Ví dụ bao gồm kỹ thuật bằng cách thực hiện code. Ví dụ bao gồm kỹ thuật kiểm tra chức năng (function) và phi chức năng (non- kiểm tra chức năng (function) và phi chức năng (non- function). function). 3 4 3 4 CuuDuongThanCong.com https://fb.com/tailieudientucntt
Chương 8: Quản lý chất lượng phần 1. Mô hình V & V mềm • Mô hình V & V • Kiểm thử 1. Khái niệm kiểm thử 2. Phương pháp kiểm thử om 3. Kỹ thuật thiết kế trường hợp thử và các phương pháp kiểm thử .c 4. Kiểm thử module 5. Kiểm thử hệ thống 6. Kiểm thử chấp nhận ng • Bảo trì co 5 6 an 5 6 th 1. Khái niệm kiểm thử o ng Khó khăn du • Là mấu chốt của đảm bảo chất lượng phần • Nâng cao chất lượng phần mềm nhưng không mềm vượt quá chất lượng khi thiết kế: chỉ phát hiện u • Là tiến trình (và là nghệ thuật) nhằm phát các lỗi tiềm tàng và sửa chúng cu hiện lỗi bằng việc xem xét lại đặc tả, thiết kế • Phát hiện lỗi bị hạn chế do thủ công là chính và mã nguồn. • Dễ bị ảnh hưởng tâm lý khi kiểm thử • Kiểm thử thành công là phát hiện ra lỗi; kiểm • Khó đảm bảo tính đầy đủ của kiểm thử thử không phát hiện ra lỗi là kiểm thử dở 7 8 7 8 CuuDuongThanCong.com https://fb.com/tailieudientucntt
Tương ứng giữa vòng đời dự án và Lưu ý khi kiểm thử kiểm thử 1. Chất lượng phần mềm do khâu thiết kế quyết định là chủ yếu, chứ không phải khâu kiểm thử Đối tượng và phạm vi Kiểm thử chấp nhận 2. Tính dễ kiểm thử phụ thuộc vào cấu trúc chương trình 3. Người kiểm thử và người phát triển nên khác nhau Đặc tả chức năng/ Kiểm thử hệ thống Thiết kế lô gíc 4. Dữ liệu thử cho kết quả bình thường thì không có ý nghĩa nhiều, om cần có những dữ liệu kiểm thử mà phát hiện ra lỗi 5. Khi thiết kế trường hợp thử, không chỉ dữ liệu kiểm thử nhập vào, Thiết kế Vật lý Kiểm thử Kiểm thử .c tích hợp hồi quy mà phải thiết kế trước cả dữ liệu kết quả sẽ có 6. Khi phát sinh thêm trường hợp thử thì nên thử lại những trường hợp thử trướcđó để tránh ảnh hưởng lan truyền sóng Cấu trúc chương trình Kiểm thử đơn vị ng và đặc tả module chương trình co Mã hoá module 9 chương trình 10 an 9 10 th 2. Phương pháp kiểm thử o ng Kiểm thử trên máy du Kiểm thử tĩnh • Gỡ lỗi bằng máy (machine debug) hay kiểm • Kiểm thử trên bàn: giấy và bút trên bàn, thử động: Dùng máy chạy chương trình để u kiểm tra logic, lần từng chi tiết ngay sau khi điều tra trạng thái từng động tác của chương cu lập trình xong. trình • Đi xuyên suốt (walk through) • 9 bước của trình tự kiểm thử bằng máy: • Thanh tra (inspection) 11 12 11 12 CuuDuongThanCong.com https://fb.com/tailieudientucntt
begin Begin Statement Coverage if ( y >= Trình 0) tự kiểm thử bằng y >= 0máy yes Ví dụ: Statement coverage Begin begin 1.then Thiếtykế= 0; hợp thử trường y =kế0cho 5. Nhập dữ liệu đã thiết Begin Begin Begin abs = y;theo thử trên bàn trường hợp kiểm thử abs môi = ytrường thực if If((yyif>=>= 0) ( x < 0) 10 && y > 20) { x=&&0 no yes yes 2. Trường hợp thử phải có cả 6. Điều chỉnh then y = 0; x 20) { y>20 no && yes end; kết quả kỳ vọng sẽ thu được hiện module tải (tạo thủ tục Abs = y; then y = 0; y = 0y>20 3. test case-1: Dịch chương trình nguồn và đưa các tệp truy cập tệp vào End;z = foo (x,y); else z =fie (x,y); om hiện y = 0 chương trình) tạo module tải để thựcinput: abs = y; z = foo (x,y); else z =fie (x,y); z=fie (x,y) abs = y z=foo (x,y) } 4. Khi trường hợp thử cóexpected xử lý 7.result: Thực0hiện module tải và ghi end;end; } z=fie (x,y) z=foo (x,y) actual result:nhận tệp vào-ra, phải làm trước ? kết quả test case-1: .c Test case-1: input: y = test 0 case-2: trên bàn việc xác định miền 8. Xác nhận kết quả với kết quả test end; case-1: input: x =input: y = 0result: 0input: x = 12, y = 12 2001-10-10 PUM-I, Mariam Kamkar, IDA 5 của các tệp kỳ vọng -4,expected y = 30 test case-1: test case-2: ng 9. Lặp lại thao tác (5)-(8) expected result:actual ... result: ? expected result: ... expected-result: input: x = -4, y = 30 0 input: x = 12, y = 12 2001-10-10 actual result: ? Kamkar, IDA PUM-I, Mariam actual result: ? 5 expected result: actual result: ? ... expected result: ... co 2001-10-10 actual result: ? PUM-I, Mariam Kamkar, IDA actual result: 7 ? 13 14 an 2001-10-10 PUM-I, Mariam Kamkar, IDA 7 13 14 th Branch Coverage Begin Ví dụ: Branch coverage begin o ng Ví dụ:Condition Begin Condition/branch Branch Coverage coverage / Branch Coverage Condition / Branch Coverage Begin du if ( yBegin >= 0) Begin if ( x < 10 && y > 20) { no begin yes x < 10 If (y >= 0) y >= 0 10 &&Begin if If((xy< >= 0) y > 20) thenthen y =y = 0; 0; yes z = foo (x,y); else z =fie (x,y); z = foo(x,y);if ( x < 10 && y > 20) { y >= 0 no xy yes > 20 yes no u Else} then y = 0; < 10 Abs = y; no abs =End;y; y=0 z = foo (x,y); else z =fie (x,y);no cu no yes absz =end; =fie(x,y); y; } z=fie (x,y) y = 0 (x,y) y > 20 z=foo end; End; abs = y end; x20 yes end; ----------------------------------- abs = y(x,y) z=fie z=foo (x,y) Testtestcase-1: case-1: Testcase-2: test case-2: test-case-1: t t x20 test case-1: f test case-2: input: y =y0= 0 input: input: input: yy==-5-5 test-case:2 t ----------------------------------- input: y =f0 input: y = -5 test-case-3: test-case-1: t t t expected result: expected-result: 0 0 expected result: 55 expected-result: expected test-case-4 result: f 0f expected result: 5 test-case:2 t f actual result: ? actual result: ? actual result: ? actual result: ? actual result: ? actual result: ? 2001-10-10 test-case-3: f t PUM-I, Mariam Kamkar, IDA 8 2001-10-10 PUM-I, Mariam Kamkar, IDA 6 2001-10-10 PUM-I, Mariam Kamkar, IDA 6 test-case-4 f f 15 16 2001-10-10 PUM-I, Mariam Kamkar, IDA 8 15 16 CuuDuongThanCong.com https://fb.com/tailieudientucntt
3. Kỹ thuật thiết kế trường hợp thử 3.1. Kiểm thử hộp đen và các phương pháp kiểm thử • Kỹ thuật thiết kế trường hợp thử dựa trên đặc • Phân đoạn tương đương tả bề ngoài của chương trình: Kiểm thử hộp • Phân tích giá trị biên đen (Black box test): WHAT ? • Đoán lỗi om • Kỹ thuật thiết kế trường hợp thử dựa trên đặc • Và 1 số kỹ thuật khác tả bên trong của chương trình: Kiểm thử hộp Đầu vào Kết quả trắng (white box test): HOW ? .c Hộp đen • Kiểm thử Top-Down hay Bottom-Up ng Chiến lược kiểm tra dữ liệu hộp đen co 17 18 an 17 18 th a. Phương pháp phân đoạn tương b. Phương pháp phân tích giá trị biên đương (Equivalence Partition) o ng (Boundary value analysis) du • Mục đích: giảm số lượng test bằng cách chọn • Là 1 trường hợp riêng của phân đoạn các tập dữ liệu đại diện • Thí dụ: nếu miền dữ liệu là tháng thì giá trị 0 u • Thực hiện: Chia dữ kiệu vào thành các đoạn, hay >12 là không hợp lệ cu mỗi đoạn đại diện cho một số dữ liệu => việc kiểm thử chỉ thực hiện trên đại diện đó • Thường sử dụng trong kiểm thử module • Ưu điểm: Test theo mức trừu tượng hơn là trường. • Áp dụng: màn hình, menu hay mức quá trình. • Ví dụ: 19 20 19 20 CuuDuongThanCong.com https://fb.com/tailieudientucntt
c. Phương pháp đoán lỗi d. Phương pháp đồ thị nguyên nhân - (Error Guessing) kết quả (Cause-effect Graphing) • Dựa vào trực giác và kinh nghiệm SEQUENCE • Thí dụ lỗi chia cho 0. Nếu module có phép chia AND thì phải kiểm thử lỗi này om NOT • Nhược điểm: không phát hiện hết lỗi .c DO UNTIL OR ng co 21 22 an 21 22 th 3.2. Kiểm thử hộp trắng o ng Kiểm thử hộp trắng (tiếp) du • Là phương pháp kiểm thử dựa vào cấu trúc • Người KSPM có thể đảm bảo: điều khiển của các thủ tục để thiết kế các – Kiểm tra tất cả các lộ trình độc lập bên trong 1 mô đun ít nhất 1 lần u trường hợp kiểm thử. – Kiểm tra tất cả các nhánh đúng/sai của lựa chọn cu – Kiểm tra việc thực hiện của vòng lặp tại các biên và bên trong vòng lặp – Kiểm tra các cấu trúc dữ liệu để đảm bảo tính hợp Đầu vào Kết quả thức. hh hh • Các kỹ thuật: – Kiểm thử theo lộ trình (Basis path testing) Chiến lược kiểm tra dữ liệu hộp trắng – Kiểm thử theo cấu trúc điều khiển. 23 24 23 24 CuuDuongThanCong.com https://fb.com/tailieudientucntt
a. Kiểm thử theo lộ trình Ví dụ: lưu đồ khối chương trình • Là kỹ thuật do Tom McCabe đề xuất cho phép nhà kiểm thử tiến hành 1 số đo về độ phức tạp lô gic của các thủ tục và số đo này được sử dụng để 1 giúp cho việc định nghĩa các lộ trình cơ bản sao cho các lệnh trong chương trình được thực hiện 2 11 om ít nhất 1 lần trong quá trình kiểm thử. 3 • Sử dụng Ký pháp đồ hoạ luồng/ đồ thị chương 6 4 .c trình: – Mỗi nút đồ thị biểu diễn 1 lệnh/ 1 dãy lệnh liên tiếp 7 8 5 – Cung của đồ thị biểu diễn luồng điều kiện (trình tự ng 9 thực hiện). 10 co 25 26 an 25 26 th Ví dụ: Đồ thị chương trình o ng Chú ý du 1 • Một cung bao giờ cũng phải kết thúc tại 1 nút (có thể nút này không tương ứng với bất kỳ lệnh nào trong thủ tục). u 2, • Vùng bao bởi các cung và nút gọi là Region (khi 3 cu 6 3 4, 5 tính, ta phải tính cả vùng bao ngoài). • Thí dụ đồ thị chương trình ở slide trước gồm 4 7 2 8 1 vùng (các số in nghiêng). • Với điều kiện phức tạp (nhiều hơn 1 phép so 9 10 sánh) thì mỗi so sánh lại tách thành 1 nút riêng. 4 • Thí dụ: If a OR b then X else Y Endif 11 27 28 27 28 CuuDuongThanCong.com https://fb.com/tailieudientucntt
Độ phức tạp lặp (Cyclomatic Độ phức tạp lặp Complexity) • Độ phức tạp lặp là 1 số đo phần mềm, cung cấp 1 đơn • Có 3 cách tính độ phức tạp lặp ký hiệu V(G): vị đo định lượng về độ phức tạp lô gic của CT. – V(G) = E – N +2, với E là số cung, N là số nút của G • Trong ngữ cảnh áp dụng kiểm thử theo lộ trình, giá trị này sẽ cung cấp số lượng các lộ trình (path) độc lập – V(G) = số vùng (region) trong 1 chương trình và đó được coi như là cận trên om – V(G) = P +1, với P là số lượng nút Predicat (nút giả của số lượng test phải tiến hành để đảm bảo mọi lệnh định, không có thật). đều được thực hiện ít nhất 1 lần. .c • Lộ trình độc lập? 1 phần của CT bao gồm ít nhất 1 tập lệnh hay 1 điều kiện mới. ng • Đồ thị CT trên có 4 lộ trình độc lập: 1-11; 1-2-3-4-5-10- 1-11; 1-2-3-6-8-9-10-1-11; 1-2-3-6-7-9-10-1-11 co 29 30 an 29 30 th Thí dụ: chương trình viết bằng PDL o ng Lời giải du i=1 1 TotalInput = TotalValid = 0 2 • Số lộ trình độc lập (độ phức tạp lặp) = 6 Sum = 0 While value(i) -999 And TotalInput < 100 Do 3 – 1-2-10-11-13; 1-2-10-12-13 u 4 TotalInput = TotalInput +1 – 1-2-3-10-11-13; 1-2-3-4-5-8-9-2 … cu If Value(i) >= Minimum And value(i) 0 Then Average = Sum / TotalValid 11 • Đồ thị chương trình ? Else Average = -999 12 • Số test phải thực hiện: 6 Endif 13 LastUpdate 8-07 Dept. of SE, 2001 SE-V.31 32 31 32 CuuDuongThanCong.com https://fb.com/tailieudientucntt
3.3. Trình tự thiết kế kiểm thử 4. Kiểm thử module • Kiểm thử module • Kiểm thử tích hợp module • Kiểm thử tích hợp – Kiểm thử dưới lên (Bottom-up Test) – Kiểm thử tích hợp trên xuống – Kiểm thử trên xuống (Top-down Test) om – Kiểm thử tích hợp dưới lên – Kiểm thử cột trụ (Big bang Test) – Kiểm thử hồi qui – Kiểm thử kẹp (Sandwich Test) .c ng co 33 34 an 33 34 th a. Kiểm thử dưới lên (Bottom-up Test) o ng Kiểm thử dưới lên (Tiếp) du • Các module mức thấp được tổ hợp vào các Mức 4 chùm thực hiện một chức năng con u • Viết trình điều khiển phối hợp vào/ ra và kiểm cu Mức 3 thử • Kiểm thử chùm/bó Mức 2 • Loại bỏ trình điều khiển và chuyển lên mức trên Mức 1 35 36 35 36 CuuDuongThanCong.com https://fb.com/tailieudientucntt
b. Kiểm thử trên xuống Kiểm thử trên xuống (tiếp) (Top-down Test) • module điều khiển chính được dùng như trình điều khiển kiểm thử, gắn các nút con trực tiếp vào nó om • Thay các nút con bằng các module thực tại Mức 1 (theo chiều sâu / ngang) Mức 2 .c • Kiểm thử từng module được gắn vào Mức 3 • Các 1 nút thử xong được thử tiếp nút khác Mức 4 ng • Kiểm thử hồi quy co 37 38 an 37 38 th c. Kiểm thử cột trụ (Big bang Test) o ng d. Kiểm thử kẹp (Sandwich Test) du • Tích hợp không tăng dần • Tích hợp trên xuống cho các mức trên cấu trúc • Tất các các module đều được tổ hợp trước chương trình u • Toàn bộ chương trình được kiểm thử tổng thể • Tích hợp dưới lên cho các mức phụ thuộc cu • Khó khăn: khó cô lập lỗi, khi chữa xong lỗi này có thể lỗi mới lại phát sinh 39 40 39 40 CuuDuongThanCong.com https://fb.com/tailieudientucntt
5. Kiểm thử hệ thống 6. Kiểm thử chấp nhận • Kiểm thử phục hồi: bắt buộc phần mềm hỏng • Mục đích: để bàn giao PM cho khách hàng nhiều cách để kiểm chứng phục hồi • Đối tượng: Cần có sự tham gia của ND • Kiểm thử an toàn: kiểm chứng cơ chế bảo vệ • Trình tự: Dựa vào Yêu cầu PM om • Kiểm thử gay cấn • Kiểm thử hiệu năng .c ng co 41 42 an 41 42 th Chương 8: Quản lý chất lượng phần mềm o ng 1. Khái niệm du • Mô hình V & V • Bảo trì là công việc tu sửa, thay đổi phần mềm • Kiểm thử đã được phát triển (chương trình, dữ liệu, JCL, u các loại tư liệu đặc tả, . . .) theo những lý do • Bảo trì cu nào đó. 1. Khái niệm • Các hình thái bảo trì: bảo trì để 2. Quy trình nghiệp vụ – Tu chỉnh 3. Các vấn đề còn tồn tại – Thích nghi 4. Bảo trì trong các phương pháp phát triển phần – Cải tiến mềm – Phòng ngừa 43 44 43 44 CuuDuongThanCong.com https://fb.com/tailieudientucntt
a. Bảo trì để tu sửa b. Bảo trì để thích hợp • Là bảo trì khắc phục những • Kỹ nghệ ngược (Reverse khiếm khuyết có trong phần Engineering): dò lại thiết kế để • Là tu chỉnh phần mềm theo thay đổi của môi mềm. tu sửa. trường bên ngoài nhằm duy trì và quản lý phần • Một số nguyên nhân điển hình • Những lưu ý – Kỹ sư phần mềm và khách hiểu – Mức trừu tượng mềm theo vòng đời của nó. nhầm nhau. – Tính đầy đủ • Thay đổi phần mềm thích nghi với môi trường: om – Lỗi tiềm ẩn của phần mềm do – Tính tương tác sơ ý của lập trình hoặc khi kiểm thử chưa bao quát hết. – Tính định hướng công nghệ phần cứng, môi trường phần mềm. – Vấn đề tính năng của phần • Những nguyên nhân chính: .c mềm: không đáp ứng được yêu cầu về bộ nhớ, tệp, . . . Thiết kế sai, biên tập sai . . . – Thay đổi về phần cứng (ngoại vi, máy chủ,. . .) – Thiếu chuẩn hóa trong phát – Thay đổi về phần mềm (môi trường): đổi OS ng triển phần mềm (trước đó). – Thay đổi cấu trúc tệp hoặc mở rộng CSDL co 45 46 an 45 46 th c. Bảo trì để cải tiến o ng d. Bảo trì để phòng ngừa du • Là việc tu chỉnh hệ phần • Còn gọi là tái kỹ nghệ (re- • Là công việc tu chỉnh • Mục đích: sửa đổi để mềm theo các yêu cầu ngày engineering) chương trình có tính đến thích hợp với yêu cầu càng hoàn thiện hơn, đầy • Mục đích: đưa ra một thiết đủ hơn, hợp lý hơn. tương lai của phần mềm thay đổi sẽ có của người u kế cùng chức năng nhưng • Những nguyên nhân chính: có chất lượng cao hơn. đó sẽ mở rộng và thay đổi dùng. cu – Do muốn nâng cao hiệu suất • Các bước thực hiện: như thế nào. • Thực hiện những thay đổi nên thường hay cải tiến – Xây dựng lưu đồ phần mềm • Thực ra trong khi thiết kế trên thiết kế không tường phương thức truy cập tệp. – Mở rộng thêm chức năng mới – Suy dẫn ra biểu thức Bun cho phần mềm đã phải tính minh. từng dãy xử lý cho hệ thống. – Biên dịch bảng chân lí đến tính mở rộng của nó, • Hiểu hoạt động bên trong – Cải tiến quản lý kéo theo cải nên thực tế ít khi ta gặp tiến tư liệu vận hành và trình – Tái cấu trúc phần mềm chương trình tự công việc. bảo trì phòng ngừa nếu • Thiết kế / lập trình lại. – Thay đổi người dùng hoặc như phần mềm được thay đổi thao tác. thiết kế tốt. • Sử dụng công cụ CASE 47 48 47 48 CuuDuongThanCong.com https://fb.com/tailieudientucntt
2. Quy trình nghiệp vụ Sơ đồ bảo trì Thực thi “trên bàn”: Hiểu phần mềm đã -Nắm vững các chức năng của hệ thống theo tài liệu • Quy trình bảo trì: quá trình trong vòng đời của phần mềm, có -Nắm vững đặc tả chi tiết, điều kiện kiểm thử, . . . cũng tuân theo các pha phân tích, thiết kế, phát triển và theo tài liệu kiểm thử từ khi phát sinh vấn đề cho đến khi giải quyết Loại bảo trì? 2 Phát triển phần -Dò đọc chương trình nguồn, hiểu trình tự xử lý chi xong. mềm mới tiết của hệ thống • Các nhiệm vụ bảo trì: 1 -Khi thêm chức năng mới phải phát triển chương om – Phân tích/cô lập: phân tích tác động, phân tích những giá trị lợi Tu sứa phần mềm trình cho phù hợp với yêu cầu -Cần tiến hành từ thiết kế, lập trình, gỡ lỗi và kiểm ích, và cô lập các thành phần cần bảo trì đã có thử unit – Thiết kế: thiết kế lại hệ thống (phải biết cách tu sửa, thay đổi). -Phản ảnh vào giao diện của phần mềm (thông Kiểm thử tính nhất – Thực thi: thay thế mã nguồn và kiểm soát từng đơn vị thành .c báo, phiên bản, . . .) quán phần hệ thống, có tính đến thời gian lập trình. • Thao tác bảo trì: Gồm 2 loại Kiểm thử sau bảo -Bảo trì chương trình nguồn, tạo các module mới ng – Tu chỉnh cải đã có (loại 1) trì và dịch lại. -Thực hiện kiểm thử unit và tu chỉnh những mục – Thêm cái mới (loại 2) liên quan có trong tư liệu đặc tả. co Tạo biểu quản lý bảo -Chú ý theo sát tác động của module được sửa trì đến các thành phần khác trong hệ thống. 49 50 an 49 50 th Hiểu phần mềm đã Sơ đồ bảo trì Bằng kiểm thử tích hợp o ng -Đưa đơn vị (unit) đã dược kiểm thử vào hoạt 3. Các vấn đề còn tồn tại du có động trong hệ thống -Điều chỉnh sự tương tích giữa các module -Dùng các dữ liệu trước đây khi kiểm thử để kiểm • Phương pháp cải tiến thao tác bảo trì: Loại bảo trì? 2 Phát triển phần thử lại tính nhất quán – Sáng kiến trong quy trình phát triển phần mềm u mềm mới ! Chú ý hiệu ứng làn sóng trong chỉnh sửa – Sáng kiến trong quy trình bảo trì phần mềm cu 1 Tu sứa phần mềm đã có Khi hoàn thành bảo trì: – Phát triển những kỹ thuật mới cho bảo trì -Kiểm tra nội dung mô tả có trong tư liệu đặc tả -Cách ghi tư liệu có phù hợp với mô tả môi trường Kiểm chứng tính nhất phần mềm mới hay không ? quán Kiểm thử sau bảo Để quản lý tình trạng bảo trì, lập biểu: trì -Ngày tháng, giờ -Nguyên nhân -Tóm tắt cách khắc phục Tạo biểu quản lý bảo -Chi tiết khắc phục, hiệu ứng làn sóng trì -Người làm bảo trì 51 52 -Số công 51 52 CuuDuongThanCong.com https://fb.com/tailieudientucntt
a. Sáng kiến trong quy trình b. Sáng kiến trong quy trình bảo trì phát triển phần mềm phần mềm • Chuẩn hóa mọi khâu trong phát triển phần • Sử dụng các công cụ hỗ trợ phát triển phần mềm mềm • Người bảo trì chủ chốt tham gia vào giai đoạn • Chuẩn hóa thao tác bảo trì và thiết bị môi om phân tích và thiết kế trường bảo trì • Thiết kế để dễ bảo trì • Lưu lại những thông tin sử bảo trì .c • Dự án nên cử một người chủ chốt của mình làm công việc bảo trì sau khi dự án kết thưc ng giai đoạn phát triển. co 53 54 an 53 54 th c. Phát triển những kỹ thuật mới cho bảo trì o ng Bài tập về nhà du • Công cụ phần mềm hỗ trợ bảo trì • Tìm hiểu SMMM – Software Maintenance • Cơ sở dữ liệu cho bảo trì Maturity Model. u • Quản lý tài liệu, quản lý dữ liệu, quản lý cu chương trình nguồn, quản lý dữ liệu thử, quản lý sử bảo trì • Trạm bảo trì tính năng cao trong hệ thống mạng lưới bảo trì với máy chủ thông minh. 55 56 55 56 CuuDuongThanCong.com https://fb.com/tailieudientucntt
Chương 8: Quản lý chất lượng phần a. Phát triển lặp mềm • Mô hình V & V Yêu cầu Phân tích & Thiết kế • Kiểm thử Kế hoạch ban đầu Cài đặt • Bảo trì om 1. Khái niệm Kiểm thử 2. Quy trình nghiệp vụ .c Đánh giá 3. Các vấn đề còn tồn tại Triển khai 4. Bảo trì trong các phương pháp phát triển phần ng Mỗi vòng lặp tạo ra mềm một phiên bản thực thi co 57 58 an 57 58 th Phát triển lặp RUP o ng Agile du Giá trị sản phẩm được phân phối từng bước lặp đi lặp lại Bắt đầu Khởi thảo Xây dựng Chuyển đổi Mô hình nghiệp vụ u cu Yêu cầu Phân tích và thiết kế Cài đặt Kiểm thử Triển khai Các vòng lặp Bước lặp lặp. lặp. lặp. lặp. lặp. lặp. lặp. sơ bộ(s) #1 #2 #n #n+1 #n+2 #m #m+1 59 60 59 60 CuuDuongThanCong.com https://fb.com/tailieudientucntt
Scrum b. Hướng thành phần • Những hoạt động bảo trì chính ở CBSD – Gắn kết hóa và gói hóa – May đo hóa om – Phát hiện lỗi và cô lập – Cập nhật cấu hình thành phần .c – Theo dõi và kiểm tra các hành vi hệ thống – Kiểm thử các thành phần ng co 61 62 an 61 62 th c. Mã nguồn mở o ng Kiểm thử và bảo trì du • Sự khác biệt với bảo trì theo phương pháp • Kiểm thử • Bảo trì – Thay đổi, cải tiến phần truyền thống – Phát hiện lỗi, đánh mềm đã được phát triển u – Phiên bản ngày tháng giá phần mềm – Thực hiện sau khi phần cu mềm được đưa vào sử – Chờ đợi dịch vụ – Thực hiện trong và dụng sau quá trình phát triển phần mềm 63 64 63 64 CuuDuongThanCong.com https://fb.com/tailieudientucntt