Tất cả câu hỏi

Đáp án đúng: "horizontal, vertical". Mock-up là prototype ngang (horizontal prototype): nó trải rộng trên giao diện người dùng, mô phỏng màn hình và cách điều hướng nhưng không có logic xử lý thật phía sau, dùng để khơi gợi và thẩm định yêu cầu về trải nghiệm người dùng. Proof of concept là prototype dọc (vertical prototype): nó cắt sâu qua mọi tầng kỹ thuật, từ giao diện tới xử lý và dữ liệu, cho một phần nhỏ chức năng, để chứng minh một cách tiếp cận kỹ thuật là khả thi. "vertical, horizontal" sai vì đảo ngược hai khái niệm trên. "primary, secondary" sai vì đây không phải cách phân loại prototype theo phạm vi; chính và phụ không nói lên prototype rộng hay sâu. "front-end, back-end" sai vì dù mock-up thiên về giao diện, proof of concept không chỉ làm phần back-end mà đi xuyên qua mọi tầng, nên cặp từ này không mô tả đúng.

Đáp án đúng: "Leaving the prototype looking rough and unpolished.". Bản mẫu bỏ đi (throwaway prototype) chỉ dùng để làm rõ yêu cầu rồi bỏ, không được viết với chất lượng sản phẩm; rủi ro lớn là bên liên quan thấy nó trông hoàn chỉnh rồi cho rằng sản phẩm gần xong. Giữ bản mẫu thô, như phác thảo giấy hay khung dây (wireframe), nhắc mọi người rằng đây chỉ là công cụ thảo luận. "Using high-fidelity tools that resemble the final product." làm tăng rủi ro vì bản mẫu càng giống thật càng khiến người xem kỳ vọng nó sẵn sàng đưa vào dùng. "Making the prototype available for immediate release." đi ngược bản chất bản mẫu bỏ đi, vốn không đủ chất lượng để phát hành. "Giving detailed descriptions of every feature." không giải quyết kỳ vọng về độ hoàn thiện, lại làm bản mẫu trông như đặc tả đầy đủ.

Đáp án đúng: "$100". Kỹ thuật $100 (chia 100 đô la) cho mỗi bên liên quan một ngân sách tưởng tượng 100 đô để phân bổ cho các yêu cầu; yêu cầu nào nhận nhiều tiền hơn thì được ưu tiên cao hơn, nhờ đó mức quan trọng tương đối được lượng hóa bằng giá trị tiền tệ và người tham gia buộc phải đánh đổi. Phương án "Pairwise comparison" so sánh từng cặp yêu cầu để xem cái nào quan trọng hơn, không gán giá trị tiền. Phương án "MoSCoW" xếp yêu cầu vào các nhóm Must, Should, Could, Won’t theo mức cần thiết. Phương án "Three-level scale" chia yêu cầu thành ba mức như cao, trung bình, thấp dựa trên tầm quan trọng và độ khẩn cấp. Cả ba đều là kỹ thuật ưu tiên hóa hợp lệ nhưng không dùng giá trị tiền tệ.

Đáp án đúng: "Interoperability". Khả năng liên tác (interoperability) là thuộc tính chất lượng bên ngoài cho biết hệ thống trao đổi dữ liệu và dịch vụ với các hệ thống, ứng dụng khác dễ tới mức nào; yêu cầu nhập được cấu trúc hoá học hợp lệ từ ChemDraw và MarvinSketch ở các phiên bản nêu rõ chính là đặc tả khả năng làm việc với công cụ bên ngoài. Phương án "Availability" sai vì tính sẵn sàng đo tỷ lệ thời gian hệ thống hoạt động được khi cần dùng. Phương án "Installability" sai vì khả năng cài đặt nói về việc cài, cấu hình, gỡ bỏ phần mềm dễ và đúng tới mức nào. Phương án "Integrity" sai vì tính toàn vẹn nói về bảo vệ dữ liệu khỏi bị sửa sai, mất mát hay truy cập trái phép, không phải trao đổi dữ liệu với công cụ khác.

Đáp án đúng: "Scalability". Scalability (khả năng mở rộng) là thuộc tính chất lượng cho biết hệ thống có thể tăng năng lực để phục vụ nhiều người dùng, nhiều giao dịch hay nhiều dữ liệu hơn mà không phải thiết kế lại và không suy giảm hiệu năng quá mức. Tình huống yêu cầu xử lý gấp 10 lần số giao dịch, và hệ thống không làm được vì tiến trình nguyên khối, logic gắn chặt, chính là vấn đề khả năng mở rộng; yêu cầu loại này nên được nêu rõ từ đầu kèm con số tăng trưởng. "Availability" sai vì tính sẵn sàng đo tỉ lệ thời gian hệ thống hoạt động được khi cần, ở đây hệ thống vẫn chạy đúng như dự định. "Usability" sai vì tính dễ dùng nói về việc người dùng học và thao tác dễ hay khó, không liên quan tới khối lượng giao dịch. "Robustness" sai vì tính bền vững nói về khả năng hệ thống xử lý đúng khi gặp đầu vào không hợp lệ, lỗi hay điều kiện bất thường, không phải khi tải tăng có kế hoạch.

Đáp án đúng: "Entity-Relationship Diagram (ERD)". Sơ đồ thực thể quan hệ là mô hình dữ liệu trực quan: thực thể biểu diễn đối tượng dữ liệu hệ thống cần lưu và xử lý, đường nối biểu diễn quan hệ kèm bản số như một-nhiều, nên đây là công cụ phân tích phù hợp nhất cho yêu cầu dữ liệu. "Data Flow Diagram (DFD)" cho thấy dữ liệu chảy giữa các tiến trình, kho dữ liệu và thực thể ngoài, tập trung vào biến đổi dữ liệu chứ không vào cấu trúc và quan hệ của chúng. "State-Transition Diagram (STD)" mô tả các trạng thái của một đối tượng và sự kiện làm nó chuyển trạng thái, tức hành vi theo thời gian. "Swimlane Diagram" mô tả các bước của một quy trình nghiệp vụ chia theo vai trò hoặc bộ phận thực hiện, không mô hình hoá dữ liệu.

Đáp án đúng: "Entity-relationship diagram". Entity-relationship diagram (ERD, sơ đồ thực thể quan hệ) là mô hình phân tích dữ liệu: nó biểu diễn các thực thể dữ liệu, thuộc tính của chúng và quan hệ cùng bản số (một một, một nhiều, nhiều nhiều) giữa các thực thể, thường đi kèm từ điển dữ liệu trong phần yêu cầu dữ liệu. Phương án "Class diagram" có thể thể hiện quan hệ giữa các lớp trong phân tích và thiết kế hướng đối tượng, nhưng nó mô hình hóa cả hành vi và cấu trúc lớp, không phải công cụ điển hình để mô hình hóa thực thể dữ liệu. Phương án "Data flow diagram" thể hiện dữ liệu chảy giữa tiến trình, kho dữ liệu và thực thể ngoài, không thể hiện quan hệ giữa các thực thể. Phương án "Use case diagram" thể hiện tác nhân và ca sử dụng, thuộc mô hình hóa hành vi.

Đáp án đúng: "Determine what information the dashboard users need for making specific decisions or choices.". Bảng điều khiển (dashboard) và báo cáo tồn tại để hỗ trợ ra quyết định, nên bước khơi gợi quan trọng nhất là hỏi người dùng sẽ đưa ra quyết định gì và cần thông tin nào để quyết định; từ đó mới suy ra chỉ số, cách trình bày và dữ liệu nguồn. Phương án "exact number of charts and graphs to be displayed" sai vì số biểu đồ là chi tiết trình bày, chỉ chốt được sau khi biết cần hiển thị thông tin gì. Phương án "Identify the specific data sources that will feed the dashboard." là việc cần làm nhưng đi sau, vì phải biết cần thông tin gì mới biết lấy từ nguồn nào. Phương án "Select the software tool for building the dashboard." là quyết định thiết kế và cài đặt, không phải bước khơi gợi yêu cầu đầu tiên.

