Bài giảng Đảm bảo chất lượng phần mềm: Ứng xử yêu cầu đối với phần mềm - Nguyễn Anh Hào

SW Quality Assurance

1

03. Ứng xử với
yêu cầu đ/v PM


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 thoả mãn bằng cách làm.
đặ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).

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.
 Yêu

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


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

3

Yêu cầu đv PM :
1. Yêu cầu phải được hiểu đúng để làm đúng
Không chỉ dựa vào mô tả của người sử dụng
2.

Yêu cầu phải đầy đủ & nhất quán
Vì PM là hệ thống.

3.
4.

Yêu cầu phải đưa đến hành động khả thi
Yêu cầu có thể thay đổi để có PM tốt hơn
Cách làm cần hổ trợ cho các thay đổi yêu cầu

Sự truyền đạt yêu cầu có 5 đặc điểm: S.M.A.R.T.


u cầu đ/v PM có từ đâu ?

4
1.

Mơi trường ứng dụng PM (hệ thống lớn)
Các vấn đề nghiệp vụ cần giải quyết trong hệ thống
Yêu cầu của user và giải pháp nghiệp vụ của vấn đề

2.

Môi trường vận hành PM (nguồn lực: con
người | phương pháp | cơng cụ)
Máy tính và các thiết bị dùng cho PM
Người sử dụng (trực tiếp và gián tiếp) của phần mềm
Flat-form của phần mềm: hệ điều hành, mạng,…

3.

Môi trường phát triễn PM
Các công cụ làm ra phần mềm: pm để lập trình,…
Năng lực chuyên môn của người làm phần mềm
Phương pháp, kỹ thuật (công nghệ) được chọn để
làm phần mềm


Các ứng xử cơ bản đ/v yêu cầu

5
1.

Nhận biết và kiễm soát yêu cầu (CMMI-level 2-RM)
 Phát hiện nhu cầu sử dụng PM và các yêu cầu từ
người sử dụng, trong đó có sự thay đổi yêu cầu

 Nghiên cứu khả thi: Xác định ích lợi của phần mềm
sẽ xây dựng (nên làm không) và phương án làm

2.

Khám phá yêu cầu (CMMI-level 3-RD)
 Phát triễn yêu cầu cho việc xây dựng phần mềm

3.

Truyền đạt u cầu (Comunicating)
 Mơ hình hố, tài liệu đặc tả, làm mẫu thử (demo)

4.

Kiễm chứng yêu cầu (validation)
 Chứng minh rằng các đặc tả yêu cầu phản ánh đúng
mong đợi đ/v PM (Review)


1.Nhận biết & kiễm sốt u cầu

6


PM khơng chỉ phục vụ cho người sử dụng; nó
phục vụ cho hệ thống lớn hơn
vd: website bán hàng phục vụ cho công việc kinh
doanh và kế tốn của cơng ty. Người sử dụng chỉ
làm một phần công việc của hệ thống.

Yêu cầu đ/v PM = yêu cầu của hệ thống lớn



Yêu cầu từ hệ thống được nêu ra từ người sử
dụng (hoặc stake-holders), và phải được xem
xét một cách có hệ thống vì:
Để tránh chủ quan.
Để khẳng định tính đúng đắn của yêu cầu.
Bảo đảm tính nhất quán của hệ thống.


Problem domain

7

Yêu cầu đ/v PM từ quan điểm hệ thống
Vấn đề
1

(External Quality Factors)

4
3

Yêu cầu từ
user

6

Giải pháp
FR1

FR2
2

5

Yêu cầu về
chất lượng

NFR
7

Design domain

Phần mềm
8

C1
Kết cấu của
hệ thống

9

10

C2
Các hổ trợ
(cơng nghệ)

Đặc tính
của PM
(Internal Attributes)


Hệ thống đặc tả yêu cầu cho PM

Implementation

Operation

Applicatio
n

8

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


9

CMMI-L2: Quản lý yêu cầu
Quản lý yêu cầu (Requirements Management,
RM): là những hành động tìm hiểu yêu cầu đ/v
PM từ khách hàng (users), cam kết làm thỏa
mãn yêu cầu, kiễm soát các thay đổi đ/v yêu
cầu đã biết, và gắn yêu cầu với công việc (kế
hoạch thực hiện) làm thỏa mãn yêu cầu.

 Ie, thiết lập yêu cầu từ quan điểm sử dụng PM

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


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

10
1.

Hiểu đúng yêu cầu từ khách hàng
 Tiêu chí diễn đạt nội dung : S.M.A.R.T
 Có tương tác để kiễm chứng (vd: làm mẫu thử)

2.

Khẳng định trách nhiệm thực hiện yêu cầu
 Bằng tiến trình cam kết

3.

Gắn yêu cầu vào kế hoạch thực hiện, để theo
dõi việc thực hiện (tracking & oversight)
 Ngăn ngừa và loại bỏ sự không nhất quán giữa
yêu cầu và hành động thực hiện

4.

Kiễm soát các thay đổi của yêu cầu
 Nhận biết sự thay đổi trên yêu cầu (vd: version),

và sự thay đổi tương ứng bên trong phần mềm
 Cân nhắc chi phí thực hiện & lợi ích từ sự thay đổi


Tiến trình cam kết

11
Nơi
Nơi
phát
phát
sinh
sinh
yêu
yêu
cầu
cầu

Trợ giúp

Yêu cầu


Khả năng

Y/c Khả thi


 Kết quả thực hiện
1.

2.
3.
4.
5.

Mục
Mục tiêu
tiêu
Nguồn
Nguồn lực
Phương
Phương án
án & rủi
rủi ro
ro
Kế
Kế hoạch
hoạch thực
thực hiện(BPP)
hiện(BPP)
Người thực hiện

Nhận biết yêu cầu từ khách hàng, users hoặc stack-holders
Xem xét khả năng thực hiện yêu cầu từ phía dự án
Xem xét khả năng thực hiện yêu cầu có thêm trợ giúp từ
bên ngồi
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)
Thực hiện theo kế hoạch để làm thỏa mãn cho các cam kết

12

Nghiên cứu khả thi
Mục đích: xác định vai trị & ý nghĩa của PM
trong môi trường vận hành (ie, hệ thống lớn),
và khả năng thực hiện yêu cầu từ dự án.
Nội dung: trả lời các câu hỏi
1. PM sẽ giúp được gì cho users / tổ chức ?
2. PM có hiện thực được khơng, với các hổ trợ
hiện có (vd: cơng nghệ) trong giới hạn cho
phép về chi phí và thời gian ?
3. PM có vận hành được chung với các PM khác
trong mơi trường hiện tại khơng ?
4. Có phương án khả thi được xem xét từ nhiều
phương diện : kỹ thuật, kế hoạch, chi phí,…?


13

Quản lý các thay đổi yêu cầu

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


Dự án: Quản lý yêu cầu

14

Tiền dự án (pre-project) Là một tập hợp có

hệ thống các việc cần làm để khẳng định
các yêu cầu sẽ được cam kết thực hiện (ghi
trong bản hợp đồng) giữa các bên tham gia
vào quá trình tạo ra sản phẩm phần mềm.
 Mục tiêu của tiền dự án:


◦ Lập tôn chỉ (charter) và hợp đồng (contract) để
khẳng định vai trò và trách nhiệm của các bên
tham gia dự án, và các tiêu chí để đánh giá,
nghiệm thu cho hợp đồng dự án.
◦ Khẳng định kế hoạch hợp tác thực hiện (Project
Plan, hoặc BPP).


Project Charter

15
1.

2.

Project charter là tập tài liệu xác định một
cách hết sức cơ bản về trách nhiệm và quyền
hạn của dự án mà các bên có liên quan phải
tuân thủ.
Nó được các key-person (  stackholders)
cùng nhau tạo ra để làm tiên đề cho các hành
động phối hợp thực hiện dự án.
 ie: mọi vấn đề & giải pháp cụ thể đều được dẫn

xuất từ charter này.
 Quá trình thực hiện dự án là chuổi các hành
động phát hiện, hiệu chỉnh các yêu cầu và tìm
giải pháp


Project Charter-Nội dung

16
1.
2.
3.
4.
5.
6.
7.
8.
9.

Những vấn đề, hậu quả và cơ hội khắc phục
của tổ chức thụ hưởng.
Mục tiêu của dự án →giải quyết n vấn đề nào.
Yêu cầu đối với sản phẩm/dịch vụ của dự án.
Phương pháp thực hiện yêu cầu của dự án
Giả định và phụ thuộc của phương pháp
Các chuyển giao và mốc chuyển giao
Lợi ích từ các chuyển giao
Nguồn lực & nơi cấp nguồn lực cho dự án
Vai trò và trách nhiệm của stake-holders đối
với dự án (trong đó có nhiệm vụ và quyền hạn

của trưởng dự án)


Lập hợp đồng dự án

17

Lập bản hồ sơ dự thầu (proposal ) hoặc
phương án sơ bộ gửi đến khách hàng
để hai bên cùng xem xét nội dung yêu
cầu & giải pháp trước khi ký hợp đồng.

1.

◦
2.

3.

Đây là giai đoạn khảo sát để nhận biết yêu
cầu từ hiện trạng thực tế.

Lập bản hợp đồng dự án (contract ) sau
khi proposal/phương án sơ bộ đã hoàn
chỉnh.
Lập bản hợp đồng phụ (sub-contract)
với các đối tác bên ngoài để thực hiện
một phần việc được outsource từ dự án

a) Lập hồ sơ dự thầu

18
1.

2.
3.

Mọi yêu cầu đều phải có phương án khả
thi & các phương án được xem xét từ 2
phía (tiến trình cam kết).
Mọi u cầu được nêu rõ và lập tài liệu
(cho từng phiên bản, để có thể thay đổi).
Thiết lập quan hệ giữa khách hàng & dự
án để hợp tác thực hiện, gồm
1.
2.
3.
4.
5.

