Bài giảng Thu nhận yêu cầu: Chương 4 - Trần Thị Kim Chi

ươ

ng 4

U H

I

̀

́

Ch Phân ti ch yêu câ u

1

̣ - T T N C a o h K - T T T H n ô M ô B

̣

Nôi dung

U H

• Phân tích yêu cầu là gì • Quá trình phân tích yêu cầu • Tìm kiếm các yêu cầu còn thiếu • Phương pháp phân tích yêu cầu • Prioritization and Ranking of Requirements • Quality Function Deployment (QFD) Method • Các kỹ thuật mô hình hóa

I

• Mô hình hóa mục tiêu (Goal modelling) • Mô hình hóa phân tích (analysis modelling) • Tài liệu đặc tả yêu cầu phần mềm SRS

2

̣ - T T N C a o h K - T T T H n ô M ô B

ầ

ị

Đ nh nghĩa phân tích yêu c u

U H

• Là quá trình suy luận các yêu cầu hệ thống thông qua quan sát hệ thống hiện tại, thảo luận với các người sử dụng, phân tích công việc.

• Việc này có thể liên quan với việc tạo một hay nhiều mô hình khác nhau. Nó giúp các phân tích viên hiểu biết hệ thống.

I

• Các mẫu hệ thống cũng có thể được phát triển

để mô tả các yêu cầu.

3

̣ - T T N C a o h K - T T T H n ô M ô B

ủ

ứ

ể

Qui trình đ  có các ch c năng c a  ệ ố h  th ng

U H

I

4

̣ - T T N C a o h K - T T T H n ô M ô B

ƯỚ

Ẫ

Ầ

NG D N SUY LU N YÊU C U

Ậ H (REQUIREMENTS ELICITATION GUIDELINES)

U H

I

- T T N C a o h K T T T H M B

QUY TRÌNH PHÁT TRIỂN YÊU CẦU GỢI Ý 1.Định nghĩa tầm nhìn và phạm vi của dự án 2.Xác định các lớp người dùng 3.Xác định các đại diện thích hợp của mỗi lớp người dùng 4.Xác định người ra quyết định về yêu cầu và quy trình ra quyết định của họ 5.Chọn các kỹ thuật suy luận mà bạn sẽ dùng 6.Ứng dụng các kỹ thuật suy luận để phát triển các use cases và xếp thứ tự ưu tiên các use cases đó cho từng phần của hệ thống

5

ƯỚ

Ầ

Ẫ

NG D N SUY LU N YÊU C U

Ậ H (REQUIREMENTS ELICITATION GUIDELINES)

U H

I

̣ - T T N C a o h K - T T T H n ô M ô B

QUY TRÌNH PHÁT TRIỂN YÊU CẦU GỢI Ý 7.Thu thập thông tin về các thuộc tính chất lượng và các yêu cầu phi chức năng khác từ người dùng. 8.Phác thảo các use cases từ các yêu cầu chức năng cần thiết 9.Rà xét các mô tả use-case và các yêu cầu chức năng 10.Phát triển các mô hình phân tích, nếu cần thiết, để làm sáng tỏ hiểu biết của những người tham gia suy luận về các phần của yêu cầu

6

ƯỚ

Ầ

Ẫ

NG D N SUY LU N YÊU C U

Ậ H (REQUIREMENTS ELICITATION GUIDELINES)

U H

I

- T T N C a o h K T T T H M B

QUY TRÌNH PHÁT TRIỂN YÊU CẦU GỢI Ý 11.Phát triển và đánh giá các nguyên mẫu giao diện người dùng nhằm trực quan hoá các yêu cầu chưa được hiểu kỹ 12.Phát triển các test cases dưới dạng ý tưởng từ các use cases 13.Sử dụng các test cases để kiểm tra các use cases, các yêu cầu chức năng, các mô hình phân tích, các nguyên mẫu 14.Lặp lại các bước từ 6 đến 13 trước khi thực hiện thiết kế và xây dựng từng phần của hệ thống

7

ụ ủ

ệ

ầ

Nhi m v  c a phân tích yêu c u

U H

I

Trả lời được các câu hỏi sau: •Đầu vào của hệ thống là những gì •Các quá trình cần xử lý trong hệ thống, hay hệ thống phần mềm sẽ phải xử lý những cái gì •Đầu ra: kết quả xử lý của hệ thống là gì •Những ràng buộc trong hệ thống, mối quan hệ giữa đầu vào và đầu ra như thế nào

8

̣ - T T N C a o h K - T T T H n ô M ô B

ụ ủ

ệ

ầ

Nhi m v  c a phân tích yêu c u

Trong quá trình phân tích cần lưu ý đến tính khả thi của dự án:

U H

•Khả thi về kinh tế: chi phí phát triển phải cân xứng với lợi ích mà hệ thống đem lại, gồm có:

•Chi phí:

• Mua sắm: thiết bị, vật tư (phần cứng), tư vấn, cài

I

đặt thiết bị, quản lý và phục vụ,…

9

• Chi phí cho khởi công: phần mềm phục vụ cho hệ thống, hệ thống liên lạc(truyền dữ liệu), nhân sự ban đầu, đào tạo, huấn luyện, cải tổ tổ chức cho phù hợp,…

̣ - T T N C a o h K - T T T H n ô M ô B

ụ ủ

ầ

ệ Nhi m v  c a phân tích yêu c u • Chi phí:

• Chi phí liên quan: chi phí nhân công phục vụ thu nhập dữ liệu,

sửa đổi, cập nhập hệ thống, chuẩn bị tài liệu,…

U H

• Chi phí liên tục là tốn kém nhất gồm: bảo trì, thuê bao, khấu

hao phần cứng, chi phí phục vụ cho vận hành,…

I

Lợi nhuận do sử dụng hệ thống

• Nhiệm vụ xử lý thông tin: giảm chi phí do xử lý tự động, tăng

độ chính xác và kết quả tốt hơn, thời gian trả lời rút ngắn,…

• Có được từ hệ thống: thu thập và lưu trữ dữ liệu tự động, đầy

đủ, dữ liệu được chuẩn hóa, bảo đảm an toàn và an ninh dữ

10

liệu, tương thích và chuyển đổi giữa các bộ phận, truy cập và

tìm kiếm nhanh, kết nối và trao đổi diện rộng

̣ - T T N C a o h K - T T T H n ô M ô B

ụ ủ

ệ

ầ

Nhi m v  c a phân tích yêu c u

• Khả thi về kỹ thuật:

U H

• Rủi ro xây dựng: các phần tử hệ thống (chức năng, hiệu suất) khi thiết kế và phân tích có tương đương hay không?

• Có sẵn tài nguyên: có sẵn con người và tài

nguyên cần thiết để phát triển hệ thống?

• Công nghệ: các công nghệ liên quan cho việc

phát triển hệ thống đã có sẵn hay chưa?

I

11

̣ - T T N C a o h K - T T T H n ô M ô B

ụ ủ

ệ

ầ

Nhi m v  c a phân tích yêu c u

• Khả thi về hợp pháp:

U H

• Có sự xâm phạm, vi phạm hay khó khăn nào gây ra khi xây dựng hệ thống hay không

• Các phương án: đánh giá về phương án

tiếp cận đế việc xây dựng hệ thống

I

12

̣ - T T N C a o h K - T T T H n ô M ô B

̃

́

̣ ̣

Môt sô  lô i khi thu thâp yêu  câ ù • Cố gắng sắp xếp các yêu cầu thu thập được từ hàng tá người dùng sẽ rất khó khăn nếu không có 1 sơ đồ có cấu trúc như use case.