Đáp án đúng: "A DFD details the flow of data, processing, and data storage within the system, whereas a Context Diagram only defines the system boundary and its external entities.". Context diagram (sơ đồ ngữ cảnh) coi cả hệ thống là một tiến trình duy nhất, chỉ cho thấy ranh giới hệ thống, các thực thể bên ngoài và luồng dữ liệu vào ra; data flow diagram ở các mức thấp hơn phân rã tiến trình đó thành tiến trình con, kho dữ liệu và luồng dữ liệu bên trong. Cả hai là mô hình phân tích. "A DFD only describes incoming data, while a Context Diagram only describes outgoing data." sai vì cả hai đều thể hiện dữ liệu vào lẫn ra. "A DFD is used for designing user interfaces, while a Context Diagram is used for business analysis." sai vì DFD không mô hình giao diện. "A DFD appears only in the testing phase, whereas a Context Diagram is only used during requirements analysis." sai vì cả hai dùng trong phân tích yêu cầu. "Both DFD and Context Diagram only show external entities." sai vì DFD còn có tiến trình và kho dữ liệu.

Đáp án đúng: "rectangles". Swimlane diagram (sơ đồ làn bơi) mô tả quy trình nghiệp vụ hoặc luồng xử lý, chia thành các làn ngang hay dọc, mỗi làn ứng với một vai trò, bộ phận hay hệ thống. Trong sơ đồ này, mỗi bước xử lý được vẽ bằng hình chữ nhật đặt trong làn của bên thực hiện, giống ký hiệu bước xử lý trong lưu đồ. "arrows connecting pairs of rectangles" sai vì mũi tên nối các hình chữ nhật biểu diễn sự chuyển tiếp, tức thứ tự từ bước này sang bước kế, chứ không phải bản thân bước xử lý. "diamonds" sai vì hình thoi biểu diễn điểm quyết định, nơi luồng rẽ nhánh theo điều kiện. "ovals" sai vì trong nhiều lối vẽ lưu đồ hình bầu dục dùng cho điểm bắt đầu hoặc kết thúc của quy trình, không dùng cho các bước xử lý ở giữa. Sơ đồ làn bơi hay được dùng khi phân tích quy trình hiện tại và tương lai để tìm ra yêu cầu.

Đáp án đúng: "Conduct peer review". Rà soát đồng nghiệp (peer review) thuộc hoạt động thẩm định yêu cầu: người khác đọc yêu cầu với góc nhìn của mình (lập trình, kiểm thử, người dùng) nên dễ nhận ra giả định ngầm mà người viết coi là hiển nhiên, cũng như logic thiếu nhánh hay điều kiện chưa xử lý. Phương án "Use only bullet points" sai vì định dạng gạch đầu dòng không giúp phát hiện giả định, thậm chí còn làm mất ngữ cảnh và quan hệ giữa các ý. Phương án "Include lengthy background" sai vì thêm phần nền dài dòng không chỉ ra chỗ thiếu logic mà còn làm yêu cầu khó đọc hơn. Phương án "Prioritize with MoSCoW" sai vì MoSCoW là kỹ thuật xếp ưu tiên (Must, Should, Could, Won’t), giúp chọn yêu cầu làm trước chứ không kiểm tra chất lượng nội dung từng yêu cầu.

Đáp án đúng: "Hardware Manufacturers". Software Requirements Specification (SRS, đặc tả yêu cầu phần mềm) là tài liệu nhiều đối tượng cùng dùng: khách hàng và marketing kiểm tra sản phẩm đúng nhu cầu, quản lý dự án lập kế hoạch, lập trình viên biết cần xây gì, kiểm thử viên viết ca kiểm thử, người viết tài liệu soạn hướng dẫn, nhân viên pháp lý rà các yêu cầu tuân thủ, nhà thầu phụ làm theo hợp đồng. Nhà sản xuất phần cứng không nằm trong nhóm đọc SRS của một sản phẩm phần mềm. "Project Managers" dùng SRS để ước lượng, lập lịch và kiểm soát phạm vi. "Testers" dựa vào SRS để thiết kế ca kiểm thử và xác nhận hệ thống. "Legal Staff" đọc SRS để bảo đảm yêu cầu tuân thủ luật và quy định. "Documentation Writers" dựa vào SRS để viết hướng dẫn sử dụng và tài liệu trợ giúp.

