Use-cases là một kịch bản mà mô tả

Phần mềm thực hiện như thế nào khi được dùng trong một tình huống cho trước

Những công cụ CASE sẽ được dùng như thế nào để xây dựng hệ thống

Kế hoạch xây dựng cho sản phẩm phần mềm

Những test-case cho sản phẩm phần mềm

Trả lời:

Đáp án đúng: A

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.

500+ câu trắc nghiệm môn Công nghệ phần mềm có lời giải chi tiết - Phần 4

Tổng hợp 500+ câu hỏi trắc nghiệm môn Công nghệ phần mềm có đáp án đầy đủ nhằm giúp các bạn dễ dàng ôn tập lại toàn bộ các kiến thức.

50 câu hỏi 60 phút

Bắt đầu thi

Câu hỏi liên quan

Câu 46:

Xét đường độc lập cơ bản, nếu có 7 node phân nhánh thì ta có số đường thực thi cơ bản độc lập là

Lời giải:

Đáp án đúng: A

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.

Câu 47:

Độ đo mức độ bảo trì

Lời giải:

Đáp án đúng: A

Độ đ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ì.

Câu 48:

Mô hình phát triển phần mềm dựa trên mẫu thử (prototype) là

Lời giải:

Đáp án đúng: C

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.

Câu 49:

Ba giai đoạn tổng quát của công nghệ phần mềm

Lời giải:

Đáp án đúng: a

Giai đoạn tổng quát của công nghệ phần mềm thường được chia thành ba giai đoạn chính: Định nghĩa (Definition), Phát triển (Development) và Hỗ trợ (Support).

* Định nghĩa (Definition): Giai đoạn này tập trung vào việc xác định rõ yêu cầu của phần mềm, bao gồm những gì phần mềm cần làm, mục tiêu của dự án, và các ràng buộc liên quan.
* Phát triển (Development): Giai đoạn này bao gồm việc thiết kế, lập trình và kiểm thử phần mềm. Đây là giai đoạn mà phần mềm thực sự được xây dựng.
* Hỗ trợ (Support): Giai đoạn này bao gồm việc bảo trì, sửa lỗi và nâng cấp phần mềm sau khi nó đã được triển khai. Mục tiêu là đảm bảo phần mềm hoạt động ổn định và đáp ứng nhu cầu của người dùng.

Các lựa chọn khác không phản ánh chính xác các giai đoạn tổng quát của công nghệ phần mềm:

* "what, how, where" mô tả các khía cạnh của yêu cầu, nhưng không phải là giai đoạn tổng quát.
* "Programming, debugging, maintenance" chỉ là các hoạt động cụ thể trong giai đoạn phát triển và hỗ trợ.
* "Analysis, design, testing" cũng là các hoạt động cụ thể trong giai đoạn định nghĩa và phát triển.

Câu 50:

Những thành phần kiến trúc trong kỹ thuật sản phẩm là

Lời giải:

Đáp án đúng: A

Thành phần kiến trúc trong kỹ thuật sản phẩm bao gồm các yếu tố chính: dữ liệu (data), phần cứng (hardware), phần mềm (software) và các thủ tục (procedures) cần thiết để vận hành và quản lý hệ thống. Do đó, đáp án C là chính xác nhất.

Các lựa chọn khác không đầy đủ hoặc không chính xác vì:
- Lựa chọn A thiếu 'thủ tục'.
- Lựa chọn B thiếu 'thủ tục' và thay 'con người' bằng 'tài liệu' là không phù hợp.
- Lựa chọn D thiếu 'dữ liệu' và bao gồm 'con người' không phải là một thành phần kiến trúc trong kỹ thuật sản phẩm.

Câu 1:

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?

Lời giải: