đề cương ôn thi phân tích và thiết kế phần mềm

đề cương ôn thi phân tích và thiết kế phần mềm

ĐỀ CƯƠNG PHÂN TÍCH VÀ THIẾT KẾ PHẦN MỀM

*************************

ĐỀ CƯƠNG PHÂN TÍCH VÀ THIẾT KẾ PHẦN MỀM 1

************************* 1

Chương 0 Cơ sở của phân tích và thiết kế phần mềm 5

1 Nêu khái niệm phân tích và thiết kế phần mềm (Software analysis and development)

5

2.Phân biệt khái niệm Phương pháp luận (methodologies) và Kỹ thuật (technique) 5

3.Công cụ (tool): Vai trò, tác dụng Nêu tên một số công cụ chính và ứng dụng của những công cụ này 5

4 Phân tích viên (Software Analyst): Vai trò và vị trí của cán bộ này trong công ty phần mềm 6

5 Quá trình phát triển của phương pháp tiếp cận phân tích và thiết kế phàn mềm 6

6 So sánh các phương pháp tiếp cận phân tích và thiết kế phần mềm: phương pháp cổ điển, phương pháp hướng tiến trình, phương pháp hướng dữ liệu 7

7 Hãy nêu phân loại phần mềm theo ứng dụng 7

8 [Thiếu] 7

Chương 1 Tổng hợp và phân tích các yêu cầu phần mềm 7

1 Mô tả quy trình công nghệ học yêu cầu phần mềm ( Requirement Engineering ) 7

2 Hãy nêu bản chất của yêu cầu phần mềm 9

3 Nêu định nghĩa yêu cầu phần mềm nhìn từ phía khách hàng 9

4 Hãy nêu các thói quen tốt và thói quen không tốt trong công nghệ học yêu cầu phần mềm 9

5 Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp xác định yêu cầu phần mềm Phỏng vấn (interview) 10

6 Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp xác định yêu cầu phần mềm Hội thảo 10

7 Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp xác định yêu cầu phần mềm Brainstorming 11

8 Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp xác định yêu cầu phần mềm Storyboarding 12

9 Trình bày quy trình thực hiện(Các bước), đặc điểm và những kỹ thuật phương pháp xác định yêu cầu phần mềm áp dụng UseCase 12

10 Trình bày quy trình thực hiện(Các bước), đặc điểm và những kỹ thuật phương pháp xác định yêu cầu phần mềm áp dụng Prototyping 14

11 Trình bày các yêu cầu khi xác định nhiệm vụ và phạm vi của phần mềm 14

12 Xác định và quản lý giới hạn của các yêu cầu phần mềm 15

13 Trình bày phương pháp xác định các yêu cầu phần mềm từ khách hàng 17

14 Trình bày các bước (quy trình) Phân tích các yêu cầu phần mềm 17

15 Các kỹ thuật áp dụng trong Phân tích các yêu cầu phần mềm 17

16 Nêu các tiêu chí chất lượng và đo lường chất lượng yêu cầu phần mềm 18

17 Phân biệt các khái niệm kiểm thử và đánh giá các yêu cầu phần mềm 18

18 Quan hệ giữa yêu cầu và thực hiện [Chưa làm] 19

19 Sử dụng phương pháp Traceability để kiểm thử các yêu cầu phần mềm 19

20 Hãy cho biết khái niệm ROI và phương pháp xác định ROI khi xây dựng 20

các yêu cầu phần mềm 20

21 Kỹ thuật quản lý thay đổi yêu cầu phần mềm 22

22 Nêu các yêu cầu của Đặc tả các yêu cầu phần mềm 23

23 Nêu khái niệm và thành phần của đặc tả yêu cầu phần mềm 23

24 Nêu tên các biểu mẫu của đặc tả yêu cầu phần mềm (theo IEEE và CMU) 24

25 Nêu các kỹ thuật viết đặc tả yêu cầu phần mềm 24

26 Nêu phương pháp và kỹ thuật kiểm duyệt (review) lại các yêu cầu đã xây 24

dựng 24

27 Kiểm thử (testing) yêu cầu phần mềm 24

28 Đánh giá các yêu cầu phần mềm theo các thuộc tính chất lượng phần mềm 25

29 Nêu phương pháp theo dõi các yêu cầu phần mềm và đảm bảo các yêu cầu phần mềm 26

30 Nêu tên một số kỹ thuật phát hiện các yêu cầu phần mềm 28

31 Phân loại người sử dụng có vai trò như thế nào trong phát hiện các yêu cầu phần mềm 28

32 Nêu tên các kỹ thuật mô hình hoá yêu cầu phần mềm Hãy đưa ra giải thích ngắn gọn về đặc điểm của từng kỹ thuật 28

33 Trong cấu trúc của Đặc tả yêu cầu phần mềm (SRS) System Requirement và Software Requirement được hiểu khác nhau như thế nào và được đặc tả ở vị trí nào trong tài liệu SRS 29

34 Tại sao cần kiểm thử đánh giá các yêu cầu phần mềm Nêu tên một số phương pháp kiểm thử yêu cầu phần mềm thông dụng mà em biết 29

35 Nêu các phương pháp theo dõi vết của yêu cầu phần mềm 29

36 Quản lý thay đổi yêu cầu phần mềm 30

37 chức năng của EA hỗ trợ đặc tả yêu cầu phần mềm 31

38 Các chức năng của EA hỗ trợ mô hình hóa yêu cầu phần mềm 33

39 Các kỹ thuật trong EA giúp phân tích yêu cầu phần mềm 34

Chương 2 Thiết kế phần mềm (Software Design) 36

1.Nêu quy trình thiết kế phần mềm mức Logic 36

2 Các phương pháp tạo các thiết kế mức logic (Logical Design) 36

3 Đặc tả tài liệu thiết kế mức logic 36

4 Kiểm thử và tối ưu thiết kế mức logic 37

5 Quá trình mô hình hóa dữ liệu mức logic 37

6 Quá trình và các phương pháp tạo các thiết kế mức vật lý 38

7 Nêu phương pháp xác định các yêu cầu đối với kiến trúc phần mềm 38

8 Nêu các hướng tiếp cận xây dựng kiến trúc phần mềm 39

9 Các thuộc tính chất lượng của kiến trúc phần mềm: Availability, Modifiability, 43

Performance, Security, Testability, Usability 43

10 Các thuộc tính chất lượng của kiến trúc phần mềm: Availability, Modifiability, Performance, Security, Testability, Usability 44

12 Các chiến lược và phương pháp đảm bảo thuộc tính chất lượng kiến trúc phần mềm Modifiability 45

13 Các chiến lược và phương pháp đảm bảo thuộc tính chất lượng kiến trúc phần mềm

45

Performance 45

14 Các chiến lược và phương pháp đảm bảo thuộc tính chất lượng kiến trúc phần mềm

46

Security 46

15 Các chiến lược và phương pháp đảm bảo thuộc tính chất lượng kiến trúc phần mềm

47

Testability 47

16 Các chiến lược và phương pháp đảm bảo thuộc tính chất lượng kiến trúc phần mềm Usability: 47

17 Phương pháp ATAM: Đặc điểm, Bản chất, Các kỹ thuật tiêu biểu 48

18 Phương pháp CBAM: Đặc điểm, Bản chất, Các kỹ thuật tiêu biểu 48

Câu 19: Đặc điểm và bản chất của phương pháp Function-oriented(structured) Design

49

Câu 20: Đặc điểm và bản chất của phương pháp Object-Oriented Design 49

Câu 21: Đặc điểm và bản chất của phương pháp Data-structure Centered Design 51

22 Nêu đặc điểm và bản chất phương pháp Component-based Design (CBD) 51

23.Nêu khái niệm về MSF và các phase trong MSF 52

24.Nêu quá trình thiết kế giao diện và tương tác phần mềm 52

25.Nêu các yêu cầu của giao diện và tương tác 52

26.Nêu một số kỹ thuật trong thiết kế giao diện và tương tác 53

27.Đặc điểm mô hình hóa thiết kế dữ liệu mức khái niệm (conceptual data modeling)

53

28 Đặc điểm mô hình hóa dữ liệu mức khái niệm 54

29 Quá trình mô hình hóa dữ liệu mức khái niệm 54

30 Nêu một số các kỹ thuật trong mô hình hóa dữ liệu mức khái niệm [Chưa làm] 54

31 Đặc điểm mô hình hóa dữ liệu mức Logic 54

32 Quá trình mô hình hóa dữ liệu mức Logic 55

34 Nêu các kỹ thuật đảm bảo chất lượng phần mềm ở giai đoạn thiết kế 55

35 Nêu các đặc điểm trong giai đoạn ổn định và giai đoạn triển khai 56

36 Các yêu cầu của đặc tả phần mềm 56

37 Định dạng đặc tả phần mềm: Các loại tài liệu 57

38 Các quy định chung về định dạng đặc tả 57

