Ch ng 4ươ

Phân tich yêu c uâ

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

-

HU

I

1

N i dungô• 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 con 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 ky thuât mô hình hoa• Mô hình hoa muc tiêu (Goal modelling)• Mô hình hoa phân tích (analysis modelling)• Tài liệu đặc tả yêu cầu phần mềm SRS

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

-

HU

I

2

Đ nh nghĩa phân tich yêu c uị â

• 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ử dung, phân tích công việc.

• Việc này co thể liên quan với việc tạo môt hay

nhiều mô hình khác nhau. No giúp các phân

tích viên hiểu biêt hệ thống.

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

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

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

3

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

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

4

HƯỚNG DẪN SUY LUẬN YÊU CẦU (REQUIREMENTS ELICITATION GUIDELINES)

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ùng6.Ứng dung các ky 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 đo cho từng phần của hệ thống

BM

HT

TT

Kh

oa

CN

TT

- H

UI

5

HƯỚNG DẪN SUY LUẬN YÊU CẦU(REQUIREMENTS ELICITATION GUIDELINES)

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

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

HƯỚNG DẪN SUY LUẬN YÊU CẦU (REQUIREMENTS ELICITATION GUIDELINES)

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 ky

12.Phát triển các test cases dưới dạng ý tưởng từ các use cases

13.Sử dung 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

BM

HT

TT

Kh

oa

CN

TT

- H

UI

7

Nhi m v c a phân tich yêu c uệ ụ ủ â

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

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

8

Nhi m v c a phân tich 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:

•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 co:

•Chi phí:

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

thiêt bị, quản lý và phuc vu,…

• Chi phí cho khởi công: phần mềm phuc vu 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,

…

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

9

Nhi m v c a phân tich yêu c uệ ụ ủ â• Chi phí:

• Chi phí liên quan: chi phí nhân công phuc vu thu nhâp dữ liệu, sửa đổi, câp

nhâp hệ thống, chuẩn bị tài liệu,…

• 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í phuc vu cho vân hành,…

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 hoa, bảo đảm an toàn và an ninh dữ 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

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

10

Nhi m v c a phân tich yêu c uệ ụ ủ â

• Khả thi về ky thuât:• 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 co tương đương hay không?

• Có sẵn tài nguyên: co 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 đã co sẵn hay chưa?

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

11

Nhi m v c a phân tich yêu c uệ ụ ủ â

• Khả thi về hợp pháp:• Co sự xâm phạm, vi phạm hay kho 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

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

12

M t s l i khi thu th p yêu ô ố ô âc uâ• 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 kho khăn nêu không co 1 sơ đồ co cấu trúc như use case.

• 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 co 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• 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 champion, họ đại diện cho các loại người dùng.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

13

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

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

• Nếu quá nho: khách hàng co thể co 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 chinh sửa lại product vision hay project scope.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

14

Phát hi n các yêu c u con ệ âthi uê• 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. • 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 co ít nhất 1 actor.

• 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 con thiêu đang được xác định

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

15

Phát hi n các yêu c u con ệ âthi uêVí du: Giả sử co 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 hoa đơn co 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 con thiêu

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

16

Finding Missing Requirements• Biểu diên thông tin của mọ�i yêu cầu theo

nhiều cách. • 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 đủ.

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

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

17

Ma tr n CRUDâ

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

Delete. • 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, xoa ở đâu và như thê nào.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

18

Ma tr n CRUDL cho h th ng â ệ ốtheo doi hóa ch tâ

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

-

HU

I

19

CRUDL (Create, Read, Update, Delete, List)Co thể rút ra các suy luân gì từ ma trân trên khi noi đên thực thể Requester ???

Vi d ma tr n CRUDLụ â

• Sau khi tạo ma trân CRUDL, cần kiểm tra xem: • Co ký tự nào trong 5 ký tự CRUDL không

xuất hiện trong 1 côt nào đo không? • Ví du: môt côt không co 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?

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