U H

• Thu thập yêu cầu từ 1 số ít các đại diện hay từ các khách hàng ồn ào hay cho ý kiến có thể gây rắc rối như: • Bỏ qua các yêu cầu quan trọng từ các loại người

dùng khác

I

• Quá chú trọng đến những yêu cầu không tiêu biểu

cho nhu cầu của đa số người dùng.

• Cách cân bằng tốt nhất: quan tâm đến 1 vài product

13

champion, họ đại diện cho các loại người dùng.

̣ - T T N C a o h K - T T T H n ô M ô B

̃

́

̣ ̣

Môt sô  lô i khi thu thâp yêu  câ ù • Trong lúc phân tích yêu cầu, có thể phát hiện thấy

U H

phạm vi dự án xác định không đúng • Nếu quá lớn: cần thu thập thêm nhiều yêu cầu để xác định vừa đủ nghiệp vu và nhu cầu khách hàng

I

• Nếu quá nhỏ: khách hàng có thể có các nhu cầu cũng quan trọng nhưng hiện nằm ngoài phạm vi đã xác định của dự án. Việc phân tích sẽ dẫn đến phải chỉnh sửa lại product vision hay project scope.

14

̣ - T T N C a o h K - T T T H n ô M ô B

̀

̀

́

̣

́ Pha t hiên ca c yêu câ u co n  thiê ú • Phân rã các yêu cầu mức cao đủ chi tiết để phát

hiện chính xác cái gì đang được yêu cầu.

U H

• Phải bảo đảm là tất cả các lớp người dùng đều cung cấp dữ liệu. Phải bảo đảm là mỗi use case có ít nhất 1 actor.

I

• Tìm hiểu các yêu cầu hệ thống, use cases, event- response lists, và business rules được chuyển thành yêu cầu chức năng để bảo đảm analyst đã suy dẫn được tất cả chức năng cần thiết.

• Kiểm tra cac giá trị biên cho các yều cầu còn thiếu

đang được xác định

15

̣ - T T N C a o h K - T T T H n ô M ô B

́

̀

̀

̣

U H

I

̣ - T T N C a o h K - T T T H n ô M ô B

́ Pha t hiên ca c yêu câ u co n  thiê ú Ví dụ: Giả sử có 2 yêu cầu như sau: •“If the price of the order is less than $100, the shipping charge is $5.95” •“If the price the order is more than $100, the shipping charge is 5 percent of the total price” Phí chuyển hàng cho 1 hóa đơn có trị giá chính xác 100 là gì? Vẫn chưa xác định được và được xem như 1 yêu cầu còn thiếu

16

Finding Missing Requirements

• Biểu diễn thông tin của mọ

̣i yêu cầu theo

nhiều cách.

U H

• Tập hợp các yêu cầu với toán tử Boolean logic (ANDs, ORs, and NOTs) thường không đầy đủ.

I

• Nếu tổ hợp các điều kiện logic mà không có yêu cầu nào tương ứng, developer phải suy nghĩ xem hệ thống nên làm gì

17

̣ - T T N C a o h K - T T T H n ô M ô B

̣

Ma trân CRUD

• Là 1 cách để tìm yêu cầu bị thiếu. • Viết tắt của Create, Read, Update, and

U H

Delete.

I

• Ma trận CRUD cho sự tương quan giữa các action của hệ thống với các thực thể dữ liệu giúp ta biết được mỗi data item được tạo, đọc, cập nhật, xóa ở đâu và như thế nào.

18

̣ - T T N C a o h K - T T T H n ô M ô B

́

̣ ̣

́

̃

Ma trân CRUDL cho hê thô ng  ́ theo do i ho a châ t

U H

I

19

CRUDL (Create, Read, Update, Delete, List) Có thể rút ra các suy luận gì từ ma trận trên khi nói đến thực thể Requester ???

̣ - T T N C a o h K - T T T H n ô M ô B

́

̣ ̣

Vi  du ma trân CRUDL

• Sau khi tạo ma trận CRUDL, cần kiểm tra

U H

xem: • Có ký tự nào trong 5 ký tự CRUDL không

I

xuất hiện trong 1 cột nào đó không?

- T T N C a o h K

• Ví dụ: một cột không có ký tự C  đối tượng được cập nhật mà không bao giờ được tạo ra? Nếu vậy chúng được tạo ra từ đâu?

20

̣ - T T T H n ô M ô B

́

̣ ̣

U H

I

Vi  du ma trân CRUDL • Cột Requester không chứa D, không có use case nào có thể xóa Requester. Ba khả năng xảy ra: 1. Deleting a Requester is not an expected the Chemical Tracking

function of System.

2. We are missing a use case that deletes

a Requester.

3. The "Edit Requesters" use case

is

incorrect.

21

̣ - T T N C a o h K - T T T H n ô M ô B

̀

́

̀

́ Khi na o thi  kê t thu c viêc thu thâp yêu  câ u?̀

• Nếu người dùng không thể nghĩ ra thêm 1

use case nào khác.

̣ ̣

U H

• Nếu người dùng đề nghị các use case mới nhưng thực tế chúng có thể được suy diễn các use case khác.

• Nếu người dùng lặp lại các vấn đề đã được

xét đến trong các lần thảo luận trước đó.

I

22

• Nếu các tính chất, yêu cầu người dùng, yêu cầu chức năng mới được đề nghị nằm ngoài phạm vi dự án.

̣ - T T N C a o h K - T T T H n ô M ô B

̀

̀

́

́ Khi na o thi  kê t thu c viêc thu thâp yêu  câ u?̀  Nếu các yêu cầu mới được đề nghị có độ ưu tiên

thấp.

̣ ̣

 Nếu người dùng đưa ra các khả năng có thể đôi khi

U H

xuất hiện trong sản phẩm.

I

 Tạo một checklist của các miền chức năng chung. Ví dụ checklist bao gồm error logging, backup and restore, access security, reporting, printing, preview capabilities, and configuring user preferences. So sánh định kỳ danh sách này với các chức năng đã xác định của hệ thống. Nếu không tìm thấy lỗ hổng (gap) nào có nghĩa là chúng ta đã phân tích xong.

23

̣ - T T N C a o h K - T T T H n ô M ô B

Requirements Elicitation Methods

U H

I

24

̣ - T T N C a o h K - T T T H n ô M ô B

Prioritization and Ranking of  Requirements • Prioritization là gán mức độ quan trọng cho yêu

cầu bắng cách dùng tag hay label.

U H

• Priorities thường được xác định ngay khi bắt đầu dự án, bằng cách xếp loại bằng số hay cụm từ, e.g., 1 có nghĩa là quan trọng nhất và 5 là ít quan trọng nhất.

I

• Ranking là gán 1 thứ tự duy nhất cho mỗi yêu cầu trong 1 nhóm, sao cho không có 2 yêu cầu nào có cùng thứ tự (rank)

25

̣ - T T N C a o h K - T T T H n ô M ô B

Prioritization and Ranking of  Requirements

• Khi cần phải quyết định tính năng cần có

U H

trong sản phẩm sẽ phát hành, thì nên dùng kỹ thuật ranking, trong khi đó kỹ thuật prioritization hầu như được dùng khi xác định phạm vi ban đầu của hệ thống.

I

26

̣ - T T N C a o h K - T T T H n ô M ô B

Prioritization and Ranking of  Requirements

U H

