250 câu hỏi trắc nghiệm công nghệ phần mềm có đáp án

250 câu hỏi trắc nghiệm công nghệ phần mềm có đáp án 250 câu hỏi trắc nghiệm công nghệ phần mềm có đáp án 250 câu hỏi trắc nghiệm công nghệ phần mềm có đáp án 250 câu hỏi trắc nghiệm công nghệ phần mềm có đáp án

Câu hỏi: 1/ Tiêu chuẩn ISO-14598 đưa ra: A/ Đưa quy trình đánh giá tính an toàn cho sản phẩm phần mềm B/ Đưa quy trình đánh giá hiệu phần mềm C/ Đưa quy trình đánh giá chất lượng cho sản phẩm phần mềm (đ) D/ Đưa quy trình đánh giá tính khả dụng cho sản phẩm phần mềm 2/ Trong phát triển phần mềm, yếu tố quan trọng nhất? A/ Con người (đ) B/ Quy trình C/ Sản phầm D/ Thời gian 3/ Kỹ thuật sau xây dựng phần mềm từ thành phần thiết kế lĩnh vực công nghệ khác nhau? A/ Extreme programming B/ Evolutionary prototyping C/ Component architecture (đ) D/ Open-source development 4/ IEEE 830-1993 khuyến nghị tiêu chuẩn cho A/ Software requirement specification (đ) B/ Software design C/ Testing D/ Coding 5/ Kỹ sư phần mềm không cần A/ Kiến thức phân tích thiết kế hệ thống B/ Kiến thức sở liệu C/ Lập trình thành thạo ngôn ngữ lập trình (đ) D/ Kinh nghiệm quản lý dự án phần mềm 6/ Tính khả thi phần mềm dựa vào yếu tố sau: A/ Nghiệp vụ tiếp thị B/ Phạm vi, ràng buộc thị trường C/ Công nghệ, tiền bạc, thời gian tài nguyên (đ) D/ Kỹ lực nhà phát triển 7/ Phần mềm dự báo thời tiết thu thập số liệu nhiệt độ, độ ẩm, … xử lý tính toán dự báo thời tiết ví dụ loại phần mềm: A/ Phần mềm hệ thống (System software) B/ Phần mềm trí tuệ nhân tạo (Artificial Intelligence Software) C/ Phần mềm thời gian thực (Real time software) (đ) D/ Phần mềm nghiệp vụ (Business software) 8/ Loại phần mềm tập hợp chương trình để cung cấp dịch vụ cho chương trình khác: A/ Phần mềm hệ thống (System software) B/ Phần mềm trí tuệ nhân tạo (Artificial Intelligence Software) C/ Phần mềm thời gian thực (Real time software) (đ) D/ Phần mềm nghiệp vụ (Business software) 9/ Phần mềm quản lý sinh viên trường là: A/ Phần mềm hệ thống (System software) B/ Phần mềm trí tuệ nhân tạo (Artificial Intelligence Software) C/ Phần mềm thời gian thực (Real time software) D/ Phần mềm nghiệp vụ (Business software) 10/ Phần mềm quản lý tài công ty là: A/ Phần mềm nghiệp vụ (Business software) B/ Phần mềm hệ thống (System software) C/ Phần mềm trí tuệ nhân tạo (Artificial Intelligence Software) D/ Phần mềm thời gian thực (Real time software) 11/ Theo báo cáo IBM, "31% dự án bị hủy bỏ trước chúng hoàn thành, 53% vượt dự toán trung bình 189% 100 dự án, có 94 dự án khởi động lại" Lý cho số liệu thống kê trên? A/ Thiếu đào tạo đầy đủ công nghệ phần mềm B/ Thiếu đạo đức phần mềm hiểu biết C/ Quản lý vấn đề công ty D/ Ảnh hưởng suy thoái kinh tế 12/ Điều không đúng? A/ Công nghệ phần mềm thuộc ngành khoa học máy tính B/ Công nghệ phần mềm phần ngành kỹ thuật hệ thống (System Engineering) C/ Khoa học máy tính thuộc ngành công nghệ phần mềm D/ Công nghệ phần mềm có liên quan với việc phát triển cung cấp phần mềm hữu ích 13/ Mối quan tâm công nghệ phần mềm gì? A/.Sản xuất phần cứng B/ Sản xuất phần mềm (đ) C/ Cấu hình mạng D/ Phần mềm dùng lại 14/ Điều đặc trưng thiết kế phần mềm tốt? A/ Thể kết nối mạnh mẽ mô-đun B/ Thực tất yêu cầu mô hình phân tích (đ) C/ Bao gồm trường hợp thử nghiệm cho tất thành phần D/ Cung cấp tranh hoàn chỉnh phần mềm 1/ Theo thống kê từ thách thức công nghệ phần mềm lỗi nhiều A/ Kiểm tra bảo trì B/ Phân tích yêu cầu (đ) C/ Thiết kế D/ Viết Code 2/ Yêu cầu chia thành lọai sau đây? A/ Chức năng, phi chức năng, yêu cầu hệ thống B/ Chức năng, phi chức (đ) C/ Chức năng, phi chức năng, yêu cầu miền ứng dụng D/ Chức năng, phi chức năng, yêu cầu nghiệp vụ 3/ hình thức dùng mô tả yêu cầu là: A/ Yêu cầu người dùng yêu cầu hệ thống (đ) B/ Yêu cầu chức yêu cầu phi chức C/ Yêu cầu chủ động yêu cầu thụ động D Yêu cầu cụ thể yêu cầu trừu tượng 4/ Loại khả thi không xem xét phân tích khả thi A/ Khả thi kinh tế B/ Khả thi thực C/ Khả thi vể kỹ thuật D/ Khả thi chất lượng (đ) 5/ Tính chất cần có liệu phân tích yêu cầu A/ Có định hướng thời gian (đ) B/ Có giá trị pháp lý C/ Tính mô tả trừu tượng D/ Có thể mô tả toán học 6/ Câu hỏi có liên quan đến phân tích thiết kế? A/ Thời gian hoàn thành dự án có đủ không? B/ Làm chuyển thiết kế liệu logic sang thiết kế liệu vật lý? (đ) C/ Các xử lý tiến hành thông tin chi tiết liên quan? D/ Đâu phạm vi hệ thống phần mềm? 7/ Tính chất không cần thiết cho phân tích liệu ? A/ Cấu trúc liệu B/ Đầy đủ C/ Bảo mật (đ) D/ Độ lớn 8/ Phân tích yêu cầu bao gồm hoạt động theo thứ tự ? A/ Làm tài liệu yêu cầu, làm rõ yêu cầu, xem xét yêu cầu B/ Làm rõ yêu cầu, xem xét yêu cầu, làm tài liệu yêu cầu C/ Xem xét yêu cầu, làm tài liệu yêu cầu, làm rõ yêu cầu D/ Làm rõ yêu cầu, làm tài liệu yêu cầu, xem xét yêu cầu 9/ Làm rõ yêu cầu (Eliciting requirements) A/ Giao tiếp với khách hàng người sử dụng để xác định yêu cầu họ B/ Các yêu cầu ghi nhận lại theo nhiều hình thức C/ Các yêu cầu tổng hợp lại theo nhiều hình thức D/ Xem yêu cầu có tình trạng không rõ ràng? 10/ Yêu cầu yêu cầu chức năng? A/ Cảnh báo người dùng dung lượng trống đĩa 20% B/ Thực thao tác thêm, xem, xóa, sửa liệu nghiệp vụ C/ Cảnh báo ngày hệ thống bị sai D/ Yêu cầu chỉnh lại ngày hệ thống làm việc 11/ SRS viết tắt của: A/ Software Requirement Specification B/ System Requirement Specification C/ Studying Requirement Specification D/ Solve Requirement Specification 12/ Phát biểu sau không nói đến trình thu thập yêu cầu: A/ Yêu cầu khó phát B/ Yêu cầu dễ bị thay đổi C/ Yêu cầu phải thống D/ Yêu cầu biết cách xác (đ) 13/ Kết giai đoạn thu thập yêu cầu là: A/ Bảng ước tính chi phí dự án B/ Tài liệu đặc tả yêu cầu phần mềm (đ) C/ Lược đồ ngữ cảnh D/ Lược đồ Use case đồ khác 14/ Ai người viết tài liệu SRS? A/ Người quản lý dự án B/ Phân tích viên (đ) C/ Lập trình viên D/ Khách hàng 15/ Kết cuối giai đoạn xác định phân tích yêu cầu là: A/ Tài liệu SRS (đ) B/ Sơ đồ DFD C/ Sơ đồ Use case D/ Sơ đồ ERD 16/ Mục sau không bao gồm tài liệu SRS? A/ Yêu cầu chức B/ Yêu cầu phi chức C/ Mục tiêu thực D/ Hướng dẫn sử dụng (đ) 17/ Loại hình đặc tả dùng phổ biến tài liệu SRS? A/ Đặc tả cấu trúc liệu B/ Đặc tả chức C/ Đặc tả sơ đồ (đ) D/ Đặc tả đối tượng 18/ Độ lớn (Volume) phân tích yêu cầu là: A/ Là số lượng máy tính chạy phần mềm B/ Là số lượng liệu phát sinh chu kỳ C/ Là số lượng nghiệp vụ hệ thống phải tiến hành chu kỳ (đ) D/ Là số lượng người làm việc với phần mềm 19/ Sơ đồ sau không cần thiết phân tích yêu cầu? A/ Use Case B/ Entity Relationship Diagram C/ State Transition Diagram D/ Activity Diagram (đ) 20/ Có đặc trưng xem xét phân tich yêu cầu khả thi? A/ B/ C/ D/ 21/ Có giai đoạn phân tích yêu cầu? A/ B/ C/ D/ 22/ Có nguyên lý đặc tả yêu cầu? A/ B/ C/ D/ 23/ CASE từ viết tắt A/ Cost Aided Software Engineering B/ Computer Aided Software Engineering C/ Control Aided Software Engineering D/ Computer Analyzing Software Engineering 24/ Kỹ thuật thu thập yêu cầu cần đến chuyên gia? A/ Interview B/ Observation C/ Expert D/ Delphi 25/ Kỹ thuật thu thập yêu cầu cầu cần đến trí số đông? A/ Prototype B/ Facilitated Workshops C/ Observation D/ Questionnaires & Surveys 26/ Mục không dùng cho đặc tả yêu cầu: A/ Đặc tả cú pháp B/ Đặc tả đối tượng C/ Đặc tả chức D/ Đặc tả kỹ thuật 27/ Mục không dùng cho đặc tả yêu cầu: A/ Đặc tả thao tác B/ Đặc tả mô hình C/ Đặc tả sơ đồ D/ Đặc tả thuật toán 28/ Loại hình đặc tả không có? A/ Đặc tả hình thức B/ Đặc tả phi hình thức C/ Đặc tả toán học D/ Đặc tả hỗn hợp 29/ Xác nhận yêu cầu (Requirements Validation) tiến hành A/ Phân tích viên lập trình viên B/ Phân tích viên khách hàng C/ Phân tích viên bên có liên quan D/ Phân tích viên người dùng 30/ Khi xác nhận yêu cầu, cần phải làm sáng tỏ từ sau đây: A/ “một số”, “đôi khi”, “thường”, “thông thường”, “bình thường”, “phần lớn”, “đa số” B/ Danh từ số nhiều hay số C/ Tính từ trạng thái D/ Động từ hình thức chủ động hay bị động Câu hỏi không kỹ sư phần mềm quan tâm a b c d Tại chi phí phần cứng máy tính cao? Tại phần mềm thời gian dài để hoàn tất? Tại người ta tốn nhiếu chi phí để phát triển mẩu phần mềm? Tại lỗi phần mềm không loại bỏ sản phẩm trước xuất xưởng Mô hình phát triển ứng dụng nhanh a definition, development, support b what, how, where c programming, debugging, maintenance d analysis, design, testing Mô hình phát triển ứng dụng nhanh a Một cách gọi khác mô hình phát triển dựa vào thành phần b Một cách hữu dụng khách hàng không xàc định yêu cầu rõ ràng c Sự ráp nối tốc độ cao mô hình tuyến tính d Tất mục Mô hình tiến trình phần mềm tiến hóa a Bản chất lặp b Dễ dàng điều tiết biến đổi yêu cầu sản phẩm c Nói chung không tạo sản phẩm bỏ d Tất mục Mô hình phát triển phần mềm lặp lại tăng thêm a Một hướng hợp lý yêu cầu xác định rõ b Một hướng tốt cần tạo nhanh sản phẩm thực thi lõi c Một hướng tốt dùng cho dự án có nhóm phát triển lớn d Một mô hình cách mạng không không dùng cho sản phẩm thương mại Mô hình phát triển phần mềm xoắn ốc a Kết thúc với việc xuất xưởng sản phẩm phần mềm b Nhiều hỗn độn với mô hình gia tăng c Bao gồm việc đánh giá rủi ro phần mềm vòng lặp d Tất điều Mô hình phát triển dựa vào thành phần a Chỉ phù hợp cho thiết kế phần cứng máy tính b Không thể hỗ trợ phát triển thành phần sử dụng lại c Dựa vào kỹ thuật hỗ trợ đối tượng d Không định chi phí hiệu độ đo phần mềm định lượng Để xây dựng mô hình hệ thống, kỹ sư phải quan tâm tới nhân tố hạn chế sau : a Những giả định ràng buộc b Ngân sách phí tổn c Những đối tượng hoạt động d Lịch biểu mốc kiện Trong kỹ thuật tiến trình nghiệp vụ, ba kiến trúc khác kiểm tra a Hạ tầng kỹ thuật, liệu, ứng dụng b Hạ tầng tài chánh, tổ chức truyền thông c Cấu trúc báo cáo, sở liệu, mạng d Cấu trúc liệu, yêu cầu, hệ thống 10 Thành phần kỹ thuật tiến trình nghiệp vụ trách nhiệm kỹ sư phần mềm a b c d Phân tích phạm vi nghiệp vụ Thiết kế hệ thống nghiệp vụ Kế hoạch sản phẩm Kế hoạch chiến lược thông tin 11 Những thành phần kiến trúc kỹ thuật sản phẩm a Dữ liệu, phần cứng, phần mềm, người b Dữ liệu, tài liệu, phần cứng, phần mềm c Dữ liệu, phần cứng, phần mềm, thủ tục d Tài liệu, phần cứng, người, thủ tục 12 Đặc tả hệ thống mô tả a Chức hành vi hệ thống dựa vào máy tính b Việc thi hành thành phần hệ thống c Chi tiết giải thuật cấu trúc hệ thống d Thời gian đòi hỏi cho việc giả lập hệ thống 13 Cách tốt để đưa tới việc xem xét việc đánh giá yêu cầu a Kiểm tra lỗi mô hình hệ thống b Nhờ khách hàng kiểm tra yêu cầu c Gởi họ tới đội thiết kế xem họ có quan tâm không d Dùng danh sách câu hỏi kiểm tra để kiểm tra yêu cầu 14 Sử dụng bảng lần vết giúp a Debug chương trình dựa theo việc phát lỗi thời gian thực b Xác định việc biểu diễn thi hành giải thuật c Xác định, điều khiển theo vết thay đổi yêu cầu d Không có mục 15 Mẫu mô hình hệ thống chứa thành phần a Input b Output c Giao diện người dùng d Tất mục 16 Tác vụ không biểu diễn phần phân tích yêu cầu phần mềm a Định giá tổng hợp b Mô hình hóa thừa nhận vấn đề c Lập kế hoạch lịch biểu d Đặc tả xem xét 17 Đích kỹ thuật đặc tả ứng dụng thuận tiện (FAST - facilitated application specification techniques) nhờ người phát triển khách hàng a Xây dựng nguyên mẫu nhanh chóng b Học công việc lẫn c Làm việc với để phát triển tập yêu cầu ban đầu d Làm việc với để phát triển đặc tả phần mềm kỹ thuật 18 Ai người không thích hợp để tham dự vào nhóm FAST (facilitated application specification techniques) a Kỹ sư phần cứng phần mềm b Đại diện nhà sản xuất c Đại diện thị trường d Nhân viên tài chánh cao cấp 19 Những yêu cầu quan tâm suốt QFD (quality function deployment) a exciting requirements b expected requirement c normal requirements d technology requirements 20 Phân tích giá trị dẫn phần QFD (quality function deployment) nhằm xác định a Chi phí hoạt động đảm bảo chất lượng dự án b Chi phí quan hệ yêu cầu qua việc triển khai chức năng, tác vụ thông tin c Độ ưu tiên quan hệ yêu cầu qua việc triển khai chức năng, tác vụ thông tin d Kích thước ý kiến khách hàng 21 Use-cases kịch mà mô tả a Phần mềm thực dùng tình cho trước b Những công cụ CASE dùng để xây dựng hệ thống c Kế hoạch xây dựng cho sản phẩm phần mềm d Những test-case cho sản phẩm phần mềm 22 Nội dung thông tin biểu diễn đối tượng điều khiển liệu riêng biệt mà bao gồm thông tin mà a Cần thiết để trình bày tất output b Được đòi hỏi cho việc xử lý lỗi c Được đòi hỏi cho hoạt động tạo giao diện hệ thống d Được biến đổi phần mềm 23 Dòng thông tin biểu diễn cách thức mà liệu điều khiển a Quan hệ với liệu điều khiển khác b Biến đổi lần dịch chuyển qua hệ thống c Sẽ thực thi thiết kế cuối d Không có mục 24 Cấu trúc thông tin biểu diển tổ chức nội a Những cấu trúc liệu dùng để biểu diễn loại liệu b Mô hình bố trí nhân viên dự án c Mô hình truyền thông dự án d Những liệu khác mục điều khiển 25 Loại mô hình tạo phân tích yêu cầu phần mềm a Chức hành vi b Giải thuật cấu trúc liệu c Kiến trúc cấu trúc d Tính tin cậy tính sử dụng 26 Trong ngữ cảnh phân tích yêu cầu, hai loại phân tách vấn đề a bottom-up top-down b horizontal and vertical c subordinate superordinate d Không có mục 27 Khung nhìn (view) quan tâm phân tich yêu cầu phần mềm a actor view b data view c essential view d implementation view 28 Tạo nguyên mẫu tiến hóa thường thích dùng tạo nguyên mẫu bỏ a Cho phép tái sử dụng nguyên mẫu đầu b Không đòi hỏi làm việc nhiều với khách hàng c Dễ dành thực nhanh d Nhiều tin cậy 29 Những mục không nguyên tắc cho việc biểu diễn yêu cầu a Biểu đồ phải thu hẹp số toàn vẹn sử dụng b Hình thức nội dung biểu diễn thích hợp với nội dung c Những biểu diễn phải xem xét lại d Dùng không màu dương màu âm biểu đồ 30 Mục không mục đích cho việc xây dựng mô hình phân tích a Xác định tập yêu cầu phần mềm b Mô tả yêu cầu khách hàng c Phát triển giải pháp tóm tắt cho vấn đề d Thiết lập tảng cho thiết kế phần mềm 31 Sơ đồ luồng liệu a Đưa hình ảnh quan hệ đối tượng liệu b Đưa hình ảnh chức biến đổi luồng liệu c Chỉ định logic chúng xuất d Chỉ tương tác hệ thống với kiện bên 32 Biểu đồ quan hệ thực thể a Đưa hình ảnh quan hệ đối tượng liệu b Đưa hình ảnh chức biến đổi luồng liệu c Chỉ định logic chúng xuất d Chỉ tương tác hệ thống với kiện bên 33 Biểu đồ dịch chuyển trạng thái a Đưa hình ảnh đối tượng liệu b Đưa hình ảnh chức biến đổi luồng liệu c Chỉ hình ảnh liệu biến đổi hệ thống d Chỉ tương tác hệ thống kiện bên 34 Phân tích văn phạm tường thuật xử lý bước tốt để tạo a Tự điển liệu b Biểu đồ dòng liệu c Biểu đồ quan hệ thực thể d Biểu đồ dịch chuyển trạng thái 35 Biểu đồ dòng điều khiển a Cần thiết để mô hình hệ thống hướng kiện b Được đòi hỏi cho tất hệ thống mềm a actor view b data view c essential view d implementation view 121 a b c d Kiểm nghiệm hướng đối tượng thường dùng Kiểm nghiệm tích hợp đối tượng Kiểm nghiệm hộp đen Kiểm nghiệm thừa kế Kiểm nghiệm hộp trắng 122 a b c d Kiểm nghiệm tích hợp module Có thể tích hợp từ xuống Tát Có thể tích hợp từ lên theo cách tích hợp theo chiều ngang Có thể tích hợp từ lên theo cách tích hợp theo chiều sâu 123 a b c d Kiểm thử Black-box cố gắng tìm lỗi Chức không đầy đủ hay không Những lỗi giao diện Những lỗi thực thi Tất mục 124 a b c d Kiểm thử điều kiện kỹ thuật kiểm thử cấu trúc điều khiển mà tiêu chuẩn dùng để thiết kế test-case Dựa vào kiểm thử đường Thử thách điều kiện logic module phần mềm Chọn đường dẫn kiểm tra dựa vào vị trí dùng biến Tập trung vào việc kiểm thử việc giá trị cấu trúc lặp 125 a b c d Kiểm thử lặp kỹ thuật kiểm thử cấu trúc điều khiển mà tiêu chuẩn dùng để thiết kế test-case Dựa vào kiểm thử đường Thử thách điều kiện logic module phần mềm Chọn đường dẫn kiểm tra dựa vào vị trí dùng biến Tập trung vào việc kiểm thử việc giá trị cấu trúc lặp 126 a b c d Kiểm thử luồng liệu kỹ thuật kiểm thử cấu trúc điều khiển mà tiêu chuẩn dùng để thiết kế test-case Dựa vào kiểm thử đường Thử thách điều kiện logic module phần mềm Chọn đường dẫn kiểm tra dựa vào vị trí dùng biến Tập trung vào việc kiểm thử việc giá trị cấu trúc lặp 127 a b Kiểm thử tích hợp bottom-up có thuận lợi Những điểm định kiểm thử sớm Không có driver cần viết c d Không có stub (nhánh) cần phải viết Không đòi hỏi kiểm thử hồi quy (regression) 128 a b c d Kiểm thử tích hợp Top-down có thuận lợi Những module mức thấp không cần kiểm thử Những điểm định kiểm thử sớm Không có stub cần phải viết Không có mục 129 a b c d Kiểm thử vòng lặp lồng Tất Khi xét vòng lặp cần test Min+1, typical, max-1 Kiểm thử từ vào Nếu vòng lặp độc lập xem vòng lặp đơn 130 a b c d Liên kết (Coupling) báo chất lượng cho biết mức độ mà module Tập trung vào điều Kết nối với module khác môi trường bên Có thể hoàn thành chức cách thức phù hợp thời gian Có thể viết với rắn nhiều 131 a b c d Loại mô hình tạo phân tích yêu cầu phần mềm Chức hành vi Giải thuật cấu trúc liệu Kiến trúc cấu trúc Tính tin cậy tính sử dụng 132 a b c d Loại mô hình kiến trúc phần mềm Dữ liệu Động Xử lý Cấu trúc 133 a b c d Loại trừu tượng dùng thiết kế phần mềm Điều khiển Dữ liệu Thủ tục Tất mục 134 a b c Lý tốt cho việc dùng nhóm kiểm tra phần mềm độc lập Những người phát triển phần mềm không cần làm kiểm thử Những người lạ kiểm phần mềm chặt Những người kiểm thử không dính dáng tới dự án kiểm thử bắt đầu d Mâu thuẩn quyền lợi người phát triển người kiểm thử giảm 135 a b c Mật độ lỗi (defect density) thuộc độ đo Độ đo chất lượng sản phẩm cuối Độ đo trình sản xuất Độ đo dự án phần mềm d Độ đo chất lượng bảo trì 136 a b c d Mẫu kiến trúc nhấn mạnh tới thành phần Ràng buộc Tập hợp thành phần Mô hình ngữ nghĩa Tất mục 137 a b c d Mẫu mô hình hệ thống chứa thành phần Input Output Giao diện người dùng Tất mục 138 a b c d Milestone Thường có output word product Là thời điểm cuối hoạt động xử lý Có thể chuyển giao két dự án Tất 139 a b c d Mô hình đưa hình ảnh hệ thống đầu người dùng cuối Mô hình thiết kế Mô hình người dùng Hình ảnh hệ thống Mô hình nhận thức hệ thống 140 a b c d Mô hình đưa hình ảnh look and feel cho giao diện người dùng thông tin hỗ trợ Mô hình thiết kế Mô hình người dùng Mô hình hình ảnh hệ thống Mô hình nhận thức hệ thống 141 a b c d Mô hình đưa hình ảnh tiền sử (profile) người dùng cuối hệ thống dựa vào máy tính Mô hình thiết kế Mô hình người dùng Mô hình người dùng Mô hình nhận thức hệ thống 142 a b c d Mô hình phát triển dựa vào thành phần Chỉ phù hợp cho thiết kế phần cứng máy tính Không thể hỗ trợ phát triển thành phần sử dụng lại Dựa vào kỹ thuật hỗ trợ đối tượng Không định chi phí hiệu độ đo phần mềm định lượng 143 a b c Mô hình phát triển phần mềm dựa mẫu thử Một mô hình rủi ro, khó đưa sản phẩm tốt Phương pháp tốt sử dụng dự án có nhiều thành viên Một phương pháp hữu ích khách hàng xác định yêu cầu d cách rõ ràng Một phương pháp thích hợp sử dụng yêu cầu xác định rõ ràng 144 a b c d Mô hình phát triển phần mềm lặp lại tăng thêm Một hướng hợp lý yêu cầu xác định rõ Một hướng tốt cần tạo nhanh sản phẩm thực thi lõi Một hướng tốt dùng cho dự án có nhóm phát triển lớn Một mô hình cách mạng không không dùng cho sản phẩm thương mại 145 a b c d Mô hình phát triển phần mềm tuyến tính gọi Mô hình hỗn độn Mô hình nước suối Mô hình xoắn ốc Mô hình chu kỳ sống cổ điển 146 a b c d Mô hình phát triển phần mềm xoắn ốc Kết thúc với việc xuất xưởng sản phẩm phần mềm Nhiều hỗn độn với mô hình gia tăng Bao gồm việc đánh giá rủi ro phần mềm vòng lặp Tất điều 147 a b c d Mô hình phát triển ứng dụng nhanh Một cách gọi khác mô hình phát triển dựa vào thành phần Một cách hữu dụng khách hàng không xàc định yêu cầu rõ ràng Sự ráp nối tốc độ cao mô hình tuyến tính Tất mục 148 a b c d Mô hình thiết kế không quan tâm tới Kiến trúc Dữ liệu Giao diện Phạm vi dự án 149 a b c d Mô hình tiến trình phần mềm tiến hóa Bản chất lặp Dễ dàng điều tiết biến đổi yêu cầu sản phẩm Nói chung không tạo sản phẩm bỏ Tất mục 150 a b c d Một bảng định dùng Để tư liệu tất trạng thái phụ thuộc Để hướng dẫn phát triển kế hoạch quản lý dự án Chỉ xây dựng hệ chuyên gia Khi tập phức tạp điều kiện hoạt động xuất thành phần 151 Một bổ sung cần thiết nhằm biến đổi hay ánh xạ giao dịch để tạo thiết kế kiến trúc đầy đủ a Sơ đồ quan hệ - thực thể b c d Từ điển liệu Mô tả việc xử lý cho module Những Test-case cho module 152 a b c d Một đặc trưng thiết kế tốt Cho thấy liên kết mạnh module Thực tất yêu cầu phân tích Bao gồm test case cho tất thành phần Kết hợp mã nguồn nhằm mục đích mô tả 153 Mục đích tham chiếu chéo yêu cầu (ma trận) tài liệu thiết kế nhằm a b c d Cho phép người quản lý theo dõi suất nhóm thiết kế Xác minh tất yêu cầu xem xét thiết kế Chỉ chi phí kết hợp với yêu cầu Cung cấp cho việc thực thi tên nhà thiết kế cho yêu cầu 154 a b c d Mục không đặc trưng chung phương pháp thiết kế Quản lý cấu hình Ký hiệu thành phần chức Nguyên tắc đánh giá chất lượng Heuristic tinh chế 155 a b c d Mục không mẫu kiến trúc (pattern)? Mẫu Concurrency Persistence Distribution Borker 156 a b c d Mục không mục đích cho việc xây dựng mô hình phân tích Xác định tập yêu cầu phần mềm Mô tả yêu cầu khách hàng Phát triển giải pháp tóm tắt cho vấn đề Thiết lập tảng cho thiết kế phần mềm 157 a b c d Mục không phần kiến trúc phần mềm Chi tiết giải thuật Cơ sở liệu Thiết kế liệu Cấu trúc chương trình 158 a b c d Mục loại kiến trúc (style): kiến trúc Luồng liệu Kiến trúc ngữ cảnh Gọi trả Tầng 159 a b c Mục liên quan tới phân tích người dùng: Mô hình hệ thống người dùng Trong tình đặc trưng người dùng thực công việc gì? Những feedback từ việc đánh giá người dùng d Nếu người dùng xảy lỗi hậu nào? 160 a b c d Ngôn ngữ thiết kế chương trình (PDL) thường Sự kết hợp cấu trúc lập trình văn tường thuật Ngôn ngữ lập trình truyền thống theo luật riêng Ngôn ngữ phát triển phần mềm đọc máy Một cách hữu dụng để biểu diễn kiến trúc phần mềm 161 Nguyên nhân việc sinh lỗi thiết kế mức thành phần trước thiết kế liệu a Thiết kế thành phần phụ thuộc vào ngôn ngữ thiết kế liệu không b c d Thiết kế liệu dễ thực Thiết kế liệu khó thực Cấu trúc liệu thường ảnh hưởng tới cách thức mà thíết kế thành phần phải theo 162 Nhằm xác định mẫu kiến trúc hay kết hợp mẫu phù hợp cho hệ thống đề nghị, kỹ thuật yêu cầu dùng để khám phá Giải thuật phức tạp Đặc trưng ràng buộc Điều khiển liệu Những mẫu thiết kế a b c d 163 a b c d Nhiều đo lường hữu dụng thu thập quan sát người dùng tương tác với hệ thống máy tính gồm Thời gian cho ứng dụng Số khiếm khuyết (defect) phần mềm Tính tin cậy phần mềm Thời gian đọc tài liệu trợ giúp 164 a b c d Những câu hỏi có ý nghĩa người thiết kế giao diện hoàn tất Khách hàng Những lập trình viên có kinh nghiệm Người dùng sản phẩm Người quản lý dự án 165 a b c d Những độ đo phức tạp vòng (cyclomatic complexity metric) cung cấp cho người thiết kế thống tin số Chu kỳ chương trình Số lỗi chương trình Những đường logic độc lập chương trình Những phát biểu chương trình 166 a b c d Những làm cho khó đưa yêu cầu Hiểu rõ yêu cầu người dùng Sự thay đổi Tất mục Phạm vi, giới hạn 167 Những hệ thống phát triển giao diện người dùng đặc trưng cung cấp kỹ a b c d thuật cho việc xây dựng nguyên mẫu giao diện bao gồm Tạo code Những tool vẽ Định trị input Tất mục 168 a b c d Những hoạt động khung thường không kết hợp với trình thiết kế giao diện người dùng Ước lượng giá Xây dựng giao diện Định trị giao diện Phân tích người dùng tác vụ 169 a b c d Những kiểm tra chấp nhận thường đưa Người phát triển Những người dùng cuối Nhóm kiểm thử Những kỹ sư hệ thống 170 a b c d Những mục không nguyên tắc cho việc biểu diễn yêu cầu Biểu đồ phải thu hẹp số toàn vẹn sử dụng Hình thức nội dung biểu diễn thích hợp với nội dung Những biểu diễn phải xem xét lại Dùng không màu dương màu âm biểu đồ 171 a b c d Những nguyên lý thiết kế giao diện cho phép người dùng phải nhớ Xác định shortcut trực quan Biểu lộ thông tin theo cách diễn tiến Thiết lập trường hợp mặc định có ý nghĩa Tất mục 172 a b c d Những nguyên lý thiết kế giao diện không cho phép người dùng điều khiển tương tác với máy tính Cho phép gián đoạn Cho phép tương tác undo Che dấu chất kỹ thuật với người dùng thường Chỉ cung cấp cách thức xác định cứng hoàn thành tác vụ 173 a b c d Những thành phần kiến trúc kỹ thuật sản phẩm Dữ liệu, phần cứng, phần mềm, 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, người, thủ tục 174 a b c d Những yêu cầu quan tâm suốt QFD (quality function deployment) exciting requirements expected requirement normal requirements technology requirements 175 Những vấn đề thiết kế chung trội lên hầu hết giao diện người dùng a b c d Kết nối tiền sử người dùng (profile) shortcut chức Xử lý lỗi thời gian đáp ứng hệ thống Quyết định hiển thị hình ảnh thiết kế icon Không có mục 176 a b c d Nội dung thông tin biểu diễn đối tượng điều khiển liệu riêng biệt mà bao gồm thông tin mà Cần thiết để trình bày tất output Được đòi hỏi cho việc xử lý lỗi Được đòi hỏi cho hoạt động tạo giao diện hệ thống Được biến đổi phần mềm 177 a b c d Phân tích giá trị dẫn phần QFD (quality function deployment) nhằm xác định Chi phí hoạt động đảm bảo chất lượng dự án Chi phí quan hệ yêu cầu qua việc triển khai chức năng, tác vụ thông tin Độ ưu tiên quan hệ yêu cầu qua việc triển khai chức năng, tác vụ thông tin Kích thước ý kiến khách hàng 178 Phân tích văn phạm tường thuật xử lý bước tốt để tạo a b c d Tự điển liệu Biểu đồ dòng liệu Biểu đồ quan hệ thực thể Biểu đồ dịch chuyển trạng thái 179 a b c d Sơ đồ luồng liệu Đưa hình ảnh quan hệ đối tượng liệu Đưa hình ảnh chức biến đổi luồng liệu Chỉ định logic chúng xuất Chỉ tương tác hệ thống với kiện bên 180 a b c d Sử dụng bảng lần vết giúp Debug chương trình dựa theo việc phát lỗi thời gian thực Xác định việc biểu diễn thi hành giải thuật Xác định, điều khiển theo vết thay đổi yêu cầu Không có mục 181 a b c d Sự quan trọng thiết kế phần mềm tóm tắt từ đơn Accuracy Complexity Efficiency Quality 182 a b c d Sự toàn vẹn (consistency) giao diện ngầm định 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 b 183 Tác vụ không biểu diễn phần phân tích yêu cầu phần mềm a b c d Định giá tổng hợp Mô hình hóa thừa nhận vấn đề Lập kế hoạch lịch biểu Đặc tả xem xét 184 a b c d Tài liệu sau tạo pha thiết kế hệ thống? Kế hoạch kiểm thử Mã lệnh Thiết kế chi tiết Lập kế hoạch 185 Tạo nguyên mẫu tiến hóa thường thích dùng tạo nguyên mẫu bỏ a b c d Cho phép tái sử dụng nguyên mẫu đầu Không đòi hỏi làm việc nhiều với khách hàng Dễ dành thực nhanh Nhiều tin cậy 186 Thành phần kỹ thuật tiến trình nghiệp vụ trách nhiệm kỹ sư phần mềm a b c d Phân tích phạm vi nghiệp vụ Thiết kế hệ thống nghiệp vụ Kế hoạch sản phẩm Kế hoạch chiến lược thông tin 187 a b c d Theo Boris Beizer, thiết kế Testcase cần theo ràng buộc (contraint) Theo cách thức đầy đủ Tất Nỗ lực thời gian tối thiểu Nhằm khám phá lỗi 188 a b c d Theo chiến thuật kiểm nghiệm phổ biến, kiểm nghiệm tính tương quan với Phân tích toàn hệ thống Thiết kế Phân tích yêu cầu Mã hóa 189 a b c d Thủ tục phần mềm tập trung vào Cấp bậc điều khiển cảm nhận trừu tượng Xử lý chi tiết module riêng biệt Xử lý chi tiết tập module Quan hệ điều khiển thủ tục 190 a b c d Tiêu chuẩn đánh giá chất lượng thiết kế kiến trúc phải dựa vào Tính truy cập tính tin cậy hệ thống Dữ liệu điều khiển hệ thống Tính chức hệ thống Những chi tiết thực thi hệ thống 191 a b c d Tiêu chuẩn ISO để hướng dẫn thực cho lĩnh vực phần mềm ISO 9001 Tất sai ISO 15288 ISO 9000-3 192 a b c d Trong biểu diễn lịch biểu dự án Critical path đường Là đường Có thời gian ngắn Có thời gian dài Tất phụ thuộc vào dự án 193 a b c d Trong độ đo hiệu khử lỗi DRE, số lỗi tiềm tàng Tất sai Số lỗi khách hàng phát Toàn lỗi phát sau Toàn lỗi chưa phát 194 a b c d Trong kỹ thuật tiến trình nghiệp vụ, ba kiến trúc khác kiểm tra Hạ tầng kỹ thuật, liệu, ứng dụng Hạ tầng tài chánh, tổ chức truyền thông Cấu trúc báo cáo, sở liệu, mạng Cấu trúc liệu, yêu cầu, hệ thống 195 Trong mô hình CMM (Software Capability Maturity Model) có mức độ trưởng thành a b c d mức độ mức độ mức độ mức độ 196 a b c d Trong mô hình phân tích thành phần dựa vào kịch (Scenario based element) dùng cho Thiết kế kiến trúc Thiết kế thành phần Thiết kế giao diện Thiết kế liệu/class 197 a b c d Trong dự án thành công sử dụng chiến lược Đưa xem xét kỹ thuật hình thức ưu tiên trước kiểm thử Chỉ rõ yêu cầu theo cách thức định lượng Quan tâm tới việc sử dụng nhóm kiểm thử độc lập Tất mục 198 a b c d Trong ngữ cảnh phân tích yêu cầu, hai loại phân tách vấn đề bottom-up top-down horizontal and vertical subordinate superordinate Không có mục 199 Trong nhận diện rủi ro, việc không đáp ứng lịch biểu thuộc loại rủi ro a b c d Về người Về ước lượng Về yêu cầu Về tổ chức 200 Trong phương pháp phân tích kiến trúc, mô tả mẫu kiến trúc thường dùng khung nhìn a b c d Dòng liệu Module Tiến trình Tất mục 201 a b c d Trong tích hợp module, gom cụm (cluster) dùng Tích hợp từ lên Tích hợp big-bang Tích hợp từ xuống Tích hợp tăng vòng 202 a b c d Từ điển liệu chứa mô tả Mục cấu hình phần mềm Đối tượng liệu phần mềm Biểu đồ phần mềm Hệ thống ký hiệu phần mềm 203 a Use-cases kịch mà mô tả Phần mềm thực dùng tình cho trước b Những công cụ CASE dùng để xây dựng hệ thống c Kế hoạch xây dựng cho sản phẩm phần mềm d Những test-case cho sản phẩm phần mềm 204 a b c d Vấn đề sau liên quan đến pha thiết kế? Khả thi Dữ liệu Tất mục Phạm vi dự án 205 a b c d Xét đường độc lập bản, có node phân nhánh ta có số đường thực thi độc lập 1Dạ̣ng kiểm thử nào dùng kỹ thuật hộp trắng (white box test) Kiểm thử hồi quy (regression test) Kiểm thử nghiệm thu (acceptance test) Kiểm thử hệ thống (system test) Tất cả đều đúng Câu Phát biểu nào là sai nói về bản chất của phần mềm A) Có thể sản phẩm theo đơn đặt hàng B) Là sản phẩm công nghiệp C) Là sản phẩm thực thi D) Không thực sản phẩm Câu 14 Mật độ lỗi (defect density) dùng để đo lường A) Chất lượng sản phẩm cuối B) Dự án phần mềm C) Quá trình sản xuất D) Chất lượng bảo trì Câu 14 Mô hình dùng công cụ mạnh thành phần tái sử dụng nhiều nhất? A) Mô hình xoắn ốc B) Mô hình RAD C) Mô hình tăng dần D) Mô hình thác nước Câu 14 Nguyên lý Pareto được áp dụng kiểm thử được phát biểu sau: A) 80% lỗi chương trình thường 20% bug gây B) 20% lỗi chương trình thường 80% bug gây C) Chi phí sửa lỗi ở giai đoạn thu nhận yêu cầu chỉ bằng 1/5 chi phí sửa lỗi ở giai đạon cuối D) 60% lỗi được tìm thấy giai đoạn kiển thử đơn vị Câu 14 Độ đo mức độ bảo trì A) Số vấn đề giải tháng /tổng số vấn đề phát sinh tháng B) Số lần bảo trì vượt tiêu chuẩn thời gian /tổng số lần bảo trì C) Số lần bảo trì sai sót /tổng số lần bảo trì D) Thời gian trung trung bình lần bảo trì Câu 14 Mô tả nào sau có mức trừu tượng cao nhất: A) Kiến trúc hệ thống B) Chi tiết thành phần C) Các bảng liệu ràng buộc D) Mô tả chức phần mềm Câu 14 Phát biểu nào sau là sai nói về thiết kế A) Thiết kế không code, code không thiết kế B) Thiết kế phải đánh giá chất lượng tạo có vấn đề C) Mô hình thiết kế cung cấp chi tiết kiến trúc (architecture), Giao diện (interfaces) thành phần (component) cần thiết để cài đặt phần mềm D) Thiết kế phải chỉ được hệ thống thực thi thế nào, các yêu cầu được hiện thực hóa Câu 14 A) B) C) D) Mức độ module kết nối với module khác tới 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 Câu Phát biểu nào là hợp lý nhất nói về mô hình phát triển phần mềm tuyến tính A) Một mô hình cũ phổ biến mà dùng B) Hướng tốt để dùng cho dự án với nhóm phát triển lớn C) D) Một hướng hợp lý yêu cầu xác định rõ Một hướng tốt cần tạo nhanh chương trình thực thi Câu 15 A) B) C) D) Các đặc tính của mô hình tiến hóa Thường dùng prototype Bản chất lặp Dễ dàng điều tiết biến đổi yêu cầu sản phẩm Tất mục Câu 16 Mô hình phát triển phần mềm dựa mẫu thử (prototype) A) Một phương pháp thích hợp sử dụng yêu cầu xác định rõ ràng B) Phương pháp tốt sử dụng dự án có nhiều thành viên C) Một phương pháp hữu ích khách hàng xác định yêu cầu cách rõ ràng D) Một mô hình rủi ro, khó đưa sản phẩm tốt Câu 17 A) B) C) D) Yêu cầu sau yêu cầu chức Bảo mật Các chi tiết liệu mà tổ chức hệ thống Những mô tả qui trình mà hệ thống yêu cầu xử lý Các báo cáo kết xuất Câu 18 Chọn lựa sau mô tả yêu cầu chức năng? A) Hệ thống phải có khả trả lời tất truy vấn giây B) Các người sử dụng hệ thống gây lỗi 50% so với hệ thống C) Hệ thống phải cho phép người sử dụng nhập vào chi tiết chiến dịch quảng cáo D) Hàng tháng, báo cáo phải nộp lên giám đốc trước ngày tháng sau Câu 19 Ví dụ sau yêu cầu phi chức năng? A) Phân chia ổ đĩa liệu B) Các yêu cầu xử lý C) Nội dung báo cáo in theo yêu cầu hệ thống D) Tất mục Câu 20 Chọn lựa sau mô tả yêu cầu phi chức năng? A) Hệ thống phải có khả lưu trữ ban đầu 500MB liệu, năm tăng lên 100MB B) Hệ thống phải phát sinh báo cáo tất chiến dịch quảng cáo cho khách hàng cụ thể C) Hệ thống phải cho phép người sử dụng nhập vào chi tiết khách hàng D) Tất Câu Câu 21 Trong lược đồ use case sau, phát biểu nào là sai A) “Kiểm tra ngân quỹ chiến dịch” là use case bản B) “Kiểm tra ngân quỹ chiến dịch” là use case mở rộng được khởi động từ use case "In tóm tắt chiến dịch" C) “In tóm tắt chiến dịch” là use case bản D) Tất sai 22 Nguyên tắc kiểm thử nào sau là sai: Phải lên kế hoạch kiểm thử sớm giai đoạn phân tích hệ thống Có thể thực hiện kiểm thử được toàn bộ mọi trường hợp có thể có của hệ thống Để hiệu quả, kiểm thử nên được thực hiện bởi một đội kiểm thử Tuân theo nguyên tắc Pareto 22 Kỹ thuật gì nên dùng cho kiểm thử đơn vị: a Kỹ thuật hộp trắng b Kỹ thuật hộp đen c Cả hai kỹ thuật hộp đen và trắng d Kỹ thuật hồi quy (regression) 23 Dạng kiểm thử nào sau không thuộc kiểm thử hộp trắng: a Kiểm thử điều kiện (Condition testing) b Kiểm thử dòng dữ liệu ( Data flow testing) c Kiểm thử vòng lặp (Loop testing) d Phân hoạch lớp tương đương (equivalent class partition) 24 Dạng kiểm thử nào sau không thuộc kiểm thử hộp đen: a Kiểm thử điều kiện (Condition testing) b Phân tích giá trị biên (boundary value analysis) c Kiểm thử chuyển đổi trạng thái (State Transition Testing) d Đoán lỗi (Error Guessing) 25 Xét đoạn mã giả sau: Cần tối thiểu test case để độ bao phủ rẽ nhánh (branch coverage) là 100% a b c d 26 Xét chương trình tính phí cho việc thuê băng video sau: Float calcRentalFee(Tape[] tapes, Customer customer){ float total = 0; for(int I = 0; I < tapes.length; I++){ total += tapes[I].price; } if (tapes.length > 10){ total *= 8; } else if(tapes.length > 5){ total *= 9; } if(customer.isPremium()){ total *= 9; } return total; } Nếu có các test case sau: Test case với tapes=[5,6,10,3,5,7,8] và Customer.isPremium = true Test case với tapes=[5,6,4,5,7,3,6,7,4,5,3,2] và Customer.isPreminum = true Test case với tapes=[5,6,4,5] và Customer.isPreminum = false Thì tổ hợp các test case nào có độ bao phủ về lệnh (statement coverage) 100% a Test case và b Test case và c Test case và d Cả test case 27 Hoạt động sau thuộc loại bảo trì “Phát sớm sửa sai khuyết điểm vừa phát trước chúng trở thành khuyết điểm chính” a Bảo trì sửa lỗi (Corrective maintenance) b Bảo trì thích nghi (Adaptive maintenance) c Bảo trì hoàn chỉnh (Perfective maintenance) d Bảo trì phòng tránh (Preventive maintenance) 28 Hoạt động sau thuộc loại bảo trì “Làm cho hệ thống tốt hơn, nhanh hơn, nhỏ hơn, tài liệu đầy đủ hơn” a Bảo trì sửa lỗi (Corrective maintenance) b Bảo trì thích nghi (Adaptive maintenance) c Bảo trì hoàn chỉnh (Perfective maintenance) d Bảo trì phòng tránh (Preventive maintenance) 29 Khi phần mềm bị lỗi, cách để khắc phục “dùng miếng vá khẩn cấp (patching)” Biện pháp có tác dụng phụ gì? a Tăng độ phức tạp chương trình b Tạo hiệu “ripple effect” c Tăng độ bảo mật cho chương trình d.Tất chọn lựa