20

Vi d ma tr n CRUDLụ â• Côt Requester không chứa D, không co use

case nào co thể xoa Requester. Ba khả năng xảy ra:

1. Deleting a Requester is not an expected function of the Chemical Tracking System.

2. We are missing a use case that deletes a Requester.

3. The "Edit Requesters" use case is incorrect.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

-

HU

I

21

Khi nao thì k t thuc 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.

• Nêu người dùng đề nghị các use case mới nhưng thực tê chúng co 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 đo.

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

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

-

HU

I

22

Khi nao thì k t thuc vi c thu th p yêu ê ệ âc u?â Nêu các yêu cầu mới được đề nghị co đô ưu tiên

thấp.

Nêu người dùng đưa ra các khả năng co thể đôi khi xuất hiện trong sản phẩm.

Tạo môt checklist của các miền chức năng chung. Ví du checklist bao gồm error logging, backup and restore, access security, reporting, printing, preview capabilities, and configuring user preferences. So sánh định ky 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 co nghĩa là chúng ta đã phân tích xong.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

23

Requirements Elicitation Methods

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

-

HU

I

24

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. • 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 cum từ, e.g., 1 co nghĩa là quan trọng nhất và 5 là ít quan trọng nhất.

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

ô M

ôn

HT

TT

- K

ho

a C

NT

T -

HU

I

25

Prioritization and Ranking of Requirements

• Khi cần phai quyêt định tính năng cần co trong san phâm sẽ phát hành, thì nên dùng kỹ thu t âranking, trong khi đo kỹ thu t prioritization hầu ânhư đươc dùng khi xác định phạm vi ban đầu của h thống. ê

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

26

Prioritization and Ranking of Requirements

• Khi phân phối bang câu hoi (questionnaires ) hay phiêu điêu tra (survey) cho khách hàng thường luôn co câu hoi là nên chọn đ ưu tiên nào cho 1 ôtính năng nào đ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 xay ra khi đê khách 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. ô

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

27

Các ky thu t Prioritizationâ

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

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

28

“Analytic Hierarchy Process” (AHP)(hay pairwise ranking)• Đê xêp loại yêu cầu, Stakeholder hay analyst tim 2

yêu cầu, so sánh chung và đánh giá chung đê tim 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 ca yêu cầu đươc xêp loại.

• Phương pháp này chi thich hơp cho nhưng t p hơp âyêu cầu không quá lơn.

• Vì các stakeholder khác nhau co 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 san phâm.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

29

“Planning game” (PG)

• Các yêu cầu của stakeholder, các tính năng hay yêu cầu của san 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.”

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

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

30

Đ c tinh c a rankingă ủ

• Vi c xêp loại đánh giá phai dựa vào thực tê, e.g., chi êphi và rủi ro luôn co liên quan vơi nhau.

• M t số ngành công nghi p, co 1 số yêu tố như mối ô ênguy hiêm cho người dùng và công ngh mơi cần êphai đươc khao sát cùng nhau.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

31

Đ c tinh c a rankingă ủ

• Vi du: kỹ thu t mơi cho vi c đong mơ cưa sổ của xe â êhơi dùng cam biên ánh sáng thay vì dùng công tăc v t ly như trươc đây co chi phi 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 bao đam an toàn, co thê làm cho tre con bị thương khi cưa sổ đ t ng t mơ ra, do đo kỹ thu t này đa không đươc ô ô âđưa vào mô hình xe hơi trong năm kê tiêp.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

32

Prioritization and ranking

• 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 ky phát triên san phâm.

• Ranking: Vi c xêp loại đánh giá đươc thực hi n ngay ê êkhi các yêu cầu đa thu th p khá đủ như vê chi phi, âtài nguyên …

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

33

Quality Function Deployment (QFD) Method• Muc đich: Đê tích hơp các nhu cầu của người dùng vào thiêt

kê san phâm.• Trình tự thực hi n:ê

