Ôn tập cuối kỳ SWR302 Fall 2024

Tuyên bố trên đề cập đến tính chất chất lượng nào của hệ thống? Hệ thống cần phải có khả năng nhập bất kỳ cấu trúc hóa học hợp lệ nào từ công cụ ChemDraw phiên bản 13.0 hoặc trước đó và MarvinSketch phiên bản 5.0 hoặc trước đó. Điều này cho thấy hệ thống cần phải tương tác và tích hợp được với các công cụ khác nhau, không phụ thuộc vào phiên bản. Khả năng này được gọi là tính tương tác (Interoperability). Tính tương tác là khả năng của hệ thống để tương tác và tích hợp được với các hệ thống, ứng dụng hoặc thiết bị khác, đảm bảo rằng dữ liệu được trao đổi và sử dụng một cách chính xác và hiệu quả.

Một mô hình dữ liệu là một hình ảnh trực quan thể hiện các đối tượng dữ liệu và các tập hợp dữ liệu mà hệ thống sẽ xử lý và mối quan hệ giữa chúng. Nó giúp xác định cấu trúc dữ liệu và cách dữ liệu được liên kết với nhau trong hệ thống. Mô hình dữ liệu thường được sử dụng trong thiết kế cơ sở dữ liệu và phát triển phần mềm để đảm bảo dữ liệu được tổ chức và quản lý một cách hiệu quả.

Một bảng điều khiển (dashboard) là một công cụ quan trọng trong việc theo dõi và phân tích dữ liệu. Nó cung cấp một cái nhìn tổng quan, đa chiều về tình hình của một tổ chức hoặc quy trình. Bảng điều khiển thường bao gồm nhiều biểu đồ, đồ thị và các hình thức khác nhau để thể hiện dữ liệu. Điều này giúp người dùng dễ dàng hiểu và phân tích dữ liệu, từ đó đưa ra quyết định sáng suốt. Bảng điều khiển có thể được sử dụng trên màn hình hoặc được in ra dưới dạng báo cáo.

Một mô hình phân tích được sử dụng để thể hiện các trạng thái khác nhau mà một hệ thống hoặc một đối tượng trong hệ thống có thể tồn tại, cũng như các chuyển đổi được phép giữa các trạng thái. Mô hình này giúp cho việc phân tích và thiết kế hệ thống trở nên dễ dàng hơn. Nó cho phép các nhà phát triển và nhà thiết kế xem xét các trạng thái khác nhau mà hệ thống có thể tồn tại và các chuyển đổi được phép giữa các trạng thái.

Các yêu cầu phải được thể hiện theo các dạng sau: Đầu tiên, chúng ta cần đảm bảo rằng yêu cầu có thể thực hiện được (Feasible). Điều này có nghĩa là yêu cầu phải có thể đạt được trong thực tế, không chỉ là một mục tiêu lý thuyết. Thứ hai, yêu cầu phải chính xác (Correct). Điều này có nghĩa là yêu cầu phải rõ ràng, không mơ hồ và không gây hiểu lầm. Cuối cùng, yêu cầu phải có thể kiểm tra được (Verifiable). Điều này có nghĩa là yêu cầu phải có thể đo lường được, có thể xác minh được và có thể đánh giá được. Tóm lại, yêu cầu phải được thể hiện một cách rõ ràng, chính xác và đo lường được để đảm bảo rằng chúng ta có thể đạt được mục tiêu một cách hiệu quả.

Mỗi lựa chọn đều đóng vai trò quan trọng trong mô tả chi tiết của Software Requirements Specification (SRS). Tuy nhiên, 'System feature' không phải là một phần quan trọng trong mô tả tổng quan của SRS. SRS thường bao gồm các phần như 'Product perspective' (khái quát về sản phẩm), 'User classes and characteristics' (khái quát về người dùng), 'Operating environment' (khái quát về môi trường hoạt động), 'Design and implementation constraints' (khái quát về hạn chế trong thiết kế và triển khai), 'Assumptions and dependencies' (khái quát về giả định và phụ thuộc). 'System feature' thường được sử dụng để mô tả các tính năng cụ thể của hệ thống, chứ không phải là mô tả tổng quan.

Khi viết SRS, việc ghi nhãn các yêu cầu là rất quan trọng. Điều này cho phép chúng ta tham khảo các yêu cầu cụ thể trong yêu cầu thay đổi, lịch sử sửa đổi, liên kết, hoặc ma trận theo dõi yêu cầu. Ngoài ra, việc ghi nhãn yêu cầu cũng giúp chúng ta tái sử dụng các yêu cầu trong nhiều dự án khác nhau. Điều này giúp tiết kiệm thời gian và công sức trong quá trình phát triển phần mềm. Hơn nữa, việc ghi nhãn yêu cầu cũng giúp cải thiện sự hợp tác giữa các thành viên trong nhóm khi họ thảo luận về các yêu cầu.

