Bài giảng Software quality assurance: Đặc tả phần mềm -Nguyễn Anh Hào

SW Quality Assurance

1

02. Đặc tả phần mềm

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


Yêu cầu là gi ?

2
 Yêu

cầu (requirements) là đặc tả cho những gì
cần phải được hiện thực (được thoả mãn).
đặc tả hành vi xử lý của phần mềm (functions)
đặc tả các đặc tính của phần mềm (characteristics)
đặc tả các ràng buộc đ/v cách thức phát triễn phần
mềm (constraints).

 Yêu

cầu không tường minh (needs) là những
mong muốn được cho là cần thiết, nhưng không
được đặc tả.
 Cả yêu cầu lẫn mong muốn đều góp phần
quyết định chất lượng của phần mềm.

Software_Requirements, 3rd edition, 2013.pdf: Page 6


2 khía cạnh mô tả cho PM

3

Người sử dụng cần nêu ra các yêu cầu đ/v PM
để nó thoả mãn cho nhu cầu sử dụng của họ.
 VD: đáng tin cậy (reliability)|user là PM cho
kết quả chính xác trong mọi tình huống.
2. Nhà phát triễn cần biết các chức năng và đặc
tính được mong đợi từ PM để làm ra nó.
 ie. developers cần biết
1.




Yêu cầu chức năng (functional requirements)
Yêu cầu đặc tính (non-functional requirements)

 Ví dụ : yếu tố đáng tin cậy|user được developer hiểu
là nhất quán (consistency), chịu đựng được hư hỏng
(fault tolerance) & chính xác (accuracy), là những
thuộc tính cố hữu của PM mà developer có thể kiễm
soát được.

Làm PM thoả mãn yêu cầu (1)

4

 Thông

thường, nhà phát triễn sẽ phiên dịch yêu
cầu và mong muốn của người sử dụng thành
đặc tả chức năng và đặc tính của phần mềm sẽ
xây dựng.
Vấn đề là:
 Liệu các yêu cầu từ users có đủ để làm ra phần
mềm có chất lượng ?


Ie, đôi khi user không nói ra nhưng devs phải biết.

 Các

đặc tính chất lượng được yêu cầu từ users
được hiểu như thế nào cho đúng để cài đặt ?



Hiểu đúng: không hiểu lầm, cả user lẫn devs đều có
chung một ý niệm như nhau đối với yêu cầu.


5

Mối quan hệ giữa các đặc tả

dot arrow = “is the origin of…”, arrow = “are stored in …”
Software_Requirements, 3rd edition, 2013.pdf: Page 8


Các yếu tố tham gia đặc tả yêu cầu

6

 Slide

trước chỉ ra rằng một chức năng của phần
mềm được đặc tả từ 5 nguồn:

1. Yêu cầu từ users (user requirements doc)
 2. Quy tắc quản lý tổ chức (business rules)
 3. Đặc tính chất lượng được mong đợi ở sản phẩm phần
mềm (quality attributes), bắt nguồn từ quy tắc quản lý.
 4. Yêu cầu của hệ thống có chứa phần mềm.
 5. Các giao tiếp ngoài.


 Phần

mềm có chất lượng chỉ khi các đặc tả trên
đã được hiểu đúng và làm đúng, trong đó có đặc
tả về các đặc tính chất lượng được mong đợi (bắt
nguồn từ quy tắc quản lý).

Làm PM có chất lượng (2)

7
 Thực

tế:

Người sử dụng có thể mô tả được yêu cầu chức
năng, nhưng khó mô tả những đặc tính nào của
PM (reusability, maintainability,… ) quyết định
chất lượng của PM.
Đặc tính được yêu cầu đôi khi bị nhầm lẫn, vd: dể
sử dụng (do năng lực của người sử dụng), chạy
nhanh (do tài nguyên cấp cho PM),…
 Vấn

đề trong việc mô tả yêu cầu đ/v SPPM:

Cần chuẩn hoá các yêu cầu chất lượng đ/v phần
mềm (gọi là các yếu tố chất lượng, quality factors,
“QF”) để hiểu đúng và sử dụng đúng từ 2 phía.
Cần ánh xạ các yếu tố chất lượng thành những
đặc tính cố hữu của phần mềm để devs cài đặt
chúng vào trong sản phẩm.


8

Các mô hình chất lượng của SPPM

Các

mô hình chất lượng PM trong SE:

McCall (1977), B. Boelm, …
ISO 9126 (2000) → ISO 25010 →SQuaRE,…
Vai

trò của các mô hình này:

Chuẩn hoá các yếu tố chất lượng của phần
mềm ở góc độ sử dụng (tránh trùng lặp, mâu
thuẩn hoặc hiểu lầm).
Ánh xạ các yếu tố chất lượng thành các đặc
tính của sản phẩm phần mềm.
(Để đánh giá mức độ thoả mãn các yêu cầu chất
lượng từ các đặc tính được thiết kế của phần mềm.)


