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

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,