• Khi phân phối bảng câu hỏi (questionnaires ) hay phiếu điều tra (survey) cho khách hàng thường luôn có câu hỏi là nên chọn độ ưu tiên nào cho 1 tính năng nào đó của hệ thống , e.g., more likely to buy the product, no difference, less likely to buy the product. • Một vấn đề chung hay xảy ra khi để khách

I

27

hàng đánh giá yêu cầu với 3 mức ưu tiên là “high,” “medium,” hay “low” thì một số khách hàng sẽ luôn gán độ ưu tiên là high cho mọi yêu cầu.

̣ - T T N C a o h K - T T T H n ô M ô B

́

̃

̣

Ca c ky  thuât Prioritization

• “Analytic Hierarchy Process” (AHP) • “planning game,” or PG,

U H

I

28

̣ - T T N C a o h K - T T T H n ô M ô B

“Analytic  Hierarchy  Process”  (AHP) (hay pairwise ranking)

U H

• Để xếp loại yêu cầu, Stakeholder hay analyst tìm 2 yêu cầu, so sánh chúng và đánh giá chúng để tìm ra cái nào quan trọng hơn. Quy trình này sẽ lập lại cho đến khi tất cả yêu cầu được xếp loại.

• Phương pháp này chỉ thích hợp cho những tập

hợp yêu cầu không quá lớn.

I

29

• Vì các stakeholder khác nhau có thể xếp loại yêu cầu rất khác nhau, nên tạo công thức để hợp nhất các tập yêu cầu được đánh giá khác nhau  nên hạn chế các yêu cầu của stakeholder hay các tính năng của sản phẩm.

̣ - T T N C a o h K - T T T H n ô M ô B

“Planning game” (PG)

U H

• Các yêu cầu của stakeholder, các tính năng hay yêu cầu của sản phẩm được phân chia thành 3 tập hợp theo tiêu chuần Kano: – “needed for the system to function,” – “add real value,” – “nice to have but not necessary.”

I

• Thực hiện 1 phân tích rủi ro không chính thức để xác định mức độ thực thi, sau đó quyết định xem nên chọn features hay requirements nào để thực thi.

30

̣ - T T N C a o h K - T T T H n ô M ô B

́

̣ ̉

Đăc ti nh cua ranking

U H

• Việc xếp loại đánh giá phải dựa vào thực tế, e.g., chi phí và rủi ro luôn có liên quan với nhau.

• Một số ngành công nghiệp, có 1 số yêu tố như mối nguy hiểm cho người dùng và công nghệ mới cần phải được khảo sát cùng nhau.

I

31

̣ - T T N C a o h K - T T T H n ô M ô B

́

̣ ̉

Đăc ti nh cua ranking

U H

I

• Ví dụ: kỹ thuật mới cho việc đóng mở cửa sổ của xe hơi dùng cảm biến ánh sáng thay vì dùng công tắc vật lý như trước đây có chi phí thấp được khách hàng đánh giá rất cao, nhưng khi phân tích mối nguy hiểm (hazard analysis ) thì thấy rằng không bảo đảm an toàn, có thể làm cho trẻ con bị thương khi cửa sổ đột ngột mở ra, do đó kỹ thuật này đã không được đưa vào mô hình xe hơi trong năm kế tiếp.

32

̣ - T T N C a o h K - T T T H n ô M ô B

Prioritization and ranking

U H

• Prioritization : Việc xác định độ ưu tiên ban đầu cho các yêu cầu của stakeholder nên được thực hiện càng sớm càng tốt trong chu kỳ phát triển sản phẩm.

• Ranking: Việc xếp loại đánh giá được thực hiện ngay khi các yêu cầu đã thu thập khá đủ như về chi phí, tài nguyên …

I

33

̣ - T T N C a o h K - T T T H n ô M ô B

Quality Function Deployment  (QFD) Method • Mục đích: Để tích hợp các nhu cầu của người dùng

vào thiết kế sản phẩm.

U H

• Trình tự thực hiện:

1. Tìm ra nhu cầu khách hàng từ những người dù nói ra hay không nói ra, từ những lời nói mập mờ không đầy đủ.

2. Phát hiện ra các đặc tính “tích cực” làm phấn

I

chấn khách hàng.

34

3. Chuyển các đặc tính này thành các đặc tính thiết kế và hành động có thể chuyển giao. 4. Xây dựng và phân phối sản phẩm/dịch vụ có chất lượng bằng cách tập trung vào các chức năng nghiệp vụ hướng tới mục tiêu chung – thỏa mãn khách hàng.

̣ - T T N C a o h K - T T T H n ô M ô B

Quality Function Deployment  (QFD) Method • Six Sigma là gì? • Assignment 17??

U H

I

• QFD is often part of a Six Sigma program

35

̣ - T T N C a o h K - T T T H n ô M ô B

Process Modeling Technique

• Kỹ thuật mô hình hóa quy trình (model driven)

U H

phù hợp cho cả elicitation và analysis. • Data flow diagrams (DFDs) • Use case analysis (use case = business

process)

I

36

̣ - T T N C a o h K - T T T H n ô M ô B

Data flow diagrams (DFDs)

• Được sử dụng trong 1 thời gian dài • Tập trung vào dòng dữ liệu và cấu trúc dữ liệu

hơn là vào dịch vụ (services).

U H

I

37

̣ - T T N C a o h K - T T T H n ô M ô B

U H

I

38

̣ - T T N C a o h K - T T T H n ô M ô B

Nhập User id, password  Nhập User id, password

Người quản lý Người quản lý

1.5 1.5 1.5

Nhân viên thực hiện các báo cáo Nhân viên thực hiện các báo cáo

Xem Xem Báo cáo Báo cáo

Thông tin  Thông tin  NV NV

Kiểm tra thẻ/ Kiểm tra thẻ/ Kiểm tra thẻ/ Mượn/Trảsách Mượn/Trảsách Mượn/Trảsách

Nhân viên Nhân viên thư viện thư viện

D4 Thông tin tài khoản D4 Thông tin tài khoản

D5 Thông tin độc giả D5 Thông tin độc giả

D6 Chi tiết mượn / trả sách D6 Chi tiết mượn / trả sách

1.3 1.3 1.3

U H

Độc giả Độc giả

Thông tin Thông tin Độc giả Độc giả

Đăng ký Đăng ký Đăng ký Mượn/Trảsách Mượn/Trảsách Mượn/Trảsách

1.6 1.6 1.6

Nhập Nhập User id,  User id,  password password

Phát sinh các Phát sinh các Phát sinh các Mẫu báo cáo Mẫu báo cáo Mẫu báo cáo

Nhập sách mượn Nhập sách mượn

1.4 1.4 1.4

1.1 1.1 1.1

Sách Sách

Login Login Login

Thông Thông tin Sách tin Sách

I

Tìm kiếm Tìm kiếm Tìm kiếm thông tin sách thông tin sách thông tin sách

̣ - T T N C a o h K - T T T H n ô M ô B

D2 Thông tin Sách D2 Thông tin Sách

D3 Thông tin Sách D3 Thông tin Sách

Nhà cung cấp Nhà cung cấp

Nhập Nhập User id,  User id,  password password

39

1.2 1.2 1.2

D1 User account info D1 User account info

User info User info entry entry

Người quản lý Người quản lý thư viện thư viện

User account  User account  User account  management management management

Use case analysis

• Dùng để chỉ ra quy trình nghiệp vụ và mối

quan hệ giữa hệ thống và thế giới bên ngoài.

U H

