Tất cả câu hỏi

Câu hỏi này yêu cầu bạn xác định thông tin không liên quan đến dự án được giao ngoài (outsourced projects). Các lựa chọn bao gồm: - Nó tận dụng kỹ năng phát triển có sẵn trong nội bộ. - Đó là khó khăn hơn để có được ý kiến của nhà phát triển về yêu cầu và để chuyển lại phản hồi của người dùng về phần mềm đã được giao cho nhà phát triển. - Cần có định nghĩa hợp đồng chính thức về yêu cầu, điều này có thể dẫn đến tranh chấp nếu sự khác biệt trong việc giải thích được phát hiện muộn trong dự án. Câu trả lời đúng là: Nó tận dụng kỹ năng phát triển có sẵn trong nội bộ. Vì dự án được giao ngoài thường không tận dụng kỹ năng phát triển có sẵn trong nội bộ mà thay vào đó là thuê ngoài để thực hiện.

Trong phát triển agile, các câu chuyện người dùng (user stories) và các câu chuyện lớn (epics) là hai khái niệm quan trọng. Câu chuyện người dùng là những tuyên bố ngắn gọn và rõ ràng về nhu cầu của người dùng, giúp khởi đầu cho các cuộc thảo luận chi tiết. Các câu chuyện lớn, hoặc epics, là những câu chuyện người dùng quá lớn để được triển khai trong một chu kỳ phát triển (iteration) duy nhất. Vì vậy, chúng thường được chia nhỏ thành nhiều câu chuyện người dùng nhỏ hơn để dễ dàng triển khai.

Trong quá trình phát triển phần mềm, yêu cầu (requirements) đóng vai trò quan trọng. Chúng không chỉ ảnh hưởng đến kế hoạch dự án mà còn tác động trực tiếp đến quá trình thiết kế và viết mã nguồn. Yêu cầu cũng giúp xác định các hoạt động kiểm tra và thử nghiệm, đảm bảo rằng sản phẩm cuối cùng đáp ứng được các tiêu chuẩn và yêu cầu đã được đặt ra. Vì vậy, yêu cầu (requirements) là nền tảng quan trọng để xây dựng một sản phẩm phần mềm chất lượng cao.

Các yếu tố sau đây có thể ngăn cản việc tái sử dụng yêu cầu. Yêu cầu được viết bằng ngôn ngữ tự nhiên có thể chứa các sự không rõ ràng, thiếu thông tin và giả định ẩn. Điều này có thể dẫn đến việc khó khăn trong việc hiểu và thực hiện yêu cầu. Vì vậy, việc tái sử dụng yêu cầu sẽ gặp khó khăn khi yêu cầu không được viết rõ ràng và chính xác.

Một bản mẫu phần mềm là một bản dựng thử nghiệm của một sản phẩm mới. Nó thường được tạo ra để kiểm tra ý tưởng và xác định các yêu cầu của sản phẩm. Bản mẫu phần mềm có thể được xem là một phần thực hiện của sản phẩm mới, vì nó chỉ bao gồm một số tính năng hoặc chức năng của sản phẩm. Nó cũng có thể được xem là một bản dựng khả thi của sản phẩm mới, vì nó thể hiện một cách khả thi để triển khai sản phẩm. Ngoài ra, bản mẫu phần mềm cũng có thể được xem là một bản dựng sơ bộ của sản phẩm mới, vì nó thường được tạo ra trước khi sản phẩm được hoàn thiện. Tuy nhiên, bản mẫu phần mềm không phải lúc nào cũng là bản dựng hoàn chỉnh của sản phẩm mới.

Câu hỏi này yêu cầu bạn xác định hoạt động không liên quan đến xác minh yêu cầu. Trong quá trình phát triển yêu cầu, có bốn thành phần chính: xác định yêu cầu, phân tích yêu cầu, xác minh yêu cầu và xác định yêu cầu. Xác minh yêu cầu là một hoạt động quan trọng để đảm bảo yêu cầu có tất cả các tính chất mong muốn của yêu cầu chất lượng cao. Nó cũng đảm bảo rằng yêu cầu đã được viết đúng và có liên quan đến mục tiêu kinh doanh. Tuy nhiên, câu trả lời không chính xác trong lựa chọn này là "Itis the fourth component of requirements development." vì nó chỉ là một phần của quá trình phát triển yêu cầu, không phải là hoạt động xác minh yêu cầu.