1. Tìm ra nhu cầu khách hàng từ nhưng người dù noi ra hay không noi ra, từ nhưng lời noi 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 chân ê ăkhách hàng.

3. Chuyên các đ c tính này thành các đ c tính thiêt kê và ă ăhành đ ng co thê chuyên giao. ô

4. Xây dựng và phân phối san phâm/dịch vu co chât lương băng cách t p trung vào các chưc năng nghi p vu â êhương tơi muc tiêu chung – thoa man khách hàng.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

34

• Six Sigma là gì?• Assignment 17??

• QFD is often part of a Six Sigma program

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

35

Quality Function Deployment (QFD) Method

Process Modeling Technique

• Kỹ thu t mô hình hoa quy trình (model driven) phù âhơp cho ca elicitation và analysis. • Data flow diagrams (DFDs) • Use case analysis (use case = business process)

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

36

Data flow diagrams (DFDs)

• Đươc sư dung trong 1 thời gian dài• T p trung vào dong dư li u và câu truc dư li u hơn â ê ê

là vào dịch vu (services).

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

37

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

-

HU

I

38

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

391.2

User account management

D1 User account infoUser infoentry

1.5

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

D6 Chi tiết mượn / trả sáchD5 Thông tin độc giả

Thông tin NV

1.3

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

1.4

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

D3 Thông tin Sách

SáchThôngtin Sách

Thông tinĐộc giả

Nhập sách mượn

1.6

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

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

1.1

Login

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

Độc giả

Nhân viênthư viện

NhậpUser id, password

NhậpUser id, password

Nhập User id, password Người quản lý

D4 Thông tin tài khoản

D2 Thông tin Sách

Nhà cung cấp

1.2

User account management

1.2

User account management

D1 User account infoUser infoentry

1.5

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

1.5

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

D6 Chi tiết mượn / trả sáchD5 Thông tin độc giả

Thông tin NV

1.3

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

1.3

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

1.4

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

1.4

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

D3 Thông tin Sách

SáchThôngtin Sách

Thông tinĐộc giả

Nhập sách mượn

1.6

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

1.6

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

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

1.1

Login

1.1

Login

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

Độc giả

Nhân viênthư viện

NhậpUser id, password

NhậpUser id, password

Nhập User id, password Người quản lý

D4 Thông tin tài khoản

D2 Thông tin Sách

Nhà cung cấp

Use case analysis

• Dùng đê chi ra quy trình nghi p vu và mối quan êh giưa h thống và thê giơi bên ngoài.ê ê

• Co thê dùng ngôn ngư tự nhiên hay bang biêu đê mô ta use case.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

40

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 vu (tasks) cho ai đo.

• Môt actor là môt người, môt ứng dung phần mềm khác, môt thiêt bị phần cứng, môt thực thể khác nào đo tương tác với hệ thống để đạt được môt muc đích nào đo. Con đươc gọi là user role.

• 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 co 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 co thể đong vai tro Requester.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

41

USE CASES VÀ K CH B N S D NG Ị Ả Ử Ụ(USE CASES AND USAGE SCENARIOS)• Một use case co thê bao hàm một số các tác vu (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 vu 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 thao 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 hoi người dùng muốn h thống làm cái gì.ê

• Muc tiêu của phương pháp use case là mô ta tât ca các nhi m vu mà người dùng sẽ cần thực thi vơi h thống. ê ê

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

42

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 ban (scenario) ô â

thông thường co 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, no 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.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

43

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

44

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

45

Use case c a h th ng theo doi hóa ủ ệ ốch tâ

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

46

Mô t Use case “request a chemical”a

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

47

Mô t Use case “request a chemical”a

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

48

Use case va yêu c u ch c â ứnăng• Không phai yêu cầu chưc năng nào cũng đươc đưa

vào UseCase• Khi đặc ta 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 ta yêu cầu (SRS) đa

bao gồm các yêu cầu chưc năng đươc mô ta trong các UC chưa

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

49

Use case va 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). • Các tiên trình thay thê cũng nhằm hoàn thành