Đáp án đúng: "To state the functions, capabilities, characteristics, and constraints a software system must provide.". Software Requirements Specification (SRS, đặc tả yêu cầu phần mềm) là sản phẩm của hoạt động đặc tả, ghi lại các yêu cầu chức năng, yêu cầu phi chức năng, giao diện ngoài và ràng buộc mà hệ thống phải đáp ứng; nó là cơ sở chung cho thiết kế, xây dựng, kiểm thử và quản lý dự án. "To document design, construction, and testing details for developers." sai vì SRS nói hệ thống phải làm gì, còn chi tiết thiết kế, cách lập trình và kế hoạch kiểm thử nằm ở tài liệu thiết kế và tài liệu kiểm thử riêng. "To serve as a marketing brochure for the new software product." sai vì SRS là tài liệu kỹ thuật chính xác cho đội dự án, không nhằm quảng bá sản phẩm. "To track project management schedules and resource allocation." sai vì lịch trình và phân bổ nguồn lực thuộc kế hoạch dự án; SRS chỉ là đầu vào để ước lượng các thứ đó.

Đáp án đúng: "Creating highly complex use cases with many embedded logic and branching conditions, making them incomprehensible". Một cái bẫy kinh điển khi viết use case là nhồi quá nhiều logic, điều kiện rẽ nhánh và ngoại lệ vào một ca sử dụng, khiến người dùng lẫn nhà phát triển đọc không hiểu và khó thẩm định; cách chữa là giữ luồng chính ngắn gọn, tách luồng thay thế và ngoại lệ, đưa logic phức tạp sang quy tắc nghiệp vụ hoặc bảng quyết định. Phương án "Only creating a few very high-level use cases" là vấn đề khác: ca sử dụng quá chung chung thiếu chi tiết, nhưng câu hỏi hỏi về bẫy độ phức tạp. Phương án "Separating normal flows from alternative flows" là thực hành tốt được khuyến khích, không phải bẫy. Phương án "Using use case diagrams to visualize relationships." cũng là thực hành tốt, giúp nhìn tổng thể các tác nhân và ca sử dụng cùng quan hệ giữa chúng.

Đáp án đúng: "Skipping the identification of alternative flows". Một use case tốt gồm luồng chính (normal flow) cùng các luồng thay thế (alternative flows) và ngoại lệ (exceptions); bẫy thường gặp là chỉ viết con đường suôn sẻ rồi bỏ qua các biến thể, khiến hệ thống không xử lý được tình huống lệch khỏi luồng chính và lập trình viên phải tự đoán. Phương án "Including too many preconditions" không phải bẫy điển hình, vì tiền điều kiện (preconditions) là thành phần bình thường và cần thiết của use case, chỉ cần đúng và đủ. Phương án "Writing the use case without validation" là thiếu sót chung của thẩm định yêu cầu, áp cho mọi loại yêu cầu, không phải bẫy riêng của cách viết use case. Phương án "Ignoring business rules" cũng là thiếu sót chung của phân tích; use case chỉ tham chiếu tới quy tắc nghiệp vụ còn quy tắc được ghi riêng.

Đáp án đúng: "A User Story is a brief description of a user’s need, typically written in the format “As a [user], I want [goal] so that [benefit].”". User story là một câu ngắn ghi nhu cầu của người dùng theo mẫu vai trò, mục tiêu, lợi ích; nó là lời hứa cho một cuộc trao đổi sau, chi tiết được bổ sung bằng tiêu chí chấp nhận. Khác biệt chính với use case: use case mô tả chi tiết chuỗi tương tác giữa tác nhân và hệ thống, có luồng chính, luồng thay thế và ngoại lệ. "A User Story is a detailed step-by-step description of the user’s interaction with the system." mô tả use case chứ không phải user story. "A User Story focuses on the system’s non-functional requirements." sai vì user story chủ yếu diễn đạt nhu cầu chức năng của người dùng. "A User Story is used to completely replace a Use Case in all situations." sai vì nhiều dự án dùng cả hai, use case hợp khi cần đặc tả chi tiết. "A User Story is a tool for test planning, while a Use Case is only for designing the interface." sai cả hai vế: cả hai đều là cách diễn đạt yêu cầu người dùng.

