CÂU HỎI ÔN TẬP MÔN HOC IT4460 PHÂN TÍCH CÁC YÊU CẦU PHẦN MỀM

CHƯƠNG III. ĐẶC TẢ CÁC YÊU CẦU PHẦN M

ỀM

1.1

Nêu các yêu cầu của Đặc tả các yêu cầu phần mềm

Trả lời

ü

Gán nhãn các yêu cầu phần mềm

ü

Đánh dấu những điểm chưa rõ ràng trong đặc tả

ü

Mối  liên quan giữa đặc tả và giao diện người sử dụng

ü

Không phụ thuộc vào các yêu cầu được tìm được ra hay xây dựng như thế nào

ü

Trong đặc tả phải nêu được cả business requirement , phạm vi ứng dụng , giới hạn của ứng dụng.

ü

Trong đặc tả phải nêu được đầy đủ các user requirement, sử dụng mẫu (template) của các trường hợp sử dụng của từng yêu cầu.

ü

Thỏa mãn các tiêu thức đánh giá một đặc tả:  tính nhất quán, tính thân thiện, tính dễ sử dụng.

1.2

Nêu khái niệm và thành phần của đặc tả yêu cầu phần mềm

Trả lời:

Khái niệm:

Là hiểu biết hệ thống củ

a khách hàng

vào thời điểm thiết kế và phát triển phần mềm. Đó là hợp đồng đảm bảo về cả

khách hàng

và sự hiểu biết hệ thống,các nhu cầu khác trước khi ấn định thời điểm

.

-

Không phụ thuộc các yêu cầu phần mềm được tìm ra, được xây dựng như thế nào? Cuối cùng bao giờ chúng ta cũng phải đặc tả các yêu cầu này.

-

Các tiêu chí để đánh giá 1 đặc tả: tính nhất quán, tính thân thiện và tính dễ sử dụng.

-

Trong đặc tả yêu cầu phần mềm phải nêu được cả yêu cầu thương mại, phạm vi ứng dụng, giới hạn của ứng dụng.

-

Trong đặc tả phải nêu đầy đủ được các yêu cầu người sử dụng, sử dụng các mẫu(template) của các trường hợp sử dụng của từng yêu cầu

Thành phần :

·

Ghi lại các nguyên tắc công việc.

Khi người sử dụng miêu tả cho chúng ta một hoạt động nào đấy chỉ được thực hiện trong những điều kiện nhất định, do những tác nhân nhất định..tức là chúng ta đã có 1 nguyên tắc công việc.

·

Đặc tả các yêu cầu phần mềm theo mẫu.

Là đặc tả chức năng hệ thống, sự thỏa thuận về chức năng, đặc tả hệ thống.(SRS)

ü

Gán nhãn các yêu cầu phần mềm.

ü

Đánh dấu những điểm chưa rõ trong đặc tả.

ü

Mối liên quan giữa đặc tả vào giao diện người sử dụng.

1.3

Nêu tên các biểu mẫu của đặc tả yêu cầu phần mềm (theo IEEE và CMU)

Trả lời:

Giao diện

-Chức năng

-Cơ sở dữ liệu

-Bảo mật

-Chất lượng

-Hạn chế.

IEEE:

·

Giới thiệu

ü

Mục đích tài liệu

ü

Văn bản quy ước.

ü

Đối tượng dự kiến và góp ý.

ü

Phạm vi sản phẩm.

ü

Tài liệu tham khảo.

·

Mô tả chung

ü

Đặc điểm sản phẩm

ü

Chức năng sản phẩm

ü

Đặc điểm user

ü

Môi trường vận hành

ü

Thiết kế và ràng buộc

ü

Giả định và phụ thuộc

·

Yêu cầu về giao diện ngoài

ü

Giao diện người dùng

ü

Giao diện phần cứng

ü

Giao diện phần mềm

ü

Giao diện tương tác

·

Tính năng hệ thống

ü

Hệ thống tương lai

ü

Mô tả và ưu tiên

ü

Kích cầu/ thứ tự đáp ứng.

ü

Yêu cầu chức năng

·

Yêu cầu phi chức năng.

ü

Yêu cầu trình diễn

ü

Yêu cầu an toàn

ü

Yêu cầu bảo mật

ü

Yêu cầu chất lượng các thành phần phần mềm

ü

Nguyên tắc công việc

ü

Tài liệu người sử dụng

·

Các yêu cầu khác

ü

Thuật ngữ

ü

Mô hình phân tích

ü

Danh sách định dạng

CMU:

1.4

Trong cấu trúc của Đặc tả yêu cầu phần mềm (SRS) System Requirement và Software Requirement được hiểu khác nhau như thế nào và được đặc tả ở vị trí nào trong tài liệu SRS.

Trả lời:

a. Trong cấu trúc Đặc tả yêu cầu phần mềm ( SRS ) :

- System Requirement ( yêu cầu hệ thống ) : Nêu lên cấu hình hiện tại của cơ sở hạ tẩng thông tin của hệ thống sẽ được phát triển phần mềm như : Cấu hình hạ tầng mạng, hệ thống máy tính, các thiết bị ngoại vi đang có, …. và ảnh hưởng của chúng lên phần mềm sẽ xây dựng. Nó xác định cách mà phần mềm mới phải tương tác với hệ thống đã có và những ràng buộc quan trọng phải được quản lý cẩn thận.

- Software Requirement được hiểu là các yêu cầu về phần mềm bao gồm: các chức năng của phần mềm, hiệu năng của phần mềm, các yêu cầu về thiết kế và giao diện, các yêu cầu đặc biệt khác... do khách hàng đưa ra.

b. Trong tài liệu SRS System Requirement được đặt phía trước Software Requirement:

- System Requirement được đặc tả trong phần các yêu cầu chung nhất đối với hệ thống phần mềm sẽ phát triển.

- Software Requirement là phần chính của tài liệu SRS, bao gồm mô tả chi tiết yêu cầu đối với từng chức năng mà hệ thống cần phải đạt được , nó được đặc tả ở phần trung tâm của tài liệu SRS.

1.5

Nêu các kỹ thuật viết đặc tả yêu cầu phần mềm

Trả lời:

1.

Giả ngôn ngữ

Giả ngôn ngữ là một sự kết hợp giữa ngôn ngữ tự nhiên với những cú pháp chặt chẽ, những cấu trúc điều khiển của một ngôn ngữ lập trình để diễn giải thuật toán hay chương trình theo một cách dễ hiểu nhất.

2.

Máy trạng thái hữu hạn

Máy trạng thái hữu hạn (FSMS) rất phổ biến cho một số loại ứng dụng lập trình hệ thống, nhắn tin, chuyển đổi hệ thống, hệ điều hành và hệ thống điều khiển quá trình. FSMS là một cách để mô tả sự tương tác giữa người sử dụng nhân lực bên ngoài và hệ thống.

3.

Cây quyết định

Thường được sử dụng trong việc xem xét yêu cầu dựa trên sự kết hợp của các thông tin đầu vào, những sự kết hợp khác nhau của các thông tin đầu vào sẽ dẫn đến các hành vi khác nhau hoặc các kết quả khác nhau của các kết quả đầu ra. Việc xây dựng cây quyết định thường gắn với những câu lệnh điều kiện “if – then” lồng nhau.

4.

Biểu đồ hoạt động

Với việc sử dụng ngôn ngữ mô hình hóa UML, các đặc tả có thể được diễn giải thành các hình khối rất trực quan giúp cho người sử dụng có thể dễ dàng nắm bắt được nội dung của SRS.

5.

Mô hình thực thể liên kết

ERD cung cấp 1 kiến trúc cấp cao của dữ liệu, nó sẽ được tiếp tục tăng cường với các chi tiết thích hợp về các thông tin cần thiết để mô tả.

6.

Phân tích hướng đối tượng

Là một lối tư duy về vấn đề theo lối ánh xạ các thành phần trong bài toán vào cac đối tượng ngoài đời thực. Giúp người sử dụng dễ hiểu.

1.6

Phân tích vai trò của từng thành phần trong cấu trúc tài liệu yêu cầu phần mềm

Trả lời:

Cấu trúc tài liệu yêu cầu phần mềm: 11 thành phần

-

