Câu hỏi nào có liên quan đến phân tích thiết kế?

Giai đoạn thu thập yêu cầu (Requirements Elicitation) là một trong những giai đoạn quan trọng nhất của quy trình phát triển phần mềm. Mục tiêu chính của giai đoạn này là thu thập, phân tích và đặc tả các yêu cầu của người dùng và các bên liên quan. Kết quả của giai đoạn này thường là một tài liệu đặc tả yêu cầu phần mềm (Software Requirements Specification - SRS), mô tả chi tiết những gì phần mềm cần phải làm.

* Đáp án 2: Tài liệu đặc tả yêu cầu phần mềm là đáp án chính xác nhất. Tài liệu này chứa đựng tất cả các yêu cầu đã được thu thập, phân tích và đặc tả, làm cơ sở cho các giai đoạn thiết kế, phát triển và kiểm thử sau này.
* Đáp án 1: Bảng ước tính chi phí dự án là kết quả của giai đoạn ước tính, thường được thực hiện sau khi đã có thông tin về phạm vi và yêu cầu của dự án.
* Đáp án 3: Lược đồ ngữ cảnh là một phần của tài liệu đặc tả yêu cầu, nhưng không phải là kết quả duy nhất.
* Đáp án 4: Lược đồ Use case và các lược đồ khác cũng là một phần của tài liệu đặc tả yêu cầu, nhưng không phải là kết quả duy nhất và đầy đủ.

Trong phân tích yêu cầu, chúng ta sử dụng nhiều sơ đồ khác nhau để mô tả và hiểu rõ các yêu cầu của hệ thống. Các sơ đồ Use Case, Activity Diagram và State Transition Diagram đều đóng vai trò quan trọng trong việc mô hình hóa hành vi và chức năng của hệ thống.

- Use Case Diagram: Mô tả các tương tác giữa người dùng (actor) và hệ thống, giúp xác định các chức năng chính mà hệ thống cần cung cấp.
- Activity Diagram: Mô tả luồng hoạt động của một quy trình nghiệp vụ hoặc một chức năng của hệ thống.
- State Transition Diagram: Mô tả các trạng thái của một đối tượng và các chuyển đổi giữa các trạng thái đó.

Entity Relationship Diagram (ERD) được sử dụng chủ yếu trong thiết kế cơ sở dữ liệu, để mô hình hóa các thực thể và mối quan hệ giữa chúng, chứ không phải là một phần thiết yếu trong phân tích yêu cầu. Mặc dù ERD có thể cung cấp thông tin hữu ích về dữ liệu mà hệ thống sẽ xử lý, nhưng nó không phải là một công cụ bắt buộc để thu thập và phân tích yêu cầu.

Vì vậy, sơ đồ Entity Relationship Diagram (ERD) không phải là sơ đồ cần thiết trong phân tích yêu cầu, trong khi các sơ đồ Use Case, Activity Diagram, và State Transition Diagram đều được sử dụng phổ biến để mô hình hóa và hiểu các yêu cầu của hệ thống.

Câu hỏi yêu cầu xác định loại hình đặc tả *không* tồn tại.

* Đặc tả hình thức (A): Sử dụng ngôn ngữ hình thức, cú pháp và ngữ nghĩa chặt chẽ để mô tả hệ thống. Ví dụ: sử dụng logic vị từ, đại số quan hệ.
* Đặc tả phi hình thức (B): Sử dụng ngôn ngữ tự nhiên hoặc sơ đồ để mô tả hệ thống. Dễ hiểu nhưng có thể mơ hồ.
* Đặc tả toán học (C): Tương tự như đặc tả hình thức, sử dụng các khái niệm và ký hiệu toán học để mô tả hệ thống một cách chính xác.
* Đặc tả hỗn hợp (D): Kết hợp cả đặc tả hình thức và phi hình thức. Ví dụ: sử dụng UML kết hợp với OCL (Object Constraint Language).

Như vậy, tất cả các loại hình A, B, C và D đều có tồn tại. Vì câu hỏi yêu cầu tìm loại hình *không* tồn tại, nên có vẻ như có một sự nhầm lẫn trong câu hỏi hoặc các phương án trả lời. Tuy nhiên, nếu phải chọn một đáp án *ít phổ biến nhất* hoặc *ít được công nhận nhất* so với các loại còn lại, thì D. Đặc tả hỗn hợp có thể được xem là đáp án phù hợp nhất, vì nó chỉ đơn giản là một sự kết hợp của hai loại đặc tả cơ bản hơn (hình thức và phi hình thức), chứ không phải là một loại đặc tả hoàn toàn độc lập với các đặc điểm riêng biệt được công nhận rộng rãi.

Tuy nhiên, cần lưu ý rằng theo nghĩa chặt chẽ, không có đáp án nào hoàn toàn "sai" trong các lựa chọn đã cho, vì đặc tả hỗn hợp cũng được sử dụng trong thực tế.

Kỹ sư phần mềm chịu trách nhiệm chính trong việc thiết kế hệ thống nghiệp vụ. Các công việc như phân tích phạm vi nghiệp vụ, kế hoạch sản phẩm và kế hoạch chiến lược thông tin thường thuộc về các vai trò khác như chuyên gia phân tích nghiệp vụ, quản lý sản phẩm hoặc kiến trúc sư giải pháp.

* Thiết kế hệ thống nghiệp vụ: Bao gồm việc xác định các thành phần phần mềm cần thiết, kiến trúc hệ thống, các giao diện, và cách dữ liệu sẽ được xử lý và lưu trữ để hỗ trợ các quy trình nghiệp vụ.

Câu hỏi đề cập đến "cấu trúc thông tin biểu diễn tổ chức nội của". Trong ngữ cảnh này, đáp án D, "Những dữ liệu khác nhau và những mục điều khiển", là phù hợp nhất. Một tổ chức, về mặt thông tin, có thể được biểu diễn bằng các dữ liệu khác nhau mà nó quản lý (ví dụ: thông tin nhân viên, thông tin sản phẩm, thông tin khách hàng) và các mục điều khiển (ví dụ: các quy trình, các chính sách, các quy định). Các lựa chọn khác không phản ánh đầy đủ hoặc chính xác cách thức tổ chức nội bộ được biểu diễn thông qua cấu trúc thông tin.