Baigiang PHÂN TÍCH VÀ QUẢN LÝ YÊU CẦU PHẦN MỀM

MỤC LỤC Trang Chương 1: TỔNG QUAN VỀ PHÂN TÍCH VÀ QUẢN LÝ YÊU CẦU PHẦN MỀM 1.1 Định nghĩa yêu cầu Stakeholder 1.2 Kim tự tháp yêu cầu 1.3 Khả lưu vết yêu cầu .12 1.5 Tổng quan tiến trình quản lý yêu cầu .21 TỔNG KẾT 31 TÀI LIỆU THAM KHẢO 32 Chương 2: THIẾT LẬP KẾ HOẠCH QUẢN LÝ YÊU CẦU 33 2.1.Thời điểm lập kế hoạch quản lý yêu cầu (RMP) 33 2.2.Các định tư liệu hóa RMP 33 2.3 Mẫu kế hoạch quản lý yêu cầu .43 TỔNG KẾT 51 TÀI LIỆU THAM KHẢO 51 Chương SUY LUẬN CÁC YÊU CẦU 52 3.1 Xác định Stakeholder .52 3.2 Các kỹ thuật phân tích rút yêu cầu 54 3.3 Tạo tài liệu yêu cầu Stakeholder 74 3.4 Sử dụng khung nhìn để phân tích yêu cầu 76 TỔNG KẾT 76 TÀI LIỆU THAM KHẢO 77 Chương PHÁT TRIỂN TÀI LIỆU TRỰC QUAN 78 4.1 Cấu trúc tài liệu trực quan 79 4.2 Sinh đặc trưng từ nhu cầu Stakeholder 80 4.3 Các thuộc tính đặc trưng 87 4.4 Các dấu vết - Traceability 88 TỔNG KẾT 91 Chương TẠO CÁC USE CASE .92 5.1Xác định tác nhân (Actor) .93 5.2Xác định Use Case (UC) 94 5.3 Các biểu đồ UC 95 5.4Cấu trúc mơ hình UC 97 5.5 Tài liệu đặc tả UC .100 5.6 Các kịch .106 TỔNG KẾT 110 CHƯƠNG ĐẶC TẢ BỔ SUNG 112 6.1 Suy luận yêu cầu bổ sung .113 6.2 Phân loại yêu cầu bổ sung 113 6.3 Suy luận Yêu cầu bổ sung từ Đặc trưng 126 6.4 Các thuộc tính yêu cầu bổ sung 129 6.5 Dấu vết yêu cầu bổ sung 134 TỔNG KẾT 136 Chương TẠO CÁC TEST CASE TỪ CÁC USE CASE 138 7.1 Tạo Test Case .138 7.2 Các luật nghiệp vụ 156 7.3 Tạo kiểu tài liệu lưu kịch test case .156 TỔNG KẾT 157 CHƯƠNG TẠO CÁC TEST CASE TỪ CÁC YÊU CẦU BỔ SUNG 158 8.1 Thực thi test case lựa chọn môi trường khác 159 8.2 Thêm kiểm tra cho UC 160 8.3 Kiểm tra sửa đổi UC xác định 162 8.4 Thực tập 163 8.5 Checklist 164 8.6 Phân tích .164 8.7 Kiểm thử hộp trắng .165 8.8 Kiểm thử tự động .166 8.9 Sử dụng Robot Test Manager cho việc kiểm thử tự động 167 TỔNG KẾT CHƯƠNG 180 CHƯƠNG THIẾT KẾ HƯỚNG ĐỐI TƯỢNG 182 9.1 Giới thiệu 182 9.2 Thiết kế hệ thống từ UC 183 TỔNG KẾT 198 Chương 10 QUẢN LÝ CÁC YÊU CẦU TRONG TIẾN TRÌNH RUP 200 10.1 RUP 200 10.2 Kim tự tháp yêu cầu RUP 202 Chương 11 TỔNG KẾT 217 11.1 Tổng kết cách tiếp cận kim tự tháp cho tiến trình quản lý yêu cầu .217 11.2 Các lợi ích 220 PHỤ LỤC A 221 MẪU KẾ HOẠCH QUẢN LÝ YÊU CẦU 221 LỜI NÓI ĐẦU  Bài giảng biên dịch từ tài liệu [1] tích lũy từ số kinh nghiệm giảng dạy thân tác giả  Bài giảng tập trung vào hoạt động phân tích quản lý yêu cầu phần mềm phát triển theo cách tiếp cận hướng đối tượng  Công cụ trợ giúp cho hoạt động quản lý yêu cầu giới thiệu tài liệu Rational RequisitePro IBM  Đây giảng đầu tay, chắn chắn nhiều thiếu xót, tác giả mong nhận ý kiến đóng góp từ độc giả Mọi ý kiến đóng góp xin gửi địa chỉ: ptthuong@ictu.edu.vn Tác giả xin chân thành cảm ơn! Tác giả  Chương 1: TỔNG QUAN VỀ PHÂN TÍCH VÀ QUẢN LÝ YÊU CẦU PHẦN MỀM Chương bắt đầu việc định nghĩa khái niệm yêu cầu khái niệm Stakeholder Sau mơ tả kiểu u cầu tồn dự án Mối quan hệ yêu cầu trình bày theo dạng kim tự tháp Khái niệm dấu vét giới thiệu (nguồn gốc yêu cầu) Các đặc tính yêu cầu tốt trình bày Chương cấp ví dụ vấn đề liên quan đến yêu cầu hướng dẫn cách thức để khắc phục chúng Các bước quản lý yêu cầu chung (RM) suốt vòng đời dự án chương Cuối chương giới thiệu bước qua kim tự tháp yêu cầu từ xuống 1.1 Định nghĩa yêu cầu Stakeholder 1.1.1 Định nghĩa yêu cầu Yêu cầu định nghĩa điều kiện mà hệ thống phải tuân theo lực mà hệ thống phải có Nó là:  Một lực mà hệ thống phải có, lực cần thiết với khách hàng/người dùng để giải vấn đề để đạt mục tiêu cụ thể  Một lực mà hệ thống phải có để thỏa mãn hợp đồng, thỏa mãn chuẩn, thỏa mãn đặc tả, quy tắc tài liệu áp đặt hình thức khác  Một giới hạn đòi hỏi Stakeholder 1.1.2 Định nghĩa Stakeholder Stakeholder định nghĩa người nhóm người bị tác động kết dự án phát triển hệ thống tác động đến hoạt động đầu dự án (có thể xem Stakeholder đối tượng mà có yêu cầu hệ thống) Các Stakeholder là:  Các Khách hàng;  Những người dùng cuối;  Những người phát triển;  Những nhà sản xuất;  Những người kiểm thử;  Người đảm bảo chất lượng;  Người quản trị Cơ sở liệu;  Người quản lý cấu hình;  Những nhà cung cấp;  Những nhà tiếp thị;  Những người bảo trì;  Người quản lý;  Các quan quy định tính an tồn hệ thống (Safety regulation agencies) Hai loại Stakeholder người dùng (là người sử dụng hệ thống) khách hàng (là người yêu cầu phát triển hệ thống, có trách nhiệm phê chuẩn nó, thường người chi trả chi phí phát triển dự án) Phân biệt hai loại Stakeholder quan trọng yêu cầu nhóm Stakeholder xung đột Ví dụ, xét Website hãng du lịch, Stakeholder là:  Khách hàng: Người chủ Website;  Người dùng cuối người sử dụng Website qua internet  Người tham gia vào hoạt động phát triển hệ thống (người phân tích nghiệp vụ, nhà thiết kế, người mã hóa, nhà quản lý dự án, người quản lý phát hành, người thiết kế UC, nhà thiết kế đồ họa)  Người cung cấp tri thức cho hệ thống (các chuyên gia miền, tác giả tài liệu mà sử dụng để suy luận yêu cầu, chủ sở hữu Website mà cung cấp đường link)  Người quản lý (lãnh đạo công ty du lịch, xem khách hàng, giám đốc phòng Cơng nghệ thông tin công ty thiết kế phát triển hệ thống)  Người bảo trì hỗ trợ hệ thống (công ty cung cấp Website hosting, )  Người cung cấp luật lệ quy tắc (các luật áp đặt cơng cụ tìm kiếm nội dung website, luật phủ, luật thuế quốc gia) Hình 1.1 Stakeholder hệ thống yêu cầu đặt hệ thống cung cấp họ Hình 1.1 Khách hàng, yêu cầu thành phần sản phẩm, sản phẩm 1.2 Kim tự tháp yêu cầu Phụ thuộc vào hình thức, nguồn gốc đặc tính chung, u cầu phân loại thành kiểu yêu cầu khác Sau số kiểu yêu cầu thường sử dụng dự án:  Stakeholder need (nhu cầu Stakeholder): Một yêu cầu để xuất Stakeholder  Feature (đặc trưng): Một dịch vụ cung cấp hệ thống, thường hình thành hoạt động phân tích nghiệp vụ; mục tiêu đặc trưng để thỏa mãn nhu cầu Stakeholder  Use case (ca sử dụng): Một mô tả hành vi hệ thống theo thuật ngữ chuỗi hành động  Supplementary requirement (yêu cầu bổ sung): yêu cầu khác (thường yêu cầu phi chức năng) thể use cases  Test case (ca kiểm thử): đặc tả đầu vào kiểm thử, điều kiện thực thi, kết mong đợi  Scenario (kịch bản): Một chuỗi hành động cụ thể; đường cụ thể qua use case Các kiểu yêu cầu biểu diễn theo hình kim tự tháp, hình 1.2 Ở mức đỉnh nhu cầu Stakeholder, mức thấp đặc trưng, ca sử dung, yêu cầu bổ sung Thông thường mức yêu cầu khác nhau, mức độ chi tiết khác Càng mức thấp hơn, mức độ chi tiết cao Ví dụ, nhu cầu Stakeholse “dữ liệu nên lưu trữ lâu dài” Một đặc trưng tinh chế từ nhu cầu “hệ thống nên sử dụng sở liệu quan hệ” Ở mức đặc tả bổ sung, yêu cầu chí chi tiết “Hệ thống nên sử dụng CSDL Oracle 9i” Một cách tiếp cận tốt để quản lý u cầu có hai mức độ khác trừu tượng hóa u cầu Ví dụ, tài liệu trực quan chứa yêu cầu mức cao (các đặc trưng) yêu cầu mức thấp kim tự tháp Những Stakeholder thâm niên (ví dụ lãnh đạo cơng ty) khơng có thời gian để đọc 200 trang yêu cầu chi tiết mà họ mong đợi đọc tài liệu trực quan khoảng 12 trang Hình 1.2 – Kim tự tháp yêu cầu Tuy nhiên, người phân tích nghiệp vụ để định tính chất yêu cầu mức, không sai đặt yêu cầu chi tiết mức nhu cầu Stakeholder Sự khác nhu cầu đặc trưng nguồn gốc yêu cầu Các nhu cầu đến từ Stakeholder đặc trưng hình thành hoạt động phân tích nghiệp vụ Vai trò test case để kiểm thử liệu use case yêu cầu bổ sung cài đặt cách đắn chưa Các kịch giúp tìm thấy use case từ test case tạo thuận lợi cho thiết kế cài đặt đường cụ thể qua use case Khi quản lý yêu cầu cần đạt linh hoạt lưu trữ thuộc tính chúng dấu vết yêu cầu sử dụng chế cho kiểu yêu cầu khác 1.3 Khả lưu vết yêu cầu Dấu vết – Traceability kỹ thuật mà cung cấp mối quan hệ hai mức độ yêu cầu khác hệ thống Kỹ thuật giúp ta định nguồn gốc yêu cầu Hình 1.2 minh họa u cầu lưu vết từ mức xuống mức Mỗi nhu cầu thường ánh xạ thành số đặc trưng Nhìn chung, quan hệ nhiều – nhiều nhu cầu dẫn đến nhiều đặc trưng, đặc trưng sinh từ nhiều nhu cầu Một nhu cầu ánh xạ thành đặc trưng Các đặc trưng ánh xạ thành use case theo quan hệ nhiều – nhiều Các đặc trưng ánh xạ thành yêu cầu bổ sung theo quan hệ nhiều – nhiều Mỗi use case ánh xạ thành nhiều kịch bản, quan hệ – n Các kịch ánh xạ thành test case theo quan hệ – n Traceability đóng số vai trò quan trọng sau:  Thẩm tra cài đặt thỏa mãn đầy đủ yêu cầu: Mọi thứ mà khách hàng yêu cầu cài đặt  Thẩm tra ứng dụng đáp ứng yêu cầu: Không cài đặt thứ mà khách hàng không yêu cầu  Phân tích ảnh hưởng: Những phần tử bị tác động thêm yêu cầu thay đổi yêu cầu tồn  Giúp quản lý thay đổi: Khi số yêu cầu thay đổi, muốn biết test case nên thực lại để kiểm tra thay đổi => Traceability phải thành phần cần thiết dự án 1.4 Các đặc trưng yêu cầu tốt Một yêu cầu cần thỏa mãn số tiêu chuẩn sau xem „yêu cầu tốt” [HUL05][LEF03][LUD05][YOU01] Các yêu cầu tốt nên có đặc tính sau:  Khơng mập mờ  Có thể kiểm thử (có thể thẩm định)  Rõ ràng (ngắn gọn, súc tích, đơn giản, xác) 10 cầu phần mềm (Đăc tả bổ sung UC), Test cas Một số tài liệu thêm vào yêu cầu, Kế hoạch lặp Bên cạnh việc triển khai phát triển lặp, việc triển khai đầy đủ nhu cầu RUP để kết hợp thực tiễn tốt nhất:  Phát triển phần mềm lặp lại: Bằng cách thay đổi thứ tự việc tạo phần tử kim tự tháp, giới thiệu lần lặp Trước lần lặp, kết hoạch lặp chi tiết phải tạo Khi kết thúc lần lặp, đánh giá lặp thực  Quản lý yêu cầu: Sử dụng cách tiếp cận kim tự tháp giới thiệu sách cho phép quản lý yêu cầu mạnh lưu dấu vết kiểu yêu cầu biến đổi Sử dụng RequisitePro khuyên dùng  Sử dụng kiến trúc dựa thành phần: thiết kế hướng đối tượng gợi ý Phụ thuộc vào kiến trúc hệ thống tảng, thực thể khác bao bọc thành phần (như kiến trúc EJB J2ME)  Phần mềm mơ hình hóa trực quan: Sử dụng UML công cụ biểu đồ (ví dụ, cơng cụ IBM Rational Rose, Kiến trúc phân mềm, Kiến trúc liệu, Bộ mơ hình hóa Phần mềm) tạo thuận lợi cho tiến trình thiết kế  Thẩm định chất lượng liên tục: Trong thiết kế test case, cần chắn tập test case cuối bao trùm yêu cầu hệ thống  Quản lý thay đổi: Sau yêu cầu giới thiệu, dấu vết cần kiểm tra Sử dụng cách tiếp cận kim tự tháp yêu cầu, tạo điều kiện cho việc cài đặt dấu vết Sử dụng công cụ điều khiển thay đổi, IBM Rational ClearQuest, công cụ điều khiển phiên bản, IBM Rational ClearCase, giúp điều khiển lưu vết thay đổi Di chuyển từ Waterfall đến RUP không khó, cấu trúc tiến trình u cầu số nguyên tắc TỔNG KẾT CHƯƠNG Các tiếp cận kim tự tháp yêu cầu khớp với RUP Việc tạo phần tử kim tự tháp tương ứng với hoạt động RUP cụ thể Tuy nhiên, cách tiếp cận kim tự tháp sử dụng dự án mà không sử dụng RUP 218 219 Chương 11 TỔNG KẾT Cách tiếp cận trình bày sách cách thức cấu trúc tiến trình quản lý u cầu cách tổ chức yêu cầu kim tự tháp 11.1 Tổng kết cách tiếp cận kim tự tháp cho tiến trình quản lý yêu cầu Hãy tổng kết cách tiếp cận này: Sau kế hoạch quản lý yêu cầu tạo dự án thiết lập, phần tử kim tự tháp yêu cầu tạo: Các yêu cầu đỉnh kim tự tháp (các nhu cầu stakeholder) thu thập sử dụng phương pháp khác để suy luận tri thức: Phân tích nghiệp vụ sinh mức thứ hai kim tự tháp (các đặc trưng) từ yêu cầu stakeholder cách làm yêu cầu chuyển dịch chúng từ miềm vấn đề đến miền giải pháp Các đặc trưng nên có thuộc tính yêu cầu tốt: 220 Để cố định u cầu thiếu sót thuộc tính này, áp dụng số chuyển dịch sau đây: Tầng thứ kim tự tháp chứa uc yêu cầu bổ sung Các UC nắm bắt yêu cầu chức Tạo UC gồm bước sau: Các yêu cầu bổ sung nắm bắt phần lớn yêu cầu phi chức Chúng nắm bắt số yêu cầu chức tổng quát không kết hợp với UC cụ thể Các yêu cầu bổ sung phân loại sau: 221 Các test case tạo để kiểm thử yêu cầu từ tầng thứ Các bước sau sử dụng để phát sinh test case từ UC: Để tạo test case từ yêu cầu bổ sung, sử dụng cách tiếp cận sau đây: 222 Các biểu đồ thiết kế phát sinh từ yêu cầu tầng thứ 3, đặc biệt UC Sau số cách tiếp cận cụ thể: Tài liệu tạo từ phần tử khác kim tự tháp 11.2 Các lợi ích Sau số lợi ích cách tiếp cận trình bày để quản lý yêu cầu:  Dễ dàng lưu vết kiểu yêu cầu khác Nhờ có khả lưu dấu vết, dễ dàng đảm bảo khơng u cầu bị bỏ quên Nó giúp lưu vết nguồn gốc yêu cầu  Sự phân biệt rõ ràng yêu cầu thô gửi stakeholder yêu cầu nẩy sinh từ phân tích nghiệp vụ  Một số test case hợp lý cung cấp bao trùm tốt yêu cầu  Dễ lưu vết tiến trình 223 PHỤ LỤC A MẪU KẾ HOẠCH QUẢN LÝ YÊU CẦU Giới thiệu 1.1 Mục đích Tài liệu mơ tả hướng dẫn sử dụng dự án để thiết lập tài liệu yêu cầu, kiểu yêu cầu, thuộc tính u cầu Nó mơ tả khả lưu vết kiểu yêu cầu biến đổi mà bảo trì suốt vòng đời dự án Nó phục vụ tài liệu cấu hình cho cơng cụ RequisitePro Mục tiêu việc lưu vết yêu cầu để giảm số lượng lỗi tìm trễ chu kỳ phát triển Đảm bảo yêu cầu sản phẩm nắm bắt yêu cầu phần mềm, thiết kế, kiểm thử cải thiện chất lượng sản phẩm 1.2 Phạm vi Kế hoạch nói đến giai đoạn dự án 1.3 Tổng quan Đoạn mô tả công cụ mà sử dụng cho quản lý yêu cầu Đoạn 3.1 mô tẳ thuật ngữ dấu vết định nghĩa cách thức sử dụng thêm gọi, đánh dấu chữ số Các công cụ, Môi trường Cơ sở hạ tầng RequisitePro sử dụng để quản lý yêu cầu Các thuộc tính yêu cầu dấu vết lưu trữ CSDL RequisitePro Các thành viên nhóm, người mà khơng có quyền truy cập đến RequisitePro sử dụng MS Word Một số biểu đồ tạo Rational Rose kết hợp vào tài liệu RequisitePro Các tài liệu kiểu yêu cầu Sau số tài liệu tạo dự án 224 3.2 Các kiểu yêu cầu Phần mô tả mục dấu vết định nghĩa cách thức chúng đặt tên, đánh dấu đánh số 3.3 Dấu vết Hình A.1 cấu trúc dấu vết sử dụng dự án 225 3.4 Các thuộc tính yêu cầu 3.4.1 Các thuộc tính cho FEAT 226 227 228 3.4.2 Các thuộc tính cho STRQ 3.4.3 Các thuộc tính cho UC Tương tự thuộc tính FEAT Thêm thuộc tính Actor 229 230 231 TÀI LIỆU THAM KHẢO [1] Peter Zielczynski, Requirements Management Using IBM Rational RequisitePro, IBM Press, ISBN: 0-321-38300-1, 2008 [2] Ian Sommerville’s , “Software Engineering”; 7th Ed., Addison – Wesley; 2005 [3] Hull, Elizabeth Jacson, and Jeremy Dick, Requirements Engneering, London: Spinger, 2005 [4] Risk Lutowski, Software Requirements encapsulation, quality, and Reuse, Auerbach Publication, 2005 [5] Tim Kasse, Practical Insight into CMMI®; 2Ed, ISBN-13: 978-1-59693-275-3, ARTECH HOUSE, INC., 2008 232