Bài giảng Phân tích và thiết kế hướng đối tượng - Bài 1: Bài mở đầu - Đỗ Ngọc Như Loan

1 – Bài mở đầu 
GV: Phan Thị Kim Loan 
Bài mở đầu 
Đỗ Ngọc Như Loan 
1 – Bài mở đầu 
Nội dung 
2 
 Giới thiệu 
 Tiến trình phát triển hệ thống 
 Các phương pháp phát triển hệ thống 
1 – Bài mở đầu 
Hiện trạng cuộc sống 
 Thế giới phụ thuộc vào sự phát triển công nghệ 
 Yêu cầu sự phát triển của công nghệ phần mềm 
 Các ứng dụng của công nghệ phần mềm: càng ngày càng 
được mở rộng và phức tạp hơn 
 Nhu cầu thị trường tăng: đòi hỏi tăng năng suất, nâng cao 
chất lượng nhưng lại giảm thiểu thời gian. 
 Tuy nhiên lại thiếu nguồn nhân lực thực sự có trình độ. 
3 
1 – Bài mở đầu 
Thống kế về các dự án phần mềm 
4 
 The Robbins-Gioia Survey (2001) 
 Khảo sát trên 232 người làm việc tại các công ty đang triển khai hệ 
thống ERP. 51%: không thành công. 49% còn lại (46% không thể 
nâng cấp) 
 The KPMG Canada Survey (1997) 
 Khảo sát trên 1450 phiếu khảo sát, phân tích 176 trường hợp. 
 61% các dự án được xem là thất bại 
 Hơn 1/3 các dự án vượt quá ngân sách ước tính ban đầu. 
 Thất thoát ngân sách cho các dự án công nghệ thông tin hàng năm 
lên đến hàng tỷ đôla. Canada ($25 billion per year) 
1 – Bài mở đầu 
Thống kê về các dự án phần mềm 
5 
 The Chaos Report (1995) 
 365 người trả lời đại diện cho 8380 ứng dụng 
 31.1% hủy bỏ 
 52.7% vượt quá ngân sách ước tính ban đầu 
189%. 
 16.2% kịp tiến độ trong ngân sách cho phép 
 The OASIG Study (1995) 
 7 trong 10 IT projects thất bại vì nhiều lý do 
Theo nguồn thống kê của Ó IT Cortex 
1 – Bài mở đầu 
Những thách thức 
 Thách thức 
 Công nghệ thay đổi nhanh 
 Công việc phát triển phần mềm là công việc tập thể 
 Sự chuyên môn hoá và cách thức làm việc phân tán 
 Kết luận: 
 1 IT Project: Tỷ lệ thất bại nhiều hơn thành công 
 Chỉ 1 trong 5 dự án thì thực sự đáp ứng được nhu cầu 
 Dự án càng lớn khả năng thất bại càng cao. 
 Có thành công nhưng quá nhiều thất bại 
6 
1 – Bài mở đầu 
Vấn đề phát sinh trong phát triển HT 
 Hiểu không đúng những gì người dùng cần 
 Không thể thích ứng với các thay đổi về yêu cầu của hệ thống 
 Các Module không khớp với nhau 
 Phần mềm khó bảo trì và nâng cấp, mở rộng 
 Phát hiện trễ các lỗ hổng của dự án 
 Chất lượng phần mềm kém 
 Hiệu năng của phần mềm thấp 
 Các thành viên trong nhóm không biết được ai đã thay đổi cái gì, khi 
nào, ở đâu, tại sao phải thay đổi 
 Quá trình build-and-release không đáng tin cậy 
7 
1 – Bài mở đầu 
Các nguyên nhân cốt lõi 
 Sự quản lý yêu cầu người dùng không đầy đủ 
 Trao đổi thông tin mơ hồ và không đầy đủ 
 Kiến trúc không vững chắc 
 Độ phức tạp vượt quá tầm kiểm soát 
 Có những mâu thuẫn không phát hiện được giữa yêu cầu, thiết kế, 
và cài đặt. 
 Kiểm chứng không đầy đủ 
 Sự lượng giá chủ quan về tình trạng của dự án 
 Sự chậm trễ trong việc giảm rủi ro do mô hình thác nước 
 Sự lan truyền không thể kiểm soát của các thay đổi 
 Thiếu các công cụ tự động hóa 