Đáp án đúng: "Focus groups". Nhóm tập trung (focus group) tập hợp một nhóm người dùng đại diện, thường cho từng lớp người dùng, để thảo luận có điều phối về nhu cầu và kỳ vọng; với dự án lớn có rất nhiều người dùng, kỹ thuật khơi gợi này thu được quan điểm của số đông một cách hiệu quả hơn so với làm việc từng người. "Observation" là quan sát người dùng làm việc thật, rất tốt để hiểu quy trình ngầm nhưng tốn thời gian và chỉ phủ được ít người. "Brainstorming sessions" nhằm sinh nhiều ý tưởng mới, phù hợp khi tìm giải pháp chứ không nhằm thu thập nhu cầu đại diện của đông đảo bên liên quan. "Stakeholder interviews" là phỏng vấn một-một, cho thông tin sâu nhưng khó mở rộng khi số bên liên quan quá lớn, nên thường dùng cho người chủ chốt.

Đáp án đúng: "Draft straw man models". Khi chuẩn bị phỏng vấn trong hoạt động khơi gợi yêu cầu, người phân tích nên phác sẵn straw man model (mô hình nháp để người khác góp ý), như một sơ đồ quy trình hay danh sách tính năng thô; người được phỏng vấn thường dễ chỉ ra chỗ sai trong một bản nháp cụ thể hơn là trả lời câu hỏi trừu tượng từ trang giấy trắng. Phương án "Avoid preparing questions" sai vì chuẩn bị bộ câu hỏi giúp buổi phỏng vấn đi đúng mục tiêu và không bỏ sót chủ đề. Phương án "Focus only on UI design" sai vì phỏng vấn cần tìm hiểu mục tiêu, nhiệm vụ, quy tắc nghiệp vụ và yêu cầu chất lượng, giao diện chỉ là một phần nhỏ. Phương án "Skip meeting stakeholders" đi ngược bản chất phỏng vấn, vốn là trao đổi trực tiếp với bên liên quan.

Đáp án đúng: "Product vision describes the ultimate product, while project scope identifies the portion of that vision to be addressed by the current project.". Product vision (tầm nhìn sản phẩm) mô tả sản phẩm cuối cùng sẽ là gì và đạt mục tiêu nghiệp vụ nào, ổn định trong dài hạn; project scope (phạm vi dự án) xác định phần nào của tầm nhìn đó được làm trong dự án hay đợt phát hành hiện tại. Cả hai nằm trong tài liệu vision and scope, thuộc tầng yêu cầu nghiệp vụ. "Product vision and project scope are interchangeable terms." sai vì hai khái niệm khác tầm: một là đích dài hạn, một là phần việc trước mắt. "Project scope defines business objectives, while product vision defines functional requirements." sai vì mục tiêu nghiệp vụ gắn với tầm nhìn, còn yêu cầu chức năng ở tầng chi tiết hơn, không phải nội dung của tầm nhìn. "Product vision is a subset of project scope for each release." đảo ngược quan hệ, vì phạm vi mới là tập con của tầm nhìn.

Đáp án đúng: "To represent the system as a whole and its interaction with external entities". Context diagram (sơ đồ ngữ cảnh) là mô hình phạm vi: cả hệ thống được vẽ thành một khối duy nhất ở giữa, xung quanh là các thực thể bên ngoài như người dùng, tổ chức, hệ thống khác, nối với hệ thống bằng các luồng dữ liệu. Nó cho thấy ranh giới giữa cái thuộc hệ thống và cái nằm ngoài, thường đặt trong tài liệu tầm nhìn và phạm vi. "To list system features" sai vì sơ đồ ngữ cảnh không cho thấy bên trong hệ thống; liệt kê tính năng là việc của danh sách tính năng hay feature tree. "To define user stories" sai vì user story là cách viết yêu cầu người dùng trong agile, không phải mục đích của mô hình phạm vi. "To prioritize requirements" sai vì sơ đồ ngữ cảnh không chứa thông tin ưu tiên; xếp ưu tiên là hoạt động phân tích riêng, dùng các kỹ thuật như MoSCoW.