Introduction (Giới thiệu)

-

Glossary (từ điển thuật ngữ)

-

Use Cases (trường hợp sử dụng)

-

 Design Overview (thiết kế tổng quan)

-

 System Object Model (mô hình đối tượng hệ thống)

-

Object Descriptions (mô tả đối tượng)

-

Object Collaborations (đối tượng hợp tác)

-

 Data Design (thiết kế dữ liệu)

-

Dynamic Model (mô hình động)

-

Non-functional Requirements (yêu cầu phi chức năng)

-

Supplementary Documentation (tài liệu bổ sung)

1.

Introduction

: cho ta biết

-

Mục đích: 

·

Cung cấp một mô tả về các thiết kế của một hệ thống đầy đủ để cho phép phát triển phần mềm.

·

Cung cấp thông tin cần thiết để cung cấp mô tả chi tiết cho các phần mềm và hệ thống được xây dựng

-

Phạm vi: cho biết phạm vi của hệ thống

-

Các từ viết tắt,các định nghĩa: giúp tài liệu trở nên ngắn gọn hơn, người đọc dễ đọc, dễ hiểu hơn.

-

Sự tham khảo

-

Tổng quan: giúp người đọc có cái nhìn tổng quan về hệ thống cần xây dựng

2.

Glossary

:cung cấp các thuật ngữ và định nghĩa để sử dụng nội bộ của tài liệu

3.

Use Cases

: xác định được những ai sẽ sử dụng hệ thống, tác nhân kích hoạt, đại diện và quản trị hệ thống

4.

Design Overview

: đưa ra một tổng quan về thiết kế, cho nó vào một ngữ cảnh với các hệ thống bên ngoài. Cho phép người đọc và người sử dụng tài liệu định hướng cho bản thân để thiết kế và nhìn thấy một bản tóm tắt trước khi tiếp tục thiết kế các chi tiết.

5.

System Object Model

: cho phép mô tả các hệ thống một cách tổng thể, cho thấy các nhóm khác nhau của các phần vào các hệ thống tương ứng

6.

Object Descriptions

: mô tả các đối tượng trong tài liệu

7.

Object Collaborations

: mô tả mối quan hệ các đối tượng

8.

Data Design

: Sơ đồ thực thể liên kết: cho biết các liên kết giữa các đối tượng (1-1, 1-nhiều, nhiều-nhiều)

9.

Dynamic Model

:

-

Sơ đồ trình tự: cho thấy mức độ tổng quan về hình thức trình tự di chuyển từ dữ liệu và mẫu để có một tài liệu

-

Sơ đồ chỉnh sửa tài liệu: cho thấy mức độ tổng quan về trìn tự di chuyển từ một tài liệu ban đầu chưa sửa đổi cho một tài liệu sửa đổi

10.

Non-functional Requirements

: cung cấp các yêu cầu thực hiện (các yêu cầu phi chức năng)

11.

Supplementary Documentation

: có thể là tài liệu tham khảm, có thể là công cụ được sử dụng để tạo biểu đồ

1.7

Ý nghĩa của đặc tả hệ thống trong đặc tả yêu cầu phần mềm

Trả lời:

 ý

nghĩa của đặc tả hệ thống trong đặc tả yêu cầu phần mềm

Đặc tả hệ thống là đặc tả chức năng hệ thống: Định nghĩa các chức năng phần mềm mà người phát triển cần phải xây dựng để có thể đáp ứng được tất cả các nhiệm vụ đã miêu tả trong yêu cầu người sử dụng.

1.8

Các kỹ thuật đăc tả các yêu cầu chức năng trong đặc tả yêu cầu phần mêm. Phương pháp mã hóa các đặc tả chức năng và kiểm soát quan hệ  giữa các yêu cầu chức năng

Trả lời

Các kĩ thuật đặc tả yêu cầu chức năng.

Các phương pháp kỹ thuật để xác định các yêu cầu phù hợp với mô tả yêu cầu là quá phức tạp đối với ngôn ngữ tự nhiên.

1 số phương pháp kĩ thuật bao gồm:kỹ thuật mã giả,máy trạng thái hữu hạn,cây quyết định,sơ đồ hoạt động, mô hình thực thể-quan hệ, phân tích hướng đối tượng, và phân tích cấu trúc.

Bạn có thể chọn từ nhiều phương pháp đặc tả kỹ thuật:

1.Mã giả

2.Máy trạng thái hữu hạn.

3.Cây quyết định

4.Biểu đồ hoạt động

5.Mô hình thực thể quan hệ

6.Phân tích hướng đối tượng

7.Phân tích cấu trúc(Biểu đồ luồng dữ liệu)

1.Mã giả

Mã giả là một "chuẩn" lập trình ngôn ngữ,kết hợp các phi chính thức của ngôn ngữ tự nhiên với cú pháp chặt chẽ, cấu trúc điều khiển của một ngôn ngữ lập trình. Mã giả bao gồm sự kết hợp của:

Câu bắt buộc với một động từ duy nhất và một đối tượng duy nhất.

Thường không quá 40-50, các "hành động theo định hướng" động từ mà từ đó các câu phải được xây dựng

Quyết định đại diện có cấu trúc IF-ELSE-ENDIF

Lặp đi lặp lại các hoạt động biểu diễn với DO-WHILE hay cấu trúc FOR-NEXT

Hình 28-1 cho thấy một ví dụ về một đặc tả mã giả của thuật toán để tính doanh thu.

2.Máy trạng thái hữu hạn.

Trong một số trường hợp, đó là thuận tiện để mô tả mối quan hệ rời rạc của 1 nhóm các hệ thống. Trong phản ứng với một đầu vào, chẳng hạn như nhập dữ liệu từ người sử dụng hoặc nhập vào từ một thiết bị bên ngoài, máy tính này thay đổi trạng thái của nó và sau đó tạo ra sản phẩm hoặc thực hiện một hành động.

Thiết kế phần cứng đã sử dụng máy trạng thái hữu hạn (FSMS) trong nhiều thập niên.

Hình 28-2 minh họa chuyển trạng thái cho các hộp đèn

FSMS đang rất phổ biến cho một số loại ứng dụng lập trình hệ thống, chẳng hạn như nhắn tin, chuyển đổi hệ thống, hệ điều hành, và hệ thống điều khiển quá trình.

3.Cây quyết định.

Nó phổ biến để xem một yêu cầu với một sự kết hợp của các yếu tố đầu vào, kết hợp khác nhau của các yếu tố đầu vào dẫn đến các hành vi khác nhau hoặc kết quả đầu ra.

Hình 28-3 cho thấy một cây quyết định sử dụng để mô tả các trình tự khẩn cấp HOLIS.

4.Biểu đồ hoạt động.

Các hoạt động sơ đồ UML, có lợi thế là hiểu biết hợp lý: Ngay cả người không có đào tạo liên quan đến máy tính đều có thể hiểu được.

5.Mô hình thực thể-quan hệ

Nếu các yêu cầu trong thiết lập liên quan đến một mô tả về cấu trúc và các mối quan hệ giữa các dữ liệu trong hệ thống, nó thường thể hiện bằng sơ đồ thực thể-quan hệ (ERD). Hình 28-5 cho thấy một ERD điển hình.

Các ERD không chính xác tập trung vào các hành vi bên ngoài của hệ thống mà cho phép chúng ta  xác định những câu hỏi như "Có thể có nhiều hơn một địa chỉ thanh toán cho mỗi hoá đơn?" Trả lời: không có.

Mặc dù một ERD là một kỹ thuật mô hình hóa mạnh mẽ nhưng không phải là tất cả mọi người đều có thể hiểu được nó.

6.Mô hình hướng đối tượng.

Với sự phổ biến của OO và UML, các sơ đồ này được coi là nổi bật hơn cả trong số các kỹ thuật, trong các mô hình triển khai để thực hiện các chức năng của hệ thống.

Trong hình 28-6

7.Biểu đồ luồng dữ liệu

Ví dụ hình 28-7.

Biểu đồ luồng dữ liệu (DFD) các mô hình khá giống như mô hình ERD nhưng nó dễ hiểu hơn so với ERD.

1.9

