Bài giảng Software quality assurance: Ứng xử với yêu cầu đ/v 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.


Yê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 yêu cầu (Comunicating)
 Mô hình hoá, 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 soát yê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ế toá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

4

(External Quality Factors)

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

Application

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

Trợ giúp
Nơi
phát
sinh
yêu
cầu


Yêu cầu


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

2.
3.
4.
5.

Kế hoạch thực hiện(BPP)



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

Mục tiêu
Nguồn lực
Phương án & rủi ro

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 ngoà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.
 Đâ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ế.
2. Lập bản hợp đồng dự án (contract ) sau khi
proposal/phương án sơ bộ đã hoàn chỉnh.
3. 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 (nếu có).
1.


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 yê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. Thiết lập các kênh thông tin liên lạc;
2. Cách thức nêu yêu cầu & thay đổi yêu cầu;

3. Cách thức chuyển giao và tiêu chí đánh giá;
4. Cách kiểm thử và thông báo lỗi;
5. 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à hoàn toà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ụ


Kế hoạch hợp tác

21
1.

Thể hiện đầy đủ và đúng thực tế về nội dung

thực hiện hợp đồng.
2.

3.

4.

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.
Có đáp ứng cho các thay đổi của hợp đồng.
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 chuyên môn,
các phương tiện, các milestones, các rủi ro,
vv…


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.
2.

3.

User requirement: yêu cầu từ môi trường vận hành của
phần mềm
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)
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)