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

Dưới đây là câu hỏi về việc sử dụng danh sách kiểm tra lỗi trong quy trình phát triển phần mềm. Câu hỏi yêu cầu người tham gia đánh giá tính chính xác của tuyên bố: 'Phát triển danh sách kiểm tra lỗi và sử dụng nó cho tất cả các loại tài liệu yêu cầu'. Để trả lời câu hỏi này, chúng ta cần xem xét vai trò của danh sách kiểm tra lỗi trong quy trình phát triển phần mềm. Danh sách kiểm tra lỗi là một công cụ quan trọng giúp đảm bảo chất lượng của sản phẩm phần mềm. Nó giúp phát hiện và sửa lỗi trong quá trình phát triển, từ đó cải thiện chất lượng của sản phẩm. Việc sử dụng danh sách kiểm tra lỗi cho tất cả các loại tài liệu yêu cầu là một thực hành tốt, giúp đảm bảo rằng tất cả các yêu cầu được kiểm tra và xác minh một cách đầy đủ. Điều này giúp giảm thiểu khả năng xảy ra lỗi và cải thiện chất lượng của sản phẩm phần mềm. Vì vậy, tuyên bố trên là đúng.

Các dự án nhỏ thường dành khoảng 5 đến 7 phần trăm tổng công sức của họ cho công việc yêu cầu. Điều này có nghĩa là khi bạn đang thực hiện một dự án nhỏ, bạn nên dành một phần nhỏ của thời gian để xác định yêu cầu của dự án. Yêu cầu là bước quan trọng trong dự án vì nó giúp bạn hiểu rõ hơn về dự án và đảm bảo rằng dự án được thực hiện đúng mục tiêu. Việc dành thời gian cho công việc yêu cầu sẽ giúp bạn tránh được những sai lầm và tiết kiệm thời gian trong quá trình thực hiện dự án. Tuy nhiên, cần lưu ý rằng việc dành thời gian cho công việc yêu cầu không phải là việc lãng phí thời gian, mà là một phần quan trọng của quá trình thực hiện dự án.

Khái niệm yêu cầu hệ thống (System Requirement) được định nghĩa là mô tả về một tính chất hoặc đặc điểm mà hệ thống phải đáp ứng hoặc một ràng buộc mà hệ thống phải tuân thủ. Điều này bao gồm các thuộc tính như hiệu suất, độ tin cậy, khả năng tương thích và các yêu cầu khác không liên quan trực tiếp đến chức năng của hệ thống. Yêu cầu hệ thống thường được xác định dựa trên yêu cầu của người dùng, yêu cầu của quy trình kinh doanh và các ràng buộc về kỹ thuật. Mục tiêu của yêu cầu hệ thống là đảm bảo rằng hệ thống được phát triển đáp ứng được các yêu cầu và nhu cầu của người dùng, đồng thời đảm bảo rằng hệ thống có thể vận hành một cách ổn định và hiệu quả.

Khi thực hiện hoạt động thu thập thông tin (elicitation activities), bạn cần chuẩn bị kỹ lưỡng để đảm bảo quá trình thu thập thông tin diễn ra hiệu quả. Một trong những cách giúp bạn khi thực hiện hoạt động này là giáo dục người tham gia (stakeholders). Điều này có nghĩa là bạn cần giúp họ hiểu rõ mục đích và yêu cầu của hoạt động thu thập thông tin, từ đó họ sẽ có thể cung cấp thông tin chính xác và đầy đủ. Giáo dục người tham gia cũng giúp xây dựng sự tin tưởng và hợp tác giữa bạn và họ, tạo điều kiện thuận lợi cho quá trình thu thập thông tin. Ngoài ra, giáo dục người tham gia còn giúp bạn tránh được những hiểu lầm và sai sót trong quá trình thu thập thông tin.

Theo Karl Wiegers và Joy Beatty trong cuốn sách Software Requirements 3rd Edition, quá trình ưu tiên yêu cầu là một quá trình liên tục và thay đổi. Quá trình này liên tục được cập nhật và điều chỉnh dựa trên các yếu tố như mức độ ưu tiên, mức độ phức tạp và mức độ ảnh hưởng đến dự án. Quá trình ưu tiên yêu cầu không phải là một quá trình cố định và tĩnh, mà là một quá trình liên tục và thay đổi để đảm bảo rằng các yêu cầu được ưu tiên đúng và phù hợp với mục tiêu của dự án.

