Trong chất lượng thiết kế phần mềm, độ đo "sự kết dính" là gì?

Độ đo về tính khớp lại với nhau của các phần trong mô đun đó

Độ ghép nối với nhau giữa các đơn vị hay mô đun của hệ thống

Các phần tử trong mô đun được ghép lại trong một dãy điều khiển

Các thành phần cùng thực hiện các chức năng tương tự đặt vào một mô đun

Trả lời:

Đáp án đúng: A

Độ kết dính (cohesion) là một độ đo trong chất lượng thiết kế phần mềm, đánh giá mức độ liên quan chức năng của các phần tử bên trong một mô-đun. Một mô-đun có độ kết dính cao khi các phần tử của nó liên quan chặt chẽ với nhau và cùng hướng tới một mục tiêu chung. Điều này giúp cho mô-đun dễ hiểu, dễ bảo trì và tái sử dụng. Các phương án khác không mô tả chính xác khái niệm độ kết dính. * **Phương án 1** chính xác nhất: "Độ đo về tính khớp lại với nhau của các phần trong mô đun đó". * **Phương án 2** mô tả "coupling" (độ liên kết), không phải "cohesion". * **Phương án 3** và **4** là các ví dụ cụ thể về các loại kết dính (ví dụ: kết dính tuần tự, kết dính chức năng), nhưng không phải là định nghĩa chung nhất về kết dính.

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 6

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

Loại kiểm thử nào được tiến hành bởi một nhóm nhỏ người sử dụng dưới sự hướng dẫn của người phát triển, thẩm định tính dùng được của hệ thống?"

Lời giải:

Đáp án đúng: A

Kiểm thử alpha là loại kiểm thử được thực hiện bởi một nhóm nhỏ người dùng nội bộ (ví dụ: nhân viên công ty phát triển phần mềm) trong môi trường được kiểm soát, thường là dưới sự hướng dẫn trực tiếp của các nhà phát triển hoặc nhóm kiểm thử. Mục đích chính của kiểm thử alpha là xác định các lỗi, vấn đề về tính khả dụng và thu thập phản hồi ban đầu trước khi phát hành phần mềm cho một lượng lớn người dùng. Trong trường hợp này, câu hỏi mô tả đúng tình huống của kiểm thử alpha, khi một nhóm nhỏ người sử dụng làm việc dưới sự hướng dẫn của người phát triển để thẩm định tính dùng được của hệ thống.

Kiểm thử beta được thực hiện bởi một nhóm lớn hơn người dùng cuối bên ngoài tổ chức phát triển, trong một môi trường thực tế. Kiểm thử thống kê không phải là một loại kiểm thử phần mềm cụ thể.

Kiểm thử khiếm khuyết không phải là một thuật ngữ kiểm thử tiêu chuẩn.

Câu 22:

Yêu cầu có thể chia ra thành các lọai nào sau đây?

Lời giải:

Đáp án đúng: B

Yêu cầu phần mềm được phân loại thành nhiều loại khác nhau, trong đó ba loại chính là:

* Yêu cầu chức năng (Functional requirements): Mô tả những gì hệ thống *phải làm*, các chức năng cụ thể mà hệ thống cung cấp cho người dùng.
* Yêu cầu phi chức năng (Non-functional requirements): Mô tả *cách* hệ thống thực hiện các chức năng, liên quan đến các thuộc tính như hiệu suất, bảo mật, độ tin cậy, khả năng sử dụng.
* Yêu cầu miền ứng dụng (Domain requirements): Mô tả các yêu cầu đặc thù xuất phát từ lĩnh vực ứng dụng của phần mềm, phản ánh kiến thức và quy tắc của lĩnh vực đó.

Đáp án 1: 'Chức năng, phi chức năng, yêu cầu hệ thống' - Yêu cầu hệ thống là một khái niệm rộng và có thể bao gồm cả yêu cầu chức năng và phi chức năng, không phải là một phân loại riêng biệt tương đương với hai loại kia.
Đáp án 2: 'Chức năng, phi chức năng' - Thiếu yêu cầu miền ứng dụng.
Đáp án 4: 'Chức năng, phi chức năng, yêu cầu nghiệp vụ' - Yêu cầu nghiệp vụ thường được xem xét trong giai đoạn phân tích nghiệp vụ ban đầu, và có thể được chuyển thành các yêu cầu chức năng và phi chức năng, hoặc yêu cầu miền ứng dụng, tùy thuộc vào tính chất của chúng.

Do đó, đáp án đúng nhất là đáp án 3: 'Chức năng, phi chức năng, yêu cầu miền ứng dụng'.

Câu 23:

Mục nào sau đây không bao gồm trong tài liệu SRS?

Lời giải:

Đáp án đúng: D

Tài liệu SRS (Software Requirements Specification) là tài liệu đặc tả các yêu cầu của phần mềm, bao gồm các yêu cầu chức năng (functional requirements), các yêu cầu phi chức năng (non-functional requirements) và các mục tiêu thực hiện (implementation goals). Hướng dẫn sử dụng (user manual) không nằm trong tài liệu SRS mà là một tài liệu riêng biệt, cung cấp thông tin cho người dùng về cách sử dụng phần mềm.

Câu 24:

Độ lớn (Volume) trong phân tích yêu cầu là:

Lời giải:

Đáp án đúng: C

Độ lớn (Volume) trong phân tích yêu cầu đề cập đến lượng dữ liệu hoặc số lượng công việc mà hệ thống phải xử lý trong một khoảng thời gian nhất định.

Phương án 1: Số lượng máy tính chạy phần mềm không trực tiếp thể hiện độ lớn của công việc mà hệ thống phải xử lý.
Phương án 2: Số lượng dữ liệu phát sinh trong một chu kỳ thể hiện rõ ràng khối lượng công việc mà hệ thống phải quản lý và xử lý. Đây là một yếu tố quan trọng của 'độ lớn' trong phân tích yêu cầu.
Phương án 3: Số lượng các nghiệp vụ hệ thống phải tiến hành trong một chu kỳ cũng thể hiện khối lượng công việc hệ thống phải thực hiện.
Phương án 4: Số lượng người làm việc với phần mềm có thể ảnh hưởng đến khối lượng công việc, nhưng không trực tiếp định nghĩa 'độ lớn'.

Như vậy, phương án 2 và 3 đều có ý đúng, tuy nhiên phương án 2 tập trung vào dữ liệu, là yếu tố quan trọng thường được xem xét khi nói đến 'độ lớn'. Phương án 3, mặc dù liên quan, nhưng 'nghiệp vụ' có thể bao gồm nhiều khía cạnh khác ngoài dữ liệu. Trong trường hợp này, phương án 2 chính xác và phù hợp hơn.

Câu 25:

CASE là từ viết tắt của

Lời giải:

Đáp án đúng: B

CASE là viết tắt của Computer-Aided Software Engineering, nghĩa là Kỹ nghệ phần mềm có sự hỗ trợ của máy tính. Đây là việc sử dụng các công cụ phần mềm để tự động hóa hoặc hỗ trợ các hoạt động trong quy trình phát triển phần mềm, từ đó giúp tăng năng suất, cải thiện chất lượng và giảm chi phí.

Câu 26:

Để xây dựng mô hình hệ thống, kỹ sư phải quan tâm tới một trong những nhân tố hạn chế sau :

Lời giải: