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



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


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


Nguồn yêu cầu: thị trường
Khảo sát thị trường
Phỏng vấn khách hàng (cũ, tiềm năng, …)
Lưy ý tới những quảng cáo, tạo nhu cầu thị trường
Quan tâm tới xu hướng phát triển của thị trường

Vấn đề
Người ta không biết người ta muốn gì?
Thị trường thay đổi rất nhanh
Bảo mật ý tường ???

Phi chức năng
Hướng người dùng
• Performance, Precision, Reliability

Hướng người phát triển
• Maintainability, Reusability, Interoperability

4 – Mô hình hóa đối tượng– Class Diagram

13


Những vấn đề quản trị yêu cầu
Nhiều hệ thống thường
Chuyền giao trễ và vượt ngân sách cho phép
Không đáp ứng đầy đủ yêu cầu người dùng
Không hoạt động hiệu quả

Bước đầu tiên để giải quyết vấn đề
xác định nguyên nhân cốt lõi

Ví dụ về những nguyên nhân cốt lõi
Thiếu dữ liệu người dùng
Yêu cầu đặc tả không đầy đủ
Yêu cầu và đặc tả thay đổi
4 – Mô hình hóa đối tượng– Class Diagram

14




Thế nào là quản trị yêu cầu tốt
Ngăn:
Vượt chi phí và thời gian
Huỷ dự án

Một dự án thành công cần các yếu tố:
Sự quan tâm của người dùng
Hỗ trợ của người quản lý
Yêu cầu rõ ràng

4 – Mô hình hóa đối tượng– Class Diagram

16


Chất lượng của yêu cầu: tính ổn định
Ổn định
Không có mâu thuẫn
Chương trình sẽ không thể hoạt động nếu yêu cầu
mâu thuẫn
Khó đảm báo vì
Số lượng yêu cầu lớn
Mâu thuẫn tiềm ẩn
Bản chất VĐ: mâu thuẫn có thể dẫn đến mọi thứ …
Vấn đề
Khó giải thích mâu thuẫn cho khách hàng
Khách hàng muốn những thứ không thể
4 – Mô hình hóa đối tượng– Class Diagram


Những định nghĩa
Luôn là những ý tưởng tốt
Vd: “by 'Number', we always mean a 16-bit signed
integer”
Qui tắc định nghĩa
Không định nghĩa xoay vòng (phụ thuộc)
4 – Mô hình hóa đối tượng– Class Diagram

19


Chất lượng yêu cầu không thiên về cài đặt
Thiên về cài đặt:
Đưa thông tin thiết kế
Đưa thông tin về mã nguồn
Sử dụng những thuật ngữ chuyên môn
Không dùng từ ngữ chuyên môn kỹ thuật
Bạn muốn tập trung vài CÁI GÌ
Bỏ LÀM THẾ NÀO lại phần sau
Ví dụ không tốt
“store the checked-out books in an array”
“calculate the square root with Newton's algorithm”

Ví dụ tốt
•“the library knows which books are checked out”
“return the square root with 5-digit precision”
4 – Mô hình hóa đối tượng– Class Diagram

20