• Có thể dùng ngôn ngữ tự nhiên hay bảng

biểu để mô tả use case.

I

40

̣ - T T N C a o h K - T T T H n ô M ô B

Use case analysis

• Một use case mô tả một dãy các tương tác giữa một hệ thống và một “actor” bên ngoài, kết quả là actor hoàn thành một tác vụ (tasks) cho ai đó.

U H

• Một actor là một người, một ứng dụng phần mềm

khác, một thiết bị phần cứng, một thực thể khác nào đó tương tác với hệ thống để đạt được một mục đích nào đó. Còn được gọi là user role.

I

• VD:use case “Đề nghị một hoá chất” của CTS bao hàm một actor gọi là “Requester” (Người đề xuất). Không có lớp người dùng nào trong CTS gọi là “Requester” cả, cả lớp người dùng các nhà hoá học và lớp người dùng nhân viên kho đều có thể đóng vai trò Requester.

41

̣ - T T N C a o h K - T T T H n ô M ô B

Ả Ử Ụ

U H

I

Ị USE CASES VÀ K CH B N S  D NG  (USE CASES AND USAGE  SCENARIOS) • Một use case có thể bao hàm một số các tác vụ (tasks) liên kết logic với nhau và một số chuỗi công việc tương tác lẫn nhau để hoàn thành các tác vụ này.

• Use case là phương pháp nổi bật trong hướng OO,

là tâm điểm của tiến trình RUP.

• Use case chuyển hướng việc phát triển yêu cầu thành việc thảo luận xem người dùng cần hoàn thành cái gì (what), ngược lại với phương pháp truyền thống hỏi người dùng muốn hệ thống làm cái gì.

42

• Mục tiêu của phương pháp use case là mô tả tất cả các nhiệm vụ mà người dùng sẽ cần thực thi với hệ thống.

̣ - T T N C a o h K - T T T H n ô M ô B

Ả Ử Ụ

U H

I

̣ - T T N C a o h K - T T T H n ô M ô B

Ị USE CASES VÀ K CH B N S  D NG  (USE CASES AND USAGE  SCENARIOS) • Use case là một tập hợp các kịch bản (scenario) thông thường có liên quan nhau. • Một kịch bản được gọi là một tiến trình chuẩn (normal course) của các sự kiện nối tiếp nhau tạo nên use case, nó cũng được gọi là tiến trình chính (main course), tiến trình cơ sở (basic course), luồng chuẩn (normal flow), hay là “đường yên lành” (happy path). • Tiến trình chuẩn được mô tả bằng cách liệt kê

một dãy đối thoại (dialogue elements) hoặc dãy tương tác giữa actor và hệ thống.

43

U H

I

44

̣ - T T N C a o h K - T T T H n ô M ô B

U H

I

45

̣ - T T N C a o h K - T T T H n ô M ô B

̃

́

́ Use case cua hê thô ng theo do i ho a  châ t́

̉ ̣

U H

I

46

̣ - T T N C a o h K - T T T H n ô M ô B

̉

Mô ta Use case “request a chemical”

U H

I

47

̣ - T T N C a o h K - T T T H n ô M ô B

̉

Mô ta Use case “request a chemical”

U H

I

48

̣ - T T N C a o h K - T T T H n ô M ô B

ứ

ầ

Use case và yêu c u ch c năng

• Không phải yêu cầu chức năng nào cũng được

đưa vào UseCase

U H

• Khi đặc tả UC nên xác nhận yêu cầu chức năng nào cho phép người dùng hoàn thành mỗi UC • Kiểm tra xem trong tài liệu đặc tả yêu cầu (SRS) đã bao gồm các yêu cầu chức năng được mô tả trong các UC chưa

I

49

̣ - T T N C a o h K - T T T H n ô M ô B

ầ

ứ

I

Use case và yêu c u ch c năng • Các kịch bản khác trong use case được mô tả là các tiến trình thay thế (alternative courses).

U H

• Các tiến trình thay thế cũng nhằm hoàn thành tác vụ (tasks) nhưng chúng được dùng để thay thế tiến trình chuẩn khi một số điều kiện xảy ra khiến không thể thực hiện được tiến trình chuẩn.

50

• Tiến trình chuẩn có thể tách thành một tiến trình thay thế tại một điểm quyết định nào đó trên dãy đối thoại (dialogue sequence), và nhập lại vào tiến trình chuẩn sau

̣ - T T N C a o h K - T T T H n ô M ô B

ứ

ầ

Use case và yêu c u ch c năng

U H

I

51

̣ - T T N C a o h K - T T T H n ô M ô B

Ủ

Ợ

U H

I

L I ÍCH C A USE CASES  (BENEFITS OF USE CASES) • Sức mạnh của cách tiếp cận use-case là suy luận yêu cầu theo quan điểm hướng người dùng (user- centric) và hướng tác vụ (task – centric).

• Giúp phân loại các ý tưởng cần phải làm đối với mỗi

khách hàng.

- T T N C a o h K

• Use cases giúp các nhà phân tích và các nhà phát triển hiểu cả nghiệp vụ của người dùng (user’s business) và miền ứng dụng (problem domain) của bài toán.

52

• Kỹ thuật use-case ngăn ngừa tính năng “mồ côi” – các chức năng có vẻ như là cần thiết khi suy luận nhưng không có ai sử dụng vì chúng chả liên quan gì đến các tác vụ (tasks) của họ

̣ - T T T H n ô M ô B

Ẫ

Ử Ụ

U H

I

- T T N C a o h K

TRÁNH CÁC B Y KHI S  D NG  USE CASES (USE CASE TRAPS TO  AVOID) • Quá nhiều use cases (Too many use cases): Đừng tạo ra một use case riêng cho mỗi kịch bản. Thay vì vậy, hãy gom tiến trình chuẩn (normal course), các tiến trình thay thế (alternative courses), các loại trừ (exceptions) thành các kịch bản (scenarios) trong một use case duy nhất. Đừng xử lý mỗi bước trong chuỗi tương tác giữa actor và system như một use case riêng.

53

• Trùng lặp trong các use cases (Duplicatiom across use cases): Để tránh sự lặp lại đó, hãy sử dụng quan hệ “include” để nhiều use cases sử dụng chung một chức năng.

̣ - T T T H n ô M ô B

Ẫ

Ử Ụ

U H

I

TRÁNH CÁC B Y KHI S  D NG  USE CASES (USE CASE TRAPS TO  AVOID) • Thiết kế giao diện người dùng kèm theo use cases (User interface design included in the use cases). • Đưa các định nghĩa dữ liệu vào use cases (Including data definitions in use cases). Hãy tập hợp các định nghĩa dữ liệu của toàn bộ dự án vào data dictionary

• Cố gắn kết mỗi yêu cầu với một use case

- T T N C a o h K

(Attempting to associate every requirement with a use case).

54

̣ - T T T H n ô M ô B

• Assignment 18: Ôn lại use case và mô tả use case • Yêu cầu:

U H

• Các dạng use case: include, “macro”, extend • Các dạng scenario • Các cách xác định use case • Use case và yêu cầu chức năng • Lợi ích của use case • Một số trường hợp cần tránh khi dùng use case

I

55

̣ - T T N C a o h K - T T T H n ô M ô B

Event­Response Tables

Phương pháp dùng bảng Event-Response để xác định các event bên ngoài mà hệ thống cần phải đáp ứng.

U H

Event là 1 số thay đổi hay hoạt động xảy ra trong môi trường người dùng để kích khởi một đáp ứng (response) từ hệ thống phần mềm.

