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

Bài giảng Software quality assurance: Ứng xử với yêu cầu đ/v phần mềm cung cấp cho người học các kiến thức: Ứng xử với yêu cầu, yêu cầu đ/v phần mềm có từ đâu, các ứng xử cơ bản đ/v yêu cầu,... Mời các bạn cùng tham khảo.

Nguyễn Anh Hào Khoa CNTT2

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

2

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

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

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. Yêu cầu phải đưa đến hành động khả thi

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

3

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

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

4

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

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)

5

1.Nhận biết & kiễm soát yêu cầu

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

6

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

Kết cấu của

hệ thống

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

Yêu cầu từ user

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

dot arrow = “is the origin of…”, arrow = “are stored in …”

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

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

9

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

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

10

Y/c Khả thi

Nơi phát sinh yêu

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

2 Xem xét khả năng thực hiện yêu cầu từ phía dự án

3 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

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

11

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í,…?

12

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

13

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

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

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

14

Project Charter

15

1. 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ủ

2. Nó được các key-person (  stackholders)

cùng nhau tạo ra để làm tiên đề cho các hành

 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

của tổ chức thụ hưởng

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

1. 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ế

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ó)

17

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

các phương án được xem xét từ 2 phía (tiến trình cam kết)

từng phiên bản, để có thể thay đổi)

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)

18

b) Lập hợp đồng

1. Hợp đồng có yêu cầu rõ ràng, đầy đủ, không

thừa và hoàn toàn khả thiMọ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

19

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

3. 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ụ

20

Kế hoạch hợp tác

1. 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 chuyên môn, các phương tiện, các milestones, các rủi ro, vv…

21

 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

22

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

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

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

 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)

24

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

SW spec.

External quality requirement

Internal quality requirement

User quality needs

Component requirements

User’s requirements

Trace (vết) Đặc tả (yêu cầu)

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

25

Dò vết của các yêu cầu

 Vết (trace): chỉ ra nguồn gốc (ie, đặc tả đã biết)

phát sinh ra các đặc tả mới

 vd: giải thuật (là đặc tả mới) được đưa ra để thực

hiện một chức năng được yêu cầu (là đặc tả đã biết)

 Nó liên kết các đặc tả giữa các mức phát triễn (phân

tích, thiết kế, lập trình, )

 Việc dò vết yêu cầu giữa các mức là để bảo đảm

tính liên kết nhất quán & mạch lạc (dễ hiểu) giữa các bộ tài liệu đặc tả cho quá trình phát triễn và cập nhật phần mềm

 Dò vết từ hồ sơ phân tích → hồ sơ thiết kế → mã

nguồn & cấu trúc dữ liệu

 Tracing dùng cho phát triễn lẫn kiễm thử phần mềm

26

Các khía cạnh để dò vết

 Toàn diện (coverage): các đặc tả được đưa ra ở

các mức chi tiết (ie, giải pháp ) có đáp ứng được trọn vẹn mọi đặc tả ở mức bên trên (ie, yêu cầu ) không ?

 Ý nghĩa: phát hiện sự thiếu sót (không đủ) của đặc tả mới

 Tác động (impact): Nếu thay đổi (phát sinh, sửa,

hủy) một đặc tả ở mức bên trên, thì những đặc tả nào ở mức chi tiết sẽ bị ảnh hưởng (cần phải thay đổi theo) ?

 Ý nghĩa: chỉ ra phạm vi bị tác động bởi sự thay đổi yêu cầu

 Dẫn xuất (derivation): một đặc tả ở mức chi tiết

được sinh ra từ đặc tả nào ở mức trên (ie, phải có

lý do để tồn tại), và tại sao nó lại nằm ở mức này ?

 Ý nghĩa: phân hoạch các đặc tả vào từng mức phát triễn cho

phù hợp với nội dung thực hiện của từng mức.

27

Product requirements

Component requirements

nó cần nằm ở mức nào ?

Coverage: Đặc

tả chi tiết đã đầy đủ chưa ?

Requirements Engineering, 2nd Edition - 2005.pdf

28

Dò vết trong kiễm thử đặc tả (V-model)

System Test cases

Component Test cases

Coverage: Các test-cases đã được định nghĩa đủ chưa ?

29

Kiễm chứng yêu cầu

 Là hành động chứng minh rằng các đặc tả yêu

cầu đ/v PM phản ánh đúng “mong đợi” từ môi trường mà nó sẽ được phát triễn & vận hành

 Mong đợi: được phát biểu từ những tác nhân

 Các hành động này phân tích mối quan hệ giữa

phần mềm với các môi trường trong suốt chu kỳ sống của nó, để khẳng định rằng các đặc tả là cần thiết, và đầy đủ.

 Phương pháp:

 Revew, Làm mẫu thử

 Định nghĩa các tiêu chí nghiệm thu

 Kiễm thử yêu cầu (để phát hiện sai)

 Giả lập các yêu cầu (để phát hiện thiếu)

30

Dự án: Khảo sát & phân tích

Khảo sát hiện trạng là một hệ thống các công việc đưa ra nhận định về bối cảnh phát sinh vấn

đề, yêu cầu và giải pháp để giải quyết vấn đề

mà PM sẽ hổ trợ thực hiện

 Xem xét: nhu cầu sử dụng PM từ môi trường

nghiệp vụ , khả năng triễn khai áp dụng PM từ

môi trường vận hành , cách thức xây dựng PM trong môi trường phát triễn từ khía cạnh học thuật, mô hình phát triễn, công nghệ và chuẩn

