Tất cả câu hỏi

Đáp án đúng: "To link requirements to design, development, and testing artifacts". Requirements traceability matrix (RTM, ma trận truy vết yêu cầu) là bảng ghi liên kết giữa từng yêu cầu với nguồn gốc của nó và với các sản phẩm phía sau như thiết kế, mã nguồn, ca kiểm thử; đây là công cụ của hoạt động quản lý yêu cầu, phục vụ phân tích tác động thay đổi và kiểm tra mọi yêu cầu đều được hiện thực, được kiểm thử. "To identify redundant requirements" chỉ là lợi ích phụ: nhìn ma trận có thể thấy yêu cầu trùng lặp hay không gắn mục tiêu nào, nhưng đó không phải mục tiêu chính khi lập RTM. "To finalize the system budget" sai vì ngân sách thuộc quản lý dự án, ma trận truy vết không chốt chi phí. "To prioritize stakeholder meetings" sai vì việc sắp lịch họp với các bên liên quan không liên quan tới truy vết yêu cầu.

Đáp án đúng: "Context diagram". Sơ đồ ngữ cảnh (context diagram) là mức trừu tượng cao nhất của mô hình luồng dữ liệu: toàn bộ hệ thống được vẽ thành một tiến trình duy nhất ở giữa, xung quanh là các thực thể bên ngoài (external entity) cùng luồng dữ liệu trao đổi với chúng, nhờ đó thể hiện ranh giới và phạm vi hệ thống. "Data flow diagram" phân rã hệ thống thành các tiến trình con, kho dữ liệu và luồng dữ liệu chi tiết bên trong, nên nằm ở mức thấp hơn chứ không phải cái nhìn tổng quan. "Entity-relationship diagram" mô hình hoá dữ liệu và quan hệ giữa chúng, không thể hiện tiến trình hay thực thể ngoài. "Use case diagram" cũng ở mức cao nhưng cho thấy tác nhân và các mục tiêu người dùng đạt được qua hệ thống, không mô tả luồng dữ liệu giữa hệ thống và thực thể bên ngoài.

Đáp án đúng gồm hai ý: "The business analyst primarily focuses on eliciting, analyzing, documenting, and validating the needs of the project stakeholders." và "The business analyst plays a central role in collecting and disseminating product information, while the project manager focuses on communicating project information.". Chuyên viên phân tích nghiệp vụ (business analyst) là người chịu trách nhiệm chính về yêu cầu: khơi gợi, phân tích, đặc tả, thẩm định nhu cầu các bên liên quan; họ là đầu mối thông tin về sản phẩm, còn quản lý dự án lo thông tin về dự án như tiến độ, nguồn lực, chi phí. Phương án "solely responsible for managing communication between the customer" sai vì BA là kênh chính chứ không phải duy nhất, khách hàng và nhóm phát triển vẫn trao đổi trực tiếp, nhất là trong agile. Phương án "often acts as the project manager, handling both internal and external" sai vì trong agile BA thường góp sức cho product owner hoặc nhóm, không kiêm vai trò quản lý dự án.

Đáp án đúng: "Ineffective communication between customers and the development team.". Expectation gap (khoảng cách kỳ vọng) là khoảng chênh giữa sản phẩm khách hàng nghĩ họ sẽ nhận và sản phẩm đội phát triển thực sự giao. Khoảng cách này lớn dần khi hai bên ít trao đổi: khách hàng chỉ tham gia lúc đầu và lúc nghiệm thu, trong khi nhu cầu của họ đã đổi và cách hiểu của đội đã lệch. Cách thu hẹp là gắn kết khách hàng thường xuyên qua rà soát, prototype, demo theo vòng lặp. "A rigorous testing process." sai vì kiểm thử chặt giúp phát hiện sai lệch sớm, không tạo ra khoảng cách. "Continuously updating the requirements documentation." sai vì cập nhật tài liệu liên tục giữ cho hai bên cùng nhìn một phiên bản yêu cầu, tức là làm hẹp khoảng cách. "Time pressure from project management." có thể gây ra nhiều vấn đề như cắt bớt chất lượng, nhưng không phải nguyên nhân cốt lõi khiến kỳ vọng của khách hàng lệch với sản phẩm. "Using advanced technology in software development." sai vì công nghệ dùng để xây không quyết định việc hiểu đúng nhu cầu.