tác vu (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.

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

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

50

Use case va yêu c u ch c â ứnăng

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

51

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 vu (task – centric).

• Giup phân loại các ý tưởng cần phải làm đối với mỗi khách hàng.

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

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

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

52

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 ban. Thay vì vậy, hay 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.

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

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

53

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). Hay 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 (Attempting to associate every requirement with a use case).

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

54

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

• 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 ich của use case• M t số trường hơp cần tránh khi dùng use caseô

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

55

Event-Response Tables

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

Event là 1 số thay đổi hay hoạt đ ng xay ra trong ômôi trường người dùng đê kich khơi m t đáp ôưng (response) từ h thống phần mêm. ê

Bang event-response (con đươc gọi là event table hay event list) li t kê tât ca các event và êhành vi mà h thống đáp ưng lại ưng vơi mỗi sự êki n.ê

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

56

Vi d các lo i s ki n ụ a ư ệva đáp ng h th ngứ ệ ố

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

57

Các lo i s ki n h th nga ư ệ ệ ố

• 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. ô

• Bang event-response không mô ta muc tiêu người dùng khi sư dung 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. B

ô M

ôn

HT

TT

- K

ho

a C

NT

T -

HU

I

58

Các lo i s ki n h th nga ư ệ ệ ố

• Hành đ ng của con ngườiô• Tin hi u điêu khiên hay ngăt từ thiêt bị phần cưng bên ê

ngoài• Sự ki n kich khơi bơi đồng hồ máy tínhê

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

59

Quy t c nghi p v do khách hang xác đ nhă ệ ụ ị Customer-Specific Business Rules

• Business rules là loại đ c bi t của yêu cầu khách hàng.ă ê• Khác vơi các nhu cầu cố định của khách hàng, các quy tăc

nghi p vu dùng đê:ê• mô ta vi c thực thi chinh sách của khách hàng ê• co thê bị thay đổi bơi chinh khách hàng sau khi san

phâm đươc phân phối.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

60

Quy t c nghi p v va chinh sáchă ệ ụ

• M t tổ chưc co thê ban hành, chinh sưa hay hủy bo các ôquy tăc nghi p vu ê mà các quy tăc này sẽ chi phối và hương dẫn tổ chưc.

• Chinh sách (business policy) là yêu tố quan ly, không trực tiêp đươc thi hành mà dùng đê hương dẫn tổ chưc hoạt đ ng. Chinh sách không đoi hoi phai diên ta co câu truc ô(không cần thu t ngư tiêu chuân) như là quy tăc nghi p â êvu. B

ô M

ôn

HT

TT

- K

ho

a C

NT

T -

HU

I

61

Vi dụ• “Bank customers should not be able to make too 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.”

Đây là chinh sách hay quy tăc nghi p vu????êChinh sách

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

62

Why Are Customer-Specific Business Rules Important?• Các quy tăc nghi p vu do người dùng xác định phai tách riêng ê

khoi các yêu cầu thông thường, vì chung không thực sự là yêu cầu.

• Yêu cầu khách hàng co thê đươc suy diên từ quy tăc nghi p êvu, các yêu cầu co thê khác vơi quy tăc mà chung đươc suy diên.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

63

Why Are Customer-Specific Business Rules Important?• Chinh quy tăc nghi p vu do khách hàng xác định dùng đê thực ê

thi chinh sách (policy) của công ty, nhưng quy tăc nghi p vu co êthê thay đổi sau khi h thống đa đươc phân phối. ê

Nên xây dựng h thống sao cho khách hàng co kha năng thay êđổi quy lu t mà không làm cho h thống bị sưa đổi theo. â ê

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

64

Vi dụ• Policy: The hospital shall be able to define the difference

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

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

65

Vi dụRule: Any patient under the age of 14

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.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

66

Vi dụ• Requirement: A facility shall be provided with the 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.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

