Tất cả câu hỏi

Đáp án đúng: "The steps involved in a process and the roles or departments responsible for each step". Swimlane diagram (sơ đồ làn bơi) là một dạng sơ đồ quy trình chia thành các làn ngang hoặc dọc, mỗi làn ứng với một vai trò, bộ phận hay hệ thống; các bước được đặt vào làn của bên thực hiện nên người đọc thấy cả trình tự công việc lẫn ai chịu trách nhiệm. Trong kỹ nghệ yêu cầu nó dùng ở bước phân tích để mô hình hoá quy trình nghiệp vụ và tìm yêu cầu còn thiếu. "The system's data flow" là nội dung của data flow diagram, vốn không có khái niệm làn theo vai trò. "The transition of states in a system" là việc của state-transition diagram hay state table, mô tả đối tượng chuyển trạng thái. "The user interface design" thuộc về wireframe, prototype hay dialog map, không phải sơ đồ làn bơi.

Đáp án đúng: "It ensures that high-value requirements are implemented first.". Khi các bên liên quan đưa ra yêu cầu xung đột hoặc vượt quá nguồn lực, ưu tiên hoá (prioritization) là hoạt động phân tích giúp quyết định cái gì làm trước dựa trên giá trị kinh doanh, chi phí, rủi ro; nhờ đó xung đột được giải quyết bằng tiêu chí chung thay vì theo ai nói to hơn, và phần giá trị cao nhất được giao sớm. "It eliminates non-functional requirements from consideration." sai vì ưu tiên hoá áp dụng cho cả yêu cầu phi chức năng; thuộc tính chất lượng như bảo mật hay hiệu năng có thể được xếp ưu tiên rất cao. "It finalizes all requirements before the design phase." sai vì xếp ưu tiên không chốt cứng toàn bộ yêu cầu; danh sách ưu tiên còn được xem lại khi có thay đổi. "It focuses on budget over stakeholder needs" sai vì ưu tiên hoá cân nhắc chi phí cùng với giá trị cho bên liên quan, không đặt ngân sách lên trên nhu cầu của họ.

Đáp án đúng: "Business requirements". Tài liệu tầm nhìn và phạm vi (Vision and Scope Document) ghi tầng yêu cầu nghiệp vụ: cơ hội hay vấn đề kinh doanh, mục tiêu nghiệp vụ, chỉ số thành công, tầm nhìn sản phẩm cùng phạm vi và giới hạn của dự án. Nó được xây dựng từ yêu cầu nghiệp vụ, rồi chính nó làm khung để khơi gợi các tầng bên dưới. Phương án "User requirements" sai vì yêu cầu người dùng (mô tả việc người dùng cần làm, thường bằng use case hay user story) được ghi ở tài liệu yêu cầu người dùng và phải nằm trong phạm vi tầm nhìn đã đặt, tức là đi sau. Phương án "System requirements" sai vì yêu cầu hệ thống mô tả hệ thống gồm nhiều thành phần phần cứng và phần mềm, ở tầng chi tiết hơn nhiều. Phương án "Original requirements" không phải tên một tầng yêu cầu chuẩn trong kỹ nghệ yêu cầu.

Đáp án đúng: "The project risks significant delays and cost overruns". Đạt thoả thuận về yêu cầu (requirements agreement) mà chưa thật sự rõ ràng nghĩa là các bên ký vào những điều họ hiểu khác nhau; khi mơ hồ lộ ra ở thiết kế, xây dựng hay kiểm thử, đội phải làm lại, và chi phí sửa lỗi yêu cầu càng về sau càng đắt. Đó là lý do yêu cầu thiếu rõ ràng là nguồn rủi ro lớn về tiến độ và chi phí. "The developers will proceed with an ambiguous understanding" mô tả một hiện tượng có thể xảy ra, nhưng đó là nguyên nhân trung gian chứ không phải hệ quả mà câu hỏi nhắm tới; hậu quả thực sự của việc làm theo cách hiểu mơ hồ chính là trễ hạn và vượt ngân sách. "Customer feedback will be ignored" sai vì sự mơ hồ không khiến phản hồi bị bỏ qua; ngược lại thường dẫn tới nhiều phản hồi và yêu cầu sửa. "The project will be automatically canceled" sai vì không có cơ chế huỷ tự động nào; dự án vẫn chạy, chỉ là với rủi ro cao hơn.

Đáp án đúng: "70-85%". Số liệu thường được trích dẫn trong kỹ nghệ yêu cầu cho thấy làm lại (rework) chiếm một phần lớn chi phí phát triển, và trong phần làm lại đó, khoảng 70 tới 85 phần trăm bắt nguồn từ lỗi yêu cầu như thiếu, sai, mơ hồ hay mâu thuẫn. Lý do là lỗi yêu cầu được phát hiện càng muộn thì càng phải sửa lan qua thiết kế, mã, kiểm thử và tài liệu, nên đầu tư vào khơi gợi, đặc tả và thẩm định tốt mang lại lợi ích lớn. Phương án "10-30%" quá thấp, đánh giá thấp vai trò của yêu cầu trong chi phí làm lại. Phương án "30-50%" dễ gây nhầm vì đó gần với tỷ lệ mà làm lại chiếm trong tổng chi phí phát triển, chứ không phải tỷ lệ làm lại do lỗi yêu cầu. Phương án "90-100%" quá cao vì lỗi thiết kế, lỗi lập trình và lỗi môi trường cũng gây làm lại.

Đáp án đúng gồm hai ý: "In the waterfall life cycle, most of the requirements development effort is concentrated at the beginning of the project." và "Agile and incremental development projects allocate requirements development effort throughout the project, with small but frequent efforts.". Cách phân bổ công sức phát triển yêu cầu phụ thuộc vòng đời: mô hình thác nước dồn phần lớn việc khơi gợi, phân tích, đặc tả và thẩm định vào đầu dự án rồi mới thiết kế và xây dựng; dự án lặp, tăng dần hay agile làm một ít yêu cầu đủ cho từng vòng lặp, lặp lại nhiều lần suốt dự án. "Iterative and phased life cycles involve gathering and refining requirements only once at the start of the project." sai vì đặc trưng của vòng đời lặp và phân giai đoạn là mỗi vòng hay mỗi giai đoạn lại thu thập và tinh chỉnh yêu cầu cho phần sắp làm, không phải một lần duy nhất. "Regardless of the life cycle, no additional requirements work is needed once the initial requirements phase is complete." sai vì ở mọi vòng đời yêu cầu vẫn thay đổi và phải được làm rõ, quản lý thay đổi, cập nhật suốt dự án, kể cả thác nước.

Đáp án đúng: "It helps in delivering the most critical or valuable functionality as early as possible, ensuring maximum business value within project constraints.". Trong dự án agile, backlog sản phẩm được sắp ưu tiên liên tục để mỗi vòng lặp (iteration) giao phần có giá trị cao nhất trước; khi kỳ vọng của khách hàng cao mà thời gian ngắn, ưu tiên hoá (prioritization) là cách quyết định làm gì trước, hoãn gì, để giá trị kinh doanh đạt tối đa trong giới hạn thời gian, ngân sách và nhân lực. Phương án nói việc ưu tiên giúp quản lý dự án làm "without customer input, focusing solely on cost and efficiency" sai vì ưu tiên hoá cần khách hàng hoặc product owner tham gia đánh giá giá trị, không thể chỉ dựa vào chi phí. Phương án cho rằng ưu tiên để bỏ bớt tính năng và chỉ đảm bảo "only critical bugs are fixed before release" sai vì ưu tiên hoá áp cho mọi hạng mục trong backlog, mục đích là giao giá trị chứ không phải chỉ sửa lỗi nghiêm trọng. Phương án cho quản lý dự án "choose which requirements to ignore" chỉ theo ngân sách và nhân sự sai vì ưu tiên không phải đơn phương gạt bỏ yêu cầu mà là sắp thứ tự cùng các bên liên quan, cân nhắc giá trị, chi phí và rủi ro.

Đáp án đúng: "Stakeholders stuffing in more features to satisfy every interest, risking the project collapsing under its own weight.". Scope creep (phình phạm vi) là khi yêu cầu mới liên tục được thêm vào sau khi phạm vi đã thống nhất; khi không có quy trình kiểm soát thay đổi (change control) để đánh giá tác động và quyết định nhận hay từ chối, các bên liên quan cứ nhồi tính năng để chiều mọi mong muốn, khiến chi phí, tiến độ và chất lượng vỡ dần cho tới khi dự án sụp vì chính khối lượng của nó. Phương án "Adjusting scope in a controlled way to optimize cost." sai vì điều chỉnh có kiểm soát chính là quản lý phạm vi đúng cách, ngược với chữ uncontrolled. Phương án "Cutting scope to meet a deadline." là thu hẹp phạm vi, không phải phình ra. Phương án "Improving quality without changing scope." không đụng tới phạm vi nên không thể là scope creep. Phương án "Moving part of the scope to a later phase as planned." là hoãn tính năng sang bản phát hành sau theo kế hoạch, một kỹ thuật hợp lệ để giữ phạm vi trong tầm kiểm soát.

