Bài giảng Software quality assurance: Qualification - Nguyễn Anh Hào

SW Quality Assurance

1

06. Qualification
(duy trì chất lượng)


Nguyễn Anh Hào
Khoa CNTT2
Học viện CNBCVT – Cs Tp.HCM


Sự thay đổi lên PM

2

1. Vì PM là một mô hình về thế giới thực. Thế giới
thực luôn thay đổi (quy luật Lehman)



Công nghệ luôn cải tiến
Nghiệp vụ của tổ chức thay đổi

2. Bị lỗi chưa phát hiện được.


3.


Fault tolerance

Users cần cá nhân hóa PM.
Làm việc có hiệu quả cao hơn

4. Thay đổi PM dể hơn phần cứng.
5. Môi trường vận hành ngày càng nguy hiểm.


Virus, hackers


Yêu cầu dự phòng đ/v PM

3
 Ngoài

2 khía cạnh verification và validation (dựa
trên yêu cầu đã nhận thức được), SQA còn phải
chuẩn bị trước cho những yêu cầu sẽ xuất hiện.
 Hành động này được hiểu phổ biến với khái
niệm “bảo trì”: bảo đảm cho PM sẽ duy trì được
chất lượng (theo thời gian) trong ngữ cảnh áp
dụng của nó
1. Cập nhật cho nhu cầu sử dụng theo thời gian
2. Đa dạng hóa xử lý


Qualification

4
 ISO

25010 - Quality In Use đưa ra các tiêu chí
chất lượng trong ngữ cảnh sử dụng PM, như:
1.
2.
3.
4.
5.

Phát huy được năng lực (effectiveness)
Hiệu quả dùng tài nguyên (efficiency)
Thỏa mãn cho tác nhân (Satisfaction)
An toàn (safety)
Khả dụng (usability)

 Qualification

là những hành động bảo đảm cho
PM bộc lộ được các tố chất trên
Hành động chuẩn bị sẵn trong PM & nhân công


5

Hổ trợ bảo trì từ phần mềm (ISO 25010)
Quality in use of
DEVELOPER

Quality in use
of INSTALLER

Quality in use
of USERS

ISO_25010.PDF


Chất lượng của việc bảo trì

6

Từ các công việc cụ thể:
 Từ cách thức hổ trợ cho bảo trì đã được thiết
kế sẵn bên trong phần mềm
 Từ chính sách bảo trì cho phần mềm
 Từ các công việc bảo trì được cho là cần thiết
phải tiến hành



Quản lý cấu hình
Giám sát sự thay đổi của môi trường


Quản lý cấu hình (CM)

7


Software configuration item (SCI): Là bất kỳ
sản phẩm nào (của dự án phần mềm) được
xem như là một thực thể có ý nghĩa đối với
phần mềm; ie, nó góp phần tạo ra các đặc
điểm của sản phẩm.
 Ví dụ: SW Req. Spec. (SWRS), System Spec.(SS),
Design Doc.(DD), User Man. (UM), Source Code,
Project Plan, Installation Doc., … là những SCIs.



SCI version (phiên bản của SCI): là một trạng
thái được phê duyệt của SCI
 Vd: Source code ver 1.24, DD ver 1.23

7


Configuration Management

8


Software configuration version: Là một bộ gồm
nhiều SCI version đã được phê duyệt; nó xác
định đặc tính riêng của sản phẩm trong chuổi
tiến trình tạo & cập nhật sản phẩm
 Vd: Product Ver 1.00 ≠ Product Ver 1.01



Software configuration management (SCM): là
sự theo đõi (nhận biết, phân biệt) và kiễm soát
(phê duyệt) tất cả các thay đổi trên các SCI.

8


CM: Xử lý

9
SC

Ver 1.1

Ver 2.1
Change control

Version
control

DD

Ver 1.2

Ver 1.3

Ver 2.2

Build control

1. Version control: Phân biệt
các phiên bản của SCI. Mỗi
SCI có nhiều phiên bản,
mỗi phiên bản thể hiện sự
khác biệt của PM so với các
phiên bản khác
2. Change control: xem xét
yêu cầu thay đổi để quyết
định thay đổi, thực hiện và
ghi vết các thay đổi trên
cấu hình.
3. Build control: quyết định
những phiên bản SCI nào
được tích hợp với nhau để
tạo ra một phiên bản PM
mới

9


CM: Phát hành phiên bản PM

10


Sequential : Phát hành tuần tự các phiên bản



cho một PM.
Tree : đa dạng hóa một phiên bản PM cho
nhiều đối tượng sử dụng.

10


11

CM: Tree version

Microsoft website. Branching and Merging Primer.
11
/>

12

CM: Tree version

12


Chính sách bảo trì

13




