Phân tích và quản lý yêu cầu phần mềm

Chủ Đề: Ngân hàng đề thi + giáo trình môn Chuyên đề 2Read

Đề cương ôn tập Chuyên đề 2: Phân tích và quản lý yêu cầu

phần mềm.

Câu 1: Nêu tầm quan trọng và mục tiêu of hoạt động phân tích và quản lý yêu cầu phần mềm ?

• Tầm quan trọng:

 Quản lý yêu cầu (RM) là một trong các thành phần quan trọng nhất của dự

án phát triển phần mềm:

o Chắt lọc,

o Tổ chức,

o Tư liệu hóa,

o Lưu vết các yêu cầu hệ thống.

=> giúp thẩm tra, thẩm định hệ thống, quản lý thay đổi và phân tích các trạng thái của dự án

Như vậy có thể quản lý được mọi thay đổi của yêu cầu dự án

 Chi phí sửa lỗi do hiểu sai, bỏ sót yêu cầu là rất lớn nếu bỏ sót hay hiểu sai các yêu cầu phần mềm có thể dẫn đến sai lầm nghiêm trọng ( Cái này nên đưa vào một số con số)

 Tuy nhiên hoạt động phần tích và quản lý yêu cầu phần mềm thường bị coi nhẹ

o Mục tiêu:- Chém gió thôi chưa tìm được tài liệu nào

o Phân tích các yêu cầu của người sử dụng (Yêu cầu thô thường là ngôn ngữ tự nhiên) thành các feature làm đầu vào để sinh các Use Case phục

vụ cho các pha sau trong tiến trình phát triển phần mềm

o Sinh các test case phục vụ cho việc kiểm thử

o Tạo ra các tài liệu đặc tả phục cho phần mềm hay người sử dụng, phát triển và bảo trì phần mềm

Câu 2: Định nghĩa StackHolder và Actor của hệ thống ? Xác định các StackHolder

và Actor cho dự án phần mềm cụ thể.

- Đinh nghĩa StackHolder và Actor của hệ thống:

o StackHolder:

StackHolder được định nghĩa là 1 người hoặc 1 nhóm người bị tác động bởi kết quả của dự án phát triều hệ thống hoặc có thể tác động đến các hoạt

1

động hoặc đầu ra của dự án (Có thể xem StackHolder là bất kỳ người nào

có thể có yêu cầu với hệ thống)

Các StackHolder có thể là:

 Các khách hàng;

 Người dùng cuối

 Người phát triển

 Nhà sản xuất

 Người kiểm thử

 Đảm bảo chất lượng

 Người quả trị Cơ sở dữ liệu

 Người quản lý cấu hình

 Nhà cung cấp

 Nhà tiếp thị

 Người bảo trì

 Người quản lý

 Các cơ quan quy định tính an toàn/ không nguy hiềm

o Actor

Một tác nhân là một người hoặc một vật tương tác với hệ thống Nó có thể

là một người nhưng nó cũng có thể là một hệ thống khác

- Ví dụ về website của công ty du lịch:

o StackHolder có thể là :

 Khách hàng: là người chủ of Website ;

 Người dùng cuối là những người sử dụng Website qua Internet;

 Người tham gia vào hoạt động phát triển hệ thống

 Người cung cấp tri thức cho hệ thống

 Người quản lý hệ thống

 Người bảo trì và hỗ trợ hệ thống

o Actor của hệ thống:

 User: Người trực tiếp sử dụng hệ thống

 Travel Agency Owner: Có thể là một tác nhân nếu anh ta ban hành một

số UC cụ thể cho anh ấy Phụ thuộc vào liệu anh ấy có quyền hạn cụ thể

gì và liệu có chức năng hệ thống nào là chỉ sẵn dùng cho anh ấy Nếu anh ấy truy cập đến các chức năng tương tự như quản trị viên, thì không cần tạo tác nhân riêng cho Travel Agency Owner vì tác nhân quản trị viên bao trùm nó

 Content Manager là một tác nhân, người cung cấp nội dung qua giao diện

 Hotel Provider, Car Rental Agent, và Airline Representative có thể xem

như 3 tác nhân riêng rẽ, hoặc xem như một tác nhân được gọi là Service

Provider Phụ thuộc vào việc họ thực hiện các UC khác nhau như thế

nào Quyết định này có thể được tạo trong tiến trình sau hơn

Câu 3: Trình bày phương pháp suy luận yêu cầu Ưu và nhược điểm của từng

phương pháp?

ST

vấn 1 nhóm Stackholder đã được lựa chọn

- Tính tự nhiên trong giao tiếp

- Là cách tốt nhất cho việc thu thập các yêu cầu về khả năng sử dụng, độ tin cậy hiệu năng và khả năng hỗ trợ củ hệ thống

- Mất nhiều thời gian, căng thẳng, phụ thuộc nhiều vào điều kiện của người được hỏi

thăm dò Bản câu hỏi thăm dò là hữu ích nhất nếu

chúng ta có thể hỏi nhiều stackholder các câu hỏi tương tự và chúng ta không mong đợi sinh them các câu hỏi

- Nhanh và rẻ hơn phỏng vấn

- Dễ tổng kết

- Đào tạo người điều tra

ít tốn kém hơn cả về thời gian và chi phí

Kết quả có độ chính xác thấp và được đánh giá bằng con số trung bình thống kê

được lựa chọn gặp gỡ nhóm dự án Họ thảo luận tập trung trong một khoảng thời gian

- Có thể áp dụng các kỹ thuật suy luận yêu cầu khác nhau

- Có thể thu thập các yêu cầu mới xét duyệt, phân loại và đánh thứu

tự ưu tiên cho các yêu cầu đang tồn tại

- Mất thời gian nếu hội thảo về 1 vấn đề quá lâu

- Thiếu dữ liệu về stackeholder có thể khiến cho buổi hội thảo thất bại

- Những phát biểu tiêu cực, không có tính xây dựng có thể làm thất bại buổi hội thảo hay kéo dài thời gian

4 Thẻ sự kiện -Sử dụng công cụ đồ

họa, trực quan để mô

tả hành vi hệ thống

- Bộ tiện ích chỉ ra thẻ sự kiện ban đầu cho nhóm

- Sau đó, dựa trên các lời bình từ những người tham gia, thẻ

sự kiện được thay đổi

- Nhanh và chính xác cho mỗi thẻ sự kiện

- Thuận tiện cho các quá trình lặp (nếu muốn lấy lại ý kiên )

- Trực quan , dễ tưởng tượng

- Phải design lại nếu các yêu cầu có sự thay đổi

- Việc cập nhật thẻ sự kiện là 1 tiến trình lặp hay thẻ sự kiện sẽ thay đổi để mô phỏng hệ thống ngày một chính xác theo yêu cầu của stackeholder

3

và được biểu diễn lại.

5 Phân vai Các thành viên trong

nhóm được gán cho vai trò liên quan đến

hệ thống được xây dựng.Thông thường nhất, các vài trò thường là người sử dụng hệ thống hoặc các tác nhân khác tương tác với hệ thống

- Mô tả tương đối chính xác các yêu cầu của stackeholder

- Có thể thiếu sót đi yêu cầu do chưa mới khảo sát trên phương diện của một

stackeholder

- Tốn thời gian và mất chi phí đào tạo

làm việc tập

trung

Những người tham gia tập hợp lại trong thời gian ngắn Khi bắt đầu, người chỉ đạo thông báo mục đích của phiên Các yêu cầu mới có thể sinh ra liên quan đến một số phần của hệ thống hoặc liên quan đến việc giải quyết vấn đề Mỗi người tham gia cung cấp 1

số ý kiến và các ý kiến không được phép bình phẩm Sau khi mọi ý kiến đã được viết, chọn ngẫu nhiên hoặc tạo sự kết hợp các ý kiến này

- Phương pháp này đặc biệt hữu ích khi một vấn đề cần được giải quyết – hoặc là một phần đáng kể của yêu cầu bị bỏ sót, hoặc yêu cầu là xung độtrr

- Tốn thời gian và chi phí

- Thời gian cho 1 phiên rất lâu nếu các yêu cầu được sinh ra càng nhiều

- Không thích hợp cho các biểu đồ quan hệ vì

nó chỉ sinh ra một số lượng nhỏ các ý kiến

các biểu đổ

quan hệ

Gồm 4 bước:

B1: Tạo các thẻ

B2.Sắp xếp các thẻ B3.Thảo luận mô hình

B4 Tạo các tiêu đề

B5 Cấu trúc mô hình

Phương pháp này đặc biệt hữu ích khi:

- Có một số lớn các ý kiến

- Mối quan hệ giữa các mục không rõ rang

- Các vấn đề là phức tạp

- Sự nhất trí nhóm là cần thiết

Phương pháp này không thích hợp trong trường hợp chỉ có một số lượng nhỏ các ý kiến

8 Mẫu thử Mẫu thử là một - Đem lại những ý kiến - Chi phí lớn do phải

phương pháp tiềm lực

để có được các phản hồi từ người dùng và khách hàng

đầy đủ về hệ thống khi đưa ra mẫu thử để chính khách hàng kiểm thử

phát hành một phiên bản mới của hệ thống

là tón chi phí

- Nhiều chức năng của

hệ thống thường được hóa cứng , nên mẫu thử như bản sự kiên phức tạp

dụng (UC) Các UC là một kiểu yêu cầu trong kim tự

tháp Chúng ta cũng

là khuôn dạng để các stackeholder phát biểu các nhu cầu của họ

- Mô tả chính xác hệ thống từ các stackeholder

10 Phân tích

các tài liệu

Trích rút thông tin từ các tài liệu word, các email và các ghi chú

- Tiết kiệm chi phí (Do chỉ phải tìm tài liệu

và trích rút)

- Chưa đầy đủ nếu thiếu tài liệu

- Cần người có kinh nghiệm để parse dữ liệu

11 Quan sát và

mô phỏng

nhiệm vụ

Quan sát người dùng thực thi những nhiệm

vụ cụ thể

- Người dùng có thể

mô phỏng nhiệm vụ, trong khi người phân tích ghi chú và tạo các quan sát

- Tốn chi phí do cần người mô phỏng và người quan sát

12 Phân tích

các hệ

thống đang

tồn tại

- Thu thập các yêu cầu từ hệ thống bị thay thế hoặc từ các hệ thống cạnh tranh đã được xây

dựng

- Nếu chúng ta đang phát triển 1 hệ thống tương tự 1 hệ thống

đã tồn tại và chúng ta

có quyền truy cập đến sản phẩm cuối cùng, rất đáng giá cho việc phân tích công việc của các hệ thống này

để học hỏi rút ra kinh nghiệm từ các thành công cũng như các lỗi của chúng

- Không thích hợp cho những hệ thống mới

- Có thể mất sự sang tạo nếu quá phụ thuộc vào các hệ thống cũ (I thinks so

^_^)

Kết luận: Tùy thuộc vào từng dự án đang phát triển chúng ta có thể lựa chọn một phương

án hay kết hợp lại nhằm đưa ra 1 kết quả tốt nhất nhé !!!!

5

Câu 4: Trình bày ngắn gọn tiến trình phân tích và quản lý yêu cầu phần mềm.

1 Thiết lập kế hoạch quản lý các yêu cầu

Một trong các nhiệm vụ đầu tiên trong dự án là phát triển kế hoạch quản lý các yêu cầu (Requirements Management Plan - RPM) RPM mô tả cách tiếp cận tổng quan để quản lý các yêu cầu trong dự án

