Tất cả câu hỏi

Đá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.

Đáp án đúng: "Data sources, formats, and integration points". Khi chọn một giải pháp đóng gói (packaged solution, tức phần mềm thương mại mua sẵn), việc phân tích yêu cầu dữ liệu phải trả lời dữ liệu đến từ đâu, ở định dạng nào và giải pháp phải trao đổi dữ liệu với hệ thống nào khác, vì gói phần mềm có mô hình dữ liệu riêng nên cần ánh xạ, chuyển đổi, di trú và tích hợp với dữ liệu sẵn có của tổ chức. "Only the storage capacity of the solution" sai vì chữ only thu hẹp vào dung lượng lưu trữ, một ràng buộc kỹ thuật nhỏ chứ không phải toàn bộ nhu cầu dữ liệu. "User access permissions" thuộc yêu cầu bảo mật (security), quan trọng khi cấu hình gói nhưng không cho biết dữ liệu nào cần có và luân chuyển ra sao. "The cost of data storage" là yếu tố chi phí trong quyết định mua, không mô tả bản thân nhu cầu dữ liệu.

Đáp án đúng: "To define data items and structures with consistent definitions for all project stakeholders.". Data dictionary (từ điển dữ liệu) là kho tập trung định nghĩa từng phần tử dữ liệu và cấu trúc dữ liệu của miền bài toán: tên, ý nghĩa, kiểu, độ dài, miền giá trị, các thành phần cấu tạo nên nó. Công cụ này thuộc hoạt động phân tích và đặc tả yêu cầu dữ liệu, giúp khách hàng, người phân tích nghiệp vụ, lập trình viên và kiểm thử viên cùng hiểu một nghĩa duy nhất cho mỗi thuật ngữ dữ liệu, tránh mỗi nơi định nghĩa một kiểu. "To list all functional requirements in a project" sai vì danh sách yêu cầu chức năng nằm trong SRS hay product backlog, không phải trong từ điển dữ liệu. "To depict the sequence of process flows within a system" là việc của sơ đồ quy trình như activity diagram hay swimlane diagram. "To model user interface interactions." thuộc về mô hình giao diện như dialog map, wireframe hay prototype, không liên quan tới việc định nghĩa dữ liệu.

Đáp án đúng: "Eliciting, analyzing, documenting, and validating the needs of project stakeholders.". Business Analyst (BA, chuyên viên phân tích nghiệp vụ), còn gọi là requirements analyst, là người giữ vai trò chính trong kỹ nghệ yêu cầu: khơi gợi (elicitation) nhu cầu từ các bên liên quan, phân tích để làm rõ và phát hiện xung đột, viết thành đặc tả rồi thẩm định (validation) để chắc rằng yêu cầu phản ánh đúng điều họ cần. BA là cầu nối giữa phía khách hàng và đội phát triển, tập trung vào câu hỏi hệ thống phải làm gì. "Programming and testing software." là việc của lập trình viên và kiểm thử viên; BA có thể góp tiêu chí chấp nhận nhưng không viết mã hay chạy kiểm thử. "Designing system architecture and databases." thuộc về kiến trúc sư và người thiết kế, tức là quyết định hệ thống được xây như thế nào, một bước nằm sau khi yêu cầu đã rõ. "Managing project budget and schedule." là trách nhiệm của quản lý dự án (project manager); BA chỉ cung cấp yêu cầu làm đầu vào cho việc ước lượng và lập lịch chứ không nắm ngân sách hay tiến độ.

Đáp án đúng: "A small team to establish the best way to use the tool". Theo ISTQB Foundation, khi đưa một công cụ mới vào tổ chức nên bắt đầu bằng dự án thí điểm (pilot project) với một nhóm nhỏ: tìm hiểu công cụ chi tiết, xác định cách nó khớp với quy trình hiện có, đặt ra cách dùng chuẩn, quy ước đặt tên và cách bảo trì, đánh giá lợi ích so với chi phí. Chỉ sau khi thí điểm thành công mới triển khai rộng. "Everyone who may eventually have some use for the tool" sai vì triển khai cho mọi người ngay khi chưa có cách dùng chuẩn dễ dẫn tới dùng lộn xộn và thất bại. "The independent testing team" không phải câu trả lời đúng vì việc thí điểm do một nhóm nhỏ được chọn đảm nhận, không gắn cứng với đội kiểm thử độc lập. "The vendor contractor to write the initial scripts" sai vì nhà cung cấp viết kịch bản thì tổ chức không tự học được cách dùng phù hợp với mình.

