(NB) Tiếp nội dung phần 1 Bài giảng Công nghệ phần mềm: Phần 2 cung cấp các nội dung chính như: Thiết kế phần mềm, cài đặt, kiểm thử và bảo trì phần mềm. Mời các bạn cùng tham khảo để nắm chi tiết nội dung của bài giảng.
Bài giảng Công nghệ phần mềm Chương THIẾT KẾ PHẦN MỀM Thời lượng: 08 tiết lý thuyết Kết thúc chương này, sinh viên có thể: - Hiểu phải thiết kế phần mềm - Biết kiến thức phần thiết kế: liệu, xử lý, giao diện - Biết phương pháp thiết kế phần mềm - Biết thiết kế có chất lượng tốt 3.1 TỔNG QUAN 3.1.1 Khái niệm thiết kế phần mềm Trong thiết kế, định hình hệ thống tìm dạng thức (kể kiến trúc) mà đáp ứng yêu cầu, yêu cầu phi chức ràng buộc khác – đặt cho hệ thống Bản chất thiết kế phần mềm trình chuyển hóa yêu cầu phần mềm thành biểu diễn thiết kế Từ mơ tả quan niệm tồn phần mềm, việc làm mịn liên tục dẫn đến biểu diễn thiết kế gần với cách biểu diễn chương trình nguồn để ánh xạ vào ngơn ngữ lập trình cụ thể Xét cách chi tiết mục tiêu thiết kế là: - Thu hiểu biết sâu yêu cầu phi chức ràng buộc có liên quan tới ngơn ngữ lập trình, sử dụng lại thành phần, hệ điều hành, công nghệ phân tán, công nghệ CSDL, công nghệ giao diện người dùng, công nghệ quản lý giao dịch - Tạo đầu vào thích hợp xuất phát điểm cho hoạt động cài đặt sau cách nắm bắt yêu cầu hệ thống cụ thể, giao diện lớp - Có khả phân rã việc cài đặt thành mẫu nhỏ dễ quản lý nhiều đội phát triển khác xử lý tiến hành đồng thời Điều có ích trường hợp mà tiến hành phân rã kết thu từ nắm bắt yêu cầu phân tích 58 Bài giảng Cơng nghệ phần mềm - Nắm bắt sớm giao diện chủ yếu hệ thống vòng đời phần mềm Điều có ích suy luận kiến trúc sử dụng giao diện công cụ đồng phát triển khác - Trực quan hóa suy luận thiết kế cách sử dụng hệ thống ký pháp chung - Tạo trừu tượng hóa liên tục việc cài đặt hệ thống, tức cài đặt làm mịn dần thiết kế cách đắp thịt vào khung xương không thay đổi cấu trúc Hoạt động thiết kế hoạt động đặc biệt: - Là trình sáng tạo, địi hỏi có kinh nghiệm nhanh nhạy, sáng tạo - Cần phải thực hành học kinh nghiệm, khảo sát hệ thống tồn tại, học sách không đủ 3.1.2 Tầm quan trọng Tầm quan trọng thiết kế phát biểu từ “chất lượng” Thiết kế nơi chất lượng phần mềm nuôi dưỡng trình phát triển: cung cấp cách biểu diễn phần mềm xác nhận chất lượng, cách mà chuyển hóa cách xác u cầu khách hàng thành sản phẩm hay hệ thống phần mềm cuối 59 Bài giảng Cơng nghệ phần mềm Hình 1: Luồng thông tin thiết kế Thiết kế phần mềm công cụ giao tiếp làm sở để mơ tả cách đầy đủ dịch vụ hệ thống, để quản lý rủi ro lựa chọn giải pháp thích hợp Thiết kế phần mềm phục vụ tảng cho bước kỹ nghệ phần mềm bảo trì: Khơng có thiết kế, ta có nguy dựng lên hệ thống không ổn định – hệ thống thất bại có thay đổi nhỏ; hệ thống khó mà thử được; hệ thống khơng thể xác định chất lượng chừng chưa đến cuối tiến trình kiểm thử; thời gian ngắn mà khơng tiền Thiết kế tốt bước quan trọng để đảm bảo chất lượng phần mềm 3.1.3 Kết thiết kế phần mềm Kết việc thiết kế sản phẩm nói chung vẽ: vẽ nhà, vẽ máy bay, “bản vẽ phần mềm”,…Các vẽ cung cấp thông tin chi tiết cấu trúc sản phẩm tương ứng Trong lĩnh vưc tin học, thuật ngũ “bản vẽ phần mềm” không sử dụng mà thay vào thuật ngữ mơ hình phần mềm với ý nghĩa Mơ hình phần mềm cung cấp thông tin chi tiết thành phần phần mềm: - Thành phần giao diện 60 Bài giảng Công nghệ phần mềm - Thành phần xử lý - Thành phần liệu Thông tin thành phần giao diện bao gồm thông tin sau: - Nội dung hình thức trình bày hình giao tiếp phẩn mềm - Hệ thống thao tác mà người dùng thực hình giao tiếp xử lý tương ứng phẩn mềm Thông tin thành phần xử lý bao gồm thông tin sau: - Hệ thống kiểu liệu sử dụng phần mềm Các kiểu liệu mô tả cách tổ chức lưu trữ liệu nhớ phần mềm - Hệ thống hàm sử dụng phần mềm Các hàm thể tương ứng việc thực cơng việc giới thực máy tính (kiểm tra tính hợp lệ việc cho mượn sách, ghi vào sổ việc cho mượn sách,…) Thông tin thành phần liệu bao gồm thông tin liên quan đến cách thức tổ chức lưu trữ liệu (nội dung công việc ghi chép vào sổ sach giới thực) nhớ phụ - Dạng lưu trữ sử dụng phần mềm - Hệ thống thành phần lưu trữ với quan hệ chúng Bảng sau mơ tả tóm tắt kết cần có thiết kế thành phần phần mềm 61 Bài giảng Công nghệ phần mềm Bảng 1: Các kết cần có thiết kế thành phần phần mềm Thành phần Kết Kết chi tiết Thành phần giao diện Hệ thống hình Sơ đồ hình giao diện Danh sách hình Nội dung hình Biến cố xử lý hình Thành phần xử lý Hệ thống hàm Danh sách hàm với cấu trúc liệu Danh sách kiểu liệu tương ứng Mô tả chi tiết hàm Mô tả chi tiết kiểu liệu Thành phần liệu Tổ chức lưu trữ Sơ đồ (cấu trúc lưu trữ) nhớ phụ Danh sách thành phần lưu trữ Mô tả chi tiết thành phần Danh sách ràng buộc 3.1.4 Phương pháp thiết kế phần mềm Tùy thuộc vào quy trình chọn thực phần mềm, việc thiết kế tiến hành theo hai phương pháp chính: - Phương pháp trực tiếp - Phương pháp gián tiếp a Phương pháp trực tiếp Được áp dụng thực phần mềm khơng thơng qua giai đoạn phân tích Với phương pháp việc thiết kế nhận kết chuyển giao trực tiếp từ giai đoạn xác định yêu cầu Mơ hình phần mềm xây dựng trực tiếp từ yêu cầu Cách tiếp cận khó khăn cho người thực với phần mềm có quy mơ lớn (nhiều u cầu, u cầu phức tạp,…) 62 Bài giảng Công nghệ phần mềm Với phương pháp trực tiếp, thiết kế phần mềm trình cho phép chuyển đổi từ yêu cầu (kết giai đoạn xác định u cầu) đến mơ hình phần mềm tương ứng Mục tiêu việc thiết kế mô tả thành phần phần mềm (thành phần giao diện, thành phần xử lý, thành phần liệu) tương ứng với yêu cầu phần mềm (yêu cầu chức nghiệp vụ, yêu cầu chức hệ thống, yêu cầu phi chức năng) b Phương pháp gián tiếp Được áp dụng với quy trình có giai đoạn phân tích Với phương pháp việc thiết kế nhận phần kết chuyển giao trực tiếp từ giai đoạn xác định yêu cầu, phần yếu nhận gián tiếp qua giai đoạn phân tích Mơ hình phần mềm xây dựng tương ứng theo mơ hình giai đoạn phân tích Cách tiếp cận thuận lơi đa số trường hợp với phần mềm quy mô lớn Với phương pháp gián tiếp, thiết kế phần mềm q trình cho phép chuyển từ mơ hình giới thực (kết giai đoạn phân tích) đến mơ hình phần mềm tương ứng Mục tiêu việc thiết kế mô tả thành phần phần mềm (thành phần giao diện, thành phần xử lý, thành phần liệu) tương ứng với mơ hình giới thực (mơ hình xử lý, mơ hình liệu) 3.1.5 Thiết kế phần mềm yêu cầu chất lượng Khi thực thiết kế, yêu cầu chất lượng có yêu cầu riêng thành phần: liệu, xử lý, giao diện Các yêu cầu mô tả bảng bên dưới: 63 Bài giảng Công nghệ phần mềm Bảng 2: Thiết kế liệu yêu cầu chất lượng Yêu cầu chất Yêu cầu thành phần liệu phần mềm lượng Tính đắn Phù hợp với mơ hình liệu (giai đoạn phân tích) theo yêu cầu (giai đoạn xác định yêu cầu) bỏ qua giai đoạn phân tích Tính tiến hóa Có dự kiến thay đổi nội dung liệu cần lưu trữ ràng buộc tương ứng Tính hiệu Lưu trữ tốn chỗ, truy xuất nhanh Bảng 3: Thiết kế xử lý yêu cầu chất lượng Yêu cầu chất Yêu cầu thành phần xử lý phần mềm lượng Tính đắn Phù hợp với mơ hình xử lý (giai đoạn phân tích) theo yêu cầu (giai đoạn xác định yêu cầu) bỏ qua giai đoạn phân tích Tính tiến hóa Có dự kiến thay đổi quy định, quy tắc tính tốn Tính hiệu Tốc độ thực nhanh Tính tương thích Cho phép chuyển đổi liệu với phần mềm khác 64 Bài giảng Công nghệ phần mềm Bảng 4: Thiết kế giao diện yêu cầu chất lượng Yêu cầu chất Yêu cầu thành phần giao diện phần mềm lượng Tính đắn Phù hợp với mơ hình xử lý (nếu có thực giai đoạn phân tích) theo yêu cầu (giai đoạn xác định yêu cầu) bỏ qua giai đoạn phân tích Tính tiến hóa Có dự kiến thay đổi thành phần liệu xử lý Tính tiện dụng Tự nhiên, dễ học, dễ sử dụng, đầy đủ thơng tin Tính hiệu Thao tác thực nhanh, sử dụng tối ưu khơng gian Tính tương thích Sự qn hình 3.1.6 Chất lượng thiết kế Khơng có cách hay để xác định thể thiết kế tốt Tiêu chuẩn dễ bảo trì tiêu chuẩn tốt cho người dùng Một thiết kế dễ bảo trì thích nghi với việc cải biên chức việc thêm chức Một thiết kế phải dễ hiểu việc sửa đổi có hiệu ứng cục Các thành phần thiết kế phải kết dính (cohesive) theo nghĩa tất phận thành phần phải có quan hệ logic chặt chẽ, thành phần ghép nối (coupling) với lỏng lẻo Ghép nối lỏng lẻo dễ thích nghi, nghĩa dễ sửa đổi để phù hợp với hoàn cảnh Để xem thiết kế có tốt hay khơng, người ta tiến hành thiết lập số độ đo chất lượng thiết kế: a Sự kết dính (Cohesion) Sự kết dính module độ đo tính khớp lại với thành phần module Nếu module thực chức logic thực thể logic, tức tất phận module tham gia vào việc thực cơng việc đọ kết dính cao Nếu nhiều phận không tham gia trực tiếp vào việc chức logic mức độ kết dính thấp Thiết kế tốt độ kết dính cao Khi dễ dàng hiểu module việc sửa chữa module khơng (ít) ảnh hưởng tới module khác 65 Bài giảng Công nghệ phần mềm Constantine Yourdon định mức kết dính theo thứ tự tăng dần sau: Kết dính gom góp: công việc không liên quan với nhau, song lại bị bó vào module Kết dính logic: thành phần thực chức tương tự logic, chẳng hạn: vào/ra, xử lý lỗi,… đặt vào module Kết dính thời điểm: tất thành phần hoạt động lúc, chẳng hạn thao tác khởi tạo bó lại với Kết dính thủ tục: phần tử module ghép lại dãy điều khiển Kết dính truyền thơng: tất phần tử module thao tác liệu vào đưa liệu Kết dính tuần tự: module, đầu phần từ đầu vào phần từ khác Kết dính chức năng: phần module cần thiết đề thi hành chức Các lớp kết dính khơng định nghĩa chặt chẽ luôn xác định Một đối tượng kết dính thể thực thể đơn: tất phép toán thực thể nằm thực thể Vậy xác định lớp kết dính là: Kết dính đối tượng: phép tốn liên quan đến thay đổi, kiểm tra sử dụng thuộc tính đối tượng, sở cung cấp dịch vụ đối tượng b Sự ghép nối (Coupling) Ghép nối độ đo nối ghép với đơn vị (module) hệ thống HỆ thống có nối ghép cao module phụ thuộc lẫn lớn Hệ thống nối ghép lỏng lẻo module độc lập tương đối độc lập với dễ bảo trì Các module ghép nối chặt chẽ chúng dùng biến chung chúng trao đổi thông tin điều khiển (ghép nối chung ghép nối điều khiển) Ghép nối lỏng lẻo đạt bảo đảm thông tin cục che giấu 66 Bài giảng Công nghệ phần mềm moduun module trao đổi thông tin thông qua danh sách thao số (giao diện) xác định Có thể chia ghép nối thành mức từ chặt chẽ đến lỏng lẻo sau: Ghép nối nội dung: hai hay nhiều module dùng lẫn liệu nhau, mức xấu nhất, thường xảy ngơn ngữ mức thấp dùng liệu tồn cục hay lạm dụng lệnh GOTO Ghép nối chung: số module dùng biến chung, xảy lỗi thao tác liệu, khó xác định lỗi module gây Ghép nối điều khiển: module truyền thông tin điều khiển để điều khiển hoạt đọng module khác Ghép nối dư thừa: module nhận thông tin thừa không liên quan trực tiếp đến chức nó, điều làm giảm khả thích nghi module Ghép nối liệu: module trao đổi thông tin thông qua tham số giá trị trả lại Ghép nối khơng có trao đổi thơng tin: module thực chức độc lập hoàn toàn khơng nhận tham số khơng có giá trị trả lại Ưu điểm thiết kế hướng đối tượng chất che giấu thông tin đối tượng dẫn tới việc tạo hệ ghép nối lỏng lẻo Việc thừa kế hệ thống hướng đối tượng lại dẫn tới dạng khác ghép nối, ghép nối đối tượng mức cao đối tượng kế thừa c Sự hiểu (Understandability) Sự hiểu thiết kế liên quan tới số đặc trưng sau đây: - Tính kết dính: hiểu thành phần mà khơng cần tham khảo tới thành phần khác hay không? - Đặt tên: phải tên dùng thành phần có nghĩa? Tên có nghĩa tên phản ánh tên thực thể giới thực mơ hình thành phần - Soạn tư liệu: thành phần có soạn thảo tư liệu cho ánh xạ thực thể giới thực thành phần rõ ràng - Độ phức tạp: độ phức tạp thuật toán dùng để thực thành phần nào? 67 Bài giảng Cơng nghệ phần mềm Hình 8: Mơ hình minh họa kiểm thử tích hợp (từ xuống) Ưu điểm: - Kiểm thử từ xuống kết hợp với phát triển xuống giúp phát sớm lỗi thiết kế làm giảm giá thành sửa đổi - Nhanh chóng có phiên thực với chức - Có thể thẩm định tính dùng sản phẩm sớm Nhược điểm: - Nhiều module cấp thấp khó mơ phỏng: thao tác với cấu trúc liệu phức tạp, kết trả phức tạp,… Từ lên Kiểm thử tích hợp từ lên thực kiểm tra module trước khơng cần phải viết stub Thuật giải hướng là: - Các module cấp thấp nhóm thành nhóm (thực chức năng) - Viết driver điều khiển tham số nhập xuất - Bỏ driver gắn chùm vào module cao 100 Bài giảng Cơng nghệ phần mềm Hình 9: Mơ hình minh họa kiểm thử tích hợp (từ lên) Ưu điểm: - Tránh xây dựng module tạm thời phức tạp - Tránh sinh kết nhân tạo (nhập từ bàn phím) - Thuận tiện cho phát triển module để dùng lại Nhược điểm: - Chậm phát lỗi kiến trúc - Chậm có phiện thực c Kiểm thử hệ thống Đến giai đoạn này, công việc kiểm thử tiến hành với nhìn nhận phần mềm yếu tố hệ thống thơng tin phức tạp hồn chỉnh Cơng việc kiểm thử nhằm kiểm tra khả phục hồi sau lỗi, độ an toàn, hiệu giới hạn phần mềm d Kiểm thử chấp nhận Kiểm thử chấp nhận thực để trả lời cho câu hỏi: “Phần mềm có đáp ứng yêu cầu khách hàng/người dùng không? Ở mức độ này, loại kiểm thử sử dụng kiểm thử hộp đen Có hai loại kiểm thử chấp nhận: kiểm thử alpha kiểm thử beta Kiểm thử alpha Trong giai đoạn này, phần mềm kiểm thử môi trường điều khiển với liệu mô 101 Bài giảng Công nghệ phần mềm Kiểm thử beta Đây giai đoạn mở rộng kiểm thử alpha Công việc kiểm thử thực số lượng lớn người sử dụng Công việc kiểm thử tiến hành cách ngẫu nhiên mà khơng có hướng dẫn nhà phát triển Các lỗi phát thông báo lại cho nhà phát triển 4.2.5 Những lỗi phần mềm Có nhiều định nghĩa khác lỗi phần mềm Định nghĩa lỗi phần mềm dựa khái niệm đặc tả: đặc tả thống người phát triển phần mềm người phát triển phần mềm người sử dụng phần mềm Lỗi phần mềm xuất hay nhiều điều kiện sau đúng: Phần mềm không thực mà đặc tả định nghĩa Phần mềm thực mà đặc tả khuyến cáo không nên thực Phần mềm thực mà đặc tả khơng đề cập đến Phần mềm khơng thực mà đặc tả không đề cập đến lẽ nên thực Phần mềm khó hiểu hay khó sử dụng Ví dụ kiểm thử chương trình tính tốn phân số sau minh họa khái niệm lỗi Chương trình cho phép thực phép tốn phân số: rút gọn, cộng, trừ, nhân chia Đặc tả định nghĩa chương trình phải thực phép toán: rút gọn phân số, cộng, trừ, nhân chia hai phân số Nếu thực phép tốn cộng hai phân số mà chương trình khơng hiển thị hiển thị kết sai, lỗi ứng với điều kiện Đặc tả định nghĩa chương trình khơng nên chạy chế độ thường trú tiến trình Tuy nhiên, kích hoạt chương trình lại ln thường trú, làm tốn nhớ Đó lõi ứng với điều kiện Khi kiểm thử nhận thấy, phép toán rút gọn phân số, cộng, trừ, nhân chia hai phân số, cịn có phép tốn cộng, trừ, nhân chia n (n>2) phân số Vấn đề không đề cập đến đặc tả, lỗi ứng với điều kiện 102 Bài giảng Công nghệ phần mềm Sau thực phép toán nhân hai phân số 3/10 * 100/9, kết 300/90 Tuy nhiên, kết mong đợi 10/3 Mặc dù vấn đề không định nghĩa xác đặc tả, vấn đề mà chương trình nên thực Lỗi tương ứng với điều kiện Lỗi ứng với điều kiện người sử dụng chạy thử chương trình nhận thấy chương trình khơng tốt, cho dù lý Chẳng hạn, người sử dụng cho cách hiển thị phân số với màu sắc khó nhìn hay nút bấm q nhỏ, khó sử dụng Tất nhiên, mối người sử dụng có cách nhìn khác chương trình, thể khó để đáp ứng tất yêu cầu khác người sử dụng Tuy nhiên, kiểm thử phải nghĩ đến lỗi ứng với điều kiện để có chọn lựa hợp lý Ngồi ra, lĩnh vực nghiên cứu tính khả tin cậy hệ thống, ba khái niệm – sai sót, lỗi, thất bai – sử dụng nhằm thể rõ mức độ ảnh hưởng lỗi phần mềm Một sai sót (fault) nhầm lẫn hay hiểu sai trình phát triển phần mềm người phát triển Người phát triển bao gồm: người phân tích, người thiết kế, lập trình viên, kiểm thử viên hay nói cách ngắn gọn tất người tham gia vào trình phát triển phần mềm Như thế, sai sót xuất q trình phát triển phần mềm Ví dụ, người thiết kế hiểu nhầm khái niệm hay vấn đề nhỏ lập trình viên gõ nhầm câu lệnh, toán tử,… Một lỗi (error) xuất phần mềm kết sai sót Lỗi làm cho phần mềm có hoạt động không so với yêu cầu đặt Như thế, dễ nhận thấy sai sót nguyên nhân gây lỗi hay sai sót kích hoạt tạo nên lỗi Một cách cụ thể, sai sót xuất q trình phần tích, thiết kế, lập trình lỗi xuất thực thi chương trình Ví dụ, thực thi chương trình xuất thông báo lỗi Một thất bại (failure) kết lỗi xuất làm cho chương trình khơng hoạt động hay hoạt động cho kết không mong đợi Như lỗi nguyên nhân gây nên thất bại Một thất bại xảy chương trình khơng thể tiếp tục hoạt động 103 Bài giảng Công nghệ phần mềm Hình 10: Quan hệ khái niệm 4.2.6 Nguyên tắc kiểm thử Sau nguyên tắc kiểm thử Nguyên tắc 1: Kiểm thử đưa lỗi (Testing shows presence of defects) Kiểm thử phần mềm có lỗi, khơng thể chứng minh phần mềm khơng có lỗi Nó làm giảm xác suất lỗi chưa tìm thấy Nguyên tắc 2: Kiểm thử đầy đủ (Exhaustive testing is impossible) Kiểm thử thứ thực Thay kiểm thử tồn bộ, việc phân tích rủi ro dựa mức độ ưu tiên tập trung việc kiểm thử vào số điểm cần thiết Nguyên tắc 3: Kiểm thử sớm (Early testing) Để tìm lỗi sớm, hoạt động kiểm thử nên bắt đầu sớm tốt quy trình phát triển phần mềm hệ thống, nên tập trung vào hoạt động định trước Nguyên tắc 4: Sự tập trung lỗi (Defect clustering) Nỗ lực kiểm thử nên tập trung cách cân đối vào mật độ lỗi kiến lỗi phát sau mơ đun Một số mơ đun thường chứa nhiều lỗi không phát lúc kiểm thử trước phát hành, chịu trách nhiệm cho hầu hết lỗi hoạt động phần mềm Nguyên tắc 5: Nghịch lý thuốc trừ sâu (Pesticide paradox) Nếu việc kiểm thử tương tự lặp lại nhiều lần cuối có số trường hợp kiểm thử khơng tìm thấy lỗi Để khắc phục, trường hợp kiểm thử cần phải xem xét sửa đổi thường xuyên; cần phải viết trường hợp kiểm thử (test case) khác để thực nhiều phần khác phần mềm hệ thống để tìm lỗi tiềm ẩn nhiều Nguyên tắc giống việc trừ sâu nông nghiệp, phun loại thuốc với nồng độ giống khoảng thời gian dài có số sâu quen dần lờn thuốc, lúc khơng thể diệt chúng Do để 104 Bài giảng Công nghệ phần mềm diệt sâu cách hiệu quả, người ta thường thay đổi loại thuốc trừ sâu, loại dùng thời gian ngắn Nguyên tắc 6: Kiểm thử theo ngữ cảnh độc lập (Testing is context dependent) Theo nguyên tắc này, kiểm thử phụ thuộc vào ngữ cảnh phải kiểm thử nhiều ngữ cảnh khác Để hiểu rõ xét ví dụ sau: Một chương trình có tên “Calculator” có nhiều chức nhưng: - Nếu test chương trình cho mẫu giáo cần test cộng trừ - Nếu test chương trình cho cấp cộng trừ nhân chia - Nếu test chương trình cho đại học tích phân, đạo hàm… Nguyên tắc 7: Sự sai lầm việc khơng có lỗi (Absence-of-errors fallacy) Việc tìm sửa lỗi khơng giúp hệ thống xây dựng xong dùng không đáp ứng nhu cầu người dùng 4.2.7 Thiết kế test case Việc thiết kế testcase dựa vào kỹ thuật chiến lược kiểm thử Dựa vào Kiểm thử giá trị biên Một chương trình có nhiều biến đầu vào, biến đầu vào xác định giá trị liệu thử, sau kết hợp giá trị liệu thử biến để tạo nên ca kiểm thử Có hai trường hợp xem xét: - Giả thuyết “lỗi đơn” (single fault) – thất bại chương trình kết hai lỗi (hay nhiều hơn) Số liệu thử xác định qua số biến vào: chương trình có n biến vào, biến nhận giá trị min-, min, min+, max-, max, max+, biến lại nhận giá trị nom Như chương trình có n biến vào, kiểm thử giá trị biên (với giả thuyết lỗi đơn) có 6n+1 liệu thử Kiểm thử giá trị biên cho chương trình f với hai biến đầu vào gồm liệu thử sau: 105 Bài giảng Công nghệ phần mềm {, , , , , , , , , , , , } - Bỏ qua giả thuyết lỗi đơn Nếu bỏ qua giả thuyết lỗi đơn, quan tâm đến điều xảy nhiều biến đầu vào đạt đến giá trị biên Trong trường hợp này, gọi kiểm thử giá trị biên trường hợp xấu Đối với biến đầu vào, bắt đầu với tập hợp bảy giá trị min-, min, min+, nom, max-, max, max+ Chúng ta sử dụng tích Đề-các tập hợp để tạo liệu thử Như vậy, liệu thử có tính đến giả thuyết lỗi đơn tập liệu thử bỏ qua giả thuyết lỗi đơn Kiểm thử trường hợp xấu (bỏ qua giả thuyết lỗi đơn) cho chương trình có n biến vào tạo 7n liệu thử, so với 6n+1 liệu thử tính đến giả thuyết lỗi đơn Ví dụ: Áp dụng kỹ thuật kiểm thử giá trị biên để kiểm thử chương trình sau: Tính tổng hai biến đầu vào a, b kiểu số nguyên có giá trị thuộc [1, 99] Đối với Kiểm thử lớp tương đương Chẳng hạn, chương trình cần kiểm thử hàm gồm hai biến vào a b Giả sử miền liệu biến a chia thành ba lớp tương đương sau: 𝐴1 ≤ 𝑎 < 𝐴2 , 𝐴2 ≤ 𝑎 < 𝐴3 , 𝑣à 𝐴3 ≤ 𝑎 < 𝐴4 Và miền liệu biến b chia thành hai lớp tương đương sau: 𝐵1 ≤ 𝑏 < 𝐵2 𝑣à 𝐵2 ≤ 𝑏 < 𝐵3 Chúng ta ký hiệu giá trị đại diện lớp tương đương sau: 𝑎1 ∈ [𝐴1 , 𝐴2 ], 𝑎2 ∈ [𝐴2 , 𝐴3 ], 𝑎3 ∈ [𝐴3 , 𝐴4 ] 𝑏1 ∈ [𝐵1 , 𝐵2 ], 𝑏2 ∈ [𝐵2 , 𝐵3 ] Khi đó, ca kiểm thử ba loại kiểm thử lớp tương đương minh họa sau: 106 Bài giảng Công nghệ phần mềm Bảng 1: Minh họa ca kiểm thử lớp tương đương yếu Ca kiểm thử a b a1 b1 a2 b2 a3 b1 Bảng 2: Minh họa ca kiểm thử lớp tương đương mạnh Ca kiểm thử a b a1 b1 a1 b2 a2 b1 a2 b2 a3 b1 a3 b2 Đối với kiểm thử lớp tương đương truyền thống, ca kiểm thử xây dựng sau: Đối với liệu vào hợp lệ, sử dụng giá trị đại diện cho lớp tương đương, nghĩa tương tự kiểm thử lớp tương đương yếu Lưu ý tất liệu vào ca kiểm thử hợp lệ Đối với liệu vào không hợp lệ, ca kiểm thử có liệu khơng hợp lệ, liệu lại hợp lệ Trong trường hợp này, chấp nhận giả thuyết lỗi đơn Chẳng hạn, ví dụ trên, giả sử biến vào a, lớp [A2, A3] hợp lệ lớp [A1, A2] [A3, A4] không hợp lệ; biến vào b, lớp [B1, B2] hợp lệ, lớp [B2, B3] khơng hợp lệ Khi đó, kiểm thử lớp tương đương truyền thống xác định ca kiểm thử bảng sau: 107 Bài giảng Công nghệ phần mềm Bảng 3: Minh họa ca kiểm thử lớp tương đương truyền thống Ca kiểm thử a b Kết a2 b1 Hợp lệ a1 b1 Không hợp lệ a3 b1 Không hợp lệ a2 b2 Không hợp lệ 4.2.8 Lập kế hoạch tài liệu kiểm thử Kế hoạch kiểm thử cho phép xác định mục tiêu kiểm thử, đối tượng kiểm thử, kỹ thuật kiểm thử, nguồn tài nguyên, lịch kiểm thử,… Một kế hoạch kiểm thử tốt giảm chi phí, cải thiện quan hệ với lập trình viên nâng cao chất lượng kiểm thử 4.3 BẢO TRÌ PHẦN MỀM Bảo trì giai đoạn cuối chu trình phát triển phần mềm Các chương trình máy tính ln thay đổi- phải mở rộng, sửa lỗi, tối ưu hố, theo thống kê bảo trì chiếm đến 70% tồn cơng sức bỏ cho dự án phần mềm Do vậy, bảo trì hoạt động phức tạp lại vơ cần thiết chu trình sống sản phẩm phần mềm để đảm bảo cho phần mềm phù hợp với người sử dụng Do nhu cầu phát triển hệ thống thông tin, hay không muốn nói khơng thể có hệ thống thơng tin khơng có thay đổi suốt chu trình sống Để trì tính đắn, trật tự giai đoạn bảo trì quản lý thay đổi phần mềm hoạt động cần thiết song song 4.3.1 Hoạt động bảo trì phần mềm phân loại Bảo trì phần mềm phức tạp chia hoạt động bảo trì làm bốn hoạt động sau: 108 Bài giảng Công nghệ phần mềm a Bảo trì hiệu chỉnh Cơng việc bảo trì cần phải thực việc kiểm tra chương trình khơng thể tránh mội lỗi ẩn chứa bên hệ phần mềm lớn Trong sử dụng bất kỹ chương trình lớn nào, lỗi báo lại cho người phát triển Bảo trì hiệu chỉnh q trình phân tích hiệu chỉnh hay nhiều lỗi chương trình b Bảo trì tiếp hợp Hoạt động thứ hai diễn thay đổi thường xuyên môi trường Những hệ phần cứng dường cơng bố theo chu trình 24 tháng lần Những hệ điều hành hay phiên hệ cũ đặn xuất hiện; thiết bị ngoại vi thành phần hệ thống khác liên tục nâng cấp thay đổi Thời gian hữu dụng phần mềm ứng dụng mặt khác lại dễ dàng vượt qua thời hạn mười năm, lâu môi trường hệ thống phát triển Bảo trì tiếp hợp hoạt động sửa đổi phần mềm để thích ứng với thay đổi mơi trường c Bảo trì hồn thiện Hoạt động thứ ba diễn phần mềm hoàn tất thành công Hoạt động chiếm hầu hết công sức tiêu tốn cho việc bảo trì phần mềm Lúc sử dụng, yêu cầu khả mới, thay đổi chức có, mở rộng tổng quát người dùng gửi đến Để thỏa mãn yêu cầu phát triển người sử dụng, ta tiến hành bảo trì hồn thiện d Bảo trì phịng ngừa Bảo trì phịng ngừa hoạt động bảo trì diễn phần mềm thay đổi để cải thiện tính bảo trì hay độ tin cậy tương lai để cung cấp tảng tốt cho mở rộng sau Bảo trì phòng ngừa, hoạt động nhiều xa lạ giới phần mềm 109 Bài giảng Công nghệ phần mềm Các thuật ngữ dùng để mô tả ba hoạt động bảo trì Swanson đề xướng Thuật ngữ thứ tư thường dùng việc bảo trì phần cứng hay hệ thống vật lý khác Tuy nhiên cần ý điểm tương tự bảo trì phần mềm bảo trì phần cứng gây nhầm lẫn Phần mềm khác với phần cứng, khơng thể tận dụng được, hoạt động bảo trì phần cứng chủ yếu - thay phận bị hỏng hóc hay gãy vỡ - không kể đến Trong thực tế hoạt động bảo trì, nhiệm vụ làm phần bảo trì tiếp hợp bảo trì hoàn thiện giống nhiệm vụ cần làm giai đoạn phát triển chu trình phần mềm Để tiếp hợp hay hoàn thiện, phải xác định yêu cầu, thiết kế lại, tạo mã kiểm tra phần mềm có Thơng thường nhiệm vụ gọi bảo trì 4.3.2 Đặc điểm bảo trì phần mềm Bảo trì phần mềm gần giai đoạn bị coi nhẹ chu trình phần mềm Kiến thức bảo trì có so sánh với giai đoạn hoạch định phát triển Có số liệu nghiên cứu chế tạo tập trung vào đề tài này, vầ phương pháp kỹ thuật đưa Để hiểu điểm chất bảo trì, xem xét vấn đề từ ba góc độ khác nhau: - Các hoạt động cần thiết để hoàn thành giai đoạn bảo trì tính tồn vẹn cách tiếp cận theo công nghệ phần mềm hiệu hoạt động đó, hay thiếu hụt - Chi phí kèm theo giai đoạn bảo trì - Các vấn đề thường gặp phải tiến hành bảo trì phần mềm a Bảo trì có cấu trúc bảo trì khơng cấu trúc Nếu thành phần có cấu hình phần mềm mã nguồn, hoạt động bảo trì bắt đầu với việc đánh giá chi tiết mã nguồn thường phức tạp với tài liệu nghèo nàn bên Những đặc điểm tế nhị cấu trúc phần mềm, cấu trúc liệu toàn cục, giao diên hệ thống,hoạt động ràng buộc thiết kế thường khó sáng tỏ hay bị hiểu lầm Các thay đổi lặt vặt thường xuyên làm cho mã khó đánh giá Các kiểm tra hồi quy (lặp lại kiểm tra trước để đảm bảo thay đổi không tạo lỗi phần mềm hoạt động) thực 110 Bài giảng Công nghệ phần mềm lưu kiểm tra Chúng ta tiến hành phép bảo trì khơng cấu trúc phải trả giá (khi lãng phí cơng sức gây tâm trạng thất vọng) Sự trả giá kèm với phần mềm không phát triển theo phương pháp đắn Nếu có cấu hình phần mềm hồn thiện, nhiệm vụ bảo trì bắt đầu việc đánh giá tài liệu thiết kế Sau xác định đặc điểm thuộc cấu trúc quan trọng, đặc điểm hoạt động giao diện Tính tồn vẹn sửa đổi hiệu chỉnh cần thiết đánh giá kế hoạch sửa đổi thiết lập Thiết kế thay đổi (sử dụng kỹ thuật phù hợp với điều bàn luận ácc chương trước) nhận xét đánh giá Mã nguồn phát triển, sau tiến hành kiểm tra hồi quy sử dụng thông tin chứa phần "đặc tả kiểm tra" phần mềm lại phát hành Các mơ tả phép bảo trì cấu trúc tiến hành kết ứng dụng trước khoa học công nghệ phần mềm Mặc dù có mặt cấu hình phần mềm khơng đảm bảo vấn đề bảo trì nảy sinh, khối lượng cơng việc giảm bớt chất lượng chung thay đổi hiệu chỉnh cải thiện b Giá thành bảo trì Theo thống kê, giá thành cho việc bảo trì phần mềm tăng lên cách đặn suốt năm qua Trong năm 1970, bảo trì chiếm đến 35 đến 40 phần trăm kinh phí phần mềm dành cho tổ chức hệ thống thơng tin.Tỷ lệ nhảy tới số 60 vào năm 1980 Và nhiều công ty chi 80% kinh phí cho việc bảo trì vào năm 1990 Chi phí cho việc bảo trì rõ ràng Tuy nhiên chi phí khác khó thấy gây mối quan tâm lớn hơn: - Một chi phí khó xác định việc bảo trì phần mềm hội phát triển bị bỏ qua tài ngun có sẵn dành cho nhiệm vụ bảo trì - Sự khơng hài lịng người dùng yêu cầu hợp lý cho việc sửa chữa hay sửa đổi không ý cách hợp lý - Việc suy giảm chất lượng nói chung lỗi tạo thay đổi phần mềm bảo trì 111 Bài giảng Công nghệ phần mềm - Một yêu cầu làm ngắt quãng trình phát triển nhân viên buộc tiến hành công việc bảo trì c Một số vấn đề khác Hầu hết vấn đề liên quan tới việc bảo trì phần mềm liên quan tới sai lệch cách xây dựng phát triển phần mềm Sự thiếu sót việc điều khiển tổ chức hai giai đoạn chu trình phần mềm gần luôn tạo vấn đề giai đoạn cuối Nhiều vấn đề kinh điển liên quan tới việc bảo trì phần mềm trình bày đây: - Rất khó khơng thể theo dõi tiến hóa phần mềm qua phiên Các thay đổi khơng tư liệu hóa - Khó theo dõi trình xử lý tạo phần mềm - Thường xuyên gặp nhiều khó khăn việc tìm hiểu chương trình người khác viết Những khó khăn tăng lên số thành phần cấu hình phần mềm giảm Nếu có chương trình nguồn khơng có tài liệu hướng dẫn khơng nên tìm hiểu phần mềm - Những người viết phần mềm thường khơng có mặt để giải thích Chúng ta khơng thể trơng cậy vào giải thích cá nhân nhà phát triển phần mềm việc bảo trì yêu cầu - Các tài liệu xác khơng có hay thiếu trầm trọng Phải thừa nhận phải có tài liệu phần mềm bước đầu tiên, tài liệu phải hiểu phù hợp với chương trình lại chuyện khác - Phần lớn phần mềm không thiết kế để thay đổi, sử dụng phương pháp thiết kế dùng khái niệm phân tách chương trình thành module độc lập Việc thay đổi phần mềm khó khăn dẫn đến xu hướng sai - Việc bảo trì phần mềm khơng coi công việc dễ dàng mà công việc bảo trì phần mềm ln liên quan tới sai lệch mức độ cao 4.4 CÂU HỎI TRẮC NGHIỆM, BÀI TẬP THẢO LUẬN Chọn câu trả lời nhất: Câu 1: Kiểm thử Alpha thực (a) User (b) Tester 112 Bài giảng Công nghệ phần mềm (c) Developer (d) Tất Câu 2: Kiểm thử Beta thực (a) Công ty phần mềm (b) Phía người dùng (c) Bất kỳ đâu (d) Tất Câu 3: Kỹ thuật kiểm thử sau kỹ thuật kiểm thử chức (a) Phân tích giá trị biên (b) Phân hoạch lớp tương đương (c) Bảng định (d) Tất Câu 4: Suốt giai đoạn phát triển, kiểm thử không thực (a) Kiểm thử đơn vị (b) Kiểm thử chấp nhận (c) Kiểm thử tích hợp (d) Tất Kiểm thử phần mềm gig? Theo anh/chị kiểm thử phần mềm lại quan trọng? Khi không phát lỗi q trình kiểm thử, theo anh/chị khẳng định chương trình 100% khơng? Giải thích 113 Bài giảng Công nghệ phần mềm TÀI LIỆU THAM KHẢO [1] Cem Kaner, Jack Falk, Hung Quoc Nguyen, Testing Computer Software, Wiley Computer Publishing, 1999 [2] Ian Sommerville, Software Engineering 9th Edition, Addison-Wesley, 2011 [3] Vishnuvarthanan Moorthy, Jumpstart to Software Quality Assurance, Smashwords, 2013 [4] Nguyễn Thanh Bình, Kiểm thử phần mềm, Nhà xuất Giáo dục Việt Nam, 2013 [5] Nguyễn Việt Hà, Bài giảng Kỹ nghệ phần mềm [6] Nguyễn Tiến Huy, Giáo trình Nhập mơn Cơng nghệ phần mềm, 2001 [7] Nguyễn Tiến Huy, Giáo trình Cơng nghệ phần mềm, 2002 [8] Nguyễn Trác Thức, Nguyễn Thị Thanh Trúc, Giáo trình Nhập mơn Cơng nghệ phần mềm, Nhà xuất Đại học Quốc gia Tp Hồ Chí Minh, 2007 [9] Roger S.Pressman, Ph.D, Software Engineering, A Practitioner’s Approach, McGraw-Hill Companies Inc, 2001 [10] Thạc Bình Cường, Nhập mơn Công nghệ phần mềm, Nhà xuất Giáo dục, 2008 [11] Istqbexamcertification.com [12] https://www.tutorialspoint.com/ [13] http://www.nngroup.com/articles/ten-usability-heuristics/ [14] http://designingwebinterfaces.com/6-tips-for-a-great-flex-ux-part-5 114 ... vẽ phần mềm” khơng sử dụng mà thay vào thuật ngữ mơ hình phần mềm với ý nghĩa Mơ hình phần mềm cung cấp thơng tin chi tiết thành phần phần mềm: - Thành phần giao diện 60 Bài giảng Công nghệ phần. .. tắt kết cần có thiết kế thành phần phần mềm 61 Bài giảng Công nghệ phần mềm Bảng 1: Các kết cần có thiết kế thành phần phần mềm Thành phần Kết Kết chi tiết Thành phần giao diện Hệ thống hình Sơ.. .Bài giảng Công nghệ phần mềm - Nắm bắt sớm giao diện chủ yếu hệ thống vịng đời phần mềm Điều có ích suy luận kiến trúc sử dụng giao diện công cụ đồng phát triển khác - Trực quan hóa