Khái niệm được gọi là bản mẫu ngang tương tự như bản mẫu ngang prototype là cấu trúc điều hướng. Bản mẫu ngang là một bản mẫu cơ bản được sử dụng để mô tả và thiết kế giao diện người dùng của một ứng dụng hoặc trang web. Nó thường bao gồm các yếu tố như menu, nút, biểu tượng và các thành phần khác. Cấu trúc điều hướng là một phần quan trọng của bản mẫu ngang, giúp người dùng dễ dàng tìm kiếm và truy cập các tính năng và nội dung trên ứng dụng hoặc trang web.

Mục tiêu kinh doanh trong phần mô tả mục tiêu kinh doanh của tài liệu Vision và Scope là mô tả lý do và bối cảnh cho sản phẩm mới hoặc thay đổi đối với sản phẩm hiện có. Nó mô tả lịch sử hoặc tình huống dẫn đến quyết định xây dựng sản phẩm này. Mục tiêu kinh doanh không chỉ mô tả cơ hội kinh doanh mà còn mô tả lợi ích chính mà hệ thống mới sẽ mang lại cho các nhà tài trợ, người mua và người dùng. Nó không chỉ tóm tắt lợi ích kinh doanh quan trọng mà sản phẩm sẽ mang lại mà còn mô tả nó một cách cụ thể và đo lường được.

Khách hàng có trách nhiệm đảm bảo rằng họ dành đủ thời gian để cung cấp và làm rõ các yêu cầu. Điều này bao gồm việc cung cấp thông tin cụ thể và chính xác về các yêu cầu. Họ cũng cần đảm bảo rằng các yêu cầu được rõ ràng và dễ hiểu. Ngoài ra, khách hàng cần phải xác định các tiêu chí chấp nhận để đánh giá sản phẩm hoặc dịch vụ cuối cùng. Điều này giúp đảm bảo rằng sản phẩm hoặc dịch vụ đáp ứng được nhu cầu và kỳ vọng của khách hàng.

Một số người có thể nhầm lẫn giữa các khái niệm "kỹ năng" và "kiến thức" khi nói về vai trò của một nhà phân tích kinh doanh. Tuy nhiên, "kiến thức" và "kỹ năng" là hai khái niệm khác nhau. "Kỹ năng" đề cập đến khả năng thực hiện một công việc hoặc nhiệm vụ cụ thể, trong khi "kiến thức" đề cập đến kiến thức và thông tin cần thiết để thực hiện công việc đó. "Thái độ làm việc" (working styles) không phải là một khía cạnh quan trọng trong vai trò của một nhà phân tích kinh doanh. Vì vậy, trong các lựa chọn trên, "thái độ làm việc" không phải là một trong những nhu cầu cơ bản cần có để tạo ra một nhà phân tích kinh doanh hiệu quả.

Câu hỏi này yêu cầu người đọc đánh giá tính đúng sai của một tuyên bố. Tuyên bố cho rằng các dự án khác nhau sẽ đòi hỏi cùng một bộ các đặc tính chất lượng. Điều này không phải lúc nào cũng đúng vì các dự án khác nhau có thể có các yêu cầu và mục tiêu khác nhau. Vì vậy, câu trả lời đúng là 'False'.

Để xác định ưu tiên theo yêu cầu Prioritization dựa trên giá trị, chi phí và rủi ro, chúng ta cần xem xét các yếu tố giá trị, chi phí và rủi ro. Giá trị (value %) đại diện cho lợi ích hoặc giá trị mà dự án mang lại. Chi phí (cost %) bao gồm các chi phí liên quan đến dự án, chẳng hạn như chi phí nhân công, vật liệu, thiết bị, v.v. Rủi ro (risk %) là khả năng xảy ra sự cố hoặc thảm họa trong dự án. Để tính toán ưu tiên, chúng ta cần so sánh giá trị với chi phí và rủi ro. Formula đúng là Priority = value % / (cost % + risk %). Điều này cho phép chúng ta xác định dự án nào có giá trị cao nhất và cần ưu tiên đầu tư.

Câu hỏi này yêu cầu bạn đánh giá tính chính xác của tuyên bố rằng tất cả các dự án công nghệ thông tin (IT) của doanh nghiệp đều chọn thay thế tất cả các quy trình kinh doanh thủ công bằng việc triển khai tự động hóa quy trình kinh doanh. Tuy nhiên, thực tế có thể không phải vậy. Một số dự án IT chỉ chọn tự động hóa một số quy trình kinh doanh nhất định, hoặc có thể không tự động hóa gì cả. Vì vậy, câu trả lời đúng là 'False'.

