SQA

P3
 Đảm bảo chất lượng phần mềm
Software Quality Assurance


3. Ứng xử với yêu cầu

Nguyễn Anh Hào
Khoa CNTT2, Học viện Công Nghệ BCVT Tp.HCM
: nahao@ptithcm.edu.vn
: 0913609730

Tài liệu môn học – 2019

 Các ứng xử đ/v yêu cầu 3

1. Quản lý yêu cầu (CMMI-L2-RM)

– Ý chính: khám phá yêu cầu mới & kiểm soát chúng.
– Nhận biết đúng về nhu cầu và các yêu cầu từ người sử
dụng, kể cả sự thay đổi yêu cầu ban đầu, và xem xét tính
khả thi.
2. Phát triển yêu cầu (CMMI-L3-RD)
– Ý chính: biến yêu cầu thành đặc tả PM.
– Là việc cụ thể hóa yêu cầu đối với PM của người sử dụng
thành các đặc tả chi tiết về phần mềm cho người phát triển.
Kiểm chứng và diễn đạt yêu cầu cũng là hành động cần phải
có trong cả hai xử lý trên.

CMMI v1-1.pdf
1. Quản lý yêu cầu (RM) 4
 a) RM Hiểu đúng yêu cầu 5

Yêu cầu

Hiểu yêu cầu Xem xét (mẫu)

Tạo/sửa mẫu Đặt yêu cầu
“sả ốn ”
u
(Developers) np
hẩ on gm (Stakeholders:
m” “ m Users,Dev,..)

Tình huống dùng Lợi/hại

(usecases) Mẫu thử (consequences)

Ràng buộc/
Hiệu quả
Phụ thuộc
Rủi ro

Quá trình này dùng để đặt yêu cầu & kiểm chứng yêu cầu (validation)
Các tài liệu để hiểu đúng yêu cầu 6

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

 b) RM Cam kết cho yêu cầu 7

Trợ giúp Khả năng Mục tiêu

Nguồn lực
Nơi
  Phương án & rủi ro
phát
sinh Yêu cầu Y/c Khả thi
Kế hoạch sơ sở (BPP)
yêu cầu
 
Người thực hiện
Kết quả 

1. Nhận biết yêu cầu từ khách hàng, users hoặc stakeholders

2. Xem xét khả năng đáp ứng từ dự án, theo nhiều khía cạnh
3. Xem xét khả năng thực hiện có thêm trợ giúp từ bên ngoài
4. Cam kết thực hiện yêu cầu khả thi bằng kế hoạch cơ sở (base line project
plan, BPP)
5. Thực hiện theo kế hoạch để làm thỏa mãn cho các cam kết
Các khía cạnh xem xét tính khả thi 8
Đàm phán, thỏa thuận 9
Chất lượng của yêu cầu 10
 c) RM Tracking & Oversight 11

 Khởi động Yêu cầu, Tổ chức,

dự án stakeholders
Hiện trạng
Project Charter Thay đổi yêu cầu

Lập kế hoạch  Lập kế hoạch Thay đổi  Kiểm soát

chi tiết tổng thể thay đổi

Q.Lý Chất lượng Baseline Project Plan Cải tiến, khắc phục,
Q.Lý Phạm vi phòng ngừa
Q.Lý Thời gian  Thực hiện  Giám sát &
Q.Lý Chi phí dự án điều khiển
Q.Lý Nhân lực
… Các chuyển giao

 Kết thúc
dự án
 d) RM Kiểm soát các thay đổi 12

Track changes

V1
V2
V3
…

Quản lý thay đổi trên yêu cầu hoặc trên PM đều giống nhau: Quản lý cấu hình
Software_Requirements, 3rd edition, 2013.pdf: Page 18
Dự án: Giai đoạn tiền dự án 13
Project Charter (tôn chỉ) 14
Charter Index 15
Dự án: Lập hợp đồng 16
Hồ sơ dự thầu (proposal) 17
Hợp đồng (contract) 18
19
 2. Phát triển yêu cầu (RD) 20

a) Thấu hiểu yêu cầu đ/v phần mềm

– Khám phá những mong muốn về phần mềm theo quan điểm hệ
thống trong suốt chu kỳ sống của nó.
b) Chi tiết hóa yêu cầu thành đặc tả cho PM
– “Requirements allocation and flow-down”: phiên dịch yêu cầu
đ/v PM (nhìn từ quan điểm sử dụng) thành đặc tả sản phẩm, thiết
kế, lập trình, kiểm thử,.. (quan điểm xây dựng, tạo sản phẩm)
c) Phân tích và kiểm chứng các đặc tả
1. Mô phỏng môi trường vận hành, phân tích các tình huống cần
sử dụng phần mềm (bằng prototype hoặc user story);
2. Chỉ ra sự phù hợp của bản thiết kế PM với các môi trường
nghiệp vụ, vận hành, phát triển của nó.

CMMI DEV-V1.3 (2010).pdf Page 341 & 325

 a) Thấu hiểu yêu cầu đ/v phần mềm 21
Yêu cầu đ/v PM nhìn từ quan điểm hệ thống

Vấn đề SW Requirements
Problem domain

= FRs + NFRs + Constraints

1 4
(External Quality Factors)
3 6
Yêu cầu từ Giải pháp Yêu cầu
users chất lượng
FR1 FR2 NFR
2 5 7
ISO 25010
Phần mềm
Design domain

8 9 10
C1 C2
Đặc tính
Kết cấu của Các hổ trợ
hệ thống
của PM
(công nghệ)
(Internal Attributes)
Môi trường sống của PM 22
Quan hệ giữa PM và môi trường 23
 IEEEstd 1233:1998 24
System Requirements Analysis

6
4

2 3

TECHNICAL REPRESENTATION: DFD/ERD, USECASE/CLASS, PROGRAM,…

CUSTOMER REPRESENTATION: ROLE, PROTOTYPE, USER STORY,…

IEEEstd1233 - System Requirements.pdf, page 7

Các tài liệu để khám phá yêu cầu (RE) 25

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

b) Chi tiết hóa yêu cầu thành đặc tả 26
Chi tiết hóa yêu cầu làm PM 27
 Chi tiết hóa yêu cầu theo CMMI 28

SW spec.
User’s Yêu cầu của users
Needs
requirements được phát triển
thành yêu cầu chi
User’s view

Req.Elicitation
Trace (vết) tiết cho hệ thống (ie,
External Product
usecases), và gán
requirements requirements nhiệm vụ giải quyết
yêu cầu (ie, lập CRC)
Dev ‘s view

Req.Development
cho các thành phần
Internal Component của hệ thống
requirements requirements (components)

Yêu cầu giữa các mức có liên kết nhau (trace)

(Vết và dò vết –Traceability- được trình bày trong phần riêng)

c) Phân tích và kiểm chứng các đặc tả 29
Dự án: Khảo sát & phân tích 30
Dự án: Thiết kế 31
Yêu cầu & giải pháp làm PM (1) 32
Yêu cầu & giải pháp làm PM (2) 33
Yêu cầu & giải pháp làm PM (3) 34
Yêu cầu & giải pháp làm PM (4) 35
Yêu cầu & giải pháp làm PM (5) 36