I

56

Bảng event-response (còn được gọi là event table hay event list) liệt kê tất cả các event và hành vi mà hệ thống đáp ứng lại ứng với mỗi sự kiện.

̣ - T T N C a o h K - T T T H n ô M ô B

̣ ự

̣ ̣

́ ̀

́

́

́ ư

̣

Vi  du ca c loai s  kiên  ́ va  đa p  ng hê thô ng

U H

I

57

̣ - T T N C a o h K - T T T H n ô M ô B

́

́

̣ ự

̣ ̣

Ca c loai s  kiên hê thô ng

U H

• Hành động người dùng mở ra 1 hộp thoại ( dialog) trong phần mềm, cũng giống như khi người dùng bắt đầu 1 use case

• Chuỗi event-response tương đương với các bước

trong hộp thoại của 1 use case.

I

• Bảng event-response không mô tả mục tiêu người dùng khi sử dụng hệ thống hay cho biết tại sao chuỗi event-response cung cấp giá trị gì cho người dùng.

58

̣ - T T N C a o h K - T T T H n ô M ô B

́

́

̣ ự

̣ ̣

Ca c loai s  kiên hê thô ng

• Hành động của con người • Tín hiệu điều khiển hay ngắt từ thiết bị phần cứng

U H

bên ngoài

• Sự kiện kích khởi bởi đồng hồ máy tính

I

59

̣ - T T N C a o h K - T T T H n ô M ô B

́

́

́

̀

Quy tă c nghiêp vu do kha ch ha ng xa c đinh  Customer­Specific Business Rules

• Business rules là loại đặc biệt của yêu cầu khách

hàng.

̣ ̣ ̣

U H

• Khác với các nhu cầu cố định của khách hàng, các

quy tắc nghiệp vụ dùng để: • mô tả việc thực thi chính sách của khách hàng • có thể bị thay đổi bởi chính khách hàng sau khi

sản phẩm được phân phối.

I

60

̣ - T T N C a o h K - T T T H n ô M ô B

́

̀

́

̣ ̣

U H

I

Quy tă c nghiêp vu va  chi nh  sa ch́ • Một tổ chức có thể ban hành, chỉnh sửa hay hủy bỏ các quy tắc nghiệp vụ mà các quy tắc này sẽ chi phối và hướng dẫn tổ chức.

• Chính sách (business policy) là yếu tố quản lý,

- T T N C a o h K

không trực tiếp được thi hành mà dùng để hướng dẫn tổ chức hoạt động. Chính sách không đòi hỏi phải diễn tả có cấu trúc (không cần thuật ngữ tiêu chuẩn) như là quy tắc nghiệp vụ.

61

̣ - T T T H n ô M ô B

̣

Vi  dú

• “Bank customers should not be able to make too

U H

I

many bank withdrawals in a single day or withdraw more than a certain amount of money in a fixed period of time; the maximum amount being based on their total account value and history.”

- T T N C a o h K

Đây là chính sách hay quy tắc nghiệp vụ???? Chính sách

62

̣ - T T T H n ô M ô B

I

Why Are Customer­Specific  Business Rules Important? • Các quy tắc nghiệp vụ do người dùng xác định phải tách riêng khỏi các yêu cầu thông thường, vì chúng không thực sự là yêu cầu.

U H

• Yêu cầu khách hàng có thể được suy diễn từ quy tắc nghiệp vụ, các yêu cầu có thể khác với quy tắc mà chúng được suy diễn.

63

̣ - T T N C a o h K - T T T H n ô M ô B

Why Are Customer­Specific Business  Rules Important?

U H

• Chính quy tắc nghiệp vụ do khách hàng xác định dùng để thực thi chính sách (policy) của công ty, nhưng quy tắc nghiệp vụ có thể thay đổi sau khi hệ thống đã được phân phối.

 Nên xây dựng hệ thống sao cho khách hàng có khả năng thay đổi quy luật mà không làm cho hệ thống bị sửa đổi theo.

I

64

̣ - T T N C a o h K - T T T H n ô M ô B

̣

Vi  dú

• Policy: The hospital shall be able to define the

difference between adult and child patients for check- in and medical records purposes.

U H

I

65

̣ - T T N C a o h K - T T T H n ô M ô B

̣

Vi  dú

Rule: Any patient under the age of 14

U H

I

66

checking in shall be considered a child. When a child checks into the hospital, depending on the hospital’s business policy, a parent or guardian may have to accompany the child and sign all the admission forms. Detailed rules explain under what circumstances (e.g., an accident, emergency, or life-threatening situation) a child may be checked in without a parent’s or guardian’s consent.

̣ - T T N C a o h K - T T T H n ô M ô B

̣

Vi  dú

• Requirement: A facility shall be provided with the

U H

system such that the hospital check-in process for adults and children can be changed by hospital administrators without the need for system or software modifications.

I

67

̣ - T T N C a o h K - T T T H n ô M ô B

̃ ̣ ư

̀ a policy va  business

́ Mô i quan hê gi rule

U H

I

68

̣ - T T N C a o h K - T T T H n ô M ô B

́

̣ ̣

Quy tă c nghiêp vu

U H

• Mỗi tổ chức nghiệp vụ đều phải tuân theo 1 tập các chính sách, luật và tiêu chuẩn (được gọi là business rule). Phần mềm ứng dụng buộc phải tuân theo các quy tắc nghiệp vụ này. Trong một số trường hợp, các quy tắc nghiệp vụ không nằm trong phần mềm nhưng được kiểm soát thông qua việc người dùng phải tuân theo các chính sách và thủ tục.

I

69

̣ - T T N C a o h K - T T T H n ô M ô B

́

̣ ̣

Quy tă c nghiêp vu

• Hầu hết các quy tắc nghiệp vụ đều xuất phát từ bên

ngoài ngữ cảnh của bất kỳ phần mềm nào, nhưng các quy tắc này là nguồn yêu cầu chức năng chính của phần mềm vì nó đưa ra các khả năng mà hệ thống phải có để phù hợp với các quy luật.

U H

• Ví dụ: trong hệ thống Chemical Tracking cần phát ra các báo cáo phù hợp vơi các quy định của liên bang về việc lưu trữ hóa chất.

I

70

̣ - T T N C a o h K - T T T H n ô M ô B

́

ầ

̣ ̣

ứ

U H

I

Quy tă c nghiêp vu và yêu c u  ch c năng • Không phải mọi công ty đều xem các quy tắc nghiệp vụ như tài sản có giá trị. Có thể các thông tin này không được ghi chép và quản lý, mà chỉ tồn tại trong đầu các cá nhân.

• Các cá nhân khác nhau có thể hiểu khác nhau về các quy tắc, dẫn đến các phần mềm tuân theo các quy tắc nghiệp vụ chung sẽ không thống nhất (inconsistent).

- T T N C a o h K

71

̣ - T T T H n ô M ô B

́

̣ ̣ ̣

phân loai quy tă c nghiêp vu

U H

I

72

̣ - T T N C a o h K - T T T H n ô M ô B

Documenting Business Rules • Quy tắc nghiệp vụ có thể ảnh hưởng đến nhiều ứng dụng,

nhiều tổ chức  các tổ chức nên quản lý các quy tắc nghiệp vụ ở mức enterprise không phải ở mức dự án.

U H

Dùng business rules catalog Nếu tổ chức lớn nên xây dựng một database of business

rules.