Các kỹ thuật đăc tả các yêu cầu phi chức năng trong đặc tả yêu cầu phần mêm. Phương pháp mã hóa các đặc tả phi chức năng và kiểm soát quan hệ  giữa các yêu cầu phi chức năng

Trả lời:

Yêu cầu phi chức năng là các ràng buộc về các loại giải pháp thỏa mãn các yêu cầu chức năng. Các yêu cầu này mô tả về chính hệ thống, và về việc nó cần thực hiện các chức năng của mình tốt đến mức độ nào, chẳng hạn yêu cầu loại này là yêu cầu về tính sẵn có, khả năng kiểm thử, khả năng bảo trì, và tính dễ sử dụng. Có thể chia các yêu cầu phi chức năng thành hai loại:

ü

Ràng buộc về hiệu năng: chẳng hạn "hệ thống cần phục vụ liên tục từ 5 giờ sáng đến 9 giờ tối.", "mỗi đơn đặt hàng cần được lưu trữ trong tối thiểu 7 năm".

ü

Ràng buộc về quá trình phát triển hệ thống: thời gian, tài nguyên, chất lượng. Ví dụ: khi nào hệ thống cần hoàn thành (thời gian); tổng chi phí cho phát triển hệ thống (tài nguyên); cần áp dụng các tiêu chuẩn nào cho quá trình phát triển hệ thống, trong đó có các phương pháp quản lý dự án và phát triển hệ thống (chất lượng).

Các kỹ thuật chính:

ü

Làm rõ yêu cầu (Eliciting requirements): giao tiếp với khách hàng và người sử dụng để xác định các yêu cầu của họ.

ü

Xem xét yêu cầu (Analyzing requirements): xác định xem các yêu cầu được đặt ra có ở tình trạng không rõ ràng, không hoàn chỉnh, đa nghĩa, hoặc mâu thuẫn hay không, và giải quyết các vấn đề đó.

ü

Làm tài liệu yêu cầu (Recording requirements): các yêu cầu có thể được ghi lại theo nhiều hình thức, chẳng hạn các tài liệu ngôn ngữ tự nhiên, các tình huống sử dụng(use case), câu chuyện sử dụng(user story), hoặc các đặc tả tiến trình.

Làm rõ yêu cầu khách hàng có thể sử dụng một số kỹ thuật sau như:

ü

Các cuộc phỏng vấn

ü

Thành lập các nhóm trọng tâm (focus group) với các cuộc họp bàn về yêu cầu (requirements workshops)

ü

Tạo ra các danh sách yêu cầu

ü

Tạo nguyên mẫu(prototyping)

ü

Tạo tình huống sử dụng

1.10

Nêu các phương pháp đánh giá chất lượng tài liệu đặc tả yêu cầu phần mềm

Trả lời:

Tài liệuyêucầu:

ü

Chỉ mô tả về chức năng, ràng buộc

ü

Không mô tả về phương pháp cài đặt

ü

Phải dễ thay đổi (có cấu trúc)

ü

Khó xác định được đầy đủ chính xác ngay

ü

Phải qua nhiều bước xét duyệt lại

Các nguyên tắc chỉ đạo khi viết tài liệu đặc tả:

(1) Cố gắng viết các câu và đoạn văn ngắn gọn, không dài dòng

(2) Sử dụng các thuậtngữ dễ hiểu, đã có trong glossary

(3) Viết các câu văn trong sáng, đúng ngữ pháp

(4) Tránh sử dụng những từ mang tính chất quảng cáo: giao diện

thân thiện, hệ thống hoạt động hiệu quả, v.v một cách chung

chung mà cần chỉ rõ như thế nào là thân thiện, như thế nào

là hiệu quả

(5) Tránh sử dụng những tính từ so sánh: tốt hơn tốt nhất mà nên

chỉ ra rõ ràng các tiêu thức đánh giá trong đặc tả.

Chất lượng của hồ sơ đặc tả đánh giá qua các tiêu thức

ü

Tính rõ ràng, chính xác

ü

 Tính phù hợp

ü

Tính đầy đủ hoàn thiện

1.11

Phân tích vai trò của từng tác nhân trong xem xét và thông qua (phê duyệt) tài liệu đặc tả yêu cầu phần mềm

Trả lời:

Các tác nhân tham gia vào quá trình xem xét và thông qua (phê duyệt) tài liệu yêu cầu đặc tả phần mềm:

-

Các đại diện của người sử dụng (Product Champions): Thực hiện quá trình xác nhận các yêu cầu (Requirements Validation). Căn cứ vào tài liệu đặc tả và các yêu cầu thực tế của hệ thống, họ sẽ phải trả lời câu hỏi “Tôi có đang

mô tả đúng phần mềm

hay không?”.

Các tiêu chí để xác nhận gồm có:

Tính chính xác (Correct)

Tính khả thi (feasible)

Tính cần thiết (necessary)

Độ ưu tiên (prioritized) của các yêu cầu.

-

Các phân tích viên (Requirements Analysts): Thực hiện quá trình xác minh các yêu cầu (Requirements Verification). Căn cứ vào tài liệu đặc tả và các yêu cầu người dùng, họ sẽ phải trả lời cho câu hỏi “Tôi có đang

xây dựng phần mềm đúng

không?”. Các tiêu chí xác minh gồm:

Tính ngắn gọn, súc tích (concise)

Khả năng truy vết (traceable)

Không dư thừa (non-redundant)

Tổ chức tốt (organized)

Đúng quy chuẩn (conformant to standards)

Khả năng kiểm chứng (verifiable)

-

Ngoài ra còn có các thành viên của công ty phần mềm tham gia vào qua trình thực hiện phát triển phần mềm: Lập trình viên, các nhà kiểm thử…

1.12

Các chức năng của EA hỗ trợ mô hình hóa các yêu cầu phần mềm. Em đã sử dụng như thế nào trong BTL

Trả lời:

Mô hình hóa use case

Mô hình hóa  dữ liệu

Mô hình hóa nghiệp vụ

Requirements Modeling

Trong Enterprise Architect bạn có thể thu được hoặc thấy các yêu cầu một cách trực tiếp theo dạng mô hình, sử dụng thành phần Requirement cho phép từ bảng Requirements của Toolbox. Đây được coi là những yêu cầu bên ngoài. (Bảng Requirements đặt ở phía bên trái của giao diện EA trong Toolbox)

Sử dụng thành phần UML cho phép các yêu cầu được theo dõi đến các thành phần UML khác như là những yêu cầu khác, những use case, test case, và các thành phần phân tích hoặc thiết kế. Thành phần này có thể được sử dụng để mô hình hóa hoặc tài liệu hóa bất kì yêu cầu nào từ những yêu cầu dạng nghiệp vụ cho đến những yêu cầu về hiệu năng hoặc bảo mật. Những yêu cầu này có thể được thể hiện theo dạng sơ đồ với những quan hệ đi kèm( Hình 1). Những thông tin cốt lõi phía sau bất kì một yêu cầu nào cũng được định nghĩa trong phần properties (Hình 2) người dùng định nghĩa các “attributes” sử dụng Tagged Values và Profiles

Hình 1

Hình 2

Cách tạo External Requirement

·

Chuột trái vào ‘Custom Button’ trong ‘UML Toolbox’ để mở bảng custom

·

Click và kéo ‘Requirement’ từ bảng vào sơ đồ

·

EA cho phép bạn xác định vài thuộc tính của yêu cầu

Một trường ‘Short Description’ sẽ hiển thị trên sơ đồ

Nhìn ‘External Requirement Attributes’ bên dưới để rõ hơn

·

Click Ok để kết thúc

·

Những thuộc tính này có thể sử chữa lại sau này bằng cách double-click vào requirement

·

Một requirement mới được hiển thị trong ‘Project View’

Tên của requirement có thể đơn giản là dạng text hoặc được đánh số phía trước tên nhãn. EA hỗ trợ đánh số tự động các requirements (xem phần auto-naming elements bên dưới)

Các thuộc tính của External Requirement

Double-click vào các Requirement để gán các thuộc tính cho requirement. EA hỗ trợ các thuộc tính của Requirement như là status, difficulty, priority, and type. Ví dụ: xem hình 2 bên trên. Thay đổi chỉnh sửa dễ dàng

à

nhần OK để apply.

Những đặc trưng hữu ích cho External Requirement

Khi sử dụng external requirements, có một vài cách để thay đổi dữ liệu và cách nhìn các chi tiết.

Ví dụ:

·

Tạo những thuộc tính user-definable sử dụng tagged values

·

Viewing Requirement sử dụng Elements list view hoặc diagram view

·

Thiết lập những mối quan hệ giữa các yêu cầu, như quan hệ với các thành phần UML khác như use case, class, test case v.v

·

Những quan hệ dò vết giữa những yêu cầu và những thành phần khác.

·

Tạo một cây yêu cầu kế thừa sử dụng thành phần child hoặc packages.

Thêm Additional Attributes của Requirements

Thông thường có một chuỗi các thuộc tính yêu cầu được xác định cho một dự án nào đó. Bạn có thể nhập vào một số bất kì những thuộc tính thêm vào này như độ tin cậy, giá thành, độ trễ phạt thông qua việc sử dụng ‘tagged values’.

Tagged values có thể định nghĩa trên một one-off cơ bản cho vài thành phần hoặc được định nghĩa trức khi thêm vào trong việc tạo ra một thành phần mới.

Tagged values data cho một thành phần được cho phép như là một cửa sổ riêng biệt, để truy xuất sử dụng Ctrl + Shift + 6 ( hoặc từ Main menu View| Tagged Values). Ví dụ xem hình 3

Hình 3

Predefining Tagged Values Types for Requirements

Những thành phần trong EA, bao gồm những thành phần yêu cầu, có thể có một tập các thuộc tính mở rộng đã được định nghĩa cho một dự án. Các thuộc tính thành phần này có thể được định nghĩa trước sử dụng một UML profile hoặc EA Template. Ví dụ xem hình 4 một thành phần sử dụng tập tagged values predefined cho những yêu cầu của một dự án.

Hình 4

Những thuộc tính mở rộng này có thể thấy được trực tiếp trên sơ đồ. Để thiết lập chế độ này right-click vào diagram và trong menu context lựa chọn Properties| Elements| Show Compartments| [v] Tags. Ví dụ xem hình 5

Hình 5

Element Numbering

EA hỗ trợ việc tạo một cây phân cấp những thành phần dưới dạn package. Việc đánh số kết hợp với cấu trúc phân cấp cho phép các thành phần bên trong một Package được đánh số theo dạng 1.1.1. Những đặc trưng này có thể được thiết lập trên bất kì package nào và áp dụng cho những thành phần chứa trong root of package (không áp dụng cho child package)

Ví dụ Element hierarchy với Element Numbering

Hình 6

Để cho phép lựa chọn này

·

Select một package trong Project Browser

·

Right-click và từ menu context select: Show Level Numbering

Hình 7

Từ Project View, các thành phần được đánh số có thể được sắp xếp lại đơn giản bằng cách kéo một child element vào một element khác. Những elements con sẽ được đánh số lại để phù hợp với elements cha.

Hình 8

Different Views of Requirements Using the Element List View

Thông thường nhưng yêu cầu được định nghĩa bởi người dùng không giống với sơ đò UML. EA hỗ trợ một text-based view của những yêu cầu, trong khi vẫn duy trì cấu trúc phân cấp trong Project View.

Vài đặc trưng là:

·

The Project View. Cái này có thể gắn ở phía trái màn hình để hiển thị cây phân cấp.

·

The Element List View. Sơ đồ này có thể thiết lập về chế độ text view

Để thay đổi chế độ diagram view và Elements List View từ main menu, sleect View| Element List.

·

The Notes and Tagged Value windows có thể thiết lập là default view

Để xem the notes window select View| Notes

Để xem the tagged values window select View| Tagged Values.

Dưới đây là ví dụ của text-based mode

Hình 9

Bên dưới là ví dụ text-based với Tagged Value window và the Notes window được mở:

Hình 10

Việc mô hình hóa này còn một số phần nhưng nó dính sang phần ‘Traceability’ và ‘Change Control’ thuộc những câu khác nên các bạn tham khảo để chém thêm nhé.

1.13

Các chức năng của EA hỗ trợ xây dựng đặc tả yêu cầu phần mềm. Em đã sử dụng như thế nào trong BTL

Trả lời:

ü

Tạo ra các yêu cầu phần mềm bên ngoài (External

Requirements)

+

Tạo trong biểu đồ ( Diagram )

·

M

ở Custom pages trong

Enterprise Architect UML

Toolbox. Chọn Requirements

·

Cầm đối tượng Requirement, thả vào trong biểu đồ

·

Nhập tên và các thông tin khác cho Requirement. Save lại

+

Tạo trong gói ( Package)

·

Nháy phải vào gói, chọn Insert | New Element ( hoặc Ctrl + M )

·

Trong hộp thoại

New Element, chọn

Requirement

·

Nhập tên

và các thông tin khác cho Requirement. Save lại.

ü

Tạo ra các yêu cầu phần mềm bên trong một Element khác (Internal Requirements)

Ta có thể tạo ra các yêu cầu phần mềm bên trong 1 Element khác như Usecase, Class,… để chỉ ra rằng Element đó có nhiệm vụ cài đặt các yêu cầu đã nêu.

Để thực hiện việc này, ta thực hiện như sau:

·

Mở hộp thoại Properties của Element.

·

Chọn Tab Require

·

Nhập tên Requirement và các thuộc tính của nó.

·

Bấm Save để lưu Requirement lại

·

Nếu muốn, bấm New để tạo tiếp Internal Requirement khác cho Element, cũng hoặc thực hiện các thao tác quản lý khác ( sắp xếp, sửa, xóa )

·

Bấm OK để đóng hộp thoại

ü

Chuyển yêu cầu bên trong ra ngoài

·

M

ở

hộp thoại Properties của Element. Chọn Tab Require

·

Chọn Requirement cần chuyển. Bấm Move External

·

Trong hộp thoại mở ra, chọn package để lưu External Requirement

ü

Quản lý các thuộc tính cơ bản của yêu cầu:

Các thuộc tính cơ bản của yêu cầu được quản lý trong EA:

·

Tên

·

Trạng thái thực hiện (đề xuất, đã phê chuẩn, đang cài đặt, bắt buộc, đã kiểm tra)

·

Độ khó

·

Độ ưu tiên

·

Loại yêu cầu ( Chức năng, hiển thị, báo cáo, kiểm thử , …)

·

Ghi chú

·

Các thông tin khác

ü

Ghi chú các thông tin bổ sung

·

Sử dụng thuộc tính Note

·

Sử dụng đối tượng chú thích Note

·

Sử dụng Tagged Values (lựa chọn, mở cửa sổ Tagged Values, tạo ra các cặp Key – Value lưu trữ các thông tin bổ sung cho yêu cầu )

ü

Xóa, sắp xếp các yêu cầu

Thực hiện trong cửa sổ Project Browser, thông qua các button trên toolbox hoặc menu ngữ cảnh.

ü

Tạo cấu trúc phân cấp cho yêu cầu

Khi muốn chuyển 1 Requirement thành con của 1 Requirement khác, trong cửa sổ Project Browser, ta rê rồi thả Requirement-con vào Requirement-cha.

Với chức năng này, ta có thể xây dựng được cấu trúc phân cấp cho Requirement: 1 requirement lớn có thể bao gồm nhiều Reqiurement nhỏ hơn.

ü

Đánh số cho các Requirement:

Nháy phải vào package, chọn Show Level Numbering

ü

Kết xuất thành văn bản

·

L

ựa chọn Requ

ment cần kết xuất

·

Vào menu, chọn Project | Documentation

·

Lựa chọn loại báo cáo phù hợp ( Rich Text Format, HTML,…)

·

Trong hộp thoại mở ra, nhập các thông số cần thiết. Chú ý chọn Use template là requirement template

….

CHƯƠNG IV.  DUYỆT VÀ KIỂM SOÁT CÁC YÊU CẦU PHẦN MỀM

1.14

Phân biệt các khái niệm Kiểm thử và Đánh giá các yêu cầu phần mềm

Trả lời:

* Kiểm thử các yêu cầu phần mềm (Testing): Việc kiểm thử yêu cầu phần mềm nhằm xác định các yêu cầu có đáp ứng được các yêu cầu của người sử dụng không. Công việc được thực hiện như sau:

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 kiểm thử để đánh giá họat động 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 yêu cầu của người sử dụng hay không.

Quy trình kiểm thử:

•Business Requirement

•Use Case

•Functional Requirement

Các công cụ sử dụng:

•Dialog Map

•Test Case

•Ma trận theo dõi các trường hợp sửdụng

* Đánh giá các yêu cầu phần mềm

Khác với kiểm thử yêu cầu phần mềm là xem xét xem yêu cầu phần mềm có phù hợp với  yêu cầu người sử dụng hay không, việc đánh giá yêu cầu phần mềm lại dựa trên tính nhất quán, thân thiện, và dễ sử dụng của tài liệu đặc tả yêu cầu phần mềm.

Cụ thể việc đánh dựa vào các đặc điểm sau:

Các đặc điểm đối với từng yêu cầu phần mềm tốt.

a.

Đầy đủ ( complete )

b.

Chính xác (Correct)

c.

Khả thi ( feasible)

d.

Cần thiét ( necessary).)

e.

Xếp hạng tính quan trọng và ổn định (Ranked for importance and stability)

f.

Rõ ràng.

g.

Có thể kiểm tra được (Verifiable)

Các đặc điểm của một tài liệu đặc tả phần mềm tốt.

a.

Đầy đủ.

b.

Có thể sửa đổi (Modifiable)

c.

Có thể thể theo dõi được (Traceable)

d.

Thống nhất ( consistent)

(Có thể trả lời theo đặc tính chất lượng).

1.15

Tại sao cần kiểm thử đánh giá các yêu cầu phần mềm. Nêu tên một số phương pháp kiểm thử yêu cầu phần mềm thông dụng mà em biết.

Trả lời:

Việc kiểm thử đánh giá các yêu cầu phần mềm là cần thiết bởi vì qua việc kiểm thử đánh giá, chúng ta mới có thể thẩm định được tính đúng đắn, tính hoàn thiện và chất lượng của các yêu cầu phần mềm mà chúng ta đã miêu tả trong SRS. Các yêu cầu đó phải đúng là những yêu cầu từ khách hàng, giải quyết được các công việc của họ.

Một số phương pháp kiểm thử yêu cầu phần mềm thông dụng:

-

Kiểm thử hộp đen

-

Kiểm thử hộp trắng

1.16

Nêu các phương pháp xem xét lại yêu cầu phần mềm. Những tác nhân nào tham gia vào xem xét lại yêu cầu phần mềm

Trả lời:

Quy trình xem xét:

Lập kế hoạch

Các buổi họp mặt

Chuẩn bị

Các buổi họp duyệt

Làm sửa đổi

Kết thúc

·

Công cụ  sử dụng, mẫu sử dụng

Các tiêu thức đánh giá

Requirement Inspection Checklist

·

Các tác nhân tham gia vào quá trình duyệt các yêu cầu phần mềm (review):

Các PTV – Phát Triển Viên

Các đại diện của NSD (Product champions)

Tất cả các thành viên của Cty phần mềm sẽ tham gia vào quá trình thực hiện phần mềm: LTV, các nhà kiểm thử…

1.17

Phân tích các nguyên nhân dẫn tới thay đổi yêu cầu phần mềm

Tác động bên ngoài

ü

có thay đổi đòi hỏi chúng ta phải giải quyết bài toán mới

ü

người dùng thay đổi ý kiến của họ

ü

môi trường ngoài thay đổi

ü

một hệ thống mới tồn tại trong đó

Tác động bên trong

ü

Thất bại trong việc lấy yêu cầu từ người dùng ( chưa lấy đầy đủ yêu cầu từ nhiều người dùng)

ü

Thất bại trong việc tạo một quy trình thực hành giúp quản lý sự thay đổi yêu cầu phần mềm

1.18

Nêu vai trò phương pháp prototyping trong duyệt và kiểm soát yêu cầu phần mềm

Trả lời:

Vai trò:

Phương pháp Prototyping  có vai trò trong duyệt và kiểm soát yêu cầu phần mềm  giúp hoàn thiện hơn về yêu cầu, đáp ứng  được yêu cầu của người dùng

Cho người dùng dùng thử mẫu thử như là mẫu thử bản beta từ đó người dùng  sẽ dùng thử và đưa ra những điểm tốt , điểm không tốt của mẫu thử, cái nào không cần thiết của mẫu thử từ đó người phân tích viên có thể duyệt yêu cầu nào đã đạt được yêu cầu nào hay những yêu cầu nào rườm ra có thể bỏ qua hay nên bổ sung những yêu cầu gì để thỏa mãn được yêu cầu của người dùng

Ví dụ: khi cho người dùng delete một bản ghi thì đòi hỏi phải có yêu cầu là có nên delete hay không?

Mẫu thử cho thẩm định yêu cầu  giải thích các yêu cầu và giúp các bên liên quan khám phá được vấn đề

Thẩm định mẫu thử sẽ hoàn thành có hiệu quả cao và  thiết thực. nó có thể dụng chúng trong cách giống nhau như là yêu cầu hệ thống

Tài liệu đào tạo cho người sử dụng sẽ được cung cấp

1.19

Nêu kỹ thuật duyệt mô hình hệ thống của các yêu cầu phần mềm. Các nội dung cần duyệt trong đánh giá mô hình

Trả lời:

Thẩm định mô hình hệ thống là một yêu tố cần thiết trong quá trình thẩm định

Có thể kiểm tra với một số công cụ tự động

Những giải thích về mô hình là một kỹ thuật kiểm tra  có hiệu quả (kết quả)

Thành phần của mô hình hệ thống:

ü

Để giải thích mỗi mô hình là phù hợp

ü

Nếu có một vài mô hình của hệ thống để giải thích những sự phù hợp bên trong và bên ngoài.

ü

Để giải thích rằng các mô hình có tính chính xác với các yêu cầu thực của những bên liên quan đến hệ thống. đây là một việc rất khó khăn.

1.20

Vai trò của kiểm thử chấp nhận trong duyệt và kiểm soát các yêu cầu phần mềm

1.21

Các kỹ thuật kiểm thử chấp nhận trong duyệt và kiểm soát các yêu cầu phần mềm

Trả lời:

Các kỹ thuật kiểm thử chấp nhận:

-

Phát hiện lỗi: Các chương trình được thực hiện và kết quả là thứ cần kiểm tra. Nếu kết quả đúng, tiếp tục thực hiện bình thường. Một kiểm tra thất bại là triệu chứng của một lỗi. Kiểm thử chấp nhận hiệu quả nhất nếu nó được dựa trên các tiêu chí độc lập với chức năng đang được thử nghiệm và có thể tính toán một cách đơn giản để biết trước kết quả.

-

Chẩn đoán lỗi: Kiểm thử chấp nhận không dùng để xác định cái gì đã sai. Nó chỉ có thể nói rằng có cái gì đó đã sai

-

Ngăn chặn lỗi: Kiểm thử chấp nhận tạo ra rào cản không cho lỗi lan rộng.

-

Che giấu lỗi: Kiểm thử chấp nhận che giấu một giá trị xấu nếu kết quả thử lại hoặc thay thế chính xác trong thời gian quy định trước khi tuyên bố thất bại

-

Bồi thường lỗi: Nếu một chương trình thất bại trong kiểm thử chấp nhận có thể thay thế bằng một trường hợp dự phòng. Nếu trường hợp dự phòng thành công, có thể sử dụng đề bù đắp cho trường hợp ban đầu

-

Sửa lỗi:

-

------------------------------------------Nguồn------------------------------------------------------

-

4.3 Acceptance Test Techniques

-

The fault detection mechanism used influences the remainder of the fault tolerance activities (diagnosis, containment, masking, compensation, and recovery). The two common mechanisms for fault detection are acceptance tests and comparison.

-

4.3.1 Fault Detection

-

-

Acceptance tests are the more general fault detection mechanism in that they can be used even if the system is composed of a single (non-redundant) processor. The program or sub-program is executed and the result is subjected to a test. If the result passes the test, execution continues normally. A failed acceptance test is a symptom of a fault. An acceptance test is most effective if it is based on criteria that can be derived independently of the function being tested and can be calculated more simply that the function being tested (e.g., multiplication of a result by itself to verify the result of a square root function).

