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

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 trình bày nội dung về ứng xử với yêu cầu, hệ thống đặc tả yêu cầu cho phần mềm, tiến trình cam kết, khám phá yêu cầu, các phương pháp xem xét bản thiết kế. kính mời quý đọc giả tham khảo nội dung chi tiết.

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

10 C1

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

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

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

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

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

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

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

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 độ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. Những vấn đề, hậu quả và cơ hội khắc phục

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

2. Mục tiêu của dự án →giải quyết n vấn đề nào

3. Yêu cầu đối với sản phẩm/dịch vụ của dự án

4. Phương pháp thực hiện yêu cầu của dự án

5. Giả định và phụ thuộc của phương pháp

6. Các chuyển giao và mốc chuyển giao

7. Lợi ích từ các chuyển giao

8. Nguồn lực & nơi cấp nguồn lực cho dự án

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

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

17

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

1. Mọi yêu cầu đều phải có phương án khả

phía (tiến trình cam kết).

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

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

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ả 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

19

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

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ơ trễ hạn từ hợp đồng phụ làm trễ hạn hợp đồng chính.

phần việc outsource để làm thoả mãn yêu cầu của hợp đồng chính.

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

2.Khám phá yêu cầuCMMI –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

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)

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

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