Câu hỏi: SWR302 - Phần 17: Kiểm soát thay đổi và truy vết yêu cầu

Mô hình theo dõi yêu cầu (Requirements traceability matrix) là một công cụ quan trọng trong quy trình phát triển phần mềm. Nó đại diện cho các liên kết giữa các yêu cầu và các thành phần khác của hệ thống. Mô hình này giúp đảm bảo rằng các yêu cầu được thực hiện một cách chính xác và đầy đủ. Nó cũng giúp xác định các vấn đề và lỗi trong quá trình phát triển phần mềm. Vì vậy, câu trả lời đúng là: 'Requirements traceability matrix Represents the links between requirements and other system elements'.

Các nguồn thông tin liên kết theo dấu vết có thể bao gồm nhiều loại khác nhau. Ví dụ, nếu nguồn liên kết là yêu cầu hệ thống, thì đích liên kết có thể là yêu cầu chức năng. Nếu nguồn liên kết là yêu cầu người dùng, thì đích liên kết cũng có thể là yêu cầu chức năng. Tương tự, nếu nguồn liên kết là thành phần thiết kế, thì đích liên kết có thể là mã nguồn. Do đó, tất cả các câu trả lời trên đều có thể đúng tùy thuộc vào ngữ cảnh cụ thể.

Câu hỏi này yêu cầu học viên phân biệt giữa các câu nói khác nhau về thay đổi yêu cầu. Câu không đúng về thay đổi yêu cầu là 'Requirements changes do not affect requirement effort.' (Thay đổi yêu cầu không ảnh hưởng đến nỗ lực yêu cầu). Điều này không đúng vì thay đổi yêu cầu thường ảnh hưởng đến thời gian, chi phí và nguồn lực của dự án. Học viên cần hiểu được tầm quan trọng của việc quản lý thay đổi yêu cầu và cách nó ảnh hưởng đến dự án.

Để xử lý một yêu cầu thay đổi, có bốn nhiệm vụ cần được thực hiện. Trước hết, chúng ta phải đánh giá yêu cầu thay đổi (evaluate change request). Tiếp theo, chúng ta phải đưa ra quyết định thay đổi (make change decision). Sau đó, chúng ta phải thực hiện thay đổi (implement the change). Cuối cùng, chúng ta phải kiểm tra lại thay đổi (verify the change) để đảm bảo rằng nó đã được thực hiện đúng cách và không có lỗi nào.

Giải pháp yêu cầu theo dõi (requirements tracing) là một công cụ quan trọng trong quản lý dự án. Nó cho phép tạo liên kết giữa các nhiệm vụ trong kế hoạch dự án và tiến độ phát triển. Điều này giúp tăng cường theo dõi dự án, đảm bảo rằng các nhiệm vụ được thực hiện đúng theo kế hoạch. Ngoài ra, yêu cầu theo dõi còn giúp xác định các yêu cầu chưa được đáp ứng và cần phải bổ sung. Điều này giúp giảm thiểu chi phí phát triển và tăng cường chất lượng sản phẩm cuối cùng.

Đáp án đúng: "To track the relationship between requirements and other project artifacts". Ma trận truy vết yêu cầu (Requirements Traceability Matrix) là công cụ của quản lý yêu cầu, ghi các liên kết xuôi và ngược giữa từng yêu cầu với nguồn gốc của nó (mục tiêu nghiệp vụ, use case) và với các sản phẩm phía sau như thiết kế, mã, ca kiểm thử. Nhờ đó nhóm phân tích được tác động khi có thay đổi và kiểm tra không yêu cầu nào bị bỏ sót. Phương án "To trace the origin of software bugs" sai vì truy nguyên lỗi là việc của gỡ lỗi và quản lý lỗi, dù RTM có thể giúp tìm yêu cầu liên quan. Phương án "To document project milestones" sai vì mốc tiến độ thuộc kế hoạch dự án. Phương án "To manage project budgets" sai vì ngân sách thuộc quản lý dự án, không phải mục đích của ma trận truy vết.

