Font size
WorksheetsTEST_P1
Total questions: 100
Worksheet time: 58mins
Phân tích yêu cầu là khâu nào trong tiến trình phát triển phần mềm?
Khâu đầu tiên về kỹ thuật
Khâu cuối cùng trước triển khai
Khâu sau khi thiết kế
Khâu kiểm thử
Đặc tả yêu cầu phần mềm là gì?
Bản thiết kế hệ thống
Cơ sở để ký kết hợp đồng giữa khách hàng và nhà phát triển
Tài liệu hướng dẫn sử dụng
Kế hoạch kiểm thử
Nếu xác định yêu cầu sai, hậu quả là:
Không ảnh hưởng đến chi phí
Tăng chi phí phát triển rất nhiều
Hệ thống chạy nhanh hơn
Hệ thống dễ bảo trì hơn
Giai đoạn đầu tiên của kỹ nghệ yêu cầu là gì?
Đặc tả yêu cầu
Nghiên cứu khả thi
Thẩm định yêu cầu
Phân tích hành vi
Nghiên cứu khả thi nhằm:
Đảm bảo hệ thống thỏa mãn nhu cầu, công nghệ phù hợp, giá cả hợp lý
Kiểm thử hệ thống
Viết đặc tả yêu cầu
Lập kế hoạch bảo trì
Phân tích yêu cầu được thực hiện sau:
Thẩm định yêu cầu
Thiết kế cơ sở dữ liệu
Nghiên cứu khả thi
Kết quả của tiến trình kỹ nghệ yêu cầu là:
Mã nguồn hệ thống
Các tài liệu yêu cầu phần mềm
Tài liệu hướng dẫn sử dụng
Báo cáo kiểm thử
Đặc tả yêu cầu phần mềm nhằm:
Mô tả chính xác yêu cầu làm cơ sở giao kèo
Thay thế luôn tài liệu thiết kế
Tối ưu hóa mã nguồn
Chỉ mô tả giao diện
Thẩm định yêu cầu nhằm:
Kiểm tra đặc tả có đúng với mong muốn của khách hàng không
Viết thêm chức năng mới
Chạy thử chương trình
Phân tích hiệu năng
Một trong những khó khăn lớn khi phân tích yêu cầu là:
Khách hàng không bao giờ thay đổi yêu cầu
Khách hàng thường thay đổi và mô tả mơ hồ
Khách hàng viết code trực tiếp
Khách hàng không tham gia quá trình phát triển
Nguyên lý 1 trong phân tích yêu cầu tập trung vào:
Mô hình hóa miền thông tin
Mô hình hóa chức năng
Mô hình hóa hành vi
Phân hoạch mô hình
Nguyên lý 2 là:
Mô hình hóa chức năng
Tìm hiểu bản chất vấn đề
Phân hoạch mô hình
Nguyên lý 3 là:
Mô hình hóa hành vi
Phân hoạch mô hình
Mô hình hóa dữ liệu
Mô hình hóa kiến trúc
Biểu đồ trạng thái dùng để:
Mô hình hóa hành vi
Mô hình hóa dữ liệu
Mô hình hóa kiến trúc
Phân tích chi phí
Nguyên lý 5 trong phân tích yêu cầu là:
Tìm hiểu bản chất của vấn đề
Mô hình hóa dữ liệu
Làm bản mẫu
Xây dựng kiến trúc
Biểu đồ phân rã chức năng (FDD) giúp:
Xác định phạm vi hệ thống và phân hoạch chức năng
Xác định hành vi hệ thống
Mô tả giao diện người dùng
Kiểm tra yêu cầu phi chức năng
Biểu đồ luồng dữ liệu (DFD) mô tả:
Quá trình dữ liệu di chuyển và biến đổi trong hệ thống
Quan hệ giữa thực thể
Phân rã hệ thống thành mô-đun
Giao diện người dùng
Trong DFD, tác nhân ngoài là:
Đối tượng bên ngoài hệ thống, phát sinh hoặc tiếp nhận thông tin
Luồng dữ liệu
Kho dữ liệu
Tiến trình xử lý
Một nguyên tắc quan trọng khi xây dựng DFD:
Tiến trình phải có cả luồng vào và luồng ra
Luồng dữ liệu có thể quay lại nơi xuất phát
Tác nhân ngoài kết nối trực tiếp với kho dữ liệu
Không cần bắt đầu từ mức 0
Biểu đồ ERD (Entity-Relationship Diagram) mô tả:
A. Quan hệ vốn có của thế giới thực
B. Luồng dữ liệu trong hệ thống
C. Hành vi hệ thống
D. Cấu trúc phần mềm
Yêu cầu chức năng mô tả:
Những gì hệ thống phải làm, các dịch vụ hệ thống cung cấp
Hiệu năng và tính tin cậy
Giao diện đồ họa
Ngân sách dự án
Yêu cầu phi chức năng thường liên quan đến:
Đặc tả cơ sở dữ liệu
Thuật toán xử lý
Hiệu năng, tính an toàn, khả chuyển, tính dễ sử dụng
Thiết kế phần cứng
Một ví dụ về yêu cầu phi chức năng là:
Hệ thống cho phép người dùng đăng nhập
Hệ thống trả kết quả tìm kiếm trong vòng 2 giây
Hệ thống có chức năng in báo cáo
Người dùng quản lý hồ sơ cá nhân
Yêu cầu sản phẩm bao gồm:
Các yêu cầu về hiệu năng, độ tin cậy, tính khả dụng
Yêu cầu về chi phí
Yêu cầu bảo trì
Yêu cầu hợp đồng
Yêu cầu quy trình (process requirement) đề cập đến:
Yêu cầu chức năng và phi chức năng khác nhau chủ yếu ở:
Hình thức đặc tả
Việc mô tả “làm cái gì” so với “làm như thế nào, tốt đến mức nào”
Tài liệu ghi nhận
Cách viết code
Tài liệu đặc tả yêu cầu phần mềm (SRS) thường bao gồm:
Giới thiệu, mô tả tổng thể, yêu cầu cụ thể
Chỉ có mô hình ERD
Chỉ có DFD mức 0
Chỉ liệt kê chức năng
Yêu cầu sản phẩm phi chức năng thường khó:
Xác minh, đo lường
Lập trình
Thực hiện dự án
Vẽ mô hình
Yêu cầu chức năng trả lời câu hỏi:
Hệ thống phải làm gì
Hệ thống phải nhanh đến mức nào
Hệ thống phải an toàn thế nào
Hệ thống phải dùng công nghệ gì
Yêu cầu phi chức năng trả lời câu hỏi:
Hệ thống làm cái gì
Hệ thống phải hoạt động tốt đến mức nào
Ai là người dùng cuối
Lập trình viên nào sẽ phát triển
Một khó khăn chính trong thu thập yêu cầu là:
Phương pháp phỏng vấn trong thu thập yêu cầu có ưu điểm:
Trực tiếp nắm bắt ý kiến khách hàng
Không cần sự tham gia của khách hàng
Luôn tiết kiệm thời gian
Tránh được mâu thuẫn
Một phương pháp thu thập yêu cầu thường dùng trong nhóm:
Phỏng vấn nhóm
Joint Application Design (JAD)
Workshop yêu cầu
Cả A, B, C
Bản mẫu (prototype) giúp:
Người dùng dễ hình dung hệ thống
Thay thế tài liệu đặc tả
Tránh hoàn toàn sai sót
Rút ngắn giai đoạn phân tích
Một nhược điểm của bản mẫu là:
Khách hàng nghĩ nó là sản phẩm cuối cùng
Không thể trình diễn được chức năng
Không giúp phát hiện lỗi yêu cầu
Không cần thời gian phát triển
Phỏng vấn bán cấu trúc (semi-structured interview) là:
Hoàn toàn tự do
Có dàn câu hỏi trước nhưng linh hoạt theo tình huống
Chỉ hỏi theo bảng câu hỏi cố định
Không cần chuẩn bị gì
Sử dụng bảng hỏi (questionnaire) có ưu điểm:
Thu thập được ý kiến của nhiều người trong thời gian ngắn
Tương tác sâu với từng người
Luôn chính xác tuyệt đối
Thay thế mọi phương pháp khác
Người dùng luôn đưa yêu cầu chính xác
Người dùng luôn đưa yêu cầu chính xác
Hệ thống luôn ổn định
Yêu cầu không bao giờ thay đổi
Thảo luận nhóm (focus group) thường dùng để:
Nắm bắt ý kiến nhiều người dùng cùng lúc
Viết code
Kiểm thử hệ thống
Thẩm định sản phẩm
Quan sát người dùng trong môi trường làm việc giúp:
Hiểu được quy trình thực tế
Tăng chi phí
Mất đi thông tin quan trọng
Không hữu ích
JAD (Joint Application Design) đặc biệt hữu ích khi:
Cần sự phối hợp chặt chẽ giữa người dùng và nhà phát triển
Không cần khách hàng tham gia
Hệ thống rất nhỏ
Hệ thống không quan trọng
Đặc tả phi hình thức thường là:
Văn bản tự nhiên, dễ hiểu
Ký pháp toán học
Biểu diễn đồ thị như hình
Mã nguồn chương trình
Nhược điểm chính của đặc tả phi hình thức là:
Mơ hồ, dễ gây hiểu lầm
Dễ kiểm chứng
Rất chặt chẽ
Khó viết
Đặc tả hình thức có ưu điểm:
Chính xác, có thể kiểm chứng bằng toán học
Luôn dễ đọc cho mọi đối tượng
Không cần công cụ hỗ trợ
Luôn rẻ hơn
Ngôn ngữ đặc tả Z dùng để:
Mô tả hệ thống theo tập hợp và logic toán
Mô tả giao diện đồ họa
Viết mã nguồn
Tạo báo cáo
Ngôn ngữ VDM là viết tắt của:
Vienna Development Method
Visual Data Model
Variable Data Machine
Verified Design Method
CSP (Communicating Sequential Processes) dùng để mô tả:
Các tiến trình song song và giao tiếp giữa chúng
Dữ liệu tĩnh
Chức năng cơ bản
Quan hệ thực thể
Petri Net thường được dùng để:
Mô tả hệ thống đồng thời, song song, bất đồng bộ
Viết code Java
Vẽ biểu đồ ERD
Mô tả GUI
Đặc tả hình thức thường khó áp dụng rộng rãi vì:
Đòi hỏi kiến thức toán học cao
Quá dễ học
Không chính xác
Không có công cụ hỗ trợ
Đặc tả yêu cầu nên kết hợp:
Cả phương pháp phi hình thức và hình thức
Chỉ phi hình thức
Chỉ hình thức
Không cần đặc tả
Một công cụ hỗ trợ đặc tả và mô hình hóa yêu cầu phổ biến là:
Rational Rose
Photoshop
AutoCAD
Thẩm định yêu cầu nhằm đảm bảo:
Yêu cầu đúng, không mâu thuẫn, đầy đủ, hiện thực
Mã nguồn chạy được
Hệ thống có giao diện đẹp
Báo cáo tài chính chính xác
Tính đúng đắn (correctness) của yêu cầu nghĩa là:
Yêu cầu phản ánh đúng nhu cầu khách hàng
Yêu cầu không mâu thuẫn
Yêu cầu đầy đủ
Yêu cầu có thể thực hiện được
Tính nhất quán (consistency) nghĩa là:
Không có mâu thuẫn giữa các yêu cầu
Mọi yêu cầu đều được viết rõ ràng
Yêu cầu phản ánh đúng mong muốn khách hàng
Yêu cầu dễ đọc
Tính đầy đủ (completeness) trong đặc tả yêu cầu là:
Mọi yêu cầu cần thiết đều được mô tả
Mỗi yêu cầu có ít nhất một hình minh họa
Có bảng biểu đồ UML
Có kế hoạch kiểm thử
Tính hiện thực (realism) của yêu cầu nghĩa là:
Yêu cầu có thể thực hiện được trong điều kiện kỹ thuật, tài chính
Yêu cầu luôn dễ lập trình
Yêu cầu không thay đổi
Yêu cầu chỉ liên quan đến phần mềm
Phương pháp thẩm định yêu cầu phổ biến:
Review (xem xét), kiểm thử, chứng minh hình thức
Viết code thử
Triển khai hệ thống luôn
Hỏi khách hàng một lần duy nhất
Kỹ thuật “review yêu cầu” thường tiến hành bởi:
Nhóm phát triển và khách hàng
Chỉ lập trình viên
Người dùng cuối không liên quan
Tự động bởi phần mềm
Một yêu cầu không khả thi (unrealistic) ví dụ:
Hệ thống phải phản hồi trong 0.001 giây trên máy tính phổ thông
Hệ thống cho phép đăng nhập
Hệ thống có chức năng tìm kiếm
Hệ thống lưu trữ dữ liệu
Để thẩm định tính nhất quán, người ta thường:
Kiểm tra logic giữa các yêu cầu
So sánh với mã nguồn
So sánh với ngân sách
Kiểm tra sơ đồ ERD
Một công cụ CASE hỗ trợ thẩm định yêu cầu là:
Rational Rose
Paint
Excel
Photoshop
Mục tiêu của thiết kế phần mềm là:
Biến yêu cầu thành mô tả kiến trúc và chi tiết để triển khai
Viết mã nguồn
Viết tài liệu hướng dẫn sử dụng
Kiểm thử hệ thống
Thiết kế phần mềm cần đảm bảo:
Một nguyên lý thiết kế quan trọng là:
Tính mô-đun (modularity)
Tính phức tạp
Tính bất định
Tính ngẫu nhiên
Thiết kế tốt giúp:
Giảm chi phí bảo trì và phát triển
Tăng độ phức tạp
Giảm tốc độ chạy
Làm khách hàng khó hiểu
Tính độc lập mô-đun cao được đo bằng:
Độ kết dính cao và độ phụ thuộc thấp
Độ kết dính thấp và phụ thuộc cao
Mức độ tài liệu nhiều
Số dòng code
Tính trừu tượng trong thiết kế nhằm:
Che giấu chi tiết, chỉ bộc lộ bản chất
Hiển thị toàn bộ chi tiết
Làm tăng độ phức tạp
Tăng độ dài tài liệu
Một tiêu chuẩn của thiết kế chất lượng cao là:
Dễ bảo trì và mở rộng
Khó hiểu
Càng phức tạp càng tốt
Không cần kiểm thử
Nguyên lý "divide and conquer" trong thiết kế là:
Chia nhỏ vấn đề phức tạp thành các phần đơn giản hơn
Gộp mọi thứ thành một khối
Không chia tách gì cả
Tập trung viết code trước
Thiết kế tốt giúp dễ dàng:
Tái sử dụng, kiểm thử, bảo trì
Khó thay đổi
Khó mở rộng
Gây nhầm lẫn cho khách hàng
Tính khả chuyển (portability) nghĩa là:
Phần mềm dễ dàng chuyển sang môi trường khác
Phần mềm chạy nhanh
Phần mềm đẹp
Phần mềm rẻ
Thiết kế kiến trúc phần mềm là:
Xác định các thành phần chính và cách giao tiếp giữa chúng
Viết code
Vẽ giao diện
Lập kế hoạch bảo trì
Kiến trúc dữ liệu tập trung (data-centered) có đặc điểm:
Có kho dữ liệu trung tâm chia sẻ cho các hệ con
Mỗi hệ con có dữ liệu riêng biệt
Không có chia sẻ dữ liệu
Không có kiến trúc
Nhược điểm của kiến trúc data-centered là:
Nếu kho dữ liệu trung tâm hỏng thì toàn hệ thống ngừng hoạt động
Dữ liệu khó đồng bộ
Tốn nhiều băng thông
Không chia sẻ được dữ liệu
Kiến trúc client-server có đặc điểm:
Client yêu cầu dịch vụ, server cung cấp
Server yêu cầu dịch vụ, client cung cấp
Mọi nút đều ngang hàng
Không có sự phân vai
Ưu điểm của client-server là:
Dễ mở rộng, quản lý dữ liệu tập trung
Khó mở rộng
Không an toàn
Không phổ biến
Nhược điểm của client-server là:
Server có thể thành điểm nghẽn
Client không cần phần mềm
Khó đồng bộ dữ liệu
Không có mạng
Kiến trúc phân tầng (layered architecture) có ưu điểm:
Dễ thay đổi từng tầng, dễ bảo trì
Không linh hoạt
Khó mở rộng
Không thể thay đổi
Trong kiến trúc phân tầng:
Mỗi tầng chỉ giao tiếp với tầng liền kề
Mọi tầng giao tiếp với nhau
Không có quy định giao tiếp
Client giao tiếp trực tiếp với tất cả tầng
Kiến trúc gọi – trả lời (call and return) là:
Chương trình chia thành thủ tục và hàm, gọi nhau theo thứ tự
Các tiến trình song song giao tiếp
Kho dữ liệu chia sẻ
Sự kiện điều khiển hệ thống
Ưu điểm của call and return là:
Đơn giản, dễ cài đặt
Khó hiểu
Không dùng được
Tốn kém
Kiến trúc hướng sự kiện (event-driven) có đặc điểm:
A. Các thành phần phản ứng khi sự kiện xảy ra
B. Mọi thành phần luôn chạy tuần tự
C. Chỉ có dữ liệu tĩnh
D. Không có sự kiện
Kiến trúc pipeline (ống dẫn) thường dùng cho:
Xử lý dữ liệu theo chuỗi các bước
Giao diện người dùng
Cơ sở dữ liệu
Thống kê chi phí
Kiến trúc hướng đối tượng (OO architecture) tổ chức hệ thống thành:
Các đối tượng có trạng thái và hành vi
Các thủ tục đơn lẻ
Các luồng dữ liệu
Các bảng tính
Ưu điểm của OO architecture là:
Tái sử dụng, dễ bảo trì, gần gũi thế giới thực
Khó mở rộng
Không tái sử dụng
Không phù hợp thực tế
Kiến trúc event-driven thường áp dụng trong:
Hệ thống giao diện người dùng
Hệ thống batch offline
Cơ sở dữ liệu tĩnh
Tài liệu văn bản
Kiến trúc pipeline phù hợp khi:
Cần xử lý dữ liệu nhiều bước tuần tự
Không có quy trình nào
Dữ liệu không cần xử lý
Hệ thống không cần tuần tự
Kiến trúc phân tán giúp:
Phân bố chức năng và dữ liệu trên nhiều máy
Mọi thứ tập trung một chỗ
Không có tính mở rộng
Một nhược điểm của hệ phân tán là:
Phức tạp trong đồng bộ và truyền thông
Không bao giờ lỗi
Không chia sẻ được dữ liệu
Không hỗ trợ nhiều người dùng
Kiến trúc “ống dẫn – bộ lọc” (pipe-filter) là biến thể của:
Pipeline
Event-driven
Client-server
Layered
Ưu điểm của pipe-filter là:
Mỗi bộ lọc độc lập, dễ thay đổi và tái sử dụng
Khó thay đổi
Phức tạp
Không dùng được
Phân hoạch ngang (horizontal partitioning) giúp:
Tách giao diện với xử lý và dữ liệu
Gom mọi thứ lại
Tăng độ phức tạp
Không phân chia gì cả
Phân hoạch dọc (vertical partitioning) nghĩa là:
Sắp xếp các chức năng theo mức độ ưu tiên và điều khiển
Chia dữ liệu thành bảng
Chia theo người lập trình
Chia theo thời gian
Kỹ thuật thiết kế chuyển đổi (transform analysis) áp dụng khi:
Có dòng dữ liệu vào – xử lý – ra
Không có dữ liệu
Hệ thống không tuần tự
Kỹ thuật thiết kế theo luồng giao tiếp (transaction analysis) dùng khi:
Có nhiều loại giao dịch, mỗi loại có xử lý riêng
Chỉ có một loại dữ liệu
Không có giao dịch
Chỉ có xử lý tuần tự
Refining (làm mịn dần) trong thiết kế nghĩa là:
A. Từ mô tả tổng quát đến chi tiết hơn
B. Bỏ hết chi tiết
C. Chỉ viết code
D. Chỉ vẽ sơ đồ
Một lợi ích của phân hoạch ngang là:
Giảm sự phụ thuộc, dễ thay đổi giao diện
Tăng độ phức tạp
Khó bảo trì
Khó mở rộng
Phân hoạch dọc giúp:
Làm rõ luồng điều khiển chính và các xử lý phụ
Không phân cấp
Làm hệ thống khó hiểu
Không giúp gì
Thiết kế kiến trúc phải xét đến:
Hiệu năng, bảo trì, bảo mật, mở rộng
Chỉ hiệu năng
Chỉ bảo mật
Không xét gì cả
Một kiến trúc tốt thường:
Có tính mô-đun, dễ thay đổi, dễ mở rộng
Khó bảo trì
Phụ thuộc chặt chẽ
Gây lỗi liên tục
