500+ câu Trắc nghiệm Công nghệ phần mềm có đáp án - Phần 16

Đặc tả hình thức

Đặc tả phi hình thức

Đặc tả toán học

Đặc tả hỗn hợp

Phân tích viên và lập trình viên

Phân tích viên và khách hàng

Phân tích viên và các bên có liên quan

Phân tích viên và người dùng

“một số”, “đôi khi”, “thường”, “thông thường”, “bình thường”, “phần lớn”, “đa số”

Danh từ là số nhiều hay số ít

Tính từ chỉ trạng thái

Động từ ở hình thức chủ động hay bị động

Bản chất lặp

Dễ dàng điều tiết những biến đổi yêu cầu sản phẩm

Nói chung không tạo ra những sản phẩm bỏ đi

Tất cả các mục

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

Cải tiến quy trình

Giảm lỗi giá

Gia tăng số bản bán được

Giảm thời gian sửa lỗi

Những kỹ thuật input giữ tương tự suốt ứng dụng

Mỗi ứng dụng phải có look and feel riêng biệt

Cách thức điều hướng (navigational) nhạy với ngữ cảnh

Câu a và b

Dữ liệu, phần cứng, phần mềm, con người

Dữ liệu, tài liệu, phần cứng, phần mềm

Dữ liệu, phần cứng, phần mềm, thủ tục

Tài liệu, phần cứng, con người, thủ tục

Hiểu rõ những yêu cầu người dùng

Sự thay đổi

Tất cả các mục

Phạm vi, giới hạn

Chu kỳ trong chương trình

Số lỗi trong chương trình

Những đường logic độc lập trong chương trình

Những phát biểu của chương trình

Mô hình hệ thống của người dùng

Trong tình huống đặc trưng thì người dùng thực hiện công việc gì?

Những feedback từ việc đánh giá của người dùng

Nếu người dùng xảy ra lỗi thì hậu quả như thế nào?

Luồng dữ liệu

Kiến trúc ngữ cảnh

Gọi trả về

Tầng

Đưa ra quy trình đánh giá tính an toàn cho sản phẩm phần mềm

Đưa ra quy trình đánh giá hiệu quả của phần mềm

Đưa ra quy trình đánh giá chất lượng cho sản phẩm phần mềm

Đưa ra quy trình đánh giá tính khả dụng cho sản phẩm phần mềm

Con người

Quy trình

Sản phẩm

Thời gian

Extreme programming

Evolutionary prototyping

Component architecture

Open-source development

Software requirement specification

Software design

Testing

Coding

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

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

Mục tiêu thực hiện

Hướng dẫn sử dụng

Thường dùng prototype

Bản chất lặp

Dễ dàng điều tiết những biến đổi yêu cầu sản phẩm

Tất cả các mục

Một mô hình cũ phổ biến mà bây giờ hiếm khi dùng nữa

Hướng tốt nhất để dùng cho những dự án với những nhóm phát triển lớn

Một hướng hợp lý khi những yêu cầu được xác định rõ

Một hướng tốt khi cần tạo nhanh một chương trình thực thi

Đặc tả cấu trúc dữ liệu

Đặc tả chức năng

Đặc tả bằng sơ đồ

Đặc tả đối tượng

Tính liên kết (coupling)

Tính kết dính (cohesion)

Chỉ đến chi phí tích hợp

Chỉ đến chi phí phát triển

Là số lượng máy tính chạy phần mềm

Là số lượng dữ liệu phát sinh trong một chu kỳ nào đó

Là số lượng các nghiệp vụ hệ thống phải tiến hành trong một chu kỳ nào đó

Là số lượng người làm việc với phần mềm

Thiết kế không là code, code không là thiết kế

Thiết kế phải được đánh giá chất lượng khi nó đang được tạo không phải khi nó có vấn đề

Mô hình thiết kế cung cấp chi tiết về kiến trúc (architecture), Giao diện (interfaces) và thành phần (component) cần thiết để cài đặt phần mềm

Thiết kế phải chỉ ra được hệ thống thực thi như thế nào, các yêu cầu được hiện thực hóa ra sao

Dựa vào kiểm thử đường cơ bản

Thử thách điều kiện logic trong module phần mềm

Chọn những đường dẫn kiểm tra dựa vào những vị trí và dùng những biến

Tập trung vào việc kiểm thử giá trị những cấu trúc lặp

Dựa vào kiểm thử đường cơ bản

Thử thách điều kiện logic trong module phần mềm

Chọn những đường dẫn kiểm tra dựa vào những vị trí và dùng những biến

Tập trung vào việc kiểm thử giá trị những cấu trúc lặp

Chức năng không đầy đủ hay không đúng

Những lỗi giao diện

Những lỗi thực thi

Tất cả mục trên

Những người phát triển phần mềm không cần làm bất kỳ kiểm thử nào

Những người lạ sẽ kiểm phần mềm rất chặt

Những người kiểm thử không được dính dáng tới dự án cho đến khi kiểm thử bắt đầu

Mâu thuẫn về quyền lợi giữa những người phát triển và những người kiểm thử sẽ giảm

Đưa ra những xem xét kỹ thuật hình thức ưu tiên trước khi kiểm thử

Chỉ rõ những yêu cầu theo một cách thức có thể định lượng

Quan tâm tới việc sử dụng những nhóm kiểm thử độc lập

Tất cả mục trên

Những module mức thấp không bao giờ cần kiểm thử

Những điểm quyết định chính được kiểm thử sớm

Không có những stub cần phải viết

Không có mục nào

Những điểm quyết định chính được kiểm thử sớm

Không có những driver cần được viết

Không có những stub (nhánh) cần phải viết

Không đòi hỏi kiểm thử hồi quy (regression)

Backtracking

Brute force

Sự loại trừ nguyên nhân

Tất cả các mục