-

4.3.2 Fault Diagnosis

-

-

An acceptance test cannot generally be used to determine what has gone wrong. It can only tell that something has gone wrong.

-

4.3.3 Fault Containment

-

-

An acceptance test provides a barrier to the continued propagation of a fault. Further execution of the program being tested is not allowed until some form of retry successfully passes the acceptance test. If no alternatives pass the acceptance test, the subsystem fails, preferably silently. The silent failure of faulty components allows the rest of the system to continue in operation (where possible) without having to worry about erroneous output from the faulty component [Schlichting 83].

-

4.3.4 Fault Masking

-

-

An acceptance test successfully masks a bad value if a retry or alternate results in a new, correct result within the time limit set for declaring failure.

-

4.3.5 Fault Compensation

-

-

A program that fails an acceptance test can be replaced by an alternate, as described in the next section. If the alternate passes the acceptance test, its result may be used to compensate for the original result. Notice that the alternate program run during a retry may be a very simple one that just outputs a "safe" value to compensate for the faulty subsystem. A common approach in control systems is to "coast" the result by providing the value calculated from the last known good cycle.

-

4.3.6 Fault Repair

-

-

Acceptance tests are usually used in a construct known as a recovery block. A recovery block provides backward fault recovery by rolling program execution back to the state before the faulty function was executed. This repairs the faulty state and the result. When a result fails an acceptance test, the program can be executed again before leaving the recovery block. If the new result passes the acceptance test, it can be assumed that the fault originally detected was transient. If the software is suspect, an alternative can be executed in place of the original program fragment. If a single processor is used, the state of the processor must be reset to the beginning of the function in question. A mechanism called the recovery cache has been proposed to accomplish this [Anderson 76]. A recovery cache records the state of the processor at the entrance to each recovery block. Although a recovery cache is best implemented in hardware, implementations to date have been limited to experimental software. Where multiple processors are available, the retry may take the form of starting the program on a backup processor and shutting down the failed processor. Recovery blocks can be cascaded so that multiple alternatives can be tried when an alternate result also fails the acceptance test.

-

----------------------------------------------------------------------------------------------------------------

-

1.22

Các chức năng cơ bản của EA hỗ trợ người dùng trong duyệt và kiểm soát yêu cầu phần mềm. Em đã sử dụng như thế nào trong BTL

Trả lời:

EA hỗ trợ tính năng theo dõi thay đổi định nghĩa yêu cầu. Chúng bao gồm kiểm toán, quản lý đường cơ sở, yêu cầu thay đổi thành phần và vấn đề khai thác

Kiểm toán:

Các tính năng kiểm toán cho phép bạn ghi lại những thay đổi mô hình trong EA.

Nó ghi chi tiết của người thay đổi một yếu tố, khi nào và những gì đã được thay đổi, cùng với tình trạng trước của mô hình. Điều này có thể đặc biệt hữu ích để ghi lại lịch sử các thay đổi cho mô hình yêu cầu.

Để kích hoạt tính năng này:

1.

Từ menu chính bạn chọn:  View | Other  Project Tools | Audit View,sẽ mở ra:

2.

Bạn chọn Audit Settings

3.

Nó sẽ mở ra cửa sổ Audit Settings :

4.

Trong cửa sổ Audit Settings bạn thiết lập kích hoạt tính năng kiểm toán như hình vẽ trên.

Ví dụ dưới

đâ

y có

Element List

xem các tùy chọn thiết lập

.cửa sổ Output | Audit History

cho thấydanh sách các thay đổi cho các phần tử được lựa chọn

:

Nghe

Đọc ngữ âm

Từ điển -

Xem từ điển chi tiết

Lịch sử đầy những thay đổi có thể xem được bằng cách loại phần tử bằng cách sử dụng

Audit View:

Để biết thêm thông tin về cách sử dụng tính năng kiểm toán xem

trợ giúp của EA :Projects and

Teams | Change Management | Tracking Changes | Auditing

Sử dụng đường cơ sở:

Các tính năng kiểm toán nêu trên, cung cấp liên tục theo dõi và ghi các thay đổi yêu cầu

.

tính năng

Baseline Management 

hỗ trợ thêm để so sánh vàsáp nhập thay đổi. Nó cho phép đường cơ sở của một mô hình được tạo ra trên cơ sở định kỳ (nghĩa là theo tháng, phiên bản, giai đoạn hoặc xây dựng). Đường cơ sở đó có thể được so sánh với mô hình nhà nước hiện hành và thay đổi lựa chọn kết hợp.

Để biết thêm thông tin về thiết lập đường cơ sở và xem sự khác biệt xem phần trợ giúp:

Projects and Teams | Change Management | Tracking Changes | Package Baselines

Thay đổi yêu cầu và các vấn đề về yêu cầu ngoại

ea hỗ trợ đăng nhập của biến đổi, yêu cầu đối với yêu cầu. Điều này có thể được xác định

sử dụng hai phương pháp khác nhau:

-Dùng  Maintenance View  để thay đổi danh sách, khiếm khuyết, vấn đề và nhiệm vụ chống lại mỗi phần tử.

-Sử dụng các yếu tố tùy thuộc loại "Issue " và "Change " liên kết với các yêu cầu ngoài

được thay đổi.

Mỗi cái đã sử dụng khác nhau được liệt kê như sau:

a.Sử dụng các Xem Bảo trì:

có thể được sử dụng để đăng nhập thay đổi đối với bất cứ phần tử hoặc trọn gói. Điều này cung cấpdanh sách cho:

o Element khiếm khuyết

o Thay đổi Element

o Các vấn đề Element

o Element Nhiệm vụ

Chúng bao gồm các lĩnh vực để ghi âm "by whom and when " yêu cầu đã được thực hiện và hoàn thành, cũnglà trạng, mô tả, ưu tiên và lịch sử.

Maintenance View

có thể được truy cập từ trình đơn chính bằng cách sử dụng:View | Other Element Tools |Maintenance or (Alt+4)

.

Hình

sau đây

là một ví dụ của một tập hợp các thay đổi được liệt kê cho một phần tử

:

Việc sử dụng chung cho quản lý yêu cầu là để đăng nhập chi tiết Yêu cầu-vấn đề và thay đổi-Yêu cầu đối với bất kỳ yếu tố yêu cầu hiện có.

b)Sử dụng các yếu tố bảo trì cho Thay đổi và các vấn đề

các yếu tố bảo dưỡng

của EA

bao gồm các yếu tố của loại

  Issue và Change.

Đây là những truy cập từ

Toolbox | Maintenance hoặc Toolbox | Custom

Bảo trì các yếu tố có thể được liên kết bằng cách sử dụng một kết nối đến bất kỳ yếu tố (nghĩa là một yêu cầu đối ngoại) để hiển thị một sự thay đổi hay vấn đề một.

Nghe

Đọc ngữ âm

Từ điển -

Xem từ điển chi tiết

Lời khuyên:

-

Những yếu tố có thể được lưu trữ trong gói có chứa các yêu cầu liên quan hoặc trong mộtriêng gói có chứa một bộ các thay đổi.

-

Chúng có thể được liên kết với yêu cầu yếu tố trong biểu đồ thông thường hoặc bằng cách sử dụng các mối quan hệMa trận.

-

Những yếu tố có thể được tùy chỉnh như là một phần của một hồ sơ để bao gồm các đặc tính mở rộng.

Sơ đồ sau đây minh họa việc sử dụng một phần tử hành liên kết với một yêu cầu.

 Nghe

Đọc ngữ âm

Từ điển -

Xem từ điển chi tiết

Nghe

Đọc ngữ âm

Từ điển -

Xem từ điển chi tiết

Nghe

Đọc ngữ âm

Từ điển -

Xem từ điển chi tiết

Dưới đây là cùng một dữ liệu xem trong

Element List

xem cùng với

Relationship

cửa sổ hiển thị các yếu tố liên quan đến việc phát hành lựa chọn:

1.23

Kiểm thử (testing) yêu cầu phần mềm

Trả lời:

