Theo quan điểm của quản lý dự án thì thiết kế phần mềm được chia thành hai giai đoạn nào?

Tính chất cần có của dữ liệu trong phân tích yêu cầu

Lời giải:

Đáp án đúng: A

Tính chất cần có của dữ liệu trong phân tích yêu cầu là tính có định hướng thời gian. Điều này có nghĩa là dữ liệu cần được thu thập và phân tích theo một trình tự thời gian nhất định để có thể hiểu được sự thay đổi và phát triển của hệ thống theo thời gian. Các phương án khác không phải là tính chất cần thiết của dữ liệu trong phân tích yêu cầu.
- Giá trị pháp lý: Dữ liệu không nhất thiết phải có giá trị pháp lý.
- Tính mô tả trừu tượng: Dữ liệu cần cụ thể để phân tích hiệu quả.
- Mô tả bằng toán học: Không phải lúc nào cũng cần thiết hoặc khả thi.

Câu 21:

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

Lời giải:

Đáp án đúng: B

Phân tích thiết kế tập trung vào việc chuyển đổi các yêu cầu và đặc tả của hệ thống thành một bản thiết kế chi tiết, sẵn sàng cho việc triển khai. Câu hỏi "Làm thế nào chuyển thiết kế dữ liệu logic sang thiết kế dữ liệu vật lý?" trực tiếp liên quan đến việc này, vì nó đề cập đến việc cụ thể hóa cấu trúc dữ liệu để phù hợp với một hệ quản trị cơ sở dữ liệu cụ thể.

Các lựa chọn khác không trực tiếp liên quan đến phân tích thiết kế:

- "Thời gian hoàn thành dự án có đủ không?" liên quan đến quản lý dự án và ước tính thời gian.
- "Các xử lý nào được tiến hành và các thông tin chi tiết liên quan?" liên quan đến phân tích yêu cầu hoặc đặc tả hệ thống.
- "Đâu là phạm vi của hệ thống phần mềm?" liên quan đến định nghĩa phạm vi dự án trong giai đoạn khởi tạo dự án.

Câu 22:

Kết quả của giai đoạn thu thập yêu cầu là:

Lời giải:

Đáp án đúng: B

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 đủ.

Câu 23:

Sơ đồ nào sau đây không cần thiết trong phân tích yêu cầu?

Lời giải:

Đáp án đúng: D

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 24:

Loại hình đặc tả nào không có?

Lời giải:

Đáp án đúng: C

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ế.

Câu 25:

Thành phần nào của kỹ thuật tiến trình nghiệp vụ là trách nhiệm của kỹ sư phần mềm

Lời giải: