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
Trang 2đ 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)
Trang 3đ 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
Trang 4
tay Phân tích bài toán (vẫn dé) >
[Dean Leffingwell]
Problem analysis is the process of understanding real-world problems and users needs and proposing solutions to meet those needs
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
Trang 5
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
\ solution ,
Trang 6
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
i benefits -/
Trang 7
tay Phân tích bài toán (vẫn dé) >
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
Trang 8
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?
LO Is there anyone else? 7
Trang 9
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
\ system? J)
Trang 10
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
Trang 11
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
Trang 12phần mêm ⁄ 122 Xây dựng khả năng (vision) và phạm vỉ (scope) của SN Khả năng và phạm vi của phần mềm tập hợp các yêu cầu phần mềm ở mức độ cao (business 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:
Trang 13
⁄ 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
Trang 14⁄ 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
Trang 15⁄ 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
` 15 /
Trang 16
⁄ 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
Mô tả các rủi ro của công việc khi phát triên phân mém
Trang 17
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 ` hiên trong phần mềm
Danh sách các đặc điểm chính của phần mềm Các đặc
đ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
Trang 18
⁄ 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
Trang 19⁄ 122 Xây dựng khả năng (vision) và phạm vỉ (scope) của SN phần mêm 4 Ngữ cảnh công viéc (business context) 4.1 Tiêu sử khách hàng Các đặc điễm của khách hàng: Phân loại khách hàng 4.2 Các trong sô dự án
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
Trang 20(123 Xác định các nhóm người sử dụng và đặc tính của SN họ và đại diện tiêu biêu cho mỗi nhóm (1) Phân lớp người sử dụng phân mêm (user classes)
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)
Trang 211.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
Trang 22
⁄ 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
Trang 23
⁄ 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
Trang 24⁄ 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
Phát hiện các yêu cầu phân mềm là một công
việc phức tạp
Đây chính là cầu nỗi đề giải quyết bài toán Đây chính là câu nồi giữa PTV và NSD
Đòi hỏi rất nhiêu nỗ lực và các phẩm chất của
PTV
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
` /
Trang 25.2.4 Phần tích và xác định các yêu cầu phần mềm dựa 1 ⁄ ta các đại điện của các nhóm NSD ¬ `
Use-case: Thể hiện tập hợp các tương tác
Trang 27⁄ 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
Trang 29
⁄ 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
Trang 30
⁄ 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?
Trang 31
⁄ 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
Trang 32⁄ 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
The requirements workshop Is perhaps the most powerful technique for eliciting requirements
It gathers all key stakeholders together for a short but intensely focused period
The use of an outside facilitator experienced in
Trang 33⁄ 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
` 33 /
Trang 34⁄ 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
Trang 35⁄ 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 4 Storyboarding The purpose of storyboarding is to elicit early "Yes, But" reactions
Storyboards can be passive, active, or interactive
Storyboards identify the players, explain what happens to them, and describe how it happens
Trang 36⁄ 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 4 Storyboarding Types of Storyboards
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
Trang 37⁄ 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
5 Applying Use Cases
Use cases, like storyboards, identify the who, what, and how of system behavior
Use cases describe the interactions between a user and
a system, focusing on what the system "does" for the
user
The use-case model describes the totality of the system's functional behavior
Trang 38
⁄ 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
6 Prototyping
Prototyping is especially effective in addressing the "Yes, But" and "Undiscovered Ruins" syndromes
A software requirements prototype is a_ partial implementation of a software system, built to help developers, users, and customers better understand system requirements
Prototype the "fuzzy" requirements: those that, although known or implied, are poorly defined and _ poorly understood
` /