Tất cả câu hỏi

Đáp án đúng: "It categorizes requirements into Must-have, Should-have, Could-have, and Won’t-have to prioritize effectively". MoSCoW xếp yêu cầu vào bốn nhóm ưu tiên: bắt buộc phải có, nên có, có thể có và lần này sẽ không làm. Khi có yêu cầu mới hoặc thay đổi phạm vi, nhóm đặt nó vào một nhóm rõ ràng, nên dễ quyết định cái gì vào bản phát hành, cái gì bị đẩy ra sau mà không phá vỡ cam kết với nhóm bắt buộc. Phương án "It eliminates the need for stakeholder reviews" sai vì xếp nhóm MoSCoW cần chính các bên liên quan thảo luận và đồng ý. Phương án "It focuses only on technical requirements" sai vì MoSCoW áp cho mọi loại yêu cầu, chủ yếu theo giá trị nghiệp vụ. Phương án "It avoids scope creep entirely" sai vì không kỹ thuật nào loại bỏ hoàn toàn phình phạm vi; MoSCoW chỉ giúp kiểm soát nó bằng ưu tiên rõ ràng.

Đáp án đúng: "By linking to them from a shared location such as a database or a requirements management tool.". Yêu cầu tái sử dụng nên được lưu một bản gốc ở nơi dùng chung, có tìm kiếm và quản lý phiên bản, như cơ sở dữ liệu hay công cụ quản lý yêu cầu; các dự án tham chiếu (reuse by reference) tới bản gốc thay vì sao chép, nhờ vậy khi bản gốc được cập nhật thì mọi nơi dùng nó đều nhất quán. "By storing them in a spreadsheet." có thể dùng ở quy mô nhỏ nhưng bảng tính khó liên kết, khó kiểm soát phiên bản và khó chia sẻ giữa nhiều dự án. "By copying them into every new project document." sai vì sao chép tạo ra nhiều bản rời rạc, sửa một nơi thì các nơi khác lệch nhau. "By creating new versions for every instance they are used." sai vì nhân bản theo từng lần dùng làm mất ý nghĩa của tái sử dụng và gây khó quản lý.

Đáp án đúng: "They require more time to build and refine.". Prototype càng tinh vi, như mô phỏng (simulation) có tương tác gần như thật, càng tốn công xây dựng và sửa đổi; thời gian đó lẽ ra có thể dùng cho sản phẩm thật, và nếu prototype chỉ để làm rõ yêu cầu thì một bản phác hay wireframe đơn giản thường đủ. Vì vậy cần cân nhắc mức độ hoàn thiện vừa đủ cho câu hỏi cần trả lời. "They often create confusion about the system's features." không phải nhược điểm đặc trưng; rủi ro thường được nhắc lại là ngược lại, bản mô phỏng quá thật khiến khách hàng tưởng sản phẩm sắp xong, chứ không gây nhầm lẫn về tính năng. "They remove the need for stakeholder input." sai vì prototype tồn tại chính là để lấy phản hồi của bên liên quan. "They do not reflect real user behavior." sai vì prototype càng tinh vi thì càng gần hành vi thực của người dùng, đó là ưu điểm của nó.

Đáp án đúng: "In or out". Kỹ thuật In or out là cách ưu tiên hóa đơn giản nhất: nhóm bên liên quan xét từng yêu cầu và chỉ quyết định nhị phân là nó có vào bản phát hành này hay không, rất hợp khi danh sách ngắn hoặc cần chốt phạm vi nhanh. Phương án "Pairwise comparison" so sánh từng cặp yêu cầu, cho thứ hạng chi tiết nhưng tốn công khi số yêu cầu lớn và không cho kết quả nhị phân. Phương án "MoSCoW" xếp yêu cầu vào bốn nhóm Must, Should, Could, Won’t, tức nhiều hơn hai mức. Phương án "The $100 method" yêu cầu bên liên quan chia một ngân sách tưởng tượng giữa các yêu cầu, cho ra mức quan trọng tương đối chứ không phải quyết định vào hay ra.