8 
1 – Bài mở đầu 
Tiến trình phát triển hệ thống 
 Tổng quát Tiến trình (Process) xác định: 
 Who - ai. 
 What - làm gì 
 Where - ở đâu 
 When - làm khi nào 
 How - làm như thế nào để đạt tới mục đích mong muốn. 
 Software Development Process 
 Rational Unified Process - RUP 
9 
1 – Bài mở đầu 
Software Development Life Cycle - SDLC 
10 
1 – Bài mở đầu 
Rational Unified Process - RUP 
11 
Qui trình phát triển phần mềm 
thống nhất: 
Các bước: 
Mô hình hóa nghiệp vụ & 
Lấy yêu cầu 
Phân tích thiết kế 
Thực thi 
Kiểm thử 
Triển khai 
1 – Bài mở đầu 
Tiến trình phát triển hệ thống 
 Lập kế hoạch (Planning) 
 Phân tích yêu cầu (Requirements Analysis) 
 Thiết kế (Design) 
 Phát triển và kiểm tra (Development & Testing) 
 Triển khai và thực hiện (Deployment & Implement) 
 Bảo trì (Maintenance) 
 Nâng cấp (Improvement) 
12 
1 – Bài mở đầu 
Lập kế hoạch (Planning) 
 Xác định giá trị kinh doanh của hệ thống 
 Phân tích tính khả thi 
 Xây dựng kế hoạch công việc 
 Xác định nguồn nhân lực cho dự án 
 Ước lượng chi phí 
 Điều khiển và quản lý dự án 
13 
1 – Bài mở đầu 
Phân tích yêu cầu (Requirements Analysis) 
 Yêu cầu người sử dụng là mục tiêu chính phát triển hệ thống 
 Một thiết kế ban đầu có thể không hoàn chỉnh so với các yêu cầu 
chính 
 Việc phát hiện và bổ sung các thiếu sót trong thiết kế sẽ làm tăng 
giá thành, tốn thời gian hoặc hỏng dự án. 
 Thời gian và chi phí để phát triển một thiết kế sai là không thể bù 
đắp 
14 
1 – Bài mở đầu 
Phân tích yêu cầu (Requirements Analysis) 
 Yêu cầu chức năng mô tả hệ thống phải làm gì (what) nhưng 
không mô tả hệ thống phải làm thế nào (how) 
 Yêu cầu phi chức năng: ràng buộc về thời gian, các hỗ trợ ngôn 
ngữ,  
 Thu thập và phân tích yêu cầu là công việc rất khó khăn 
 Các yêu cầu không hoàn chỉnh 
 Các thuật ngữ trong nhiều lĩnh vực gây khó hiểu 
 Các yêu cầu khách hàng thường thiếu chính xác, thừa, không có cấu trúc và 
thiếu nhất quán 
 Có cả các yêu cầu thiếu tính khả thi. 
15 
1 – Bài mở đầu 
Requirement Management 
16 
Quản lý yêu cầu là một công việc 
 - Quan trọng 
 - Không dễ dàng 
 - Ảnh hưởng đến các giai đoạn khác 
 - Quyết định việc thành bại của PM 
1 – Bài mở đầu 
Phân tích yêu cầu (Requirements Analysis) 
 Mục tiêu: Requirement Specification (RS) 
 Tài liệu đặt tả: 
 Cam kết giữa khách hàng và tổ chức phát triển hệ thống 
 Nguồn nhân lực để phát triển hệ thống 
 Mô hình tương đối hoàn chỉnh về những yêu cầu hệ thống 
 Tiến trình phân tích: 
17 
RS 
Understanding 
Developers 
Requirement 
Capture 
Classification 
Validation 
User 
Feasibility 
Study 
1 – Bài mở đầu 
Thiết kế (Design) 
 Xác định chiến lược thiết kế 
 Xây dựng cấu trúc thành phần 
 Thiết kế giao diện 
 Thiết kế chức năng 
 Thiết kế cơ sở dữ liệu 
 Hồ sơ thiết kế cho cả hệ thống 
18 
1 – Bài mở đầu 
Thiết kế (Design) 
 Tài liệu thiết kế: mô hình kiến trúc 
 Đặt tả thành phần, mô tả các thành phần phải làm gì 