67

M i quan h gi a policy va business ố ệ ưrule

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

-

HU

I

68

Quy t c nghi p vă ệ ụ• Mỗi tổ chưc nghi p vu đêu phai tuân theo 1 t p các chinh ê â

sách, lu t và tiêu chuân (đươc gọi là â business rule). Phần mềm ưng dung bu c phai tuân theo các quy tắc nghi p vu này. ô êTrong m t số trương hơp, các quy tắc nghi p vu 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 phai tuân theo các chinh sách và thu tuc.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

-

HU

I

69

Quy t c nghi p vă ệ ụ• Hầu hêt các quy tăc nghi p vu đêu xuât phát từ bên ngoài ngư ê

canh của bât ky 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 chinh của phần mêm vì no đưa ra các kha năng mà h thống phai co đê phù hơp vơi các quy êlu t. â

• Vi du: 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ư êhoa chât.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

-

HU

I

70

Quy t c nghi p v va yêu c u ă ệ ụ âch c năngứ• Không phai mọi công ty đêu xem các quy tăc nghi p vu như ê

tài san co giá trị. Co thê các thông tin này không đươc ghi chép và quan ly, mà chi tồn tại trong đầu các cá nhân.

• Các cá nhân khác nhau co 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 vu chung êsẽ không thống nhât (inconsistent).

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

71

phân lo i quy t c nghi p va ă ệ ụ

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

72

Documenting Business Rules• Quy tăc nghi p vu co thê anh hương đên nhiêu ưng dung, nhiêu tổ ê

chưc các tổ chưc nên quan ly các quy tăc nghi p vu ơ mưc êenterprise không phai ơ mưc dự án.

Dùng business rules catalogNê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 luc làm vi c vơi ưng dung, hay â ê

thêm no vào catalog, đừng nhung no vào tài li u của riêng ưng êdung hay chi viêt code cho no.

• Các quy lu t liên quan đên safety, security, finance , co thê dẫn đên âcác rủi ro cao nhât nêu quan ly không đung. B

ô M

ôn

HT

TT

- K

ho

a C

NT

T -

HU

I

73

Vi d : Business rule catalog ụ

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

74

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

75

• Sau khi nh n dạng và xác định các quy tăc nghi p vu, 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ẽ anh hương âđên yêu cầu chưc năng của use case đo.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

76

Vi dụ

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 chemical that can form explosive decomposition products is considered expired one year after its manufacture date."

Rule #3 (fact) "Ethers can spontaneously form explosive peroxides."

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

77

Vi dụ• Ba quy tăc này dẫn đên use case "Notify Chemical 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."

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

78

Quy t c nghi p v va yêu c u ch c năngă ệ ụ â ứ

• Đôi khi các quy tăc nghi p vu 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 phai đư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 phai quyêt định quy tăc nào phù hơp vơi ưng dung, cái nào nên đưa vào phần mêm, và đưa vào như thê nào.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

79

Vi dụ• Xét h thống Chemical Tracking, co 1 constraint rule yêu cầu ê

người dùng co hồ sơ đào tạo (training record) rồi mơi co quyên yêu cầu hoa chât đ c hại (hazardous chemical). ô

• Nhà phân tích co 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 co trực tuyên hay không?

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

80

Vi dụ

• Nêu co, h thống chi đơn gian tim 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 co thê lưu trư tạm thời yêu êcầu này và gưi email đên training coordinator, người này co thê phê duy t hay từ chối yêu cầu. ê

Cùng 1 quy tăc nghi p vu cho ca 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. ê

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

81

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

• Các kỹ thu t mô hình hoaâ• Data Flow Diagram (DFD)• State Transition Diagram (STD)• Prototype

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

82

Cách mô t requirementa• 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 anh đê co 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 ta requirement• Functional requirements lists and tables• Graphical analysis models• User interface prototypes• Test case• Decision trees, and decision tables

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

83

Mô t requirementa

