Tất cả câu hỏi

Đáp án đúng: "Analysis". Phát triển yêu cầu gồm bốn hoạt động: khơi gợi, phân tích, đặc tả và thẩm định. Phân tích (analysis) là lúc nhu cầu thô của khách hàng được xử lý: làm rõ, phân rã, mô hình hoá, phát hiện xung đột, ưu tiên và chuyển thành yêu cầu phần mềm cụ thể, có quan hệ truy vết với nhu cầu gốc. "Elicitation" là khơi gợi, thu thập nhu cầu từ bên liên quan qua phỏng vấn, workshop, quan sát; nó tạo ra đầu vào thô chứ chưa xử lý thành yêu cầu phần mềm. "Specification" là đặc tả, ghi các yêu cầu đã phân tích thành tài liệu có cấu trúc như SRS. "Validation" là thẩm định, kiểm tra các yêu cầu đã ghi có phản ánh đúng nhu cầu và đủ chất lượng chưa, diễn ra sau khi yêu cầu đã được phân tích và viết ra.

Đáp án đúng: "To reveal insights and problems that no single view can provide.". Trong phân tích yêu cầu, biểu diễn cùng một nội dung bằng nhiều góc nhìn, như văn bản, sơ đồ luồng dữ liệu, sơ đồ trạng thái, mô hình dữ liệu hay prototype, giúp đối chiếu chéo: chỗ thiếu, mâu thuẫn hay mơ hồ khó thấy trong một dạng sẽ lộ ra khi so với dạng khác, và mỗi bên liên quan có thể hiểu tốt hơn qua dạng hợp với mình. Phương án "To increase the volume of project documentation." sai vì mục tiêu là hiểu sâu hơn, không phải tăng khối lượng giấy tờ. Phương án "To make the requirements more complex." sai vì nhiều góc nhìn giúp làm rõ, không làm rối yêu cầu. Phương án "To meet strict compliance regulations." sai vì có lĩnh vực đòi hỏi tài liệu theo quy định, nhưng đó không phải lý do cốt lõi để mô hình hóa yêu cầu bằng nhiều cách.

Đáp án đúng: "Involving customers throughout the development process to continuously refine and validate requirements.". Cách tiếp cận agile coi yêu cầu sẽ thay đổi và được hiểu dần, nên điều cốt lõi để sản phẩm đúng nhu cầu là khách hàng tham gia liên tục: làm rõ story trước mỗi vòng lặp, xem bản demo và phản hồi để điều chỉnh, tức là khơi gợi và thẩm định yêu cầu diễn ra suốt dự án. Phương án "Documenting all requirements in detail before development begins." sai vì đó là cách làm kiểu thác nước, trái với tinh thần agile là chi tiết hoá đúng lúc. Phương án "Prioritizing speed over accuracy to deliver functionality quickly." sai vì giao nhanh mà sai nhu cầu thì vô ích, agile giao nhanh để nhận phản hồi chứ không hy sinh độ đúng. Phương án "Focusing solely on the technical aspects." sai vì bỏ qua góc nhìn nghiệp vụ và người dùng.

Đáp án đúng: "Estimate the effort required to implement the change". Thủ tục phân tích tác động thay đổi đi theo thứ tự: bước một là hiểu các hệ quả có thể có của thay đổi; bước hai là xác định các việc cần làm, dùng truy vết yêu cầu để tìm mọi yêu cầu, thiết kế, mã, ca kiểm thử, tài liệu bị ảnh hưởng; bước ba là ước lượng công sức để thực hiện từng việc đó, rồi cộng lại để thấy tác động lên chi phí và lịch. "Understand the implications of the change" sai vì đó là bước đầu tiên, phải hiểu thay đổi kéo theo gì rồi mới tìm việc cụ thể. "Identify tasks required to implement the change" sai vì đó là bước thứ hai, chỉ khi đã có danh sách việc mới ước lượng được công sức. "Communicate the change to stakeholders" sai vì báo kết quả phân tích cho ban kiểm soát thay đổi và bên liên quan là bước cuối, sau khi đã có ước lượng.