… để đưa ra nhận định về vấn đề và giải pháp.

 Theo dõi sự thay đổi trong các môi trường này;

vì chúng có thể làm thay đổi yêu cầu ban đầu (UP/RUP: giám sát môi trường & quản lý cấu hình)

31

Dự án: Thiết kế phần mềm

Thiết kế phần mềm là một hệ thống các công việc chỉ ra giải pháp cho các vấn đề đã biết, đó

là các đặc tả chi tiết để xây dựng, kiễm thử và triễn khai ứng dụng một phiên bản PM :

 Đặc tả các chức năng và kết cấu của PM (các usecase, class, layers, package/subsystem,…)

 Đặc tả chi tiết để lập trình (mô đun, dữ liệu, giải thuật, giao tiếp, công nghệ / chuẩn,…)

 Đặc tả chi tiết kiễm thử: test cases, test plans

 Đặc tả cách vận hành của PM (mô hình vận hành, các vai trò của users, flat-forms, giao tiếp với các hệ thống khác,… )

32

Yêu cầu & giải pháp trong dự án (1)

33

 Yêu cầu dùng để xây dựng các giải pháp, mà

sau cùng là PM → phát hiện yêu cầu đúng và đầy đủ cho PM càng sớm càng tốt

1 Yêu cầu đúng là yêu cầu từ bản chất của vấn

đề, không hoặc ít thay đổi ( invariances ).

2 Tạo điều kiện cho users tiếp cận sớm với PM

( user involvement ) để nhận được tư vấn thiết thực.

Yêu cầu & giải pháp trong dự án (2)

34

 Xem xét toàn diện các khía cạnh phát triễn,

vận hành, tiến hóa của PM để đưa ra yêu cầu bằng cách phối hợp nhiều chuyên gia

 Tổ chức cuộc họp / forum / workflow

 Ý kiến từ người sử dụng được ưu tiên, vì nó

thường diễn tả yêu cầu từ tổ chức (nghiệp vụ, môi trường vận hành, hiệu quả dùng tài

nguyên, ), tuy nhiên họ chỉ giải quyết vấn đề trước mắt, không giải quyết được vấn đề sử dụng lâu dài của PM (công nghệ, an toàn, cải tiến, )

Yêu cầu & giải pháp trong dự án (3)

35

 PM sẽ thực hiện các chức năng theo yêu cầu

nhưng vì chưa có sẵn, nên khó hình dung cách

xử lý → cần mô tả hành vi của chúng một cách trực quan để các tác nhân (users, devs,

managers) dể tiếp thu

 Bằng các lược đồ (DFD,UMLs)

 Bằng CASE tools: Rational Rose/ Power

Designer/Oracle Designer, ) làm mẫu thử bỏ đi (throw-away prototype)

 Agile: Bằng chính source code đang làm

Yêu cầu & giải pháp trong dự án (4)

36

 Lỗi rất khó phát hiện → việc kiểm thử PM cần

được thực hiện sớm, để tránh gây hậu quả (làm lại, rework) sau này

1 Các công đoạn ban đầu (phân tích, thiết kế, lập

trình) đều cần kiểm thử

2 Xác định các test cases trước khi đặc tả nội

dung xử lý một chức năng.

3 Đặc tả tổng quát cần phải kiểm thử (và sửa cho

đúng) trước đặc tả chi tiết ( top down approach )

4 Tự động hóa việc kiểm thử là rất cần thiết.

Yêu cầu & giải pháp trong dự án (5)

37

 Tài liệu phát triễn PM phải được mô tả một

cách có hệ thống; sự truyền đạt yêu cầu thành giải pháp là rõ ràng, trong suốt (~traceability)

 Mọi vấn đề/giải pháp trong từng mức đều nhất

quán ( consistency )

 Mỗi yêu cầu được cụ thể hóa thành những giải

pháp chi tiết trong mức thấp hơn ( impact )

 Mỗi chi tiết phải giải quyết vấn đề nào đó ở mức

cao hơn ( derive ).

 Liệu mọi yêu cầu ở mức cao đều đã có giải pháp

ở mức chi tiết hơn ? ( coverage)

Yêu cầu & giải pháp trong dự án (6)

38

 Yêu cầu chức năng và phi chức năng cần

được phát triễn đồng thời

 Các yêu cầu phi chức năng được quy chuẩn

thành các yếu tố chất lượng (external quality factors) và diễn tả thành các đặc tính sẽ được cài đặt vào PM bằng mô hình McCall, ISO9126, hoặc ISO 25010,

 Xem xét đồng thời yêu cầu chức năng & tính

năng của PM để quyết định cách thức cài đặt các chức năng này (vd: chọn giải thuật phù hợp).

Xem xét bản thiết kế: ý nghĩa

1. Để phát hiện lỗi phân tích, lỗi thiết kế cũng

như các nội dung mà trong đó sự hoàn thiện, thay đổi hoặc sửa chữa phải làm thỏa mãn cho đặc tả ban đầu, và phải được chấp thuận

2. Để phát hiện rủi ro ảnh hưởng đến dự án

3. Để tìm sự lệch chuẩn chất lượng

 Sửa chữa những sai lệch này dự kiến sẽ góp phần

cải thiện giao tiếp & phối hợp thực hiện nhờ tính nhất quán & phổ biến của chẩn.

4. Để phê duyệt bản phân tích, thiết kế sản

phẩm, cho phép nhóm dự án tiếp tục thực hiện giai đoạn tiếp theo

39