Kỹ Nghệ Phần Mềm Chương 1

Câu hỏi trắc nghiệm vể CNPM

• Câu 1: Ưu điểm của mô hình chữ V là: công việc được kiểm tra ở mỗi giai đoạn, công việc liên quan chặt chẽ với nhau, công việc có cùng mức độ quan trọng.

• Câu 2: Mô hình xoắn ốc WINWIN khác với mô hình xoắn ốc ở chỗ: nó xác định các nhiệm vụ cần thiết để kiểm tra, cài đặt, xây dựng và cung cấp hỗ trợ người dùng.

• Câu 3: Quy tắc thiết kế giao diện người dùng: đặt người dùng làm trung tâm, giao diện cần nhất quán, cung cấp khả năng tương tác đa dạng cho người dùng, giảm tải bộ nhớ cho người dùng.

• Câu 4: Kỹ năng yêu cầu phần mềm: yêu cầu phải luôn thống nhất, yêu cầu dễ bị thay đổi, yêu cầu khó phát hiện, yêu cầu luôn được biết chính xác.

• Câu 5: Trong biểu đồ usecase, một tác nhân đại diện cho: một người dùng, khách hàng và không quan tâm đến vai trò của họ.

• Câu 6: Loại biểu đồ trong UML: biểu đồ trạng thái.

• Câu 7: Quy trình mô hình xoắn ốc: lập kế hoạch phát triển, kỹ nghệ, phân tích rủi ro, xây dựng & xuất xưởng, đánh giá, giao tiếp khách hàng.

• Câu 8: Tài liệu đặc tả yêu cầu: chương trình sẽ không có lỗi, nhiều người dùng có thể đăng nhập mà không gặp xung đột khi tải, hệ thống lưu trạng thái và khởi động lại nếu có vấn đề nghiêm trọng, hệ thống ngắt kết nối nếu người dùng nhập giá trị không hợp lệ.

• Câu 9: Loại biểu đồ trong UML: biểu đồ lớp (Class Diagram)

• Câu 10: Truyền thông hiệu quả trong Agile: trực tiếp, cuộc họp công cộng, tin nhắn riêng, email an toàn.

• Câu 11: Lệnh xem phiên bản Git đã cài đặt: git --version

• Câu 12: Biểu đồ trong UML: biểu đồ triển khai (Deployment Diagram).

• Câu 13: Đặc điểm mô hình xoắn ốc: bao gồm việc đánh giá rủi ro, kết thúc bằng sản phẩm phần mềm, nhiều hỗn độn hơn so với mô hình gia tăng.

• Câu 14: Biểu đồ mô tả hành vi của đối tượng : biểu đồ trình tự (sequence diagram).

• Câu 15: Loại mô hình cần trong phân tích yêu cầu: giải thuật và cấu trúc dữ liệu, kiến trúc và cấu trúc, tính tin cậy và tính sử dụng.

• Câu 16: Tạo cơ hội kiểm tra và thích nghi trong Scrum: cuộc họp đánh giá tốc độ, cuộc họp rủi ro, cuộc họp thiết kế, cuộc họp hàng ngày.

• Câu 17: Khái niệm tính gắn kết trong thiết kế module: tập trung vào một nhiệm vụ duy nhất, không kết nối với các module khác và thế giới bên ngoài, có thể được viết gọn hơn, hoàn thành chức năng của nó một cách kịp thời.

• Câu 18: Thước đo tiến độ của nhóm Agile: Biểu đồ Burndown, bảng Kanban, phần mềm đang sử dụng, sự hài lòng của khách hàng.

• Câu 19: Lý do thực hiện code review: đánh giá lập trình viên, huấn luyện thành viên mới, sản xuất trường hợp kiểm thử mới, mã dễ hiểu.

• Câu 20: Cách viết chú thích tốt: ở trên đầu các module/hàm, mô tả mục đích, chức năng của module, tham số, giá trị trả về, chú thích cho tất cả các biến khai báo trong chương trình.

• Câu 21: Mô hình quy trình phần mềm dùng nhiều công cụ mạnh và thành phần tái sử dụng: RAD

• Câu 22: Yêu cầu chức năng phần mềm: hệ thống phải trả lời tất cả các truy vấn trong vòng 5 giây. Hệ thống cần cho phép chủ cửa hàng nhập thông tin sản phẩm mới.

• Câu 23: Lỗi thiết kế giao diện: đáp ứng kém, thiếu nhất quán, không có hướng dẫn, quá nhiều chi tiết.

• Câu 24: Mục tiêu của mẫu kiến trúc: tập hợp các thành phần, ràng buộc hay kết nối giữa các thành phần, tất cả các lựa chọn còn lại, mô hình ngữ nghĩa.