39 Một số kỹ thuật chính trong thiết kế đặc tả 57

40 Nêu các phương pháp kiểm duyệt, kiểm thử và đánh giá các đặc tả phần mềm 58

Các tiêu thức để đánh giá một đặc tả: tính nhất quán, tính thân thiện dễ sử dụng 58

41 Các chức năng của EA giúp thiết kế phần mềm mức Logic 59

42 Các chức năng của EA giúp phân tích các thuộc tính chất lượng của kiến trúc phần mềm 59

Chương 3 Xây dựng phần mềm (Software Construction) 59

Câu 1:Trình tự thiết kế chi tiết 59

Câu 2: Nêu các kỹ thuật thiết kế thành phần phần mềm : Phân chia thành các thành phần,xác định đặc tả chức năng ,Giao diện giữa các thành phần 59

Câu 3: Nêu các kỹ thuật thiết kế vào /ra :Thiết kế báo cáo ,Thiết kế giao diện người dùng ,Thiết kế màn hình ,Phương pháp kiểm tra vào /ra và thiết kế thông báo 60

Câu 4: Thiết kế dữ liệu vật lý 60

Câu 5: Nêu tên các tài liệu thiết kế chi tiết 61

Câu 6: Nêu tổ chức các tài liệu thiết kế chi tiết 61

7 Nêu các biểu mẫu thiết kế màn hình [Không chắc chắn]: 63

8 Nêu các biểu mẫu thiết kế báo cáo [Không chắc chắn]: 63

9 Nêu các phương pháp xét duyệt thiết kế chi tiết 63

10 Nêu trình tự thiết kế chương trình 63

11 Nêu các tiêu chuẩn thiết kế chương trình 64

12 Nêu các tiêu chuẩn phân chia module 64

13.[Thiếu] 65

14 Tạo tài liệu thiết kế chương trình 65

15 Nêu các phương pháp xét duyệt thiết kế [Chưa làm] 65

16 Nêu các phương pháp thiết kế chi tiết và sản xuất phần mềm [Chưa làm] 65

17 Các chức năng của EA giúp thiết kế chi tiết phần mềm 66

Câu 18 Các chức năng của EA giúp thiết kế dữ liệu mức vật lí 66

Chương 0 Cơ sở của phân tích và thiết kế phần mềm

1 Nêu khái ni ệ m phân tích và thi ế t k ế ph ầ n m ề m (Software analysis and development)

Thiết kế phần mềm bao gồm cả chu trình từ xác định kiến trúc, thành phần, giao diện và các nhân tố khác của một hệ thống hay một thành phần nào đó, lẫn kết quả của chu trình đó(định nghĩa của IEEE )

2.Phân biệt khái niệm Phương pháp luận (methodologies) và Kỹ thuật (technique)

Methodologies(Phương pháp luận) Technique(kĩ thuật)

- Phương pháp chung(cách tiếp cận) để tạo ra

phần mềm

- Hiện tại có hai luồng chính của các phương

pháp luận:

+ Structured Methodology(phương pháp cấu

trúc)- (SSADM phân tích cấu trúc và phương

pháp thiết kế…)

+ Object Oriented Methodology(phương pháp

hướng đối tượng)(OOA/OOD…)

- Được thiết kế ra để làm chuẩn hoá quá trình

phần mềm

- Phương pháp cụ thể trong một giai đoạn của phương pháp luận, thực hiện cụ thể của phương pháp luận

VD: SSADM: dùng 3 kĩ thuật chủ yếu: mô hình dữ liệu logic, mô hình luồng dữ liệu, mô hình ứng xử thực thể

OOA/OOD: UML

(Tham khảo K47)

- Phương pháp luận là các hướng tiếp cận khi phân tích thiết kế phần mềm nói chung Đây

là các phương pháp tuân theo một chuẩn thiết kế nào đó được đưa ra nhằm làm chuẩn hóa quá trình thiết kế phần mềm Ví dụ: phương pháp tiếp cận trên xuống, phương pháp tiếp cận hướng dữ liệu, …

- Các kĩ thuật là các phương pháp được sử dụng để thực hiện một giai đoạn nào đó trong toàn bộ chu trình phát triển phần mềm Ví dụ:

o Phương pháp đặc tả hình thức là kĩ thuật dùng để mô tả các đặc tả của phần mềm dựa trên các luật hình thức

o Phương pháp Jackson là kĩ thuật dùng để định nghĩa thuật toán của một chương trình theo cấu trúc dữ liệu đầu vào

3.Công cụ (tool): Vai trò, tác dụng Nêu tên một số công cụ chính và ứng dụng của những công cụ này

Trả lời :

- Vai trò: cung cấp những hỗ trợ tự động hoặc bán tự động cho các quy trình và phương pháp phân tích thiết kế phần mềm Nói cách khác công cụ chính là những phần mềm được tạo ra nhằm mục đích sử dụng chung

- Tác dụng: khi một công cụ được tích hợp thì những thông tin do nó tạo ra có thể được sử dụng cho việc xây dựng và phát triển các phần mềm khác Chính vì vậy việc sử dụng công cụ có một số tác dụng như sau:

o Rút ngắn thời gian phát triển hệ thống

o Kích cỡ phát triển được rút ngắn lại

o Dịch vụ nâng cấp được kèm theo

- Một số công cụ và vai trò của nó:

o CAD: (Computer Aided Design) thiết kế có máy tính hỗ trợ Người làm ra bản thiết kế bằng cách nhận sự hỗ trợ của máy tính qua hiển thị đồ họa

o CAM: (Computer Aided Manufactoring) chế tạo có máy tính hỗ trợ Hỗ trợ cho quản lý tiến trình, chuẩn bị cho sản xuất, kiểm thử xử lý và lắp ráp

o CAE: (Computer Aided Engineering) kĩ nghệ có máy tính hỗ trợ Là hệ thống hỗ trợ cho một loạt các công việc bao gồm từ thiết kế sản phẩm, kiểm thử hiệu năng

Do đó phân tích viên cần phải có các yếu tố sau :

o Am hiểu về công việc của công nghệ phần mềm

o Có nhiều kinh nghiệm và thành thạo trong lập trình phần mềm

o Có hiểu biết chung về nghiệp vụ

o Có các kĩ năng giải quyết vấn đề

o Khả năng giao tiếp tốt

o Linh hoạt và có khả năng thích nghi

- Vị trí: Có vị trí quan trọng đầu tiên trong một dự án Nếu không đưa ra được những phân tích điểm lợi của dự án hay những điểm yếu cần khắc phục cũng như những yêu cầu cần thiết đặt ra của dự án thì có thể dẫn tới thất bại dự án Trong một công ty phần mềm, là người chịu trách nhiệm phân tích những hướng phát triển trong tương lai của công ty cũng như đưa ra những ưu nhược điểm của các mô hình phát triển hiện thời mà công ty đang áp dụng

5 Quá trình phát triển của phương pháp tiếp cận phân tích và thiết kế phàn mềm

- Hướng tiếp cận hướng tiến trình:

o Tập trung vào các giải thuật và xử lý dữ liệu

o Quá trình phát triển phần mềm tập trung thể hiệnc ác phương pháp xử lý dữ liệu

o Cấu trúc dữ liệu thông thường không được thể hiện rõ

o Nhược điểm của hướng tiếp cận: các tệp dữ liệu rất khó xây dựng để thỏa mãn phần mềm

- Hướng tiếp cận hướng dữ liệu:

o Mô tả tổ chức của dữ liệu: mô tả dữ liệu được lấy ở đâu ra và sử dụng như thế nào

o Mô hình dữ liệu được thành lập cũng như mối quan hệ giữa các dữ liệu này

o Sử dụng các business rules dể chỉ ra phương pháp xử lý dữ liệu

- Hướng tiếp cận hướng kiến trúc:

o Lựac họn kiến trúcvà công nghệ phần mềm để thực hiện bài toán

o Áp dụng phương pháp prototyping để nhah chóng xây dựng được phần mềm

o Sử dụng các partern kiến trúc mẫu để chỉ ra phương pháp xử lý dữ liệu

6 So sánh các phương pháp tiếp cận phân tích và thiết kế phần mềm: phương pháp cổ điển, phương pháp hướng tiến trình, phương pháp hướng dữ liệu

So sánh các phương pháp tiếp cận phân tích và thiết kế phần mềm:

- Phương pháp cổ điển: là phương pháp phân tích và thiết kế có cấu trúc Các yêu cầu về

hệ thống đích được phát triển được phân tích bằng việc đặc biệt chú ý tới chức năng của

hệ thống và luồng dữ liệu giữa các chức năng Mục đích của phương pháp này là chuyển các tiến trình trong biểu đồ DFD thành các module chương trình và tiến hành phân chia các module bằng cách tiếp cận trên xuống

- Phương pháp hướng tiến trình: việc phân tích và thiết kế đặt trọng tâm vào các chức năng

