Câu hỏi: SWR302 - Phần 13: Tái sử dụng yêu cầu và nối sang kế hoạch, thiết kế, kiểm thử

Đá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: "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: "Junior business analyst". Requirements pattern (mẫu yêu cầu) là khuôn có sẵn cho một loại yêu cầu hay gặp, chỉ ra những thông tin cần có, cách diễn đạt và ví dụ, giúp viết yêu cầu đầy đủ, nhất quán ở bước đặc tả. Người hưởng lợi nhiều nhất là người phân tích nghiệp vụ còn ít kinh nghiệm, vì mẫu bù cho phần kinh nghiệm họ chưa có và nhắc họ những chi tiết dễ bỏ sót. "Project manager" chủ yếu lập kế hoạch và điều phối dự án, không trực tiếp viết yêu cầu nên ít dùng tới mẫu. "Deployment engineer" làm việc ở khâu triển khai, nhận yêu cầu đã hoàn chỉnh chứ không soạn chúng. "Marketing director" đóng góp góc nhìn thị trường và mục tiêu kinh doanh, có thể là nguồn yêu cầu nhưng không phải người dùng mẫu để đặc tả.

Đáp án đúng: "Baselined requirements". Đường cơ sở yêu cầu (requirements baseline) là tập yêu cầu đã được rà soát, thống nhất và cam kết cho một bản phát hành; nó trở thành trung tâm dẫn dắt mọi hoạt động khác: kế hoạch dự án ước lượng dựa trên nó, thiết kế và mã hiện thực nó, kiểm thử kiểm chứng theo nó, và mọi thay đổi đi qua kiểm soát thay đổi so với nó. Phương án "Project plans" sai vì kế hoạch được lập dựa trên yêu cầu, tức là sản phẩm phía sau. Phương án "Designs and code" sai vì thiết kế và mã được tạo ra để đáp ứng yêu cầu, không phải thứ dẫn dắt yêu cầu. Phương án "Tests" sai vì ca kiểm thử được suy ra từ yêu cầu để kiểm tra hệ thống có đúng yêu cầu hay không, nên cũng phụ thuộc vào yêu cầu đã chốt.

Đá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: "Have developers review requirements". Yêu cầu là đầu vào trực tiếp của thiết kế và viết mã, nên thực hành gắn với khâu này là để nhà phát triển rà soát yêu cầu sớm: họ phát hiện chỗ mơ hồ, không khả thi về kỹ thuật hay thiếu thông tin trước khi bắt tay thiết kế, tránh hiểu sai rồi phải làm lại. Một số bộ ôn tập xếp câu này khác, nhưng các phương án kia rõ ràng thuộc khâu khác. Phương án "Base estimates on product size" thuộc lập kế hoạch dự án, dùng kích thước yêu cầu để ước lượng công sức. Phương án "Use requirement priorities to drive iterations" cũng thuộc lập kế hoạch, chọn yêu cầu nào làm ở vòng lặp nào. Phương án "Start test design early" và phương án "Trace requirements to tests" thuộc kiểm thử: thiết kế ca kiểm thử sớm từ yêu cầu và truy vết mỗi yêu cầu tới ca kiểm thử của nó.

Đá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: "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: "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: "Project Planning Process". Yêu cầu phần mềm thực ra là đầu vào cho gần như mọi quy trình được liệt kê, nên đây là câu dễ gây tranh cãi; tuy vậy khi chỉ chọn một, lập kế hoạch dự án là đáp án hợp lý nhất vì đó là quy trình đầu tiên dùng tới yêu cầu: từ yêu cầu mới ước lượng được quy mô, công sức, chi phí và lịch, rồi các quy trình khác mới chạy theo kế hoạch đó. "Project Tracking and Control Process" cũng dùng yêu cầu, nhưng ở bước sau, để đo tiến độ so với phạm vi đã lập kế hoạch. "Change Control Process" cũng dùng yêu cầu, nhưng chỉ khi đã có đường cơ sở yêu cầu và phát sinh đề xuất thay đổi. "Acceptance & System Testing Process" cũng dùng yêu cầu để thiết kế ca kiểm thử, nhưng đó là giai đoạn muộn. "Construction Process" cũng dùng yêu cầu khi thiết kế và viết mã, nhưng diễn ra sau khi kế hoạch đã có. Vì vậy các quy trình này không sai về bản chất, chỉ không phải nơi yêu cầu đóng vai trò đầu vào trước tiên.