• Câu 25: Nguyên lý thiết kế giao diện giúp người dùng ghi nhớ ít: xác định những lối tắt trực quan, thiết lập những trường hợp mặc định có ý nghĩa, biểu lộ thông tin theo cách diễn tiến, tất cả các lựa chọn còn lại.

• Câu 26: Loại quan hệ trong UML use case: quan hệ mở rộng, quan hệ bao gồm, quan hệ tổng quát hoá.

• Câu 27: Trách nhiệm trong Scrum: Product Owner.

• Câu 28: Mục đích của biểu đồ gói (package diagram): biểu diễn các đối tượng cộng tác trong một usecase, cung cấp chi tiết về mục đích các hành vi và trạng thái hợp lệ, biểu diễn các lớp và mối quan hệ giữa chúng.

• Câu 29: Quan hệ của thiết kế phần mềm với các yếu tố: sự chính xác, sự phức tạp, chất lượng, phạm vi.

• Câu 30: Phương pháp tính hiệu quả của việc quản lý dự án phần mềm: people, performance, payoff, product.

• Câu 31: Khái niệm Liên kết (Coupling) trong module: tập trung vào một nhiệm vụ, có thể hoàn thành chức năng một cách phù hợp, có thể được xây dựng một cách vững chắc, kết nối với module khác và môi trường bên ngoài.

• Câu 32: Hoạt động quản lý cấu hình phần mềm: quản lý nhánh (branch management).

• Câu 33: Loại biểu đồ UML cho việc xử lý thông tin: biểu đồ luồng dữ liệu.

• Câu 34: Các giá trị của Agile: cá nhân và tương tác, phần mềm hoạt động, hợp tác khách hàng, phản hồi nhanh.

• Câu 35: Khái niệm "độ mạnh" của sự kết nối giữa các thành phần hệ thống: liên kết (coupling).

• Câu 36: Kiểu liên kết trong sơ đồ lớp: tất cả các lựa chọn. Mỗi Instructor có nhiều Student. Mỗi Student có thể liên kết với nhiều Instructor.

• Câu 37: Điều KHÔNG được ngụ ý bởi sơ đồ lớp trong UML: Một giáo viên chỉ dạy hai khóa học, một giáo viên có thể dạy ba khóa học, một học khóa có thể được giảng dạy bởi nhiều giáo viên.

• Câu 38: Rủi ro liên quan đến lịch biểu trong dự án: về con người, về hỗ trợ, về tiến độ, về hiệu suất.

• Câu 39: Đường "critical path" trong biểu đồ lịch biểu dự án: là một đường duy nhất, là tập hợp các công việc có ảnh hưởng trực tiếp đến ngày kết thúc dự án.

• Câu 40: Giải pháp cho quan hệ nhiều - nhiều trong thiết kế dữ liệu quan hệ: gộp hai tập thực thể thành một tập thực thể, giữ nguyên không cần thay đổi, tách thành hai quan hệ một - nhiều và nhiều - một, xóa đi một quan hệ.

• Câu 41: Nhân tố quan trọng trong lập trình cấu trúc (mô-đun) trong khởi tạo chương trình: sử dụng chú giải hiệu quả để hiểu chương trình, được mô tả với 3 cấu trúc, kích thước chuẩn cho mỗi mô đun (từ 100 đến 150 bước), nguyên tắc thụt cột giúp cho việc đọc chương trình dễ hơn.

• Câu 42: Ưu tiên cao nhất trong Agile: Việc triển khai phần mềm liên tục.

• Câu 43: Kỹ thuật kiểm thử đơn vị: kỹ thuật kiểm thử hộp trắng.

• Câu 44: Khám phá yêu cầu: các yêu cầu được tổng hợp theo nhiều hình thức, các yêu cầu được ghi nhận lại, xem lại các yêu cầu không thực tế, liên lạc với khách hàng để xác định yêu cầu.

• Câu 45: Git là gì? nền tảng kho lưu trữ từ xa, hệ thống kiểm soát phiên bản.

• Câu 46: Dòng đời hoạt động (life line) trong biểu đồ trình tự (sequence diagram): Hình chữ nhật hẹp đứng để nhấn mạnh đối tượng hoạt động trong phần kịch bản tương ứng.

• Câu 47: Phát biểu liên quan đến yêu cầu phần mềm: yêu cầu phi chức năng.

• Câu 48: Lệnh khởi tạo Git: git init.

• Câu 49: SRS là viết tắt của: Software Requirement Specification.