do phần mềm thực hiện Không có chuẩn rõ ràng để định nghĩa đơn vị chức năng do đó việc định nghĩa này có thể ảnh hưởng bởi cách nghĩ riêng của người thiết kế Khó điều chỉnh các yêu cầu cho nhiều người dùng Sử dụngc ác chức năng chồng chéo nhau là khó tránh khỏi Kết quả là hệ thống bao gồm nhiều chức năng chồng chéo nhau là một trong những nhân tố làm cho việc bảo trì trở nên khó khăn

- Phương pháp hướng dữ liệu: dữ liệu không thay đổi bởi các yêuc ầu hay đòi hỏi của người dùng về thao tác nghiệp vụ Trong thiết kế hướng dữ liệu hệ thống được thiết kế dựa trên cấu trúc tiến trình dữ liệu Việc phân tích thiết kế được tiến hành cho dữ liệu được tách bạch với yêuc ầu hay đòi hỏi của người dùng về thao tác Do vậy tiến trình được xác định và tích hợp vào trong các thủ tục chuyên dụng dữ liệu

7 Hãy nêu phân loại phần mềm theo ứng dụng

Phân loại phần mềm theo ứng dụng:

Chương 1 Tổng hợp và phân tích các yêu cầu phần mềm

1 Mô tả quy trình công nghệ học yêu cầu phần mềm ( Requirement Engineering ).

Quy trình công nghệ học phần mềm được chia thành 2 giai đoạn: Phát triển yêu cầu và Quản lý yêu cầu Trong đó Phát triển yêu cầu được chia làm các giai đoạn nhỏ hơn: Phát hiện yêu cầu, Phân tích yêu cầu, Đặc tả yêu cầu và kiểm thử yêu cầu

HÌNH 1-2 Phân cấp công nghệ học yêu cầu.

- Trong đó Phát triển yêu cầu được chia làm các giai đoạn nhỏ hơn:

Phát hiện yêu cầu

Phân tích yêu cầu

Đặc tả yêu cầu

Kiểm thử yêu cầu

- Quản lý yêu cầu được hiểu là :”thiết lập và duy trì một thoả thuận với khách hàng về các yêu cầu của dự án phần mềm” (CMU/SEI 1995) Quản lý yêu cầu gồm các bước sau

Xác định giới hạn yêu cầu phần mềm (Requirement baseline)

Duyệt các giới hạn của phần mềm

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

Quy trình phát triển được thể hiện trên hình vẽ sau:

HÌNH 1-3 Biên phân chia giữa phát triển yêu cầu và quản lý yêu cầu

Mô tả quy trình như sau:

Maketing Customer Managerment lấy yêu cầu từ khách hàng, sau đó các yêu cầu đó được tổng hợp lại, phân tích, thỏa thuận với khách hàng, rà soát lại ( Đây là quá trình phát triển yêu cầu ) Kết quả của quá trình phát triển yêu cầu là bản Baseline Requrirements Tài liệu này được chuyển chuẩn hóa và làm mốc cho cả quá trình thay đổi ( gọi là phiên bản cơ sở 1.0)

Phiên bản cơ sở 1.0 được gửi cho khách hàng, bộ phận MCM lại tiếp tục đàn phán với khách hàng trên cơ sở phiên bản này, những yêu cầu thay đổi được tổng hợp, xử lý cập nhập lại

Baseline Requirements

Với mỗi thay đổi cập nhập lại gồm : thay đổi cái gì, ai là người thay đổi, thay đổi ảnh hưởng như thế nào đến hệ thống, đề phòng ra sao Tất cả các thông tin trên được chuẩn hóa thành phiên bản 1.1

Bây giờ phiên bản 1.1 được lấy làm cơ sở Quy trình cứ tiếp tục cho đến khi có sự thống nhất từ khách hàng và đội phát triển

2 Hãy nêu bản chất của yêu cầu phần mềm.

Bản chất của yêu cầu phần mềm là mâu thuẫn

Sự mâu thuẫn thể hiện ở ý niệm về yêu cầu phần mềm xuất phát từ khách hàng và từ người sử dụng

• Các yêu cầu phần mềm xuất phát từ người sử dụng đối với người phát triển phần mềm thông thường quá trừu tượng, ở mức cao

• Ngược lại yêu cầu phần mềm được mô tả từ người phát triển đối với người sử dụng lại ở mức quá thấp, quá chi tiết cho nên người sử dụng không thể hiểu hết được

Vì sự mâu thuẫn đó nên IEEE 1997 đã đưa ra một định nghĩa yêu cầu phần mềm nhìn từ góc độ người sử dụng và người phát triển, và những yêu cầu đó cần được đúc kết thành một văn bản để thống nhất giữa 2 bên

• Văn bản thể hiện các điều kiện khả năng được thể hiện ở (1) và (2)

3 Nêu định nghĩa yêu cầu phần mềm nhìn từ phía khách hàng.

Định nghĩa IEEE về yêu cầu phần mềm từ phía khách hàng:

• Điều kiện hay khả năng của sản phẩm phần mềm cần thiết cho người sử dụng để giải quyết một vấn đề hoặc để giải quyết một mục tiêu (1)

4 Hãy nêu các thói quen tốt và thói quen không tốt trong công nghệ học yêu cầu phần mềm Thói quen tốt:

• Luôn hỏi lại người dùng những gì mình chưa hiểu hết về yêu cầu của họ

• Không chỉ khảo sát yêu cầu với một loại người sử dụng, mà phải bao quát tất cả những người sử dụng

• Đánh dấu những điểm chưa rõ trong đặc tả: Đôi khi chúng ta thiếu một số thông tin về các yêu cầu phần mềm, chúng ta cần thảo luận với người sử dụng để hiểu

chi tiết hơn Tất cả những chỗ như vậy đc đánh đấu là TBD( Tobe determined)

 Tất cả TBD này phải đc giải quyết trước khi bắt đầu quá trình phân tích và xây dựng phần mềm

Thói quen không tốt:

• Tự mình nghĩ ra những yêu cầu của người dùng, hay tự cho mình là người dùng phần mềm

• Người sử dụng là chuyên viên trong lĩnh vực nào đó nên có thói quen nghĩ là tất

cả các phân tích viên đề là các chuyên gia trong lĩnh vực đó  Đưa ra các yêu cầu ngắn gọn mà ko miêu tả kỹ lưỡng hơn chúng là gì

5 Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp xác định yêu cầu phần mềm Phỏng vấn (interview).

Đặt ra các câu hỏi về bản chất của các vấn đề người dùng Để giải quyết vấn đề này, cần

sử dụng các câu hỏi:

- Người sử dụng là ai?

- Khách hàng là ai?

- Nhu cầu của họ có khác nhau không?

- Trong trường hợp nào thì có thể tìm thấy giải pháp cho vấn đề này?

Nội dung của cuộc phỏng vấn có thể được thực hiện theo mẫu như sau:

- Thiết lập tiểu sử người dùng hay khách hàng.

- Đi vào vấn đề

- Tìm hiểu về môi trường người dùng

- Tóm tắt lại những gì thu được.

- Phân tích đầu vào trên các vấn đề của khách hàng.

- Đi vào giải pháp của mình (nếu thích hợp).

- Đi vào cơ hội.

- Đi vào sự đáng tin cậy, hiệu quả và các nhu cầu hỗ trợ.

- Những yêu cầu khác

- Bao quát lại

- Tổng kết phân tích.

Những điểm cần lưu ý khi tiến hành phỏng vấn:

- Chuẩn bị trước nội dung cần phỏng vấn Xem lại các câu hỏi trước khi tiến hành phỏng vấn.

- Trước cuộc phỏng vấn nên tìm hiểu về nền tảng của các bên liên quan và công ty được phỏng vấn.

- Ghi lại những câu trả lời trong quá trình phỏng vấn (Không cố gắng lấy ra thông tin trong lúc này).

- Tham khảo mẫu trong quá trình phỏng vấn để đảm bảo đặt ra những câu hỏi đúng đắn.

6 Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp xác định yêu cầu phần mềm Hội thảo.

Quy trình thực hiện và kỹ thuật xác định yêu cầu phần mềm hội thảo.

- Chuẩn bị Hội thảo

o Quảng bá nội dung

o Đảm bảo các bên liên quan sẽ tham dự.

o Chuẩn bị hậu cần tốt.

o Khởi động vật chất (warm-up materials): gửi material ra trước hội thảo để chuẩn bị tham dự và cũng để tăng hiệu quả của cuộc hội thảo Có 2 loại warm-up materials:

 Thông tin cụ thể về dự án Trong đó có thể bao gồm bản phác thảo của các tài liệu yêu cầu, liệt kê những tính năng được đề nghị, bản sao các cuộc phỏng vấn với những người dùng tiềm năng, báo cáo phân tích về xu hướng, thư từ khách hàng, báo cáo lỗi về hệ thống hiện hành, chỉ thị quản lý mới, dữ liệu marketing mới…

 Chuẩn bị cách suy nghĩ vượt ra khỏi giới hạn.

