Mô hình phát triển dựa vào thành phần:

Kỹ thuật FAST (Facilitated Application Specification Techniques) là một phương pháp tiếp cận hợp tác, trong đó nhà phát triển và khách hàng cùng nhau làm việc để xác định và phát triển một tập hợp các yêu cầu ban đầu cho phần mềm. Mục tiêu là tạo ra một sự hiểu biết chung về phạm vi và mục tiêu của dự án, giảm thiểu rủi ro hiểu lầm và đảm bảo rằng phần mềm cuối cùng đáp ứng được nhu cầu của khách hàng.

Phương án 1 không chính xác vì FAST không chỉ tập trung vào việc xây dựng nguyên mẫu nhanh chóng, mà còn đảm bảo rằng nguyên mẫu đó dựa trên các yêu cầu đã được thống nhất.

Phương án 2 không chính xác vì học công việc lẫn nhau là một phần của quy trình, nhưng không phải là mục tiêu chính.

Phương án 4 không chính xác vì FAST tập trung vào các yêu cầu ban đầu, chứ không phải là đặc tả kỹ thuật chi tiết.

Phương án 3 chính xác vì nó mô tả đúng mục đích của FAST, đó là sự hợp tác giữa nhà phát triển và khách hàng để xác định các yêu cầu ban đầu.

Mô hình thiết kế tập trung vào việc hiện thực hóa các yêu cầu của dự án, bao gồm kiến trúc, dữ liệu và giao diện. Phạm vi dự án là một yếu tố xác định giới hạn của dự án, nhưng không trực tiếp liên quan đến việc thiết kế các thành phần bên trong dự án. Do đó, mô hình thiết kế không trực tiếp quan tâm đến phạm vi dự án, mà quan tâm đến việc làm thế nào để đáp ứng các yêu cầu trong phạm vi đó.

* Kiến trúc: Mô hình thiết kế phải tuân thủ kiến trúc tổng thể của hệ thống.
* Dữ liệu: Mô hình thiết kế phải xác định cấu trúc và cách thức lưu trữ dữ liệu.
* Giao diện: Mô hình thiết kế phải định nghĩa giao diện người dùng và các giao diện khác.
* Phạm vi dự án: Phạm vi dự án xác định những gì cần được xây dựng, nhưng mô hình thiết kế tập trung vào cách xây dựng những thứ đó.

Câu hỏi yêu cầu xác định mục *không* phải là đặc trưng chung trong các phương pháp thiết kế.

* Quản lý cấu hình: Là một đặc trưng quan trọng trong quá trình thiết kế, đảm bảo kiểm soát và theo dõi các thay đổi của thiết kế.
* Ký hiệu thành phần chức năng: Các phương pháp thiết kế thường sử dụng các ký hiệu để mô tả và biểu diễn các thành phần chức năng của hệ thống.
* Nguyên tắc đánh giá chất lượng: Các phương pháp thiết kế luôn đi kèm với các nguyên tắc để đánh giá và đảm bảo chất lượng của thiết kế.
* Heuristic tinh chế: Heuristic là các quy tắc hoặc phương pháp dựa trên kinh nghiệm được sử dụng để cải thiện hoặc tinh chỉnh thiết kế. Tuy nhiên, không phải phương pháp thiết kế nào cũng sử dụng heuristic tinh chế một cách rõ ràng và có hệ thống. Do đó, đây là mục *không* phải là đặc trưng chung.

Vậy đáp án đúng là "Heuristic tinh chế".

Trong kiến trúc phần mềm, có một số loại mô hình chính được sử dụng để mô tả và thiết kế hệ thống. Các mô hình này bao gồm:

* Mô hình dữ liệu: Mô tả cấu trúc và mối quan hệ của dữ liệu được sử dụng bởi hệ thống. Nó bao gồm các thực thể, thuộc tính và các ràng buộc dữ liệu.
* Mô hình xử lý: Mô tả các chức năng và quy trình xử lý dữ liệu trong hệ thống. Nó tập trung vào luồng dữ liệu và các hoạt động chuyển đổi dữ liệu.
* Mô hình cấu trúc: Mô tả cấu trúc tĩnh của hệ thống, bao gồm các thành phần, kết nối giữa các thành phần và các giao diện.
* Mô hình động: Mô tả hành vi động của hệ thống, bao gồm các trạng thái, chuyển đổi trạng thái và các sự kiện.

Như vậy, các loại mô hình dữ liệu, động, và cấu trúc đều cần thiết và được sử dụng rộng rãi trong kiến trúc phần mềm. Mô hình "Xử lý" có thể được coi là một phần của mô hình động hoặc được thể hiện thông qua các mô hình khác (ví dụ: mô hình use case, sơ đồ hoạt động).

Vì vậy, không có loại mô hình "Xử lý" tách biệt như một thành phần cơ bản trong kiến trúc phần mềm theo cách mà các mô hình dữ liệu, động và cấu trúc được định nghĩa rõ ràng.

Mục đích chính của việc tham chiếu chéo các yêu cầu (thường được thực hiện thông qua ma trận truy vết yêu cầu - Requirement Traceability Matrix) trong tài liệu thiết kế là để đảm bảo rằng tất cả các yêu cầu đã được thu thập và phân tích đều được xem xét và đáp ứng đầy đủ trong quá trình thiết kế. Việc này giúp xác minh rằng không có yêu cầu nào bị bỏ sót hoặc hiểu sai, từ đó giảm thiểu rủi ro phát sinh lỗi và đảm bảo chất lượng của sản phẩm cuối cùng.

Phương án 1 không đúng vì tham chiếu chéo yêu cầu không trực tiếp liên quan đến việc theo dõi năng suất của nhóm thiết kế. Mặc dù nó có thể cung cấp thông tin về tiến độ công việc, nhưng mục tiêu chính không phải là đánh giá năng suất.

Phương án 3 không đúng vì tham chiếu chéo yêu cầu không chỉ ra chi phí liên quan đến mỗi yêu cầu. Chi phí thường được quản lý thông qua các công cụ và quy trình quản lý dự án khác.

Phương án 4 không đúng vì tham chiếu chéo yêu cầu không cung cấp thông tin về tên của nhà thiết kế chịu trách nhiệm cho mỗi yêu cầu. Thông tin này có thể được quản lý riêng.

Vì vậy, phương án 2 là chính xác nhất.