Mô hình Mc.Call (1977)

9

Chuyển giao

Xây dựng

Cập nhật

Sử dụng (vận hành)

PM cần thỏa mãn các yêu cầu & mong đợi từ 3
khía cạnh: chuyển giao, vận hành và cập nhật.
2. Các yếu tố chất lượng (quality factors) được đưa
ra từ 3 khía cạnh này, để users và devs “hiểu
nhau” (có chung quan điểm).
3. Quality factors được mô hình “phiên dịch” thành
các đặc điểm của PM (quality criteria) cho devs
tiến hành xây dựng PM.
1.


10

Mô hình Mc.Call (1977)

Quality Factors = external quality factors


Mc.Call : OPERATION

11

Correctness: là khả năng cung cấp các kết quả
chính xác chấp nhận được.
Reliability: Là khả năng hoạt động ổn định trong
những điều kiện bất thường và tránh được các kết
xuất sai.

1.

2.

◦
◦
3.
4.

5.

Khả năng chịu lỗi.
Khả năng tự phục hồi.

Usability: Là khả năng giúp người sử dụng hiểu
được, học được và sử dụng được phần mềm.
Integrity: Là khả năng bảo vệ thông tin và dữ liệu
để ngăn chặn sự truy cập, đọc hay chỉnh sửa trái
phép.
Efficiency: Là khả năng thực hiện tất cả các chức
năng một cách hợp lý tương ứng với lượng tài
nguyên được phép sử dụng.


Mc.Call : TRANSITION

12

Portablity: Là khả năng dùng được PM trong
nhiều môi trường khác nhau.

1.

◦
◦
◦

Thích nghi với nhiều môi trường (lớp nền,
services,…)
Cùng nhau tồn tại trong môi trường (no conflict)
Thay thế cho phần mềm khác có cùng chức năng

Reusability: Là khả năng sử dụng lại được một
hoặc nhiều thành phần của PM.

2.

◦

PM có thể tháo rời thành nhiều gói dùng lại được

Interoperability: khả năng cộng tác giữa các
thành phần, hoặc giữa PM với các hệ thống
khác.

3.

◦

PM có giao tiếp & phương thức hợp chuẩn.

Mc.Call : REVISION

13

Maintainability: Là mức độ trợ giúp từ PM cho
người bảo trì, để giảm thiểu nổ lực tìm ra
nguyên nhân hư hỏng (failures), sửa chữa
hoặc cải tiến.

1.

◦
◦

Cấu trúc thành phần của PM thuận lợi cho bảo trì
Có tài liệu đặc tả tốt về phần mềm (q.lý cấu hình)

Flexibility: Là mức độ đáp ứng linh hoạt của
PM cho các yêu cầu đa dạng trong phạm vi
sử dụng các chức năng được thiết kế.

2.

◦

Dự trù trước các tình huống tùy biến của chức
năng

Testability: Là mức độ trợ giúp người kiểm tra
đánh giá, chẩn đoán để tìm lỗi hoặc để xác

định những chổ cần sửa của phần mềm.

3.

◦

Bẩy lỗi và báo lỗi trong chương trình


Mc.Call:Mapping

14

Quality Factors

Quality Criteria
Traceability

Correctness

Completeness

OPERATION

Consistency
Reliability

Accuracy
Error tolerance

Efficiency

Execution efficiency
Storage efficiency

Integrity

Access control
Access audit

Usability

Operability
Training
Communicativeness


Mc.Call: Mapping

15

REVISION

Quality Factors
Maintainability
Testability

Quality Criteria
Simplicity
Conciseness

Instrumentation
Self-descriptiveness

Flexibility

Expandability

TRANSITION

Generality
Modularity
Portability
Reusability
Interoperability

Software-system independence
Machine independence
Communication commonality
Data commonality


ISO 9126 (2000) : tiếp cận

16

1.
2.

Chất lượng PM có từ việc sử dụng nó trong
một ngữ cảnh cụ thể (quality in use)

Giống McCall: external quality attributes (QF)
phụ thuộc vào internal quality attributes
(Quality Criteria).

ISO 9126-1 standard.pdf


17

ISO 9126 (2000) : nguyên lý
Specs
Evaluation

User’s view

Dev’s view

Product


development supports

18

ISO 9126 (2000): SW characteristics


19

ISO 9126 (2000): SW in use

application supports

Specified users, specified goals in a specified context of use

Satisfaction

Productivity

Quality
in use
Safety

Effectiveness


Internal attributes (Criteria)

Attribute

Sub-characteristic
Characteristic

ISO 9126-1 standard.pdf

External attributes (QF)

ISO 9126 : Mapping

20