- Chuẩn bị vai trò cho facilitator (vai trò như người dẫn chương trình hay người chủ tọa):

o Đó là người bên ngoài, có kinh nghiệm.xử lý về quản lý yêu cầu hoặc.

o Là một thành viên trong nhóm và đã đạt được những thành tựu nhất định.

- Lên lịch trình Hội thảo

7 Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp xác định yêu cầu phần mềm Brainstorming

Brainstorming gồm có 2 pha:

- Nêu ra các ý tưởng: Mục đích là đưa ra được càng nhiều ý tưởng càng tốt, mục đích mới

là bề rộng, chưa cần có chiều sâu.

- Thâu tóm lại ý tưởng: Phân tích các ý tưởng được đưa ra, chọn lọc, tổ chức, đánh giá,

mở rộng theo chiều sâu, tinh chỉnh chúng lại thành ý tưởng thích hợp.

Kỹ thuật này có những lợi ích chính sau:

• Khuyến khích được mọi thành viên tham gia.

• Cho phép các thành viên tranh luận với nhau về các ý kiến đề xuất.

• Người điều phối hoặc thư ký duy trì cuộc hội thảo không bị gián đoạn.

• Diễn ra nhanh chóng.

• Đưa ra các giải pháp khả thi cho vấn đề.

• Khuyến khích các ý tưởng, suy nghĩ sáng tạo, độc đáo.

Quy định:

 Không được phép tranh cãi, phê bình gay gắt.

 Tự do sáng tạo, tưởng tượng.

 Đưa ra càng nhiều ý tưởng càng tốt

 Nghiên cứu tổng hợp lại ý tưởng hay.

8 Trình bày quy trình thực hiện (các bước), đặc điểm và những kỹ thuật phương pháp xác định yêu cầu phần mềm Storyboarding

 Không nên đầu tư quá nhiều vào Storyboarding

 Storyboard nên dễ chỉnh sửa.

 Không nên làm quá chi tiết Điều đó sẽ gây khó khăn khi sử dụng các kỹ thuật hoặc công cụ khác nhau khi cài đặt sau này.

 Cố gắng làm cho storyboard liên hệ với nhau, tương tác được với nhau.

9 Trình bày quy trình thực hiện(Các bước), đặc điểm và những kỹ thuật phương pháp xác định yêu cầu phần mềm áp dụng UseCase.

Use Case là một phương pháp luận trong ngôn ngữ mô hình hóa UML Đó là một phương pháp luận khá hoàn chỉnh cho việc phát triển phần mềm hướng đối tượng Use case được mô tả qua biểu đồ Use-case

Use case mô tả tương tác giữa người dùng với hệ, nó cho biết các actor (Các tác nhân) , các chức năng của hệ thống Qua phương pháp mô hình hóa Use case, các tác nhân (Actor) bên ngoài quan tâm đến hệ thống sẽ được mô hình hóa song song với chức năng mà họ đòi hỏi từ phía

hệ thống (tức là Use case) Các tác nhân và các Use case được mô hình hóa cùng các mối quan hệ

và được miêu tả trong biểu đồ Use case của UML Mỗi một Use case được mô tả trong tài liệu, và

nó sẽ đặc tả các yêu cầu của khách hàng

Xây dựng mô hình Use-case:

- Bước đầu tiên của quá trình mô hình hóa Use-Case là định nghĩa hệ thống(Xác định phạm vi của hệ thống – Hình chữ nhật liền nét) : Vì hệ thống là một thành phần của

mô hình Use Case nên ranh giới của hệ thống mà ta muốn phát triển cần phải được định nghĩa rõ ràng Định nghĩa các ranh giới và trách nhiệm của hệ thống không phải bao giờ cũng là việc dễ dàng, bởi không phải bao giờ người ta cũng rõ ràng nhìn ra tác vụ nào có khả năng được tự động hóa tốt nhất ở hệ thống này và tác vụ nào thì tốt nhất nên thực hiện thủ công hoặc dành cho các hệ thống khác Một khía cạnh khác cần chú ý là hệ thống cần phải lớn tới mức độ nào trong phiên bản đầu tiên của nó

Cố gắng tối đa cho phiên bản đầu tiên của hệ thống thường là cách mà người ta hay thực hiện, thế nhưng những mục tiêu quá tầm như vậy có thể khiến cho hệ thống trở nên quá lớn và thời gian để cung cấp hệ thống quá lâu

- Tìm ra các tác nhân(Actor) và các use-case

o Một tác nhân là một người hoặc một vật nào đó tương tác với hệ thống, sử dụng hệ thống Trong khái niệm "tương tác với hệ thống", ý chúng ta muốn nói rằng tác nhân sẽ gửi thông điệp đến hệ thống hoặc là nhận thông điệp xuất phát từ hệ thống, hoặc là thay đổi các thông tin cùng với hệ thống Nói một cách ngắn gọn, tác nhân thực hiện các Use Case Thêm một điều nữa, một tác nhân có thể là người mà cũng có thể là một hệ thống khác (ví dụ như

là một chiếc máy tính khác được nối kết với hệ thống của chúng ta hoặc một loại trang thiết bị phần cứng nào đó tương tác với hệ thống)

o Một Use Case là đại diện cho một chức năng nguyên vẹn mà một tác nhân nhận được Một Use Case trong ngôn ngữ UML được định nghĩa là một tập hợp của các chuỗi hành động mà một hệ thống thực hiện để tạo ra một kết quả có thể quan sát được, tức là một giá trị đến với một tác nhân cụ thể Những hành động này có thể bao gồm việc giao tiếp với một loạt các tác nhân cũng như thực hiện tính toán và công việc nội bộ bên trong hệ thống

- Mô tả các Use-case

- Định nghĩa mối quan hệ giữa các Use-case

- Kiểm tra và phê chuẩn mô hình

Ví dụ:

10 Trình bày quy trình thực hiện(Các bước), đặc điểm và những kỹ thuật phương pháp xác định yêu cầu phần mềm áp dụng Prototyping.

Prototyping là phương pháp xác định yêu cầu phần mềm bằng cách đưa ra các mẫu thử Người phát triển sẽ dựa vào các yêu cầu khảo sát để đưa ra 1 sản phẩm ban đầu phác thảo có thể bằng công nghệ khác với công nghệ sẽ được sử dụng Sau đó có sự trao đổi với người sử dụng, từ

đó tìm ra các yêu cầu một cách cụ thể, rõ ràng hơn, đặc biệt là các yêu cầu có tính “mờ” Việc tạo mẫu thử có thể được sử dụng nhiều lần ở nhiều phần và giai đoạn khác nhau Các mẫu thử được tạo ra có thể có khả năng tái sử dụng, các mẫu thử sau sẽ phát triển liên tiếp nên nền các mẫu thử trước.(Mô hình tiến hóa)

Với mục đích phân tích yêu cầu phần mềm ta xem mẫu thử yêu cầu phần mềm như là sự thực thi riêng lẻ của hệ thống, nhằm mục đích giúp đỡ người phát triển, người sử dụng và khách hàng hiểu cặn kẽ hơn về yêu cầu của hệ thống

Với mục đích phân tích yêu cầu ta có thể chon xây dựng các mẫu thử : throwaway, horizontal, user interface (Nếu muốn nói cụ thể từng loại mọi người đọc sách Managing Requirement Software chương 13 nhe)

Để xây dựng các mẫu thử cho mục đích phân tích yêu cầu phần mềm, trước hết người phát triển phải khảo sát các yêu cầu của hệ thống, tiến hành trao đổi đàm phán với khách hàng Lựa chọn công cụ thích hợp cho việc phát triển mẫu thử Dựa vào các yêu cầu đã khảo sát tạo bản mẫu rồi tro đổi với người sử dụng, với khách hàng, để phát hiện cụ thể hơn các yêu cầu đặc biệt các yêu cầu có tính “mờ” Tiến hành phát triển theo mẫu thử đã được phê duyệt, sau bước đó tiếp tục tạo các mẫu thử có thể sử dụng các mẫu thử đã có từ trước

11 Trình bày các yêu cầu khi xác định nhiệm vụ và phạm vi của phần mềm

Trong phát triển phần mềm, có nhiều yếu tố cấu thành phạm vi của dự án Phạm vi dự án là một hàm của:

• Chức năng cần có để đáp ứng nhu cầu người dùng

• Tài nguyên sẵn sàng cho dự án

• Thời gian cần có để có thể thực hiện dự án

Phạm vi dự án.

 Tài nguyên, trước hết bao gồm lao động từ developers, testers, tech writers, nhân viên đảm bảo chất lượng

Nếu thời gian đủ dài, kết quả công việc có thể được tăng lên, nhưng nó không tăng tỷ

