Bài giảng Công nghệ phần mềm (Phần 2)

Bài giảng Công nghệ phần mềm 
58 
Chương 3. 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 được tại sao phải thiết kế phần mềm 
- Biết các kiến thức cơ bản về 3 phần thiết kế: dữ liệu, xử lý, giao diện 
- Biết các phương pháp thiết kế phần mềm 
- Biết được khi nào 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ế, chúng ta định hình hệ thống và tìm dạng thức của nó (kể cả kiến 
trúc) mà đáp ứng được mọi yêu cầu, cả yêu cầu phi chức năng và các ràng buộc khác – 
được đặt ra cho hệ thống đó. 
 Bản chất thiết kế phần mềm là một quá trình chuyển hóa các yêu cầu phần mềm 
thành một biểu diễn thiết kế. Từ những mô tả quan niệm về toàn bộ phần mềm, việc làm 
mịn liên tục dẫn đến một biểu diễn thiết kế rất gần với cách biểu diễn của chương trình 
nguồn để có thể ánh xạ vào một ngôn ngữ lập trình cụ thể. 
 Xét một cách chi tiết mục tiêu của thiết kế là: 
- Thu được sự hiểu biết sâu về các yêu cầu phi chức năng và cá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, các hệ điều hành, các công 
nghệ phân tán, các công nghệ CSDL, các công nghệ giao diện người dùng, các 
công nghệ quản lý các giao dịch 
- Tạo ra một đầu vào thích hợp và xuất phát điểm cho các hoạt động cài đặt tiếp 
theo sau bằng cách nắm bắt các yêu cầu về mỗi hệ thống cụ thể, các giao diện và 
các lớp 
- Có khả năng phân rã việc cài đặt thành các mẫu nhỏ dễ quản lý hơn được nhiều 
đội phát triển khác nhau xử lý và có thể tiến hành đồng thời. Điều này sẽ có ích 
trong các trường hợp khi mà không thể tiến hành sự phân rã giữa các kết quả thu 
được từ nắm bắt các yêu cầu hoặc phân tích 
Bài giảng Công nghệ phần mềm 
59 
- Nắm bắt sớm các giao diện chủ yếu giữa các hệ thống con trong vòng đời của 
phần mềm. Điều này sẽ có ích khi chúng ta suy luận về kiến trúc và khi chúng ta 
sử dụng các giao diện như những công cụ đồng bộ các phát triển khác nhau 
- Trực quan hóa và suy luận thiết kế bằng cách sử dụng một hệ thống các ký pháp 
chung 
- Tạo ra một sự trừu tượng hóa liên tục của việc cài đặt của hệ thống, tức là cài đặt 
sự làm mịn dần thiết kế bằng cách đắp thịt vào khung xương nhưng không thay 
đổi cấu trúc của nó. 
 Hoạt động thiết kế là một hoạt động đặc biệt: 
- Là quá trình sáng tạo, đòi hỏi có kinh nghiệm và sự nhanh nhạy, sáng tạo 
- Cần phải được thực hành và học bằng kinh nghiệm, bằng khảo sát các hệ thống 
tồn tại, chỉ học bằng sách vở là không đủ. 
3.1.2. Tầm quan trọng 
 Tầm quan trọng của thiết kế có thể được phát biểu bằng một từ “chất lượng”. 
Thiết kế là nơi chất lượng phần mềm được nuôi dưỡng trong quá trình phát triển: cung 
cấp cách biểu diễn phần mềm có thể được xác nhận về chất lượng, là cách duy nhất mà 
chúng ta có thể chuyển hóa một cách chính xác các yêu cầu của khách hàng thành sản 
phẩm hay hệ thống phần mềm cuối cùng. 
Bài giảng Công nghệ phần mềm 
60 
Hình 3. 1: Luồng thông tin trong thiết kế 
 Thiết kế phần mềm là công cụ giao tiếp làm cơ sở để có thể mô tả một cách đầy 
đủ các dịch vụ của hệ thống, để quản lý các rủi ro và lựa chọn giải pháp thích hợp. Thiết 
kế phần mềm phục vụ như một nền tảng cho mọi bước kỹ nghệ phần mềm và bảo trì: 
Không có thiết kế, ta có nguy cơ dựng lên một hệ thống không ổn định – một hệ thống 
sẽ thất bại khi có một thay đổi nhỏ; một hệ thống khó có thể mà thử được; một hệ thống 
không thể nào xác định được chất lượng chừng nào chưa đến cuối tiến trình kiểm thử; 
khi thời gian con rất ngắn mà không ít tiền đã phải chi ra. 
 Thiết kế tốt là bước quan trọng đầu tiên để đảm bảo chất lượng phần mềm. 
