THIẾT KẾ VÀ XÂY DỰNG PHẦN MỀM - Chương 1: Tổng hợp và phân tích các yêu cầu phần mềm potx

Phát hiện các yêu cau phan mém Software SN Elicitation Phan tich bai toan _ Xác định quá trình phát triên các yêu câu phân mêm Xây dựng khả năng vision và phạm vị scope của phân mêm X

THIET KE VA XAY DUNG PHAN MEM (SOFTWARE DESIGN AND CONSTRUCTION)

Nam hoc 2007-2008

Giáo viên: TS.Huỳnh Quyết Thang

BM Công nghệ phần mêm Khoa CNTT, DHBK HN

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

1 Các vẫn đề và khái niệm trong yêu cầu phần mém

2 Phát hiện các yêu cầu phân mêm (Software Elicitation)

3 Xây dựng các đặc tính xác định chất lượng yêu câu và các

yêu cầu khác

4 Đặc tả các yêu cầu phân mêm

5 Xác định nguôn gốc yêu cau và ma trận theo dõi các yêu

cau phan mém

6 Tham dinh xac minh cac yéu cau phan mém (verification

requirement)

đ 1.2 Phát hiện các yêu cau phan mém (Software SN

Elicitation)

Phan tich bai toan _ Xác định quá trình phát triên các yêu câu phân mêm

Xây dựng khả năng (vision) và phạm vị (scope) của phân mêm

Xác định các nhóm người sử dụng và đặc tính của họ và đại diện tiêu biêu cho môi nhóm

Phan tích và xác định các yêu câu phân mềm dựa trên các đại diện của các nhóm NSD

Xây dựng các đặc tính xác định chất lượng yêu câu và các yêu câu khác (non-functional requirement)

The goal of problem analysis is to gain a better understanding, before development begins, of the problem being solved

To identify the root cause, or the problem behind the problem, ask the people directly involved

Identifying the actors on the system is a key step

tay Phân tích bài toán (vẫn dé) >

[Dean Leffingwell] - The 5 specific steps that must be taken in order to achieve the goal:

Gain agreement on the problem definition

Understand the root causes—the problem behind the problem

Identify the stakeholders and the users

Define the solution system boundary

Identify the constraints to be imposed on the

tay Phân tích bài toán (vẫn dé) >

Step 1: Gain Agreement on the Problem Definition

Simply write the problem down and see whether everyone agrees

The Problem Statement:

Table 4-1 Problem statement format

Element Description The problem of Describe the problem

affects Identify stakeholders affected by the problem

the result of which Describe the impact of this problem on

stakeholders and business activity

Benefits of Indicate the proposed solution and list a few key

Step 2: Understand the Root Causes—The Problem Behind the Problem

Your team can use a variety of techniques to gain an understanding of the real problem and its real causes

One such technique Is "root cause" analysis, which Is

a systematic way of uncovering the root, or underlying, cause of an identified problem or a symptom of a

problem

tay Phân tích bài toán (vẫn dé) >

Step 3: Identify the Stakeholders and the Users

Who are the users of the system?

Who is the customer (economic buyer) for the system?

Who else will be affected by the outputs that the system produces?

Who will evaluate and bless the system when it is delivered and deployed?

Are there any other internal or external users of the system whose needs must be addressed?

Who will maintain the new system?

tay Phân tích bài toán (vẫn dé) >

otep 4: Define the Solution System Boundary

Who will supply, use, or remove information from the system?

Who will operate the system?

Who will perform any system maintenance?

Where will the system be used?

Where does the system get its information?

What other external systems will interact with the

tay Phân tích bài toán (vẫn dé) >

Step 5: Identify the Constraints to Be Imposed on the Solution

Potential system constraints: Economic, Political, Technical, System, Environmental, Schedule and resources

1.2.1 Xác định quá trình phát triên các yêu câu phân SN mêm

Xác định các bước và tài liệu mô tả quy trình chúng ta

sẽ thực hiện quá trình phát triển các yêu cầu phân mém

M6 ta phuong phap xac dinh cac NSD trong pham vi

bài toán của phần mềm và các kỹ thuật sẽ sử dụng để

phát hiện các yêu câu phần mềm

Mô tả các đặc tả hoặc các mô hình phân tích của phân mém

Các thông tin cho mỗi yêu câu, trọng số của yêu câu Các bước tiên hành phá hiện các yêu câu, phân tích yêu cau

requirement)

Mô tả khả năng, mục tiêu của phần mềm, các

phạm vi ứng dụng của phần mềm, các hạn chế

của phân mềm, một số đặc điểm của ứng dụng: ai

sử dụng, trong mô trường nào

Thông thường tất cả các thôg tin này được mô tả

ngắn gon trong 3-8 trang theo câu trúc như sau:

⁄ 122 Xây dựng khả năng (vision) và phạm vỉ (scope) của SN

phân mêm

Câu trúc của tài liệu:

1 Yêu cầu phần mềm (mức cao business)

1.1 Cơ sở (background)

1.2 Cơ hội

1.3 Đối tượng 1.4 Yêu cầu khách hàng hay yêu câu thị trường 1.5 Các giá trị cung cập cho khách hàng

1.6 Các rủi ro

2 Kha nang cua phan mềm (vision of solution)

2.1 Cac kha nang

2.2 Cac dac diém 2.3 Các phụ thuộc và chấp nhận

⁄ 122 Xây dựng khả năng (vision) và phạm vỉ (scope) của SN

phân mêm

Câu trúc của tài liệu:

3 Phạm vi và giới hạn (scope and limitation)

3.1 Phạm vi của phiên bản đầu 3.2 Phạm vi của các phiên bản tiếp theo

⁄ 122 Xây dựng khả năng (vision) và phạm vỉ (scope) của SN

phần mêm

1 Yêu cầu phân mềm (mức cao business requirement)

Mô tả các đặc điểm chính mà phần mềm mới sẽ cung

cấp cho khách hàng Thông thường phân này rất khác nhau cho những phần mềm khác nhau

1.1 Cơ sở (background)

Mô tả lý do hợp lý cần phát triển phần mềm mới: tai

sao, cơ sở nào Có thể giải thích tông thể lịch sử hoặc

tình huỗng quyết định cần phải xây dựng phần mềm

1.2 Co hdi (business opportunity)

Mô tả cơ hội trên thị trường đang tôn tai van dé ma

phần mềm sẽ giải quyết Có thê mô tả ngắn gọn một số

phan mềm tương tự và các đặc tính của chúng và giải

thích tại sao càan làm phần mềm này

⁄ 122 Xây dựng khả năng (vision) và phạm vỉ (scope) của SN

phân mêm

1.3 Đối tượng/mục tiêu

Mô tả mục tiêu mà phần mềm giải quyết 1.4 Yêu cầu khách hàng hay yêu câu thị trường

Mô tả các đối tượng khách hàng mà phân mềm sẽ phục

vụ

1.5 Các giá trị cung cập cho khách hàng

Mô tả chỉ tiết các khả năng của phần mềm sẽ cung cấp

cho khách hàng:

- Khả năng giải quyết công việc

- Khả năng tiết kiệm

- Khả năng tự độnghóa các công việc trước đây

1.6 Các rủi ro

phần mêm

⁄ 122 Xây dựng khả năng (vision) và phạm vi (seope) của ¬

2 Khả năng của phần mém (vision of solution)

các chức năng phân mêm

2.1 Các khả năng

mềm

2.2 Các đặc điệm

nao 2.3 Các phụ thuộc và châp nhận

điểm này sẽ khách những phân mêm tương tự như thê

Ghi nhận lại các phụ thuộc và các chấp nhận đã thực

17

Mô tả cáckhả năng của phần mềm ở đay sẽ không mô tả

Mô tả chính xác ngắn gọn các mục đích dài hạn của phần

/

⁄ 122 Xây dựng khả năng (vision) và phạm vỉ (scope) của SN

phân mêm

3 Phạm vi và giới hạn (scope and limitation)

Mô tả các giới hạn về khả năng của phần mềm Phân mềm chỉ giải quyết bài toán ở mức độ như vay

3.1 Phạm vi của phiên bản đầu Các phạm vi của phiên bản đầu (1.0) 3.2 Phạm vi của các phiên bản tiếp theo

Các phạm vi của các phiên bản tiếp theo

3.3 Hạn chế và ngoại lệ

Mô tả các hạn chế và ngoại lệ của phần mềm

4 Ngữ cảnh công viéc (business context)

4.1 Tiêu sử khách hàng

4.2 Các trong sô dự án

5 Các yêu tô thành công của dự án

⁄ 122 Xây dựng khả năng (vision) và phạm vỉ (scope) của SN

Chia lam O3 loại:

Các mục tiêu chính của phần mém (objectives)

Các ràng buộc và hạn chế (constraint)

Mức độ tự do của phần mềm (khả năng cân đôi giữa mục

tiêu và các ràng buộc)

5 Các yêu tô thành công của dự án

Các yếu tô làm dự án kha thi Các yêu tô chứng tỏ khả ăng cạnh tranh của phân mềm

Phân loại theo đặc điêm

Phân loại theo vị trí địa lý Phân loại theo vai trò công việc Phân loại theo chức năng

Liệt kê các phân loại (các lớp) và mô tả chỉ tiết

các đặc điềm của NSD ở từng lớp

(2) Tim cdc NSD tiéu biéu (presentative user)

(3) Khái niệm Product Champion: Nhtng dai dién

tiêu biểu của từng nhóm người sử dụng Trên

thực tê các yêu câu phần mềm sẽ được phát a)

1.2.3 Xác định các nhóm người sử dụng và đặc tính của họ SN

và đại điện tiêu biêu cho môi nhóm

21

⁄ 124 Phân tích và xác định các yêu câu phân mêm dựa

trên các đại diện của các nhóm NSD ¬

Nguyên tắc của phát hiện yêu câu phần mềm:

(1) định nghĩa phạm vi và giới hạn phần mềm

(2) Xác định các phân nhóm người sử dụng

(3) Xác định các đại diện của từng nhóm

(4) Xac dinh Product Champion của từng nhóm

(5) Lựa chọn kỹ thuật phát hiện yêu cầu phần mềm

(6) áp dụng kỹ thuật cho tung dai dién - Product Champion

(7) Xây dựng các tiêu thức chất lượng

(8) Chi tiết hóa (chuyên hóa) các trường hợp sử dụng thành

chức năng phân mềm

(9) Xem xét các trường hợp sử dụng và chức năng

(10) Phat triển mô hình phân tích, gải thích và làm rõ với các

khách hàng

⁄ 124 Phân tích và xác định các yêu câu phân mêm dựa

trên các đại diện của các nhóm NSD

Nguyên tắc của phát hiện yêu câu phần mềm:

(11) Phá ttriển và đánh giá giao diện cho từng yêu cầu

(12) Phát triển các trường hợp kiểm thử cho các yêu cầu

(13) Sử dụng các trường hợp kiểm thử đề kiểm tra

(14) Lặp lại các bước 6-13 trước khi thiết kế

⁄ 124 Phân tích và xác định các yêu câu phân mêm dựa SN

trên các đại diện của các nhóm NSD

Một trong những kỹ thuật tiêu biểu để xác định

và phát hiện các yêu câu sử dụng là “Trường

hợp sử dụng”- use-case

Use-case: Thể hiện tập hợp các tương tác

giữa các tác nhân (actor) và hệ thông Actor (tác nhân):

⁄ 124 Phân tích và xác định các yêu cầu phan mém dựa SN

trên các đại diện của các nhóm NSD

⁄ 124 Phân tích và xác định các yêu câu phân mêm dựa SN

trên các đại diện của các nhóm NSD

Các lỗi thường hoặc là những điểm nên tránh

trong phát hiện yêu câu:

(1) Có quá nhiêu use-case

(2) Có các use-case trùng lặp

(3) Trong mô hinh use-case xay dựng không được

phép dưa vào giao diện voi NSD

(4) Định nghĩa dữ liệu trong các use-case

(5) Cô gắng gắn mỗi yêu câu với một use-case

⁄ 12 Các kỹ thuật phát hiện yêu câu phân mêm từ phía SN

⁄ 12 Các kỹ thuật phát hiện yêu câu phân mêm từ phía SN

khách hàng

Interview

Interviewing is a simple and direct technique

Context-free questions can help achieve bias-free interviews

Then, it may be appropriate to search for undiscovered requirements by exploring solutions

Convergence on some common needs will initiate a

"requirements repository" for use during the project

A questionnaire is no substitute for an interview

⁄ 12 Các kỹ thuật phát hiện yêu câu phân mêm từ phía SN

khách hàng

Interview

The Context-Free Question

Who is the user?

Who is the customer?

Are their needs different?

Where else can a solution to this problem be found?

⁄ 12 Các kỹ thuật phát hiện yêu câu phân mêm từ phía SN

khách hàng

Interview

Prepare an appropriate context-free interview, and jot it down

in a notebook for reference during the interview Review the

questions just prior to the interview

Before the interview, research the background of the stakeholder and the company to be interviewed Don't bore the person being interviewed with questions you could have

answered in advance On the other hand, it wouldn't hurt to

briefly verify the answers with the interviewee

Jot down answers in your notebook during the interview

(Don't attempt to capture the data electronically at this time!) Refer to the template during the interview to make certain that the right questions are being asked

⁄ 12 Các kỹ thuật phát hiện yêu câu phân mêm từ phía SN

⁄ 12 Các kỹ thuật phát hiện yêu câu phân mêm từ phía SN

khách hàng

2 Requirement Workshop

Preparing for the Workshop:

Selling the Concept Ensuring the Participation of the Right Stakeholders Logistics

“Warm-Up Materials"

Role of the Facilitator Setting the Agenda Running the Workshop

⁄ 12 Các kỹ thuật phát hiện yêu câu phân mêm từ phía SN

khách hàng

3 Brainstorming and Idea Reduction

Brainstorming involves both idea generation and idea reduction

The most creative, innovative ideas often result from

combining multiple, seemingly unrelated ideas

Various voting techniques may be used to prioritize the idea created

Although live brainstorming is preferred, Web-based brainstorming may be a viable alternative in some situations

⁄ 12 Các kỹ thuật phát hiện yêu câu phân mêm từ phía SN

Storyboards can be passive, active, or interactive

Storyboards identify the players, explain what happens

to them, and describe how it happens

Make the storyboard sketchy, easy to modify, and unshippable

Storyboard early and often on every project with new or innovative content

Passive storyboards tell a story to the user They can consist of

sketches, pictures, screen shots, PowerPoint presentations, or

sample outputs

Active storyboards try to make the user see "a movie that hasn't been produced yet." Active storyboards are animated or automated, perhaps by an automatically sequencing slide presentation or an animation tool or even a movie

Interactive storyboards let the user experience the system in as realistic a manner as practical They require participation by the user in order to execute Interactive storyboards can be simulations

or mock-ups or can be advanced to the point of throwaway code