Đáp án đúng: "Request for Proposal (RFP), requirements specification, and product acceptance criteria.". Trong dự án thuê ngoài (outsourced project), bên đặt hàng không ngồi cạnh đội phát triển nên tài liệu là kênh truyền yêu cầu chính; ba sản phẩm nền tảng gửi cho nhà cung cấp là hồ sơ mời thầu để họ hiểu nhu cầu và đề xuất, đặc tả yêu cầu đủ chi tiết vì không thể hỏi lại thường xuyên, và tiêu chí chấp nhận sản phẩm để hai bên thống nhất khi nào sản phẩm được coi là đạt. "Project plan, progress reports, and contracts." là tài liệu quản lý dự án và pháp lý, không phải nền tảng yêu cầu. "Design specification, test plan, and user manuals." thường do nhà cung cấp tạo ra trong quá trình làm, không phải đầu vào gửi đi. "Meeting minutes, risk logs, and open issue lists." là tài liệu theo dõi phát sinh trong quá trình làm việc, không định nghĩa yêu cầu.

Đáp án đúng: "Aligning the requirements with business objectives". Với packaged solution (giải pháp đóng gói, phần mềm mua sẵn như COTS), tổ chức không tự xây mà chọn và cấu hình sản phẩm có sẵn, nên yêu cầu người dùng cần tập trung vào việc người dùng phải làm được gì để đạt mục tiêu kinh doanh, rồi dùng chúng để đánh giá gói nào đáp ứng tốt nhất và xác định cần cấu hình, tích hợp hay mở rộng gì. Phương án "Focusing solely on user interface design" sai vì giao diện do nhà cung cấp quyết định phần lớn và không phải trọng tâm duy nhất. Phương án "Ensuring compatibility with the development platform" sai vì tổ chức không phát triển gói, dù khả năng tích hợp với môi trường hiện có vẫn cần xem xét. Phương án "Defining the technical architecture of the solution" sai vì kiến trúc kỹ thuật đã do nhà cung cấp xác định.

Đáp án đúng: "Users who are familiar with how the system works today might like the changes they are about to encounter.". Câu hỏi tìm phát biểu sai về thách thức của dự án nâng cấp và thay thế hệ thống; thách thức thật là người dùng đã quen cách hệ thống đang chạy thường không thích thay đổi và có thể phản đối, nên nói họ có thể thích thay đổi không phải một thách thức. Phương án "degrade the performance to which users are accustomed" đúng vì thay đổi có thể làm chậm hệ thống so với điều người dùng đã quen. Phương án "Little or no requirements documentation might be available" đúng vì hệ thống cũ thường thiếu tài liệu yêu cầu. Phương án "unknowingly break or omit functionality that is vital" đúng vì dễ vô tình làm hỏng chức năng quan trọng với một nhóm. Phương án "request new functionality that seems like a good idea" đúng vì các bên dễ nhân dịp xin thêm tính năng không cần cho mục tiêu nghiệp vụ. Các phát biểu đúng này không được chọn.

Đáp án đúng: "Scalability". Architectural allocation (phân bổ yêu cầu vào kiến trúc) là việc gán yêu cầu cho các hệ thống con, thành phần phần cứng, phần mềm hay con người; những thuộc tính chất lượng tác động mạnh tới cấu trúc hệ thống như scalability (khả năng mở rộng), performance, availability hay security thường được xét nhiều nhất ở bước này, vì muốn đáp ứng chúng phải chọn cách chia thành phần và phân tải phù hợp. "Humor" không phải thuộc tính chất lượng phần mềm, không có ý nghĩa trong phân bổ kiến trúc. "Color selection" là quyết định trình bày giao diện, thuộc thiết kế giao diện chứ không ảnh hưởng tới cách chia thành phần hệ thống. "Typography" cũng là lựa chọn kiểu chữ trong thiết kế hình ảnh, không phải thuộc tính chất lượng được phân bổ vào kiến trúc.

Đáp án đúng: "Whether the cost of reuse is justified by the benefits". Tái sử dụng yêu cầu không miễn phí: phải tìm yêu cầu phù hợp, đánh giá, sửa cho khớp bối cảnh mới, và tổ chức phải đầu tư vào kho yêu cầu, chuẩn hoá cách viết, quản lý phiên bản. Vì vậy câu hỏi then chốt là lợi ích như tiết kiệm thời gian, nhất quán, giảm rủi ro có đủ lớn để bù chi phí đó không. "How much effort it will take to create new requirements" chỉ là một nửa của phép so sánh; công sức viết mới là một phần lợi ích, nhưng không cân với chi phí tái sử dụng thì chưa đủ để quyết định. "How many stakeholders are involved" sai vì số lượng bên liên quan không quyết định có nên dùng lại yêu cầu hay không. "How complex the new system is" sai vì độ phức tạp của hệ thống mới không trực tiếp cho biết yêu cầu cũ có dùng lại được, điều quan trọng là mức tương đồng và chi phí lợi ích.

Đáp án đúng: "Across an enterprise: business rules, stakeholder profiles, user class descriptions, user personas, glossary, security requirements". Tái sử dụng yêu cầu (requirements reuse) có nhiều phạm vi, và mỗi phạm vi phù hợp với một loại tài sản riêng. Ở phạm vi toàn doanh nghiệp, những thứ dùng chung cho nhiều sản phẩm của cùng tổ chức là quy tắc nghiệp vụ, hồ sơ bên liên quan, mô tả lớp người dùng, persona, bảng thuật ngữ và yêu cầu bảo mật, vì chúng phản ánh chính tổ chức chứ không phụ thuộc một ứng dụng. Phương án bắt đầu bằng "Within a product or application" gán cho phạm vi hẹp nhất một danh sách quá rộng như mục tiêu kinh doanh, ecosystem map, yêu cầu chứng nhận, vốn là tài sản dùng chung cho cả họ sản phẩm. Phương án "Across a product line" lại liệt kê tài sản đặc trưng cho cả một lĩnh vực nghiệp vụ như mô hình quy trình nghiệp vụ, yêu cầu tuân thủ. Phương án "Across a business domain" ghép với ràng buộc, giao diện, hạ tầng chức năng như bộ sinh báo cáo, vốn gắn với môi trường hay nền tảng vận hành. Phương án "Within an operating environment or platform" ghép với yêu cầu chức năng cụ thể trong use case, yêu cầu hiệu năng, vốn chỉ tái dùng được trong cùng một sản phẩm.

Đáp án đúng: "Evolutionary prototypes". Prototype được phân loại theo ba chiều: phạm vi (mock-up hay proof of concept), mục đích sử dụng về sau (throwaway hay evolutionary) và hình thức (paper hay electronic, độ trung thực thấp hay cao). Theo chiều sử dụng về sau, nguyên mẫu được phát triển dần qua các vòng lặp để trở thành sản phẩm thật là evolutionary prototype (nguyên mẫu tiến hoá), hợp với nhu cầu nghiệp vụ thay đổi nhanh. "Throwaway mock-ups" bị bỏ đi sau khi đã làm rõ yêu cầu, không phát triển thành sản phẩm. "Paper prototypes" là hình thức vẽ trên giấy, thuộc chiều hình thức và không thể trở thành sản phẩm. "Proof-of-concept prototypes" thuộc chiều phạm vi, dùng để kiểm tra tính khả thi kỹ thuật. "High-fidelity prototypes" nói về độ trung thực so với giao diện thật, không trả lời câu hỏi về mục đích sử dụng về sau.

Đáp án đúng: "A more desirable performance objective than the minimum goal". Trong Planguage, ngôn ngữ đặc tả định lượng thuộc tính chất lượng, STRETCH là mức mục tiêu thách thức, đáng mong muốn hơn mức mục tiêu đã cam kết; đạt được thì tốt nhưng không bắt buộc, giúp đội biết hướng cải thiện thêm khi điều kiện cho phép. "The ideal performance level" gần với nghĩa của từ khoá WISH, tức mức lý tưởng nếu không có giới hạn chi phí hay thời gian, cao hơn và xa vời hơn STRETCH. "A benchmark for testing" không phải ý nghĩa của STRETCH; cách đo và kiểm chứng giá trị được mô tả bằng các từ khoá như SCALE và METER. "A failure condition" ứng với từ khoá FAIL, mức mà dưới đó sản phẩm bị coi là không chấp nhận được, ngược hẳn với một mục tiêu thách thức.