Thiết lập các kênh thông tin liên lạc;
Cách thức nêu yêu cầu & thay đổi yêu cầu;
Cách thức chuyển giao và tiêu chí đánh giá;
Cách kiểm thử và thông báo lỗi;
Cách kết thúc từng giai đoạn (nghiệm thu).


b) Lập hợp đồng

19
1.

Hợp đồng có yêu cầu rõ ràng, đầy đủ, khơng
thừa và hồn tồn khả thi
Mọi sự hiểu biết về nội dung dự án (yêu cầu chức
năng, vấn đề tài chính, mong muốn của tác nhân,
giải pháp của yêu cầu,…) đều được thể hiện trong
bản hợp đồng hoặc phụ lục hợp đồng.

2.

Mọi sự thay đổi, thêm hoặc bớt trên nội dung
hợp đồng đã ký, đều phải được thảo luận và
đồng ý giữa các bên.
Thay đổi nội dung hợp đồng (cập nhật, nâng cấp
sản phẩm) cũng cần có cách thức và điều khoản


c) Lập hợp đồng phụ

20


1.

2.

3.

Phạm vi trách nhiệm của các hợp đồng
phụ nhỏ hơn so với hợp đồng chính,
nhưng nó lại góp phần tạo ra chất lượng
cho hợp đồng chính, do đó:
Cần nhận biết sớm và đầy đủ các nguy
cơ trễ hạn từ hợp đồng phụ làm trễ hạn
hợp đồng chính.
Bảo đảm mức chất lượng hợp lý trên các
phần việc outsource để làm thoả mãn
yêu cầu của hợp đồng chính.
Bảo đảm đủ tài liệu để bảo trì các sản
phẩm được chuyển giao từ hợp đồng phụ


21

Kế hoạch hợp tác
Thể hiện đầy đủ và đúng thực tế về nội
dung thực hiện hợp đồng.
2. Tường trình chi tiết về thời gian, nguồn
lực và rủi ro của các cơng việc đang
thực hiện.
3. Có đáp ứng cho các thay đổi của hợp
đồng.
4. Cảnh báo các khó khăn trong quá trình
thực hiện: thiếu hụt nguồn nhân lực
chun mơn, các phương tiện, các
milestones, các rủi ro, vv…
1.

22

2.Khám phá yêu cầu
CMMI –L3: Phát triễn yêu cầu (Requirement
Development, RD)
Phát triễn yêu cầu : là những hành động khám
phá yêu cầu từ hệ thống, phát triễn các yêu
cầu ban đầu thành yêu cầu chi tiết cho từng
công đoạn làm phần mềm và kiễm chứng sự
phù hợp của yêu cầu trong thực tế.
 Ie, chi tiết hoá yêu cầu theo quan điểm tạo sản
phẩm

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


CMMI-L3: Phát triễn yêu cầu (RD)

23
1.

Thấu hiểu yêu cầu đ/v phần mềm
Khám phá (tìm hiểu căn kẽ) yêu cầu từ mong muốn
về phần mềm (users) và những thứ có liên quan đến
phần mềm, theo quan điểm hệ thống.

2.

Chi tiết hóa yêu cầu thành đặc tả cho việc phát

triễn sản phẩm phần mềm
Phiên dịch yêu cầu đ/v PM (nhìn từ quan điểm sử
dụng) thành đặc tả thiết kế, lập trình, kiễm thử,..
(quan điểm xây dựng, tạo sản phẩm)

3.

Phân tích và kiễm chứng các đặc tả
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;
Chỉ ra sự phù hợp của bản thiết kế với các môi trường
nghiệp vụ, vận hành, phát triễn PM.


Chi tiết hóa yêu cầu

24


Là sự cụ thể hóa yêu cầu đ/v sản phẩm phần mềm
thành đặc tả chi tiết trong các mức phát triễn phần
mềm (mức thiết kế, mức lập trình)
 Yêu cầu đối với PM được thể hiện thành các đặc tả cho
PM ngày càng rõ dần (cụ thể hơn) trong quá trình hiện
thực ý tưởng thành sản phẩm PM (mơ hình làm PM).



Theo CMMI v1.3, có 3 mức chi tiết:
1. User requirement: yêu cầu từ môi trường vận hành của

phần mềm
2. Product requirement (hoặc system requirements): yêu cầu
để sản phẩm PM sẽ dùng được tốt trong môi trường vận
hành (external view)
3. Product-component requirement: yêu cầu cho từng
môđun bên trong PM (đặc tả của thiết kế, internal view)


25

Chi tiết hóa yêu cầu từ ISO-9126
(ISO 9126-1)

User’s view

SW spec.

Đặc tả (yêu cầu)

User quality
needs

User’s
requirements

Req.Elicitation

Trace (vết)

External quality

requirement

Product
requirements

Req.Development
Dev ‘s view

Internal quality
requirement

Component
requirements
Yêu cầu ở các mức có liên kết nhau (trace)