Trong quá trình phát triển yêu cầu, việc thiết lập cơ chế quản lý thay đổi yêu cầu là rất quan trọng. Điều này giúp dự án có thể thích nghi với nhu cầu thay đổi trong quá trình thực hiện, đồng thời vẫn duy trì được sự kiểm soát. Khi yêu cầu thay đổi, cơ chế này sẽ giúp dự án cập nhật và điều chỉnh các yêu cầu phù hợp, tránh gây ra sự cố hoặc lãng phí tài nguyên. Ngoài ra, cơ chế này cũng giúp dự án duy trì được sự minh bạch và rõ ràng trong quá trình thay đổi, đảm bảo rằng tất cả các bên liên quan đều hiểu rõ về các thay đổi và tác động của chúng.

Câu trả lời đúng là "Agile processes harness change for the customer's competitive advantage.". Lý do là vì Agile là một phương pháp quản lý dự án linh hoạt, cho phép thay đổi và thích nghi với nhu cầu của khách hàng. Khi khách hàng thay đổi nhu cầu, Agile cho phép đội ngũ phát triển nhanh chóng thích nghi và đáp ứng nhu cầu đó. Điều này giúp cho khách hàng có được lợi thế cạnh tranh và tăng cường khả năng thành công của dự án. Các câu trả lời còn lại đều liên quan đến quản lý thay đổi trong Agile, vì vậy chúng không phải là câu trả lời đúng.

Một Requirements Change Control Board (RCCB) đóng vai trò quan trọng trong quá trình quản lý yêu cầu. Mục tiêu chính của RCCB là đánh giá và quyết định chấp nhận hoặc từ chối các thay đổi đối với yêu cầu. Điều này giúp đảm bảo rằng các yêu cầu được cập nhật một cách có hệ thống và phù hợp với mục tiêu của dự án. RCCB cũng giúp ngăn chặn những thay đổi không cần thiết hoặc không phù hợp, từ đó giúp dự án được quản lý một cách hiệu quả hơn. Trong quá trình đánh giá, RCCB sẽ xem xét các yếu tố như tác động của thay đổi đến dự án, chi phí và thời gian cần thiết để thực hiện thay đổi, cũng như sự đồng ý của các bên liên quan.

Requirements Traceability Matrix (RTM) là một công cụ quan trọng trong quản lý dự án, giúp theo dõi và theo dõi các yêu cầu của dự án. Nó là một bảng tính (spreadsheet) mà liệt kê các yêu cầu và các trường hợp kiểm tra tương ứng. Tuy nhiên, RTM còn được sử dụng rộng rãi hơn là một bảng tính (spreadsheet) mà ánh xạ các yêu cầu đến các tài liệu dự án khác như tài liệu thiết kế, các trường hợp kiểm tra và mã nguồn. Điều này giúp cho các nhà phát triển và quản lý dự án có thể theo dõi và quản lý các yêu cầu một cách hiệu quả hơn.

Tạo một ma trận theo dõi trong một dự án giúp đảm bảo rằng tất cả các yêu cầu được liên kết với các giai đoạn thiết kế, thử nghiệm và triển khai. Điều này giúp đảm bảo rằng các yêu cầu được thực hiện một cách có hệ thống và toàn diện. Ma trận theo dõi giúp xác định rõ ràng các yêu cầu nào đã được thực hiện, và các yêu cầu nào vẫn còn cần được xử lý. Điều này giúp giảm thiểu khả năng xảy ra lỗi và đảm bảo rằng dự án được hoàn thành đúng hạn. Ngoài ra, ma trận theo dõi còn giúp cải thiện sự hiểu biết và giao tiếp giữa các thành viên trong dự án, giúp đảm bảo rằng tất cả mọi người đều có cùng một bức tranh về dự án.

