Bài giảng Phân tích và thiết kế hướng đối tượng: Mô hình hóa đối tượng - Đỗ Ngọc Như Loan

Sử dụng những kỹ thuật mang tính hệ thống để đảm bảo yêu cầu:.. Complete ( đầ y đủ ).[r]

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

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

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

Các kỹ năng

Mô hình hoá đối tượng

Class & Class Diagram

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

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

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)

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

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ó

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

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

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ì

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

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

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ó

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 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 ???

Nguồn các yêu cầu: các chuẩn

Các chuẩn và các hệ thống chuyển đổi

System standard, file formats, network protocols Usability standards

Domain standards

Official standards

written by a standards body written by a standards body

• ANSI

• ISO (e.g Unicode)

• IEEE (e.g Posix)

Industry standards

Java, Dot-Net Wimp user interface WAMP, LAMP

Các loại yêu cầu

Chức năng Features User interface Input/Output Phi chức nă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

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 đề

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 đủ

Tăng chi phí do yêu cầu sai hoặc thiếu sót

0.1 0.5 1

Requirements

Design

Coding

2 5 20

Unit testing

Acceptance - testing

Maintenance

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

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

Chất lượng của yêu cầu: tính ổn định

Ổn định

Khó đảm báo vì

Bản chất VĐ: mâu thuẫn có thể dẫn đến mọi thứ …

Vấn đề

Chất lượng yêu cầu: có thể quản lý được

Tài nguyên phải có thể đáp ứng các yêu cầu

Quản lý rủi ro

Quản lý độ phức tạp

Chất lượng yêu cầu: sự đặc tả

Càng chính xác và chi tiết càng tốt

Không tốt

“program shall be fast”

“it takes a number as input”

Tốt

“program shall give a response in less than 1s”

“program shall give a response in less than 1s”

“it takes a 16-bit signed integer as input”

Những định nghĩa

Vd: “by 'Number', we always mean a 16-bit signed integer”

Qui tắc định nghĩa

Chất lượng yêu cầu không thiên về cài đặt

Thiên về cài đặt:

Sử dụng những thuật ngữ chuyên môn

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”