Đáp án đúng: "Written requirements.". Bản mẫu (prototype) giúp khơi gợi và thẩm định yêu cầu bằng cách cho người dùng nhìn và thử một phần hệ thống, nhưng nó không ghi lại được các chi tiết ẩn như quy tắc nghiệp vụ, điều kiện ngoại lệ, yêu cầu chất lượng hay logic phía sau màn hình; vì vậy bản mẫu chỉ bổ sung chứ không thay thế yêu cầu viết thành văn bản. Phương án "Multiple iterations." không phải thứ bản mẫu thay thế, mà ngược lại việc làm bản mẫu thường cần nhiều vòng lặp đánh giá và chỉnh sửa. Phương án "Plausible data." là lời khuyên khi làm bản mẫu: dùng dữ liệu hợp lý, giống thật để người đánh giá không bị phân tâm, chứ không phải thứ bị thay thế. Phương án "The purpose of the prototype" là điều cần xác định rõ trước khi làm bản mẫu (thăm dò hay tiến hoá, bỏ đi hay giữ lại), bản mẫu không thể thay mục đích của chính nó.

Đáp án đúng: "To reduce the effort and cost of requirements development". Tái sử dụng yêu cầu (requirements reuse) là lấy lại những yêu cầu đã được viết, rà soát và kiểm chứng ở dự án trước hay ở thành phần dùng chung, nhờ đó giảm công sức và chi phí cho các hoạt động khơi gợi, phân tích, đặc tả và thẩm định; lợi ích kéo theo là tính nhất quán và chất lượng cao hơn. "To improve system security" sai vì bảo mật không phải mục tiêu chính của tái sử dụng, chỉ khi tái dùng đúng yêu cầu bảo mật đã kiểm chứng thì mới có ích gián tiếp. "To validate requirements more efficiently" chỉ là lợi ích phụ: yêu cầu tái dùng vẫn phải được thẩm định trong bối cảnh mới. "To develop new requirements faster" dễ gây nhầm nhưng tái sử dụng không sinh ra yêu cầu mới, nó dùng lại yêu cầu có sẵn, còn tốc độ là hệ quả của việc giảm công sức.

Đáp án đúng: "It is a language with a rich set of keywords that permits precise statements of quality attributes and other project goals.". Planguage là ngôn ngữ đặc tả do Tom Gilb đề xuất, dùng các từ khoá như TAG, GIST, SCALE, METER, MUST, PLAN, WISH để viết thuộc tính chất lượng sao cho đo được: chỉ rõ đại lượng đo, cách đo, mức tối thiểu chấp nhận và mức mong muốn. Nó giúp tránh các câu mơ hồ kiểu "hệ thống phải nhanh". "It is a programming language." sai vì Planguage không biên dịch hay chạy được, nó chỉ dùng để viết yêu cầu. "It is a planning language used in project management." sai vì dù tên gợi chữ planning, nó không dùng để lập lịch hay phân bổ nguồn lực mà để đặc tả mục tiêu định lượng. "It is a language to express non functional requirements." chỉ đúng một phần: Planguage hay được dùng cho yêu cầu phi chức năng, nhưng phát biểu này thiếu điểm cốt lõi là bộ từ khoá phong phú cho phép viết chính xác, và nó còn áp dụng cho các mục tiêu dự án khác chứ không riêng yêu cầu phi chức năng, nên không phải mô tả đầy đủ nhất.

Đáp án đúng: "GOAL". Planguage là ngôn ngữ do Tom Gilb đề xuất để đặc tả định lượng thuộc tính chất lượng bằng các từ khoá. Trong cách dùng Planguage cho yêu cầu chất lượng, từ khoá GOAL ghi mức đạt tối thiểu chấp nhận được của thuộc tính trên thang đo đã định, tức là mức sản phẩm bắt buộc phải đạt để được chấp nhận; bên trên nó là STRETCH cho mức mong muốn hơn và WISH cho mức lý tưởng. "SCALE" sai vì nó định nghĩa thang đo của thuộc tính, chẳng hạn số giây hay phần trăm giao dịch, chứ không đặt ra mức cần đạt. "AMBITION" chỉ là phát biểu định tính ngắn về ý định cải thiện, chưa có con số. "WISH" là mức mong muốn lý tưởng nếu không bị giới hạn chi phí hay thời gian, cao hơn mức cam kết nên không thể là mức tối thiểu.