• Khi xác định 1 quy luật mới trong lúc làm việc với ứng dụng, hãy thêm nó vào catalog, đừng nhúng nó vào tài liệu của riêng ứng dụng hay chỉ viết code cho nó.

I

• Các quy luật liên quan đến safety, security, finance , có thể

dẫn đến các rủi ro cao nhất nều quản lý không đúng.

73

̣ - T T N C a o h K - T T T H n ô M ô B

́

̣

Vi  du: Business rule catalog

U H

I

- T T N C a o h K

74

̣ - T T T H n ô M ô B

U H

I

75

̣ - T T N C a o h K - T T T H n ô M ô B

U H

• Sau khi nhận dạng và xác định các quy tắc nghiệp vụ, nên xác định xem quy tắc nào cần thực thi trong phần mềm. Một số quy tắc sẽ làm phát sinh các use case, vì vậy sẽ ảnh hưởng đến yêu cầu chức năng của use case đó.

I

76

̣ - T T N C a o h K - T T T H n ô M ô B

̣

Vi  dú

U H

I

Rule #1 (action enabler) "If the expiration date for a chemical container has been reached, then notify the person who currently possesses that container." Rule #2 (inference) "A container of a

- T T N C a o h K

chemical that can form explosive decomposition products is considered expired one year after its manufacture date."

Rule #3 (fact) "Ethers can spontaneously

77

form explosive peroxides."

̣ - T T T H n ô M ô B

̣

Vi  dú

• Ba quy tắc này dẫn đến use case "Notify Chemical

U H

Owner of Expiration.“ Một yêu cầu chức năng cho use case này là "The system shall e-mail a notification to the current owner of a chemical container on the date the container expires."

I

78

̣ - T T N C a o h K - T T T H n ô M ô B

́

̀

́

ư

̀  Quy tă c nghiêp vu va  yêu câ u ch c năng

̣ ̣

U H

• Đôi khi các quy tắc nghiệp vụ và yêu cầu chức năng tương ứng rất giống nhau. Tuy nhiên các quy tắc là những phát biểu bên ngoài cần phải đưa vào phần mềm thành các chức năng hệ thống.

• Mỗi nhà phân tích phải quyết định quy tắc nào phù hợp với ứng dụng, cái nào nên đưa vào phần mềm, và đưa vào như thế nào.

I

79

̣ - T T N C a o h K - T T T H n ô M ô B

̣

Vi  dú

U H

• Xét hệ thống Chemical Tracking, có 1 constraint rule yêu cầu người dùng có hồ sơ đào tạo (training record) rồi mới có quyền yêu cầu hóa chất độc hại (hazardous chemical).

• Nhà phân tích có thể suy diễn quy tắc này thành các yêu cầu chức năng khác nhau tùy thuộc vào điều kiện CSDL về hồ sơ đào tạo có trực tuyến hay không?

I

80

̣ - T T N C a o h K - T T T H n ô M ô B

̣

Vi  dú

U H

• Nếu có, hệ thống chỉ đơn giản tìm kiếm hồ sơ đào tạo và quyết định chấp nhận hay từ chối yêu cầu.

• Nếu không, hệ thống có thề lưu trữ tạm thời

I

yêu cầu này và gửi email đến training coordinator, người này có thể phê duyệt hay từ chối yêu cầu.

81

 Cùng 1 quy tắc nghiệp vụ cho cả 2 yêu cầu chức năng – các yêu cầu chức năng thay đổi tùy theo môi trường hệ thống.

̣ - T T N C a o h K - T T T H n ô M ô B

Mô Hình Hóa Yêu C uầ

• Các kỹ thuật mô hình hóa

U H

• Data Flow Diagram (DFD) • State Transition Diagram (STD) • Prototype

I

82

̣ - T T N C a o h K - T T T H n ô M ô B

ả

requirement

U H

I

Cách mô t • Cần kết hợp việc trình bày Requirement bằng nhiều cách khác nhau vừa bằng text vừa bằng hình ảnh để có 1 bức tranh tổng thể hơn về hệ thống cần xây dựng

• Các cách diễn tả requirement

- T T N C a o h K

• Functional requirements lists and tables • Graphical analysis models • User interface prototypes • Test case • Decision trees, and decision tables

83

̣ - T T T H n ô M ô B

ả

Mô t

requirement

• Mỗi người sẽ mô tả requirement theo những cách

U H

khác nhau: • Nhà phân tích (Analyst) viết yêu cầu và vẽ mô hình • Nhà thiết kế giao diện (user interface designer) xây dựng

I

các prototype và viết các test cases

- T T N C a o h K

• Khi so sánh các cách biểu diễn yêu cầu của nhóm người khác nhau sẽ giúp phát hiện ra được sự không nhất quán, chưa rõ ràng, hay thiếu sót của các yêu cầu

84

̣ - T T T H n ô M ô B

Mô hình hóa yêu c uầ

U H

• Dùng hình ảnh để diễn đạt yêu cầu giúp dễ dàng giao tiếp hơn giữa stakeholder và nhà phát triển, giữa các thành viên của đội…

• Các kỹ thuật mô hình hóa yêu cầu:

I

- T T N C a o h K

• Data flow diagrams (DFD) • Entity – relationship diagrams (ERD) • State – transition diagrams (STD) or statecharts • Use case diagrams, activity diagrams

85

̣ - T T T H n ô M ô B

U H

I

From Voice of the Customer to  Analysis Models • Chú ý cách khách hàng trình bày yêu cầu của họ, nhà phân tích có thể rút ra được các keyword và chuyển nó thành các thành phần trong mô hình.

- T T N C a o h K

86

̣ - T T T H n ô M ô B

From Voice of the Customer to  Analysis Models

U H

I

- T T N C a o h K

87

̣ - T T T H n ô M ô B

ầ ủ

ườ

Case study: yêu c u c a nhóm  ng

i dùng chemist

U H

I

- T T N C a o h K

88

̣ - T T T H n ô M ô B

Data Flow Diagram (DFD)

U H

I

• DFD xác định quá trình biến đổi của hệ thống, tập hợp dữ liệu và dòng dữ liệu giữa các xử lý (processes), kho (stores) và thế giới bên ngoài.

- T T N C a o h K

• Mô hình Data flow dùng phương pháp phân rã chức năng (functional decomposition) để phân tích hệ thống phù hợp cho các hệ thống xử lý giao dịch (transaction-processing system) và các ứng dụng nhiều chức năng.

89

̣ - T T T H n ô M ô B

Data Flow Diagram (DFD)

U H

• DFD minh họa các yêu cầu chức năng trong SRS kết hợp với nhau như thế nào để thực hiện nhiệm vụ của người dùng.

I

• DFD cung cấp cách biểu diễn từng bước

của một qui trình nghiệp vụ.

- T T N C a o h K

• Có thể dùng DFD để phỏng vấn khách

hàng

90

̣ - T T T H n ô M ô B

ượ ồ ữ ả

L

c đ  ng  c nh

U H

I

- T T N C a o h K

91

̣ - T T T H n ô M ô B

Data Flow Diagram (DFD)

U H

• Từ lược đồ ngữ cảnh phát triển thành lược đồ DFD mức 0, chia hệ thống thành các process chính.

I

- T T N C a o h K

• Tất cả dòng dữ liệu từ lược đồ ngữ cảnh phải xuất hiện đủ trong lược đồ DFD mức 0. • Trong lược đồ DFD mức 0 bắt đầu xuất hiện

các kho dữ liệu (data stores)

92

̣ - T T T H n ô M ô B

Data Flow Diagram (DFD)

Lược đồ DFD mức 0