Đáp án đúng gồm hai ý: "All participants in the requirements approval process must understand what signing off implies." và "Reaching agreement on requirements ensures that both customers and developers have a shared understanding of project objectives.". Ký duyệt yêu cầu (sign-off) có ý nghĩa là các bên đồng ý rằng bộ yêu cầu hiện tại là đường cơ sở (baseline) để lập kế hoạch và xây dựng, vì vậy mọi người tham gia phải hiểu rõ chữ ký đó cam kết điều gì; và quá trình đạt đồng thuận chính là cách tạo hiểu biết chung giữa khách hàng và nhà phát triển. Phát biểu "is an infallible method to prevent any changes later in the project" sai vì không có cách nào ngăn hoàn toàn thay đổi; yêu cầu vẫn đổi và được xử lý qua quy trình kiểm soát thay đổi. Phát biểu cho rằng ký duyệt nhằm "freeze requirements and prevent any future modifications" sai vì đường cơ sở không phải đóng băng; thay đổi sau ký duyệt được chấp nhận nếu đi qua phân tích tác động và phê duyệt.

Đáp án đúng: "Quality attributes describe the system's functional behaviors in terms of user interactions.". Thuộc tính chất lượng (quality attributes) là một loại yêu cầu phi chức năng, mô tả hệ thống phải tốt tới mức nào (hiệu năng, khả dụng, bảo mật, độ tin cậy) chứ không mô tả hệ thống làm gì; gán cho chúng việc mô tả hành vi chức năng là sai nên đây là phát biểu cần chọn. Phương án "Business rules are the origin of several types of software requirements" đúng: quy tắc nghiệp vụ (business rules) là chính sách, luật lệ tồn tại ngoài phần mềm, sinh ra nhiều yêu cầu nhưng bản thân không phải yêu cầu phần mềm. Phương án "describe the system's performance characteristics rather than its specific behaviors" đúng vì yêu cầu phi chức năng nói về đặc tính chất lượng, không phải hành vi cụ thể. Phương án "Functional requirements describe how the system will perform certain actions" đúng vì yêu cầu chức năng mô tả hệ thống phải làm gì trong điều kiện nhất định. Ba phát biểu này đúng nên không được chọn.

Đáp án đúng: "Process Flows". Phân loại đơn giản về business rule (quy tắc nghiệp vụ) có năm loại: fact (sự thật đúng về nghiệp vụ), constraint (ràng buộc giới hạn hành động), action enabler (quy tắc kích hoạt hành động khi điều kiện thoả), inference (suy diễn ra tri thức mới từ điều kiện) và computation (công thức tính toán). Luồng quy trình mô tả trình tự công việc, là mô hình quy trình chứ không phải một loại quy tắc nghiệp vụ. "Facts" là loại đầu tiên, như mỗi đơn hàng có một mã duy nhất. "Constraints" là loại giới hạn, như sinh viên chỉ được đăng ký tối đa một số tín chỉ nhất định. "Computations" là quy tắc tính toán, như công thức chiết khấu theo số lượng. "Inferences" là quy tắc suy ra kết luận, như khách quá hạn thanh toán ba mươi ngày thì bị coi là tài khoản nợ xấu.

Đáp án đúng: "To identify underlying issues in current practices". Root cause analysis (phân tích nguyên nhân gốc) là kỹ thuật dùng khi cải tiến quy trình yêu cầu: từ một vấn đề quan sát được, như nhiều lỗi do yêu cầu hay thay đổi liên tục, hỏi tiếp tại sao nhiều lần hoặc vẽ sơ đồ xương cá để tìm nguyên nhân sâu xa trong cách làm hiện tại, rồi chọn thực hành mới nhắm đúng nguyên nhân đó thay vì chữa triệu chứng. "To prioritize changes" sai vì xếp ưu tiên thay đổi là việc của ban kiểm soát thay đổi, dựa trên giá trị và chi phí, không phải mục đích của phân tích nguyên nhân gốc. "To assess stakeholder satisfaction" sai vì đo mức hài lòng dùng khảo sát hay phản hồi; kết quả đó có thể là triệu chứng đầu vào nhưng không phải điều kỹ thuật này tìm ra. "To define the scope of the project" sai vì phạm vi dự án được xác định qua tầm nhìn, sơ đồ ngữ cảnh, danh sách tính năng, không liên quan tới cải tiến quy trình.