Sự khác biệt giữa Use Cases và User Stories là gì? Use Cases là một tài liệu kinh doanh xác định yêu cầu phần mềm hoặc tính năng ứng dụng. Trong khi đó, User Stories là một tài liệu kiểm thử xác định các bước để xác minh và xác thực rằng yêu cầu phần mềm hoặc tính năng ứng dụng tồn tại. Use Cases thường được sử dụng để mô tả các yêu cầu kinh doanh và chức năng của ứng dụng, trong khi User Stories được sử dụng để mô tả các yêu cầu kiểm thử và xác thực. Ví dụ, một Use Case có thể mô tả cách một người dùng có thể tạo một tài khoản mới, trong khi một User Story có thể mô tả các bước để kiểm thử tính năng tạo tài khoản mới.

Các Use Case mô tả các tương tác giữa hệ thống và các thực thể bên ngoài. Điều này có nghĩa là chúng mô tả các hành động mà người dùng thực hiện với hệ thống và hệ thống phản hồi lại như thế nào. Điều này giúp cho các nhà phát triển hiểu rõ hơn về yêu cầu của người dùng và có thể xây dựng được hệ thống đáp ứng được nhu cầu của họ. Ngoài ra, các Use Case cũng giúp cho việc xác định các yêu cầu chức năng của hệ thống trở nên dễ dàng hơn. Vì vậy, các Use Case là công cụ quan trọng trong việc thu thập và xác định các yêu cầu của hệ thống.

Để viết được câu hỏi điều tra hiệu quả, cần bắt đầu bằng việc hỏi những câu hỏi mở (open-ended questions) ngay từ đầu. Những câu hỏi này cho phép người tham gia trả lời một cách tự do và chi tiết, giúp thu thập được thông tin đầy đủ và có ý nghĩa. Câu hỏi mở thường bắt đầu bằng từ như 'Bạn nghĩ gì về', 'Bạn cảm thấy thế nào khi', 'Bạn nghĩ rằng', v.v. Điều này giúp người tham gia có thể thể hiện quan điểm và ý kiến của mình một cách tự nhiên và chân thực. Ngoài ra, câu hỏi mở cũng giúp nhà điều tra có thể thu thập được thông tin sâu sắc và chi tiết hơn, giúp cho việc phân tích và tổng hợp dữ liệu trở nên dễ dàng hơn.

Xác định các bên liên quan (stakeholders) là một bước quan trọng khi thu thập yêu cầu cho một hệ thống phần mềm. Điều này giúp bạn hiểu rõ ai đang tham gia vào dự án, ai sẽ bị ảnh hưởng bởi kết quả dự án và ai có thể ảnh hưởng đến kết quả dự án. Việc xác định các bên liên quan giúp bạn có thể thu thập yêu cầu chính xác và đầy đủ, từ đó đảm bảo rằng hệ thống phần mềm đáp ứng được nhu cầu và kỳ vọng của các bên liên quan. Ngoài ra, việc xác định các bên liên quan cũng giúp bạn có thể dự đoán và giải quyết các vấn đề có thể xảy ra trong quá trình thực hiện dự án.

Dưới đây là câu trả lời cho câu hỏi: 'Đâu là điều không được bao gồm trong danh sách Yêu cầu về Hóa đơn Phần mềm?'. Các lựa chọn có sẵn là: - 'Chờ BAs nói ngôn ngữ của bạn.' - 'Chờ BAs tìm hiểu về doanh nghiệp và mục tiêu của bạn.' - 'Thông báo ngay các thay đổi về yêu cầu.' - 'Nhận giải thích về thực hành và sản phẩm yêu cầu.' - 'Thay đổi yêu cầu của bạn.' - 'Chờ một môi trường tôn trọng lẫn nhau.' Câu trả lời đúng là: 'Thay đổi yêu cầu của bạn.' Vì trong danh sách Yêu cầu về Hóa đơn Phần mềm, không có yêu cầu nào nói về việc thay đổi yêu cầu của người dùng. Các yêu cầu khác đều liên quan đến việc giao tiếp, học hỏi và tôn trọng lẫn nhau.

Trong quá trình phát triển yêu cầu, có năm bước cơ bản: thu thập thông tin (elicitation), thiết kế (design), phân tích (analysis), xác minh (validation) và tạo tài liệu (documentation). Tuy nhiên, tạo tài liệu (documentation) không phải là một bước phát triển yêu cầu riêng biệt mà là một phần của quá trình phát triển yêu cầu. Nó là một bước sau khi đã thu thập thông tin, thiết kế và phân tích yêu cầu. Vì vậy, trong số các lựa chọn trên, tạo tài liệu (documentation) không phải là một bước phát triển yêu cầu độc lập.

