Nội dung

Mô hình hóa đối tượng Nội dung trước Mô hình hóa yêu cầu: Lược đồ Use-case Khái niệm Actor và Usecase Ví dụ Mô hình hóa các dòng dữ liệu của mỗi Use-case Giới thiệu Mô hình DFD Sử dụng mô hình DFD để mô hình hóa yêu cầu lưu trữ, tra cứu, tính toán, kết xuất 4 – Mô hình hóa đối tượng– Class Diagram 2 Nội dung Quản lý yêu cầu: Giới thiệu Chi tiết quản lý yêu cầu Các kỹ năng Mô hình hoá đối tượng Class & Class Diagram 4 – Mô hình hóa đối tượng– Class Diagram 3 Giới thiệu Một trong những hoạt động đầu tiên Mục tiêu: tìm cái cần xây dựng Giao tiếp giữa người dùng và người phát triển, vì vậy Không có ký hiệu phức tạp (ngoại trừ trong lĩnh vực chuyên môn) Thường dùng ngôn ngữ tự nhiên Hợp đồng Các cách thức để xác định yêu cầu Các cách thức để chuẩn hóa yêu cầu Scenarios, Use Cases, Mockups / Prototypes, Feature, Lists Stakeholders Những người quan tâm đến sản phẩm 4 – Mô hình hóa đối tượng– Class Diagram 4 Thế nào là quản trị yêu cầu Là tiến trình tìm hiểu, sưu liệu và quản lý các yêu cầu. Sử dụng những kỹ thuật mang tính hệ thống để đảm bảo yêu cầu: Complete (đầy đủ) Consistent (nhất quán) Relevant (thích đáng) 4 – Mô hình hóa đối tượng– Class Diagram 5 Thế nào là quản trị yêu cầu Diễn tả bằng văn xuôi, Tìm hiểu cái người dùng muốn Tổ chức thông tin này lại Sưu liệu thông tin này Theo vết thay đổi thông tin này Quản lý tất cả thay đổi Đáp ứng nhu cầu người dùng cuối Thiết lập quy trình và thực hiện theo nó 4 – Mô hình hóa đối tượng– Class Diagram 6 Thế nào là quản trị yêu cầu Hầu hết các tổ chức phát triển phần mềm đều làm việc này theo những cách thức khác nhau. Nhưng thường chúng không mang tính hình thức và mang tính không thống nhất từ dự án này qua dự án khác CMM Level 1 vs. CMM Level 2 = Định nghĩa được tiến trình quản lý yêu câu 4 – Mô hình hóa đối tượng– Class Diagram 7 Thế nào là một yêu cầu Là một khả năng của phần mềm được người dùng yêu cầu, để giải quyết một vấn đề nhằm đạt một mục tiêu nào đó Thành công của dự án = thoả mãn các yêu cầu 4 – Mô hình hóa đối tượng– Class Diagram 8 Nguồn yêu cầu: Khách hàng Phỏng vấn khách hàng Người trả tiền cho chúng ta Những stakeholders • Người sử dụng • Người quản lý Vấn đề: Khách hàng có thể không biết họ muốn gì • Phần mềm là một khái niệm trừu tượng và phức tạp KH có thể thay đổi ý kiến KH không có khả năng diễn tả nhu cầu theo những thuật ngữ chuyên môn • Giao tiếp giữa người chuyên làm p.mềm <> người bình thường Các kỹ thuật Giao diện & Hệ thống đã tồn tại 4 – Mô hình hóa đối tượng– Class Diagram 9 Nguồn yêu cầu: thị trường Đánh giá các sản phẩm cạnh tranh Những gì trước đây đã thực hiện? Nơi nào là nơi thích hợp cho chúng ta Lưu ý vấn đề bản quyền, thương hiệu sáng chế Tự đánh giá khả năng của chúng ta Chúng ta có thể làm gì tốt hơn đối thủ cạnh tranh Những kiến thức, kỹ năng, ý tưởng mà chúng ta có 4 – Mô hình hóa đối tượng– Class Diagram 10