Đáp án đúng: "Use paper prototypes or tools unrelated to actual development.". Bản mẫu bỏ đi (throwaway prototype) chỉ để khám phá yêu cầu, thường làm nhanh và không đủ chất lượng để chạy thật; nếu nó trông giống sản phẩm, khách hàng dễ nghĩ hệ thống sắp xong và gây áp lực đem dùng luôn. Làm bản mẫu trên giấy hoặc bằng công cụ khác hẳn công nghệ phát triển khiến không ai nhầm nó là sản phẩm. Phương án "Make the prototype appear as polished as possible." sai vì càng bóng bẩy càng tăng áp lực đưa vào sản xuất. Phương án "Provide detailed documentation for each prototype iteration." sai vì tài liệu chi tiết tốn công và không giảm ảo tưởng rằng bản mẫu đã dùng được. Phương án "Use functional prototypes that are nearly production-ready." sai vì bản mẫu gần như sẵn sàng sản xuất chính là thứ làm áp lực phát hành tăng lên.

Đáp án đúng: "A mock-up prototype focuses on the user experience, while a proof-of-concept prototype explores the technical soundness of a proposed approach.". Xét về phạm vi, mock-up là prototype ngang, mô phỏng giao diện và trải nghiệm người dùng mà không có logic thật phía sau, dùng để làm rõ yêu cầu người dùng; proof-of-concept là prototype dọc, cài đặt một lát cắt qua mọi tầng kỹ thuật để kiểm tra cách tiếp cận kỹ thuật có đứng vững không. "A mock-up prototype focuses on technical feasibility, while a proof-of-concept prototype focuses on user experience." sai vì đảo ngược hai vai trò. "A mock-up prototype is always throwaway, while a proof-of-concept prototype is always evolutionary." sai vì vứt bỏ hay tiến hoá là cách phân loại theo mục đích sử dụng sau này, độc lập với phạm vi; prototype nào cũng có thể là loại vứt bỏ hoặc tiến hoá, và chữ always làm phát biểu sai. "A mock-up prototype is used for testing performance, while a proof-of-concept is used for testing functionality." sai vì mock-up không có xử lý thật nên không đo hiệu năng được; proof-of-concept thì lại hay dùng để thử hiệu năng của một kiến trúc. "None of the above." sai vì có một phát biểu mô tả đúng sự khác biệt.

Đáp án đúng: "Availability". Tính sẵn sàng (availability) là thuộc tính chất lượng đo mức độ dịch vụ của hệ thống có thể dùng được khi và ở nơi người dùng cần, thường đặc tả bằng tỉ lệ thời gian hoạt động trong các khung giờ quy định, ví dụ 99,5 phần trăm trong giờ làm việc. "Usability" là tính dễ dùng: người dùng học, thao tác và đạt mục tiêu dễ dàng, hiệu quả và ít lỗi đến đâu, không nói về việc hệ thống có hoạt động hay không. "Security" là khả năng bảo vệ hệ thống và dữ liệu khỏi truy cập trái phép và tấn công. "Performance" là hiệu năng, đo tốc độ phản hồi, thông lượng hay khả năng xử lý tải, tức hệ thống chạy nhanh đến đâu khi đang hoạt động, chứ không phải nó có sẵn để dùng hay không.

Đáp án đúng: "Modifiability". Thuộc tính chất lượng nội tại (internal quality attribute) là thứ nhà phát triển và người bảo trì cảm nhận được chứ người dùng không trực tiếp thấy. Modifiability (khả năng sửa đổi) đo mức dễ dàng khi sửa lỗi, thay đổi và mở rộng hệ thống, bao trùm cả khả năng bảo trì, nên khớp đúng mô tả. Phương án "Efficiency" nói về việc dùng tài nguyên như bộ xử lý, bộ nhớ, băng thông một cách tiết kiệm. Phương án "Scalability" nói về khả năng phục vụ thêm người dùng, dữ liệu hay giao dịch mà vẫn giữ hiệu năng. Phương án "Reusability" nói về mức độ các thành phần có thể dùng lại ở hệ thống khác. Cả ba cũng là thuộc tính nội tại nhưng không trực tiếp diễn tả việc dễ bảo trì, thay đổi và nâng cấp.

