Font size
S
M
L
XL
Worksheets100Q-CNPM_[PDK]
Total questions: 103
Worksheet time: 52mins
Name
Class
Date
1.
Phần mềm được định nghĩa như thế nào?
a)
Là tập hợp các thiết bị phần cứng trong hệ thống
b)
Là tập hợp các tài liệu hướng dẫn vận hành phần cứng
c)
Là chương trình máy tính cùng tài liệu đi kèm phục vụ sử dụng, phát triển và bảo trì
d)
Là ngôn ngữ lập trình và hệ điều hành
2.
Phần mềm khác phần cứng ở điểm nào?
a)
Phần mềm có thể sờ nắm được, phần cứng thì không
b)
Phần mềm mang tính logic, phần cứng mang tính vật lý
c)
Phần mềm rẻ hơn phần cứng
d)
Phần mềm bền vững hơn phần cứng
3.
Các thành phần cấu thành nên phần mềm gồm
a)
Chương trình, tài liệu, dữ liệu cấu hình
b)
Chỉ có chương trình thực thi
c)
Phần cứng và tài liệu hướng dẫn
d)
Ngôn ngữ lập trình và hệ điều hành
4.
Phần mềm khác với phần cứng ở điểm nào?
a)
Có thể nhìn thấy trực tiếp
b)
Khó bảo trì hơn phần cứng
c)
Không thể hỏng
d)
Sản xuất hàng loạt dễ dàng
5.
Hệ thống thông tin gồm những phần tử nào?
a)
Con người, phần cứng, phần mềm, quy trình, dữ liệu
b)
Con người, máy móc, tiền tệ
c)
Chỉ phần cứng và phần mềm
d)
Phần mềm và mạng máy tính
6.
Sai sót phần mềm (ví dụ Y2K, Ariane 5) thường dẫn đến:
a)
Tăng năng suất ngay lập tức
b)
Tổn thất kinh tế lớn và rủi ro hệ thống
c)
Tự phục hồi mà không can thiệp
d)
Chỉ ảnh hưởng phần cứng
7.
Vấn đề Y2K chủ yếu liên quan đến:
a)
Thiết kế phần cứng CPU
b)
Lỗi xử lý ngày tháng trong phần mềm
c)
Lỗi đường truyền mạng
d)
Lỗi trình biên dịch
8.
Đặc trưng cơ bản của phần mềm là:
a)
Dễ đo lường trực tiếp chất lượng
b)
Không thay đổi theo thời gian
c)
Mang tính logic, khó kiểm soát việc sản xuất & chất lượng
d)
Có thể lắp ghép theo phụ tùng vật lý
9.
Tiêu chí một phần mềm “tốt” gồm:
a)
Đáng tin cậy, dễ bảo trì, hiệu quả kinh tế
b)
Giảm tài liệu xuống tối thiểu
c)
Chạy nhanh nhưng khó bảo trì
d)
Không cần kiểm thử
10.
Tại sao bảo trì phần mềm thường phức tạp?
a)
Phần mềm có danh mục phụ tùng đầy đủ
b)
Phần mềm thoái hóa theo thời gian do môi trường và yêu cầu thay đổi
c)
Phần cứng dễ thay thế hơn phần mềm
d)
Vì phần mềm không có tài liệu
11.
Phần mềm máy tính cá nhân thường đặc trưng bởi:
a)
Điều khiển thiết bị thời gian thực
b)
Giao diện đồ họa phát triển và nhu cầu sử dụng rộng
c)
Yêu cầu thời gian thực cực kỳ chặt chẽ
d)
Là phần mềm nhúng
12.
Phần mềm nhúng thường:
a)
Được cài trên máy chủ doanh nghiệp
b)
Thực hiện chức năng hạn chế, gắn chặt với thiết bị
c)
Phục vụ phân tích tính toán khoa học phức tạp
d)
Là phần mềm văn phòng
13.
Vì sao phần mềm phải tiến hóa liên tục?
a)
Vì phần mềm ít phức tạp hơn phần cứng
b)
Do yêu cầu người dùng và môi trường thay đổi liên tục
c)
Vì ngôn ngữ lập trình luôn ổn định
d)
Do phần cứng không thay đổi
14.
Sản phẩm phần mềm bao gồm những gì?
a)
Chương trình (đơn vị thực thi), mã nguồn, tài liệu (HDSD, cài đặt, kỹ thuật)
b)
Chỉ mã nguồn
c)
Chỉ tài liệu người dùng
d)
Chỉ tệp thực thi
15.
Kỹ nghệ phần mềm (Software Engineering) là:
a)
Một tập hợp phương pháp, thủ tục và công cụ để phát triển phần mềm một cách có hệ thống
b)
Chỉ là nghệ thuật viết chương trình
c)
Chỉ là quản lý dự án phần cứng
d)
Là việc mua bán phần mềm
16.
CASE tools (Computer-Aided Software Engineering) dùng để:
a)
Tự động hóa, hỗ trợ phân tích, thiết kế và một số tác vụ phát triển
b)
Viết mail nội bộ công ty
c)
Thay thế hoàn toàn con người trong phát triển
d)
Giữ bí mật tài liệu
17.
Cấu trúc phát triển phần mềm truyền thống nhấn mạnh:
a)
Lập trình theo bản năng, không có phương pháp
b)
Thiết kế top-down, lập trình có cấu trúc, phân modular
c)
Chỉ dùng mã máy
d)
Chỉ dùng phương pháp Agile
18.
Trong lịch sử phát triển phần mềm, xu hướng lớn là:
a)
Giảm quy mô phần mềm theo thời gian
b)
Tăng tính modul hóa, hướng đối tượng, tái sử dụng, công cụ hỗ trợ (UML, RUP, CASE)
c)
Trở về mã máy thuần túy
d)
Loại bỏ tài liệu thiết kế
19.
Phân loại phần mềm theo mục tiêu sử dụng gồm:
a)
Hệ thống, thời gian thực, nghiệp vụ, khoa học kỹ thuật, nhúng, PC, AI, công cụ kỹ thuật
b)
Chỉ có hai loại: tốt & xấu
c)
Chỉ phần mềm nhúng và phần mềm web
d)
Phần mềm không có phân loại
20.
Khi phát triển “sản phẩm đặt hàng” khác với “sản phẩm bán rộng” ở chỗ:
a)
Sản phẩm đặt hàng chung cho nhiều khách hàng
b)
Sản phẩm đặt hàng thường có yêu cầu đặc thù, một đơn chiếc
c)
Sản phẩm bán rộng luôn tùy biến cao cho từng khách hàng
d)
Không có khác biệt
21.
“Phần mềm là phần tử logic” nghĩa là:
a)
Có cấu trúc vật lý giống phần cứng
b)
Khó kiểm soát quá trình xây dựng bằng các phép đo vật lý, đòi hỏi phương pháp & công cụ
c)
Không cần kiểm thử
d)
Dễ dàng tự sửa lỗi
22.
Vai trò phần mềm đối với tổ chức và kinh tế là:
a)
Không quan trọng
b)
Tạo lợi thế cạnh tranh, quyết định năng suất và có tác động lớn đến nền kinh tế
c)
Chỉ dùng cho thí nghiệm học thuật
d)
Thay thế hoàn toàn con người
23.
Tại sao phần mềm ngày càng chi phí cao hơn phần cứng trong hệ thống?
a)
Vì phần cứng rẻ đi nhiều theo Moore
b)
Vì phần mềm phức tạp, cần nhân lực và bảo trì lâu dài
c)
Vì phần cứng hiếm hơn phần mềm
d)
Vì phần mềm không cần kiểm thử
24.
Tiến trình phần mềm (software process) thường gồm các hoạt động chính nào?
a)
Đặc tả (xác định yêu cầu), phát triển (thiết kế & mã hóa), thẩm định (kiểm thử), tiến hoá (bảo trì)
b)
Chỉ mã hóa và nộp sản phẩm
c)
Bán hàng, marketing, bảo trì
d)
Chỉ viết tài liệu
25.
Mô hình thác nước (Waterfall) có đặc điểm gì?
a)
Các pha tách biệt, thực hiện theo thứ tự và ít lặp lại
b)
Luôn phản hồi nhanh với thay đổi yêu cầu
c)
Không cần tài liệu
d)
Luôn tạo phiên bản chạy sớm
26.
Nhược điểm lớn của mô hình thác nước là:
a)
Phù hợp khi yêu cầu chưa rõ
b)
Khó đáp ứng yêu cầu thay đổi và phát hiện lỗi muộn
c)
Không có chuyên trách cho từng pha
d)
Luôn nhanh ra sản phẩm
27.
Khi nào mô hình thác nước là lựa chọn hợp lý?
a)
Khi yêu cầu được hiểu rõ, ổn định và dễ đặc tả kỹ lưỡng
b)
Khi khách hàng không muốn tài liệu
c)
Khi dự án rất ngắn (vài tuần) và cần prototype nhanh
d)
Khi rủi ro kỹ thuật rất cao
28.
Mô hình lập bản mẫu (prototyping) có ưu điểm:
a)
Giúp nhanh chóng xác định yêu cầu chưa rõ thông qua mẫu chạy hoặc mock-up
b)
Luôn tạo phần mềm có cấu trúc cao
c)
Không cần sự tham gia của người dùng
d)
Loại trừ hoàn toàn rủi ro dự án
29.
Nhược điểm thường gặp của prototyping là:
a)
Cấu trúc hệ thống có thể kém, khách hàng khó tin tưởng nếu mẫu quá thô sơ
b)
Luôn tốn chi phí thấp
c)
Không thể dùng để huấn luyện người dùng
d)
Luôn phù hợp tất cả dự án
30.
Mô hình xoắn ốc (spiral) khác các mô hình khác bằng việc:
a)
Bỏ qua kiểm thử
b)
Nhấn mạnh phân tích rủi ro và tiến hóa theo vòng lặp có kiểm soát rủi ro
c)
Làm việc chỉ một lần duy nhất qua các pha
d)
Không cần giao tiếp với khách hàng
31.
Điểm yếu của mô hình xoắn ốc là:
a)
Không kiểm soát rủi ro
b)
Đòi hỏi năng lực quản lý & phân tích rủi ro cao, có thể tốn kém chuyên gia
c)
Không thể tạo bản mẫu
d)
Không dùng cho dự án lớn
32.
Phát triển dựa trên sử dụng lại (reuse-based development) chủ yếu là:
a)
Viết lại toàn bộ mã nguồn từ đầu
b)
Tích hợp các thành phần, thư viện hoặc hệ thống sẵn có để giảm công sức
c)
Không dùng tài liệu
d)
Không tích hợp các phần bên ngoài
33.
RAD (Rapid Application Development) phù hợp khi:
a)
Hệ thống khó chia module, hiệu năng rất cao bắt buộc
b)
Có khả năng module hóa cao, cần phát triển nhanh (ví dụ 60–90 ngày)
c)
Dự án không yêu cầu thử nghiệm
d)
Không có công cụ hỗ trợ tự động
34.
XP (Extreme Programming) nhấn mạnh điều gì?
a)
Tài liệu nặng, ít viết mã
b)
Phát triển từng phần nhỏ, giao tiếp chặt, lập trình theo cặp, refactor thường xuyên
c)
Không có kiểm thử tự động
d)
Tập trung vào dự án một người làm
35.
4GT (Fourth Generation Technology) thường chỉ ra:
a)
Kỹ thuật viết mã máy thuần túy
b)
Công cụ cho phép mô tả đặc tả mức cao và tự sinh mã (ví dụ báo cáo, giao diện)
c)
Loại bỏ lập trình viên
d)
Chỉ dành cho hệ thống nhúng
36.
Phát triển hệ thống hình thức (formal methods) thích hợp cho:
a)
Các hệ thống cần đảm bảo an toàn, bảo mật cao (ví dụ hàng không, y tế)
b)
Ứng dụng văn phòng đơn giản
c)
Dự án không có thời hạn
d)
Chỉ cho prototyping
37.
Mô hình tăng dần (incremental/incremental delivery) có lợi ích là:
a)
Không bao giờ phát hành bản chạy được
b)
Cho phép giao các phiên bản nhỏ, sớm có chức năng và thu phản hồi nhanh
c)
Làm chậm quá trình thu thập yêu cầu
d)
Không phù hợp với Agile
38.
Mô hình tiến trình có thể được nhìn từ các góc độ nào?
a)
Chỉ luồng công việc
b)
Luồng công việc, luồng dữ liệu, vai trò/hành động
c)
Chỉ luồng dữ liệu
d)
Chỉ vai trò/hành động
39.
RUP (Rational Unified Process) liên quan nhiều đến:
a)
Mô hình cổ điển không lặp lại
b)
Phương pháp hướng đối tượng, giai đoạn lặp và công cụ UML hỗ trợ
c)
Chỉ dùng cho phần mềm nhúng
d)
Không có tài liệu hướng dẫn
40.
Agile nói chung ưu tiên điều gì?
a)
Tài liệu dài đầy đủ hơn code
b)
Giao tiếp với khách hàng, phản hồi nhanh, giao nộp từng phần chức năng nhỏ
c)
Bỏ qua kiểm thử
d)
Lập kế hoạch cố định và không thay đổi
41.
Mô hình “phát triển tiến hóa” nghĩa là:
a)
Tạo một phiên bản chính thức duy nhất rồi dừng lại
b)
Phát triển phần mềm qua nhiều phiên bản, dần hoàn thiện theo yêu cầu thay đổi
c)
Không dùng quản lý cấu hình
d)
Chỉ dùng trong giáo dục
42.
Mô hình “bản mẫu dùng xong bỏ đi” (throwaway prototype) phù hợp khi:
a)
Muốn thử nhanh yêu cầu giao diện hay thao tác rồi loại bỏ mã mẫu
b)
Muốn dùng mã mẫu làm sản phẩm chính thức
c)
Không muốn tương tác với người dùng
d)
Luôn tạo ra phần mềm có cấu trúc tốt
43.
Khi nào nên dùng phương pháp hình thức (formal methods)?
a)
Khi dự án nhỏ, không quan trọng
b)
Khi yêu cầu bảo đảm tính chính xác toán học và an toàn cao
c)
Khi khách hàng không thích tài liệu
d)
Khi muốn phát triển nhanh trong vòng 1 tuần
44.
“Luồng dữ liệu” trong mô hình tiến trình mô tả:
a)
Trình tự thực hiện các hoạt động
b)
Các dữ liệu di chuyển giữa các hoạt động và sản phẩm trung gian
c)
Chỉ người thực hiện công việc
d)
Thời hạn dự án
45.
Mô hình nào thêm phân tích rủi ro vào tiến trình phát triển?
a)
Waterfall
b)
Spiral (xoắn ốc)
c)
Prototyping
d)
No-model
46.
Phát triển “dựa trên thành phần” (component-based) giúp:
a)
Tăng phát minh mọi thứ từ đầu
b)
Tái sử dụng thành phần sẵn có, giảm thời gian và chi phí phát triển
c)
Loại bỏ cần QA (kiểm thử)
d)
Không cần thiết kế hệ thống
47.
Mô hình nào thích hợp khi yêu cầu I/O và thuật toán chưa rõ ràng nhưng giao diện cần tương tác?
a)
Waterfall
b)
Prototyping
c)
Formal methods
d)
Strict sequential plan
48.
“Mức độ mẫu” (prototyping levels) không bao gồm:
a)
Bản mẫu trên giấy
b)
Bản mẫu mô tả toàn bộ hệ thống vận hành 100% chính xác tự động
c)
Bản mẫu giao diện
d)
Bản mẫu dùng tạm và bản mẫu dùng lại cho bước sau
49.
Một trong những mục tiêu của các mô hình tiến trình là:
a)
Loại bỏ hoàn toàn rủi ro trong dự án
b)
Đưa ra khung làm việc để lập kế hoạch, quản lý và kiểm soát phát triển phần mềm
c)
Chỉ phục vụ cho nhóm lập trình viên cá nhân
d)
Không cần phản hồi từ khách hàng
50.
Mô hình “formal systems development” thường yêu cầu:
a)
Kỹ năng đặc thù về mô tả hình thức và kỹ thuật tiên tiến
b)
Không cần đào tạo, ai cũng làm được
c)
Không dùng khi cần an toàn
d)
Không có giới hạn ứng dụng
51.
Mô hình nào phù hợp với hệ thống có yêu cầu bảo mật và an toàn rất cao?
a)
XP
b)
Formal systems development
c)
Throwaway prototyping
d)
RAD
52.
“Pareto (80-20)” trong quản lý rủi ro có ý nghĩa là:
a)
80% rủi ro gây 20% hậu quả
b)
Tập trung vào 20% vấn đề trọng yếu có thể giải quyết 80% tác động
c)
Luôn loại bỏ 80% yêu cầu
d)
Không áp dụng cho phần mềm
53.
Phát triển theo hướng đối tượng (OOP) hỗ trợ gì cho tiến trình?
a)
Làm tăng sự phụ thuộc giữa các module
b)
Che dấu thông tin, tái sử dụng, dễ bảo trì và mở rộng
c)
Loại bỏ kiểm thử
d)
Không tương thích với UML
54.
Mục tiêu chính của quản lý dự án phần mềm là:
a)
Giảm thời gian phát triển bằng mọi giá
b)
Đảm bảo đúng thời hạn, đúng chức năng, không vượt chi phí và thỏa mãn khách hàng
c)
Chỉ tập trung vào chất lượng kỹ thuật, bỏ qua tiến độ
d)
Lập càng nhiều tài liệu càng tốt
55.
Trách nhiệm của người quản lý dự án không bao gồm:
a)
Lập lịch, điều phối tài nguyên, quản lý rủi ro
b)
Quản lý chất lượng và giám sát tiến độ
c)
Viết toàn bộ mã nguồn cho dự án
d)
Xác định mốc (milestones) và xuất phẩm (deliverables)
56.
Cột mốc (milestone) trong dự án là gì?
a)
Khoản tiền thanh toán
b)
Điểm kết thúc của một hoạt động với xuất phẩm rõ ràng để kiểm tra tiến độ
c)
Một bug trong phần mềm
d)
Ngày nghỉ lễ của tổ chức
57.
Tài liệu cần thiết khi viết đề án dự án thường gồm:
a)
Tài liệu mô hình nghiệp vụ, giải pháp, khả thi, ước lượng sơ bộ
b)
Chỉ bảng giá bán
c)
Chỉ mã nguồn mẫu
d)
Không cần tài liệu
58.
Khi lập lịch, cần xác định:
a)
Nhiệm vụ, thời điểm bắt đầu/kết thúc, người thực hiện, các ràng buộc giữa nhiệm vụ
b)
Chỉ tên dự án và ngân sách
c)
Chỉ số lượng máy chủ cần mua
d)
Chỉ ngày giao phần mềm cuối cùng
59.
Lập lịch tốt giúp:
a)
Tăng tối đa thời gian nhàn rỗi cho nhân viên
b)
Kiểm soát tiến độ, tối ưu sử dụng nguồn lực, giảm phụ thuộc không cần thiết
c)
Loại bỏ hoàn toàn rủi ro yêu cầu thay đổi
d)
Giảm số lượng tài liệu cần thiết
60.
Giám sát và điều chỉnh trong quản lý dự án nhằm:
a)
Đảm bảo chất lượng, tuân thủ quy trình, quản lý thay đổi và cấu hình phần mềm
b)
Giảm chi phí bằng cách cắt nhân sự đột ngột
c)
Bỏ kiểm thử để tiết kiệm thời gian
d)
Tự động tạo mã nguồn mới
61.
Phương pháp quản lý thay đổi (change management) cần làm gì?
a)
Cho phép thay đổi vô hạn mà không kiểm soát
b)
Xác định, phê duyệt, theo dõi và cập nhật cấu hình sản phẩm khi có thay đổi
c)
Xóa toàn bộ lịch sử phiên bản cũ
d)
Không liên quan đến quản lý cấu hình
62.
Software Quality Assurance (SQA) là hoạt động:
a)
Tập trung kiểm thử cuối cùng trước giao sản phẩm, không tham gia quá trình phát triển
b)
Công việc xuyên suốt để đảm bảo chất lượng phần mềm và tuân thủ chuẩn
c)
Chỉ là viết báo cáo để nộp khách hàng
d)
Chỉ do quản lý dự án thực hiện một lần
63.
Các mức kiểm thử thường gồm:
a)
Unit test, Integration test, System test, Alpha, Beta
b)
Chỉ Unit test và System test
c)
Chỉ Alpha và Beta
d)
Không cần phân cấp mức test
64.
Rủi ro dự án khác rủi ro sản phẩm ở điểm nào?
a)
Rủi ro dự án tác động đến tiến độ và nguồn lực; rủi ro sản phẩm tác động đến chất lượng/hiệu năng
b)
Không khác nhau
c)
Rủi ro sản phẩm chỉ liên quan đến phần cứng
d)
Rủi ro dự án chỉ là lỗi code nhỏ
65.
Hoạt động quản lý rủi ro gồm:
a)
Xác định, phân tích, lập kế hoạch ứng phó, giám sát và đánh giá lại rủi ro
b)
Chỉ xác định rủi ro 1 lần ban đầu
c)
Chỉ dựa vào may rủi
d)
Chỉ phớt lờ rủi ro nhỏ
66.
Biện pháp giảm rủi ro nhân sự gồm:
a)
Tuyển người dở nhất để tiết kiệm chi phí
b)
Sử dụng người giỏi, làm việc theo nhóm, đào tạo người mới
c)
Không cho phép nghỉ phép cho nhân viên
d)
Không lập hồ sơ năng lực nhân sự
67.
Pareto (80-20) trong quản lý rủi ro ám chỉ:
a)
80% rủi ro không đáng quan tâm
b)
20% yếu tố quan trọng thường gây 80% tác động và cần ưu tiên xử lý
c)
Luôn phân chia đội thành 80%/20%
d)
Không áp dụng cho phần mềm
68.
Một cách ứng phó với rủi ro ước lượng (dự toán sai) là:
a)
Chỉ chấp nhận vượt ngân sách
b)
Ước lượng lại nhiều lần, phân loại, loại bỏ yêu cầu thứ yếu
c)
Bỏ qua ước lượng ban đầu
d)
Tuyển thêm người không có kinh nghiệm để rút ngắn thời gian
69.
Khi phát triển sai chức năng (không đúng business), biện pháp hữu hiệu là:
a)
Bỏ qua phản hồi khách hàng
b)
Phân tích nghiệp vụ, làm bản mẫu và tạo kịch bản sử dụng để xác minh
c)
Thay đổi công nghệ để che lấp lỗi
d)
Tự động sửa code bằng công cụ AI mà không làm rõ yêu cầu
70.
Trong tổ chức dự án, kích thước nhóm tối ưu thường được khuyến nghị là:
a)
50–100 người
b)
3–8 người cho mô-đun nhỏ; dự án lớn cần phân tách thành nhiều nhóm nhỏ
c)
Luôn 1 người là tốt nhất
d)
Càng lớn càng tốt để nhanh hoàn thành
71.
Sử dụng phần mềm đóng gói/đã có sẵn (COTS) trong dự án có lợi:
a)
Luôn đảm bảo không cần tuỳ chỉnh
b)
Giảm thời gian phát triển, tận dụng lại giải pháp đã kiểm chứng
c)
Luôn rẻ hơn tự phát triển hoàn toàn
d)
Loại bỏ nhu cầu kiểm thử tích hợp
72.
Quản lý cấu hình (configuration management) phục vụ:
a)
Lưu trữ mã nguồn mà không theo phiên bản
b)
Kiểm soát phiên bản, thay đổi, và đảm bảo tái tạo được các bản phát hành
c)
Loại bỏ khả năng rollback (quay lui)
d)
Không liên quan đến QA
73.
Chi phí lớn nhất trong vòng đời phần mềm thường thuộc về:
a)
Việc viết mã ban đầu
b)
Bảo trì (sửa lỗi, thích nghi, nâng cao) chiếm tỷ trọng lớn (thường >50%)
c)
In ấn tài liệu
d)
Mua phần cứng
74.
Khi lập kế hoạch dự án, “phân đoạn công việc” (Work Breakdown Structure) dùng để:
a)
Xác định các nhiệm vụ nhỏ, ước lượng thời gian & nguồn lực cho từng phần
b)
Chỉ để liệt kê tên nhân viên
c)
Làm báo cáo tài chính
d)
Thay thế testing
75.
Công cụ ước lượng (ví dụ COCOMO) được dùng để:
a)
Xuất mã tự động
b)
Ước lượng nỗ lực, thời gian và chi phí dự án dựa trên kích thước và hệ số điều chỉnh
c)
Thay thế lập kế hoạch chuyên gia
d)
Chỉ dùng cho phần mềm nhúng
76.
“Deliverable” (xuất phẩm) là:
a)
Một nhiệm vụ chưa hoàn thành
b)
Sản phẩm cụ thể (tài liệu, mã nguồn, prototype) bàn giao cho khách hàng hoặc nội bộ tại mốc nhất định
c)
Chỉ là email thông báo tiến độ
d)
Một bug report
77.
Khi dự án gặp thay đổi yêu cầu liên tục từ khách, quản lý nên:
a)
Từ chối mọi thay đổi
b)
Áp dụng cơ chế quản lý thay đổi, đánh giá tác động và tái ước lượng kế hoạch; cân nhắc mô hình tiến hóa/xoắn ốc/Agile
c)
Thực hiện ngay thay đổi mà không kiểm tra
d)
Hủy dự án
78.
Việc phân bổ tài nguyên trong dự án cần cân nhắc:
a)
Chỉ dựa vào kinh nghiệm cá nhân mà không ước lượng
b)
Năng lực, mặt bằng thời gian, phụ thuộc giữa nhiệm vụ và tối ưu hóa song song khi có thể
c)
Không quan tâm đến ràng buộc phần cứng
d)
Chỉ quan tâm số lượng nhân lực, không quan tâm năng lực
79.
Kiểm soát tiến độ dự án thường thực hiện qua:
a)
Không theo dõi gì cả
b)
So sánh thực tế vs kế hoạch, cập nhật lịch, điều phối lại nguồn lực, họp review định kỳ
c)
Chỉ dựa vào cảm giác của PM
d)
Không thay đổi lịch khi có trục trặc
80.
“Xét duyệt” (review) tài liệu ở mỗi pha nhằm mục đích:
a)
Tăng số lượng tài liệu để nộp cho quản lý
b)
Phát hiện lỗi sớm, ngăn chuyển lỗi sang pha sau, đảm bảo chất lượng và sự đồng thuận nhóm
c)
Hoãn việc kiểm thử
d)
Tiết kiệm thời gian test
81.
Một rủi ro công nghệ (technology risk) có thể là:
a)
Thiếu người dùng
b)
Công nghệ mới chưa trưởng thành, khó tích hợp hoặc chưa có công cụ hỗ trợ đủ mạnh
c)
Lỗi do con người trong thanh toán tiền lương
d)
Thiếu máy in trong văn phòng
82.
Ví dụ biện pháp giảm rủi ro: “không phát triển được GUI” — giải pháp hợp lý là:
a)
Bỏ GUI hoàn toàn
b)
Làm bản mẫu giao diện, dùng công cụ/mẫu giao diện có sẵn hoặc thuê chuyên gia UI
c)
Đợi tới trước ngày giao sản phẩm rồi làm vội
d)
Giao phần việc cho người mới hoàn toàn chưa có kinh nghiệm
83.
Khi đánh giá đội dự án, yếu tố quan trọng nhất thường là:
a)
Số lượng người nhiều nhất có thể
b)
Năng lực con người (cá nhân giỏi có giá trị cao hơn nhiều), kỹ năng chuyên môn và khả năng làm việc nhóm
c)
Tuổi trung bình của nhóm
d)
Nhân viên có nhiều bằng cấp nhất
84.
Mục tiêu phân tích yêu cầu là:
a)
Xác định chức năng, ràng buộc, nghiệp vụ và tạo đặc tả yêu cầu rõ ràng cho thiết kế
b)
Viết mã nguồn luôn
c)
Tạo giao diện người dùng cuối cùng ngay lập tức
d)
Bỏ qua sự tham gia khách hàng
85.
Thiết kế phần mềm thường bao gồm:
a)
Thiết kế kiến trúc, mô hình dữ liệu, thiết kế thủ tục/xử lý và giao diện người dùng
b)
Chỉ viết test cases
c)
Chỉ là công việc của người quản lý
d)
Không liên quan đến yêu cầu
86.
Kiểm thử đơn vị (unit test) thường do ai thực hiện?
a)
Người lập trình (developer)
b)
Người dùng cuối
c)
Quản lý dự án
d)
Nhà tài trợ
87.
Kiểm thử tích hợp nhắm tới:
a)
Kiểm tra các thành phần khi kết hợp với nhau (interfaces, interaction)
b)
Chỉ kiểm tra tính năng UI
c)
Kiểm tra tài liệu người dùng
d)
Chỉ test database performance
88.
Kiểm thử hệ thống (system test) là:
a)
Kiểm tra toàn bộ hệ thống trong môi trường gần với thực tế để xác định đáp ứng yêu cầu
b)
Tương đương với unit test
c)
Chỉ do developer thực hiện
d)
Không cần dữ liệu thật
89.
Kiểm thử Alpha thường là:
a)
Kiểm thử nội bộ tại xưởng với dữ liệu thật trước khi phát hành beta cho người dùng
b)
Kiểm thử bởi toàn bộ khách hàng trên thị trường
c)
Không bao giờ dùng trong công nghiệp
d)
Thay thế hoàn toàn unit test
90.
Kiểm thử Beta thường là:
a)
Kiểm thử nội bộ sớm nhất
b)
Thử nghiệm sản phẩm bởi một nhóm người dùng thật để thu phản hồi trước khi phát hành chính thức
c)
Loại kiểm thử kỹ thuật duy nhất cần thiết
d)
Kiểm thử không cần tài liệu
91.
Phân biệt Verification và Validation:
a)
Verification (xác minh) = “Bạn xây đúng sản phẩm theo spec?”; Validation (xác nhận) = “Bạn xây sản phẩm đúng nhu cầu người dùng?”
b)
Hai khái niệm giống nhau hoàn toàn
c)
Verification do người dùng thực hiện; Validation do lập trình viên làm
d)
Chỉ áp dụng cho phần cứng
92.
Black-box testing kiểm tra:
a)
Cấu trúc bên trong của chương trình
b)
Đầu vào/đầu ra & chức năng theo đặc tả mà không xem mã nguồn
c)
Chỉ performance của hệ thống
d)
Chỉ check style code
93.
White-box testing kiểm tra:
a)
Chức năng hệ thống theo spec
b)
Cấu trúc bên trong, luồng điều khiển và từng nhánh trong mã nguồn
c)
Chỉ UI
d)
Chỉ do người dùng thực hiện
94.
Gray-box testing là:
a)
Kết hợp hiểu biết về cấu trúc nội bộ và kiểm thử theo chức năng từ bên ngoài
b)
Chỉ là black-box testing nhưng đổi tên
c)
Không hữu ích trong thực tế
d)
Thay thế unit test
95.
Các loại bảo trì phần mềm không bao gồm:
a)
Sửa lỗi (corrective)
b)
Thích nghi (adaptive) — thay đổi để phù hợp môi trường mới
c)
Nâng cao (perfective/enhancement) — thêm chức năng mới
d)
Bảo trì vật lý phần cứng (hardware maintenance)
96.
Việc tích hợp các thành phần trước khi kiểm thử toàn hệ thống gọi là:
a)
Unit testing
b)
Integration testing
c)
Deployment
d)
Documentation review
97.
“Code review” (xem xét mã nguồn) nhằm mục đích:
a)
Phát hiện lỗi sớm, chia sẻ kiến thức và đảm bảo chất lượng mã nguồn
b)
Chỉ phê bình nhân viên
c)
Làm việc chỉ của quản lý dự án
d)
Thay thế hoàn toàn unit test
98.
Yêu cầu tốt nên có đặc điểm:
a)
Mơ hồ để dễ phát triển linh hoạt
b)
Rõ ràng, có thể kiểm tra, không mâu thuẫn, có thể đo lường được
c)
Chỉ miêu tả cảm giác người dùng
d)
Không cần phân loại (chức năng/phi chức năng)
99.
Tài liệu “test plan” thường chứa:
a)
Mục tiêu kiểm thử, phạm vi, chiến lược, môi trường, nguồn lực và lịch trình kiểm thử
b)
Chỉ danh sách tester tên họ
c)
Chỉ kết quả test cuối cùng
d)
Không cần thiết nếu có Agile
100.
Khi cập nhật phần mềm, quản lý phiên bản (versioning) quan trọng vì:
a)
Giúp người dùng nhớ mật khẩu
b)
Cho phép theo dõi, rollback, và phân phối các release khác nhau một cách có kiểm soát
c)
Làm chậm quá trình phát hành mà không lợi ích
d)
Thay thế testing
101.
Hồ sơ “bug report” tốt cần có:
a)
Chỉ tiêu đề ngắn gọn
b)
Mô tả chi tiết lỗi, bước tái tạo, dữ liệu dùng, môi trường, mức độ ưu tiên và logs nếu có
c)
Chỉ ID và ngày giờ
d)
Không cần người kiểm thử ký tên
102.
Chỉ số “chi phí tìm và sửa lỗi” tăng khi lỗi được phát hiện muộn vì:
a)
Lỗi muộn ít quan trọng
b)
Sửa lỗi ở giai đoạn sau (ví dụ sau khi sản phẩm đã triển khai) thường tốn thời gian, ảnh hưởng nhiều thành phần hơn
c)
Không ảnh hưởng đến chi phí
d)
Lỗi muộn dễ fix hơn
103.
Sau khi bàn giao sản phẩm, hoạt động “tiến hoá” (evolution) của phần mềm bao gồm:
a)
Sửa lỗi, thích nghi môi trường mới, nâng cao chức năng theo nhu cầu thay đổi
b)
Ngưng mọi hoạt động với phần mềm
c)
Xóa code cũ và viết lại mọi thứ ngay lập tức
d)
Chỉ chạy backup dữ liệu
Reset