thông qua giao diện. Chủ yếu mô tả “what” 
Thiết kế chi tiết (thực hiện nhiều bước) 
 Mô hình thiết kế chi tiết: 
 Thiết kế chức năng cho mỗi thành phần 
 Thiết kế giao diện cho mỗi thành phần 
 Mô hình hệ thống cốt lõi 
 Cụ thể - phụ thuộc cài đặt – xác định làm thế nào “how” 
19 
1 – Bài mở đầu 
 Development & Testing 
 Mỗi thành phần trong giai đoạn thiết kế được thực hiện thành một 
module của hệ thống 
 Kiểm chứng và thử nghiệm mỗi module theo đặc tả từ thiết kế 
 Lập lại qui trình trên cho đến khi từng module hoàn thiện 
 Tổ hợp các module hệ thống 
 Kiểm tra toàn hệ thống để đảm bảo đáp ứng đúng và đủ yêu cầu đồng 
thời không phát sinh lỗi. 
 Yêu cầu khách hàng thử nghiệm hệ thống 
 Khách hàng chấp nhận sản phẩm Tiến trình này đã hoàn tất 
20 
1 – Bài mở đầu 
Deployment & Implement 
 Lên kế hoạch triển khai hệ thống 
 Các báo cáo và tài liệu đính kèm 
 Có kế hoạch tập huấn sử dụng cho khách hàng hay không 
 Kế hoạch và thời gian bảo hành hệ thống 
 Hỗ trợ kèm theo hệ thống? 
 Nhận phản hồi của đối tác ra sao 
 Cài đặt hệ thống 
21 
1 – Bài mở đầu 
Maintenance & Improvement 
 Bảo trì: 
 Sau khi hệ thống được cài đặt và sử dụng thực tế 
 Bảo vệ và duy trì cho hệ thống hoạt động 
 Sửa các lỗi phát sinh (lỗi hệ thống hay lỗi do người sử dụng) 
 Tính chi phí bảo trì bảo dưỡng hệ thống 
 Nâng cấp: gồm 
 Bổ sung chức năng 
 Thay đổi mới do nâng cấp phần cứng hay các phần mềm khác 
có liên quan 
22 
1 – Bài mở đầu 
Các giai đoạn thiết kế và kết quả 
23 
Process Product 
Planning 
Requirement Analysis 
Design 
Development & Testing 
Deploy& Implement 
Maintenance & Improve 
Project Plan 
Requirement Specification 
System Specification 
Testing -System 
New System, Maintenance Plan 
Improved System 
1 – Bài mở đầu 
Software development Methodologies 
 1970s Structured programming 
 1980s Structured Systems Analysis and Design Methodology (SSADM) 
 1990s Object-oriented programming (OOP) phát triển từ những năm đầu 1960s, 
và phát triển như phương pháp lập trình suốt giữa thập niên 1990s. 
 Rapid application development (RAD) từ 1991. 
 Scrum (development), từ cuối 1990s 
 Team software process bởi Watts Humphrey tại SEI 
 2000s Extreme Programming 
 Rational Unified Process (RUP) từ 1998. 
 Agile Unified Process (AUP) từ 2005 bởi Scott Ambler 
 Integrated Methodology từ 2007 
24 
1 – Bài mở đầu 
Software development approaches 
 Thiết kế cấu trúc (Structured design) 
 Phương pháp thác nước (waterfall method) 
 Phương pháp phát triển song song (Parallel development) 
 Phương pháp dạng Spiral 
 Phương pháp phát triển nhanh ứng dụng (RAD - ) 
 Phương pháp phát triển theo các pha 
 Phương pháp xây dựng nguyên mẫu (prototyping) 
• Thông thường (regular) 
• Loại bỏ (throwaway) 
 Phương pháp phát triển linh động (Agile development) 
 XP (extreme programming) 
25 
1 – Bài mở đầu 
Software development approaches 
26 
 Object-Oriented Analysis and Design - OOAD 
 Use-case Diagram 
 Class Diagram 
 Object Diagram 
 State Diagram 
 Transition Diagram 
 Interaction Diagram 
 Module Diagram 
 Process Diagram 
 Integrated Methodology Software Development 
1 – Bài mở đầu 
Structured Design 
 Dự án sẽ tiến triển từ bước này sang bước tiếp theo một 
