1.1Nê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.

o   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.

o   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:

o   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.

o   Source traceability table: Xác định nguồn của từng yêu cầu.

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

o   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.

o   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.2Phâ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.3Kỹ 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.4Đá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.5Nê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.6Nê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:

a.      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)

b.      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).

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.7Cá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.8Cá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: