Tất cả câu hỏi

Đáp án đúng: "To identify and address missing or unclear requirements". Một tài liệu đặc tả yêu cầu phần mềm (SRS) tốt phải đầy đủ; xử lý sự thiếu hoàn chỉnh nghĩa là tìm ra yêu cầu còn thiếu hoặc chưa rõ, đánh dấu chỗ chưa biết bằng TBD, giao người chịu trách nhiệm và giải quyết trước khi xây dựng, vì yêu cầu thiếu là nguồn lỗi tốn kém nhất. "To eliminate unnecessary requirements" là việc cắt bỏ yêu cầu ngoài phạm vi hoặc không mang giá trị, ngược hướng với bổ sung chỗ thiếu. "To finalize the system design" sai vì thiết kế là hoạt động sau đặc tả, không phải mục đích của việc rà soát độ đầy đủ yêu cầu. "To prepare for testing and validation" là lợi ích gián tiếp, vì SRS đầy đủ giúp viết kiểm thử tốt hơn, nhưng không phải mục đích trực tiếp của việc xử lý thiếu sót.

Đáp án đúng: "Use case diagrams show the graphical user interface that needs to be implemented.". Câu hỏi tìm phát biểu không đúng về mục đích của use case diagram (sơ đồ ca sử dụng): sơ đồ này chỉ thể hiện tác nhân, ca sử dụng và quan hệ giữa chúng ở mức khái niệm, hoàn toàn không mô tả màn hình hay giao diện đồ họa cần xây, vì giao diện thuộc thiết kế. Phát biểu "both behavior diagrams because they describe the behavior of the system" đúng theo UML, vì sơ đồ ca sử dụng mô tả hành vi và có thể được xem như một dạng đặc biệt của sơ đồ lớp với bộ phân loại là tác nhân và ca sử dụng, nên không được chọn. Phát biểu "usually referred to as behavior diagrams used to describe a set of actions" cũng đúng, nêu mục đích mô tả tập hành động hệ thống thực hiện cùng người dùng bên ngoài. Phát biểu "A use case describes a sequence of interactions between a system and an external actor" là định nghĩa chuẩn của ca sử dụng, nên cũng không phải đáp án.

Đáp án đúng: "Drafting straw man models and questions beforehand". Khi chuẩn bị một buổi khơi gợi có điều phối (facilitated elicitation) như workshop, người điều phối nên soạn trước mô hình nháp (straw man) và danh sách câu hỏi, vì người tham gia thường góp ý và sửa một bản có sẵn dễ hơn nhiều so với tự tạo từ trang trắng; nhờ vậy buổi làm việc tập trung và hiệu quả. "Finalizing all requirements before the session." đi ngược mục đích, buổi khơi gợi là để thu thập và làm rõ yêu cầu chứ không phải xác nhận thứ đã chốt. "Inviting only senior stakeholders." sai vì thiếu người dùng thực, những người hiểu công việc hằng ngày, nên dễ bỏ sót nhu cầu thật. "Avoiding any pre-session communication" sai vì cần gửi trước mục tiêu, chương trình và tài liệu để người tham gia chuẩn bị.

Đáp án đúng: "Identifying and engaging the right stakeholders". Khơi gợi yêu cầu (elicitation) là thu thập yêu cầu từ con người và tài liệu, nên trước khi chọn kỹ thuật phỏng vấn, workshop hay quan sát, người phân tích phải xác định ai là bên liên quan, ai đại diện cho từng lớp người dùng và mời họ tham gia; thiếu đúng người thì yêu cầu sẽ thiếu hoặc sai ngay từ gốc. Phương án "Designing the user interface" sai vì thiết kế giao diện diễn ra sau khi đã hiểu yêu cầu. Phương án "Building the prototype" sai vì prototype có thể dùng làm kỹ thuật khơi gợi nhưng chỉ dựng được khi đã có hiểu biết ban đầu từ bên liên quan, không phải bước đầu tiên. Phương án "Writing test scripts" thuộc khâu kiểm thử, cần yêu cầu đã được đặc tả.