Một mô hình phân tích thể hiện luồng quy trình di chuyển từ một hoạt động sang hoạt động khác được gọi là sơ đồ luồng quy trình (Process Flow Diagram) hoặc sơ đồ hoạt động (Activity Diagram). Tuy nhiên, trong các lựa chọn đã cho, sơ đồ luồng quy trình không có, nhưng có một lựa chọn khác có thể phù hợp, đó là sơ đồ hoạt động (Activity Diagram). Sơ đồ hoạt động thể hiện các hoạt động và các luồng quy trình giữa chúng, giúp phân tích và mô hình hóa quy trình kinh doanh.

Khi hệ thống phần mềm của khách hàng đã phát triển và họ muốn hệ thống này có thể xử lý 10 lần số lượng giao dịch hơn trước, thì điều này liên quan đến chất lượng đặc trưng của hệ thống phần mềm. Chất lượng đặc trưng này là khả năng mở rộng của hệ thống phần mềm. Khả năng mở rộng của hệ thống phần mềm là khả năng của hệ thống phần mềm để tăng cường khả năng xử lý của nó mà không làm giảm hiệu suất của hệ thống. Trong trường hợp này, hệ thống phần mềm không thể xử lý 10 lần số lượng giao dịch hơn trước do các quá trình monolithic và logic được kết nối chặt chẽ. Do đó, chất lượng đặc trưng mà hệ thống phần mềm này đang thiếu là khả năng mở rộng.

Trong mô hình Use Case, các yếu tố bắt buộc phải có là những gì? Các Use Case phải có tên (Name), điều kiện trước (Pre-condition) và điều kiện sau (Post-condition). Điều kiện trước và sau giúp xác định rõ ràng các yêu cầu của Use Case, trong khi tên của Use Case giúp phân biệt nó với các Use Case khác. Các tác nhân (Actors) cũng là một phần quan trọng của Use Case, nhưng chúng không phải là bắt buộc. Vì vậy, đáp án đúng là ["Pre-condition", "Name", "Post-condition"].

Các hoạt động sau đây thuộc về các hoạt động cốt lõi của quản lý yêu cầu. Quản lý yêu cầu là một phần quan trọng trong chu kỳ phát triển sản phẩm, giúp đảm bảo rằng các yêu cầu của khách hàng được hiểu và thực hiện chính xác. Các hoạt động cốt lõi của quản lý yêu cầu bao gồm kiểm soát phiên bản, kiểm soát thay đổi, theo dõi trạng thái yêu cầu và theo dõi yêu cầu. Kiểm soát phiên bản giúp quản lý các phiên bản của yêu cầu, kiểm soát thay đổi giúp đảm bảo rằng các thay đổi được thực hiện một cách có hệ thống, theo dõi trạng thái yêu cầu giúp theo dõi tiến độ của yêu cầu và theo dõi yêu cầu giúp đảm bảo rằng các yêu cầu được thực hiện chính xác.

Mục tiêu quan trọng của việc viết yêu cầu là đảm bảo rằng bất kỳ ai đọc yêu cầu đều có cùng hiểu biết về yêu cầu đó. Điều này có nghĩa là yêu cầu phải rõ ràng, dễ hiểu và không gây nhầm lẫn. Mục tiêu này giúp tránh những hiểu lầm không cần thiết và đảm bảo rằng tất cả các bên liên quan đều có cùng mục tiêu. Ví dụ, nếu yêu cầu không rõ ràng, một người đọc có thể hiểu nó một cách khác với người đọc khác, dẫn đến việc thực hiện sai yêu cầu. Vì vậy, việc viết yêu cầu một cách rõ ràng và dễ hiểu là rất quan trọng để đảm bảo rằng tất cả các bên liên quan đều có cùng hiểu biết về yêu cầu.

Câu hỏi này yêu cầu bạn xác định lựa chọn không liên quan đến giải pháp đóng gói. Giải pháp đóng gói là một phần của quá trình phát triển phần mềm, nơi bạn có thể mua hoặc sử dụng một phần hoặc toàn bộ giải pháp đã được thiết kế sẵn. Trong khi đó, việc xây dựng hệ thống bằng cách sử dụng nhân viên của mình là một phần của quá trình phát triển phần mềm truyền thống, nơi bạn xây dựng hệ thống từ đầu mà không sử dụng giải pháp đóng gói. Vì vậy, câu trả lời đúng là "Bạn xây dựng hệ thống bằng cách sử dụng nhân viên của mình".

Một thách thức phổ biến mà cả các dự án cải tiến và thay thế thường gặp phải là sự phản đối từ người dùng. Người dùng đã quen thuộc với cách hệ thống hoạt động hiện tại có thể không thích những thay đổi mà họ sắp phải đối mặt. Điều này có thể dẫn đến sự kháng cự và khó khăn trong việc chấp nhận những thay đổi mới. Người dùng có thể cảm thấy không thoải mái với những thay đổi này, đặc biệt là nếu họ đã quen thuộc với cách hệ thống hoạt động trước đây. Vì vậy, việc hiểu được nhu cầu và mong muốn của người dùng là rất quan trọng trong việc đảm bảo rằng những thay đổi mới được chấp nhận và sử dụng một cách hiệu quả.