Đáp án đúng: "The business analyst". Quản lý yêu cầu (requirements management) gồm lập đường cơ sở (baseline), kiểm soát thay đổi, theo dõi trạng thái và truy vết yêu cầu; người thường giữ trách nhiệm dẫn dắt mảng này là chuyên viên phân tích nghiệp vụ, vì đó là người hiểu yêu cầu sâu nhất và đã làm chúng ra. "The project manager" phối hợp chặt và thường tham gia ban kiểm soát thay đổi, nhưng trách nhiệm chính của quản lý dự án là kế hoạch, lịch trình, nguồn lực và rủi ro, không phải duy trì bộ yêu cầu. "The developer" là người hiện thực hoá yêu cầu, góp ý về tác động kỹ thuật khi có thay đổi chứ không quản lý yêu cầu. "The quality assurance team" dùng yêu cầu để thiết kế kiểm thử và góp phần thẩm định, nhưng không dẫn dắt việc quản lý chúng.

Đáp án đúng: "A User Representative is a real individual from the user base who participates directly in the development process, while a User Persona is a fictional composite based on real data.". Người đại diện người dùng (user representative, như product champion) là một người thật thuộc một nhóm người dùng, tham gia trực tiếp để cung cấp và thẩm định yêu cầu thay mặt nhóm đó; chân dung người dùng (persona) là nhân vật hư cấu tổng hợp từ dữ liệu thật, dùng khi không tiếp cận được người dùng thật. Phương án "used only in testing, while a User Persona is used solely" sai vì cả hai đều phục vụ khơi gợi và thẩm định suốt dự án. Phương án "are exactly the same" sai vì một bên là người thật, một bên là nhân vật giả định. Phương án "employed to document technical requirements" sai vì người đại diện không viết yêu cầu kỹ thuật và persona không chỉ dùng thiết kế giao diện. Phương án "represents one individual only, while a User Persona represents an entire organization" sai vì người đại diện nói thay cả một nhóm người dùng, còn persona đại diện cho một nhóm người dùng chứ không phải cả tổ chức.

Đáp án đúng: "Opportunity". Phương pháp Agile coi thay đổi yêu cầu là điều tất yếu và là cơ hội để sản phẩm sát với nhu cầu thật hơn; tuyên ngôn Agile đề cao phản hồi với thay đổi hơn bám theo kế hoạch, nên yêu cầu được làm mịn dần, ưu tiên lại ở mỗi vòng lặp qua product backlog. Phương án "Disruption" phản ánh góc nhìn coi thay đổi là sự xáo trộn cần ngăn chặn, ngược với tinh thần Agile. Phương án "Risk" sai vì dù thay đổi không kiểm soát có thể gây rủi ro, Agile chủ động đón nhận nó thông qua vòng lặp ngắn thay vì coi là mối đe dọa. Phương án "Expense" sai vì Agile giữ chi phí thay đổi thấp bằng cách giao từng phần nhỏ và nhận phản hồi sớm, không xem thay đổi chủ yếu là khoản tốn kém.

Đáp án đúng: "By considering both the likelihood of occurrence and potential impact of risks". Trong quản lý rủi ro, mỗi rủi ro được đánh giá theo xác suất xảy ra và mức tác động nếu xảy ra; tích của hai đại lượng (độ phơi nhiễm rủi ro, risk exposure) dùng để xếp hạng, nhờ đó nhóm tập trung giảm thiểu những rủi ro vừa dễ xảy ra vừa gây hại lớn. Phương án "By focusing on risks that are least likely to occur" sai vì dồn sức vào rủi ro ít xảy ra là ngược với mục đích ưu tiên. Phương án "By ignoring potential impact and only considering likelihood" sai vì một rủi ro ít khả năng nhưng hậu quả nặng vẫn có thể cần ưu tiên cao, bỏ qua tác động sẽ đánh giá lệch. Phương án "By assuming that all risks are equally important" sai vì coi mọi rủi ro như nhau là không xếp ưu tiên gì cả, nguồn lực giảm thiểu bị dàn trải.