Kiểm thử yêu cầu phần mềm là công việc thực hiện lại sau khi có được các yêu cầu phần mềm từ phía NSD, chủ dự án…Qúa trình này là một quá trình cân nhắc về khả năng đáp ứng lại yêu cầu phần mềm do những hạn chế về nhân lực, thời gian và tài chính của đội ngũ phát triển phần mềm.

Quá trình kiểm thử phát hiện các yêu cầu phần mềm đi quá phạm vi và giới hạn của phần mềm, ảnh hưởng đến kiến trúc hệ thống.

Nhìn chung kiểm thử phần mềm là một quá trình kiểm tra các yêu cầu phần mềm, từ đó đưa ra những yêu cầu hợp lý và những phương án chấp nhận được, thỏa mãn cả hai bên là người sử dụng và người phát triển hệ thống.

Tại sao phải kiểm thử yêu cầu phần mềm:

-

Do tính chất 2 mặt của yêu cầu phần mềm: Cách nhìn và suy nghĩ về phần mềm từ phía người sử dụng và cách nhìn, suy nghĩ về phần mềm từ phía nhà phát triển.

-

Người sử dụng đưa ra những đòi hỏi quá cao hoặc chẳng liên quan đến quá trình phát triển phần mềm

-

NSD đưa ra các yêu cầu và đề nghị rất khó chấp nhận là gây khó khăn cho các lập trình viên

-

NSD đưa ra các yêu cầu nhập nhằng và mơ hồ, quá trình kiểm thử sẽ có trách nhiệm làm rõ các yêu cầu này.

-

Phát hiện các đặc tính thừa do người phát triển hệ thống đưa thêm vào hoặc các yêu cầu phụ phần mềm từ phía người sử dụng gây tốn kém và không cần thiết

-

Kiểm tra khả năng đáp ứng về mặt kỹ thuật

-

Đặc tả rõ ràng và chi tiết các yêu cầu

Tiêu chí kiểm thử yêu cầu phần mềm

-

Hoàn thiện

-

Chính xác

-

Khả thi

-

Cần thiết

-

Rõ ràng

-

Kiểm tra được, xác minh được

Quy trình kiểm thử yêu cầu phần mềm:

·

Bussiness Requirement

·

Use Case

·

Functional Requirement

Các công cụ sử dụng:

·

Dialog Map

·

Test Case

·

Ma trận theo dõi các trường hợp sử dụng

CHƯƠNG V. CÁC KỸ THUẬT NÂNG CAO CHẤT LƯỢNG YÊU CẦU PHẦN MỀM

1.24

Nêu các phương pháp theo dõi vết của yêu cầu phần mềm.

Trả lời:

·

Có 2 loại theo dõi vết: Tường minh và không tường minh.

Tường minh: Các mối quan hệ được thêm vào một cách tường minh bởi đội dự án. Ví dụ: Mối quan hệ giữa yêu cầu và các use case.

Không tường minh: Ví dụ mối quan hệ phân cấp giữa các yêu cầu với nhau. Yêu cầu cha có mối quan hệ không tường minh với các yêu cầu con.

·

Phương pháp: (từ sách SE – Pressman – p289)

Sau khi xác định yêu cầu, chúng ta lập các bảng theo dõi vết. Các bảng này cho phép chúng ta biết khi thay đổi một yêu cầu thì nó sẽ ảnh hưởng đến những nhân tố nào trong hệ thống sẽ xây dựng. Một số bảng theo dõi vết:

Features traceability table

: Cho biết mối quan hệ giữa yêu cầu và các tính năng mà khách hàng sẽ thấy được trong sản phẩm.

Source traceability table

:

Xác định nguồn của từng yêu cầu.

Dependency traceability table

:

Cho biết mối quan hệ giữa các yêu cầu với nhau.

Subsystem traceability table

:

Phân loại các yêu cầu theo các phân hệ mà nó có ảnh hưởng.

Interface traceability table

:

Cho biết mối quan hệ giữa yêu cầu và các giao diện của hệ thống (cả giao diện ngoài và giao diện trong).

1.25

Phân tích các thành phần trong ma trân vết yêu cầu phần mềm. Vai trò của ma trận trong theo dõi các thay đổi yêu cầu phần mềm

Trả lời:

Ma trận vết (theo dõi) yêu cầu phần mềm (Requirements Traceability Matrix - RTM)

Vai trò :

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 vết (theo dõi) các yêu cầu phần mềm.

Việc sử dụng các RTM tăng cường quá trình quản lý phạm vi. Nó cũng hỗ trợ việc kiểm soát quy trình và quản lý chất lượng. RTM cũng có thể được coi như là một quá trình ghi chép các kết nối và mối quan hệ giữa các yêu cầu ban đầu của dự án và sản phẩm cuối cùng, dịch vụ sản xuất.

Thành ph

ần :

Bao gồm các thành phần trong sơ đồ

Các liên kết này thường được thể hiện giữa các thành phần của ma tr

ậ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 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)

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

1.26

Kỹ thuật quản lý thay đổi yêu cầu phần mềm

Trả lời:

Tại sao các yêu cầu phần mềm  thay đổi?

-

Nhân tố ngoài: Vấn đề thay đổi, NSD thay đổi suy nghĩ, Môi trường thay đổi,….

-

Nhân tố trong: Chúng ta đã thất bại trong việc đặt đúng câu hỏi cho đúng đối tượng đúng thời điểm trong suốt quá trình thu thập yêu cầu ban đầu. Chúng ta thất bại trong việc tạo ra một quá trình thích hợp để trợ giúp cho việc quản lý các thay đổi tron yêu cầu phần mềm

Một tiến trình quản lý các thay đổi :

1.

Nhận thức được rằng, sự thay đổi trong yêu cầu phần mềm là không thể tránh khỏi và phải lên kế hoach cho nó

2.

Vạch ra các yêu cầu cơ sở.

3.

Thiết lập một kênh duy nhất để kiểm soát các thay  đổi.

4.

Sử dụng một hệ thống kiểm soát thay đổi để nắm bắt những thay đổi

5.

Quản lý thay đổi thứ bậc.

Quản lý cấu hình yêu cầu:

-

Ngăn cản các sự thay đổi trái phép và có khả năng phá hủy hoặc hư hại tới yêu cầu

-

Lưu giữ các phiên bản tài liệu của yêu cầu.

-

Tạo điều kiện cho việc thu hồi và/(hoặc) xây dựng lại các phiên bản tài liệu trước.

-

Hỗ trợ quản lý, tổ chức các chiến lược cơ bản để cải tiến cập nhật hệ thống.

-

Ngăn chặn việc cập nhật đồng thời các tài liệu hoặc các thông tin mẫu thuẫn nhau.

1.27

Đánh giá các yêu cầu phần mềm theo các thuộc tính chất lượng phần mềm

Trả lời:

Thuộc tính của các sản phẩm phần mềm là các đặc tính xuất hiện của sản phẩm một khi nó được cài đặt và được đưa ra dùng. Các thuộc tính này không bao gồm các dịch vụ được cung cấp kèm theo sản phẩm đó.

            VD: mức độ hiệu quả, độ bền, khả năng bảo trì, khả năng dùng ở nhiều nền…

Các thuộc tính biến đổi tùy thuộc phần mềm, tuy nhiên, có một số thuộc tính tối quan trọng sau:

1.

Khả năng bảo trì: có khả năng thực hiện những tiến triển để thỏa mãn yêu cầu của khách hàng.

2.

Khả năng tin cậy: bao gồm hàng loạt các đặc tính như độ tin cậy, độ an toàn, bảo mật…

Phần mềm tin cậy không thể tạo ra các thiệt hại vật chất hay kinh tế trong trường hợp hư hỏng.

3.

Độ hữu hiệu: phần mềm không thể phí phạm các nguồn tài nguyên như là bộ nhớ và các chu kỳ xử lý.

4.

Khả năng sử dụng: phần mềm nên có một giao diện tương đối dễ cho người sử dụng và có đầy đủ các hồ sơ về phần mềm.

Đánh giá các yêu cầu phần mềm theo các thuộc tính chất lượng phần mềm

ü

Tính chính xác của yêu cầu?

ü

Yêu cầu có bị lặp lại hay không?

ü

Tính hợp lý của yêu cầu?