lệ với tài nguyên đầu tư thêm Hiệu quả tổng thể của dự án vì thế mà sẽ bị giảm sút Thêm tài nguyên thậm chí có thể làm chậm dự án bởi vì cần phải đào tạo và hỗ trợ cho nhân sự mới, vì thế sẽ làm giảm năng suất của dự án

Nhằm mục đích phân tích phạm vi, ta coi tài nguyên là không đổi trong suốt dự án

 Thời gian, có thể thay đổi nếu như tài nguyên sẵn có không đủ để hoàn thành các chức năng mong muốn Để phân tích phạm vi, ta coi như thời gian là yếu tố cố định

Chức năng tổng thể bị giới hạn bởi thời gian (cố định) và tài nguyên (cũng cố định), vì thế phạm vi khả thi chính là hình chữ nhật màu trắng

Nếu hiệu năng đòi hỏi phải bổ sung đặc tính của hệ thống bằng với tài nguyên trên thời gian sẵn có thì dự án có phạm vi khả thi

Thông thường trong công nghiệp, các dự án đều là dự án vượt phạm vi

12 Xác định và quản lý giới hạn của các yêu cầu phần mềm

Một số vấn đề quan trọng khi xác định giới hạn của các yêu cầu phần mềm:

• Thiết lập một ranh giới cho các yêu cầu cấp cao, một tập các đặc tính được đánh chỉ mục sẽ được phân cho một phiên bản cụ thể của sản phẩm

• Thiết lập ở mức phác thảo hiệu năng của mỗi đặc tính của ranh giới

• Ước lượng rủi ro cho mỗi đặc tính, hay xác suất thực hiện có thể gây ra ảnh hưởng tới lịch trình và ngân sách

• Sử dụng các dữ liệu này, thiết lập ranh giới đảm bảo sự phân phối các đặc tính có ảnh hưởng đến thành công của dự án

a Ranh giới của các yêu cầu

Mục đích của quản lý giới hạn của các yêu cầu phần mềm là nhằm thiết lập một ranh giới cho các yêu cầu cấp cao của dự án Chúng ta xác định ranh giới theo: tập các đặc tính

được chia thành các chỉ mục, hay các yêu cầu sẽ được phân phối cho một phiên bản cụ thể nào đó của ứng dụng.

Ranh giới các yêu cầu

Ranh giới vạch ra phải:

• Ít nhất là có thể chấp nhận được đối với khách hàng

• Có một khả năng thành công hợp lý

Bước đầu tiên để tạo ranh giới đơn giản là liệt kê các đặc tính được định nghĩa cho ứng dụng Chìa khóa của bước này chính là việc điều khiển mức độ chi tiết

b Thiết lập mức ưu tiên

Trong thiết lập mức ưu tiên, quan trọng là khách hàng và người dùng, quản đốc hoặc một người đại diện nào đó, chứ không phải đội phát triển, sẽ thiết lập mức ưu tiên từ bộ phận marketing trong nhà

c Định mức hiện năng

Thiết lập mức thô cho hiệu năng mỗi đặc tính của ranh giới đã đề xuất Chia nhóm theo 3 mức: thấp-trung bình-cao

d Bổ sung yếu tố rủi ro

Chúng ta coi xét rủi ro là xác suất việc thực hiện đặc tính sẽ gây ra tác động bất lợi đến lịch trình và ngân sách Rủi ro cho phép chúng ta ước đoán được tác động của việc gộp mỗi đặc tính riêng biệt vào trong ranh giới Một đặc tính có độ rủi ro cao có tác động rất xấu đến dự án, dù cho tất cả các đặc tính khác được hoàn thành đúng thời hạn

Rủi ro cũng được chia thành 3 mức như với hiệu năng

e Thu hẹp phạm vi

Thông thường mức ưu tiên, hiệu năng và rủi ro không đồng nhất với nhau Có nhiều chỉ mục cấp thiết lại có hiệu năng thấp, nhiều chỉ mục hữu dụng lại khó thực hiện Từ đó, ta

có thể xem xét ưu tiên cho các đặc tính, áp dụng vào các tài nguyên được cung cấp để tăng tối đa lợi ích cho khách hàng Có thể thêm nhân lực cho đội dự án hoặc có thể cho một số tính năng có độ ưu tiên thấp hơn, dành nguồn lực để phát triển các tính năng tối cần thiết.

13 Trình bày phương pháp xác định các yêu cầu phần mềm từ khách hàng

Trong khi xác định yêu cầu của khách hàng, ta phải xem xét có hai dạng khách hàng:

-Khách hàng cung cấp các yêu cầu về nghiệp vụ : Cung cấp các thông tin về công ty, về các đặc điểm ở mức độ cao, về mô hình và phạm vi của hệ thống

-Khách hàng cung cấp các yêu cầu người sử dụng " cung cấp các thông tin về từng nhiệm vụ cụ thể mà họ sẽ làm việc với phần mềm

Ta cần phối hợp, kết hợp chặt chẽ với hai loại khách hàng trên

Phương pháp xác định yêu cầu của khách hàng :

-Lên lịch hẹn gặp rõ ràng khi thực hiện công việc trao đổi với khách hàng

-Tạo môi trường thân thiện với khách hàng trong khi thực hiện xác định các yêu cầu, tránh làm cho khách hàng khó chịu trong quá trình phỏng vấn(đây là vấn đề rất nhạy cảm)

-Trong khi trao đổi với khách, cần tôn trọng các quyền lợi của khách hàng

-Trong quá trình trao đổi, sử dụng các ngôn từ thông dụng, không sử dụng nhiều các thuật ngữ tin học

-Cần trao đổi về công việc của khách hàng, nắm bắt, học và hiểu các công việc đó(để khi thiết kế

và xác định chức năng cho phần mềm chính xác) Yêu cầu khách hàng giải thích từng đặc điểm công việc nếu chưa hiểu rõ để phần mềm được làm ra sẽ tốt và dễ sử dụng hơn

-Khi xác định được các yêu cầu của khách hàng, cần thực hiện việc đánh trọng số, tức là xác định mức độ quan trọng của từng yêu cầu khách hàng để tập trung xây dựng phần mềm hợp lý

-Tôn trọng khách hàng, ngay cả khi phương pháp của khách hàng khác với mình, vì có thể đó là ý tưởng mới!

-Kết thúc quá trình trao đổi, cần viết các đặc tả phần mềm

14 Trình bày các bước (quy trình) Phân tích các yêu cầu phần mềm

Sau khi thu thập được các thông tin về yêu cầu phần mềm từ khách hàng, ta cần tiến hành phân tích các yêu cầu đó Mục đích của việc phân tích này là để xác các yêu cầu đó có dư thừa, mức độ quan trọng của các yêu cầu đó

-Từ các yêu cầu phần mềm, ta xác định biếu đồ use case

-Xác định các hoạt động nghiệp vụ với các điểm bắt đầu và kết thúc Trong các chu trình này, ta cần xác định các đối tượng tham gia, các luồng thông tin và điều khiển trong chu trình

-Xác định vấn đề của môi trường hoạt động phần mềm

-Thực hiền kết nối các yêu cầu nghiệp vụ và yêu cầu của người sử dụng

-Mô ta cụ thể chính xác các điều kiện và thuận lợi trong khi thực hiện các yêu cầu đó

15 Các kỹ thuật áp dụng trong Phân tích các yêu cầu phần mềm

Các kỹ thuật áp dụng trong Phân tích các yêu cầu phần mềm là:

1 Mã giả (Pseudocode)

2 Máy trạng thái hữu hạn (Finite state machines)

3 Cây quyết định (Decision trees)

4 Cây quyết định dạng đồ thị (Graphic decision trees)

5 Biểu đồ hoạt động (Activity diagrams (flowcharts))

6. Mô hình thực thể liên kết (Entity relationship models)

7 Phân tích hướng đối tượng (Object-oriented analysis)

8 Phân tính cấu trúc (Structured analysis)

9 Biểu đồ luồng dữ liệu (Data flow Diagrams)

16 Nêu các tiêu chí chất lượng và đo lường chất lượng yêu cầu phần mềm.

1 Tiêu chí chất lượng

a Các tiêu chí chất lượng đối với người sử dụng

1) Đáp ứng (availability)2) Hiệu quả (eficiency)3) Mềm dẻo (flexibility)4) Tính toàn vẹn (integrity)5) Khả năng kết hợp vơi hệ thống (interoperability)6) Tin cậy (realibility)

7) Khả năng kiểm soát các dữ liệu không chính xác (robustness)8) Dễ sử dụng (usability)

b Các tiêu chí chất lượng của phân tích viên

1) Bảo dưỡng (maintainability)2) Hiệu quả (portability)3) Mềm dẻo (reusability)4) Dễ kiểm tra (testability)

 Như vậy tổng cộng có 12 thuộc tính chất lượng, cần phải cân bằng các thuộc tính chất lượng