Đáp án đúng gồm ba ý: "Literacy skills for effectively interpreting written material and communicating requirements.", "Facilitation skills to manage group discussions and ensure effective participation from all stakeholders." và "Analytical skills to break down complex problems and identify feasible solutions.". Chuyên viên phân tích nghiệp vụ (business analyst) làm việc chủ yếu với con người và thông tin: phải đọc hiểu tài liệu, viết yêu cầu rõ ràng; phải điều phối (facilitate) các buổi khơi gợi để mọi bên được nói và đi tới đồng thuận; và phải phân tích, tách vấn đề phức tạp thành phần nhỏ, tìm khoảng trống và giải pháp khả thi. Phương án "Technical skills to ensure the analyst can implement the software" sai vì BA không có nhiệm vụ lập trình hệ thống; hiểu biết kỹ thuật có ích để trao đổi với lập trình viên và đánh giá tính khả thi, nhưng khả năng tự cài đặt phần mềm không phải kỹ năng cốt lõi của vai trò này.

Đáp án đúng: "Establish a clear decision-making rule". Bất đồng giữa các bên liên quan là chuyện thường xuyên trong phát triển yêu cầu, nên ngay từ đầu dự án cần xác định ai là người ra quyết định cho từng loại vấn đề và họ quyết theo quy tắc nào, ví dụ đồng thuận, biểu quyết đa số hay người có thẩm quyền quyết sau khi nghe ý kiến; có quy tắc rõ thì tranh cãi được giải quyết nhanh và công bằng. "Let developers decide" sai vì lập trình viên không nắm giá trị nghiệp vụ, quyết định yêu cầu không phải trách nhiệm của họ. "Avoid involving too many users" sai vì né tránh người dùng chỉ làm thiếu thông tin chứ không giải quyết bất đồng. "Follow whatever the executive sponsor says" không phải quy tắc ra quyết định: nhà tài trợ có thể là người quyết cuối ở một số vấn đề, nhưng làm theo mọi điều họ nói mà không có quy trình sẽ bỏ qua ý kiến các bên khác.

Đáp án đúng: "Elicitation, analysis, specification, and validation.". Kỹ nghệ yêu cầu chia thành phát triển yêu cầu (requirements development) và quản lý yêu cầu (requirements management). Phát triển yêu cầu có bốn phân ngành: khơi gợi để thu thập yêu cầu từ bên liên quan, phân tích để làm rõ, mô hình hoá, xếp ưu tiên, đặc tả để ghi thành tài liệu có cấu trúc, và thẩm định để xác nhận yêu cầu đúng với nhu cầu. Các hoạt động này lặp đi lặp lại chứ không chạy một lượt. "Planning, execution, monitoring, and control." sai vì đây là các nhóm quy trình của quản lý dự án. "Collection, documentation, review, and approval." sai vì tuy gần nghĩa nhưng không phải bộ thuật ngữ chuẩn, và bỏ mất phần phân tích, vốn là nơi yêu cầu được tinh chỉnh và soát lỗi. "Business, user, functional, and nonfunctional." sai vì đây là các loại hay tầng yêu cầu, tức sản phẩm của phát triển yêu cầu, chứ không phải các hoạt động của nó.

Đáp án đúng: "Inconsistent behavior is implemented". Yêu cầu mơ hồ (ambiguous) cho phép nhiều cách hiểu; khi các nhà phát triển khác nhau hiện thực theo cách hiểu riêng của mình, các phần của hệ thống sẽ hành xử không nhất quán với nhau và có thể không khớp mong đợi của khách hàng, buộc phải làm lại. Vì thế yêu cầu tốt phải rõ ràng, chỉ có một cách hiểu. "The software works better" sai vì diễn giải khác nhau chỉ sinh lỗi và mâu thuẫn, không làm phần mềm tốt hơn. "Developers work faster" sai vì có thể nhanh lúc đầu nhưng sau đó tốn công sửa, tổng thời gian tăng. "Ambiguities go unnoticed" mô tả điều kiện dẫn tới vấn đề, tức mơ hồ không được phát hiện khi rà soát, chứ không phải hậu quả khi nhà phát triển đã hiện thực theo nhiều cách khác nhau.

Đáp án đúng: "To evaluate their effectiveness on a small scale". Trong chu trình cải tiến quy trình yêu cầu, sau khi đánh giá hiện trạng và thiết kế quy trình mới, tổ chức nên chạy thử (pilot) trên một dự án hoặc nhóm nhỏ trước khi áp dụng rộng; việc này cho thấy quy trình có hiệu quả thật không, bộc lộ chỗ cần điều chỉnh với rủi ro thấp và tạo bằng chứng thuyết phục người khác. Phương án "To ensure they are perfect before implementation" sai vì không quy trình nào hoàn hảo, thí điểm nhằm học hỏi và cải tiến dần. Phương án "To skip feedback from participants" ngược lại hoàn toàn, vì phản hồi của người tham gia chính là đầu ra quý nhất của thí điểm. Phương án "To create an abstract understanding without practical testing" sai vì thí điểm chính là kiểm nghiệm thực tế, không phải hiểu biết trừu tượng.

Đáp án đúng: "They are short and simple, avoiding "or" logic on the left-hand side and "and" logic on the right-hand side of "if/then" constructs, to facilitate reuse and modification.". Atomic business rule (quy tắc nghiệp vụ nguyên tử) là quy tắc không thể tách nhỏ hơn mà vẫn giữ nghĩa; quy tắc dạng nếu thì có điều kiện nối bằng hoặc nên tách thành nhiều quy tắc, kết quả nối bằng và cũng vậy, nhờ đó mỗi quy tắc dễ tái sử dụng, dễ sửa và dễ truy vết. "They combine multiple details into a single complex rule" ngược hẳn với tính nguyên tử, gộp nhiều chi tiết là thứ cần tránh. "They are primarily used for computational logic" sai vì tính nguyên tử áp dụng cho mọi loại quy tắc, từ fact, constraint tới inference, không riêng computation. "They are specific to a single software application and cannot be reused." sai vì quy tắc nghiệp vụ thuộc về tổ chức chứ không thuộc một ứng dụng, và viết nguyên tử chính là để dễ tái sử dụng.

Đáp án đúng: "Use a word processor or a simple catalog". Business rules (quy tắc nghiệp vụ) là chính sách, quy định, công thức, ràng buộc áp lên hoạt động của tổ chức; nhiều hệ thống dùng chung một quy tắc nên cần lưu chúng ở một nơi. Cách đơn giản để bắt đầu là ghi chúng vào một danh mục quy tắc nghiệp vụ (business rules catalog) bằng trình soạn thảo hay bảng tính, mỗi quy tắc có mã, phát biểu, loại, nguồn. "Implement a full-scale business rule management tool" là bước về sau, khi tổ chức có rất nhiều quy tắc và muốn quản lý tập trung, chi phí và công sức lớn nên không phải cách bắt đầu đơn giản nhất. "Use a requirements management tool" là cách phức tạp hơn một bậc, hợp khi muốn liên kết và truy vết quy tắc tới yêu cầu, nhưng cần công cụ và cấu hình. "Write business rules directly in application code" sai vì nhúng quy tắc vào mã khiến chúng khó tìm, khó dùng lại và khó sửa khi chính sách đổi; đó không phải cách quản lý quy tắc.