3.1.3. Kết quả thiết kế phần mềm 
 Kết quả của việc thiết kế sản phẩm nói chung là các bản vẽ: bản vẽ nhà, bản vẽ 
máy bay, “bản vẽ phần mềm”,Các bản vẽ này cung cấp các thông tin chi tiết về cấu 
trúc của 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 được sử dụng mà thay vào đó là thuật ngữ mô hình phần mềm với cùng ý nghĩa. 
 Mô hình phần mềm cung cấp các thông tin chi tiết về 3 thành phần phần mềm: 
- Thành phần giao diện 
Bài giảng Công nghệ phần mềm 
61 
- Thành phần xử lý 
- Thành phần dữ liệu 
 Thông tin về thành phần giao diện bao gồm các thông tin sau: 
- Nội dung và hình thức trình bày các màn hình giao tiếp của phẩn mềm 
- Hệ thống các thao tác mà người dùng có thể thực hiện trên một màn hình giao 
tiếp và xử lý tương ứng của phẩn mềm. 
 Thông tin về thành phần xử lý bao gồm các thông tin sau: 
- Hệ thống các kiểu dữ liệu được sử dụng trong phần mềm. Các kiểu dữ liệu này 
mô tả cách tổ chức lưu trữ dữ liệu trong bộ nhớ chính của phần mềm 
- Hệ thống các hàm được sử dụng trong phần mềm. Các hàm này sẽ thể hiện tương 
ứng việc thực hiện một công việc nào đó của thế giới thực trên 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 về thành phần dữ liệu bao gồm các thông tin liên quan đến cách thức 
tổ chức lưu trữ các dữ liệu (nội dung của công việc ghi chép vào sổ sach trong thế giới 
thực) trên bộ nhớ phụ 
- Dạng lưu trữ được sử dụng của phần mềm 
- Hệ thống các thành phần lưu trữ cùng với quan hệ giữa chúng 
 Bảng sau mô tả tóm tắt các kết quả cần có khi thiết kế các thành phần phần mềm 
Bài giảng Công nghệ phần mềm 
62 
Bảng 3. 1: Các kết quả cần có khi thiết kế các thành phần phần mềm 
Thành phần Kết quả Kết quả chi tiết 
Thành phần giao diện Hệ thống các màn hình 
giao diện 
Sơ đồ các màn hình 
Danh sách các màn hình 
Nội dung từng màn hình 
Biến cố và xử lý trên từng màn 
hình 
Thành phần xử lý Hệ thống các hàm cùng 
với cấu trúc dữ liệu 
tương ứng 
Danh sách các hàm 
Danh sách các kiểu dữ liệu 
Mô tả chi tiết từng hàm 
Mô tả chi tiết các kiểu dữ liệu 
Thành phần dữ liệu Tổ chức lưu trữ trên bộ 
nhớ phụ 
Sơ đồ (cấu trúc lưu trữ) 
Danh sách các thành phần lưu trữ 
Mô tả chi tiết các thành phần 
Danh sách các 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 được chọn khi thực hiện phần mềm, việc thiết kế có thể 
được 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 khi thực hiện phần mềm không thông qua giai đoạn phân tích. Với 
phương pháp này việc thiết kế sẽ nhận kết quả 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 sẽ được xây dựng trực tiếp từ các yêu cầu. Cách tiếp 
cận này sẽ rất khó khăn cho người thực hiện với các phần mềm có quy mô lớn (nhiều 
yêu cầu, yêu cầu phức tạp,) 
Bài giảng Công nghệ phần mềm 
63 
 Với phương pháp trực tiếp, thiết kế phần mềm là quá trình cho phép chuyển đổi 