cách có hệ thống 
 Thông thường, một bước phải được hoàn thành trước khi 
bắt đầu bước tiếp theo 
27 
1 – Bài mở đầu 
Waterfall method 
28 
Waterfall method 
Time 
Qui trình tháp nước nhiều rủi ro 
1 – Bài mở đầu 
Ứng dụng tháp nước theo vòng lập 
 Các vòng lặp đầu dành cho các vấn đề nhiều rủi ro 
 Mỗi vòng lặp sinh ra một phiên bản với một sự bổ sung cho 
hệ thống 
 Mỗi vòng lập bao gồm cả việc tích hợp và kiểm chứng 
 29 
Iteration 3 Iteration 2 Iteration 1 
Time 
1 – Bài mở đầu 
Qui trình lập 
 Các rủi ro chính được giải quyết trước khi có các phát triển lớn 
 Các vòng lặp đầu tiên cho phép nhận feedback 
 Việc kiểm chứng và tích hợp diễn ra liên tục 
 Các cột mốc cục bộ sẽ định ra các tiêu điểm ngắn hạn 
 Sự tiến triển được đo bằng bản cài đặt 
 Các cài đặt bộ phận có thể triển khai riêng 
30 
TIME 
R
IS
K
Tháp nước tuần tự Tháp nước cải tiến 
TIME 
R
IS
K
Iteration Iteration Iteration 
Iteration 
Giảm rủi ro 
1 – Bài mở đầu 
Phương pháp thác nước 
 Ưu điểm: 
 Trước khi lập trình thì các yêu cầu về hệ thống được xác định 
rất chi tiết và đầy đủ => giảm thiểu được sự thay đổi về yêu 
cầu trong quá trình phát triển hệ thống 
 Nhược điểm: 
 Thời gian từ khi đề xuất dự án đến khi có sản phẩm cuối cùng 
thường rất dài (vài tháng -> vài năm) 
31 
1 – Bài mở đầu 
Parallel Development 
32 
A Parallel Development-based Methodology 
1 – Bài mở đầu 
Spiral 
 Kết hợp giữa prototyping-in-stages 
và top-down and bottom-up 
 Đánh giá và giảm thiểu rủi ro bằng 
cách tách nhỏ các phân đoạn thay 
vì quản lý trên toàn bộ dự án 
 Mỗi vòng xoắn ốc đi qua: 
 Phân tích mục tiêu, lựa chọn thay thế. 
 Đánh giá các lựa chọn thay thế, xác 
định và giải quyết các rủi ro. 
 Phát triển từ các iteration 
 Kế hoạch được lặp tiếp theo 
33 
Bắt đầu mỗi chu kỳ với: các bên liên quan xác định mục đích và kết quả cần thoả 
Kết thúc mỗi chu kỳ: xem xét và cam kết của các bên 
1 – Bài mở đầu 
Rapid Application Development (RAD) 
Các nhân tố quan trọng: 
 Công cụ CASE (Computer Aided Software Engineering ) 
 JAD (Joint Application Development ) 
 Ngôn ngữ lập trình thế hệ thứ tư/ visual 
 Công cụ tạo mã 
34 
1 – Bài mở đầu 
Phương pháp phát triển theo pha 
35 
1 – Bài mở đầu 
Software prototyping 
36 
1 – Bài mở đầu 
Phương pháp xây dựng nguyên mẫu loại bỏ 
37 
1 – Bài mở đầu 38 
Agile Development 
Là phương pháp phát triển lặp 
Cố định thời gian của từng vòng 
lặp 
Đưa ra các sản phẩm (release) 
theo hướng tiến hóa dần 
Có kế hoạch thích hợp (không phải 
cố định), sẵn sàng cho mọi sự thay 
đổi nếu có xảy ra. 
1 – Bài mở đầu 
Lựa chọn phương pháp phù hợp 
Tiêu chí: 
 Độ rõ ràng, đầy đủ của các yêu cầu của 
người sử dụng 
 Khả năng, mức độ thành thạo về công nghệ 
 Độ phức tạp của hệ thống 
 Độ tin cậy của hệ thống 
 Quỹ thời gian 
 39 
1 – Bài mở đầu 
Lựa chọn phương pháp phù hợp 
40 
Criteria for Selection a Methodology