Đáp án đúng: "A superset of stakeholders". Bên liên quan (stakeholder) là mọi cá nhân hay tổ chức bị ảnh hưởng hoặc có ảnh hưởng tới dự án, nên tập này rộng nhất; khách hàng là một phần của bên liên quan, và người dùng lại là một phần trong đó. Vì vậy nói người dùng là tập bao của bên liên quan là sai, đây chính là phát biểu không đúng cần chọn. "A subset of the product’s customers in some cases" là đặc điểm đúng: có lúc người dùng cũng là khách hàng, như người mua phần mềm để tự dùng. "A subset of the product’s users" đúng theo nghĩa mỗi lớp người dùng (user class) chỉ là một nhóm con trong toàn bộ người dùng sản phẩm. "Includes direct users and indirect users" cũng đúng: người dùng trực tiếp thao tác hệ thống, còn người dùng gián tiếp nhận kết quả từ nó như báo cáo, nên cả hai đều phải được xét khi khơi gợi yêu cầu.

Đáp án đúng gồm ba ý: "The platform they will be using, such as desktop PCs, laptops, tablets, or smartphones.", "The frequency with which they use the product and the tasks they perform during business operations." và "Their access privileges or security levels, such as ordinary user, guest user, or administrator.". Phân lớp người dùng (user classes) là chia người dùng thành nhóm có nhu cầu khác nhau để khơi gợi yêu cầu đủ cho từng nhóm; tiêu chí thường dùng gồm thiết bị và nền tảng họ dùng, tần suất dùng cùng nhiệm vụ họ làm, mức quyền truy cập, ngoài ra còn trình độ, kinh nghiệm miền, vị trí địa lý. Mỗi tiêu chí này làm nhóm người dùng cần tính năng và giao diện khác nhau. Phương án "The specific languages used in the system’s backend processes." sai vì ngôn ngữ lập trình phía máy chủ là quyết định cài đặt của nhóm phát triển, người dùng không thấy và không tạo ra khác biệt về nhu cầu giữa các nhóm người dùng.

Đáp án đúng gồm hai ý: "Defining the product vision and project scope early in the project to ensure all stakeholders have a shared understanding." và "Identifying user classes and their characteristics to ensure that all user needs are considered.". Đây là hai thực hành tốt của khơi gợi yêu cầu: xác định sớm tầm nhìn và phạm vi giúp mọi người cùng hướng tới một mục tiêu và có căn cứ để quyết định yêu cầu nào nằm trong phạm vi; xác định các user class (nhóm người dùng) cùng đặc điểm của họ giúp không bỏ sót nhu cầu của nhóm nào. "Focusing exclusively on nonfunctional requirements during initial elicitation while ignoring functional requirements to save time." sai vì khơi gợi phải bao quát cả yêu cầu chức năng lẫn phi chức năng, bỏ một nhóm sẽ gây thiếu sót. "Avoiding the use of prototypes in the early stages of requirements elicitation to prevent biasing stakeholders." sai vì prototype là kỹ thuật được khuyến khích để làm rõ yêu cầu từ sớm, chỉ cần dùng có chủ đích.

Đáp án đúng: "They represent small, actionable pieces of functionality". Trong agile, câu chuyện người dùng (user story) là mô tả ngắn một nhu cầu từ góc nhìn người dùng, thường theo dạng tôi là ai, muốn gì, để làm gì; mỗi câu chuyện là một phần chức năng nhỏ, đủ cụ thể để ước lượng, làm xong và kiểm thử trong một vòng lặp, kèm tiêu chí chấp nhận. "They define the system architecture" sai vì kiến trúc là quyết định thiết kế kỹ thuật, không do câu chuyện người dùng xác định. "They specify project deadlines" sai vì hạn chót thuộc kế hoạch dự án và phát hành; câu chuyện chỉ được xếp vào vòng lặp theo ưu tiên. "They describe the business goals in detail" sai vì mục tiêu kinh doanh thuộc tầng yêu cầu kinh doanh như tầm nhìn và phạm vi, còn câu chuyện người dùng là yêu cầu ở mức người dùng, ngắn gọn chứ không chi tiết.