U H

I

- T T N C a o h K

93

̣ - T T T H n ô M ô B

ấ ứ DFD m c th p

U H

• Từ DFD mức 0, nhà phân tích tiếp tục tinh chỉnh thành các DFD mức thấp hơn cho đến khi tiến tới DFD mức thấp nhất chỉ còn 1 process cơ bản (primitive process).

I

- T T N C a o h K

94

• Các yêu cầu chức năng trong SRS định nghĩa chính xác từng process cơ bản này. • Lưu ý: mỗi mức DFD phải cân bằng và thống nhất với mức trên của nó sao cho tất cả dòng vào và ra của lược đồ con phải khớp với số dòng vào và ra của lược đồ cha.

̣ - T T T H n ô M ô B

ấ ứ DFD m c th p

U H

I

95

̣ - T T N C a o h K - T T T H n ô M ô B

State – Transition Diagram (STD)

U H

• Hệ thống Real-Time và các ứng dụng quản lý đều có thể tồn tại 1 số giới hạn các trạng thái (states) tại mỗi thời điểm.

I

- T T N C a o h K

• Việc thay đổi trạng thái xảy ra khi thỏa mãn 1 tiêu chuẩn nào đó, như nhận 1 tác nhân từ bên ngoài trong một điều kiện nào đó

• Các phần tử hệ thống liên quan đến tập các trạng thái và các thay đổi giữa chúng được xem như là fifite-state machines

96

̣ - T T T H n ô M ô B

State – Transition Diagram (STD)

• Lược đồ STD là 1 loại lược đồ UML, có 3

U H

thành phần chính sau:

• Trạng thái hệ thống (system state): ký hiệu

I

hình chữ nhật.

• Các chuyển đổi trạng thái được phép: ký

- T T N C a o h K

hiệu mũi tên nối các cặp hình chữ nhật.

• Các sự kiện (event) hay điều kiện (condition) gây ra việc đổi trạng thái, được ký hiệu như 1 nhãn trên các đường mũi tên.

97

̣ - T T T H n ô M ô B

State – Transition Diagram (STD)

U H

I

- T T N C a o h K

98

̣ - T T T H n ô M ô B

State – Transition Diagram (STD)

U H

• STD không chỉ ra chi tiết hệ thống cần xử lý mà chỉ đưa ra những thay đổi có thể có được sau khi xử lý.

I

- T T N C a o h K

• STD giúp developers hiểu được các hành vi của hệ thống, có thể kiểm tra tất cả các trạng thái và chuyện đổi có mô tả đúng và chính xác trong yêu cầu chức năng hay không?

99

• Tester có thể suy diễn các test cases từ STD sao cho có thể bao được tất cả các hướng chuyển đổi (transtition path)

• Customer có thể đọc và hiểu được STD dễ

dàng vì ký hiệu đơn giản

̣ - T T T H n ô M ô B

State – Transition Diagram (STD)

U H

I

- T T N C a o h K

100

̣ - T T T H n ô M ô B

Prototype

• Phương pháp SW prototyping làm cho yêu

U H

cầu thực hơn, giúp hiểu rõ yêu cầu hơn

I

- T T N C a o h K

• Bản thiết kế ban đầu mô tả suy nghĩ người dùng và được người dùng xem xét phản hồi (feedback) lại giúp cho các stakeholders tiến đến có cùng hiểu biết chung về yêu cầu.

101

̣ - T T T H n ô M ô B

Prototyping: What and why

U H

• Clarify and complete the requirements • Explore design alternatives. • Grow into the ultimate product.

I

102

̣ - T T N C a o h K - T T T H n ô M ô B

Prototyping: What and why

U H

• Lý do chính tạo prototype là để giải quyết sớm tình trạng không rõ ràng trong quá trình phát triển phần mềm.

I

- T T N C a o h K

• Từ tình trạng không rõ ràng (uncertainties) nên quyết định phần nào của hệ thống làm prototype và cái gì sẽ học hỏi được từ việc đánh giá prototype.

103

̣ - T T T H n ô M ô B

Qui trình làm Prototyping

U H

I

• Bước 1: xác định các yêu cầu cơ bản bao gồm các thông tin chủ yếu về input, output, bỏ qua các chi tiết như bảo mật, tốc độ thực thi,…

• Bước 2: phát triển Prototype đầu tiên chỉ

- T T N C a o h K

bao gồm các giao diện người dùng.

• Bước 3: Xét duyệt (Review) bởi người dùng

cuối để nhận các phản hồi (feedback)

• Bước 4: Chỉnh sửa và mở rộng Prototype.

104

Nêú có thay đổi sẽ lặp lại bước 3 và 4

̣ - T T T H n ô M ô B

ạ

Phân lo i Prototyping

U H

I

- T T N C a o h K

• Throwaway • Evolutionary • Paper & Electronic • Vertical & Horizontal • Extreme • Incremental

105

̣ - T T T H n ô M ô B

Horizontal Prototype • Còn được gọi là behavioral prototype hay mock –

up.

U H

• Được gọi là horizontal vì nó không đi sâu vào tất cả layer của kiến trúc mà chỉ mô tả cơ bản giao diện người dùng

I

• Horizontal prototype chỉ ngầm chứa chức năng mà

không thực sự thực thi.

- T T N C a o h K

106

̣ - T T T H n ô M ô B

ụ

ủ M c đích c a Horizontal  Prototype • Xác nhận các yêu cầu về giao diện người dùng và

phạm vi hệ thống

U H

• Phiên bản thuyết minh của hệ thống để được chấp

nhận mua từ đối tác

I

• Phát triển các đánh giá sơ bộ về thời gian, chi phí

và nhân sự.

- T T N C a o h K

107

̣ - T T T H n ô M ô B

Vertical Prototype

• Còn được gọi là structure prototype hay proof of

concept

U H

I

• Nó thực thi 1 phần chức năng của ứng dụng từ giao diện người dùng thông qua các lớp dịch vụ kỹ thuật. Nó làm việc như 1 hệ thống thực sự vì tiếp xúc vào tất cả các mức độ của việc thực thi hệ thống.

- T T N C a o h K

108

̣ - T T T H n ô M ô B

Khi nào dùng Vertical  Prototype • Muốn kiểm tra phương pháp kiến trúc được đề nghị

U H

có khả thi và đúng đắn hay không?

• Tối ưu hóa các thuật toán, đánh giá các lược đồ cơ

sở dữ liệu dự định.

I

• Kiểm tra những yêu cầu quan trọng.

- T T N C a o h K

109

̣ - T T T H n ô M ô B

Throwaway Prototypes

U H

• Còn được gọi là exploratory protype để trả lời câu hỏi, giải quyết sự không chắc chắn, và nâng cao yêu cầu chất lượng.

• Được loại bỏ sau khi kết thúc và không dùng lại

I

trong các phiên bản sau.

- T T N C a o h K

• Sau khi thu thập yêu cầu sơ bộ, throwaway prototype được xây dựng để chi cho người dùng các yêu cầu của họ sẽ như thế nào khi chúng được thực thi trong hệ thống.

110

̣ - T T T H n ô M ô B

Throwaway Prototypes

U H

• Vì Throwaway Prototype được làm rất nhanh. Người dùng có thể nhanh chóng phản hồi và làm rõ hơn yêu cầu của họ.

I

• Các thay đổi được thực hiện sớm trong chu kỳ SDLC sẽ làm giảm chi phí đáng kể và không phải reword trong các giai đoạn sau.

- T T N C a o h K