Theo Halle và Goldberg (2010) trong cuốn sách Software Requirements, phiên bản thứ ba, có sáu loại quy tắc kinh doanh cơ bản. Chúng bao gồm: Constraints (khuyến cáo), Action Enablers (cơ chế thực hiện hành động), Inferences (xác minh), Computations (tính toán), References (chỉ dẫn) và Facts (thông tin). Tuy nhiên, References không phải là một loại quy tắc kinh doanh cơ bản. Thay vào đó, nó chỉ là một loại thông tin liên quan đến quy tắc kinh doanh.

Sách yêu cầu phần mềm (Software Requirements Specification - SRS) là một tài liệu quan trọng trong quá trình phát triển phần mềm. Nó cung cấp thông tin chi tiết về yêu cầu của khách hàng, chức năng của sản phẩm và các ràng buộc kỹ thuật. Dưới đây là một số đối tượng chính sử dụng SRS: - Nhóm phát triển phần mềm: Họ cần biết những gì cần xây dựng. - Quản lý dự án: Họ dựa vào yêu cầu để ước tính lịch trình, nỗ lực và tài nguyên. - Khách hàng, bộ phận tiếp thị và bán hàng: Họ cần biết sản phẩm nào sẽ được giao. - Nhóm bảo trì và hỗ trợ: Họ sử dụng nó để hiểu chức năng của từng phần của sản phẩm. Tuy nhiên, đối tượng không chính thức sử dụng SRS là đối thủ cạnh tranh muốn đánh cắp dữ liệu của hệ thống phần mềm. Họ không có quyền truy cập vào SRS và không cần thông tin chi tiết về sản phẩm.

Khi muốn giải quyết yêu cầu mâu thuẫn giữa các lớp người dùng, cách tiếp cận phù hợp nhất là dựa trên mục tiêu kinh doanh. Điều này có nghĩa là việc đưa ra quyết định sẽ được hướng dẫn bởi các mục tiêu kinh doanh, giúp đảm bảo rằng các quyết định được đưa ra là có lợi cho doanh nghiệp. Cách tiếp cận này giúp giải quyết mâu thuẫn giữa các lớp người dùng bằng cách đặt mục tiêu kinh doanh lên trên hết, giúp đảm bảo rằng các quyết định được đưa ra là có lợi cho doanh nghiệp.

Trong mô hình Actor, một Actor được định nghĩa là một thực thể có thể là một người dùng, một hệ thống hoặc một phần của hệ thống. Điều này cho phép mô hình hóa các hệ thống phức tạp bằng cách chia chúng thành các Actor độc lập. Vì vậy, câu trả lời đúng là 1. A-subsystem or external system cannot be modelled as an actor.

Trong dự án hệ thống thời gian thực và hệ thống nhúng, nhà phân tích nên phân tích các yêu cầu hệ thống riêng lẻ thành nhiều yêu cầu được suy ra. Loại yêu cầu nào sẽ phân bổ cho người?

Kỹ năng không phải là cơ bản của một nhà phân tích kinh doanh là kỹ năng giao tiếp. Nhà phân tích kinh doanh cần có kỹ năng giao tiếp để truyền đạt ý tưởng và thông tin một cách hiệu quả. Tuy nhiên, kỹ năng giao tiếp không phải là một trong những kỹ năng cơ bản của một nhà phân tích kinh doanh. Các kỹ năng cơ bản khác bao gồm kỹ năng lập kế hoạch, kỹ năng phân tích, kỹ năng phỏng vấn và kỹ năng lắng nghe.

Các công cụ phát triển yêu cầu bao gồm các công cụ mô hình hóa, thu thập thông tin và tạo bản mẫu. Trong số các lựa chọn trên, công cụ kiểm soát phiên bản không thuộc nhóm công cụ phát triển yêu cầu. Công cụ kiểm soát phiên bản được sử dụng để theo dõi và quản lý các phiên bản của mã nguồn, thường được sử dụng trong quy trình phát triển phần mềm. Trong khi đó, công cụ mô hình hóa giúp tạo ra các mô hình của hệ thống, công cụ thu thập thông tin giúp xác định yêu cầu của hệ thống và công cụ tạo bản mẫu giúp tạo ra các bản mẫu của hệ thống. Vì vậy, công cụ kiểm soát phiên bản không thuộc nhóm công cụ phát triển yêu cầu.

Các hoạt động thu thập yêu cầu người dùng và nhóm tập trung nên được thực hiện ở giai đoạn nào?