Đáp án đúng: "Must, Should, Could, Won’t". MoSCoW là kỹ thuật xếp ưu tiên yêu cầu thuộc hoạt động phân tích, chia yêu cầu vào bốn nhóm: Must (bắt buộc có, thiếu thì đợt phát hành thất bại), Should (quan trọng nhưng có thể hoãn), Could (có thì tốt, làm nếu còn nguồn lực) và Won’t (lần này không làm, có thể xét ở đợt sau); hai chữ o viết thường chỉ để đọc thành tiếng. "Must, Should, Could, Will" sai ở chữ cuối: nhóm W là những thứ sẽ không làm trong đợt này, không phải sẽ làm. "Must, Should, Can, Will" sai cả hai chữ cuối, Can không phải tên nhóm và Will lại đảo nghĩa nhóm loại trừ. "Must, Shall, Could, Won’t" sai vì nhóm thứ hai là Should, thể hiện mức ưu tiên thấp hơn Must, còn shall trong văn bản yêu cầu thường mang nghĩa bắt buộc như Must.

Đáp án đúng: "investing excessive effort in prototypes". Bản mẫu có giá trị nhất khi tập trung vào phần chưa chắc chắn, rủi ro cao hoặc phức tạp; làm bản mẫu cho toàn bộ giải pháp nghĩa là dồn công sức vào cả những phần đã rõ, tốn thời gian và chi phí lẽ ra dành cho phát triển thật, đó là rủi ro đầu tư quá mức vào bản mẫu. Phương án "distraction by details" là rủi ro khi người xem sa vào chi tiết giao diện như màu sắc, phông chữ thay vì đánh giá yêu cầu, không phải hệ quả của làm cả hệ thống. Phương án "pressure to release the prototype" là rủi ro khi bản mẫu trông quá giống sản phẩm thật. Phương án "unrealistic performance expectations" là rủi ro khi người dùng thấy bản mẫu chạy nhanh (do không có xử lý thật) rồi kỳ vọng sản phẩm cũng vậy.

Một mockup là một mô hình giả lập của hệ thống, thường được sử dụng trong quá trình thiết kế và phát triển phần mềm. Nó cho phép người dùng tương tác với hệ thống và đánh giá các tính năng và giao diện người dùng. Trong các lựa chọn trên, câu trả lời sai là 'nó đi sâu vào tất cả các lớp kiến trúc hoặc vào chi tiết chức năng'. Điều này không đúng vì mockup thường chỉ tập trung vào giao diện người dùng và các hành vi cơ bản của hệ thống, chứ không phải tất cả các lớp kiến trúc và chi tiết chức năng.

Throwaway prototype là một loại prototype được xây dựng để đáp ứng nhu cầu cụ thể trong một giai đoạn nhất định. Nó thường được sử dụng khi đội ngũ phát triển gặp phải sự không chắc chắn, mơ hồ, không đầy đủ hoặc không rõ ràng trong yêu cầu. Mục đích chính của một prototype như vậy là để trả lời các câu hỏi, giải quyết sự không chắc chắn và cải thiện chất lượng yêu cầu. Khi xây dựng một prototype như vậy, đội ngũ phát triển không cần phải tuân thủ các kỹ thuật xây dựng phần mềm nghiêm ngặt. Điều này cho phép họ tập trung vào việc giải quyết các vấn đề quan trọng và tạo ra một sản phẩm có thể đáp ứng nhu cầu của khách hàng. Tuy nhiên, nó không phải là một sản phẩm cuối cùng và có thể được loại bỏ sau khi hoàn thành.

Tính chất chất lượng bên ngoài (external quality attribute) là những đặc điểm của một hệ thống hoặc phần mềm mà người dùng quan tâm. Các lựa chọn bên dưới đều là tính chất chất lượng bên ngoài, ngoại trừ một trong số đó. Tính sẵn có (Availability) là khả năng của hệ thống để sẵn sàng sử dụng khi người dùng cần. Tính toàn vẹn (Integrity) là khả năng của hệ thống để đảm bảo dữ liệu được cập nhật và lưu trữ chính xác. Tính an toàn (Safety) là khả năng của hệ thống để đảm bảo an toàn cho người dùng và hệ thống. Tính tái sử dụng (Reusability) là khả năng của hệ thống để được sử dụng lại trong nhiều dự án khác nhau. Tuy nhiên, tính tái sử dụng không phải là một tính chất chất lượng bên ngoài, mà là một tính chất chất lượng bên trong (internal quality attribute).

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