2. Đo lường chất lượng yêu cầu phần mềm Để đánh giá một yêu cầu phần mềm như thế nào

là tốt, dựa vào các đặc điểm sau

a Các đặc điểm đối với từng yêu cầu phần mềm

1) Đầy đủ ( complete )2) Chính xác (Correct)3) Khả thi ( feasible)4) Cần thiét ( necessary).)5) Xếp hạng tính quan trọng và ổn định (Ranked for importance and stability)

6) Rõ ràng

7) Có thể kiểm tra được (Verifiable)

b Các đặc điểm của một tài liệu đặc tả phần mềm tốt

1) Đầy đủ

2) Có thể sửa đổi (Modifiable)3) Có thể thể theo dõi được (Traceable)4) Thống nhất ( consistent)

17 Phân biệt các khái niệm kiểm thử và đánh giá các yêu cầu phần mềm.

* Kiểm thử các yêu cầu phần mềm (Testing): Việc kiểm thử yêu cầu phần mềm nhằm xác định các yêu cầu có đáp ứng được các yêu cầu của người sử dụng không Công việc được thực hiện như sau:

• Viết các trường hợp kiểm thử cho các yêu cầu

• Sử dụng mô hình hộp đen từ các trường hợp kiểm thử để đánh giá họat động hành vi của

hệ thống

• Duyệt các hành vi và theo dõi các hoạt động để kiểm tra hệ thống đang đặc tả có đáp ứng yêu cầu của người sử dụng hay không

•Ma trận theo dõi các trường hợp sửdụng

* Đánh giá các yêu cầu phần mềm

Khác với kiểm thử yêu cầu phần mềm là xem xét xem yêu cầu phần mềm có phù hợp với yêu cầu người sử dụng hay không, việc đánh giá yêu cầu phần mềm lại dựa trên tính nhất quán, thân thiện, và dễ sử dụng của tài liệu đặc tả yêu cầu phần mềm

Cụ thể việc đánh dựa vào các đặc điểm sau:

a Các đặc điểm đối với từng yêu cầu phần mềm tốt

g Có thể kiểm tra được (Verifiable)

b Các đặc điểm của một tài liệu đặc tả phần mềm tốt

a Đầy đủ

b Có thể sửa đổi (Modifiable)

c. Có thể thể theo dõi được (Traceable)

d Thống nhất ( consistent)(Có thể trả lời theo đặc tính chất lượng)

18 Quan hệ giữa yêu cầu và thực hiện [Chưa làm]

19

Sử dụng phương pháp Traceability để kiểm thử các yêu cầu phần mềm

Yêu cầu phần mềm có tính phân cấp

Cho nên cách tốt nhất để kiểm thử các yêu cầu phần mềm là dò vết, đi từ trên xuống dưới, theo từng nhánh, để xem yêu cầu đã đáp ứng với mong muốn người sử dụng hay chưa Kỹ thuật traceability sẽ làm công việc dò vết này

Traceability đi từ yêu cầu cao nhất ( Bessiness requirement ), đặt liên kết tới các yêu cầu liên quan, từ yêu cầu tổng quát cho đến yêu cầu con, tạo thành một cây phân cấp Như vậy khi tiến hành kiểm thử sẽ kiểm thử dựa theo các nhánh trên các cây phân cấp này

20 Hãy cho biết khái niệm ROI và phương pháp xác định ROI khi xây dựng

các yêu cầu phần mềm

( Đáp án cũ: ROI là cụm từ viết tắt của Return on Investment ( Lợi nhuận trên vốn đầu tư )

Là 1 khái niệm trong công nghệ phần mềm ROI là một phương pháp dùng để xác định giá trị của đầu tư phần mềm trong từng trạng thái của sự phát triển từ khởi điểm ban đầu cho đến giai đoạn triển khai

ROI gồm các nhân tố sau:

Trong các phần mềm đã phát triển, chi phí bỏ ra để sửa chữa những yêu cầu lỗi là rất tốn kém, nếu phát hiện càng muộn chi phí lại còn tốn kếm hơn Sau đây là hình minh họa cho chi phí sửa lỗi yêu cầu.

Như vậy để giảm bớt những chi phí này cần phải giảm bớt nguyên nhân yêu cầu sai bằng việc quản lý yêu cầu thật hiệu quả.

Vốn đầu tư: chi phí để quản lý yêu cầu hiệu quả.

Lợi nhuận: Chi phí thu được do không phải sửa các yêu cầu sai.

ROI=Lợi nhuận/Vốn đầu tư.

What Does Return On Investment - ROI Mean?

A performance measure used to evaluate the efficiency of an investment or to compare the efficiency of a number of different investments To calculate ROI, the benefit (return)

of an investment is divided by the cost of the investment; the result is expressed as a percentage or a ratio

The return on investment formula:

Return on investment is a very popular metric because of its versatility and simplicity That is, if an investment does not have a positive ROI, or if there are other opportunities with a higher ROI, then the investment should be not be undertaken.

Investopedia explains Return On Investment - ROI

Keep in mind that the calculation for return on investment and, therefore the definition, can be modified to suit the situation -it all depends on what you include as returns and costs The definition of the term in the broadest sense just attempts to measure the

profitability of an investment and, as such, there is no one "right" calculation

For example, a marketer may compare two different products by dividing

the revenue that each product has generated by its respective marketing expenses A financial analyst, however, may compare the same two products using an entirely

different ROI calculation, perhaps by dividing the net income of an investment by the total value of all resources that have been employed to make and sell the product

This flexibility has a downside, as ROI calculations can be easily manipulated to suit the user's purposes, and the result can be expressed in many different ways When using this metric, make sure you understand what inputs are being used.

21 Kỹ thuật quản lý thay đổi yêu cầu phần mềm

Một điều rõ ràng rằng, thay đổi là một phần tấp yếu của quá trình xây dựng yêu cầu phần mềm, thay đổi có thể đến từ bên trong hoặc bên ngoài, vì vậy quản lý thay đổi là cần thiết.

1.Thay đổi là không thể tránh được , đặt kế hoạch cho nó

2.Vạch ranh giới cho yêu cầu

3.Thiết lập một kênh đơn để điều khiển thay đổi

4.Sử dụng hệ thống điều khiển thay đổi để bắt các thay đổi

5.Quản lý thay đổi một cách phân cấp

(

Recognize that change is inevitable, and plan for it

Baseline the requirements

Establish a single channel to control change

Use a change control system to capture changes

Manage change hierarchically

Sách Manaing software requirements)

)

Thay đổi yêu cầu phần mềm có tính phân cấp, có nghĩa là thay đổi một yêu cầu ở mức trên sẽ kéo theo những yêu cầu mức dưới.

Do đó cần phải theo vết các thay đổi, để biết thay đổi nào dẫn đến thay đổi nào, khi có thay đổi cần phải thông báo cho những ai Kỹ thuật ma trận theo dõi yêu cầu phần mềm có thể đạt được mục đích như vậy

Quá trình lập ma trận như sau:

(1)Xác định các mối liên kết và các khả năng lập ma trận

(2) Chọn dạng ma trận: tổng hợp hay chi tiết

(3) Chọn các chức năng/ các yêu cầu cần theo dõi

(3) Xác định phương pháp gán nhãn các yêu cầu

(4) Xác định nguồn các thông tin về các yêu cầu phục vụ cho sự liênkết

(5) Thông báo cho những người tham gia về sự liên kết

(6) Kiểm soát sự liên kết trong quá trình phá triển phần mềm

22 Nêu các yêu cầu của Đặc tả các yêu cầu phần mềm

Mô tả hoàn chỉnh ứng xử của hệ thống đã phát triển , bao gồm tập các trường hợp

sử dụng ( use cases ) mô tả mọi tương tác người dùng với phần mềm Ngoài ra SRS còn chưa các yêu cầu bổ sung ( các yêu cầu ép ràng buộc lên thiết kế hoặc triển khai như hiệu suất , chất lượng…)

23 Nêu khái niệm và thành phần của đặc tả yêu cầu phần mềm

Là hiểu biết hệ thống của khách hang vào thời điểm thiết kế và phát triển phần mềm Đó

là hợp đồng đảm bảo về cả khách hang và sự hiểu biết hệ thống,các nhu cầu khác trước khi ấn định thời điểm.

24 Nêu tên các biểu mẫu của đặc tả yêu cầu phần mềm (theo IEEE và CMU)

25 Nêu các kỹ thuật viết đặc tả yêu cầu phần mềm

• Làm theo và sử dụng các mẫu đặc tả (ví dụ IEEE 830-1998)

• Xác định rõ các nguồn gốc của yêu cầu phần mềm trong đặc tả

• Đặt nhãn cho các yêu cầu phần mềm

• Ghi lại các nguyên tắc công việc

• Tạo ma trận theo dõi phần mềm

26 Nêu phương pháp và kỹ thuật kiểm duyệt (review) lại các yêu cầu đã xây

