Mô hình phát triển ứng dụng nhanh

Trong phân tích yêu cầu, hai loại phân tách vấn đề phổ biến là phân tích từ trên xuống (top-down) và phân tích từ dưới lên (bottom-up).

* Top-down (Từ trên xuống): Tiếp cận bằng cách chia một vấn đề lớn, phức tạp thành các phần nhỏ hơn, dễ quản lý hơn. Bắt đầu từ mục tiêu tổng quát, sau đó chia nhỏ thành các chức năng con, các quy trình, và cuối cùng là các tác vụ cụ thể.
* Bottom-up (Từ dưới lên): Bắt đầu bằng việc xác định các thành phần cơ bản, sau đó kết hợp chúng lại để tạo thành một hệ thống hoàn chỉnh. Cách tiếp cận này thường được sử dụng khi đã có sẵn các thành phần hoặc khi vấn đề chưa được xác định rõ ràng.

Các lựa chọn khác không phải là các phương pháp phân tách vấn đề tiêu chuẩn trong phân tích yêu cầu.

Do đó, đáp án đúng là A.

Câu hỏi yêu cầu tìm ra mục không phải là đặc trưng chung trong các phương pháp thiết kế. Các phương pháp thiết kế thường bao gồm quản lý cấu hình, sử dụng các ký hiệu để mô tả các thành phần chức năng và các nguyên tắc để đánh giá chất lượng thiết kế. Heuristic tinh chế là một kỹ thuật cụ thể được sử dụng trong một số phương pháp thiết kế, nhưng nó không phải là một đặc trưng chung cho tất cả các phương pháp thiết kế. Do đó, đáp án D là đáp án phù hợp nhất.

Mục đích của việc tham chiếu chéo các yêu cầu (thường được thể hiện dưới dạng ma trận truy vết yêu cầu - Requirements 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 xác định và ghi lại đều được xem xét và đáp ứng đầy đủ trong quá trình thiết kế. Điều này giúp xác minh rằng không có yêu cầu nào bị bỏ sót và thiết kế cuối cùng thực sự đáp ứng nhu cầu của người dùng và các bên liên quan. Các lựa chọn khác không phải là mục đích chính của việc tham chiếu chéo yêu cầu.

Phân tích câu hỏi:
Câu hỏi này liên quan đến việc chuyển đổi hoặc ánh xạ giao dịch (transaction) thành một thiết kế kiến trúc đầy đủ trong phát triển phần mềm. Chúng ta cần xác định yếu tố bổ sung nào là cần thiết nhất để đạt được mục tiêu này.

Đánh giá các phương án:
* A. Sơ đồ quan hệ - thực thể (Entity-Relationship Diagram - ERD): ERD mô tả cấu trúc dữ liệu, các thực thể và mối quan hệ giữa chúng. Đây là một phần quan trọng của thiết kế kiến trúc, đặc biệt khi liên quan đến dữ liệu.
* B. Từ điển dữ liệu (Data Dictionary): Từ điển dữ liệu chứa thông tin chi tiết về các yếu tố dữ liệu, chẳng hạn như kiểu dữ liệu, kích thước, ràng buộc. Nó bổ sung cho ERD và cung cấp cái nhìn sâu sắc hơn về dữ liệu.
* C. Mô tả việc xử lý cho mỗi module: Điều này đề cập đến logic nghiệp vụ và cách các module tương tác với nhau để xử lý các giao dịch. Đây là yếu tố quan trọng để hoàn thiện thiết kế kiến trúc, đặc biệt là phần xử lý.
* D. Những Test-case cho mỗi module: Test-case dùng để kiểm tra chức năng của module, không trực tiếp tham gia vào việc tạo ra thiết kế kiến trúc.

Giải thích đáp án đúng:
Trong các lựa chọn trên, "Mô tả việc xử lý cho mỗi module" là yếu tố cần thiết nhất để hoàn thiện thiết kế kiến trúc từ các giao dịch. Việc ánh xạ giao dịch không chỉ liên quan đến dữ liệu mà còn cả logic xử lý. ERD và từ điển dữ liệu tập trung vào khía cạnh dữ liệu, còn test-case chỉ là công cụ kiểm tra. Mô tả việc xử lý cho mỗi module sẽ giúp xác định cách các giao dịch được thực hiện, luồng dữ liệu và sự tương tác giữa các thành phần, từ đó tạo ra một thiết kế kiến trúc đầy đủ.

Mô hình hình ảnh hệ thống (C) tập trung vào việc thể hiện giao diện người dùng một cách trực quan, bao gồm cả "look and feel" (diện mạo và cảm giác) và các thông tin hỗ trợ khác giúp người dùng tương tác dễ dàng hơn với hệ thống. Các mô hình khác không trực tiếp đề cập đến khía cạnh giao diện người dùng và trải nghiệm người dùng một cách cụ thể như mô hình hình ảnh hệ thống.