1.28

Nêu phương pháp theo dõi các yêu cầu phần mềm và đảm bảo các yêu cầu phần mềm

Trả lời:

1.29

Nêu các phương pháp đo đánh giá yêu cầu phần mềm

Trả lời :

* Đánh giá các yêu cầu phần mềm

Khác với kiểm thử yêu cầu phần mềm là xem xét xem yêu cầu phần mềm có phù hợp với  yêu cầu người sử dụng hay không, việc đánh giá yêu cầu phần mềm lại dựa trên tính nhất quán, thân thiện, và dễ sử dụng của tài liệu đặc tả yêu cầu phần mềm.

Cụ thể việc đánh dựa vào các đặc điểm sau:

Các đặc điểm đối với từng yêu cầu phần mềm tốt.

h.

Đầy đủ ( complete )

i.

Chính xác (Correct)

j.

Khả thi ( feasible)

k.

Cần thiét ( necessary).)

l.

Xếp hạng tính quan trọng và ổn định (Ranked for importance and stability)

m.

Rõ ràng.

n.

Có thể kiểm tra được (Verifiable)

Các đặc điểm của một tài liệu đặc tả phần mềm tốt.

e.

Đầy đủ.

f.

Có thể sửa đổi (Modifiable)

g.

Có thể thể theo dõi được (Traceable)

h.

Thống nhất ( consistent)

(Có thể trả lời theo đặc tính chất lượng).

Theo mình nghĩ phương pháp đo đánh giá yêu cầu phần mềm đó là làm đặc tả yêu cầu phần mềm tốt.

Các phương pháp đặc tả yêu cầu là

·

Pseudocode (Giả ngôn ngữ)

·

Finite state machines (máy trạng thái hữu hạn)

·

Decision trees (Cây quyết định)

·

Activity diagrams (flowcharts) (Biểu đồ hoạt động)

·

Entity relationship models (Mô hình thực thể quan hệ)

·

Object-oriented analysis (Phân tích hướng đối tượng)

·

Structured analysis (Phân tích hướng cấu trúc)

Đo chất lượng cho mô hình Use Case

Đo chất lượng cho gói SRS

Đo chất lượng dựa vào đánh giá các thuộc tính chất lượng yêu cầu phần mềm

1.30

Các chức năng của EA trợ giúp trong theo dõi yêu cầu phần mềm

Trả lời:

Lập ma trận theo dõi yêu cầu phần mềm

-

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ử dụng 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 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)

-

Các mối liên kết co 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

Quá trình lập ma trận:

-

Xác định các mối liên kết và các khả nang lập ma trận

-

Chọn dạng ma trận: tổng hợp hay chi tiết

-

Chọn các chức năng/ các yêu cầu cần theo dõi

-

Xác định phương pháp gán nhãn các yêu cầu

-

Xác định nguồn các thông tin về các yêu cầu phục vụ cho sự liên kết

-

Thông báo cho những người tham gia về sự liên kết

-

Kiểm soát sự liên kết trong quá trình phát triển phần mềm.

Sử dụng ma trận quan hệ (Relationship Matrix): thông qua cửa sổ Relationship Matrix. Cho biết quan hệ giữa các đối tượng trong 2 package

1.31

Các chức năng của EA trợ giúp trong quản lý thay đổi yêu cầu phần mềm

Trả lời:

a.

Auditing

Chức năng Audit cho phép bạn ghi lại những thay đổi mô hình trong EA. Nó ghi chi tiết những ai thay đổi một thành phần, khi nào và những gì được thay đổi, cùng với trạng thái trước của mô hình. Điều này có thể đặc biệt hữu dụng cho việc ghi lại lịch sử thay đổi của những mô hình yêu cầu.

Để cho phép chức năng này:

1.

Từ menu chính chọn:

View | Audit View

, để mở

2.

Chọn nút

Audit Settings

3.

Ta được cửa sổ

Audit Settings

:

4.

Trong cửa sổ

Audit Settings

check vào

enable Auditing

như hình trên.

Chọn

Ouput | Audit History

cửa sổ sẽ hiển thị danh sách những thay đổi cho thành phần đã chọn

Lịch sử đầy đủ của sự thay đổi được hiển thị bởi loại nhân tố sử dụng Audit View.

Để biết thêm thông tin về việc sử dụng chức năng Auditing xem trợ giúp của EA:

Help | Help Contents | Model Management | Auditing

b.

Using Baselines

Chức năng auditing nêu trên, cung cấp theo dõi liên tục và ghi các thay đổi của yêu cầu. chức năng Baseline Management cung cấp hỗ trợ thêm cho so sánh và kết nối các thay đổi. Nó cho phép đường cơ sở của một mô hình được tạo ra trên cơ sở định kì ( ví dụ theo tháng, giai đoạn, phiên bản hoặc xây dựng. Baseline có thể được so sánh với mô hình trạng thái hiện tại và thay đổi kết hợp chọn lọc.

Để biết thêm thông tin về thiết lập baseline và xem sự khác biệt, xem phần trợ giúp:

Help | Help Contents | Model Management | Baselines, Diffirencing and Merges

c.

Change Requests and Issues on External Requirements

EA hỗ trợ việc ghi nhận những yêu cầu thay đổi dựa theo những yêu cầu. Nó có thể được định nghĩa sử dụng hai phương thức khác nhau:

-

Sử dụng Maintenance View để liệt kê những thay đổi, khiếm khuyết, vấn đề và nhiệm vụ dựa theo mỗi nhân tố.

-

Sử dụng những nhân tố tự chọn của kiểu “Issue” và “Change” liên kết với các yêu cầu ngoài được thay đổi

Mỗi một cách sử dụng khác nhau được liệt kê như sau:

Using the Maintenance View

Maintenance View có thể được sử dụng để ghi nhận những thay đổi dựa theo bất kì nhân tố hay gói nào. Nó cung cấp danh sách cho:

·

Yếu tố khiếm khuyết

·

Yếu tố thay đổi

·

Yếu tố vấn đề

·

Yếu tố nhiệm vụ

Chúng bao gồm các lĩnh vực để ghi “ bởi người nào và khi nào” yêu cầu đã được hoàn thành, cũng như tình trạng, mức độ, miêu tả và lịch sử.

Maintenance View có thể được truy cập từ menu chính sử dụng:

View | Maintenance or (Alt+4)

Việc sử dụng chung cho quản lí yêu cầu là để ghi nhận chi tiết các vấn đề yêu cầu và những yêu cầu thay đổi theo bất kì nhân tố yêu cầu nào tồn tại.

Using Maintenance Elements for Changes and Issues

Những nhân tố bảo trì của EA gồm những nhân tố loại: Issue và Change. Có thể truy cập từ Toolbox | Custom

Những nhân tố bảo trì có thể được liên kết bằng cách sử dụng một kết nối tới bất kì nhân tố nào (ví dụ một yêu cầu ngoài) để hiển thị một thay đổi hay một vấn đề.

-

Những nhân tố đó được lưu trữ trong gói chứa các yêu cầu liên quan hoặc trong một gói riêng biệt chứa một tập những sự thay đổi.

-

Chúng có thể được liên kết tới những nhân tố yêu cầu trong biểu đồ thông thường hoặc sử dụng ma trận quan hệ.

-

Những nhân tố có thể được tùy chỉnh như là một phần của một hồ sơ để bao gồm các đặc tính mở rộng.

Biểu đồ dưới đây minh họa việc sử dụng một nhân tố Issue được liên kết với một yêu cầu

Dưới đây là cùng một dữ liệu được hiển thị trong Element List cùng với các cửa sổ quan hệ hiển thị những nhân tố liên quan tới những vấn đề đã chọn:

Nội dung các

bài tiểu luận

Bài tập 1. Các kỹ thuật phát hiện và tổng hợp các yêu cầu phần mềm

Bài tập 2. Các kỹ thuật phân tích các yêu cầu phần mềm.

Bài tập 3. Xây dựng tài liệu đặc tả yêu cầu phần mềm

Bài tập 4. Các kỹ thuật duyệt và kiểm soát yêu cầu phần mềm

Bài tập 5. Các kỹ thuật truy hồi và đánh giá chất lượng yêu cầu phần mềm.