Đáp án đúng: "Scribe". Người ghi chép (scribe, recorder) trong rà soát hình thức có nhiệm vụ ghi lại mọi lỗi, vấn đề và điểm còn mở được nêu trong cuộc họp rà soát, cùng các đề xuất cải tiến, làm cơ sở cho bước làm lại và theo dõi. "Moderator" dẫn dắt quy trình và chủ trì cuộc họp; việc điều hành đòi hỏi tập trung nên ghi chép được giao cho người khác. "Reviewers" là những người rà soát, tìm lỗi và nêu vấn đề trong cuộc họp; họ cung cấp nội dung chứ không phải người lưu lại. "Author" là tác giả tài liệu, người nhận danh sách lỗi để sửa trong bước làm lại; ở một số rà soát ít hình thức tác giả có thể tự ghi, nhưng vai trò được giao chính thức việc này là người ghi chép.

Đáp án đúng: "i,ii,iii are true and iv is false". Theo ISTQB, kiểm thử thành phần (component testing) là cấp kiểm thử các phần nhỏ nhất có thể kiểm thử riêng, còn được gọi là kiểm thử đơn vị (unit testing), kiểm thử mô-đun (module testing) và kiểm thử chương trình (program testing), nên mục i, ii, iii đúng. Kiểm thử thành phần hệ thống (system component testing) không phải tên gọi chuẩn; nó lẫn lộn giữa cấp thành phần và cấp hệ thống, vốn là hai cấp kiểm thử khác nhau, nên mục iv sai. "i,ii,iii,iv are false" sai vì loại cả ba tên đồng nghĩa đã được thừa nhận. "i,ii,iv are true and iii is false" sai vì loại kiểm thử mô-đun, một tên gọi chuẩn, lại nhận mục iv không chuẩn. "All of them are true" sai vì đưa cả mục iv vào.

Đáp án đúng: "Even though the numbers you look at appear better, to achieve these numbers, people are doing other aspects of their work much less well.". Rối loạn đo lường (measurement dysfunction) là hiện tượng khi một chỉ số được dùng để đánh giá con người, họ điều chỉnh hành vi cho chỉ số đẹp lên, nhưng cái giá là những phần việc không được đo bị làm kém đi; ví dụ chấm điểm người kiểm thử theo số lỗi tìm được thì họ báo nhiều lỗi vặt và né lỗi khó, con số tốt hơn mà chất lượng thực giảm. "We don't know how to measure a variable (our measurement is dysfunctional)" mô tả việc không biết cách đo, đó là vấn đề độ tin cậy của phép đo chứ không phải sự biến dạng hành vi do bị đo. "You are measuring the wrong thing and thus reaching the wrong conclusions." là lỗi chọn sai đại lượng dẫn tới kết luận sai, không nói tới việc con người làm tệ đi phần việc khác. "All of the others" sai vì hai mô tả kia không phải bản chất của rối loạn đo lường.

Đáp án đúng: "Syntax testing". Chuẩn BS 7925-2 về kiểm thử thành phần chia kỹ thuật thành hai nhóm: hộp trắng (white box) dựa trên cấu trúc mã như statement testing, branch testing, data flow testing, và hộp đen (black box) dựa trên đặc tả như phân hoạch tương đương, giá trị biên, syntax testing. Syntax testing thiết kế ca kiểm thử từ cú pháp đầu vào đã đặc tả hình thức, không nhìn vào mã, nên không thuộc hộp trắng. Cần nói thẳng: "Random testing" cũng được BS 7925-2 xếp vào nhóm hộp đen, vì nó sinh đầu vào ngẫu nhiên theo phân bố của miền đầu vào chứ không dựa vào cấu trúc mã, nên xét chặt thì câu hỏi có hai phát biểu đúng; vì đề chỉ cho chọn một, đáp án chốt là syntax testing theo cách hiểu phổ biến nhất, còn random testing là phương án nhiễu rất sát. "Data Flow testing." là kỹ thuật hộp trắng, thiết kế ca theo cặp định nghĩa và sử dụng biến. "Statement testing" là kỹ thuật hộp trắng cơ bản nhất, nhắm cho mọi câu lệnh được thực thi.