Tracing yêu cầu là một quá trình quan trọng trong phát triển phần mềm, giúp đảm bảo rằng các yêu cầu của dự án được thực hiện chính xác và hiệu quả. Motivation chính cho việc tracing yêu cầu là để cải thiện chất lượng sản phẩm, giảm chi phí bảo trì và hỗ trợ tái sử dụng. Khi yêu cầu được tracing chính xác, các nhà phát triển có thể dễ dàng xác định và sửa lỗi, từ đó cải thiện chất lượng sản phẩm và giảm chi phí bảo trì. Ngoài ra, việc tracing yêu cầu cũng giúp hỗ trợ tái sử dụng các thành phần đã được phát triển, giảm thiểu thời gian và chi phí phát triển mới.

Đáp án đúng gồm hai ý: "To map requirements to other system elements like design and code" và "To identify missing or unnecessary requirements". Traceability matrix (ma trận truy vết) ghi liên kết giữa từng yêu cầu với nguồn gốc của nó và với thiết kế, mã nguồn, ca kiểm thử; nhìn vào ma trận, ô trống cho biết yêu cầu chưa được hiện thực hoặc chưa được kiểm thử, còn yêu cầu không truy về mục tiêu nghiệp vụ nào là dấu hiệu yêu cầu thừa, và thành phần thiết kế không gắn yêu cầu nào gợi ý yêu cầu còn thiếu. "To track project progress in real-time" sai vì ma trận có thể cho biết trạng thái hiện thực của yêu cầu nhưng không phải công cụ theo dõi tiến độ dự án theo thời gian thực, việc đó thuộc công cụ quản lý dự án. "To generate new requirements automatically" sai vì ma trận chỉ ghi lại liên kết, không tự sinh ra yêu cầu, yêu cầu mới phải qua khơi gợi và phân tích.

Đáp án đúng: "To track changes and ensure alignment with project goals". Traceability (khả năng truy vết) là việc liên kết mỗi yêu cầu ngược về nguồn gốc của nó (mục tiêu nghiệp vụ, yêu cầu người dùng) và xuôi tới thiết kế, mã, ca kiểm thử; thuộc hoạt động quản lý yêu cầu. Khi yêu cầu thay đổi, các liên kết này cho biết thay đổi ảnh hưởng tới đâu và yêu cầu mới có còn phục vụ mục tiêu dự án không. "To prioritize functional requirements" sai vì xếp ưu tiên là một hoạt động phân tích riêng, dựa vào giá trị, chi phí, rủi ro chứ không dựa vào liên kết truy vết. "To reduce stakeholder involvement" sai vì truy vết không thay thế được sự tham gia của các bên liên quan. "To eliminate ambiguous requirements" là việc của viết yêu cầu rõ ràng và review, truy vết không làm yêu cầu bớt mơ hồ.

Trong bối cảnh quản lý thay đổi trên các dự án agile, thay đổi thường được quản lý như thế nào để duy trì sự phù hợp với các mục tiêu và ưu tiên kinh doanh?

Đáp án đúng: "Requirements Volatility Chart". Requirements volatility (độ biến động yêu cầu) đo số lượng yêu cầu được thêm, sửa, xoá theo thời gian; vẽ thành biểu đồ, nó cho thấy khối lượng thay đổi và xu hướng của chúng, giúp phát hiện khi yêu cầu chưa ổn định gần ngày phát hành. Đây là một chỉ số của hoạt động quản lý yêu cầu, gắn với kiểm soát thay đổi. "Use Case Matrix" sai vì ma trận ca sử dụng chỉ đối chiếu ca sử dụng với các phần tử khác, như tác nhân hay yêu cầu chức năng, nó không theo dõi số lần thay đổi theo thời gian. "MoSCoW Grid" sai vì MoSCoW là kỹ thuật xếp ưu tiên Must, Should, Could, Won't, không đo lượng thay đổi. "Stakeholder Priority Index" sai vì một chỉ số ưu tiên bên liên quan, nếu có, phản ánh mức quan trọng của bên liên quan hay yêu cầu, chứ không cho thấy khối lượng và xu hướng thay đổi yêu cầu.

