Phân tích yêu cầu phần mềm Bài tâ âp tuần Giảng viên: PGS.TS Huỳnh Quyết Thắng Danh sách sinh viên: Lê Trung Hiếu Đàm Văn Hoài Nguyễn Đức Cương Đoàn Văn Đạt 20111568 20111600 20111203 20111370 CNTT-TT 2.3 K56 CNTT-TT 2.3 K56 CNTT-TT 2.3 K56 CNTT-TT 2.3 K56 Bài I Các hướng tiếp cận  Process-Oriented  Data-Oriented  Architecture-Oriented  Điểm mạnh, điểm yếu phương pháp tiếp cận Process-Oriented Approach  Bản chất:phân tích thiêt kế đặt trọng tâm vào chức phần mềm thực • Tập trung vào giải thuật thao tác xử lý liệu • Quá trình phát triển phần mềm tập trung vào thể phương pháp xử lý liệu • Cấu trúc liệu thông thường rõ Nhóm 3-Phân tích yêu câầu phâần mêầm 05/20/17 Data-Oriented Approach  Dữ liệu không thay đổi yêu cầu hay đòi hỏi người dùng thao tác nghiệp vụ  Trong thiết kế hướng liệu, hệ thống thiết kế dựa cấu trúc tiến trình liệu  Việc phân tích thiết kế tiến hành cho liệu cách tách bạch với yêu cầu hay đòi hỏi người dùng thao tác Nhóm 3-Phân tích yêu câầu phâần mêầm 05/20/17 Data-Oriented Approach Nghiên cứu phát triển sở liệu tập trung vào thực thể mối quan hệ thực thể Mô tả tổ chức liệu ,mô tả liệu lấy đâu sử dụng Mô hình liệu thành lập mô tả mối quan hệ liệu tương ứng quy định mối quan hệ Sử dụng Business rules để phương pháp xử lí liệu Nhóm 3-Phân tích yêu câầu phâần mêầm 05/20/17 Architecture-Oriented Approach  Là phương pháp phân tích thiết kế có cấu trúc • Các yêu cầu hệ thống đích phát triển phân tích việc đặc biệt ý tới chức hệ thống luồng liệu chức • Mục đích phương pháp chuyển tiến trình biểu đồ thành modules chương trình tiến hành phân chia modules cách tiếp cận từ xuống Nhóm 3-Phân tích yêu câầu phâần mêầm 05/20/17 Architecture-Oriented Approach • Lựa chọn kiến trúc công nghệ phần mềm để thực toán • Áp dụng phương pháp Prototyping để nhanh chóng xây dựng phần mềm • Sử dụng Pattern kiến trúc mẫu để phương pháp xử lý liệu Nhóm 3-Phân tích yêu câầu phâần mêầm 05/20/17 Điểm mạnh, điểm yếu phương pháp tiếp cận Nhóm 3-Phân tích yêu câầu phâần mêầm 05/20/17 4.1 Process-Oriented Approach Điểm mạnh: • Thích hợp với toán phức tạp • Giảm thời gian đáp ứng phần mềm tập trung vào giải thuật xử lí liệu • Tránh trùng lặp sở liệu  Điểm yếu: • Khó điều chỉnh yêu cầu cho nhiều người dùng • Sử dụng chức chồng chéo khó tránh khỏi Kết hệ thống có nhiều chức chồng chéo nhân tố làm cho việc bảo trì trở nên khó khăn • Các tệp liệu xây khó để thỏa mãn phần mềm Nhóm 3-Phân tích yêu câầu phâần mêầm 05/20/17 4.2 Data-Oriented Approach Điểm mạnh: • Thích hợp với hệ thống quản lí sở liệu • Không phụ thuộc vào chức yêu cầu người sử dụng thiết kế liệu tách bạch • Biểu diễn đươc mối quan hệ bảng liệu với Điểm yếu: • Việc xử lí liệu không linh hoạt phụ thuộc vào Business rules • Các chức phần mềm phụ thuộc vào cách tổ chức sở liệu Nhóm 3-Phân tích yêu câầu phâần mêầm 05/20/17 10 Mô hình RUP (Rational Unified Process) • Được áp dụng rộng rãi nhờ tính thích nghi Bài • Tìm KPA Requirement Engineering • Vẽ sơ đồ biểu diễn mối quan hệ • Mô tả ngắn gọn nội dung KPA Định nghĩa Requirement Engineering Requirement Engineering (quy trình yêu cầu phần mềm) chế thích hợp để hiểu khách hàng muốn gì, phân tích yêu cầu, đánh giá tính khả thi, đàm phán giải pháp hợp lí, xác định giải pháp rõ ràng, xác nhận yêu cầu kĩ thuật quản lí yêu cầu chúng chuyển thành hệ thống hoạt động Requirement Engineering Document: What system do?  Requirement Development (Phát triển yêu cầu) • + Requirement Elicitation (Phát yêu cầu) • + Requirement Analysis (Phân tích yêu cầu) • + Requirement Specification (Đặc tả yêu cầu) • + Requirement Verification (Kiểm thử yêu cầu)  Requirement Management (Quản lí yêu cầu) Các KPA bản của Requirement Engineering Sơ đồ mối quan â trình hoạt đô n â g KPA Làm viêâc vơi khách hàng Cââp nhâât Làm viêâc vơi khách hàng Các KPA Requirement Development (Phát triển yêu cầu) Phát triển yêu cầu giai đoạn xác định yêu cầu khách hàng hệ thống, sản phẩm cho yêu cầu sở Các KPA Requirement Elicitation (Phát yêu cầu) Phát yêu cầu trình thu thập tài liệu hóa nhu cầu bên liên quan, xác định yêu cầu tài nguyên thu thập thông tin, tài liệu cần thiết khác • Phỏng vấn khách hàng • Quan sát người dùng thực công việc họ • Nghiên cứu kịch bản làm việc • Tổ chức hôâi thảo • Kiểm tra báo cáo vấn đề • Tái sử dụng yêu cầu Xác định yêu cầu trình phát triển • Xác định tầm nhìn và phạm vi • Xác định lớp người dùng • Xác định tiêu chí sản phẩm • Xác định trường hợp ca sử dụng • Xác định kiện hệ thống và đáp ứng Các KPA Requirement Analysis (Phân tích yêu cầu)  Phân tích liệu thu từ Phát yêu cầu Giải xung đột  Phân tích luật thương mại  Tài liệu hóa giả định, ràng buộc phụ thuộc, Làm việc với bên liên quan để tạo lập ưu tiên ban đầu Các KPA Requirement Specification (Đặc tả yêu cầu) UML Các yêu cầu Mô hình hóa tiến trình Các văn bản chức & Xác định bổ trợ Các bảng khung v.v Các KPA Các KPA Requirement Verification (Kiểm thử yêu cầu) Kiểm thử yêu cầu trình xem xét lại đặc tả yêu cầu minh họa trực quan kèm với bên liên quan để xác định thuộc tính chất lượng hoàn thiện, phù hợp, rõ ràng, tính thực tiễn… • Kiểm tra tài liệu yêu cầu • Kiểm tra yêu cầu • Xác định tiêu chí chấp nhận • Tạo mẫu thử • Kiểm tra chấp nhâân • Đảm bảo kĩ sư phần mềm hiểu rõ tất cả yêu cầu • Đảm bảo yêu cầu đưa khách hàng chấp nhâân Các KPA Requirement Management (Quản lí yêu cầu)  Xác định giới hạn phần mềm (Requirement baseline)  Duyệt lại giới hạn phần mềm  Quản lý thay đổi yêu cầu phần mềm (Requirement Changes) Các KPA Requirement Management (Quản lí yêu cầu)      Xác định trình kiểm soát thay đổi yêu cầu Thành lập ban kiểm soát thay đổi Phân tích tác động thay đổi yêu cầu Thiết lập đường sở kiểm soát phiên yêu cầu Duy trì lịch sử yêu cầu thay đổi Cảm ơn thầy và bạn lắng nghe