• Câu 50: Biểu đồ để biểu diễn các quan hệ vật lý giữa phần mềm và các thiết bị phần cứng: biểu đồ triển khai (Deployment Diagram).

• Câu 51: Nhiệm vụ chung trong xây dựng phần mềm: thiết kế giao diện người dùng, lập trình thành phần, kiểm thử.

• Câu 52: Lỗi trong thiết kế giao diện: quá nhiều chi tiết, không có hướng dẫn, thiếu nhất quán, không nhạy cảm với ngữ cảnh.

• Câu 53: Quan hệ giữa usecase: extend.

• Câu 54: Ký hiệu biểu thị quan hệ trong sơ đồ lớp: Association (kết hợp).

• Câu 55: Sai khi nói về thiết kế: thiết kế không phải là code, code không phải là thiết kế.

• Câu 56: Quy trình liên quan đến việc phân tích chi phí và lợi ích: Quản lý thay đổi.

• Câu 57: Việc che dấu thông tin trong OOP: Encapsulation.

• Câu 58: Đặc điểm của các mô hình phát triển phần mềm tiến hóa: dễ dàng ứng phó với sự thay đổi của yêu cầu.

• Câu 59: Biểu đồ lớp UML mô tả quan hệ "A Person keeps animals as pets. An animal as a single person as its owner": Người chủ sở hữu (Option 3)

• Câu 60: Thông tin mà biểu đồ Burndown thể hiện: biểu diễn trực quan về số lượng công việc còn tồn đọng qua thời gian.

• Câu 61: Thời gian vòng đời phần mềm: từ 3 đến 8 tháng, tùy thuộc vào độ phức tạp.

• Câu 62: Biểu đồ thực thể-quan hệ (ER diagram): chỉ ra sự tương tác giữa các thực thể trong một hệ thống, sự phụ thuộc giữa các thực thể, các yêu cầu.

• Câu 63: Mục tiêu biên soạn tài liệu đi kèm với mã nguồn: dễ dàng xác minh sự phù hợp giữa mã nguồn và bản mô tả, các thủ tục xử lý kỹ thuật chi tiết, ước lượng thời gian truy cập và dung lượng lưu trữ.

• Câu 64: Biểu đồ dùng trong mô hình nghiệp vụ: Biểu đồ hoạt động (activity diagram).

• Câu 65: Lệnh để xem lịch sử commit trong Git: git log.

• Câu 66: Cấu trúc UML để nhóm các thành phần và che dấu thông tin: Package, Subsystem hoặc Component.

• Câu 67: Mô hình xoắn ốc quan tâm đến bao nhiêu chiều: 4

• Câu 68: Loại biểu đồ trong UML: biểu đồ đối tượng (Object Diagram).

• Câu 69: Mô hình phát triển phần mềm gia tăng: Cách tốt khi cần tạo nhanh một sản phẩm phức hợp chỉ với các khả năng cơ bản nhất.

• Câu 70: Khái niệm hệ thống: một tập hợp các thành phần kết nối với nhau hoạt động theo mục đích xác định.

• Câu 71: Loại phần mềm xử lý dữ liệu thời gian thực: phần mềm thời gian thực.

• Câu 72: Mục tiêu chính của kiểm thử chấp nhận: đảm bảo hệ thống đáp ứng đúng nhu cầu người dùng.

• Câu 73: Kết luận về việc chạy bộ kiểm thử (T) trên chương trình (P): nếu tất cả các ca kiểm thử đều thành công thì chương trình P không còn lỗi.

• Câu 74: Giai đoạn tổng quát của CNPM: định nghĩa, phát triển, hỗ trợ.

• Câu 75: Mô hình quy trình phần mềm dựa trên mẫu thử: một phương pháp hữu ích khi khách hàng không xác định được yêu cầu rõ ràng.

• Câu 76: Kiểm thử tích hợp sau khi kiểm thử module: xác nhận sự tương tác giữa các modules, không có vấn đề về giao diện giữa các modules, không có vấn đề về thiết bị vào/ra.

• Câu 77: Ràng buộc trong thiết kế dữ liệu kiểm thử (testcase): nỗ lực và thời gian tối thiểu, theo một cách thức đầy đủ, tất cả các lựa chọn, mục tiêu nhằm khám phá lỗi.

• Câu 78: Ca sử dụng (use case) bao gồm những mô tả về: test cases, cách thực thi phần mềm, cách sử dụng các công cụ, kế hoạch xây dựng.

• Câu 79: Loại biểu đồ trong UML: Package Diagram.

• Câu 80: Xử lý (processing) trong biểu đồ luồng dữ liệu (DFD): Hình chữ nhật.

• Câu 81: Biểu đồ UML thể hiện ký hiệu : biểu đồ hoạt động.

