Thông tin tài liệu
1
THI
THI
Ế
Ế
T K
T K
Ế
Ế
V
V
À
À
XÂY D
XÂY D
Ự
Ự
NG PH
NG PH
Ầ
Ầ
N M
N M
Ề
Ề
M
M
(SOFTWARE DESIGN AND CONSTRUCTION)
(SOFTWARE DESIGN AND CONSTRUCTION)
Năm
Năm
h
h
ọ
ọ
c
c
2008
2008
-
-
2009
2009
Giáo viên: PGS. Huỳnh QuyếtThắng
BM Công nghệ phầnmềm
Khoa CNTT, ĐHBK HN
22
Chương 1. Tổng hợpvàphântíchcácyêucầuphầnmềm
1. Các vấn đề và khái niệmtrongyêucầuphầnmềm
2. Phát hiệncácyêucầuphầnmềm (Software Elicitation)
3. Phân tích yêu cầuphầnmềm và xây dựng các đặc tính xác
định chấtlượng yêu cầu và các yêu cầukhác
4. Đặctả các yêu cầuphầnmềm
5. Xác định nguồngốcyêucầuvàma trận theo dõi các yêu
cầuphầnmềm
6. Thẩm định xác minh các yêu cầuphầnmềm (verification
requirement)
7. Quảnlýthayđổiyêucầuphầnmềm
3
1.4. Đặctả các yêu cầuphầnmềm
z Không phụ thuộccácyêucầuphầnmềm được
tìm ra, đượcxâydựng như thế nào, cuối cùng
bao giờ chúng ta cũng phải đặctả các yêu cầu
này.
z Các tiêu thức để đánh giá một đặctả: tính nhất
quán, tính thân thiện, dễ sử dụng
z Trong đặctả phải nêu đượccả business
requirement, phạmvi ứng dụng, giớihạncủa
ứng dụng
z Trong đặctả phải nêu được đầy đủ các user
requirement, sử dụng các mẫu (template) của
các trường hợpsử dụng củatừng yêu cầu.
4
1.4. Đặctả các yêu cầuphầnmềm
Các điểmlưuý khiđặctả yêu cầuphầnmềm (SRS):
(1) Làm theo và sử dụng các mẫu đặctả: nên quy định
mộtmẫu đặctả chung trong tổ chứccủa chúng ta,
sử dụng mộtsố mẫu (template) nào đó: IEEE 830 -
1998. Lưuý rằng hoàn toàn có quyềnsửđổi, quy
định lạicácbiểumẫunếunhưđiều đólàcầnthiết.
(2) Xác đinh rõ nguồngốccủayêucầuphầnmềm trong
đặctả: để có thể tấtcả biết đượctạisaolại phát sinh
các yêu cầuphầnmềm này, chúng ta nên chỉ rõ tại
saonólạicó-từ NSD, yêu cầuchứcnăng hệ thống,
do quy chế, hay do các nguồn khác.
5
1.4. Đặctả các yêu cầuphầnmềm
Các điểmlưuý khiđặctả yêu cầuphầnmềm (SRS):
(3) Đặt nhãn (label) cho từng yêu cầuphầnmềm: chúng
ta nên thống nhất quy ướccáchđặt nhãn (tên) cho
các yêu cầu - nên đặt nhãn làm sao nhãn củacác
yêu cầu mang càng nhiều các thông tin về các yêu
cầu đó càng tốt.
(4) Ghi lại các nguyên tắccủa công việc (business rule):
các nguyên lý hoạt động củahệ thống, của các thao
tác, công việccần đượcmiêutả.
6
1.4. Đặctả các yêu cầuphầnmềm
Các điểmlưuý khiđặctả yêu cầuphầnmềm (SRS):
(5) Nên tạorama trận theo dõi các yêu cầuphầnmềm
(requirements traceability matrix): điều này rấtcóích
trong quá trình phân tích các yêu cầu, quá trình thiết
kế, lập trình và kiểmthử các chứcnăng củahệ
thống. Ma trậnnàycũng rất có ích giúp cho chúng ta
liên kếtcácchứcnăng vớicácyêucầuphầnmềm
liên quan. Nên sử dụng thường xuyên ma trận trong
suốtthời gian phát triểnphầnmềm.
7
1.4.1. Ghi lại các nguyên tắccủa công việc (Record business
rule)
z Khi NSD miêu tả cho chúng ta mộthoạt động nào đó
chỉđượcthựchiện trong những diềukiệnnhất định, do
những tác nhân nhất định, v.v. tức là chúng ta đãcó
một nguyên tắc công việc
z Nguyên tăccôngviệclàtậphợp các các nguyên tăc
hoạt động của quá trình thựchiện công việc
z Chúng ta có nghĩ vụ phảixâydụng các yêu cầuhệ
thống về mặtchứcnăng để đáp ứng các nguyên tắc
công việc này - tuy nhiên không nền đồng nhấtyêucầu
chứcnăng với nguyên tắc công việc
z Trong SRS nên tậphợpvàđặctả tấtcả các nguyên tắc
của công việcvàomộtmục riêng.
8
1.4.2. Đặctả các yêu cầuphầnmềmtheomẫu
z Có thể nó đặctả yêu cầuphầnmềm (SRS) được
coi như: đặctả chứcnăng hệ thống, sự thoả thuận
về chứcnăng, đặctả hệ thống.
z SRS là cơ sở cho mọihoạt động củadự án: phân
tích, thiếtkế, lậpkế hoạch, viếtmã, kiểmthử, v.v.
z Khi đặctả yêu cầuphầnmềmcóthể sử dụng các
công cụ:
• Vănbản (textual document)
• Mô hình đồ hoạ (graphical models)
• Các ngôn ngữđặctả hình thức
z Các điểmlưuý:
• Tấtcả các yêu cầuphầnmềmphải được đua vào đặctả.
• SRS đượcxâydựng trước khi phân tích và xây dựng
phầnmềm
9
1.4.2. Đặctả các yêu cầuphầnmềmtheomẫu
1. Gán nhãn các yêu cầuphầnmềm (labeling)
Để có đượcmột đặctả tốt, có thể theo dõi mối liên
quan giữacácyêucầu, quá trình phát sinh ra
chúng, v.v. chúng ta cầncómột quy định gán
nhãn các yêu cầumột cách khoa học. Có mộtsố
phương pháp thông dụng:
• Gánnhãnliêntiếp (sequence number): UR - xxxx
• Gán nhãn theo thứ bậc (Hierarchical numbering):
UR 3.2.1 (phương pháp này đượcsủdụng rộng
rãi nhất)
• Gán nhãn theo tên thẻ thứ bậc (Hierarchical
texttual tags):Print.Copies.Confirm
10
1.4.2. Đặctả các yêu cầuphầnmềmtheomẫu
2. Đánh dấunhững điểmchưa rõ trong đặctả
Đôi khi chúng ta thiếumộtsố các thông tin về các
yêu cầuphầnmềm, chúng ta cầnthảoluậnvới
NSD để biếtchi tiếthơn, v.v. Tấtcả những chỗ
như vây nên được đánh dấubằng “To be
determined’ - TBD. Như vậy chúng ta đã phân
định rõ những điểmthiếu (gaps) trong đặctảđể
cầnlàsángtỏ.
Tấtcả các TBD này phải đượcgiải quyếttrước
khi bắt đầu quá trình phân tích và xây dựng phần
mềm.
[...]... và ma trận theo dõi các yêu cầu phần mềm Ma trận theo dõi các yêu cầu phần mềm (Requirements Traceability Matrix) Phương pháp hay được sử dụng nhất để liên kết các yêu cầu phần mềm và các thành phần khác của hệ thống là sử dung ma trận theo dõi các yêu cầu phần mềm Các liên kết này thường được thể hiện giữa các thành phần: • • • • • Các trường hợp sử dụng (yêu cầu phần mềm) Các yêu cầu chức năng (functional... chúng ta xây dựng các yêu cầu phần mềm Các giao diện xây dựng ở giai đoạn này chỉ mang tính chất định hướng 11 1.4.2 Đặc tả các yêu cầu phần mềm theo mẫu • • 3 Mối liên quan giữa đặc tả và giao diện người sử dụng (tiếp) Uu điểm: Có khả năng trau chuốt các yêu cầu phần mềm, xây dựng các tương tác trở nên hữu hìh và dễ hiểu hơn cho cả khách hàng và cả các PTV Trợ giúp tốt hơn cho việc lập kế hoạch và đánh... kết (6) Kiểm soát sự liên kết trong quá trình phá triển phần mềm 30 1.6 Thẩm định xác minh các yêu cầu phần mềm (Validating the Requirements) Mục đích của việc kiểm tra xác minh thẩm định các yêu cầu phần mềm về tính đúng dắn, tính hoàn thiện và chất lượng của các yêu cầu phần mềm Các yêu cầu phần mềm chúng ta miêu tả trong SRS phải đúng là những yêu cầu từ khách hàng, các yêu cầu giải quyết được những... requirement) Các thành phần thiết kế (design element) Mã chương trình (code) Trường hợp kiểm thử (test case) 26 1.5 Xác định nguồn gốc yêu cầu và ma trận theo dõi các yêu cầu phần mềm Ma trận theo dõi các yêu cầu phần mềm (Requirements Traceability Matrix) Các mội liên kết có thể được phân chia: • Một - Một • Một - Nhiều • Nhiều - Nhiều Các dạng biểu diễn ma trận: • Lập bảng liên kết • Lập ma trận liên kết... nguồn gốc yêu cầu và ma trận theo dõi các yêu cầu phần mềm Quá trình lập ma trận: (1) Xác định các mối liên kết và các khả năng lập ma trận (2) Chọn dạng ma trận: tổng hợp hay chi tiết (3) Chọn các chức năng/ các yêu cầu cần theo dõi (3) Xác định phương pháp gán nhãn các yêu cầu (4) Xác định nguồn các thông tin về các yêu cầu phục vụ cho sự liênkết (5) Thông báo cho những người tham gia về sự liên kết (6)... kết 27 1.5 Xác định nguồn gốc yêu cầu và ma trận theo dõi các yêu cầu phần mềm Functional Use case Requirement UC -0 1 Input.Form …… ……… Design Code Test Case element FormNL formNL.input() Input.01 ……… ……… ……… 28 1.5 Xác định nguồn gốc yêu cầu và ma trận theo dõi các yêu cầu phần mềm Use Case Functinal Requirement FR-01 FR-02 FR-03 FR-04 FR-05 UC-01 UC-02 UC-03 UC-04 UC-01 x x FormNL formNL.input()... ràng các tiêu thức đánh giá trong đặc tả 20 1.5 Xác định nguồn gốc yêu cầu và ma trận theo dõi các yêu cầu phần mềm Tracing Requirement: Theo dõi dấu vết của một yêu cầu phần mềm cho phép chúng ta quản lý được các yêu cầu phần mềm này, nguồn gốc của nó, các mối liên quan của nó và cách thực hiện, kiểm thử, bảo dưỡng và phát triển nó Tồn tại 04 thao tác với quá trình theo dõi dấu vết của một yêu cầu phần. ..1.4.2 Đặc tả các yêu cầu phần mềm theo mẫu 3 Mối liên quan giữa đặc tả và giao diện người sử dụng Sự kết hợp giữa thiết kế giao diện trong SRS có cả ưu điểm và nhược điểm: Nhược điểm: • • • • Các yêu cầu về giao diện thực chất chỉ là các giải pháp mà không phải là các yêu cầu phần mềm Quá trình xây dựng các yêu cầu sẽ kéo dài NSD, khách hàng có thể tốn rất nhiều... của các yêu cầu phần mềm này 31 1.6 Thẩm định xác minh các yêu cầu phần mềm (Validating the Requirements) Các thao tác thẩm định xác minh có thể bao gồm: • • Viết các trường hợp kiểm thử cho các yêu cầu: sử dụng mô hình hộp đen từ các trường hợp sử dụng để đánh giá hoạt dộng và hành vi của hệ thống Duyệt các hành vi và theo dõi các hoạt động để kiểm tra hệ thống đang đặc tả có đáp ứng các yêu cầu của... định xác minh các yêu cầu phần mềm (Validating the Requirements) Các thao tác thầm định xác minh có thể bao gồm (tiếp): • Định nghĩa các tiêu chuẩn chấp nhận: Hỏi NSD xem các tiêu thực ho đánh giá sản phầm phần mềm cần xây dựng theo những tiêu thức như thế nào để chúng ta có thể đưa những tiêu thức đó vào các trường hợp sử dụng của hệ thống 34 1.6 Thẩm định xác minh các yêu cầu phần mềm (Validating . nghệ phầnmềm Khoa CNTT, ĐHBK HN 22 Chương 1. Tổng hợpvàphântíchcácyêucầuphầnmềm 1. Các vấn đề và khái niệmtrongyêucầuphầnmềm 2. Phát hiệncácyêucầuphầnmềm (Software Elicitation) 3. Phân tích yêu cầuphầnmềm. tích yêu cầuphầnmềm và xây dựng các đặc tính xác định chấtlượng yêu cầu và các yêu cầukhác 4. Đặctả các yêu cầuphầnmềm 5. Xác định nguồngốcyêucầuvàma trận theo dõi các yêu cầuphầnmềm 6. Thẩm. định xác minh các yêu cầuphầnmềm (verification requirement) 7. Quảnlýthayđổiyêucầuphầnmềm 3 1.4. Đặctả các yêu cầuphầnmềm z Không phụ thuộccácyêucầuphầnmềm được tìm ra, đượcxâydựng như thế nào,
Ngày đăng: 02/04/2014, 05:20
Xem thêm: 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 ppt, 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 ppt, Chương 1. Tổng hợp và phân tích các yêu cầu phần mềm