• Requirement Inspection Checklist

27 Kiểm thử (testing) yêu cầu phần mềm

Kiểm thử yêu cầu phần mềm là công việc thực hiện lại sau khi có được các yêu cầu phần mềm từ phía NSD, chủ dự án…Qúa trình này là một quá trình cân nhắc về khả năng đáp ứng lại yêu cầu phần mềm do những hạn chế về nhân lực, thời gian và tài chính của đội ngũ phát triển phần mềm.

Quá trình kiểm thử phát hiện các yêu cầu phần mềm đi quá phạm vi và giới hạn của phần mềm, ảnh hưởng đến kiến trúc hệ thống.

Nhìn chung kiểm thử phần mềm là một quá trình kiểm tra các yêu cầu phần mềm, từ đó đưa ra những yêu cầu hợp lý và những phương án chấp nhận được, thỏa mãn cả hai bên

là người sử dụng và người phát triển hệ thống.

Tại sao phải kiểm thử yêu cầu phần mềm:

- Do tính chất 2 mặt của yêu cầu phần mềm: Cách nhìn và suy nghĩ về phần mềm

từ phía người sử dụng và cách nhìn, suy nghĩ về phần mềm từ phía nhà phát triển.

- Người sử dụng đưa ra những đòi hỏi quá cao hoặc chẳng liên quan đến quá trình phát triển phần mềm

- NSD đưa ra các yêu cầu và đề nghị rất khó chấp nhận là gây khó khăn cho các lập trình viên

- NSD đưa ra các yêu cầu nhập nhằng và mơ hồ, quá trình kiểm thử sẽ có trách nhiệm làm rõ các yêu cầu này.

- Phát hiện các đặc tính thừa do người phát triển hệ thống đưa thêm vào hoặc các yêu cầu phụ phần mềm từ phía người sử dụng gây tốn kém và không cần thiết

- Kiểm tra khả năng đáp ứng về mặt kỹ thuật

- Đặc tả rõ ràng và chi tiết các yêu cầu

Tiêu chí kiểm thử yêu cầu phần mềm

- Kiểm tra được, xác minh được

Quy trình kiểm thử yêu cầu phần mềm:

• Ma trận theo dõi các trường hợp sử dụng

28 Đánh giá các yêu cầu phần mềm theo các thuộc tính chất lượng phần mềm

(theo slide mới phần 1.4 Khác với 9 thuộc tính chất lượng của IEEE ??? )

Các đặc tính chất lượng đối với người sử dụng

• Portability

• Reusability

• Testability

Tổng hợp có 12 thuộc tính chất lượng Cần phải cân bằng các thuộc tính chất lượng này

29 Nêu phương pháp theo dõi các yêu cầu phần mềm và đảm bảo các yêu cầu phần mềm

 Phương pháp theo dõi các yêu cầu phần mềm:

Theo dõi dấu vết của một yêu cầu phần mềm cho phép chúng ta quản lý được các yêu cầu phần mềm này, nguồn gốc của nó, các mối liên quan của nó và cách thực hiện, kiểm thử, bảo dưỡng và phát triển nó

 04 thao tác cần thiết với quá trình theo dõi dấu vết của một yêu cầu phần mềm:

• Forward to Requirement: quá trình mang yêu cầu khách hàng(cusomer’s needs) chuyển thành yêu cầu phần mềm

• Backward from Requirement: quá trình xác nhận khả năng đúng đắn của yêu cầu phần mềm bởi yêu cầu của khách hàng

• Forward from Requirement: là quá trình ấn định một yêu cầu cho một hoặc nhiều thành phần hệ thống Thao tác này thuận tiện cho việc ước lượng ảnh hưởng của việc thay đổi yêu cầu phần mềm

• Backward to Requirement: quá trình này chỉ ra rằng yêu cầu đã được kiểm tra thích ứng với hệ thống nhất định

 Người ta còn sử dụng ma trận theo dõi các yêu cầu phần mềm để liên kết các yêu cầu phần mềm và các thành phần khác của hệ thống Các liên kết này thường được thể hiện giữa các thành phần:

• Các trường hợp sử dụng (yêu cầu phần mềm)

• Các yêu cầu chức năng (functional requirement)

• Các thành phần thiết kế(design element)

• Mã chương trình (code)

• Trường hợp kiểm thử(test case)

 Đảm bảo yêu cầu phần mềm(Thẩm định&xác minh các yêu cầu phần mềm):

Mục đích của việc kiểm tra xác minh thẩm định các yêu cầu phần mềm về tính đúng đắn, tính hoàn thiện và chất lượng của các yêu cầu phần mềm

Các yêu cầu phần mềm chúng ta miêu tả trong SRS phải đúng là những yêu cầu từ khách hàng, các yêu cầu giải quyết được những công việc của họ.

Chúng ta có nhiệm vụ kiểm soát tính chính xác, tính không trùng lặp của các yêu cầu phần mềm này.

Các thao tác thẩm định xác minh có thể bao gồm:

Viết các trường hợp kiểm thử cho các yêu cầu: sử dụng mô hình hộp đen từ các trường hợp sử dụng để đánh giá hoạt dộng và hành vi của hệ thống Duyệt các hành vi

và theo dõi các hoạt động để kiểm tra hệ thống đang đặc tả có đáp ứng các yêu cầu của NSD hay không.

Xây dựng tài liệu hướng dẫn sử dụng (user manual): để tiết kiệm thời gian chúng ta

có thể dựng bản nháp của tài liệu hướng dẫn sử dụng và sử dụng nó như là tài liệu để kiểm tra lại các yêu cầu phần mềm.

Định nghĩa các tiêu chuẩn chấp nhận: Hỏi NSD xem các tiêu chí thực họ đánh giá sản phầm phần mềm cần xây dựng theo những tiêu thức như thế nào để chúng ta có thể đưa những tiêu thức đó vào các trường hợp sử dụng của hệ thống

Tham gia vào quá trình duyệt các yêu cầu phần mềm:

Các PTV

Các đại diện của NSD (Product champions)

Tất cả các thành viên của công ty phần mềm sẽ tham gia vào quá trình thực hiện phần mềm: LTV, các nhà kiểm thử, v.v

Các công cụ/biểu mẫu sử dụng:

Các tiêu thức đánh giá(entry and exit criteria check list)

Requirement Inspection Checklist

Kiểm thử các yêu cầu phần mềm(Testing):

Dialog Map

Test Case

Ma trận theo dõi các trường hợp sử dụng

30 Nêu tên một số kỹ thuật phát hiện các yêu cầu phần mềm

( Chỉ nêu tên Dựa theo phần 1.2.5 trong slide cũ – đã bỏ trong slide mới ??? )

31 Phân loại người sử dụng có vai trò như thế nào trong phát hiện các yêu cầu phần mềm

Khi phát hiện yêu cầu phần mềm ta không phải lấy yêu cầu của tất cả các người

sử dụng vì ta không thể có đủ điều kiện để làm việc đó Vì vậy có môt phương pháp được đưa ra đó là phân lớp người sử dụng:

• Chúng ta sẽ phân lớp người sử dụng ra thành các nhóm dựa vào các tiêu chí sau:

 Phân loại theo đặc điểm

 Phân loại theo vị trí địa lý

 Phân loại theo vai trò công tác

 Phân loại theo chức năng

• Sau đó ta liệt kê các loại người sử dụng ra và mô tả chi tiết các đặc điểm của những nhóm người sử dụng đó

• Tìm người sử dụng tiêu biểu cho từng lớp

• Lấy yêu cầu từ những người sử dụng tiêu biểu này

32 Nêu tên các kỹ thuật mô hình hoá yêu cầu phần mềm Hãy đưa ra giải thích ngắn gọn về đặc điểm của từng kỹ thuật

Đây là các hướng mô hình hóa yêu cầu phần mềm hay các kỹ thuật phân tích yêu cầu phần mềm

• SRS

• Stakeholder identification

33 Trong cấu trúc của Đặc tả yêu cầu phần mềm (SRS) System Requirement và Software Requirement được hiểu khác nhau như thế nào và được đặc tả ở vị trí nào trong tài liệu SRS

 Trong cấu trúc của Đặc tả yêu cầu phần mềm (SRS):

• System Requirement (yêu cầu hệ thống) nêu lên cấu hình hiện tại của cơ sở hạ tầng thông tin của hệ thống sẽ được phát triển phần mềm như : cấu hình hạ tầng mạng, hệ thống máy tính, các thiết bị ngoại vi đang có, và ảnh hưởng của chúng lên phần mềm sẽ xây dựng Nó xác định cách mà phần mềm mới phải tương tác với hệ thống đã có và những ràng buộc quan trọng phải được quản lý cẩn thận