Sau đây là một số câu hỏi có thể được trả lời trong RPM:

 Công cụ RM gì sẽ được sử dụng?

 Các kiểu yêu cầu gì sẽ được lưu dấu vết trong dự án?

 Các thuộc tính của các yêu cầu này là gì?

 Các yêu cầu sẽ được tạo ở đâu – chỉ trong CSDL hay trong các tài liệu?

 Giữa các yêu cầu nào chúng ta cần triển khai dấu vết?

 Các tài liệu gì được yêu cầu?

 Những yêu cầu và những tài liệu gì sẽ được sử dụng như là bản hợp đồng với khách hàng?

 Nếu một phần của dự án được đặt mua, các yêu cầu và các tài liệu gì sẽ được sử dụng như là bản hợp đồng với nhà cung cấp?

 Chúng ta tuân theo phương pháp luận RUP hay phương pháp luận khác?

 Khách hàng có cần tài liệu gì để tuân theo tiến trình phát triển của họ?

 Quản lý thay đổi sẽ được triển khai như thế nào?

 Giả sử rằng RequisitePro được sử dụng, toàn bộ hệ thống sẽ được lưu trữ trong một dự án RequisitePro hay lưu trữ ở nhiều dự án?

 Tiến trình nào sẽ đảm bảo rằng mọi yêu cầu đã được cài đặt và đã được kiểm thử?

 Các yêu cầu và các khung nhìn nào mà chúng ta cần để sinh ra các báo cáo?

2 Suy luận các yêu cầu

- Suy luận các yêu cầu, còn được gọi là thu thập các yêu cầu, là một bước rất quan

trọng Bỏ sót hoặc hiểu sai một yêu cầu ở trạng thái này sẽ lan truyền vấn đề xuyên qua suốt vòng đời của phát triển phần mềm

- Sau đây là một số kỹ thuật được sử dụng để thu thập các yêu cầu từ các Stakebolder:

 Phỏng vấn

 Bảng các câu hỏi

 Hội thảo

 Bảng tường thuật

 Đóng vai

 Các phiên làm việc tập thể (Brainstorming sesions)

 Các biểu đồ quan hệ

 Mẫu thử

 Phân tích các tài liệu

 Các trường hợp sử dụng (Use case)

 Phân tích hệ thống đang tồn tại

3 Phát triển tài liệu trực quan

Trong khi phát triển tài liệu trực quan, một trong các mục đích chính của phân tích nghiệp vụ là sinh ra các đặc trưng từ các nhu cầu Stakeholder

Tài liệu trực quan phải chứa thông tin bản chất về hệ thống sẽ được phát triển Bên cạnh việc liệt kê mọi đặc trưng, nó lên chứa một mô tả tổng quan về sản phẩm, mô tả người dùng và tóm lược các khả năng của hệ thống, và các thông tin khác để có thể hiểu mục tiêu của hệ thống Nó cũng liệt kê mọi nhu cầu Stakeholder trong trường hợp chúng không được nắm bắt trong các tài liệu riêng lẻ

4 Tạo các Use case

7

Hình 1.5 Các đặc trung được sinh ra từ các nhu cầu

Một use case là một mô tả về hệ thống theo một chuỗi các hành động Nó nên sinh

ra kết quả có thể quan sát hoặc trả về giá trị cho tác nhân (tác nhân là một người hoặc một thứ mà tương tác với hệ thống) Các use case:

 Được khởi tạo bởi một tác nhân

 Một hình hóa một sự tương tác giữa tác nhân và hệ thống

 Mô tả một chuỗi các hành động

 Nắm bắt các yêu cầu chức năng

 Nên cung cấp một số giá trị cho tác nhân

 Trình bày luồng sự kiện đầy đủ và có ý nghĩa đầy đủ

5 Đặc tả bổ sung

Đặc tả bổ sung nắm bắt các yêu cầu phi chức năng (khả năng sử dụng, độ tin cậy, sự thực thi, khả năng hỗ trợ, ) và một số yêu cầu chức năng mà xuyên xuốt hệ thống, vì nó không được nắm bắt cứng nhắc trong các use case

6 Tạo các Test Case từ các Use Case

Các Test Case sẽ chỉ cho người kiểm thử các bước nên thực hiện để kiểm tra mọi yêu cầu Trong bước này, chúng ta sẽ tập trung tạo các Test Case từ các Use Case Nếu chúng

ta chưa tạo các kịch bản trong khi sinh ra các Use Case, chúng ta cần định nghĩa chúng bây giờ

