Khái niệm phần mềm?

Mô hình xoắn ốc (Spiral Model) là một mô hình phát triển phần mềm dựa trên việc lặp đi lặp lại các giai đoạn (lập kế hoạch, phân tích rủi ro, thực hiện và đánh giá). Đặc điểm nổi bật của mô hình này là khả năng quản lý và kiểm soát rủi ro ở từng giai đoạn phát triển.

- Phương án 1: "Nhanh chóng xác định được yêu cầu" không phải là đặc điểm chính của mô hình xoắn ốc. Mặc dù yêu cầu cần được xác định, nhưng mô hình này tập trung hơn vào quản lý rủi ro.
- Phương án 2: "Tách biệt giữa các pha, tiến hành tuần tự" mô tả mô hình thác nước (Waterfall), không phải mô hình xoắn ốc.
- Phương án 3: "Có thể kiểm soát rủi ro ở từng mức tiến hóa" là đặc điểm cốt lõi của mô hình xoắn ốc. Mô hình này đặc biệt phù hợp với các dự án có nhiều rủi ro tiềm ẩn.
- Phương án 4: "Sử dụng bộ case trong quá trình phát triển" không phải là đặc điểm riêng biệt của mô hình xoắn ốc. Case study có thể được sử dụng trong nhiều mô hình phát triển khác nhau.

Vậy đáp án đúng là phương án 3.

Câu hỏi này kiểm tra kiến thức về các mức độ mô tả yêu cầu trong quá trình phát triển phần mềm.

* Phân tích yêu cầu: Là quá trình tìm hiểu, làm rõ các yêu cầu của người dùng và các bên liên quan.
* Xác định yêu cầu: Là quá trình thu thập và ghi nhận lại các yêu cầu sau khi đã phân tích.
* Yêu cầu chức năng: Mô tả những chức năng mà hệ thống cần thực hiện (ví dụ: tính năng đăng nhập, tìm kiếm, thanh toán).
* Yêu cầu phi chức năng: Mô tả các đặc tính chất lượng của hệ thống (ví dụ: hiệu năng, bảo mật, khả năng mở rộng).
* Đặc tả yêu cầu: Là tài liệu mô tả chi tiết và chính thức về các yêu cầu, thường được sử dụng làm cơ sở cho việc thiết kế và phát triển.

Trong các phương án:

* Phương án 1 (Phân tích yêu cầu, xác định yêu cầu): Chỉ đề cập đến các giai đoạn trong quá trình thu thập yêu cầu, không phải là các mức mô tả yêu cầu.
* Phương án 2 (Yêu cầu chức năng, yêu cầu phi chức năng): Mô tả hai loại yêu cầu chính trong đặc tả yêu cầu.
* Phương án 3 (Xác định yêu cầu, đặc tả yêu cầu): Tương tự phương án 1, chỉ đề cập đến các giai đoạn.
* Phương án 4 (Xác định yêu cầu, phân tích yêu cầu): Tương tự phương án 1, chỉ đề cập đến các giai đoạn.

Vậy, phương án đúng nhất là phương án 2, vì nó mô tả hai loại yêu cầu chính được sử dụng để mô tả yêu cầu ở các mức khác nhau.

Một thiết kế phần mềm tốt cần đảm bảo tính module hóa cao, nghĩa là các mô-đun nên độc lập và có sự kết nối lỏng lẻo (low coupling) để dễ dàng bảo trì, nâng cấp và tái sử dụng. Đồng thời, thiết kế phải đáp ứng đầy đủ các yêu cầu đã được xác định trong quá trình phân tích. Việc bao gồm các trường hợp thử nghiệm và cung cấp một bức tranh hoàn chỉnh về phần mềm là quan trọng, nhưng không phải là yếu tố cốt lõi đặc trưng cho một thiết kế tốt như việc đáp ứng yêu cầu và tính module hóa.

* Đáp án 1 không đúng vì một thiết kế tốt nên có kết nối lỏng lẻo giữa các mô-đun.
* Đáp án 2 đúng vì một thiết kế phần mềm tốt phải hiện thực hóa tất cả các yêu cầu đã được xác định ở giai đoạn phân tích.
* Đáp án 3 không đúng vì việc bao gồm các trường hợp thử nghiệm là một phần của quá trình kiểm thử, không phải là đặc trưng của thiết kế.
* Đáp án 4 không đúng vì mặc dù việc cung cấp một bức tranh hoàn chỉnh là hữu ích, nhưng không phải là đặc trưng chính của một thiết kế tốt.

Kỹ thuật Facilitated Workshops (Hội thảo có người điều phối) là kỹ thuật thu thập yêu cầu mà ở đó, các bên liên quan cùng tham gia vào một buổi hội thảo có người điều phối để thảo luận và thống nhất về các yêu cầu của dự án. Sự thành công của buổi hội thảo phụ thuộc vào việc đạt được sự nhất trí của số đông các bên liên quan. Các kỹ thuật khác như Prototype (Xây dựng mẫu thử), Observation (Quan sát) và Questionnaires & Surveys (Bảng hỏi và khảo sát) không trực tiếp đòi hỏi sự nhất trí của số đông như Facilitated Workshops.

* Prototype: Tập trung vào việc xây dựng và thử nghiệm một phiên bản mẫu của sản phẩm để thu thập phản hồi.
* Observation: Quan sát người dùng thực hiện công việc của họ để hiểu nhu cầu.
* Questionnaires & Surveys: Thu thập thông tin từ một lượng lớn người dùng thông qua bảng hỏi, nhưng không nhất thiết cần sự đồng thuận.

Đặc tả yêu cầu là quá trình mô tả chi tiết các chức năng, tính năng và ràng buộc của một hệ thống phần mềm. Các phương pháp đặc tả yêu cầu thường bao gồm:

* Đặc tả thao tác: Mô tả các thao tác mà người dùng hoặc hệ thống có thể thực hiện.
* Đặc tả mô hình: Sử dụng các mô hình như UML để mô tả cấu trúc và hành vi của hệ thống.
* Đặc tả bằng sơ đồ: Sử dụng các sơ đồ như sơ đồ luồng dữ liệu, sơ đồ trạng thái để trực quan hóa các yêu cầu.

Trong khi đó, đặc tả thuật toán liên quan đến việc mô tả chi tiết các bước thực hiện để giải quyết một vấn đề cụ thể trong hệ thống. Thuật toán là một phần của thiết kế chi tiết, diễn giải cách một chức năng sẽ được thực hiện chứ không phải là một phần của việc thu thập và mô tả các yêu cầu ở mức độ cao.

Vì vậy, đặc tả thuật toán không thuộc về đặc tả yêu cầu.