Bài giảng Thu nhận yêu cầu - Chương 7: Quản lý yêu cầu - Trần Thị Kim Chi

Requirement baseline Requirement Management (RM) Traceability Công cụ Requirements baseline (Ranh giới yêu cầu) Là tập hợp các yêu cầu chức năng và phi chức năng mà đội phát triển đã cam kết để thực thi trong hệ thống. Xác định baseline giúp stakeholders hiểu được khả năng và đặc trưng mà họ có thể mong thấy được trong phần mềm sẽ phát hành. Quản lý yêu cầu nhấn mạnh: Kiểm soát thay đổi đối với requirement baseline. Giữ các kế hoạch dự án phù hợp với tình trạng yêu cầu hiện tại. Kiểm soát các phiên bản của từng yêu cầu riêng biệt và của các tài liệu yêu cầu. Quản lý mối quan hệ giữa yêu cầu, các liên kết hoặc phụ thuộc giữa các yêu cầu riêng biệt và các phần tử được chuyển giao của dự án. Giám sát trạng thái của yêu cầu trong baseline.

ppt48 trang | Chia sẻ: candy98 | Lượt xem: 667 | Lượt tải: 0download
Bạn đang xem trước 20 trang tài liệu Bài giảng Thu nhận yêu cầu - Chương 7: Quản lý yêu cầu - Trần Thị Kim Chi, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
Chapter 7 Requirements Management Quản lý yêu cầu1Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUIRequirement baselineRequirement Management (RM)TraceabilityCông cụNội dung2Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI3Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUILà tập hợp các yêu cầu chức năng và phi chức năng mà đội phát triển đã cam kết để thực thi trong hệ thống.Xác định baseline giúp stakeholders hiểu được khả năng và đặc trưng mà họ có thể mong thấy được trong phần mềm sẽ phát hành. Requirements baseline Ranh giới yêu cầu 4Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUIQuản lý yêu cầu nhấn mạnh:Kiểm soát thay đổi đối với requirement baseline.Giữ các kế hoạch dự án phù hợp với tình trạng yêu cầu hiện tại.Kiểm soát các phiên bản của từng yêu cầu riêng biệt và của các tài liệu yêu cầu.Quản lý mối quan hệ giữa yêu cầu, các liên kết hoặc phụ thuộc giữa các yêu cầu riêng biệt và các phần tử được chuyển giao của dự án.Giám sát trạng thái của yêu cầu trong baseline.Requirements baseline 5Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUIRequirements Manager/Project Manager: là người có nhiệm vụ quản lý các yêu cầu từ lúc trở thành baseline và tất cả các phiên bản chỉnh sửa có phê duyệt sau đóMọi stakeholder đều có quyền sử dụngĐối tượng quản lý/sử dụng baseline6Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUIPhải có 1 ai chịu trách nhiệm về các hoạt động quản lý yêu cầu. Người phân tích yêu cầu (requirement analyst) của dự án thường là người quản lý yêu cầu, có nhiệm vụ:Xác lập cơ chế lưu trữ yêu cầuXác định các thuộc tính yêu cầuQuản lý trạng thái yêu cầu và cập nhật dữ liệu theo dõi trạng tháiPhát sinh các báo cáo về hoạt động liên quan đến thay đổiVai trò của người quản lý yêu cầu (Requirement manager)7Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUIRequirements Baseline là cầu nối giữa phát triển yêu cầu (requirement development) và quản lý yêu cầu (Requirements management )Quản lý yêu cầu bao gồm tất cả hoạt động nhằm duy trì tính bảo toàn (integrity), độ chính xác (accuracy) và tính hiện hành của baseline.Quản lý yêu cầu (Requirement management – RM))8Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUICác hoạt động chính để quản lý yêu cầu9Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUIKiểm soát thayđổi (ChangeControl)Kiểm soát phiênbản (VersionControl)Giám sát trạngthái yêu cầu(RequirementStatus Tracking)Lần vết yêu cầu(RequirementTracing)Đề xuất thay đổiPhân tích ảnh hưởngRa quyết địnhTruyền thôngTích hợpĐo lường độ ổn định của yêu cầuXác định phiên bản của tài liệu yêu cầuXác định phiên soát xét từng yêu cầuĐịnh nghĩa các liên kết với các yêu cầu khácĐịnh nghĩa các liên kết với các phần tử hệ thống khácĐịnh nghĩa trạng thái của yêu cầuGiám sát mỗi yêu cầu đã định nghĩa trạng tháiCác yêu cầu trong baseline phải được phân biệt với các yêu cầu đã được đề xuất nhưng không được chấp nhận. Tài liệu SRS đã được baseline chỉ nên chứa các yêu cầu đã được lên kế hoạch cho phiên bản cụ thể nào đó, nó khác với các phiên bản nháp trước đó khi chưa được phê duyệt. Change Control10Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUIĐội phát triển nếu chấp nhận các thay đổi yêu cầu vừa được đề xuất  có thể không hoàn thành lịch biều và các cam kết về chất lượng của dự án.  Người quản lý dự án phải thỏa thuận với khách hàng về những thay đổi so với cam kết ban đầu. Dự án có thể đối phó lại các yêu cầu bị thay đổi theo các cách sau:Trì hoãn lại các yêu cầu có độ ưu tiên mức thấpThêm nhân viênBuộc làm thêm giờ, trả thêm tiền trong 1 khoảng thời gian ngắnKéo dài thời gian để thêm chức năng mớiChất lượng bị đặt trước áp lực thời gianCác Thách thức khi yêu cầu thay đổi11Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUIVì thay đổi là hiển nhiên nên cần phải lập kế hoạch thay đổi cho các yêu cầu trong quá trình phát triển dự án, ngay cả khi hệ thống đã bàn giao  cần xây dựng quy trình và tool để quản lý các yêu cầu bị thay đổi.Change ControlProceduresTools12Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUICần xác định các hoạt động mà đội dự án phải thực hiện để quản lý yêu cầu. Lưu trữ lại các hoạt động này và tập huấn các thành viên thực thi các hoạt động một cách thống nhất và hiệu quả. Requirements Management Procedures13Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUIRequirements Management Procedures14Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUITrang 268Các đặc tính trong một công cụ để hỗ trợ quy trình kiểm soát thay đổi yêu cầu:Cho phép bạn định nghĩa các mục dữ liệu (data items) bạn muốn đưa vào một đề xuất thay đổi.Cho phép bạn định nghĩa một sơ đồ chuyển trạng thái của chu trình đề xuất thay đổi.Ràng buộc sơ đồ chuyển trạng thái sao cho chỉ những người được cấp quyền mới được phép thay đổi trạng thái của đề xuất.Ghi lại ngày tháng của mỗi thay đổi trạng thái và định danh của người thực hiện thay đổi.Cho phép bạn nhận các ghi chú bằng email tự động khi một người đề xuất (Originator) đệ trình một đề xuất thay đổi mới hoặc khi một trạng thái của đề xuất được cập nhật.Cho phép bạn sinh ra các báo cáo tiêu chuẩn hoặc được tùy biến và các biểu đồ bạn cần.CÔNG CỤ KIỂM SOÁT THAY ĐỔI (Tools)15Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUICó thể đưa tất cả thông tin này vào 1 quy trình quản lý yêu cầu chung, hoặc có thể viết thành các quy trình riêng lẻ như change-control, impact-analysis, và status-tracking .Các thủ tục này nên áp dụng cho cả tổ chức vì chúng là các chức năng thông dụng mà mỗi đội dự án nên tuân theo.Thông tin cần quản lý16Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUICác công cụ, kỹ thuật và quy ước để kiểm soát các phiên bản khác nhau của tài liệu về yêu cầu.Làm thế nào để baseline yêu cầuCác trạng thái yêu cầu và ai có thể làm nó thay đổiCác thủ tục theo dõi trạng thái yêu cầu.Cách mà các yêu cầu và thay đổi mới được đề xuất, xử lý, thỏa thuận và được chuyển đến tất cả các stakeholder quan trọng. Làm thế nào để phân tích ảnh hưởng của thay đổiLàm thế nào để kế hoạch và cam kết của dự án phản ánh được các thay đổi của yêu cầu. Thông tin cần quản lý17Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUIKế hoạch quản lý yêu cầu (Requirements Management Plan) là 1 phần trong kế hoạch quản lý dự án tổng thể. Nội dung của kế hoạch RM bao gồm:Giới thiệu về RM Phạm vi của tài liệuCác vấn đề làm ảnh hưởng đến việc thực thi kế hoạch. Các tài liệu có thể áp dụng trong RE như các chính sách, tiều chuẩnCác phương pháp và công cụ được dùng trong quá trình RM.Quyền hạn và trách nhiệm của những người tham giaCác chiến lược để hoàn thành chất lượng yêu cầu, bao gồm traceability và change control Lập kế hoạch quản lý yêu cầu18Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUIFeature creep dùng để chỉ hiện tượng nhiều thay đổi nhỏ được thông qua mà không cần đánh giá xét duyệt.Hậu quả: làm ảnh hưởng nghiêm trọng đến lợi nhuận và ngày hoàn thành sản phẩm. Cách khắc phục: mọi yêu cầu thay đổi cần được phê duyệt bởi CCB (Change Control Board).Feature creep19Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUICCB có thể là một cá nhân hoặc là một nhóm, ra quyết định chấp thuận hay không về các thay đổi yêu cầu được đề xuất và các tính năng sản phẩm mới được gợi ý. CCB cũng ra quyết định về các khiếm khuyết (defect) đã phát hiện cần được sửa chữa và được phát hành bản sửa chữa ở phiên bản nào. CCB (Change Control Board) Ban kiểm soát thay đổi20Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUICCB có thể bao gồm các lĩnh vực sau:Cấp quản lý chương trình hoặc sản phẩm.Cấp quản lý dự án.Nhóm phát triển.Kiểm thử hoặc đảm bảo chất lượng.Marketing hoặc đại diện khách hàng.Người làm tài liệu người dùng.Người hỗ trợ kỹ thuật.Nhóm hỗ trợ sản phẩm (help desk).Nhóm quản lý cấu hình.CCB (Change Control Board) Ban kiểm soát thay đổi21Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUIRa quyết địnhTruyền thông trạng thái (Communicating Status)Tái đàm phán các cam kết (Renegotiating Commitments)QUY CHẾ HOẠT ĐỘNG CỦA CCB (CCB CHARTER)22Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUICCB thực hiện rất nhiều phân tích khác nhau trong quá trình kiểm soát thay đổiCCB (Change Control Board) Ban kiểm soát thay đổi23Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUILiên quan đến việc phát hiện ra chức năng cơ bản hay hợp lý. Từ thiết kế hợp lý giúp dò tìm ngược về lại yêu cầu ban đầu và từ yêu cầu này dò tìm ra được yêu cầu của stakeholder  dẫn đến quyết định là có nên bổ sung yêu cầu này vào sản phẩm hay không?Impact analysis24Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUIMục tiêu: xác định tài chính, tài nguyên hay chi phí tạm thời phát sinh do yêu cầu bị thay đổi hay phát sinh tính chất mới. Thành viên của CCB phải xác định bất kỳ sửa đổi hay mở rộng nào sẽ ảnh hưởng đến hệ thống để suy ra chi phí và rủi ro của sửa đổi đó. Derivation analysis25Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUIĐo lường tỷ lệ giữa các tính năng của sản phẩm dự kiến và sản phẩm thực, để xác định xem yêu cầu có được thực thi trong sản phẩm hay không?Phân tích này được thực hiện bằng cách theo dõi từ các yêu cầu hệ thống lúc đầu đến các test case. Test là cách tốt nhất để đo lường mức độ tuân thủ theo thiết kế.Coverage Analysis26Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUIIdentifying volatile requirementsEstablishing Policies for requirements processes and supporting them with workflow tools, guidelines, templates, and examplesPrioritizing RequirementsEstablishing and updating the requirements baselineDocumenting DecisionsPlanning releases and allocating requirement to releases Assignment 24??Các hoạt động quản lý yêu cầu27Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUIMột yêu cầu có thể được theo dõi nếu và chỉ nếu yêu cầu này ngay từ đầu được xác định rõ ràng, có cơ chế làm cho nó khả thi trong quá trình phát triền phần mềmChiến lược theo dõi là dựa vào vai trò của thành viên dự án và nhu cầu của họ. Traceability28Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUIMục đích của RTM là để bảo đảm các mục tiêu của yêu cầu phải phù hợp với yêu cầu bằng cách kết hợp mỗi yêu cầu với mục tiêu thông qua ma trận theo dõi. Requirements traceability is concerned with documenting the life of a requirement.REQUIREMENTS TRACEABILITY MATRIX (RTM)29Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUIForward trace: ma trận theo dõi được dùng để kiểm tra tất cả các yêu cầu có được đưa vào các thành phần của hệ thống hay các kết quả (deliverable) khác hay khôngBackward trace: ma trận được dùng để xác định các nguồn của yêu cầu. REQUIREMENTS TRACEABILITY MATRIX (RTM)30Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUITheo dõi yêu cầu cũng bao gồm việc theo dõi những việc khác nhằm để thỏa mãn yêu cầu như capabilities, design elements, manual operations, tests, .Ma trận theo dõi cũng được dùng để bảo đảm tất cả yêu cầu khi thay đổi cũng vẫn được đưa vào các thành phần của hệ thống. Nhờ đó, ảnh hưởng của những yêu cầu bị thay đổi đến hệ thống có thể xác định được.REQUIREMENTS TRACEABILITY MATRIX (RTM)31Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI32Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUIVí dụ1: Ma trận theo dõi33Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI“U” chỉ yêu cầu người dùng“S” chỉ yêu cầu hệ thống.Theo dõi S12 khi trỏ đến nguồn của nó thì thấy rõ ràng yêu cầu này sai: phải loại bỏ, viết lại hay cần sửa lại việc theo dõi này. Ví dụ1: Ma trận theo dõi34Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI35Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUIVersion control là 1 trong các điểm chính của quản lý yêu cầu. Mỗi phiên bản (version) của tài liệu yêu cầu phải được xác định duy nhất. Mỗi thành viên của đội có thể truy xuất vào phiên bản hiện hành của yêu cầu và các thay đổi phải được lưu trữ lại 1 cách rõ ràng và được gửi đến mọi người có liên quan. Requirements Version Control36Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUIĐể giảm thiểu nhầm lần, mâu thuẫn và sai lệch thông tin, chỉ cho phép 1 vài cá nhân được quyền cập nhật yêu cầu và bảo đảm là mã phiên bản thay đổi khi yêu cầu thay đổi.Mỗi phiên bản hiện hành cũng nên chứa phần revision history: xác định đã có những thay đổi gì, ngày của mỗi thay đổi, ai đã gây ra thay đổi, lý do cho mỗi thay đổi, cộng thêm số phiên bản, thường số phiên bản sẽ tăng mỗi khi có yêu cầu thay đổi.Requirements Version Control37Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUICơ chế kiểm soát phiên bản đơn giản nhất là tự đặt tên mỗi lần duyệt SRS theo quy ước chuẩn. Ví dụ: phiên bản đầu tiên "Version 1.0 draft 1.“, phiên bản kế tiếp là "Version 1.0 draft 2” Số phiên bản sẽ tăng cho đến khi tài liệu được phê duyệt và baseline. Sau đó nhãn sẽ thay đổi thành "Version 1.0 approved.“, các phiên bản kế tiếp là "Version 1.1 draft 1" nếu sửa đổi nhỏ hay "Version 2.0 draft 1" nếu sửa đổi lớn.Version control mechanism38Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUIKhó giữ cho tài liệu đồng bộ khi có thay đổiKhó truyền đạt kịp thời thay đổi đến các đội thực hiện Khó khăn trong việc lưu trữ thông tin bổ sung về mỗi yêu cầuKhó xác định được link giữa yêu cầu chức năng với các phần tử khác của hệ thống. Khó khăn khi theo dõi trạng thái yêu cầu (requirements status)Các hạn chế khi quản lý yêu cầu bằng văn bản39Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUIKhó quản lý đồng thời các tập yêu cầu cho những phiên bản khác nhau hay sản phẩm có liên quan. Khi 1 yêu cầu tham chiều đến 1 phiên bản khác, analyst cần chuyển theo cả yêu cầu đó.Sử dụng lại yêu cầu có nghĩa là analyst phải tự sao chép văn bản từ SRS gốc đến SRS dùng cho hệ thống khác. Khó khăn khi có nhiều người cùng tham gia sửa đổi yêu cầu Không có chỗ thích hợp để lưu trữ lại các yêu cầu bị loại bỏ hay bị xóa khỏi baselineCác hạn chế khi quản lý yêu cầu bằng văn bản40Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUICông cụ sẽ giúp lưu trữ thông tin trong CSDL đa người dùng giúp giải quyết được các hạn chế khi quản lý yêu cầu bằng văn bản thông thường. Các dự án nhỏ có thể dùng bảng tính điện tử (spreadsheet) hay CSDL đơn giản để quản lý yêu cầu.Các dự án lớn nên dùng công cụ quản lý yêu cầu tự động. Vai trò của công cụ quản lý yêu cầu (Requirement management tools)41Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUICreate and view requirements as entities and properties directly in the model Collate the requirements in an external CSV file and then import them into your model Detail use cases and scenarios directly in the model Enter standard attributes (properties) for each requirement, such as difficulty, status and type, and define your own attributes (properties) Chức năng của công cụ quản lý yêu cầu42Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUITrace requirements to Use Cases, business rules, test cases and analysis artifacts (using, for example, the Relationship Matrix) Trace and view the impact of changes on requirements (through, for example, the Traceability window) and review the changes themselves Create customer-quality MS Word and HTML reports on requirements. Chức năng của công cụ quản lý yêu cầu43Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUIRational DOORS của IBMEnterprise Architecture (www.sparxsystems.com)CaliberRM của BorlandMột vài công cụ quản lý yêu cầu 44Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUILựa chọn các trạng thái mà bạn muốn sử dụng để mô tả vòng đời của các yêu cầu chức năng trong dự án của bạn. Định nghĩa tình trạng hiện thời cho mỗi yêu cầu trong SRS và theo sát sự diễn biến của yêu cầu trong phần còn lại của dự án.Định nghĩa một sơđồ kiểm soát phiên bản để định danh tài liệu yêu cầu của bạn. Tài liệu hóa sơđồ này nhưlà một phần của quy trình quản lý yêu cầu của bạn.Viết một mô tả quy trình về các bước mà tổ chức của bạn sẽ thực hiện để quản lý các yêu cầu của mỗi dự án. Khuyến khích các nhà phân tích soạn thảo, soát xét, làm dự án thử nghiệm, chấp thuận các hoạt động của quy trình và các sản phẩm được chuyển giao của quy trình. Hãy chắc chắn rằng các bước của quy trình mà bạn lựa chọn là có tính thực hành và thực tế, chúng giúp bạn tăng thêm giá trị của dự án.Assigment45Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUIXác định những người ra quyết định trong dự án của bạn và tổ chức họ nhưmột ban kiểm soát thay đổi. Yêu cầu CCB viết một quy chế hoạt động để chắc chắn mỗi người đều hiểu mục đích của ban, thành phần và quy trình ra quyết định.Định nghĩa một sơđồ state-transition đối với chu trình sống của các thay đổi yêu cầu được đề xuất trong dự án của bạn, bắt đầu với sơđồ trong Hình 17-2. Viết một thủ tục mô tả nhóm của bạn sẽ xử lý các thay đổi yêu cầu được đề xuất nhưthế nào. Sử dụng thủ tục bằng tay cho đến khi bạn tự nhận thấy thủ tục đã mang tính thực tế, hiệu quả, đơn giản hết mức có thể.Lựa chọn một công cụ giám sát thích hợp với môi trường làm việc của bạn và tùy biến nó để hỗ trợ thủ tục kiểm soát thay đổi mà bạn đã phát triển trước đó.Assigment46Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI47Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUIMột vài công cụ quản lý yêu cầu 48Bài giảng môn Thu Nhận Yêu cầu - BM HTTT - Khoa CNTT - HUI
Tài liệu liên quan