Đáp án đúng gồm ba ý: "Understand the possible implications of the change", "Identify all affected requirements and documents" và "Estimate the effort needed for the change". Change impact analysis (phân tích tác động thay đổi) là bước trong kiểm soát thay đổi giúp ban kiểm soát thay đổi quyết định chấp nhận hay từ chối một yêu cầu thay đổi: trước hết hiểu các hệ quả có thể có của thay đổi, kể cả xung đột với yêu cầu khác; tiếp đó dùng truy vết yêu cầu để xác định mọi yêu cầu, thiết kế, mã, ca kiểm thử, tài liệu bị ảnh hưởng; sau đó ước lượng công sức để cài đặt thay đổi, làm cơ sở đánh giá chi phí và lịch. "Implement the change without stakeholder approval" sai vì đi ngược bản chất kiểm soát thay đổi: phân tích tác động diễn ra trước khi quyết định, và thay đổi chỉ được làm sau khi người có thẩm quyền phê duyệt.

Đáp án đúng: "Change impact analysis". Requirements tracing (truy vết yêu cầu) liên kết mỗi yêu cầu với nguồn gốc, với các yêu cầu liên quan và với thiết kế, mã, ca kiểm thử. Động lực chính là khi một yêu cầu cần sửa, nhờ các liên kết đó người ta lần ra được mọi sản phẩm bị ảnh hưởng để ước lượng công sức và rủi ro, tức là phân tích tác động thay đổi, một phần của quản lý yêu cầu và kiểm soát thay đổi. "Requirements elicitation" là khơi gợi yêu cầu ở đầu dự án, khi chưa có gì để truy vết. "User interface design" là hoạt động thiết kế, có thể nằm trong chuỗi truy vết nhưng không phải lý do cần truy vết. "Project budgeting" là lập ngân sách, có thể dùng kết quả phân tích tác động nhưng không phải hoạt động mà truy vết trực tiếp phục vụ khi sửa yêu cầu.

Đáp án đúng: "Opportunity". Phương pháp Agile coi thay đổi yêu cầu là điều tất yếu và là cơ hội để sản phẩm sát với nhu cầu thật hơn; tuyên ngôn Agile đề cao phản hồi với thay đổi hơn bám theo kế hoạch, nên yêu cầu được làm mịn dần, ưu tiên lại ở mỗi vòng lặp qua product backlog. Phương án "Disruption" phản ánh góc nhìn coi thay đổi là sự xáo trộn cần ngăn chặn, ngược với tinh thần Agile. Phương án "Risk" sai vì dù thay đổi không kiểm soát có thể gây rủi ro, Agile chủ động đón nhận nó thông qua vòng lặp ngắn thay vì coi là mối đe dọa. Phương án "Expense" sai vì Agile giữ chi phí thay đổi thấp bằng cách giao từng phần nhỏ và nhận phản hồi sớm, không xem thay đổi chủ yếu là khoản tốn kém.

Đáp án đúng: "To link requirements to design, development, and testing artifacts". Requirements traceability matrix (RTM, ma trận truy vết yêu cầu) là bảng ghi liên kết giữa từng yêu cầu với nguồn gốc của nó và với các sản phẩm phía sau như thiết kế, mã nguồn, ca kiểm thử; đây là công cụ của hoạt động quản lý yêu cầu, phục vụ phân tích tác động thay đổi và kiểm tra mọi yêu cầu đều được hiện thực, được kiểm thử. "To identify redundant requirements" chỉ là lợi ích phụ: nhìn ma trận có thể thấy yêu cầu trùng lặp hay không gắn mục tiêu nào, nhưng đó không phải mục tiêu chính khi lập RTM. "To finalize the system budget" sai vì ngân sách thuộc quản lý dự án, ma trận truy vết không chốt chi phí. "To prioritize stakeholder meetings" sai vì việc sắp lịch họp với các bên liên quan không liên quan tới truy vết yêu cầu.