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 ln 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
u cầu dự phịng đ/v PM
3
Ngồ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 q 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
q trình làm (khơng có 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
Ngun
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 ngồ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
…