Đáp án đúng: "Decisions in a Decision Tree". Khi đọc văn bản yêu cầu để chọn mô hình phân tích, các từ chỉ điều kiện như if, when, unless báo hiệu logic rẽ nhánh, nên ánh xạ tự nhiên sang nút quyết định trong cây quyết định (decision tree) hoặc bảng quyết định (decision table), nơi mỗi nhánh ứng với một tổ hợp điều kiện và hành động kèm theo. "Processes in a DFD" sai vì tiến trình trong sơ đồ luồng dữ liệu thường ứng với động từ chỉ hành động biến đổi dữ liệu, như tính toán hay ghi nhận. "Entities in an ERD" ứng với danh từ chỉ đối tượng dữ liệu cần lưu, như hoá chất hay nhà cung cấp. "Transitions in a State Transition Diagram" ứng với sự kiện làm một đối tượng đổi trạng thái; điều kiện chỉ xuất hiện ở đó dưới dạng điều kiện canh (guard) gắn trên một chuyển trạng thái, còn một điều kiện nghiệp vụ đứng riêng như ví dụ thì cây quyết định biểu diễn trực tiếp hơn.

Đáp án đúng gồm ba ý: "It is a partial implementation of a proposed new product.", "It is a possible implementation of a proposed new product." và "It is a preliminary implementation of a proposed new product.". Software prototype (bản mẫu phần mềm) là một hiện thực hóa mang tính thăm dò của sản phẩm định làm: nó chỉ dựng một phần (partial) như vài màn hình hay một luồng xử lý, nó là một cách hiện thực khả dĩ (possible) để người dùng nhìn thấy và phản hồi, và nó là bản sơ bộ (preliminary) làm trước khi phát triển thật. Prototype được dùng trong khơi gợi và thẩm định yêu cầu, giúp làm rõ chỗ mơ hồ và giảm rủi ro hiểu sai. Phương án "It is a complete implementation of a proposed new product." sai vì nếu đã hiện thực đầy đủ thì đó là sản phẩm chứ không còn là bản mẫu; giá trị của prototype nằm ở chỗ làm nhanh, rẻ, chỉ đủ để học hỏi, có thể vứt bỏ hoặc tiến hóa dần.

Đáp án đúng: "They are often ambiguous and difficult to quantify.". Yêu cầu phi chức năng (non-functional requirements), nhất là thuộc tính chất lượng như hiệu năng, khả dụng, bảo mật, thường được người dùng nói bằng lời mơ hồ kiểu "phải nhanh", "phải dễ dùng"; khó khăn chính khi khơi gợi (elicitation) là biến những mong muốn đó thành tiêu chí đo được, có thang đo và ngưỡng chấp nhận để kiểm chứng. Phương án "They are less important than functional requirements." sai vì thuộc tính chất lượng thường quyết định người dùng có chấp nhận hệ thống hay không. Phương án "They focus only on system design." sai vì chúng mô tả hệ thống phải tốt tới mức nào khi vận hành, còn thiết kế là cách đáp ứng chúng. Phương án "They do not require stakeholder input." sai vì chỉ các bên liên quan mới biết mức chất lượng nào chấp nhận được, nên phải hỏi họ.

Đáp án đúng: "External: Usability; Internal: Verifiability.". Thuộc tính chất lượng bên ngoài (external quality attribute) là thứ người dùng cảm nhận được khi vận hành hệ thống, như availability, installability, integrity, interoperability, performance, reliability, robustness, safety, security, usability; thuộc tính bên trong (internal) chủ yếu nhà phát triển và người bảo trì cảm nhận, như efficiency, modifiability, portability, reusability, scalability, verifiability. Usability là bên ngoài và verifiability (khả năng kiểm chứng) là bên trong nên cặp này đúng. "External: Performance; Internal: Security." sai vì security cũng là thuộc tính bên ngoài. "External: Reliability; Internal: Installability." sai vì installability là trải nghiệm cài đặt người dùng thấy trực tiếp, thuộc nhóm bên ngoài. "External: Portability; Internal: Scalability." sai vì portability là thuộc tính bên trong, đảo vị trí so với cách phân loại.