• Mỗi người sẽ mô ta requirement theo nhưng cách 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 các

prototype và viêt các test cases

• Khi so sánh các cách biêu diên yêu cầu của nhom người khác nhau sẽ giup phát hiện ra đươc sự không nhât quán, chưa rõ ràng, hay thiêu sot của các yêu cầu B

ô M

ôn

HT

TT

- K

ho

a C

NT

T -

HU

I

84

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

• Dùng hình anh đê diên đạt yêu cầu giup 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 hoa yêu cầu:• Data flow diagrams (DFD)• Entity – relationship diagrams (ERD)• State – transition diagrams (STD) or statecharts• Use case diagrams, activity diagrams

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

85

From Voice of the Customer to Analysis Models• Chu y cách khách hàng trình bày yêu cầu của họ,

nhà phân tích co thê rut ra đươc các keyword và chuyên no thành các thành phần trong mô hình.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

86

From Voice of the Customer to Analysis Models

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

87

Case study: yêu c u c a nhóm â ủng i dùng chemistườ

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

88

Data Flow Diagram (DFD)

• DFD xác định quá trình biên đổi của hệ thống, tập hơp dư liệu và dong dư liệu giưa các xư ly (processes), kho (stores) và thê giơi bên ngoài.

• Mô hình Data flow dùng phương pháp phân ra chưc năng (functional decomposition) đê phân tích hệ thống phù hơp cho các hệ thống xư ly giao dịch (transaction-processing system) và các ưng dung nhiêu chưc năng.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

89

Data Flow Diagram (DFD)

• 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 vu của người dùng.

• DFD cung câp cách biêu diên từng bươc của một qui trình nghiệp vu.

• Co thê dùng DFD đê phong vân khách hàng

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

90

L c đ ng c nhượ ồ ư a

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

91

Data Flow Diagram (DFD)

• Từ lươc đồ ngư canh phát triên thành lươc đồ DFD mưc 0, chia hệ thống thành các process chinh.

• Tât ca dong dư liệu từ lươc đồ ngư canh phai 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)

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

92

Data Flow Diagram (DFD)

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

93

Lược đồ DFD mức 0

DFD m c th pứ â

• Từ DFD mưc 0, nhà phân tích tiêp tuc tinh chinh 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 chi con 1 process cơ ban (primitive process).

• Các yêu cầu chưc năng trong SRS định nghĩa chinh xác từng process cơ ban này.

• Lưu y: mỗi mưc DFD phai cân băng và thống nhât vơi mưc trên của no sao cho tât ca dong vào và ra của lươc đồ con phai khơp vơi số dong vào và ra của lươc đồ cha.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

94

DFD m c th pứ â

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

95

State – Transition Diagram (STD)

• Hệ thống Real-Time và các ưng dung quan ly đêu co 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.

• Việc thay đổi trạng thái xay ra khi thoa man 1 tiêu chuân nào đo, như nhận 1 tác nhân từ bên ngoài trong một điêu kiện nào đ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 chung đươc xem như là fifite-state machines

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

96

State – Transition Diagram (STD)

• Lươc đồ STD là 1 loại lươc đồ UML, co 3 thành phần chinh sau:

• Trạng thái hệ thống (system state): ky hiệu hình chư nhật.

• Các chuyên đổi trạng thái đươc phép: ky 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 ky hiệu như 1 nhan trên các đường mũi tên.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

97

State – Transition Diagram (STD)

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

98

State – Transition Diagram (STD)• STD không chi ra chi tiêt hệ thống cần xư ly mà chi

đưa ra nhưng thay đổi co thê co đươc sau khi xư ly.• STD giup developers hiêu đươc các hành vi của hệ

thống, co thê kiêm tra tât ca các trạng thái và chuyện đổi co mô ta đung và chinh xác trong yêu cầu chưc năng hay không?

• Tester co thê suy diên các test cases từ STD sao cho co thê bao đươc tât ca các hương chuyên đổi (transtition path)