Xem xét việc sửa đổi phần mềm theo quan
điểm:
“Có/không”: từ người có quyền, thường gây ra
quá tải trong việc thực hiện thay đổi
“Cân bằng”: chỉ chấp thuận cho thay đổi nào
thực sự quan trọng và có được lợi ich nhiều
hơn chi phí thực hiện thay đổi này

13


Duy trì chất lượng (bảo trì)

14

1.
2.
3.

4.

Có 4 công việc chính trong hoạt động bảo trì :
Corrective action: sửa lỗi còn sót lại trong PM,
trong khi nó đang được sử dụng.
Adaptive action: làm cho PM tương thích với
môi trường đã bị thay đổi so với trước đây
Perfective action: làm tăng thêm giá trị sử
dụng PM.
 Cải tiến các chức năng & đặc tính chất
lượng

Preventive action: ngăn ngừa các rủi ro trước
khi chúng xuất hiện


Bảo trì

15
 Bản

chất của vấn đề bảo trì : gây ra yêu cầu
sửa đổi (modify) trên phần mềm
Sự sửa đổi thực tế là tốn kém hơn người ta nghĩ
(do mối liên kết phức tạp trong phần mềm: sự
cộng tác → phụ thuộc lẫn nhau)
 Ie, cần cân nhắc kỹ về chi phí trước khi cam kết

Yêu cầu sửa đổi này không thể biết trước trong
quá trình làm (không có yêu cầu cụ thể để đưa ra
giải pháp cụ thể) → CNPM chỉ có giải pháp tổng
quát cho các yêu cầu này
 Mô hình nào hổ trợ cho vấn đề này ?
 Phương pháp, kỹ thuật nào hổ trợ vấn đề này ?


16 Giải pháp chung: maintenance = evolution
1.

Các mô hình xoắn ốc, UP, Agile và những mô
hình sau này đều lưu giữ các SCI để tiếp tục
cập nhật cho phiên bản phần mềm mới

 IEEE định nghĩa PM = tập các SCI của nó

2.

Thay thế việc sửa lệnh,dữ liệu bằng việc tháo
lắp các môđun được thiết kế ít phụ thuộc nhau
 Hướng đối tượng phục vụ cho mục đích này

3.

Chuẩn hóa kết cấu của phần mềm, để nhận
sự hổ trợ phát triễn nó từ cộng đồng
 Các phần mềm mã nguồn mở đều thiết kế
theo chuẩn


Corrective maintenance

17
 Nguyên

nhân còn sót lỗi là do cách làm phần mềm
khá phức tạp dể gây lỗi khó phát hiện, và việc kiễm
thử chưa đủ thời gian để phát hiện lỗi.
Trong CNPM:

 Verification

& Validation : làm càng sớm càng tốt

 Có

phương pháp, kỹ thuật, công cụ hổ trợ, giống
như làm phần mềm (design, test, analysis, actions)

 Cấu

trúc cho các tài liệu đặc tả thuận lợi cho việc
dò vết (tracing) để định vị và sửa lỗi dể

 Cơ

chế phát hiện lỗi và mô tả tình huống gây lỗi
được sử dụng trong suốt chu kỳ phát triễn.


Adaptive maintenance

18
 Thiết

kế để phần mềm ít phụ thuộc vào môi trường
vd: Portable là phần mềm chạy được trên nhiều
lớp nền khác nhau
vd: ứng dụng java trên nền JRE
 Giới hạn sự phụ thuộc vào các bất biến của môi
trường
vd: yêu cầu nghiệp vụ lấy từ quy định (luật) của
nhà nước thay cho quy tắc riêng của tổ chức
 Chuẩn hóa các đặc tả yêu cầu và áp dụng chuẩn

của thế giới (vd: dùng công nghệ chuẩn, giao tiếp
chuẩn, trừu tượng hóa yêu cầu cụ thể thành vấn đề
phổ biến)


Perfective maintenance

19

Phát biểu các yêu cầu thành các bài toán chuẩn
hoặc phổ biến để dùng pattern (kiểu mẫu) có sẵn
 Thiết kế PM thành các thành phần (sub-system
hoặc package) có khả năng sử dụng lại cao
Trừu tương hóa các phương thức
 Sử

dụng cơ chế đa hình để thêm mới thay vì
sửa
 Thiết kế phần mềm có tính tùy biến cao bằng
thông số cấu hình bên ngoài
Vd: Các quy tắc tính toán, xử lý dữ liệu,.. của nghiệp
vụ được khai báo trong file .ini hoặc CSDL thay vì viết
thành mã lệnh.


Preventive maintenance

20
 Undo

là giải pháp tổng quát cho các thay đổi có
thể gây hại đến hệ thống
Được cài đặt trong MS Office
Cài đặt trong hệ quản trị CSDL của Oracle

 Fault

tolerance được cài đặt để giúp cho hệ
thống chịu đựng các hư hỏng từ phần cứng
 Control chart là cơ chế phát hiện sự bất thường
có thể gây hại cho hệ thống
…