7 Tạo các Test Case từ Đặc tả bổ sung

Cách tiếp cận được sử dụng trong bước trước không áp dụng để kiểm thử các yêu cầu bổ sung Vì các yêu cầu này không được phát biểu như một chuỗi các hành động, khái niệm

về các kịch bản không áp dụng cho chúng Một cách tiếp cận riêng nên được áp dụng cho mỗi yêu cầu bổ sung, vì các kỹ thuật được sử dụng để kiểm tra các yêu cầu thực thi là khác so với kỹ thuật được sử dụng để kiểm tra các yêu cầu về khả năng sử dụng Trong bước này chúng ta cũng thiết kế các vấn đề liên quan đến cơ sở hạ tầng và nền tảng/môi trường vận hành hệ thống

8 Thiết kế hệ thống

Các yêu cầu là nền tảng cho thiết kế hệ thống, mà thường được tạo thuận lợi bởi việc sử dụng ngôn ngữ mô hình hóa thống nhất (UML – Unified Modeling Language) [BOO98] Nhiều công cụ như Rational Rose, Rational Software Architect, Rational Data Architect,

và Rational Software Modeler, có thể tạo thuận lợi đáng kế trong việc tạo mọi biểu đồ được yêu cầu

Câu 5: Trình bày mối quan hệ giữa yêu cầu trong kim tự tháp yêu cầu Tại sao phải quản lý dấu vế các kiểu yêu cầu Tại sao đối với các dự án phần mềm lớn

và phức tạp phải quản lý các yêu cầu phần mềm theo mô hình kim tự tháp.

1 Mối quan hệ giữa yêu cầu trong kim tự tháp yêu cầu.

- Các kiểu yêu cầu thường được sử dụng trong các dự án:

 Stakeholder need (nhu cầu Stakeholder): Một yêu cầu được để xuất bởi

Stakeholder

 Feature (đặc trưng): Một dịch vụ được cung cấp bởi hệ thống, thường được hình

thành bởi hoạt động phân tích nghiệp vụ; mục tiêu của một đặc trưng là để thỏa mãn một nhu cầu Stakeholder

 Use case (ca sử dụng): Một mô tả về hành vi của hệ thống theo các thuật ngữ về

một chuỗi các hành động

 Supplementary requirement (yêu cầu bổ sung): yêu cầu khác (thường là yêu cầu

phi chức năng) và không thể được thể hiện trong các use cases

 Test case (ca kiểm thử): một đặc tả về các đầu vào kiểm thử, các điều kiện thực

thi, và các kết quả mong đợi

 Scenario (kịch bản): Một chuỗi hành động cụ thể; một đường cụ thể qua một use

case

Các yêu cầu này có thể được biểu diễn theo hình của một kim tự tháp

9

Ở mức đỉnh của nó là các nhu cầu Stackeholder, ở các mức thấp hơn là các đặc trưng, các

ca sử dụng, các yêu cầu bổ sung

Thông thường ở các mức yêu cầu khác nhau, các mức độ chi tiết cũng khác nhau Càng ở mức thấp, mức độ chi tiết càng cao

Từ một yêu cầu mức trên, có thể ánh xạ thành nhiều yêu cầu mức dưới

2. Phải quản lý dấu vết các yêu cầu là vì:

- Dấu vết – Traceability:

o Là kỹ thuật cung cấp mối quan hệ giữa hai mức độ yêu cầu

o Giúp xác định nguồn gốc của một yêu cầu bất kỳ

o Mỗi nhu cầu thương được ánh xạ từ một số đặc trưng

- Vai trò của kỹ thuật Traceability:

o Thẩm tra rằng bản cài đặt là thỏa mãn đầy đủ mọi yêu cầu: Mọi thứ mà khách hàng yêu cầu đã được cài đặt

o Thẩm tra rằng ứng dụng chỉ đáp ứng những gì được yêu cầu: Không cài đặt những thứ mà khách hàng không yêu cầu

Hình 1.2 – Kim tự tháp các yêu cầu