Đáp án đúng: "Data model". Mô hình dữ liệu (data model), thường vẽ bằng sơ đồ thực thể quan hệ hoặc sơ đồ lớp, là biểu diễn trực quan các đối tượng dữ liệu, các tập hợp dữ liệu mà hệ thống xử lý và quan hệ giữa chúng; đây là phần cốt lõi khi phân tích yêu cầu dữ liệu. "Use case diagram" biểu diễn tác nhân và các use case, tức tương tác của người dùng với hệ thống, không phải dữ liệu. "Data dictionary" là kho định nghĩa chi tiết từng phần tử dữ liệu như kiểu, độ dài, miền giá trị, thường ở dạng bảng chữ, bổ sung cho mô hình dữ liệu nhưng không phải hình vẽ thể hiện quan hệ. "Reports" là đầu ra mà hệ thống tạo cho người dùng, được đặc tả riêng về nội dung và bố cục, không mô tả cấu trúc dữ liệu bên trong.

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

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âu tuyên bố trên cho rằng tất cả màn hình trong hệ thống phải tải nhanh chóng. Để đánh giá tính chính xác và khả thi của tuyên bố này, chúng ta cần xem xét từng khía cạnh. Tính chính xác (correct) của tuyên bố này có thể được đánh giá là đúng vì nó xác định rõ yêu cầu về tốc độ tải màn hình. Tuy nhiên, tính khả thi (feasible) của tuyên bố này có thể không hoàn toàn đúng vì tốc độ tải màn hình phụ thuộc vào nhiều yếu tố như cấu hình hệ thống, dung lượng dữ liệu, và hiệu suất phần cứng. Vì vậy, tuyên bố này có thể được đánh giá là 'Correct và Feasible' nhưng với một số hạn chế.

Đáp án đúng gồm ba ý: "Feasible", "Correct" và "Verifiable". Một phát biểu yêu cầu tốt cần các đặc tính như đầy đủ, đúng, khả thi, cần thiết, có ưu tiên, không mơ hồ và kiểm chứng được. Feasible (khả thi) nghĩa là có thể cài đặt được với công nghệ, ngân sách và thời gian của dự án. Correct (đúng) nghĩa là phát biểu mô tả chính xác điều bên liên quan cần, được xác nhận bởi nguồn của yêu cầu. Verifiable (kiểm chứng được) nghĩa là có thể thiết kế kiểm thử hay phép đo để biết yêu cầu đã được đáp ứng hay chưa. "Flexible" sai vì linh hoạt không phải đặc tính của một phát biểu yêu cầu tốt; một yêu cầu được viết lỏng để dễ diễn giải theo nhiều cách thực chất là mơ hồ, đi ngược tiêu chí không mơ hồ và kiểm chứng được. Linh hoạt có thể là một thuộc tính chất lượng của hệ thống, nhưng đó là nội dung yêu cầu chứ không phải phẩm chất của câu chữ.

Đáp án đúng: "System feature". Trong mẫu đặc tả yêu cầu phần mềm (Software Requirements Specification), mục Overall description (mô tả tổng quan) gồm các tiểu mục mô tả bối cảnh sản phẩm: "Product perspective" (vị trí sản phẩm trong hệ thống lớn hơn), "User classes and characteristics" (các nhóm người dùng và đặc điểm của họ), "Operating environment" (môi trường vận hành), "Design and implementation constraints" (ràng buộc thiết kế và cài đặt) và "Assumptions and dependencies" (giả định và phụ thuộc). Cả năm mục này đều đúng là thành phần của Overall description nên không được chọn. Còn System features là một chương riêng của mẫu SRS, nơi mô tả từng tính năng kèm yêu cầu chức năng chi tiết, không thuộc phần mô tả tổng quan, vì vậy đây là câu trả lời cho câu hỏi dạng NOT.

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.