• Software Requirement được hiểu là các yêu cầu về phần mềm bao gồm: các chức năng của phần mềm, hiệu năng của phần mềm, các yêu cầu về thiết kế và giao diện, các yêu cầu đặc biệt khác do khách hàng đưa ra.

 Trong tài liệu đặc tả yêu cầu phần mềm (SRS) thì System Requirement được đặt phía trước Software Requirement:

• System Requirement được đặc tả trong phần các yêu cầu chung nhất đối với hệ thống phần mềm sẽ phát triển

• Software Requirement là phần chính của tài liệu SRS, bao gồm mô tả chi tiết yêu cầu đối với từng chức năng mà hệ thống cần phải đạt được , nó được đặc

tả ở phần trung tâm của tài liệu SRS.

34 Tại sao cần kiểm thử đánh giá các yêu cầu phần mềm Nêu tên một số phương pháp kiểm thử yêu cầu phần mềm thông dụng mà em biết

Việc kiểm thử đánh giá các yêu cầu phần mềm là cần thiết bởi vì qua việc kiểm thử đánh giá, chúng ta mới có thể thẩm định được tính đúng đắn, tính hoàn thiện và chất lượng của các yêu cầu phần mềm mà chúng ta đã miêu tả trong SRS Các yêu cầu đó phải đúng là những yêu cầu từ khách hàng, giải quyết được các công việc của họ.

Một số phương pháp kiểm thử yêu cầu phần mềm thông dụng:

- Kiểm thử hộp đen

- Kiểm thử hộp trắng

35 Nêu các phương pháp theo dõi vết của yêu cầu phần mềm

• Có 2 loại theo dõi vết: Tường minh và không tường minh.

o Tường minh: Các mối quan hệ được thêm vào một cách tường minh bởi đội

dự án Ví dụ: Mối quan hệ giữa yêu cầu và các use case.

o Không tường minh: Ví dụ mối quan hệ phân cấp giữa các yêu cầu với nhau Yêu cầu cha có mối quan hệ không tường minh với các yêu cầu con.

• Phương pháp: (từ sách SE – Pressman – p289)

Sau khi xác định yêu cầu, chúng ta lập các bảng theo dõi vết Các bảng này cho phép chúng ta biết khi thay đổi một yêu cầu thì nó sẽ ảnh hưởng đến những nhân tố nào trong hệ thống sẽ xây dựng Một số bảng theo dõi vết:

Features traceability table: Cho biết mối quan hệ giữa yêu cầu và các tính năng mà

khách hàng sẽ thấy được trong sản phẩm.

Source traceability table: Xác định nguồn của từng yêu cầu.

Dependency traceability table: Cho biết mối quan hệ giữa các yêu cầu với nhau Subsystem traceability table: Phân loại các yêu cầu theo các phân hệ mà nó có ảnh

hưởng.

Interface traceability table: Cho biết mối quan hệ giữa yêu cầu và các giao diện của hệ

thống (cả giao diện ngoài và giao diện trong).

36 Quản lý thay đổi yêu cầu phần mềm

Lý do thay đổi yêu cầu phần mềm

Các tác nhân bên ngoài: thay đổi vấn đề, người sử dụng thay đổi quyết định của mình, môi trường bên ngoài thay đổi, hệ thống mới tồn tại.

Các tác nhân bên trong: chúng ta đã không hỏi những người đúng các câu hỏi đúng tại thời gian đúng trong suốt quá trình tập hợp yêu cầu ban đầu Chúng ta đã không tạo ra một tiến trình thực hành để giúp đỡ việc quản lý thay đổi yêu cầu mà thông thường xảy ra theo chiều hướng tăng tiến.

Quá trình để quản lý thay đổi:

1.Đoán nhận những thay đổi tất yếu, và lên kế hoạch xử lý nó

2.Thiết lập ranh giới các yêu cầu.

3.Thiết lập một kênh đơn để kiểm soát sự thay đổi

4.Sử dụng một hệ điều khiển thay đổi để nắm bắt những thay đổi

5.Quản lý sự thay đổi theo phân cấp

Quản lý Cấu hình các yêu cầu :

1 Ngăn ngừa những yêu cầu không hợp pháp và các phá hoại tiềm tàng hay những yêu cầu thay đổi linh tinh.

2 Bảo đảm việc duyệt lại những tài liệu về yêu cầu.

3.Làm thuận tiện việc lấy lại và/ hoặc xây dựng lại những phiên bản trước của tài liệu.

4 Hỗ trợ quản lý, tổ chức ranh giới “giải thoát kế hoạch” cho những cải tiến hoặc cập nhập ngày càng tăng của hệ thống.

5.Ngăn chặn đồng thời việc cập nhật tài liệu hay xung đột và không cho phép cập nhập những tài liệu khác nhau cùng lúc

Các câu từ 37- 39 không chắc chắn:

Tớ không chắc chắn về 3 câu hỏi của thầy: Phân biệt 3 câu hỏi? Thầy hỏi chỉ tập trung vào phần Requirements trong EA, hay việc ứng dụng EA vào đặc tả, mô hình , phân tích yêu cầu người dùng nói chung ( tức Usecases + Requirements )

Có 2 hướng:

• Nêu cả Requirements và Usecases: Khá phù hợp cho câu 38 ( Nếu dựa trên câu 32) Nếu trả lời tóm tắt thì khó tạo khác biệt giữa 3 câu Còn nói chi tiết thì khá dài và mất công.

• Chỉ tập trung chi tiết phần Requirement: trình bày ở dưới.

37 chức năng của EA hỗ trợ đặc tả yêu cầu phần mềm

 Tạo ra các yêu cầu phần mềm bên ngoài (External Requirements)

+ Tạo trong biểu đồ ( Diagram )

• Mở Custom pages trong Enterprise Architect UML Toolbox Chọn Requirements

• Cầm đối tượng Requirement, thả vào trong biểu đồ

• Nhập tên và các thông tin khác cho Requirement Save lại + Tạo trong gói ( Package)

• Nháy phải vào gói, chọn Insert | New Element ( hoặc Ctrl + M )

• Trong hộp thoại New Element, chọn Requirement

• Nhập tên và các thông tin khác cho Requirement Save lại.

 Tạo ra các yêu cầu phần mềm bên trong một Element khác (Internal

Requirements)

Ta có thể tạo ra các yêu cầu phần mềm bên trong 1 Element khác như Usecase, Class,… để chỉ ra rằng Element đó có nhiệm vụ cài đặt các yêu cầu đã nêu.

Để thực hiện việc này, ta thực hiện như sau:

• Mở hộp thoại Properties của Element

• Chọn Tab Require

• Nhập tên Requirement và các thuộc tính của nó.

• Bấm Save để lưu Requirement lại

• Nếu muốn, bấm New để tạo tiếp Internal Requirement khác cho Element, cũng hoặc thực hiện các thao tác quản lý khác ( sắp xếp, sửa, xóa )

• Bấm OK để đóng hộp thoại

 Chuyển yêu cầu bên trong ra ngoài

• Mở hộp thoại Properties của Element Chọn Tab Require

• Chọn Requirement cần chuyển Bấm Move External

• Trong hộp thoại mở ra, chọn package để lưu External Requirement

 Quản lý các thuộc tính cơ bản của yêu cầu:

Các thuộc tính cơ bản của yêu cầu được quản lý trong EA:

• Ghi chú

• Các thông tin khác

 Ghi chú các thông tin bổ sung

• Sử dụng thuộc tính Note

• Sử dụng đối tượng chú thích Note

• Sử dụng Tagged Values (lựa chọn, mở cửa sổ Tagged Values, tạo ra các cặp Key – Value lưu trữ các thông tin bổ sung cho yêu cầu )

 Xóa, sắp xếp các yêu cầu

Thực hiện trong cửa sổ Project Browser, thông qua các button trên toolbox hoặc menu ngữ cảnh.

 Tạo cấu trúc phân cấp cho yêu cầu

Khi muốn chuyển 1 Requirement thành con của 1 Requirement khác, trong cửa sổ Project Browser, ta rê rồi thả Requirement-con vào Requirement-cha.

Với chức năng này, ta có thể xây dựng được cấu trúc phân cấp cho Requirement:

1 requirement lớn có thể bao gồm nhiều Reqiurement nhỏ hơn.

 Đánh số cho các Requirement:

Nháy phải vào package, chọn Show Level Numbering

 Kết xuất thành văn bản

• Lựa chọn Requirement cần kết xuất

• Vào menu, chọn Project | Documentation

• Lựa chọn loại báo cáo phù hợp ( Rich Text Format, HTML,…)

• Trong hộp thoại mở ra, nhập các thông số cần thiết Chú ý chọn Use template là requirement template

….

38 Các chức năng của EA hỗ trợ mô hình hóa yêu cầu phần mềm

 Xây dựng cấu trúc phân cấp của các Requirement:

o EA hỗ trợ lập biểu đồ Requirements, cung cấp các chức năng cho phép mô hình hóa Business rules, features, functional and non-functional

requirements.