Đáp án đúng: "Change control board". Ban kiểm soát thay đổi (change control board, CCB) là nhóm người, có thể chỉ một người hoặc gồm đại diện nhiều bên, được trao quyền quyết định chấp nhận, chấp nhận có sửa đổi hay từ chối từng yêu cầu thay đổi và yêu cầu mới; đây là phần cốt lõi của quy trình kiểm soát thay đổi trong quản lý yêu cầu. Phương án "Project management board" sai vì đó là cách gọi nhóm điều hành dự án nói chung, không phải tên chuẩn của nhóm quyết định thay đổi yêu cầu. Phương án "Project management office" sai vì văn phòng quản lý dự án (PMO) chuẩn hoá phương pháp, hỗ trợ nhiều dự án trong tổ chức. Phương án "Project management committee" sai vì không phải thuật ngữ chuẩn cho vai trò này. Phương án "Change control group" nghe gần nhưng không phải tên chuẩn; thuật ngữ được dùng là change control board.

Đáp án đúng: "Performance". Khi chọn một gói phần mềm có sẵn (package solution), BA cần đặc tả các thuộc tính chất lượng mà gói phải đáp ứng; Performance (hiệu năng) đo khả năng hệ thống đáp ứng tải, gồm số người dùng đồng thời, thông lượng giao dịch, thời gian phản hồi. Bảo đảm gói chịu được tải dự kiến về người dùng đồng thời và thông lượng giao dịch chính là yêu cầu hiệu năng. "Usability" sai vì tính dễ dùng nói về việc người dùng học và thao tác hiệu quả, không liên quan tới tải. "Integrity" sai vì tính toàn vẹn nói về việc bảo vệ dữ liệu khỏi sai lệch, mất mát hay truy cập trái phép, bảo đảm dữ liệu chính xác. "Modifiability" sai vì khả năng sửa đổi đo mức dễ dàng khi thay đổi, mở rộng hay sửa lỗi phần mềm, không đo khả năng chịu tải lúc vận hành.

Đáp án đúng: "It is a project in which new capabilities are added to an existing system.". Dự án nâng cấp (enhancement project) bổ sung chức năng mới hoặc cải tiến cho một hệ thống đang vận hành; khi làm yêu cầu cho loại dự án này, chuyên viên phân tích phải hiểu hệ thống hiện tại, phân tích tác động lên chức năng cũ và giữ tương thích. Phương án mô tả việc "replaces an existing application with a new custom-built system" là định nghĩa dự án thay thế (replacement project), khi hệ cũ bị thay bằng hệ tự xây, sản phẩm thương mại mua sẵn hoặc kết hợp, chứ không phải nâng cấp hệ đang có. "It is a project which costs less than planned." chỉ nói về kết quả tài chính, không phải một loại dự án. "It is a project which generates more revenues." cũng là kết quả kinh doanh mong muốn chứ không định nghĩa đặc điểm của dự án nâng cấp.

Đáp án đúng: "Have developers review requirements". Yêu cầu là đầu vào trực tiếp của thiết kế và viết mã, nên thực hành gắn với khâu này là để nhà phát triển rà soát yêu cầu sớm: họ phát hiện chỗ mơ hồ, không khả thi về kỹ thuật hay thiếu thông tin trước khi bắt tay thiết kế, tránh hiểu sai rồi phải làm lại. Một số bộ ôn tập xếp câu này khác, nhưng các phương án kia rõ ràng thuộc khâu khác. Phương án "Base estimates on product size" thuộc lập kế hoạch dự án, dùng kích thước yêu cầu để ước lượng công sức. Phương án "Use requirement priorities to drive iterations" cũng thuộc lập kế hoạch, chọn yêu cầu nào làm ở vòng lặp nào. Phương án "Start test design early" và phương án "Trace requirements to tests" thuộc kiểm thử: thiết kế ca kiểm thử sớm từ yêu cầu và truy vết mỗi yêu cầu tới ca kiểm thử của nó.