Đáp án đúng: "Change impact analysis". Requirements tracing (truy vết yêu cầu) liên kết mỗi yêu cầu với nguồn gốc, với các yêu cầu liên quan và với thiết kế, mã, ca kiểm thử. Động lực chính là khi một yêu cầu cần sửa, nhờ các liên kết đó người ta lần ra được mọi sản phẩm bị ảnh hưởng để ước lượng công sức và rủi ro, tức là phân tích tác động thay đổi, một phần của quản lý yêu cầu và kiểm soát thay đổi. "Requirements elicitation" là khơi gợi yêu cầu ở đầu dự án, khi chưa có gì để truy vết. "User interface design" là hoạt động thiết kế, có thể nằm trong chuỗi truy vết nhưng không phải lý do cần truy vết. "Project budgeting" là lập ngân sách, có thể dùng kết quả phân tích tác động nhưng không phải hoạt động mà truy vết trực tiếp phục vụ khi sửa yêu cầu.

Đáp án đúng gồm ba ý: "Understand the possible implications of the change", "Identify all affected requirements and documents" và "Estimate the effort needed for the change". Change impact analysis (phân tích tác động thay đổi) là bước trong kiểm soát thay đổi giúp ban kiểm soát thay đổi quyết định chấp nhận hay từ chối một yêu cầu thay đổi: trước hết hiểu các hệ quả có thể có của thay đổi, kể cả xung đột với yêu cầu khác; tiếp đó dùng truy vết yêu cầu để xác định mọi yêu cầu, thiết kế, mã, ca kiểm thử, tài liệu bị ảnh hưởng; sau đó ước lượng công sức để cài đặt thay đổi, làm cơ sở đánh giá chi phí và lịch. "Implement the change without stakeholder approval" sai vì đi ngược bản chất kiểm soát thay đổi: phân tích tác động diễn ra trước khi quyết định, và thay đổi chỉ được làm sau khi người có thẩm quyền phê duyệt.

Đáp án đúng: "Supplement written specifications with visual requirements models and prototypes.". Khi làm việc với đội thuê ngoài khác văn hoá và ngôn ngữ, văn bản dễ bị hiểu theo nhiều cách; bổ sung mô hình yêu cầu trực quan như sơ đồ, bảng quyết định và bản mẫu giúp truyền đạt ý nghĩa ít phụ thuộc vào câu chữ, nhờ đó giảm hiểu lầm. "Rely solely on written communication." sai vì chỉ dựa vào chữ viết chính là nguồn gây hiểu lầm lớn nhất khi người đọc không dùng tiếng mẹ đẻ. "Avoid face-to-face meetings to save travel costs." sai vì gặp mặt trực tiếp, nhất là giai đoạn đầu, giúp xây dựng quan hệ và làm rõ yêu cầu; tiết kiệm chi phí đi lại không bù được thiệt hại do hiểu sai. "Use only the native language of the outsourced party." khiến bên đặt hàng diễn đạt yêu cầu bằng ngôn ngữ mình không thạo, chỉ đẩy rủi ro hiểu lầm sang phía ngược lại.

Đáp án đúng: "It t is one in which new capabilities are added to an existing system.". Enhancement project (dự án nâng cấp) bổ sung khả năng mới vào hệ thống đang chạy; yêu cầu ở đây tập trung vào tính năng mới, tác động tới phần đang có và việc tránh làm hỏng chức năng cũ. Phương án "It replaces an existing application with a new custom-built system, a commercial off-the-shelf (COTS) system, or a hybrid of those." mô tả replacement project (dự án thay thế), khi ứng dụng cũ bị thay bằng hệ thống tự xây, phần mềm đóng gói hoặc kết hợp. Phương án "It is most commonly implemented to improve performance, cut costs" nêu các lý do thường gặp để tiến hành dự án thay thế, không định nghĩa dự án nâng cấp. Phương án "It is building new releases of established commercial products." mô tả bối cảnh phát triển sản phẩm thương mại theo từng bản phát hành; các bản này có thể chứa cải tiến, nhưng dự án nâng cấp được xác định bởi việc thêm khả năng mới vào một hệ thống hiện có.

Đáp án đúng: "Baselined requirements". Đường cơ sở yêu cầu (requirements baseline) là tập yêu cầu đã được rà soát, thống nhất và cam kết cho một bản phát hành; nó trở thành trung tâm dẫn dắt mọi hoạt động khác: kế hoạch dự án ước lượng dựa trên nó, thiết kế và mã hiện thực nó, kiểm thử kiểm chứng theo nó, và mọi thay đổi đi qua kiểm soát thay đổi so với nó. Phương án "Project plans" sai vì kế hoạch được lập dựa trên yêu cầu, tức là sản phẩm phía sau. Phương án "Designs and code" sai vì thiết kế và mã được tạo ra để đáp ứng yêu cầu, không phải thứ dẫn dắt yêu cầu. Phương án "Tests" sai vì ca kiểm thử được suy ra từ yêu cầu để kiểm tra hệ thống có đúng yêu cầu hay không, nên cũng phụ thuộc vào yêu cầu đã chốt.

Đáp án đúng: "Junior business analyst". Requirements pattern (mẫu yêu cầu) là khuôn có sẵn cho một loại yêu cầu hay gặp, chỉ ra những thông tin cần có, cách diễn đạt và ví dụ, giúp viết yêu cầu đầy đủ, nhất quán ở bước đặc tả. Người hưởng lợi nhiều nhất là người phân tích nghiệp vụ còn ít kinh nghiệm, vì mẫu bù cho phần kinh nghiệm họ chưa có và nhắc họ những chi tiết dễ bỏ sót. "Project manager" chủ yếu lập kế hoạch và điều phối dự án, không trực tiếp viết yêu cầu nên ít dùng tới mẫu. "Deployment engineer" làm việc ở khâu triển khai, nhận yêu cầu đã hoàn chỉnh chứ không soạn chúng. "Marketing director" đóng góp góc nhìn thị trường và mục tiêu kinh doanh, có thể là nguồn yêu cầu nhưng không phải người dùng mẫu để đặc tả.

Đáp án đúng: "Proof-of-concept prototype.". Bản mẫu chứng minh khái niệm (proof of concept), thường là bản mẫu dọc (vertical prototype) đi xuyên qua các tầng kỹ thuật cho một phần nhỏ chức năng, dùng để kiểm chứng một yêu cầu hay cách tiếp cận kỹ thuật có khả thi không, chẳng hạn hiệu năng hay khả năng tích hợp, trước khi cam kết xây thật. "Mock-up prototype." là bản mẫu ngang (horizontal) mô phỏng giao diện người dùng, giúp làm rõ yêu cầu và trải nghiệm chứ không chứng minh tính khả thi kỹ thuật. "Evolutionary prototype." được xây với chất lượng tốt rồi phát triển dần thành sản phẩm thật, mục đích là tiến hoá chứ không phải thử khả thi. "Simulation prototype." mô phỏng cách hệ thống vận hành hoặc tương tác để người dùng đánh giá hành vi, không nhằm kiểm chứng khả năng hiện thực hoá yêu cầu.

Đáp án đúng: "defect checklist". Trong rà soát và inspection (thanh tra) yêu cầu, defect checklist (danh sách kiểm tra khiếm khuyết) liệt kê các loại lỗi hay gặp như yêu cầu mơ hồ, thiếu, mâu thuẫn, không kiểm chứng được; mỗi loại tài liệu yêu cầu nên có danh sách riêng để người rà soát tập trung tìm đúng kiểu lỗi đó. Phương án "error checklist" nghe gần nghĩa nhưng không phải tên gọi chuẩn của công cụ này; thuật ngữ được dùng là khiếm khuyết (defect) trong sản phẩm được rà soát. Phương án "inspection meeting" là một bước trong quy trình thanh tra, nơi nhóm cùng thảo luận các lỗi tìm được, chứ không phải công cụ phát triển trước cho từng loại tài liệu. Phương án "support documentation" là tài liệu hỗ trợ người dùng hoặc vận hành, không liên quan tới việc tìm lỗi khi rà soát.