Đáp án đúng: "A summary page displaying key metrics and charts". Trong đặc tả yêu cầu về báo cáo, dashboard (bảng điều khiển) là một màn hình hay báo cáo tổng hợp gồm nhiều biểu diễn dạng chữ và đồ thị, cho người dùng thấy nhanh các chỉ số chính của một quy trình hay tổ chức; khi đặc tả cần ghi rõ nguồn dữ liệu, cách tính, tần suất làm mới và bố cục từng thành phần. "A user interface element to display a menu" sai vì thành phần hiển thị menu chỉ là cơ chế điều hướng, không tổng hợp dữ liệu. "A module for adding user accounts" sai vì đó là chức năng quản trị người dùng, thuộc yêu cầu chức năng nhập liệu chứ không phải báo cáo. "A document used for manual reporting" sai vì dashboard là màn hình tự động lấy và hiển thị dữ liệu, thường cập nhật gần thời gian thực, không phải tài liệu báo cáo làm bằng tay.

Đáp án đúng: "To visually depict the steps involved in a business process or the operations of a proposed software system, subdivided into lanes that represent different systems or actors.". Swimlane diagram (sơ đồ làn bơi) là mô hình phân tích quy trình: các bước của một quy trình nghiệp vụ hay hoạt động của hệ thống được vẽ thành luồng, chia vào các làn ngang hoặc dọc, mỗi làn là một tác nhân, phòng ban hay hệ thống, nhờ đó thấy rõ ai làm bước nào và chỗ chuyển giao giữa các bên, rất có ích để khơi gợi yêu cầu. Phương án "To represent detailed software architecture and coding structures." sai vì kiến trúc và cấu trúc mã thuộc mô hình thiết kế. Phương án "To exclusively model user interface interactions and design layouts." sai vì bố cục giao diện được thể hiện bằng wireframe hay prototype. Phương án "To show the organizational structure and management hierarchy within a company." mô tả sơ đồ tổ chức; làn có thể ứng với phòng ban nhưng sơ đồ thể hiện luồng công việc, không phải quan hệ cấp bậc.

Đáp án đúng: "business process". Sơ đồ làn bơi (swimlane diagram) chia quy trình thành các làn, mỗi làn là một vai trò, bộ phận hay hệ thống, rồi vẽ các bước và luồng chuyển giữa chúng; nó dùng để mô tả quy trình nghiệp vụ hiện tại hoặc tương lai, hay các thao tác của hệ thống phần mềm đề xuất, giúp tìm ra yêu cầu người dùng và yêu cầu chức năng ở từng bước. Phương án "design process" sai vì sơ đồ làn bơi trong phân tích yêu cầu mô tả công việc nghiệp vụ chứ không mô tả quy trình thiết kế phần mềm. Phương án "organizational activities" nghe gần nhưng quá chung, không chỉ ra chuỗi bước có thứ tự của một quy trình. Phương án "stakeholders" sai vì các bên liên quan có thể là chủ của các làn, nhưng sơ đồ thể hiện các bước của quy trình chứ không thể hiện bản thân các bên liên quan.

Đáp án đúng: "Name each process using a concise verb-object action". Trong data flow diagram (sơ đồ luồng dữ liệu), mỗi tiến trình biến đổi dữ liệu vào thành dữ liệu ra, nên nó được đặt tên bằng một động từ hành động đi kèm đối tượng, ngắn gọn và rõ nghĩa, ví dụ Generate Inventory Report hay Validate Order; quy ước này giúp mô hình phân tích dễ đọc và khớp với yêu cầu chức năng. "Use a verb only" sai vì chỉ có động từ thì không biết tiến trình tác động lên dữ liệu nào, chẳng hạn Process hay Handle quá mơ hồ. "Use a noun only" sai vì danh từ dùng để đặt tên kho dữ liệu, luồng dữ liệu và thực thể ngoài, không diễn tả được hành động. "Name the process after its corresponding data store" sai vì tiến trình và kho dữ liệu là hai loại thành phần khác nhau, một tiến trình còn có thể đọc ghi nhiều kho.

