Nhập môn Công nghệ phần mềm - Chương 8: Quản lý chất lượng phần mềm

Nội dung text: Nhập môn Công nghệ phần mềm - Chương 8: Quản lý chất lượng phần mềm

1. 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ì ENGINEERING) 1 2 1 2 1. Mô hình V & V 1. Mô hình V & V • 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 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 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
2. 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ử 3. Kỹ thuật thiết kế trường hợp thử và các phương pháp kiểm thử 4. Kiểm thử module 5. Kiểm thử hệ thống 6. Kiểm thử chấp nhận • Bảo trì 5 6 5 6 1. Khái niệm kiểm thử Khó khăn • 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 • 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 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
3. 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 4. Dữ liệu thử cho kết quả bình thường thì không có ý nghĩa nhiều, Thiết kế lô gíc cần có những dữ liệu kiểm thử mà phát hiện ra lỗi Kiểm thử Kiểm thử 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ý mà phải thiết kế trước cả dữ liệu kết quả sẽ có tích hợp hồi quy 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ị và đặc tả module chương trình Mã hoá module 9 chương trình 10 9 10 2. Phương pháp kiểm thử Kiểm thử trên máy 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 để 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 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
4. Statement Coverage begin Begin Statement Coverage Ví dụ: Statement coverage if ( y >= Trình0) tự kiểm thử bằngy >= 0máy yes Begin begin 1.thenThiết ykế =trường 0; hợp thử 5. Nhập dữ liệu đã thiếty =kế 0cho BeginBegin Begin x = 0) no yes abs = y; if ( yif >=( x 20) { y >=&& 0 yes abs = y then y = 0; x 20) { y>20no yes kết quả kỳ vọng sẽ thu được hiện module tải (tạo thủ tục Abs = y; && end; then y = 0; y = 0y>20 3. Dịch chươngtesttrình case-1: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); input: y = 0chương trình) abs = y; z=fie (x,y) z=foo (x,y) tạo module tải để thực hiện } z = foo (x,y); else z =fie (x,y); abs = y 4. Khi trường hợp thử cóexpectedxử lý 7. result:Thực 0hiện module tải và ghi end; z=fie (x,y) z=foo (x,y) nhận kết quả end; } test case-1: tệp vào-ra, phải làm trướcactual result: ? Test case-1: 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: y = test0 case-2: 2001-10-10của các tệp PUM-I, Mariam Kamkar, IDAkỳ vọng 5 input:expected y = 0 result: 0 input:test case-1: x = -4, y = 30 input:test case-2: x = 12, y = 12 expected result:actual result: ? expected result: 9. Lặp lại thao tác (5)-(8) input:expected x = -4,-result: y = 30 0 input: x = 12, y = 12 2001-10-10actual result: PUM-I, Mariam ? Kamkar, IDAactual result: ? 5 expectedactual result: ? expected result: actual result: ? actual result: ? 13 2001-10-10 PUM-I, Mariam Kamkar, IDA 7 14 2001-10-10 PUM-I, Mariam Kamkar, IDA 7 13 14 Branch Coverage Ví dụ: Branch coverage Ví dụCondition: BranchCondition/branch Coverage/ Branch Coverage coverage Begin begin Condition / Branch Coverage BeginBegin if ( yBegin >= 0) Begin no begin yes if ( x 20) { x = 0) if If( (xy =10 && Begin 0)y > 20) y >= 0 yes z = foo (x,y); else z =fie (x,y); no thenthen y =y = 0; z = foo(x,y);if ( x 20) { no y > 20 yes y >= 0 x yes 20 End; } end; abs = y x 20 yes end; end; absz=fie = y (x,y) z=foo (x,y) Test case-2: test-case-1: t t Testtest case case-1:-1: test case-2: test case-1: x 20 input: y = 0 input:input: y y = = - 5-5 test-case:2 t f input: y = 0 test-case-3:input: y = f0 t input: y = -5 expected result: 0 expected result: 5 expectedtest-case-1: result: 0 t t expected result: 5 expected-result: 0 expected-result: 5 test-case-4test-case:2 f f t f actual result: ? actual result: ? actual result: ? actual result: ? actual result: ? actual result: ? 2001-10-10test-case-3: PUM-I, fMariam Kamkar, t IDA 8 2001-10-10 PUM-I, Mariam Kamkar, IDA 6 2001-10-10test-case-4 PUM-I, Mariam Kamkar, f IDA f 6 15 16 2001-10-10 PUM-I, Mariam Kamkar, IDA 8 15 16 4 3 3 4
5. 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 • 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 trắng (white box test): HOW ? Kết quả Hộp đen • Kiểm thử Top-Down hay Bottom-Up Chiến lược kiểm tra dữ liệu hộp đen 17 18 17 18 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) (Boundary value analysis) • 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 • Thực hiện: Chia dữ kiệu vào thành các đoạn, hay >12 là không hợp lệ 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
6. 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 • Nhược điểm: không phát hiện hết lỗi NOT DO UNTIL OR 21 22 21 22 3.2. Kiểm thử hộp trắng Kiểm thử hộp trắng (tiếp) • Là phương pháp kiểm thử dựa vào cấu trúc • Người KSPM có thể đảm bảo: – Kiểm tra tất cả các lộ trình độc lập bên trong 1 mô đun điều khiển của các thủ tục để thiết kế các ít nhất 1 lần 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 – 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. h h h h • 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
7. 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 11 2 í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 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ự 9 thực hiện). 10 25 26 25 26 Ví dụ: Đồ thị chương trình Chú ý 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 2, trong thủ tục). 3 • Vùng bao bởi các cung và nút gọi là Region (khi 4, 6 tính, ta phải tính cả vùng bao ngoài). 3 5 • 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 sánh) thì mỗi so sánh lại tách thành 1 nút riêng. 9 10 4 • Thí dụ: If a OR b then X else Y Endif 11 27 28 27 28
8. Độ 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 – 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. • 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. • Đồ 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 29 30 29 30 Thí dụ: chương trình viết bằng PDL Lời giải 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) = Minimum And value(i) 0 Then Average = Sum / TotalValid 11 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
9. 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) – 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) 33 34 33 34 a. Kiểm thử dưới lên Kiểm thử dưới lên (Tiếp) (Bottom-up Test) • Các module mức thấp được tổ hợp vào các chùm thực hiện một chức năng con Mức 4 • Viết trình điều khiển phối hợp vào/ ra và kiểm 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
10. 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ó • Thay các nút con bằng các module thực tại (theo chiều sâu / ngang) Mức 1 Mức 2 • 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 • Kiểm thử hồi quy 37 38 37 38 c. Kiểm thử cột trụ (Big bang Test) d. Kiểm thử kẹp (Sandwich Test) • 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 • 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 • 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
11. 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 • Kiểm thử gay cấn • Kiểm thử hiệu năng 41 42 41 42 Chương 8: Quản lý chất lượng phần 1. Khái niệm mềm • 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, các loại tư liệu đặc tả, . . .) theo những lý do • Bảo trì 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
12. 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 đủ – Lỗi tiềm ẩn của phần mềm do – Tính tương tác • Thay đổi phần mềm thích nghi với môi trường: 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 mềm: không đáp ứng được yêu • Những nguyên nhân chính: 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 triển phần mềm (trước đó). – Thay đổi về phần mềm (môi trường): đổi OS – Thay đổi cấu trúc tệp hoặc mở rộng CSDL 45 46 45 46 c. Bảo trì để cải tiến d. Bảo trì để phòng ngừa • 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 tương lai của phần mềm thay đổi sẽ có của người đủ hơn, hợp lý hơn. 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. – 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 • phương thức truy cập tệp. Thực ra trong khi thiết kế trên thiết kế không tường – Suy dẫn ra biểu thức Bun cho phần mềm đã phải tính minh. – Mở rộng thêm chức năng mới 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 tiến tư liệu vận hành và trình – Tái cấu trúc phần mềm nên thực tế ít khi ta gặp 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
13. 2. Quy trình nghiệp vụ Sơ đồ bảoThực thi “trên trì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 có liệu • Quy trình bảo trì: quá trình trong vòng đời của phần mềm, -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 2 Phát triển phần -Dò đọc chương trình nguồn, hiểu trình tự xử lý chi Loại bảo trì? 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 – 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ó -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ì 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 báo, phiên bản, . . .) Thực thi: thay thế mã nguồn và kiểm soát từng đơn vị thành 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 – 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ả. 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 49 50 Sơ đồ bảoBằng kiểm thửtrìtích hợp 3. Các vấn đề còn tồn tại Hiểu phần mềm đã -Đưa đơn vị (unit) đã dược kiểm thử vào hoạt có động trong hệ thống -Điều chỉnh sự tương tích giữa các module • Phương pháp cải tiến thao tác bảo trì: -Dùng các dữ liệu trước đây khi kiểm thử để kiểm 2 Phát triển phần thử lại tính nhất quán Loại bảo trì? – Sáng kiến trong quy trình phát triển phần mềm mềm mới ! Chú ý hiệu ứng làn sóng trong chỉnh sửa 1 – Sáng kiến trong quy trình bảo trì phần mềm 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 Để quản lý tình trạng bảo trì, lập biểu: Kiểm thử sau bảo 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ì -Số công 51 52 51 52
14. 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 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ì • 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 giai đoạn phát triển. 53 54 53 54 c. Phát triển những kỹ thuật mới cho Bài tập về nhà bảo trì • 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. • Quản lý tài liệu, quản lý dữ liệu, quản lý 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
15. 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ì 1. Khái niệm Kiểm thử 2. Quy trình nghiệp vụ Đá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 Mỗi vòng lặp tạo ra mềm một phiên bản thực thi 57 58 57 58 RUP Agile Phát triển lặp 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ụ 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
16. 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 – Phát hiện lỗi và cô lập – Cập nhật cấu hình thành phần – Theo dõi và kiểm tra các hành vi hệ thống – Kiểm thử các thành phần 61 62 61 62 c. Mã nguồn mở Kiểm thử và bảo trì • 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 – Phiên bản ngày tháng giá phần mềm – Thực hiện sau khi phần – Thực hiện trong và mềm được đưa vào sử – Chờ đợi dịch vụ dụng sau quá trình phát triển phần mềm 63 64 63 64