• Customer co thê đọc và hiêu đươc STD dê dàng vì ky hiệu đơn gian

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

99

State – Transition Diagram (STD)

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

100

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

thực hơn, giup hiêu rõ yêu cầu hơn• Ban thiêt kê ban đầu mô ta suy nghĩ người dùng

và đươc người dùng xem xét phan hồi (feedback) lại giup cho các stakeholders tiên đên co cùng hiêu biêt chung vê yêu cầu.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

101

Prototyping: What and why

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

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

102

Prototyping: What and why

• Ly do chinh tạo prototype là đê giai quyêt sơm tinh trạng không rõ ràng trong quá trình phát triên phần mêm.

• Từ tinh 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 hoi đươc từ việc đánh giá prototype. B

ô M

ôn

HT

TT

- K

ho

a C

NT

T -

HU

I

103

Qui trình lam Prototyping• Bước 1: xác định các yêu cầu cơ ban bao gồm

các thông tin chủ yêu vê input, output, bo qua các chi tiêt như bao mật, tốc độ thực thi,…

• Bước 2: phát triên Prototype đầu tiên chi 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 phan hồi (feedback)

• Bước 4: Chinh sưa và mơ rộng Prototype. Nêu co thay đổi sẽ lặp lại bươc 3 và 4

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

104

Phân lo i Prototypinga

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

ô M

ôn

HT

TT

- K

ho

a C

NT

T -

HU

I

105

Horizontal Prototype• Con đươc gọi là behavioral prototype hay mock – up.• Đươc gọi là horizontal vì no không đi sâu vào tât ca layer

của kiên truc mà chi mô ta cơ ban giao diện người dùng• Horizontal prototype chi ngầm chưa chưc năng mà

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

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

106

M c đich 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• Phiên ban thuyêt minh của hệ thống đê đươc châp nhận

mua từ đối tác• Phát triên các đánh giá sơ bộ vê thời gian, chi phi và

nhân sự.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

107

Vertical Prototype

• Con đươc gọi là structure prototype hay proof of concept

• No thực thi 1 phần chưc năng của ưng dung từ giao diện người dùng thông qua các lơp dịch vu kỹ thuật. No làm việc như 1 hệ thống thực sự vì tiêp xuc vào tât ca các mưc độ của việc thực thi hệ thống.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

108

Khi nao dùng Vertical Prototype• Muốn kiêm tra phương pháp kiên truc đươc đê nghị co

kha thi và đung đăn hay không?• Tối ưu hoa các thuật toán, đánh giá các lươc đồ cơ sơ dư

liệu dự định.• Kiêm tra nhưng yêu cầu quan trọng.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

109

Throwaway Prototypes

• Con đươc gọi là exploratory protype đê tra lời câu hoi, giai quyêt sự không chăc chăn, và nâng cao yêu cầu chât lương.

• Đươc loại bo sau khi kêt thuc và không dùng lại trong các phiên ban sau.

• 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 chung đươc thực thi trong hệ thống. B

ô M

ôn

HT

TT

- K

ho

a C

NT

T -

HU

I

110

Throwaway Prototypes

• Vì Throwaway Prototype đươc làm rât nhanh. Người dùng co thê nhanh chong phan hồi và làm rõ hơn yêu cầu của họ.

• Các thay đổi đươc thực hiện sơm trong chu ky SDLC sẽ làm giam chi phi đáng kê và không phai reword trong các giai đoạn sau.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

111

Evolutionary Prototypes

• Trái vơi Throwaway Prototype, evolutionary prototype cung câp nên tang câu truc vưng chăc đê xây dựng san 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.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

112

Evolutionary Prototypes• Evolutionary prototype phai đươc xây dựng co ca ma

chương trình ngay từ đầu, mât nhiêu thời gian hơn là throwaway prototype khi ca hai mô phong cùng một chưc năng hệ thống