111

̣ - T T T H n ô M ô B

Evolutionary Prototypes

• Trái

U H

với Throwaway Prototype, evolutionary prototype cung cấp nền tảng cấu trúc vững chắc để xây dựng sản phẩm tăng, tiến dần khi yêu cầu nên rõ ràng hơn theo thời gian.

• Evolution prototype là 1 thành phần của mô hình phát triển phần mềm dạng xoắn ốc và chu trình phát triển phần mềm hướng đối tượng.

I

112

̣ - T T N C a o h K - T T T H n ô M ô B

Evolutionary Prototypes

U H

• Evolutionary prototype phải được xây dựng có cả mã chương trình ngay từ đầu, mất nhiều thời gian hơn là throwaway prototype khi cả hai mô phỏng cùng một chức năng hệ thống

I

• Evolution prototype phải được thiết kế sao cho phát triển và mở rộng sau này, vì vậy developers phải chú ý đến kiến trúc SW

- T T N C a o h K

113

̣ - T T T H n ô M ô B

Evolutionary Prototypes

U H

I

114

̣ - T T N C a o h K - T T T H n ô M ô B

So sánh các Prototypes

U H

I

- T T N C a o h K

115

̣ - T T T H n ô M ô B

Paper Prototypes

• Paper prototype là cách đơn giản, nhanh, rẻ và kỹ

thuật thấp

U H

• Thường được dùng cho các vòng lặp đầu tiên của

quá trình thiết kế, phác họa bằng tay trên giấy.

• Designer phác thảo ý tưởng ra giấy không bận tâm đến việc các control sẽ xuất hiện chính xác ở đâu và trông như thế nào.

I

116

• A preson plays the role of the computer while a user walks through an evaluation scenario. The user can judge whether that is indeed the expected response and whether the item displayed contains the correct elements

̣ - T T N C a o h K - T T T H n ô M ô B

Electronic Prototypes

• Có nhiều công cụ thích hợp cho việc xây dựng

election throwaway prototype:

U H

• Programming language such as: MS Visual Basic,

IBM VisualAge Smaltalk, and Inprise Delphi • Scripting language as Perl, Python, and Rexx • Commercial prototyping tool kits, screen painters,

and graphical user interface builders

I

• Drawing tools such as microsoft Visio and Microsoft

PowerPoint

117

̣ - T T N C a o h K - T T T H n ô M ô B

Đánh giá Prototypes

U H

• Để đánh giá hiệu quả horizontal prototypes nên tạo kịch bản (script) trước để hướng dẫn người dùng thực hiện tuần tự các bước và đặt các câu hỏi thu thập thông tin như:

I

• Does the prototype implement the functionality in the way

you expected?

- T T N C a o h K

• Is any functionality missing? • Can you thing of any error condition that the prototype

doesn’t address?

• Are any unnecessary functions present? • How logical and complete does the navigation seem to

118

you?

• Were any tasks overly complex?

̣ - T T T H n ô M ô B

Đánh giá Prototypes

U H

• Phải đảm bảo chọn đúng người đánh giá, nên bao gồm các đại diện người dùng thành thạo cũng như ít kinh nghiệm.

I

- T T N C a o h K

• Quan sát người dùng lúc họ làm việc với prototype tốt hơn là chỉ đơn giản hỏi họ nghĩ gì về prototype. Có thể phát hiện được nhiều điều từ sự quan sát này.

119

̣ - T T T H n ô M ô B

Đánh giá Prototypes

U H

• Yêu cầu người đánh giá chia sẻ suy nghĩ của họ khi làm việc với prototype, có thể phát hiện các yêu cầu còn thiếu. Nên tạo môi trường thân thiện để người đánh giá tự do trình bày ý kiến của họ. • Lưu trữ lại kết quả đánh giá prototype • Với horizontal prototype: dùng thông tin này để điều

chỉnh lại yêu cầu trong SRS

I

• Với verticak prototype: nên xem xét các mâu thuẫn

giữa SRS và prototype.

120

̣ - T T N C a o h K - T T T H n ô M ô B

ủ

ươ

ng pháp

U H

I

ủ Các r i ro c a ph Prototyping • The biggest risk is that a stateholder will see a running prototype and conclude that the product is nearly completed

- T T N C a o h K

• Đùng ngại việc phải giao sản phẩm “chưa hoàn chỉnh” mà bỏ qua việc tạo prototype. Phải xác định rõ với ai xem prototype là nó không phải là sản phẩm cuối.

121

̣ - T T T H n ô M ô B

ủ

ươ

ng pháp

U H

I

- T T N C a o h K

ủ Các r i ro c a ph Prototyping • Cách khắc phục: • Dùng paper prototype • DÙng 1 công cụ prototype khác hẳn với công cụ sẽ được dùng để phát triển phần mềm, tránh được áp lực của người đánh giá”kết thúc sớm và bàn giao” • Để prototype trông có vẻ như bản nháp, không cần

trau chuốt

122

̣ - T T T H n ô M ô B

ủ

ươ

ng pháp

U H

I

ủ Các r i ro c a ph Prototyping • Người dùng quá chú trọng đến hình thức, giao diện như thế nào và hoạt động ra sao, quên tập trung vào yêu cầu hệ thống.

• Người dùng sẽ nghĩ việc thực thi của sản phẩm cuối

sẽ giống như việc thực thi của prototype.

- T T N C a o h K

• Ví dụ: nếu người dùng thấy prototype đáp ứng tức thì khi truy vấn 1 DB mô phỏng, họ có thể nghĩ thực thi trong sản phẩm phần mềm cũng nhanh tương tự như với 1 CSDL phân tán cực lớn

123

̣ - T T T H n ô M ô B

ủ

ươ

ng pháp

U H

I

- T T N C a o h K

ủ Các r i ro c a ph Prototyping • Các hoạt động làm prototype có thể mất quá nhiều công sức và thời gian đội phát triển. Và khi hết thời gian, có khi họ sẽ phát hành prototype như sản phẩm cuối, hoặc vội vã đưa ra 1 sản phẩm không như dự định. Do just enough prototype to test the hypothesis, answer the questions, and refine your understending of the requirements

124

̣ - T T T H n ô M ô B

Prototyping Success Factors

U H

• Nên đưa nhiệm vụ prototyping vào kế hoạch, lập lịch biểu và tài nguyên để phát triển, đánh giá và chỉnh sửa prototype.

• Xác định mục đích của mỗi prototype trước khi bắt

I

đầu

• Nên lập kế hoạch cho nhiều prototype. Hiếm khi có

kết quả ngay trong lần thử đầu tiên

- T T N C a o h K

• Tạo throwaway prototypes thật nhanh và rẻ nhất • Không nên đưa việc kiểm tra dữ liệu đầu vào, quản

lý lỗi, mã hóa dữ liệu…vào throwaway prototype

125

̣ - T T T H n ô M ô B

Prototyping Success Factors

U H

• Sử dụng dữ liệu hợp lý trong prototype screen display and reports. Người đánh giá không còn chú ý đến dữ liệu và tập trung hơn vào việc xem xét hoạt động của hệ thống

I

- T T N C a o h K

• Đừng mong đợi prototype có thể thay thế hoàn toàn SRS. Những chức năng thu thập được từ prototype nên ghi chép lại trong SRS. Các màn hình không thể đưa ra định nghĩa chi tiết về dữ liệu và tiêu chuẩn đánh giá, mối quan hệ giữa các dữ liệu,…

126

̣ - T T T H n ô M ô B