Đáp án đúng gồm hai ý: "Use a consistent format for documenting requirements to enhance clarity and understanding among all stakeholders." và "The software requirements specification (SRS) should be used to formally record the agreed-upon requirements and ensure all stakeholders have a shared understanding.". Trong hoạt động đặc tả (specification), yêu cầu nên được viết theo một khuôn và phong cách thống nhất để người đọc dễ tìm, dễ hiểu và dễ rà soát, và tài liệu SRS là nơi chính thức ghi lại các yêu cầu đã được thống nhất, làm cơ sở chung cho thiết kế, kiểm thử và quản lý thay đổi. Phương án đòi "documented in multiple places to increase visibility" sai vì ghi một yêu cầu ở nhiều nơi gây trùng lặp, khi sửa một chỗ mà quên chỗ khác sẽ sinh mâu thuẫn; nên ghi một lần rồi tham chiếu. Phương án "Avoid documenting requirements that involve complex logic" sai vì logic phức tạp càng cần đặc tả rõ, có thể dùng bảng quyết định hay cây quyết định để trình bày dễ hiểu.

Đáp án đúng: "Logical data model". Theo khuôn SRS (đặc tả yêu cầu phần mềm) chuẩn, mục Data requirements (yêu cầu dữ liệu) là phần cố định chứa logical data model (mô hình dữ liệu logic) và từ điển dữ liệu, nên đây là thành phần chắc chắn thuộc SRS. Có tài liệu ôn tập chọn "Usecase descripions", và mô tả ca sử dụng đôi khi được đính kèm SRS, nhưng theo cách tách tài liệu chuẩn chúng thường nằm ở tài liệu yêu cầu người dùng, còn SRS mô tả các yêu cầu chức năng dẫn xuất từ đó; vì vậy mô hình dữ liệu logic mới là mục cố định của SRS. Phương án "Vision statement", "Succes metrics" và "Limitations and exclusions" đều thuộc tài liệu tầm nhìn và phạm vi (vision and scope document): tuyên bố tầm nhìn nêu sản phẩm hướng tới đâu, chỉ số thành công đo mục tiêu kinh doanh, còn giới hạn và loại trừ xác định những gì không làm.

Đáp án đúng gồm ba ý: "It allows us to refer to specific requirements in a change request, modification history, cross-reference, or requirements traceability matrix.", "It enables reusing the requirements in multiple projects." và "It facilitates collaboration between team members when they’re discussing requirements.". Gán nhãn định danh duy nhất (unique identifier) cho từng yêu cầu trong SRS là thực hành của đặc tả và quản lý yêu cầu: có nhãn ổn định thì yêu cầu được trỏ tới chính xác trong yêu cầu thay đổi, lịch sử sửa đổi, tham chiếu chéo và ma trận truy vết; được gọi lại khi tái sử dụng ở dự án khác; và khi thảo luận mọi người nói cùng một yêu cầu mà không phải chép lại cả câu. Phương án "It makes the SRS look more professional." sai vì vẻ chuyên nghiệp không phải lý do kỹ thuật; nhãn có giá trị vì giúp truy vết và quản lý thay đổi, không phải để trang trí tài liệu.

Đáp án đúng: "include". Quan hệ include nghĩa là ca sử dụng cơ sở luôn gọi tới ca sử dụng được bao gồm như một hành vi con dùng chung; extend nghĩa là ca mở rộng chỉ chen vào ca cơ sở khi một điều kiện tuỳ chọn xảy ra. Ở đây chọn include với lập luận thanh toán hoá đơn luôn cần bước viết séc như một hành vi con dùng chung. Cần nói thẳng đây là câu còn tranh cãi: câu hỏi không mô tả nội dung hai ca sử dụng, tên Play a bill ở đây cần hiểu là Pay a bill (thanh toán hoá đơn), và nếu viết séc chỉ là một trong nhiều cách thanh toán tuỳ chọn thì quan hệ hợp lý lại là "extend"; đáp án được chốt vẫn là include. "generalization" không khớp vì quan hệ tổng quát hoá dùng khi một ca là phiên bản chuyên biệt của ca kia, mà viết séc là một bước trong việc trả tiền chứ không phải một kiểu thanh toán hoá đơn.

Đáp án đúng: "Include relationship". Quan hệ include dùng khi một chuỗi bước chung được nhiều ca sử dụng cần tới; phần chung được tách thành ca sử dụng riêng, và các ca sử dụng gốc luôn gọi nó. Kiểm tra tín dụng ở đây là bước bắt buộc của cả gửi yêu cầu vay lẫn đề nghị hạn mức tín dụng, nên hai ca sử dụng này include ca sử dụng Perform credit check. "Extend relationship" sai vì extend dùng cho hành vi tuỳ chọn hoặc chỉ xảy ra khi có điều kiện, bổ sung vào ca sử dụng gốc tại một điểm mở rộng; ca gốc vẫn hoàn chỉnh khi không có phần mở rộng, trong khi kiểm tra tín dụng là phần không thể thiếu. "Generalization relationship" sai vì khái quát hoá diễn tả quan hệ cha con, ca sử dụng con là một dạng đặc biệt của ca cha và kế thừa hành vi; kiểm tra tín dụng không phải dạng tổng quát của gửi yêu cầu vay hay đề nghị hạn mức, mà chỉ là một bước dùng chung.

Đáp án đúng: "A verb followed by an object". Tên use case nên thể hiện mục tiêu mà tác nhân muốn đạt, viết dạng động từ hành động cộng tân ngữ, ví dụ Request a Chemical hay Print Boarding Pass, để đọc tên là hiểu ngay người dùng làm gì với hệ thống. "A noun followed by a verb" sai trật tự, kiểu đặt tên này khiến tên giống mô tả sự vật thay vì hành động hướng tới mục tiêu. "A random combination of words" rõ ràng không có giá trị vì tên use case phải nhất quán và dễ hiểu cho mọi bên liên quan. "A descriptive phrase" nghe hợp lý nhưng quá chung chung: một cụm mô tả có thể là danh từ hay tên chức năng như Chemical Management, không nói rõ hành động và mục tiêu cụ thể, nên không phải quy ước đặt tên được khuyến nghị.

Đáp án đúng: "To gather structured information from a large number of users". Questionnaire (bảng câu hỏi khảo sát) là kỹ thuật khơi gợi yêu cầu cho phép thu thập dữ liệu có cấu trúc từ rất nhiều người với chi phí thấp, hữu ích khi người dùng đông, phân tán về địa lý hoặc khi cần số liệu thống kê về thói quen, mức hài lòng; điểm yếu là khó hỏi sâu nên thường kết hợp với phỏng vấn hay workshop. Phương án "To create user stories" sai vì user story được viết từ thông tin đã khơi gợi, khảo sát chỉ là một nguồn đầu vào. Phương án "To define technical specifications" sai vì đặc tả kỹ thuật là việc của thiết kế, người trả lời khảo sát không định nghĩa nó. Phương án "To train users on the system" sai vì đào tạo người dùng là hoạt động triển khai, không thuộc khơi gợi yêu cầu.

Đáp án đúng: "Data Definitions (DD)". Định nghĩa dữ liệu (data definitions) mô tả đặc điểm và cấu trúc của dữ liệu hệ thống xử lý: tên phần tử, kiểu, độ dài, định dạng, miền giá trị, thành phần của cấu trúc phức hợp; chúng thường được gom trong từ điển dữ liệu (data dictionary) và gắn với mô hình dữ liệu như ERD. Phương án "Process Descriptions (PD)" sai vì mô tả quy trình nói về các bước xử lý, biến đổi dữ liệu chứ không nói cấu trúc của dữ liệu. Phương án "Business Rules (BR)" sai vì quy tắc nghiệp vụ là chính sách, ràng buộc, công thức tính của tổ chức; chúng có thể ràng buộc giá trị dữ liệu nhưng không định nghĩa cấu trúc dữ liệu. Phương án "Quality Attributes (QA)" sai vì thuộc tính chất lượng mô tả hệ thống tốt tới mức nào khi vận hành như hiệu năng, bảo mật, không phải đặc điểm dữ liệu.