từ các yêu cầu (kết quả giai đoạn xác định yêu cầu) đến mô hình phần mềm tương ứng. 
 Mục tiêu chính của việc thiết kế là mô tả các thành phần của phần mềm (thành 
phần giao diện, thành phần xử lý, thành phần dữ liệu) tương ứng với các yêu cầu của 
phần mềm (yêu cầu chức năng nghiệp vụ, yêu cầu chức năng 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 các quy trình có giai đoạn phân tích. Với phương pháp này 
việc thiết kế chỉ nhận một phần các kết quả chuyển giao trực tiếp từ giai đoạn xác định 
yêu cầu, phần chính yếu sẽ được nhận gián tiếp qua giai đoạn phân tích. 
 Mô hình phần mềm sẽ được xây dựng tương ứng theo các mô hình trong giai 
đoạn phân tích. Cách tiếp cận này sẽ thuận lơi trong đa số trường hợp với các 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 là quá trình cho phép chuyển 
từ mô hình thế giới thực (kết quả giai đoạn phân tích) đến mô hình phần mềm tương 
ứng. 
 Mục tiêu chính của việc thiết kế là mô tả các thành phần của phần mềm (thành 
phần giao diện, thành phần xử lý, thành phần dữ liệu) tương ứng với các mô hình của 
thế giới thực (mô hình xử lý, mô hình dữ liệu). 
3.1.5. Thiết kế phần mềm và các yêu cầu chất lượng 
 Khi thực hiện thiết kế, mỗi yêu cầu chất lượng có những yêu cầu riêng trên các 
thành phần: dữ liệu, xử lý, giao diện. Các yêu cầu này được mô tả trong các bảng bên 
dưới: 
Bài giảng Công nghệ phần mềm 
64 
Bảng 3. 2: Thiết kế dữ liệu và yêu cầu chất lượng 
Yêu cầu chất 
lượng 
Yêu cầu trên thành phần dữ liệu của phần mềm 
Tính đúng đắn Phù hợp với mô hình dữ liệu (giai đoạn phân tích) hoặc theo 
đúng yêu cầu (giai đoạn xác định yêu cầu) nếu bỏ qua giai đoạn 
phân tích. 
Tính tiến hóa Có dự kiến về các thay đổi trên nội dung dữ liệu cần lưu trữ và 
các ràng buộc tương ứng 
Tính hiệu quả Lưu trữ ít tốn chỗ, truy xuất nhanh 
Bảng 3. 3: Thiết kế xử lý và yêu cầu chất lượng 
Yêu cầu chất 
lượng 
Yêu cầu trên thành phần xử lý của phần mềm 
Tính đúng đắn Phù hợp với mô hình xử lý (giai đoạn phân tích) hoặc theo đúng 
yêu cầu (giai đoạn xác định yêu cầu) nếu bỏ qua giai đoạn phân 
tích 
Tính tiến hóa Có dự kiến về các thay đổi trên các quy định, quy tắc tính toán 
Tính hiệu quả Tốc độ thực hiện nhanh 
Tính tương thích Cho phép chuyển đổi dữ liệu với các phần mềm khác 
Bài giảng Công nghệ phần mềm 
65 
Bảng 3. 4: Thiết kế giao diện và yêu cầu chất lượng 
Yêu cầu chất 
lượng 
Yêu cầu trên thành phần giao diện của phần mềm 
Tính đúng đắn Phù hợp với mô hình xử lý (nếu có thực hiện giai đoạn phân 
tích) hoặc theo đúng yêu cầu (giai đoạn xác định yêu cầu) nếu 
bỏ qua giai đoạn phân tích 
Tính tiến hóa Có dự kiến về các thay đổi trên thành phần dữ liệu và 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 quả Thao tác thực hiện nhanh, sử dụng tối ưu các không gian 
Tính tương thích Sự nhất quán giữa các màn hình 
3.1.6. Chất lượng thiết kế 
 Không có cách nào hay để xác định được thể nào là thiết kế tốt. Tiêu chuẩn dễ 
bảo trì là tiêu chuẩn tốt cho người dùng. Một thiết kế dễ bảo trì có thể thích nghi với 
việc cải biên các chức năng và việc thêm các chức năng mới. Một thiết kế như thế phải 
dễ hiểu và việc sửa đổi chỉ có hiệu ứng cục bộ. Các thành phần thiết kế phải kết dính 
(cohesive) theo nghĩa là tất cả các bộ phận trong thành phần phải có một quan hệ logic 
chặt chẽ, các thành phần ghép nối (coupling) với nhau là lỏng lẻo. Ghép nối càng lỏng 
lẻo thì càng dễ thích nghi, nghĩa là càng dễ sửa đổi để phù hợp với hoàn cảnh mới. 
 Để xem một thiết kế có tốt hay không, người ta tiến hành thiết lập một số độ đo 
chất lượng thiết kế: 
a. Sự kết dính (Cohesion) 
 Sự kết dính của một module là độ đo về tính khớp lại với nhau của các thành 
phần trong module đó. Nếu một module chỉ thực hiện một chức năng logic hoặc là một 
thực thể logic, tức là tất cả các bộ phận của module đó đều tham gia vào việc thực hiện 
một công việc thì đọ kết dính là cao. Nếu một hoặc nhiều bộ phận không tham gia trực 
tiếp vào việc chức năng logic đó thì mức độ kết dính của nó là thấp. Thiết kế là tốt khi 
độ kết dính cao. Khi đó chúng ta sẽ dễ dàng hiểu được từng module và việc sửa chữa 
một module sẽ không (ít) ảnh hưởng tới các module khác. 
Bài giảng Công nghệ phần mềm 
66 
 Constantine và Yourdon định ra 7 mức kết dính theo thứ tự tăng dần như sau: 
1. Kết dính gom góp: các công việc không liên quan với nhau, song lại bị bó vào 
một module 
2. Kết dính logic: các thành phần cùng thực hiện các chức năng tương tự về logic, 
chẳng hạn: vào/ra, xử lý lỗi, được đặt vào cùng một module 
3. Kết dính thời điểm: tất cả các thành phần cùng hoạt động một lúc, chẳng hạn như 
các thao tác khởi tạo được bó lại với nhau 
4. Kết dính thủ tục: các phần tử trong module được ghép lại trong một dãy điều 
khiển 
5. Kết dính truyền thông: tất cả các phần tử của module cùng thao tác trên một dữ 
liệu vào và đưa ra cùng một dữ liệu ra 
6. Kết dính tuần tự: trong một module, đầu ra của phần từ này là đầu vào của phần 
từ khác 
7. Kết dính chức năng: mỗi phần của module đều là cần thiết đề thi hành cùng một 
chức năng nào đó 
 Các lớp kết dính này không được định nghĩa chặt chẽ và cùng không phải luôn 
luôn xác định được. 
 Một đối tượng kết dính nếu nó thể hiện như một thực thể đơn: tất cả các phép 
toán trên thực thể đó đều nằm trong thực thể đó. Vậy có thể xác định một lớp kết dính 
nữa là: 
8. Kết dính đối tượng: mỗi phép toán đều liên quan đến thay đổi, kiểm tra và sử 
dụng thuộc tính của một đối tượng, là cơ sở cung cấp các dịch vụ của đối tượng. 
b. Sự ghép nối (Coupling) 
 Ghép nối là độ đo sự nối ghép với nhau giữa các đơn vị (module) của hệ thống. 
HỆ thống có nối ghép cao thì các module phụ thuộc lẫn nhau lớn. Hệ thống nối ghép 
lỏng lẻo thì các module là độc lập hoặc là tương đối độc lập với nhau và chúng ta sẽ dễ 
bảo trì nó. 
 Các module được ghép nối chặt chẽ nếu chúng dùng các biến chung và nếu chúng 
trao đổi các thông tin điều khiển (ghép nối chung nhau và ghép nối điều khiển). Ghép 
nối lỏng lẻo đạt được khi bảo đảm rằng các thông tin cục bộ được che giấu trong các 
Bài giảng Công nghệ phần mềm 
67 
moduun và các 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 các mức từ chặt chẽ đến lỏng lẻo như sau: 
1. Ghép nối nội dung: hai hay nhiều module dùng lẫn dữ liệu của nhau, đây là mức 
xấu nhất, thường xảy ra đối với các ngôn ngữ mức thấp dùng các dữ liệu toàn cục 
hay lạm dụng lệnh GOTO 
2. Ghép nối chung: một số module dùng các biến chung, nếu xảy ra lỗi thao tác dữ 
liệu, sẽ khó xác định được lỗi đó do module nào gây ra 
3. Ghép nối điều khiển: một module truyền các thông tin điều khiển để điều khiển 
hoạt đọng của một module khác 
4. 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ăng của nó, điều này sẽ làm giảm khả năng thích nghi của module đó 
5. Ghép nối dữ liệu: các module trao đổi thông tin thông qua tham số và giá trị trả 
lại 
6. Ghép nối không có trao đổi thông tin: module thực hiện một chức năng độc lập 
và hoàn toàn không nhận tham số và không có giá trị trả lại 
 Ưu điểm của thiết kế hướng đối tượng là do bản chất che giấu thông tin của đối 
tượng dẫn tới việc tạo ra các hệ ghép nối lỏng lẻo. 
 Việc thừa kế trong hệ thống hướng đối tượng lại dẫn tới một dạng khác của ghép 
nối, ghép nối giữa các đối tượng mức cao và đối tượng kế thừa nó. 
c. Sự hiểu được (Understandability) 
 Sự hiểu được của thiết kế liên quan tới một số đặc trưng sau đây: 
- Tính kết dính: có thể hiểu được thành phần đó mà không cần tham khảo tới một 
thành phần nào khác hay không? 
- Đặt tên: phải chăng là mọi tên được dùng trong thành phần đó đều có nghĩa? Tên 
có nghĩa là những tên phản ánh tên của thực thể trong thế giới thực được mô hình 
bởi thành phần đó. 
- Soạn tư liệu: thành phần có được soạn thảo tư liệu sao cho ánh xạ giữa các thực 
thể trong thế giới thực và thành phần đó là rõ ràng. 
- Độ phức tạp: độ phức tạp của các thuật toán được dùng để thực hiện thành phần 
đó như thế nào? 
Bài giảng Công nghệ phần mềm 
68 
 Độ phức tap cao ám chỉ nhiều quan hệ giữa các thành phần khác nhau của thành 
phần thiết kế đó và một cấu trúc logic phức tạp mà nó dính líu đến độ sâu lồng nhàu của 
cấu trúc if-then-else. Các thành phần phức tạp là khó hiểu, vì thế người thiết kế nên làm 
cho thiết kế thành phần càng đơn giản càng tốt. 
 Đa số công việc về đo chất lượng thiết kế đư ...  test chương trình này cho đại học thì tích phân, đạo hàm 
Nguyên tắc 7: Sự sai lầm về việc không có lỗi (Absence-of-errors fallacy) 
 Việc tìm và sửa lỗi sẽ không giúp được gì nếu hệ thống được xây dựng xong 
nhưng không thể dùng được và không đáp ứng được nhu cầu của người dùng. 
4.2.7. Thiết kế test case 
 Việc thiết kế testcase dựa vào các kỹ thuật và 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, đối với mỗi biến đầu vào chúng ta xác 
định các giá trị dữ liệu thử, sau đó kết hợp các giá trị dữ liệu thử của các biến để tạo nên 
ca kiểm thử. 
 Có hai trường hợp được xem xét: 
- Giả thuyết “lỗi đơn” (single fault) – sự thất bại của chương trình hiếm khi là kết 
quả của hai lỗi (hay nhiều hơn) 
Số dữ liệu thử có thể được xác định qua số biến vào: nếu chương trình có n biến 
vào, chỉ một biến nhận các giá trị min-, min, min+, max-, max, max+, các biến 
còn lại nhận giá trị nom. Như vậy đối với 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 dữ 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 các dữ liệu thử 
sau: 
Bài giảng Công nghệ phần mềm 
106 
{, , , , , <xnom, 
ymax+>, , , , , , 
, } 
- Bỏ qua giả thuyết lỗi đơn 
Nếu bỏ qua giả thuyết lỗi đơn, chúng ta quan tâm đến điều gì xảy ra khi nhiều 
hơn một biến đầu vào đạt đến giá trị biên. Trong trường hợp này, chúng ta gọi 
kiểm thử giá trị biên trong trường hợp xấu nhất. Đối với mỗi biến đầu vào, chúng 
ta 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 của các tập hợp này để tạo ra các dữ liệu thử. Như vậy, 
các dữ liệu thử có tính đến giả thuyết lỗi đơn chỉ là tập con của các dữ liệu thử 
bỏ qua giả thuyết lỗi đơn. Kiểm thử trong trường hợp xấu nhất (bỏ qua giả thuyết 
lỗi đơn) cho một chương trình có n biến vào tạo ra 7n dữ liệu thử, so với 6n+1 dữ 
liệu thử khi 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 của hai biến đầu vào a, b kiểu số nguyên có cá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ử là một hàm gồm hai biến vào a và b. Giả 
sử miền dữ liệu của biến a được chia thành ba lớp tương đương sau: 
𝐴1 ≤ 𝑎 < 𝐴2, 𝐴2 ≤ 𝑎 < 𝐴3, 𝑣à 𝐴3 ≤ 𝑎 < 𝐴4 
Và miền dữ liệu của biến b được chia thành hai lớp tương đương sau: 
𝐵1 ≤ 𝑏 < 𝐵2 𝑣à 𝐵2 ≤ 𝑏 < 𝐵3 
Chúng ta ký hiệu các giá trị đại diện của các lớp tương đương như sau: 
𝑎1 ∈ [𝐴1, 𝐴2], 𝑎2 ∈ [𝐴2, 𝐴3], 𝑎3 ∈ [𝐴3, 𝐴4] 
𝑏1 ∈ [𝐵1, 𝐵2], 𝑏2 ∈ [𝐵2, 𝐵3] 
 Khi đó, các ca kiểm thử của ba loại kiểm thử lớp tương đương được minh họa 
như sau: 
Bài giảng Công nghệ phần mềm 
107 
Bảng 4. 1: Minh họa các ca kiểm thử lớp tương đương yếu 
Ca kiểm thử a b 
1 a1 b1 
2 a2 b2 
3 a3 b1 
Bảng 4. 2: Minh họa các ca kiểm thử lớp tương đương mạnh 
Ca kiểm thử a b 
1 a1 b1 
2 a1 b2 
3 a2 b1 
4 a2 b2 
5 a3 b1 
6 a3 b2 
 Đối với kiểm thử lớp tương đương truyền thống, các ca kiểm thử được xây dựng 
như sau: 
Đối với dữ liệu vào hợp lệ, sử dụng một giá trị đại diện cho mỗi lớp tương đương, nghĩa 
là tương tự như kiểm thử lớp tương đương yếu. Lưu ý rằng tất cả các dữ liệu vào của 
các ca kiểm thử này đều hợp lệ. 
Đối với dữ liệu vào không hợp lệ, một ca kiểm thử chỉ có một dữ liệu không hợp lệ, các 
dữ liệu còn lại đều hợp lệ. Trong trường hợp này, chúng ta chấp nhận giả thuyết lỗi đơn. 
 Chẳng hạn, trong ví dụ trên, giả sử đối với biến vào a, lớp [A2, A3] hợp lệ và các 
lớp [A1, A2] và [A3, A4] không hợp lệ; đối với 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 các ca kiểm 
thử như bảng sau: 
Bài giảng Công nghệ phần mềm 
108 
Bảng 4. 3: Minh họa các ca kiểm thử lớp tương đương truyền thống 
Ca kiểm thử a b Kết quả 
1 a2 b1 Hợp lệ 
2 a1 b1 Không hợp lệ 
3 a3 b1 Không hợp lệ 
4 a2 b2 Không hợp lệ 
4.2.8. Lập kế hoạch và 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 sẽ giảm 
chi phí, cải thiện được quan hệ với lập trình viên và nâng cao được chất lượng của kiểm 
thử. 
4.3. BẢO TRÌ PHẦN MỀM 
 Bảo trì là giai đoạn cuối cùng của một chu trình phát triển phần mềm. Các chương 
trình máy tính luôn thay đổi- phải mở rộng, sửa lỗi, tối ưu hoá,...và theo thống kê thì 
bảo trì chiếm đến 70% toàn bộ công sức bỏ ra cho một dự án phần mềm. Do vậy, bảo 
trì là một hoạt động phức tạp nhưng nó lại là vô cùng cần thiết trong chu trình sống của 
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 của các hệ thống thông tin, rất hiếm hay không muốn nói 
là không thể có một hệ thống thông tin không có sự thay đổi trong suốt chu trình sống 
của nó. Để duy trì tính đúng đắn, trật tự trong giai đoạn bảo trì thì quản lý sự thay đổi 
phần mềm là một hoạt động cần thiết song song. 
4.3.1. Hoạt động bảo trì phần mềm và phân loại 
 Bảo trì phần mềm là phức tạp và chúng ta có thể chia hoạt động bảo trì ra làm 
bốn hoạt động như sau: 
Bài giảng Công nghệ phần mềm 
109 
a. Bảo trì hiệu chỉnh 
 Công việc bảo trì đầu tiên cần phải thực hiện là do việc kiểm tra chương trình 
không thể tránh được mội lỗi ẩn chứa bên trong một hệ phần mềm lớn. Trong khi sử 
dụng bất kỹ một chương trình lớn nào, các lỗi sẽ được báo về lại cho người phát triển. 
Bảo trì hiệu chỉnh chính là quá trình phân tích và hiệu chỉnh một hay nhiều lỗi của 
chương trình. 
b. Bảo trì tiếp hợp 
 Hoạt động thứ hai diễn ra bởi sự thay đổi thường xuyên môi trường. Những thế 
hệ phần cứng mới dường như được công bố theo chu trình 24 tháng một lần. Những hệ 
điều hành mới hay phiên bản mới của các hệ cũ đều đặn xuất hiện; thiết bị ngoại vi và 
các thành phần hệ thống khác liên tục được nâng cấp và thay đổi. Thời gian hữu dụng 
của một 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 hơn 
môi trường hệ thống đã phát triển nó đầu tiên. 
 Bảo trì tiếp hợp là hoạt động sửa đổi phần mềm để thích ứng được với những 
thay đổi của môi trường. 
c. Bảo trì hoàn thiện 
 Hoạt động thứ ba diễn ra khi một phần mềm đã được hoàn tất thành công. Hoạt 
động này chiếm hầu hết các công sức tiêu tốn cho việc bảo trì phần mềm. Lúc sử dụng, 
các yêu cầu về những khả năng mới, các thay đổi những chức năng đã có, và các mở 
rộng tổng quát được người dùng gửi đến. 
 Để thỏa mãn những yêu cầu phát triển của người sử dụng, ta tiến hành bảo trì 
hoàn thiện. 
d. Bảo trì phòng ngừa 
 Bảo trì phòng ngừa là hoạt động bảo trì diễn ra khi phần mềm được thay đổi để 
cải thiện tính năng bảo trì hay độ tin cậy trong tương lai hoặc để cung cấp một nền tảng 
tốt hơn cho những mở rộng sau này. 
 Bảo trì phòng ngừa, hoạt động này vẫn còn nhiều xa lạ trong thế giới phần mềm 
hiện nay. 
Bài giảng Công nghệ phần mềm 
110 
 Các thuật ngữ dùng để mô tả ba hoạt động bảo trì đầu tiên là do Swanson đề 
xướng. Thuật ngữ thứ tư thường được dùng trong việc bảo trì phần cứng hay các hệ 
thống vật lý khác. Tuy nhiên cần chú ý rằng những điểm tương tự giữa bảo trì phần mềm 
và bảo trì phần cứng có thể 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, vì vậy hoạt động bảo trì phần cứng chủ yếu - thay thế các bộ phận bị hỏng 
hóc hay gãy vỡ - không được kể đến. 
 Trong thực tế của hoạt động bảo trì, các nhiệm vụ được làm như một phần của 
bảo trì tiếp hợp và bảo trì hoàn thiện cũng giống như các nhiệm vụ cần làm trong giai 
đoạn phát triển của một chu trình phần mềm. Để tiếp hợp hay hoàn thiện, chúng ta đều 
phải xác định yêu cầu, thiết kế lại, tạo mã và kiểm tra phần mềm có được. Thông thường 
các nhiệm vụ đó đã được gọi là bảo trì rồi. 
4.3.2. Đặc điểm của bảo trì phần mềm 
 Bảo trì phần mềm cho tới gần đây vẫn còn là một giai đoạn bị coi nhẹ của chu 
trình phần mềm. Kiến thức về bảo trì có được rất ít khi so sánh với các giai đoạn hoạch 
định và phát triển. Có rất ít các số liệu nghiên cứu và chế tạo tập trung vào đề tài này, 
vầ rất ít các phương pháp kỹ thuật được đưa ra. Để hiểu được điểm bản chất của bảo trì, 
chúng ta sẽ xem xét các 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ì và tính toàn vẹn của một 
cách tiếp cận theo công nghệ phần mềm đối với hiệu quả của những hoạt động 
đó, hay sự thiếu hụt nó. 
- Chi phí kèm theo giai đoạn bảo trì. 
- Các vấn đề thường gặp phải khi tiến hành bảo trì phần mềm. 
a. Bảo trì có cấu trúc đối với bảo trì không cấu trúc 
 Nếu thành phần có được duy nhất của một cấu hình phần mềm là 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 là khá phức tạp với 
những tài liệu nghèo nàn bên trong. Những đặc điểm tế nhị như cấu trúc phần mềm, các 
cấu trúc dữ liệu toàn cục, giao diên hệ thống,hoạt động và các ràng buộc thiết kế thường 
rất khó sáng tỏ và hay bị hiểu lầm. Các thay đổi lặt vặt thường xuyên làm cho các mã 
rất khó đánh giá. Các kiểm tra hồi quy (lặp lại các kiểm tra trước kia để đảm bảo rằng 
những thay đổi không tạo ra lỗi trong phần mềm đã hoạt động) là không thể thực hiện 
Bài giảng Công nghệ phần mềm 
111 
được bởi không hề có các bản lưu về các kiểm tra đó. Chúng ta đang tiến hành phép bảo 
trì không cấu trúc và đang phải trả giá (khi lãng phí công sức và gây tâm trạng thất 
vọng). Sự trả giá này luôn đi kèm với các phần mềm đã không được phát triển theo 
những phương pháp đúng đắn. 
 Nếu có một cấu hình phần mềm hoàn thiện, nhiệm vụ bảo trì bắt đầu bằng việc 
đánh giá các tài liệu thiết kế. Sau đó là xác định các đặc điểm thuộc cấu trúc quan trọng, 
các đặc điểm hoạt động và giao diện. Tính toàn vẹn của những sửa đổi và hiệu chỉnh 
cần thiết sẽ được đánh giá và một kế hoạch sửa đổi sẽ được thiết lập. Thiết kế được thay 
đổi (sử dụng những kỹ thuật phù hợp với những điều đã bàn luận ở ácc chương trước) 
rồi nhận xét đánh giá. Mã nguồn được phát triển, sau đó tiến hành các kiểm tra hồi quy 
sử dụng thông tin chứa trong phần "đặc tả kiểm tra" và rồi phần mềm lại được phát hành. 
 Các mô tả trên đây là phép bảo trì cấu trúc và được tiến hành như là kết quả của 
những ứng dụng trước đây trong khoa học về công nghệ phần mềm. Mặc dù sự có mặt 
của một cấu hình phần mềm không đảm bảo được các vấn đề bảo trì nảy sinh, nhưng 
khối lượng công việc đã được giảm bớt và chất lượng chung của những thay đổi và hiệu 
chỉnh đã được cải thiện. 
b. Giá thành bảo trì 
 Theo thống kê, giá thành cho việc bảo trì các phần mềm tăng lên một cách đều 
đặn trong suốt những năm qua. Trong những 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ệ này đã nhảy 
tới con số 60 vào giữa những năm 1980. Và nhiều công ty đã chi 80% kinh phí cho việc 
bảo trì vào giữa những năm 1990. 
 Chi phí cho việc bảo trì là rõ ràng nhất. Tuy nhiên những chi phí khác khó thấy 
hơn có thể gây ra mối quan tâm lớn hơn: 
- Một chi phí khó xác định của việc bảo trì phần mềm là các cơ hội phát triển bị bỏ 
qua vì các tài nguyên có sẵn đều dành cho nhiệm vụ bảo trì. 
- Sự không hài lòng của người dùng khi các yêu cầu có vẻ hợp lý cho việc sửa 
chữa hay sửa đổi không được chú ý một cách hợp lý. 
- Việc suy giảm chất lượng nói chung do lỗi tạo ra bởi sự thay đổi trong các phần 
mềm được bảo trì. 
Bài giảng Công nghệ phần mềm 
112 
- Một yêu cầu bất chợt làm ngắt quãng quá trình phát triển của một nhân viên buộc 
anh ta tiến hành công việc bảo trì. 
c. Một số vấn đề khác 
 Hầu hết các vấn đề liên quan tới việc bảo trì phần mềm đều liên quan tới các sai 
lệch trong cách xây dựng và phát triển phần mềm. Sự thiếu sót trong việc điều khiển và 
tổ chức trong hai giai đoạn đầu tiên của một chu trình phần mềm gần như luôn luôn tạo 
ra các vấn đề giai đoạn cuối. 
 Nhiều vấn đề kinh điển có thể liên quan tới việc bảo trì phần mềm được trình bày 
dưới đây: 
- Rất khó hoặc không thể theo dõi sự tiến hóa của phần mềm qua các phiên bản. 
Các thay đổi không được tư liệu hóa. 
- Khó theo dõi được các quá trình xử lý được tạo bởi các phần mềm. 
- Thường xuyên gặp rất nhiều khó khăn trong việc tìm hiểu chương trình của người 
khác viết. Những khó khăn này tăng lên khi số thành phần các cấu hình của phần 
mềm giảm đi. Nếu chỉ có các chương trình nguồn không có tài liệu hướng dẫn 
thì 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 những giải thích cá nhân của các nhà phát triển phần mềm khi 
việc bảo trì được yêu cầu. 
- Các tài liệu chính xác không có hay thiếu trầm trọng. Phải thừa nhận rằng phải 
có tài liệu về phần mềm là bước đầu tiên, nhưng tài liệu phải hiểu được và phù 
hợp với chương trình lại là chuyện khác. 
- Phần lớn các phần mềm không thiết kế để thay đổi, trừ phi sử dụng phương pháp 
thiết kế dùng các khái niệm về phân tách chương trình thành các module độc lập. 
Việc thay đổi phần mềm sẽ rất khó khăn và dẫn đến xu hướng sai. 
- Việc bảo trì phần mềm không được coi là một công việc dễ dàng mà công việc 
bảo trì phần mềm luôn liên quan tới các sai lệch ở mức độ cao. 
4.4. CÂU HỎI TRẮC NGHIỆM, BÀI TẬP THẢO LUẬN 
1. Chọn câu trả lời đúng nhất: 
Câu 1: Kiểm thử Alpha được thực hiện bởi 
(a) User (b) Tester 
Bài giảng Công nghệ phần mềm 
113 
(c) Developer (d) Tất cả đều đúng 
Câu 2: Kiểm thử Beta được thực hiện ở 
(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 đúng 
Câu 3: Kỹ thuật kiểm thử nào sau đây không phải kỹ thuật kiểm thử chức năng 
(a) Phân tích giá trị biên (b) Phân hoạch lớp tương đương 
(c) Bảng quyết định (d) Tất cả đều đúng 
Câu 4: Suốt giai đoạn phát triển, kiểm thử nào không được thực hiện 
(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 cả đều đúng 
2. Kiểm thử phần mềm là gig? Theo anh/chị tại sao kiểm thử phần mềm lại quan 
trọng? 
3. Khi không phát hiện lỗi trong quá trình kiểm thử, theo anh/chị có thể khẳng định 
chương trình đúng 100% không? Giải thích. 
Bài giảng Công nghệ phần mềm 
114 
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 bản 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 bản Đạ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 bản Giáo dục, 2008 
[11]. Istqbexamcertification.com 
[12]. https://www.tutorialspoint.com/ 
[13].  
[14].