• Evolution prototype phai đươc thiêt kê sao cho phát triên và mơ rộng sau này, vì vậy developers phai chu y đên kiên truc SW

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

113

Evolutionary Prototypes

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

114

So sánh các Prototypes

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

115

Paper Prototypes

• Paper prototype là cách đơn gian, nhanh, re và kỹ thuật thâp

• Thường đươc dùng cho các vong 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 thao y tương ra giây không bận tâm đên việc các control sẽ xuât hiện chinh xác ơ đâu và trông như thê nào.

• 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

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

116

Electronic Prototypes

• Co nhiêu công cu thich hơp cho việc xây dựng election throwaway prototype:

• 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• Drawing tools such as microsoft Visio and Microsoft

PowerPoint

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

117

Đánh giá Prototypes• Đê đánh giá hiệu qua horizontal prototypes nên tạo kịch ban

(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 hoi thu thập thông tin như:

• Does the prototype implement the functionality in the way you expected?

• 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 you?• Were any tasks overly complex?

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

118

Đánh giá Prototypes

• Phai đam bao chọn đung 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ư it kinh nghiệm.

• Quan sát người dùng luc họ làm việc vơi prototype tốt hơn là chi đơn gian hoi họ nghĩ gì vê prototype. Co thê phát hiện đươc nhiêu điêu từ sự quan sát này.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

119

Đánh giá Prototypes

• Yêu cầu người đánh giá chia se suy nghĩ của họ khi làm việc vơi prototype, co thê phát hiện các yêu cầu con thiêu. Nên tạo môi trường thân thiện đê người đánh giá tự do trình bày y kiên của họ.

• Lưu trư lại kêt qua đánh giá prototype• Vơi horizontal prototype: dùng thông tin này đê điêu

chinh lại yêu cầu trong SRS• Vơi verticak prototype: nên xem xét các mâu thuẫn giưa

SRS và prototype.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

120

Các r i ro c a ph ng pháp ủ ủ ươPrototyping• The biggest risk is that a stateholder will see a running

prototype and conclude that the product is nearly completed

• Đùng ngại việc phai giao san phâm “chưa hoàn chinh” mà bo qua việc tạo prototype. Phai xác định rõ vơi ai xem prototype là no không phai là san phâm cuối.

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

121

Các r i ro c a ph ng pháp ủ ủ ươPrototyping• Cách khăc phuc:• Dùng paper prototype• DÙng 1 công cu prototype khác hẳn vơi công cu 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 thuc sơm và bàn giao”

• Đê prototype trông co ve như ban nháp, không cần trau chuốt B

ô M

ôn

HT

TT

- K

ho

a C

NT

T -

HU

I

122

Các r i ro c a ph ng pháp ủ ủ ươPrototyping• Người dùng quá chu 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 san phâm cuối sẽ giống như việc thực thi của prototype.

• Vi du: nêu người dùng thây prototype đáp ưng tưc thì khi truy vân 1 DB mô phong, họ co thê nghĩ thực thi trong san 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

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

123

Các r i ro c a ph ng pháp ủ ủ ươPrototyping• Các hoạt động làm prototype co 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, co khi họ sẽ phát hành prototype như san phâm cuối, hoặc vội va đưa ra 1 san 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

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

124

Prototyping Success Factors

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

• Xác định muc đich của mỗi prototype trươc khi băt đầu• Nên lập kê hoạch cho nhiêu prototype. Hiêm khi co kêt

qua ngay trong lần thư đầu tiên• Tạo throwaway prototypes thật nhanh và re nhât• Không nên đưa việc kiêm tra dư liệu đầu vào, quan ly lỗi,

ma hoa dư liệu…vào throwaway prototype

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

125

Prototyping Success Factors

• Sư dung dư liệu hơp ly trong prototype screen display and reports. Người đánh giá không con chu y đê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

• Đừng mong đơi prototype co 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,…

Bô

Mô

n H

TT

T -

Kh

oa

CN

TT

- H

UI

126