• Câu 82: Loại biểu đồ để nắm bắt luồng sự kiện trong use case: biểu đồ hoạt động (activity diagram).

• Câu 83: Giai đoạn xây dựng phần mềm (software construction phase) bao gồm: phân tích yêu cầu, thiết kế, tích hợp, kiểm thử, tạo tài liệu, triển khai.

• Câu 84: Loại bảo trì phần mềm: Bảo trì hoàn chỉnh (Perfective maintenance).

• Câu 85: Loại biểu đồ trong UML: biểu đồ triển khai (Deployment Diagram).

• Câu 86: Cách để phân tích các tác vụ người dùng: quan sát thao tác người dùng, nghiên cứu các hệ thống tự động liên quan, người dùng cho biết những ý thích, dựa trên kinh nghiệm của các lập trình viên.

• Câu 87: Mô hình mẫu thử tiến hóa (evolutionary prototype) thích hợp hơn mô hình mẫu thử bỏ đi (throwaway prototype) vì : dễ dàng điều chỉnh, dễ dàng thực hiện nhanh chóng, cho phép tái sử dụng.

• Câu 88: Phiên bản được phê duyệt: Mốc giới hoặc Đường cơ sở, Kho lưu trữ, Cơ sở dữ liệu dự án, Bản phát hành.

• Câu 89: Trách nhiệm của Scrum Master: thu hẹp khoảng cách giữa đội phát triển và khách hàng, loại bỏ các trở ngại.

• Câu 90: Lỗi thiết kế giao diện: Phức tạp, không thân thiện với người dùng.

• Câu 91: Phát biểu sai về kiểm thử phần mềm: Bộ dữ liệu kiểm thử không nên dư thừa và quá phức tạp.

• Câu 92: Quản lý cấu hình hỗ trợ quản lý thay đổi bằng cách: xác định xu hướng và nguyên nhân gốc rễ, đánh giá tác động của lỗi, đánh giá rủi ro, ánh xạ cơ sở hạ tầng với ứng dụng và quy trình.

• Câu 93: Kiểm thử chấp nhận thường được thực hiện bởi: những người dùng cuối.

• Câu 94: Phân chia các kết quả dự án: phân chia thành những thành phần nhỏ hơn, dễ quản lý hơn.

• Câu 95: Biểu đồ trạng thái (State diagram): thể hiện các trạng thái và chuyển đổi giữa các trạng thái của hệ thống.

• Câu 96: Thuật ngữ dùng để thể hiện số liên kết của một đối tượng với một đối tượng khác: Cardinality.

• Câu 97: Phát biểu sai về sơ đồ luồng dữ liệu (DFD): DFD chứa thông tin về thời gian.

• Câu 98: Lệnh để thực hiện commit: git commit.

• Câu 99: Kỹ thuật kiểm thử sử dụng các đặc tả yêu cầu để xây dựng các ca kiểm thử: Kiểm thử từ dưới lên.

• Câu 100: Loại biểu đồ UML: Biểu đồ triển khai (Deployment Diagram).

• Câu 101: Vấn đề được phát hiện càng muộn trong phát triển phần mềm càng khó khắc phục : do càng nhiều thành phần đã được phát triển, sửa chữa thành phần càng tốn kém thời gian và công sức.

• Câu 102: Có nên sử dụng chung dữ liệu để tính gắn kết (cohesion) và liên kết (coupling)? Không khả thi, do hai khái niệm này mô tả hai khía cạnh khác nhau của thiết kế. Gắn kết đo lường sự liên quan chặt chẽ giữa các thành phần trong một module, trong khi liên kết đo lường sự phụ thuộc giữa các mô-đun.

• Câu 103: TestCase cho luật hôn nhân: Bao phủ lệnh, bao phủ nhánh.

• Câu 104: Lý do nói kiểm thử phần mềm không khẳng định được phần mềm không còn khiếm khuyết: không thể kiểm tra tất cả các trường hợp, hạn chế thời gian và nguồn lực.

• Câu 105: Để biết mô hình quy trình phần mềm có phù hợp với dự án không: đánh giá kỹ thuật dự án và nhóm phát triển, thời gian, nguồn lực, các yêu cầu có ổn định, tính chất của dự án.

Bài kiểm tra này kiểm tra kiến thức của bạn về các mô hình phát triển phần mềm, đặc biệt là mô hình chữ V và mô hình xoắn ốc WINWIN. Bạn cũng sẽ được hỏi về các quy tắc trong thiết kế giao diện người dùng và rủi ro khi phát hiện lỗi muộn trong quá trình phát triển phần mềm.