Tác vụ nào không được biểu diễn như là một phần của phân tích yêu cầu phần mềm

Đường Critical path (đường găng) trong biểu diễn lịch biểu dự án là đường có thời gian dài nhất. Đường găng xác định thời gian hoàn thành dự án tối thiểu, vì bất kỳ sự chậm trễ nào trên đường này sẽ ảnh hưởng đến toàn bộ dự án.

• Phương án A: Sai. Critical path không nhất thiết là đường duy nhất, có thể có nhiều đường găng.
• Phương án B: Sai. Critical path có thời gian dài nhất, không phải ngắn nhất.
• Phương án C: Đúng. Critical path là đường có thời gian dài nhất.
• Phương án D: Sai. Critical path luôn là đường dài nhất, không phụ thuộc vào dự án.

Use-case (ca sử dụng) mô tả cách người dùng tương tác với hệ thống phần mềm để đạt được một mục tiêu cụ thể. Nó tập trung vào hành vi của hệ thống từ quan điểm của người dùng cuối, mô tả các bước mà người dùng thực hiện và cách hệ thống phản hồi.

Phương án A chính xác vì nó mô tả use-case như một kịch bản về cách phần mềm hoạt động trong một tình huống cụ thể từ góc độ người dùng. Các phương án còn lại không chính xác vì:

• B: Use-case không liên quan trực tiếp đến công cụ CASE.
• C: Use-case không phải là kế hoạch xây dựng phần mềm mà là mô tả yêu cầu.
• D: Use-case có thể được sử dụng để tạo test-case, nhưng bản thân nó không phải là test-case.

Số đường thực thi cơ bản độc lập trong một đồ thị luồng điều khiển được tính bằng công thức: V(G) = E - N + 2P, trong đó: E là số cạnh, N là số nút, P là số thành phần liên thông. Trong trường hợp đường độc lập cơ bản, số đường thực thi cơ bản độc lập cũng có thể được tính bằng số lượng vùng kín trong đồ thị + 1. Tuy nhiên, câu hỏi này đề cập đến 'node phân nhánh'. Trong cấu trúc của một chương trình, số lượng đường đi độc lập cơ bản thường liên quan đến số lượng node quyết định (ví dụ: if, switch, while, for). Mỗi node quyết định (node phân nhánh) có thể tạo ra một đường đi độc lập. Do đó, nếu có 7 node phân nhánh, ta có thể suy ra có 7 + 1 = 8 đường thực thi cơ bản độc lập.

Độ đo mức độ bảo trì là một chỉ số đánh giá hiệu quả của quá trình bảo trì. Các lựa chọn đều có thể là các độ đo mức độ bảo trì khác nhau, tùy thuộc vào mục tiêu đánh giá cụ thể:

• A. Số vấn đề giải quyết trong tháng / tổng số vấn đề phát sinh trong tháng: Đo lường khả năng giải quyết các vấn đề phát sinh một cách nhanh chóng và hiệu quả.
• B. Số lần bảo trì vượt quá tiêu chuẩn thời gian / tổng số lần bảo trì: Đánh giá khả năng tuân thủ thời gian bảo trì tiêu chuẩn.
• C. Số lần bảo trì sai sót / tổng số lần bảo trì: Đo lường chất lượng của quá trình bảo trì, thể hiện số lượng các sai sót xảy ra.
• D. Thời gian trung bình của một lần bảo trì: Đo lường hiệu quả thời gian của mỗi lần bảo trì.

Như vậy, tất cả các đáp án đều có thể được sử dụng để đo lường mức độ bảo trì, tùy thuộc vào khía cạnh bảo trì nào cần được đánh giá. Tuy nhiên, đáp án C. Số lần bảo trì sai sót /tổng số lần bảo trì thể hiện trực tiếp và quan trọng nhất chất lượng của quá trình bảo trì, vì nó cho biết tần suất xảy ra lỗi trong quá trình bảo trì.

Mô hình phát triển phần mềm dựa trên mẫu thử (prototype) được sử dụng khi yêu cầu của khách hàng chưa rõ ràng. Khi đó, việc xây dựng một bản mẫu (prototype) giúp khách hàng hình dung rõ hơn về sản phẩm cuối cùng, từ đó đưa ra các yêu cầu cụ thể và chính xác hơn.

A. Sai. Mô hình prototype không phù hợp khi các yêu cầu đã được xác định rõ ràng, vì nó sẽ gây lãng phí thời gian và nguồn lực. B. Sai. Số lượng thành viên trong dự án không phải là yếu tố quyết định việc sử dụng mô hình prototype. C. Đúng. Khi khách hàng không thể xác định yêu cầu một cách rõ ràng, mô hình prototype là một phương pháp hữu ích để khám phá và làm rõ các yêu cầu. D. Sai. Mô hình prototype không phải là một mô hình rủi ro nếu được quản lý đúng cách. Nó có thể giúp giảm thiểu rủi ro bằng cách phát hiện và giải quyết các vấn đề sớm trong quá trình phát triển.