Đáp án đúng: "A condition that must be satisfied or a state the system must be in before a use case can begin.". Trong đặc tả ca sử dụng, pre-condition (tiền điều kiện) là điều phải đúng trước khi ca bắt đầu, ví dụ người dùng đã đăng nhập; hệ thống không kiểm tra lại nó trong luồng chính mà mặc định nó đã thỏa. Phương án "A condition that describes the state of a system after a use case is successfully completed." là định nghĩa post-condition (hậu điều kiện), mô tả trạng thái sau khi ca kết thúc thành công. Phương án "A condition that initiates execution of the use case" là trigger (sự kiện kích hoạt), thứ khiến ca bắt đầu chạy, khác với điều kiện phải có sẵn. Phương án "A condition that must be satisfied so that system run successful." quá chung chung, nói về việc hệ thống chạy thành công nói chung, không gắn với thời điểm trước khi một ca sử dụng bắt đầu.

Đáp án đúng: "A rectangle". Trong sơ đồ thực thể quan hệ (ERD), thực thể (entity) là một đối tượng hay khái niệm mà hệ thống cần lưu dữ liệu, như khách hàng, đơn hàng, sản phẩm, và được vẽ bằng hình chữ nhật mang tên thực thể; các ký pháp phổ biến như Chen hay chân chim (crow's foot) đều dùng hình chữ nhật cho thực thể. Phương án "A diamond shape" sai vì hình thoi trong ký pháp Chen biểu diễn mối quan hệ (relationship) giữa các thực thể. Phương án "An oval shape" sai vì hình bầu dục trong ký pháp Chen biểu diễn thuộc tính (attribute) của thực thể. Phương án "A hexagon shape" sai vì hình lục giác không phải ký hiệu chuẩn cho thực thể trong các ký pháp ERD thông dụng.

Đáp án đúng: "Through a process bubble, not directly between data stores or between external entities and data stores.". Quy tắc của data flow diagram là dữ liệu chỉ được biến đổi bởi tiến trình, nên mỗi luồng dữ liệu phải có ít nhất một đầu là tiến trình; không được vẽ luồng trực tiếp giữa hai kho dữ liệu, giữa thực thể ngoài và kho dữ liệu, hay giữa hai thực thể ngoài. "Directly from one process to another." là luồng hợp lệ trong DFD, nhưng nó chỉ là một trường hợp riêng và không nêu được quy tắc chung mà câu hỏi muốn hỏi về cách luồng dữ liệu đi giữa tiến trình, kho dữ liệu và thực thể ngoài. "Directly from one data store to another." vi phạm quy tắc vì dữ liệu không thể tự di chuyển giữa hai kho mà không qua tiến trình nào xử lý. "Directly between external entities and data stores." cũng vi phạm, vì thực thể ngoài muốn đọc ghi kho dữ liệu phải đi qua một tiến trình của hệ thống.

Đáp án đúng: "State-transition diagram". State-transition diagram (sơ đồ chuyển trạng thái) biểu diễn các trạng thái mà hệ thống hay một đối tượng có thể ở, các chuyển tiếp hợp lệ giữa chúng và sự kiện, điều kiện kích hoạt mỗi chuyển tiếp; ví dụ đơn hàng đi từ mới tạo sang đã thanh toán, đã giao, đã huỷ. Nó giúp phát hiện chuyển tiếp thiếu hay không được phép. "Entity-relationship diagram" sai vì sơ đồ thực thể quan hệ mô hình hoá dữ liệu và quan hệ giữa các thực thể, không thể hiện trạng thái. "Swimlane diagram" sai vì sơ đồ làn bơi mô tả các bước quy trình và ai thực hiện bước nào. "Data flow diagram" sai vì sơ đồ luồng dữ liệu cho thấy dữ liệu đi qua các tiến trình và kho dữ liệu ra sao, không nói về trạng thái. "Dialog map" sai vì dù cũng dùng ý tưởng trạng thái, sơ đồ hội thoại chỉ dành cho giao diện người dùng, mô tả các màn hình và cách điều hướng giữa chúng, không phải trạng thái của hệ thống và đối tượng nói chung.

Đáp án đúng: "By visualizing requirements and identifying inconsistencies or gaps". Mô hình phân tích như sơ đồ luồng dữ liệu, sơ đồ trạng thái, mô hình dữ liệu hay bảng quyết định biểu diễn yêu cầu dưới dạng hình ảnh, giúp người đọc thấy cấu trúc và quan hệ mà văn bản che khuất; khi vẽ mô hình, chỗ thiếu bước, trạng thái không có đường ra hay dữ liệu không ai tạo sẽ lộ ra, nên đây là công cụ mạnh của hoạt động phân tích. "By prioritizing coding over documentation" sai vì mô hình hoá chính là một dạng tài liệu phân tích, không liên quan tới việc ưu tiên viết mã. "By finalizing all functional requirements early" sai vì mô hình hỗ trợ làm rõ yêu cầu, không nhằm chốt sớm mọi thứ. "By reducing stakeholder engagement" sai vì mô hình còn là phương tiện để trao đổi và xác nhận với bên liên quan, làm họ tham gia nhiều hơn.

Đáp án đúng: ""User-friendly"". Một yêu cầu tốt phải kiểm chứng được (verifiable), tức có cách kiểm thử hoặc đo xem hệ thống có đáp ứng hay không. Từ "thân thiện với người dùng" là thuật ngữ mơ hồ điển hình vì mỗi người hiểu một kiểu; nên thay bằng tiêu chí đo được, ví dụ người dùng mới hoàn thành đặt hàng trong ba phút mà không cần hướng dẫn. Phương án "The system shall" là cụm chuẩn để viết yêu cầu chức năng, chỉ rõ hệ thống chịu trách nhiệm, không gây mơ hồ. Phương án "The user shall" mô tả việc người dùng làm, có thể không nên dùng để viết yêu cầu hệ thống nhưng bản thân nó không phải từ ngữ mơ hồ. Phương án "Error message" là một khái niệm cụ thể; nội dung thông báo lỗi cần được đặc tả rõ, nhưng thuật ngữ này không khiến yêu cầu không kiểm chứng được.

Đáp án đúng: "Write in simple language, avoid jargon, and keep sentences short and direct.". Hướng dẫn viết yêu cầu rõ ràng khuyên dùng câu ngắn, ngôn ngữ đơn giản, tránh thuật ngữ khó hiểu với người đọc, mỗi câu diễn đạt một ý để ai đọc cũng hiểu như nhau; đây là kỹ năng của bước đặc tả. "Use long, descriptive sentences to cover all aspects of a requirement." sai vì câu dài dễ gộp nhiều yêu cầu và gây mơ hồ. "Avoid using “shall” or “must” in favor of softer terms like “could” and “may.”" sai vì từ mềm làm người đọc không biết yêu cầu có bắt buộc không; từ shall hay must dùng nhất quán mới thể hiện rõ mức bắt buộc. "Use multiple terms for the same concept to make the document more interesting." sai vì tài liệu yêu cầu cần dùng một thuật ngữ thống nhất cho mỗi khái niệm, đổi từ sẽ khiến người đọc tưởng là hai khái niệm khác nhau.

Đáp án đúng: "To outline the system’s requirements". Software Requirements Specification (SRS, đặc tả yêu cầu phần mềm) là tài liệu tập hợp các yêu cầu của hệ thống: yêu cầu chức năng, yêu cầu phi chức năng, giao diện ngoài, ràng buộc thiết kế và cài đặt. Nó trả lời câu hỏi hệ thống phải làm gì và tốt đến mức nào, làm cơ sở chung cho thiết kế, kiểm thử và quản lý dự án. "To define the software’s architecture" sai vì kiến trúc phần mềm là quyết định thiết kế, ghi trong tài liệu kiến trúc hay thiết kế, nằm sau SRS. "To provide a project management plan" sai vì kế hoạch dự án gồm lịch, nguồn lực, rủi ro là tài liệu riêng; SRS chỉ là đầu vào để lập kế hoạch đó. "To describe the system’s user interface" sai vì SRS có thể có mục giao diện người dùng, nhưng đó chỉ là một phần nhỏ, không phải mục đích của cả tài liệu; thiết kế màn hình chi tiết thường nằm ở tài liệu riêng.