Đáp án đúng: "To provide a consistent structure for recording various groups of requirements-related information and to serve as a reminder of information to explore". Khuôn mẫu SRS (Software Requirements Specification, đặc tả yêu cầu phần mềm) chuẩn chia tài liệu thành các mục cố định như giới thiệu, mô tả tổng quát, tính năng hệ thống, yêu cầu dữ liệu, giao diện ngoài, thuộc tính chất lượng, nhờ đó mọi dự án ghi thông tin yêu cầu theo cùng một cấu trúc dễ tra cứu, đồng thời mỗi mục trống nhắc người phân tích còn chủ đề nào chưa khơi gợi. Phương án "To enforce a rigid document structure that cannot be changed" sai vì khuôn mẫu cần được điều chỉnh theo quy mô và loại dự án, được phép bỏ hoặc thêm mục. Phương án "To eliminate the need for any analysis activities" sai vì khuôn mẫu chỉ là nơi chứa kết quả, việc phân tích yêu cầu vẫn phải làm để có nội dung điền vào. Phương án "To ensure that the SRS is always a traditional paper document." sai vì SRS có thể nằm trong công cụ quản lý yêu cầu, wiki hay cơ sở dữ liệu, khuôn mẫu không ràng buộc hình thức lưu trữ.

Đáp án đúng: "Extent of assets, extent of modification, and mechanism of reuse.". Tái sử dụng yêu cầu (requirements reuse) được mô tả theo ba chiều: phạm vi tài sản được dùng lại (từ một câu yêu cầu lẻ tới cả bộ yêu cầu kèm mô hình, thiết kế, mã và ca kiểm thử), mức độ phải sửa đổi khi dùng lại (giữ nguyên hay chỉnh cho dự án mới) và cơ chế tái sử dụng (sao chép rồi dán vào tài liệu mới hay tham chiếu tới một kho yêu cầu dùng chung). Phương án "Scope, cost, and risk." là các yếu tố quản lý dự án, dùng để cân nhắc có nên tái sử dụng hay không chứ không phải chiều phân loại cách tái sử dụng. Phương án "Technical, business, and user levels" gợi tới các tầng yêu cầu (business, user, functional), tức là phân loại bản thân yêu cầu chứ không mô tả việc dùng lại chúng. Phương án "Elicitation, analysis, and validation." là các hoạt động của phát triển yêu cầu (khơi gợi, phân tích, thẩm định), không phải chiều của tái sử dụng.

Đáp án đúng: "By using clear, precise terms and avoiding vague language". Ambiguity (tính mơ hồ) xảy ra khi một yêu cầu có thể được hiểu theo nhiều cách khác nhau; một yêu cầu tốt phải unambiguous (không mơ hồ), nên khi đặc tả cần dùng từ chính xác, định lượng được, thống nhất với bảng thuật ngữ, và tránh các từ mơ hồ như nhanh, thân thiện, dễ dùng, hỗ trợ. Lỗi mơ hồ thường được phát hiện ở bước thẩm định qua review. "By including as many possible options as possible" sai vì đưa thêm nhiều lựa chọn chỉ khiến yêu cầu khó hiểu và khó kiểm thử hơn. "By being flexible in interpretation" đi ngược mục tiêu, vì cho phép diễn giải linh hoạt chính là bản chất của sự mơ hồ. "By relying on user preferences" không giải quyết chuyện cách viết: sở thích người dùng là nguồn của yêu cầu, còn yêu cầu vẫn phải được viết rõ ràng để mọi người hiểu như nhau.

Đáp án đúng: "A requirements effort estimation spreadsheet.". Seilevel, một công ty tư vấn chuyên về kỹ nghệ yêu cầu, xây dựng một bảng tính ước lượng công sức phát triển yêu cầu: người dùng nhập các đại lượng như số tác nhân, số quy trình nghiệp vụ, số màn hình hay số báo cáo dự kiến, bảng tính quy đổi ra số giờ cần cho khơi gợi, phân tích, đặc tả và thẩm định. Công cụ này phục vụ lập kế hoạch cho chính hoạt động phát triển yêu cầu, giúp BA và quản lý dự án dành đủ thời gian cho yêu cầu thay vì đoán mò. "A coding tool for developers." sai vì công cụ không liên quan tới viết mã, nó dùng ở giai đoạn yêu cầu. "A time-tracking tool for project managers." sai vì công cụ ghi giờ chỉ đo thời gian đã tiêu, còn bảng tính của Seilevel dự báo công sức trước khi làm. "A documentation tool for stakeholders." sai vì nó không dùng để soạn hay lưu tài liệu yêu cầu mà chỉ để ước lượng khối lượng việc.