Tài liệu tham khảo

Thông thường, các chuyên gia CNTT có mối liên hệ với nhiều nhà cung cấp phần cứng, phần mềm và các dịch vụ khác nhau, họ cũng hiểu rằng việc xây dựng mối quan hệ tốt với các nh[r]

(1)

MỤC LỤC

MỤC LỤC

DANH MỤC BẢNG BIỂU

DANH MỤC HÌNH ẢNH 10

Hình 8-1 Chi phí việc phát triển phần mềm khơng có phương pháp 169THUẬT NGỮ VIẾT TẮT 12 LỜI NÓI ĐẦU 14

Chương 1: MỞ ĐẦU 15

1.1 LỊCH SỬ HÌNH THÀNH VÀ PHÁT TRIỂN 15

1.1.1 Q trình tiến hóa phần mềm 15

1.1.2 Sự đời công nghệ phần mềm 16

1.2 MỘT SỐ KHÁI NIỆM CƠ BẢN TRONG LĨNH VỰC CÔNG NGHỆ PHẦN MỀM 17

1.2.1 Khái niệm phần mềm 17

1.2.2 Khái niệm công nghệ phần mềm 18

1.2.3 Sự khác giữa cơng nghệ phần mềm và khoa học máy tính 18

1.2.4 Tiến trình phần mềm 18

1.2.5 Mơ hình tiến trình phần mềm 19

1.2.6 Chi phí cơng nghệ phần mềm 20

1.2.7 Phương pháp công nghệ phần mềm 20

Bảng 1.1 Các thành phần mơ hình hệ thống 20

1.2.8 CASE - Các công cụ công nghệ phần mềm 21

1.2.9 Những tḥc tính phần mềm tớt 21

Bảng 1.2 Các thuộc tính phần mềm 21

1.2.10 Những thách thức bản lĩnh vực phát triển phần mềm 22

1.3 MỘT SỐ VẤN ĐỀ VỀ ĐẠO ĐỨC CỦA CÁC CHUYÊN GIA CNTT 22

1.3.1 Những mối quan hệ cần phải quản lý chuyên gia công nghệ thông tin 23

1.3.2 Những quy tắc đạo đức chuyên gia CNTT 25

CÂU HỎI ÔN TẬP 27

Chương 2: TIẾN TRÌNH PHẦN MỀM 28

(2)

2.3.1 Đặc tả phần mềm 37

2.3.2 Thiết kế và thực thi phần mềm 38

2.3.3 Thẩm định phần mềm 40

2.3.4 Cải tiến phần mềm 42

2.4 RUP – TIẾN TRÌNH SẢN XUẤT PHẦN MỀM CỦA RATIONAL 42

2.5 KỸ NGHỆ PHẦN MỀM CÓ MÁY TÍNH TRỢ GIÚP (CASE) 44

Chương 3: QUẢN LÝ DỰ ÁN PHẦN MỀM 46

3.1 CÁC KHÁI NIỆM CƠ BẢN 46

3.1.1 Khái niệm dự án 46

3.1.2 Các đặc trưng dự án 47

3.1.3 Quản lý dự án 47

3.2 QUẢN LÝ DỰ ÁN THEO PHƯƠNG PHÁP PHÁT TRIỂN TRUYỀN THỐNG 48

3.2.1 Các hoạt động quản lý dự án 48

3.2.2 Lập kế hoạch dự án 49

Bảng 3.1 Các kiểu kế hoạch cần cho dự án 50

a) Tiến trình lập kế hoạch dự án 50

b) Cấu trúc kế hoạch dự án 51

c) Các mốc quan trọng sản phẩm bàn giao 52

3.2.3 Lập lịch dự án 52

a) Tiến trình lập lịch 52

3.2.4 Phương pháp công cụ lập lịch 53

Bảng 3-2 Bảng liệt kê công việc dự án đánh dấu 54

Bảng 3.3 Bảng phân công công việc 58

3.3 QUẢN LÝ RỦI RO ĐỐI VỚI DỰ ÁN PHÁT TRIỂN PHẦN MỀM 58

3.3.1 Khái niệm rủi ro 58

Bảng 3.4 Bảng phân loại rủi ro 59

3.3.2 Tiến trình quản lý rủi ro 59

a) Xác định rủi ro 60

Bảng 3.5 Bảng đánh giá số tình rủi ro 61

Rủi ro 61

Khả xảy 61

Ảnh hưởng 61

Vấn đề tài chính của tổ chức gặp khủng hoảng và phải giảm ngân sách cho dự án 61

Thấp 61

Rất nghiêm trọng 61

Không thể thành lập một đội ngũ nhân viên có những kỹ theo yêu cầu 61

(3)

Rất nghiêm trọng 61

Những nhân viên quan trọng bị ốm và không thể làm việc tại những thời điểm quan trọng 61 Trung bình 61

Nghiêm trọng 61

Các thành phần phần mềm được sử dụng lại có chứa những khuyết điểm làm hạn chế khả của hệ thống 61

Trung bình 61

Nghiêm trọng 61

Việc thay đổi yêu cầu đòi hỏi phải thiết kế lại những công việc chính 61

Trung bình 61

Nghiêm trọng 61

Tổ chức được cấu trúc lại và thay đổi người quản lý dự án 61

Cao 61

Nghiêm trọng 61

Cơ sở dữ liệu sử dụng hệ thống không thể xử lý nhiều giao dịch tại cùng một thời điểm 61

Thấp 61

Khủng khiếp 61

Ước lượng: thời gian cần thiết để phát triển quá ngắn 61

Cao 61

Nghiêm trọng 61

Bảng 3.6 Các yếu tố rủi ro 62

3.4 KẾT THÚC DỰ ÁN 63

3.5 CẤU TRÚC TÀI LIỆU QUẢN LÝ DỰ ÁN 63

Chương 4: XÁC ĐỊNH VÀ ĐẶC TẢ YÊU CẦU PHẦN MỀM 65

4.1 TỔNG QUAN VỀ YÊU CẦU PHẦN MỀM 65

4.1.1 Khái niệm yêu cầu phần mềm 65

4.1.2 Phân loại yêu cầu phần mềm 66

(4)

Thời gian trả lời một sự kiện/người dùng 70

Thời gian làm mới màn hình 70

Kích thước 70

M Bytes 70

Dung lượng bộ nhớ ROM/RAM 70

Tính dễ sử dụng 70

Thời gian huấn luyện 70

Số màn hình trợ giúp 70

Độ tin cậy 70

Thời gian trung bình kiểm soát lỗi 70

Phần trăm thời gian hệ thống không thực hiện 70

Tỷ lệ lỗi xảy 70

Tính sẵn sàng 70

Sức kháng cự 70

Thời gian để khởi động lại sau một lỗi 70

Phần trăm của các sự kiện phát sinh lỗi 70

Xác suất của việc sai lệch dữ liệu có lỗi 70

Tính khả chuyển 70

Lựa chọn ngôn ngữ cho giao diện phần mềm 70

Lựa chọn hệ thống cho việc cài đặt phần mềm 70

HÌNH 4.4 VÍ DỤ VỀ CÁC YÊU CẦU PHI CHỨC NĂNG 71

4.2 TIẾN TRÌNH KỸ NGHỆ YÊU CẦU 72

4.2.1 Khảo sát hệ thớng phân tích tính khả thi 72

4.2.2 Tiến trình phát phân tích yêu cầu 72

4.2.3 Các phương pháp phát yêu cầu 74

4.2.4 Các kỹ thuật phân tích yêu cầu 76

A) TIẾP CẬN YÊU CẦU ĐỊNH HƯỚNG CÁCH NHÌN (VIEWPOINT) 76

B) KỸ THUẬT XÁC ĐỊNH YÊU CẦU HƯỚNG CÁCH NHÌN VORD (VIEWPOINT ORIENTED REQUIREMENT DEFINITION) 77

C) KỸ THUẬT PHÂN TÍCH U CẦU DỰA TRÊN MƠ HÌNH 77

D) CÁC CÁCH BIỂU DIỄN CỦA MƠ HÌNH PHÂN TÍCH 79

Bảng 4.2 Biểu diễn mơ hình nghiệp vụ theo cách tiếp cận 79

(5)

A) VÍ DỤ PHÂN TÍCH HƯỚNG CẤU TRÚC 80

HÌNH 4.7 BIỂU ĐỒ NGỮ CẢNH CỦA HỆ THỐNG 80

Bảng 4.3 Danh sách hồ sơ liệu sử dụng 80

81

Bảng 4.4 Mô tả chi tiết chức rút tiền 81

4.3 ĐẶC TẢ YÊU CẦU PHẦN MỀM 82

4.3.1 Khái niệm 82

4.3.2 Các phương pháp đặc tả 83

4.3.3 Cấu trúc tài liệu đặc tả 84

Chương 5: UML – XÂY DỰNG VÀ THIẾT KẾ CÁC MƠ HÌNH HỆ THỐNG 87

5.1 GIỚI THIỆU VỀ UML 87

5.1.1 Mơ hình hóa hệ thớng phần mềm 87

5.1.2 Lịch sử hình thành và phát triển 88

5.1.2 UML và giai đoạn phát triển hệ thống 89

5.2 MỘT SỐ MƠ HÌNH UML DÙNG TRONG PHÂN TÍCH VÀ THIẾT KẾ 89

5.2.1 Mơ hình ngữ cảnh 89

5.2.2 Mơ hình trường hợp sử dụng (USE-CASE) 91

Bảng 5.1 Bảng thông tin mô tả Use-case 93

5.2.3 Mơ hình lớp đới tượng 93

5.2.4 Mơ hình (Sequence diagram) 98

5.2.5 Mơ hình trạng thái máy 100

Chương 6: THIẾT KẾ PHẦN MỀM 103

(6)

c Biểu diễn thiết kế 107

d Các giai đoạn thiết kế 107

6.1.3 Các chiến lược và phương pháp thiết kế 108

a Thiết kế hướng chức 108

b Thiết kế hướng đối tượng 109

6.1.4 Chất lượng thiết kế và giải pháp đảm bảo chất lượng 109

a Sự kết dính 109

b Sự ghép nối 110

c Tính hiểu 111

d Sự thích nghi 112

e Một số hướng dẫn thiết kế 112

6.2.1 Khái niệm – tầm quan trọng thiết kế kiến trúc 114

a Khái niệm 114

b Vai trò tầm quan trọng kiến trúc 114

c Kiến trúc đặc điểm hệ thống 114

6.2.2 Các định thiết kế kiến trúc 115

a Tái sử dụng mẫu kiến trúc 116

b Phát triển sử dụng mơ hình kiến trúc 116

6.2.3 Tổ chức hệ thớng 117

a Mơ hình kho liệu 117

b Mơ hình máy khách/chủ (client/server) 118

c Mơ hình máy ảo/phân tầng 119

6.2.4 Các mơ hình điều khiển 121

a Điều khiểu tập trung 121

b Mơ hình điều khiển dựa kiện 123

6.2.5 Tiến trình thiết kế kiến trúc 124

a Cấu trúc hệ thống 125

b Phân chia module 126

6.3 THIẾT KẾ HƯỚNG ĐỐI TƯỢNG 128

6.3.1 Một số đặc điểm bản thiết kế hướng đối tượng 128

a Chiến lược thiết kế hướng đối tượng 128

b Đặc điểm thiết kế hướng đối tượng 128

6.3.2 Đối tượng và lớp đối tượng 129

a Khái niệm đối tượng lớp đối tượng 129

b Trao đổi thông tin lớp đối tượng 129

c Khái quát hóa kế thừa lớp đối tượng 130

6.3.3 Tiến trình thiết kế hướng đới tượng 131

a Giới thiệu hoạt động trạm thời tiết 131

b Mơ hình ngữ cảnh mơ hình sử dụng 132

Bảng 6.1 Mô tả use-case 132

c Thiết kế kiến trúc 133

(7)

e Xây dựng mơ hình thiết kế 136

f Đặc tả giao diện đối tượng 140

6.3.4 Cải tiến và tái sử dụng bản thiết kế 141

Chương 7: KIỂM THỬ PHẦN MỀM 144

7.1 GIỚI THIỆU CHUNG 144

7.1.1 Mục tiêu kiểm thử 145

7.1.2 Tiến trình kiểm thử phần mềm 145

7.2 KIỂM THỬ HỆ THỐNG 147

7.2.1 Kiểm thử tích hợp 147

7.2.2 Kiểm thử phát hành 149

7.2.3 Xây dựng kịch bản kiểm thử hệ thống 150

7.2.4 Kiểm thử hiệu 151

7.3 KIỂM THỬ THÀNH PHẦN 152

7.3.1 Kiểm thử lớp đối tượng 152

7.3.2 Kiểm thử giao diện 153

7.4 THIẾT KẾ TRƯỜNG HỢP KIỂM THỬ (TEST CASE DESIGN) 155

7.4.1 Kiểm thử dựa yêu cầu 155

7.4.2 Kiểm thử phân vùng 156

Bảng 7.1 Các phân hoạch tương đương cho chương trình tìm kiếm 159

7.4.3 Kiểm thử cấu trúc 159

Bảng 7.2 Các trường hợp kiểm thử cho thuật toán tìm kiếm nhị phân 161

7.4.4 Kiểm thử đường (path testing) 161

7.5 CÔNG CỤ KIỂM THỬ TỰ ĐỘNG 162

Chương 8: BẢO TRÌ PHẦN MỀM VÀ QUẢN LÝ THAY ĐỔI 166

8.1 PHÂN LOẠI HOẠT ĐỘNG BẢO TRÌ PHẦN MỀM 166

8.1.1 Bảo trì hiệu chỉnh 166

8.1.2 Bảo trì cải tiến 166

8.1.3 Bảo trì hoàn thiện 166

8.1.4 Bảo trì phịng ngừa 167

8.2 ĐẶC ĐIỂM CỦA BẢO TRÌ PHẦN MỀM 167

8.2.1 Bảo trì có cấu trúc và bảo trì khơng cấu trúc 167

8.2.2 Giá thành bảo trì 168

8.2.3 Mợt sớ khó khăn khác bảo trì 169

(8)

8.5 QUẢN LÝ THAY ĐỔI PHẦN MỀM 176

8.5.1 Các thủ tục quản lý thay đổi 176

8.5.2 Ghi định theo thời gian 178

8.5.3 Quản lý thay đổi tài liệu 178

(9)

DANH MỤC BẢNG BIỂU

Bảng 1-1 Các thành phần mơ hình hệ thớng 15

Bảng 1-2 Các tḥc tính phần mềm 16

Bảng 3-1 Các kiểu kế hoạch cần cho dự án 44

Bảng 3-2 Bảng liệt kê công việc dự án và đánh dấu 49

Bảng 3-3 Bảng phân công công việc 53

Bảng 3-4 Bảng phân loại rủi ro 54

Bảng 3-5 Bảng đánh giá mợt sớ tình huống rủi ro 56

Bảng 3-6 Các yếu tố rủi ro 57

Bảng 4-1 Thước đo định lượng tḥc tính phi chức 64

Bảng 4-2 Cách mơ hình nghiệp vụ theo cách tiếp cận 74

Bảng 4-3 Danh sách hồ sơ dữ liệu sử dụng 75

Bảng 5-1 Bảng thông tin mô tả Use-case 89

Bảng 6-1 Mô tả một use-case 129

(10)

DANH MỤC HÌNH ẢNH

Hình 1-1 Phần trăm chi phí giai đoạn tiến trình phần mềm 16

Hình 2-1 Mơ hình thác nước 25

Hình 2-2 Mơ hình phát triển phần mềm theo kiểu tiến hóa 27

Hình 2-3 Mơ hình phát triển hướng thành phần 28

Hình 2-4 Mơ hình phát triển gia tăng 30

Hình 2-5 Mơ hình xoắn ốc 32

Hình 2-6 Các giai đoạn phân tích u cầu 33

Hình 2-7 Các hoạt đợng tiến trình thiết kế 35

Hình 2-8 Tiến trình kiểm thử 36

Hình 2-9 Kế hoạch kiểm thử kết nối với hoạt động phát triển phần mềm 37

Hình 2-10 Tiến trình cải tiến sản phẩm phần mềm 38

Hình 2-11 Mơ hình tiến trình RUP 39

Hình 3-1 Tiến trình triển khai mợt dự án 44

Hình 3-2 Tiến trình lập kế hoạch thực dự án 47

Hình 3-3 Các cợt mớc tiến trình xác định u cầu 48

Hình 3-4 Tiến trình lập lịch cho hoạt đợng dự án 49

Hình 3-5 Các ký pháp sơ đồ mạng 50

Hình 3-6 Tiến trình lập lịch biểu sơ đồ mạng 50

Hình 3-7 Sơ đồ mạng cơng việc 53

Hình 3-8 Biểu đồ Gantt lịch trình dự án Error! Bookmark not defined Hình 3-9 Biểu đồ khới lịch trình cơng việc Error! Bookmark not defined Hình 3-10 Tiến trình quản lý rủi ro 57

Hình 4-1 Yêu cầu người dùng u cầu hệ thớng 63

Hình 4-2 Đới tượng đọc những tài liệu đặc tả khác 63

Hình 4-3 Các kiểu yêu cầu phi chức 66

Hình 4-4 Ví dụ yêu cầu phi chức 68

Hình 4-5 Tiến trình phát phân tích u cầu Error! Bookmark not defined Hình 4-6 Tiến trình phương pháp VORD 74

Hình 4-7 Biểu đồ ngữ cảnh hệ thớng 77

Hình 4-8 Mô tả yêu cầu một chức sơ cấp 77

Hình 4-9 Ma trận thực thể - chức 78

Hình 4-10 Biểu đồ trường hợp sử dụng mức cao 78

(11)

Hình 4-12 Biểu đồ trường hợp sử dụng mức chi tiết 79

Hình 4-13 Mơ hình miền lĩnh vực hệ thớng ATM 79

Hình 5-1 Sơ đồ ngữ cảnh hệ thống ATM ngân hàng 88

Hình 5-2 Mơ hình tiến trình đặt mua thiết bị 89

Hình 5-3 Biểu đổ USE-CASE hệ thống ngân hàng 90

Hình 5-4 Phân biệt đới tượng và lớp đới tượng 92

Hình 5-5 Mợt lớp với tḥc tính tiêu biểu 93

Hình 5-6 Mợt lớp với tḥc tính chung riêng ERROR! BOOKMARK NOT DEFINED Hình 5-7 Mợt lớp với tḥc tính và giá trị mặc định Error! Bookmark not defined Hình 5-8 Ký hiệu đới tượng Error! Bookmark not defined Hình 5-9 Vai trị liên hệ giữa Customer và Account 94

Hình 5-10 Mợt biểu đồ lớp tiêu biểu 95

Hình 5-11 Khái qt hóa và chun biệt hố 96

Hình 5-12 Biểu đồ kịch bản chức rút tiền mặt máy ATM 97

Hình 5-13 Biểu đồ kịch bản chức rút tiền mặt máy ATM 99

Hình 5-14 Lược đồ trạng thái lị vi sóng Error! Bookmark not defined Hình 6-1 Mơ hình tiến trình thiết kế ERROR! BOOKMARK NOT DEFINED Hình 6-2 Các hoạt đợng thiết kế và sản phẩm chúng Error! Bookmark not defined Hình 6-3 Mơ hình hệ thớng hướng cấu trúc Error! Bookmark not defined Hình 6-4 Hướng dẫn thiết kế tránh chia nhỏ module cố gắng co cụm tăng chiều sâu 111

Hình 6-5 Phạm vi hiệu quả việc kiểm soát module 111

Hình 6-6 Kiến trúc bợ cơng cụ CASE tích hợp ERROR! BOOKMARK NOT DEFINED Hình 6-7 Kiến trúc hệ thống tra cứu ảnh và video số Error! Bookmark not defined Hình 6-8 Mơ hình kiến trúc hệ thớng quản lý cấu hình Error! Bookmark not defined Hình 6-9 Mơ hình gọi – trả lời 120

Hình 6-10 Mơ hình quản lý tập trung cho hệ thống thời gian thực 121 Hình 6-11 Mơ hình điều khiển dựa quảng bá có tuyển chọnERROR! BOOKMARK NOT DEFINED

(12)

Hình 6-18 Mơ hình Use-case trạm khí tượng Error! Bookmark not defined Hình 6-19 Kiến trúc hệ thớng trạm khí tượng 132 Hình 6-20 Các lớp đới tượng hệ thớng trạm khí tượng 134 Hình 6-21 Mơ hình hệ thớng trạm khí tượngERROR! BOOKMARK NOT DEFINED Hình 6-22 Mơ hình phương thức report() hệ thớng trạm khí tượng Error! Bookmark not defined

Hình 6-23 Lược đồ trạng thái đối tượng WeatherStation Error! Bookmark not defined Hình 6-24 Giao diện đới tượng WeatherStation 139 Hình 6-25 Các đới tượng hệ thớng sau bổ xung thiết bị đo độ ô nhiễm 141 Hình 7-1 Các giai đoạn kiểm thử Error! Bookmark not defined

Hình 7-2 Tiến trình kiểm thử phần mềm Error! Bookmark not defined Hình 7-3 Mợt trường hợp tích hợp tăng dần Error! Bookmark not defined Hình 7-4 Mơ hình kiểm thử hợp đen 149 Hình 7-5 Mợt kịch bản mơ tả một chức hệ thống thư viện LIBSYS 150 Hình 7-6 Giao diện đới tượng WeatherStation 152 Hình 7-7 Mơ hình trạng thái đới tượng Weather Station hệ thống trạm thời tiết ERROR! BOOKMARK NOT DEFINED Hình 7-8 Tiến trình kiểm thử giao diện Error! Bookmark not defined Hình 7-9 Phân vùng tương đương Error! Bookmark not defined Hình 7-10 Các phân vùng tương đương 157 Hình 7-11 Đoạn đặc tả chương trình tìm kiếm dãy 158 Hình 7-12 Kiểm thử cấu trúc Error! Bookmark not defined. Hình 7-13 Các lớp tương đương tìm kiếm nhị phân Error! Bookmark not defined Hình 7-14 Thuật tốn tìm kiếm nhị phân Error! Bookmark not defined Hình 7-15 Đồ thị luồng chương trình tìm kiếm nhị phân 162 Hình 7-16 Mơ hình mợt cơng cụ tích hợp kiểm thử 163 Hình 8-1 Chi phí việc phát triển phần mềm khơng có phương pháp Error! Bookmark not

(13)

THUẬT NGỮ VIẾT TẮT

Chữ viết tắt

Chi tiết tiếng Anh Nghĩa tiếng Việt

APSE Ada Programming Support

Environnement

Môi trường hỗ trợ ngôn ngữ lập trình Ada

ATM Automated Teller Machine Máy rút tiền tự động

CASE Computer Aided Software Engineering Công nghệ phần mềm được máy tính

trợ giúp

CNTT Cơng nghệ thơng tin

COST Commercial off-the-shelf Gói phần mềm thương mại

CPM Critical Path Method Phương pháp đường găng

CSDL Cơ sở dữ liệu

ERP Entreprise Resource Planing Quản trị tài nguyên doanh nghiệp

ICSE Internetional Conference of SE Hội thảo quốc tế công nghệ phần

mềm IEEE Institute Electrical and Electronic

Engineers

Viện kỹ nghệ điện và điện tử

OOA Object Oriented Analysis Phân tích hướng đới tượng

OOD Object Oriented Design Thiết kế hướng đối tượng

OOP Object Oriented Programme Lập trình hướng đới tượng

SAP Systems Applications and Products Các hệ thống ứng dụng và sản xuất

SE Software Engineering Công nghệ phần mềm

RUP Rational Unified Process Tiến trình phần mềm hợp

(14)

LỜI NÓI ĐẦU

Sau gần thập kỷ phát triển, công nghệ phần mềm (SE - Software Engineering) đến được xem là một phân ngành quan trọng chuyên ngành công nghệ thông tin

Xuất phát từ cuộc khủng hoảng phần mềm cuối những năm 60, nhà quản lý và chuyên gia công nghệ thông tin nhận nhu cầu cách tiếp cận có nguyên tắc đối với việc phát triển phần mềm Công nghệ phần mềm không đơn là việc sinh mợt sản phẩm phần mềm, mà liên quan đến việc tạo một sản phẩm phần mềm một cách hiệu quả Với những nguồn lực phần mềm không hạn chế, đa sớ vấn đề phần mềm giải Tuy nhiên, thách thức lớn đối với kỹ sư phần mềm là phải tạo mợt sản phẩm có chất lượng cao với chi phí thấp và thời gian phát triển tuân theo mợt lịch trình định trước

Bài giảng này trình bày những vấn đề bản sau công nghệ phần mềm:

1 Những vấn đề công nghệ phần mềm: giới thiệu khái quát lịch sử hình thành và phát triển cơng nghệ phần mềm, những khái niệm bản liên quan đến công nghệ phần mềm

2 Tiến trình phát triển phần mềm: tìm hiểu quy trình và cách thức bản để phát triển phần mềm Nêu những bước phát triển phần mềm: Khảo sát, phân tích hệ thớng và u cầu phần mềm, thiết kế hệ thống và phát triển phần mềm, kiểm thử và bảo trì phần mềm

3 Cơng cụ hỗ trợ hoạt động phát triển phần mềm: Nhấn mạnh trợ giúp đắc lực công cụ phần mềm máy tính cho tiến trình phát triển phần mềm nhằm đạt được suất và chất lượng cao

4 Vấn đề quản lý dự án phần mềm: Tiến trình phát triển dự án phần mềm và việc quản lý mợt cách hiệu quả

Bài giảng này được biên soạn lần đầu để giảng dạy cho sinh viên chuyên ngành tin học quản lý thông tin Học viện Nơng nghiệp Việt Nam Nó cung cấp những kiến thức có tính tảng vấn đề phát triển phần mềm cho những người hoạt động lĩnh vực tin học nói chung cho sinh viên khoa Cơng nghệ thơng tin nói riêng

Tác giả xin chân thành cảm ơn đồng nghiệp khoa Công nghệ thông tin, Học viện Nông nghiệp Việt Nam cho những ý kiến đóng góp để hoàn thiện tài liệu này

Mặc dù cố gắng tham khảo nhiều tài liệu khác nhau, đúc rút từ thực tiễn giảng dạy và nghiên cứu khoa học, tổ chức biên soạn một cách công phu và kỹ càng, bài giảng không tránh khỏi nhiều thiếu sót Tác giả chân thành mong đợi góp ý bạn đồng nghiệp, sinh viên và độc giả để tài liệu ngày càng hoàn thiện

Mọi ý kiến đóng góp xin gửi địa chỉ: Bộ môn Công nghệ phần mềm - Khoa Công nghệ thông tin – Học viện Nông nghiệp Việt Nam

(15)

Chương 1: MỞ ĐẦU

Ngày nay, hầu hết hoạt động quốc gia phụ tḥc vào hệ thớng máy tính phức tạp, phần mềm hoạt đợng máy tính trở thành điều kiện sớng cịn máy tính Cơ sở hạ tầng, tiện ích dựa hệ thớng máy tính, sản phẩm điện tử bao gồm mợt máy tính và phần mềm điều khiển, sản xuất công nghiệp và dịch vụ phân phối dựa hoàn tồn vào máy tính Do đó, việc sản xuất và bảo trì mợt cách hiệu quả với chi phí hợp lý là vấn đề chủ yếu ảnh hưởng tới phát triển kinh tế quốc gia và quốc tế

Sau một thời gian ngành sản xuất phần mềm rơi vào khủng hoảng, nhà khoa học nhanh chóng nhận tầm quan trọng việc đưa phương pháp luận cho phát triển phần mềm Từ khái niệm cơng nghệ phần mềm đời Công nghệ phần mềm là kỹ nghệ bản tập trung chủ yếu vào việc phát triển phần mềm có chất lượng cao, hiệu quả với chi phí và thời gian phát triển hợp lý Chương này giới thiệu lịch sử hình thành và phát triển ngành cơng nghệ phần mềm, mợt sớ khái niệm bản có liên quan Phần cuối chương đề cập đến một số vấn đề đạo đức chuyên gia CNTT, từ giúp người học có ý thức vai trò và trách nhiệm họ tham gia vào thị trường lao động lĩnh vực này

1.1 LỊCH SỬ HÌNH THÀNH VÀ PHÁT TRIỂN

Trước thập kỷ 90 kỷ XX, công nghệ thông tin tập trung nhiều cho phát triển phần cứng, nhằm giảm giá thành xử lý và tăng dung lượng lưu trữ dữ liệu Từ thập kỷ 90 kỷ XX trở lại đây, phát triển công nghệ thông tin tập trung nhiều vào cải thiện chất lượng và giảm giá thành giải pháp dựa máy tính, tức là phương pháp được cài đặt phần mềm Sự cấp bách này nhu cầu phần mềm ngày càng tăng nhanh cả số lượng, quy mơ tính

1.1.1 Q trình tiến hóa phần mềm

Q trình tiến hóa phần mềm diễn qua thời kỳ tăng dần cùng với tiến bộ phần cứng

a) Những năm 1950s đến năm 1960s

Trong giai đoạn này, phần cứng có lực hạn chế và thay đổi liên tục, phần mềm phần lớn mang tính chuyên dụng Lập trình máy tính "theo bản năng" và được xem là mợt nghệ thuật, chưa có phương pháp mang tính hệ thống, phát triển phần mềm chưa được quản lý, phần lớn hệ thống xử lý theo lô

(16)

- Hệ thống thời gian thực đời, bao gồm việc thu thập, phân tích, biến đổi dữ liệu từ nhiều nguồn khác để kiểm soát tiến trình Hệ thớng phải đưa u cầu đáp ứng phần nghìn giây, thay nhiều phút trước

- Tiến bộ lưu trữ trực tuyến làm xuất hệ quản trị sở liệu hệ đầu

- Số lượng hệ thớng dựa máy tính phát triển, nhu cầu phân phối mở rộng, thư viện phần mềm phát triển, quy mơ phần mềm ngày càng lớn Vì nảy sinh nhu cầu sửa chữa chương trình gặp lỗi, hay người dùng u cầu chương trình phải thích nghi với những thay đổi môi trường Công việc bảo trì phần mềm làm phát sinh những bức xúc, tiêu tốn nhiều công sức và tài nguyên đến mức báo động

c) Giữa năm 1970s – 1990s

Thời kỳ này đặc trưng việc phát triển mạng toàn cục và cục bợ, truyền thơng tín hiệu số giải thông cao Những kiện này làm tăng nhu cầu truy nhập dữ liệu, yêu cầu phát triển phần mềm quản lý dữ liệu Cùng với là phát triển hệ thớng phân tán làm tăng quy mô và độ phức tạp phần mềm

Sự tiến bộ nhanh và sử dụng phổ biến bộ vi xử lý cho thiết bị (ơtơ, robot, lị vi sóng, thiết bị ch̉n đốn ) cơng nghiệp, máy tính cá nhân đời và máy trạm để bàn phát triển, làm cho nhu cầu phần mềm tăng nhanh phạm vi người dùng mở rộng Phần cứng ngày càng ổn định, chi phí phần mềm có khuynh hướng tăng nhanh chi phí mua máy Từ nảy sinh nhu cầu tăng suất sản xuất phần mềm

Phương pháp luận và phương pháp phát triển phần mềm hướng cấu trúc đạt đến mức độ hoàn thiện cao và cùng với là phát triển cơng cụ trợ giúp cơng nghệ phần mềm máy tính (CASE), làm tăng suất và chất lượng phần mềm một cách đáng kể

d) Thời kỳ năm 1990 -

Trong thời kỳ này, cách tiếp cận công nghệ hướng đới tượng nhanh chóng thay cách tiếp cận truyền thống việc phát triển nhiều lĩnh vực ứng dụng

Các hệ thống thông minh hệ chuyên gia và phần mềm trí tuệ nhân tạo chuyển từ phịng thí nghiệm thực tế Phần mềm mạng nơron nhân tạo mở khả nhận dạng và có khả xử lý thơng minh kiểu người

Sự phát triển Internet làm cho người dùng máy tính tăng vọt, nhu cầu phần mềm ngày càng lớn, quy mô và độ phức tạp những hệ thống phần mềm tăng đáng kể Các hệ thống dựa Web chiếm ưu ứng dụng nghiệp vụ Công nghệ hướng đối tượng (tiêu biểu hệ NET) và phát triển phần mềm theo hướng tái sử dụng (Pattern Frameworks) trở thành một xu hướng công nghệ Tất cả yếu tố tạo nên những thách thức cho việc phát triển phần mềm

1.1.2 Sự đời công nghệ phần mềm

Nhìn lại tiến hóa phần mềm ta thấy những năm 60s – 70s kỷ trước, nhiều vấn đề liên tục phát sinh, tạo những thách thức cho việc phát triển phần mềm như:

(17)

- Sự tăng chi phí làm phần mềm (cần nhiều lao đợng có kỹ năng) - Sự kéo dài thời gian phát triển phần mềm (do phần mềm lớn) - Sự phụ thuộc nhiều vào kinh nghiệm người làm phần mềm - Chất lượng phần mềm không ổn định phụ thuộc vào người - Thiếu nghiêm trọng kỹ sư phần mềm (do nhu cầu tăng nhanh) - Gánh nặng bảo trì nhiều hệ thống cũ để tiếp tục hoạt động

Giải vấn đề nêu làm nảy sinh việc nghiên cứu giải pháp cho chúng Vào những năm 70s kỷ XX, phát triển phần mềm được thừa nhận và bắt đầu trở thành một ngành công nghiệp yêu cầu sử dụng mở rộng

Năm 1975, sau hội nghị Công nghệ phần mềm quốc tế (ICSE - Internetional Conference of SE), nhiều lý thuyết, phương pháp luận và kỹ thuật được đề nghị Vào những năm 90s kỷ XX, công cụ trợ giúp cơng nghệ phần mềm máy tính (CASE) phát triển mạnh Nhờ vậy, việc tự đợng hóa mợt sớ bước trình phát triển phần mềm phổ biến Nhiều phương pháp luận và kỹ thuật được đề nghị và áp dụng sau khủng hoảng Tuy nhiên, tính ổn định sản phẩm phần mềm và kỹ thuật kiểm thử chưa được giải trọn vẹn Vì vậy, cơng nghệ phần mềm đời mợt địi hỏi tất yếu phát triển phần mềm 1.2 MỘT SỐ KHÁI NIỆM CƠ BẢN TRONG LĨNH VỰC CÔNG NGHỆ PHẦN MỀM 1.2.1 Khái niệm phần mềm

Rất nhiều người cho phần mềm và chương trình máy tính là hai khái niệm tương đương Tuy nhiên, hiểu theo một định nghĩa rộng hơn, phần mềm không đơn là những chương trình, mà cịn kết hợp với tài liệu, cấu hình dữ liệu cần thiết để thực những chức chương trình mợt cách đắn và hợp lý Một hệ thống phần mềm thơng thường bao gồm mợt sớ chương trình riêng biệt, tệp cấu hình mà chúng được sử dụng để thiết lập chương trình, tài liệu hệ thớng, những tài liệu mô tả cấu trúc hệ thống và tài liệu người dùng, những trang Web để người dùng tải những thơng tin sản phẩm Có hai kiểu phần mềm bản:

Generic products (sản phẩm dùng chung): là những hệ thống độc lập được sản xuất

(18)

việc đặc tả phần mềm thường được thực và kiểm soát tổ chức mua phần mềm, những người phát triển phần mềm phải làm việc theo đặc tả này

Tuy nhiên, phân biệt này ngày càng trở nên không rõ ràng, ngày càng nhiều công ty phần mềm bắt đầu với một hệ thống phần mềm chung và biến đổi cho phù hợp với nhu cầu khách hàng Các hệ thống ERP hay SAP là mợt ví dụ rõ ràng cho cách tiếp cận này 1.2.2 Khái niệm công nghệ phần mềm

Công nghệ phần mềm – software engineering (một số tài liệu gọi kỹ nghệ phần mềm) kỹ nghệ liên quan tới tất các khía cạnh của sản xuất phần mềm, từ giai

đoạn bắt đầu đặc tả hệ thớng bảo trì hệ thớng sau đưa vào sử dụng Trong định nghĩa này, có hai khái niệm quan trọng:

Những nguyên tắc công nghệ: là nguyên tắc mà kỹ sư phải sử dụng công

việc Họ áp dụng những lý thuyết, phương thức và cơng cụ thích hợp, sử dụng chúng mợt cách có chọn lọc và luôn cố gắng phát giải pháp cho vấn đề đặt ra, chí cả khơng có phương thức và sở lý thuyết thích hợp Các kỹ sư phần mềm phải làm việc những ràng ḅc tài và tổ chức, đó, những giải pháp mà họ đưa phải nằm những ràng buộc này

Tất các khía cạnh của sản phẩm phần mềm: công nghệ phần mềm không liên

quan tới tiến trình kỹ thuật việc phát triển phần mềm mà cịn là những hoạt đợng, chẳng hạn việc quản lý dự án phần mềm và việc phát triển công cụ, phương pháp, sở lý thuyết cho việc phát triển phần mềm

Nói chung, kỹ sư phần mềm phải tuân theo một phương pháp và cách tiếp cận được xác định cho công việc họ để đưa được phần mềm chất lượng tốt Hầu hết công nghệ được lựa chọn là thích hợp nhất, nhiên mợt điều kiện cụ thể và tùy theo sáng tạo, việc phát triển phần mềm không tuân thủ những nguyên tắc ban đầu sẽ hiệu quả 1.2.3 Sự khác công nghệ phần mềm khoa học máy tính

Về bản, khoa học máy tính liên quan tới những nguyên lý và phương pháp làm sở cho máy tính và hệ thớng phần mềm, đó, cơng nghệ phần mềm liên quan tới những vấn đề thực tế sản xuất phần mềm Những kiến thức khoa học máy tính là cần thiết cho kỹ sư phần mềm, giống những hiểu biết vật lý cho kỹ sư điện Một cách lý tưởng, tất cả kỹ sư phần mềm cần phải lấy tảng kiến thức từ khoa học máy tính

1.2.4 Tiến trình phần mềm

Mợt tiến trình phần mềm là một tập hợp hoạt động để sản xuất phần mềm Có hoạt đợng bản tiến trình phần mềm:

Đặc tả phần mềm: khách hàng và kỹ sư phần mềm định nghĩa sản phẩm sẽ được sinh

ra và những ràng buộc liên quan đến phần mềm trình phát triển phần mềm

Phát triển phần mềm: phần mềm được thiết kế và lập trình

Kiểm thử phần mềm: phần mềm được kiểm tra để đảm bảo phù hợp với yêu cầu

(19)

Cải tiến - bảo trì phần mềm: phần mềm được thay đổi để đáp ứng những thay đổi

khách hàng và thị trường

Các kiểu hệ thớng khác cần những tiến trình phát triển khác nhau, ví dụ, phần mềm thời gian thực điều khiển thiết bị máy bay phải được đặc tả một cách hoàn chỉnh trước phát triển Trong với hệ thớng thương mại, việc đặc tả và lập trình thường được phát triển cùng Kết quả là, những hoạt động chung này được tổ chức theo cách khác và được mô tả mức độ chi tiết khác Tuy nhiên, việc sử dụng những tiến trình khơng hợp lý làm giảm chất lượng hoặc giảm tính sử dụng sản phẩm chi phí cho việc phát triển phần mềm tăng theo

1.2.5 Mơ hình tiến trình phần mềm

Mợt mơ hình tiến trình phần mềm là việc mơ tả mợt tiến trình phát triển phần mềm Các mơ hình tiến trình bao gồm việc mơ tả hoạt đợng tiến trình phần mềm, mơ tả sản phần phầm mềm và vai trò những người liên quan q trình phát triển Mợt vài ví dụ kiểu mơ hình tiến trình là:

Workflow model: mơ hình này thứ tự hoạt đợng mợt tiến trình cùng với

đầu vào, đầu và phụ thuộc Các hoạt động mơ hình này mơ tả hoạt đợng người

Data-flow/Activity model: mơ hình này mơ tả tiến trình mợt tập hợp hoạt

động, hoạt động thực việc biến đổi mợt sớ dữ liệu Nó dữ liệu đầu vào được xử lý nào, chẳng hạn mợt bản đặc tả được biến đổi để có sản phẩm đầu là một bản thiết kế Những hoạt đợng biến đổi được thực người hoặc máy tính

Role/Action model: mơ hình này giới thiệu vai trị những người liên quan tiến

trình phần mềm và những hoạt động mà họ phải chịu trách nhiệm

Hầu hết mơ hình tiến trình dựa một ba cách tiếp cận phát triển phần mềm đây:

Cách tiếp cận thác nước: mơ hình này lấy những hoạt đợng và biểu diễn chúng

những giai đoạn riêng rẽ, chẳng hạn như: đặc tả yêu cầu, thiết kế phần mềm, phát triển và kiểm thử… Việc phát triển phần mềm tuân theo tiến trình này

Phát triển lặp tăng dần: cách tiếp cận này đan xen hoạt động đặc tả, phát triển và

(20)

1.2.6 Chi phí công nghệ phần mềm

Chi phí cơng nghệ phần mềm là việc xác định nguồn kinh phí cần thiết cho giai đoạn phát triển phần mềm Khơng có câu trả lời đơn giản cho câu hỏi này cịn phụ tḥc vào mơ hình tiến trình được lựa chọn và kiểu phần mềm cần xây dựng Ví dụ: phần mềm thời gian thực thường đòi hỏi việc kiểm thử đắt so với hệ thống dựa web Hình vẽ 1.1 phần trăm chí phí cho giai đoạn ứng với mơ hình tiến trình khác

Hình 1.1 Phần trăm chi phí giai đoạn tiến trình phần mềm

1.2.7 Phương pháp công nghệ phần mềm

Phương pháp công nghệ phần mềm là một cách tiếp cận có cấu trúc để phát triển phần mềm, là trợ thủ đắc lực giúp cho việc xây dựng phần mềm mợt cách dễ dàng hơn, bên cạnh đảm bảo chất lượng tớt, chi phí hợp lý và hiệu quả

Những phương pháp Structure Analysis, JSD được bắt đầu phát triển từ những năm 70s Những phương pháp này cố gắng xác định thành phần chức bản hệ thống; phương pháp hướng chức đến được sử dụng Vào những năm 80s, 90s, phương pháp hướng chức cịn có thêm phương pháp hướng đối tượng Những cách tiếp cận khác ngày được tích hợp mợt cách tiếp cận hợp dựa ngơn ngữ UML

Khơng có phương pháp lý tưởng, phương pháp khác thích hợp với những lĩnh vực ứng dụng khác Ví dụ: phương pháp hướng đới tượng thường thích hợp cho hệ thớng tương tác lại khơng thích hợp cho những hệ thớng có u cầu thời gian thực

Tất cả phương pháp dựa ý tưởng phát triển mơ hình hệ thớng biểu diễn đồ họa và sử dụng mô hình này mợt bản đặc tả hoặc bản thiết kế Các phương pháp bao gồm mợt sớ thành phần khác nhau:

Bảng 1.1 Các thành phần mơ hình hệ thống

Thành phần Mơ tả Ví dụ

Wat erfall m odel

It erative developm ent

Com ponent-based software eng ineering

Developm ent and evolution costs for long-lifetim e sy st em s

Sy stem evolution

10 200 30 400

0

Sy stem developm ent

Specification Design Developm ent Integ ration and testing

25 75 100

0

Specification Developm ent Integ ration and testing

2 5 75 00

0

Specification Iterative developm ent Sy stem testing

2 5 75 00

0

Mơ hình thác nước

Mơ hình lặp và tăng dần

Đặc tả Thiết kế Phát triển Tích hợp và kiểm thử

Đặc tả Phát triển tích hợp Kiểm thử hệ thớng

Kỹ nghệ phần mềm hướng thành phần

Đặc tả Phát triển Tích hợp và kiểm thử

Chi phí phát triển và cải tiến hệ thớng có thời gian sống dài

Phát triển hệ thống Cải tiến hệ thớng

(21)

Mơ hình hệ thớng

Mơ tả mơ hình hệ thớng nên được phát triển và khái niệm được sử dụng mơ hình này

Mơ hình đới tượng, mơ hình data-flow, mơ hình máy ảo và phân tầng…

Quy tắc (rules) Các ràng buộc luôn phải áp dụng mô hình hệ thớng

Mỗi thực thể mợt mơ hình hệ thớng phải có mợt tên

Gợi ý

(recommendation)

Khám phá những điểm tốt thiết kế phương thức này Tuân theo những gợi ý này giúp bạn xây dựng được mợt mơ hình tổ chức hệ thớng tớt

Khơng có đới tượng nào có đới tượng nằm

Quy trình hướng dẫn

Mơ tả hoạt đợng mà ta tn theo để phát triển mơ hình hệ thớng và tổ chức hoạt đợng này

Các tḥc tính đối tượng nên được đưa vào tài liệu trước xác định phương thức cho đối tượng này

1.2.8 CASE - Các công cụ công nghệ phần mềm

Computer-Aided software engineering bao gồm kiểu chương trình khác được

sử dụng để hỗ trợ cho hoạt đợng tiến trình phần mềm, chẳng hạn phân tích u cầu, mơ hình hóa hệ thớng, gỡ lỗi và kiểm thử Các cơng cụ thường được tích hợp để thực mợt chức trọn vẹn hay một số chức riêng rẽ Khi cơng cụ được tích hợp tới mức thơng tin chúng tạo được dùng cho công cụ khác hoặc cho giai đoạn trình phát triển chúng được gọi là những bộ công cụ (workbenches), hay một hệ thống trợ giúp phát triển phần mềm và được gọi là môi trường phát triển (developmeny invironments) Các hệ thống này gọi chung là công nghệ phần mềm được máy tính trợ giúp (CASE)

1.2.9 Những tḥc tính phần mềm tốt

Cũng dịch vụ mà cung cấp, sản phẩm phần mềm phải có mợt sớ tḥc tính khác phản ánh chất lượng phần mềm Những tḥc tính này khơng liên quan trực tiếp đến những mà phần mềm thực hiện, thay vào đó, chúng phản ánh cách thực thi phần mềm, cấu trúc và cách tổ chức chương trình nguồn, những tài liệu liên quan Dưới là một sớ tḥc tính lấy làm sở để đánh giá chất lượng phần mềm

Bảng 1.2 Các thuộc tính phần mềm

Đặc tính sản phẩm Mô tả

(22)

nguồn tài nguyên bộ nhớ và bộ vi xử lý Tính hiệu quả bao gồm: thời gian trả lời, thời gian xử lý và việc sử dụng bộ nhớ

Tính sử dụng Phần mềm phải được người sử dụng chấp nhận, điều này có nghĩa là cần phải hiểu được, sử dụng được và tương thích với hệ thống khác 1.2.10 Những thách thức lĩnh vực phát triển phần mềm

Tính không đồng nhất: hệ thống được yêu cầu để thực thi một cách phân tán

hệ thống khác được kết nối mạng, bao gồm máy tính khác nhau, phần mềm hỗ trợ khác nhau, môi trường thực thi khác Ta thường xuyên phải tích hợp phần mềm vào hệ thống cũ được viết ngôn ngữ lập trình khác Tính khơng đồng là một thách thức việc phát triển kỹ thuật xây dựng phần mềm độc lập và mềm dẻo để thực thi mơi trường khơng đồng

Thách thức về việc bàn giao: Một những hạn chế kỹ thuật công nghệ phần

mềm truyền thống là thời gian cho đời mợt sản phẩm sử dụng được là dài Tuy nhiên, ngày kinh doanh cần phải đáp ứng mợt cách nhanh chóng những thay đổi, điều có nghĩa là phải cung cấp được những sản phẩm phần mềm biến đổi mợt cách nhanh chóng Thách thức này là việc bàn giao sản phẩm thời gian ngắn, với những hệ thống lớn và phức tạp mà không cần thỏa hiệp chất lượng hệ thống

Thách thức về độ tin cậy: sản phẩm phần mềm không tách rời khỏi cuộc sống

chúng ta điều quan trọng là phải có được những sản phẩm phần mềm đủ độ tin cậy Điều này đặc biệt hệ thống truy cập từ xa thông qua trang Web hoặc qua giao diện Thách thức độ tin cậy là phải phát triển những kỹ thuật để chứng minh được sản phẩm là đáng tin cậy đối với người sử dụng

1.3 MỘT SỐ VẤN ĐỀ VỀ ĐẠO ĐỨC CỦA CÁC CHUYÊN GIA CNTT

Trong thực tế, lĩnh vực có những người làm việc có trách nhiệm, hiểu biết và được đào tạo tớt, họ được gọi là chun gia Đó là nhà phân tích thị trường, tư vấn tài hay chun gia cơng nghệ thơng tin Trong lĩnh vực cơng nghệ thơng tin có mợt sớ chun ngành như:

- Lập trình

- Phân tích hệ thớng - Cơng nghệ phần mềm - Quản trị dữ liệu - Quản trị mạng - Quản lý thông tin

(23)

1.3.1 Những mối quan hệ cần phải quản lý chuyên gia công nghệ thông tin

Các chuyên gia công nghệ thông tin phải làm việc một môi trường có nhiều ràng ḅc, nhiều mới quan hệ với đối tượng khác nhau, bao gồm người sử dụng lao động, khách hàng, nhà cung cấp, chuyên gia khác, người sử dụng công nghệ thông tin và cộng đồng nói chung Những mới quan hệ này cần phải được xem xét, đánh giá cần đề những quy tắc đạo đức định Vì việc vi phạm những quy tắc đạo đức này dẫn đến tổn thất nặng nề tính mạng, sức khỏe và tài sản những người sử dụng trực tiếp hoặc gián tiếp hệ thống được phát triển

a) Chuyên gia công nghệ thông tin người sử dụng lao động

Mối quan hệ này tương đối phức tạp, địi hỏi phải có nỗ lực từ cả hai phía để trì Chun gia cơng nghệ thông tin và người sử dụng lao động cần phải thảo luận để đến thống một số điều khoản bản hợp đồng Những điều khoản này bao gồm: tên công việc, trách nhiệm công việc cụ thể, hiệu quả mong đợi, trang phục, nơi làm việc, làm việc và lợi ích cơng ty… Bên cạnh đó, có cả những quy định riêng công ty, những quy tắc đạo đức, cách ứng xử tổ chức, bao gồm: bí mật cơng ty, quy định việc nghỉ lễ, thời gian nghỉ những lý cá nhân… Rồi vấn đề liên quan đến pháp luật khơng được có những hành đợng vi phạm pháp luật, ví dụ làm sai lệch nội dung báo cáo, tiết lộ thông tin dữ liệu khách hàng… Tóm lại giớng tất cả bản hợp đồng lao động những lĩnh vực khác

Tuy nhiên, lĩnh vực công nghệ thơng tin, đặc thù nghề nghiệp, tính chất cơng việc hoặc dự án nên có thêm những quy định riêng Ví dụ: ngơn ngữ lập trình được sử dụng, loại và sớ lượng tài liệu hướng dẫn được đưa ra, quy trình kiểm tra đánh giá…

Các chuyên gia CNTT phải thiết lập một chuỗi quy định cho việc thi hành sách liên quan đến vấn đề đạo đức việc sử dụng CNTT Các chuyên gia CNTT có kiến thức, kỹ và có quyền truy cập cả thơng tin chuyên môn lẫn thông tin cá nhân một cách thoải mái, cho phép hoặc không cho phép người khác làm

Việc vi phạm bản quyền phần mềm, hành vi trái pháp luật việc chép phần mềm hoặc tạo điều kiện cho những người khác để họ truy cập vào những phần mềm mà họ khơng có quyền là một những vấn đề nhạy cảm, dễ dẫn đến những vi phạm pháp luật và quy định công ty

b) Mối quan hệ chuyên gia CNTT khách hàng

(24)

Thông thường khách hàng là người định vấn đề dự án sở thông tin, tư vấn và lựa chọn chuyên gia CNTT, khách hàng tin tưởng và giao phó chúng cho chun gia họ tin họ sẽ có được những dịch vụ tớt từ phía nhà cung cấp Còn chuyên gia CNTT phải tin tưởng khách hàng sẽ cung cấp những thơng tin có liên quan, lắng nghe và hiểu những điều mà chuyên gia tư vấn, giải thích, đặt câu hỏi để hiểu những tác đợng định, từ sẽ có được lựa chọn đắn từ những giải pháp mà chuyên gia gợi ý Trách nhiệm định được chia sẻ cho cả khách hàng chuyên gia CNTT

Một những vấn đề thuộc đạo đức giữa chuyên gia CNTT khách hàng liên quan đến những tư vấn viên CNTT hoặc kiểm toán viên, người giới thiệu sản phẩm và dịch vụ một nhà cung cấp cho mợt vấn đề mà họ phát

Ví dụ: mợt cơng ty tư vấn CNTT được thuê để đánh giá việc lập kế hoạch chiến lược CNTT một công ty Sau vài tuần làm việc, cơng ty tư vấn đánh giá chiến lược tồn thấp và họ sẽ đưa một chiến lược phát triển Câu hỏi đặt là liệu việc đánh giá này có khách quan hay không, và làm nào khách hàng tin tưởng được?

Trong thời gian làm việc với dự án, Các chuyên gia CNTT cung cấp đầy đủ và báo cáo xác tình trạng dự án họ thiếu thông tin, công cụ hoặc kinh nghiệm để thực một đánh giá xác Người quản lý dự án ḿn che dấu thơng tin hoặc thay đổi trước cơng khai với những người khác

c) Mối quan hệ chuyên gia CNTT nhà cung cấp

Thơng thường, chun gia CNTT có mới liên hệ với nhiều nhà cung cấp phần cứng, phần mềm và dịch vụ khác nhau, họ hiểu việc xây dựng mối quan hệ tốt với nhà cung cấp sẽ giúp họ có được trao đổi thơng tin có ích và cả việc chia sẻ ý tưởng công việc Những thông tin này dẫn đến những cải tiến mặt công nghệ và giá thành sản phẩm, là hiệu quả việc sử dụng Đây là những khía cạnh mà chun gia CNTT khơng xem xét đến

Các chuyên gia CNTT cần phải phát triển tốt mối quan hệ với nhà cung cấp cách chia sẻ với họ một cách công và không đưa những yêu cầu không hợp lý

Mặt khác, nhà cung cấp ln cớ gắng để trì mới quan hệ tích cực với khách hàng nhằm tăng doanh thu công ty Đôi khi, để đạt được những mục tiêu này, họ có những hành vi vi phạm đạo đức Ví dụ vấn đề quà biếu và nhận hối lộ

d) Mối quan hệ chuyên gia CNTT chuyên gia khác

Các chuyên gia cảm nhận được mức độ trung thành thành viên khác đới với Kết quả là họ giúp đỡ để có những vị trí đơi có những tượng cơng kích nhau, hạ thấp uy tín trước cơng chúng

Mợt sớ vấn đề đạo đức nảy sinh giữa thành viên một lĩnh vực Mợt những ví dụ điển hình là vấn đề thổi phồng việc, liên quan tới việc khơng thành thật, nói q khả so với thực tế

(25)

tư, bí mật nhân viên, khách hàng, nhà cung cấp, kế hoạch sản phẩm mới, chương trình khuyến mại, ngân sách… Do họ có hợi thực những hành vi vi phạm đạo đức nghề nghiệp thơng qua việc tiết lợ thơng tin bí mật khách hàng

e) Mối quan hệ chuyên gia CNTT người sử dụng

Là người sử dụng những sản phẩm phần mềm và phần cứng, được thiết kế, cài đặt dịch vụ và hỗ trợ sản phẩm chuyên gia CNTT Người sử dụng CNTT sử dụng những phương tiện này để nâng hiệu quả hoạt động tổ chức

Các chuyên gia CNTT có trách nhiệm phải hiểu nhu cầu và khả người sử dụng để cung cấp những dịch vụ tốt cho những yêu cầu họ, tất nhiên là phải cần nhắc đến cả những ràng buộc thời gian và ngân sách

Một trách nhiệm nữa chuyên gia CNTT là thiết lập môi trường làm việc giúp người sử dụng tránh những nguy vi phạm đạo đức Ví dụ khơng khuyến khích sử dụng phần mềm vi phạm bản quyền, giảm thiểu việc sử dụng khơng thích hợp nguồn tài nguyên công nghệ thông tin, tránh việc chia sẻ thông tin không hợp lý

f) Mối quan hệ chuyên gia CNTT cộng đồng

Những quy định pháp luật thiết lập tiêu chuẩn an toàn cho sản phẩm và dịch vụ để bảo vệ công chúng Tuy nhiên, văn bản pháp luật đơi có những thiếu sót, bảo vệ một cách tuyệt đối quyền lợi cộng đồng Trong lĩnh vực CNTT, chuyên gia hiểu mợt cách chi tiết và rõ ràng những tác động tốt xấu hệ quả công việc họ tới cợng đồng và có những hành đợng nhằm hạn chế những rủi ro xảy Vì thế, xã hợi mong chờ họ là những người mang lại lợi ích cho xã hợi Một những cách tiếp cận để đáp ứng kỳ vọng này là thiết lập và trì những tiêu chuẩn nghề nghiệp để bảo vệ công chúng Rõ ràng, hoạt đợng chun gia CNTT ảnh hưởng tới xã hợi

Ví dụ: chuyên gia CNTT thiết kế và phát triển mợt hệ thớng kiểm sốt tình trạng xử lý hóa chất nhà máy Nếu hệ thống này thiết kế không đúng, hoặc thất bại sẽ mang đến những nguy hại cho người dân gần nhà máy

Tóm lại, những chun gia CNTT có mới liên hệ với nhiều đối tượng khác xã hội, nhiều người bị ảnh hưởng hành đợng họ Đó là câu trả lời cho câu hỏi: “Có cần thiết lập mợt ch̉n mực đạo đức cho chuyên gia CNTT hay không?” 1.3.2 Những quy tắc đạo đức chuyên gia CNTT

(26)

tính đạo đức Vì cần phải thiết lập những nguyên tắc đạo đức bản và những giá trị cốt lõi cho ngành nghề cụ thể

Một quy tắc đạo đức đưa những nguyên tắc bản và những giá trị cốt lõi cần thiết cho cơng việc mợt nhóm nghề riêng biệt Hầu hết những quy tắc đạo đức chuyên gia một tổ chức bao gồm hai thành phần bản sau:

- Phác thảo những nguyện vọng bản mà một chuyên gia mong muốn - Danh sách những quy tắc bản mà thành viên tổ chức cần tuân thủ Về bản, quy tắc đạo đức hướng tới lợi ích cho cả cá nhân, nghề nghiệp và xã hội thông qua cải thiện việc định mang tính đạo đức, khuyến khích nâng cao chuẩn thực tiễn và ứng xử có đạo đức, đề cao thật và tôn trọng cộng đồng Để đảm quy tắc đạo đức khơng bị vi phạm cần đưa tiêu chuẩn để đánh giá Mục tiêu bản việc xây dựng quy tắc đạo đức cho tổ chức là:

- Cải thiện việc định mang tính đạo đức: việc tuân thủ một quy tắc đạo đức nghề nghiệp là cá nhân tổ chức sử dụng một tập giá trị cốt lõi và niềm tin kim nam cho việc định mang tính đạo đức

- Khuyến khích việc nâng cao ý thức đạo đức trình thực nhiệm vụ Đồng thời nhắc nhở chuyên gia trách nhiệm và nghĩa vụ họ thực thi công việc, tránh bị những cám dỗ thỏa hiệp để đáp ứng những áp lực kinh doanh ngày càng lớn

- Các quy tắc đạo đức xác định hành vi chấp nhận và chấp nhận để hướng dẫn chuyên gia họ làm việc với đối tác khác Các quy tắc đạo đức đưa những quy định nghiêm ngặt đòi hỏi cá nhân tổ chức phải tuân thủ Nếu vi phạm họ bị phạt hoặc quyền hành nghề Điều này tồn lĩnh vực CNTT

(27)

CÂU HỎI ÔN TẬP

1 Khủng hoảng phần mềm là gì? Vì khủng hoảng phần mềm lại dẫn tới đời ngành cơng nghệ phần mềm?

2 Hãy trình bày những khái niệm bản lĩnh vực công nghệ phần mềm

3 Các chuyên gia CNTT cần phải quản lý những mới quan hệ nào q trình làm việc? Những mối quan hệ này ảnh hưởng nào đối với việc tuân thủ quy tắc đạo đức nghề nghiệp

(28)

Chương 2:TIẾN TRÌNH PHẦN MỀM

Tiến trình phần mềm là mợt tập hợp hoạt đợng nhằm kiểm sốt q trình sản xuất phần mềm Tiến trình phần mềm phức tạp, mang tính sáng tạo, dựa định và đánh giá người Do mang tính sáng tạo và phê bình, nên những nỗ lực để sản xuất phần mềm mợt cách tự đợng cịn hạn chế Các cơng cụ trợ giúp việc sản xuất phần mềm hỗ trợ một vài hoạt động tiến trình này Nhìn chung, việc tự đợng hóa q trình sản xuất phần mềm cịn là mợt điều xa vời

Mặc dù có nhiều tiến trình phần mềm khác nhau, tựu chung lại, chúng có mợt sớ hoạt đợng bản, chung cho tất cả tiến trình:

- Đặc tả phần mềm: chức và ràng buộc phải được xác định - Thiết kế thực thi: phần mềm đáp ứng bản đặc tả phải được tạo

- Xác nhận – kiểm thử phần mềm: phần mềm phải được xác nhận để đảm bảo

thực được những mà khách hàng mong ḿn

- Cải tiến – bảo trì phần mềm: phần mềm phải được cải tiến để đáp ứng được những yêu

cầu thay đổi khách hàng

Mục tiêu chương này là tóm tắt hoạt đợng bản mợt tiến trình phần mềm giới thiệu mợt sớ mơ hình tiến trình phần mềm bản được sử dụng phát triển phần mềm

2.1 MƠ HÌNH TIẾN TRÌNH PHẦN MỀM

Mơ hình tiến trình phần mềm là mợt cách trìu tượng hóa (mơ hình hóa) mợt tiến trình phần mềm Mỗi mơ hình tiến trình đưa mợt tiến trình mợt tình h́ng cụ thể, sau sẽ cung cấp mợt phần thơng tin tiến trình để nhóm phát triển sử dụng để phát triển sản phẩm phần mềm Trong phần này, cùng tìm hiểu mợt sớ mơ hình tiến trình chung nhất, chúng được xem framework tiến trình khơng có những mơ tả chi tiết hoạt đợng cụ thể

Những mơ hình chung này không phải là những mô tả rõ ràng, cụ thể tiến trình phần mềm mà được sử dụng để giải thích cho cách tiếp cận khác phát triển phần mềm Có mơ hình bản:

Mơ hình thác nước: mơ hình này lấy sở là hoạt đợng tiến trình phần mềm: đặc

tả, phát triển, kiểm thử và thay đổi Các hoạt động này được coi giai đoạn tách biệt

Phát triển tiến hóa: cách tiếp cận này tiến hành xen kẽ hoạt động đặc tả, phát triển,

xác nhận kiểm thử (validation) Một hệ thớng ban đầu sẽ được nhanh chóng phát triển từ những đặc tả trìu tượng, phiên bản này sau được khách hàng xem xét đánh giá để sinh sản phẩm phù hợp với nhu cầu khách hàng

Công nghệ phần mềm hướng thành phần: cách tiếp cận này dựa một tập hợp

(29)

Đây là mơ hình tiến trình chung được sử dụng rộng rãi thực tế phát triển phần mềm Chúng thường không được áp dụng theo kiểu độc lập và nhất, mà thường sử dụng kết hợp với nhau, đặc biệt là phát triển hệ thớng lớn Ví dụ tiến trình phát triển phần mềm RUP, sẽ nhận thấy kết hợp thành phần tất cả mơ hình này Các hệ thớng bên mợt hệ thớng lớn được phát triển cách tiếp cận khác Tuy nhiên, sẽ tìm hiểu mơ hình mợt cách đợc lập và cần hiểu rõ để kết hợp chúng với thực tế

Ngoài những mô hình tiến trình chung này, mợt sớ tổ chức, người ta cịn lựa chọn mợt cách tiếp cận khác, là việc sử dụng ngơn ngữ hình thức để đặc tả phần mềm, sau biến đổi bản đặc tả này thành mã nguồn thực thi được

Mợt ví dụ điển hình tiến trình phát triển hình thức là tiến trình Cleanroom, bắt nguồn từ IBM Trong tiến trình Cleanroom, thành phần phần mềm được đặc tả ngôn ngữ hình thức (B, Z, OCL…) và sau đó, bản đặc tả này được biến đổi thành mã nguồn

Việc sử dụng những ngơn ngữ hình thức là cần thiết đối với hệ thống an toàn quan trọng, những hệ thớng địi hỏi đợ tin cậy, an toàn cao Cách tiếp cận hình thức chứng minh được cơng cụ tốn học để đảm bảo những yêu cầu đưa là đúng, đầy đủ thớng Tuy nhiên, những tiến trình dựa việc biến đổi hình thức khơng được sử dụng rợng rãi, chúng địi hỏi phải có những chun gia, thực tế, với những hệ thống bản, tiến trình này thường khơng hiệu quả mặt kinh phí chất lượng so với những tiến trình khác 2.1.1 Mơ hình thác nước

Mơ hình tiến trình phát triển phần mềm được đời là mơ hình thác nước, hình minh họa 2.1 (Royce, 1970) Những giai đoạn bản mơ hình này được ánh xạ vào hoạt đợng phát triển bản:

Phân tích xác định yêu cầu: dịch vụ hệ thống, mục tiêu được đưa thông

qua việc trao đổi và thống kê với người sử dụng hệ thống Sau chúng được định nghĩa mợt cách chi tiết và được xem là một bản đặc tả hệ thống

Thiết kế phần mềm hệ thống: trình thiết kế sẽ tiến hành phân vùng hệ thống cho

các yêu cầu phần cứng hoặc phần mềm, sinh kiến trúc hệ thớng Thiết kế phần mềm liên quan đến việc xác định, mô tả thành phần trìu tượng hệ thớng và mới quan hệ giữa chúng

Thực hiện kiểm thử đơn vị: bước này, bản thiết kế phần mềm sẽ được cụ thể hóa

(30)

được phát sớm quy trình làm phần mềm, nâng cấp đơn vị hệ thớng và từ bổ xung thêm dịch vụ để đáp ứng được yêu cầu thay đổi

Hình 2.1 Mơ hình thác nước

Trong mơ hình, kết quả giai đoạn là một hoặc nhiều tài liệu và giai đoạn được bắt đầu giai đoạn trước kết thúc Nhưng thực tế, giai đoạn này chồng lên và sinh những thông tin phản hồi giai đoạn trước Ví dụ: q trình thiết kế, những vấn đề yêu cầu sẽ được xác định Trong trình lập trình, những vấn đề thiết kế sẽ được bợc lợ… Tiến trình phần mềm không đơn giản là một đường thẳng mà là mợt thứ tự có lặp hoạt đợng phát triển

Nhược điểm của mơ hình thác nước:

Chi phí sản xuất và cải tiến tài liệu, lặp lại hoạt động phát triển phần mềm thường tốn và coi làm một khối lượng công việc đáng kể Tuy nhiên, sau một số bước lặp nhỏ, thông thường một số phần tiến trình phát triển sẽ được cớ định (đóng băng), chẳng hạn việc đặc tả hồn thành, sau tiếp tục với giai đoạn phát triển Mợt sớ vấn đề được để lại giải sau, hoặc bỏ qua

Giai đoạn ći cùng vịng đời phần mềm là cài đặt và bảo trì Sau đưa phần mềm vào sử dụng, lỗi và những điểm thiếu sót yêu cầu phần mềm gớc sẽ được phát hiện, chương trình và những lỗi thiết kế hoặc chức cần được bổ sung Để thực những thay đổi này, ta cần phải lặp lại giai đoạn trước tiến trình

Ưu điểm của mơ hình thác nước:

Dễ phân công công việc, kiến trúc hệ thống ổn định, tài liệu được sinh sau bước và phù hợp với mơ hình tiến trình cơng nghệ khác Vấn đề bản là tính mềm dẻo và linh hoạt Đơi khi, có những thay đổi hoặc những lỗi phần mềm yêu cầu nhóm phát triển phải làm lại gần từ đầu

(31)

Mơ hình này nên được sử dụng yêu cầu hệ thống được xác định một cách rõ ràng và đầy đủ từ đầu Ngoài cịn được ứng dụng dự án công nghệ khác Ngày nay, tiến trình phần mềm dựa cách tiếp cận này được sử dụng cho việc phát triển phần mềm, đặc biệt với những dự án phần mềm là một phần dự án công nghệ lớn hoặc những hệ thớng an tồn quan trọng

2.1.2 Phát triển tiến hóa

Phát triển tiến hóa dựa ý tưởng phát triển một phiên bản đầu tiên, chuyển tới người sử dụng và chờ những góp ý, sau phiên bản này tiếp tục được chỉnh sửa hệ thống hoàn chỉnh Các hoạt động đặc tả, phát triển, kiểm định được lặp lặp lại nhiều lần là những hoạt động riêng rẽ, những phản hồi được đáp ứng một cách nhanh chóng qua giai đoạn

Phát triển tiến hóa có hai mơ hình:

Mơ hình phát triển mở rộng: Khi mục tiêu tiến trình làm việc với khách hàng để

tìm hiểu yêu cầu người dùng và đưa hệ thống cuối cùng việc phát triển phần mềm sẽ được bắt đầu mợt phần hệ thớng mà nhóm phát triển hiểu cặn kẽ Tiếp theo sẽ thêm những tính hoặc thay đổi tính có theo u cầu khách hàng

Mơ hình làm mẫu: mục tiêu việc phát triển là xây dựng phần mềm phiên bản

để hiểu yêu cầu khách hàng, từ đưa được những yêu cầu hệ thống tốt Phần mềm khởi đầu tập trung vào những yêu cầu chưa rõ ràng Thực chất mơ hình làm rõ yêu cầu khách hàng để có được bản đặc tả chi tiết trước bắt tay vào phát triển phần mềm Sau giai đoạn này, nhóm phát triển lựa chọn mợt mơ hình hoàn toàn khác để xây dựng phần mềm (chẳng hạn mơ hình thác nước hoặc mơ hình tiến hóa)

(32)

Tiến trình phần mềm khơng rõ ràng: người quản lý cần phải có những sản phẩm bàn giao thường xun để đánh giá tiến trình Nếu hệ thớng được phát triển mợt cách nhanh chóng, việc sử dụng kinh phí cho việc đưa tài liệu cho phiên bản là tốn và không hiệu quả

Hệ thớng thường có tính cấu trúc yếu: những thay đổi thường xuyên sẽ làm phá vỡ tính cấu trúc chương trình Việc kết hợp chặt chẽ những thay đổi sẽ trở nên khó khăn và tớn

Ứng dụng của mơ hình:

Với những hệ thớng vừa và nhỏ (dưới 500.000 dịng mã nguồn), là cách tiếp cận tốt để phát triển Vấn đề phát triển tiến hóa xuất với những hệ thớng lớn, phức tạp và có thời gian phát triển dài, hay nhóm khác phát triển thành phần hệ thớng Khi khó đưa mợt kiến trúc hệ thớng ổn định và khó tích hợp thành phần được thực nhóm khác

Với những hệ thống lớn cần phải sử dụng những tiến trình kết hợp để tận dụng được ưu điểm cả mơ hình thác nước và mơ hình tiến hóa Ví dụ ban đầu ta sử dụng mơ hình mẫu để hiểu rõ ràng và chắc chắn yêu cầu phần mềm Sau bạn thực thi hệ thống lại cách tiếp cận có cấu trúc Mợt sớ phần hệ thớng được hiểu rõ ràng được đặc tả và phát triển dựa cách tiếp cận mô hình thác nước Những phần khác hệ thớng, chẳng hạn giao diện người dùng, sử dụng cách tiếp cận phát triển mở rộng

2.1.3 Công nghệ phần mềm hướng thành phần

Trong phần lớn dự án phần mềm, có mợt sớ thành phần tái sử dụng Điều này thường xảy mợt cách khơng thức nhóm phát triển làm việc những dự án mà người ta biết thiết kế hoặc mã nguồn có những yêu cầu tương tự Họ nhìn vào đó, thay đổi chúng cho phù hợp với hệ thống Trong cách tiếp cận tiến hóa được mơ tả phần trên, tái sử dụng thường được áp dụng đối với việc phát triển hệ thớng mợt cách nhanh chóng

Việc tái sử dụng mợt cách khơng thức thường khơng phân biệt tiến trình phát triển được sử dụng mợt cách rõ ràng Tuy nhiên, vài năm gần đây, một cách tiếp cận được gọi là công nghệ phần mềm dựa thành phần (component), dựa vào việc tái sử dụng, lên và được sử dụng một cách rộng rãi

Cách tiếp cận tái sử dụng dựa việc sử dụng một lượng lớn thành phần phần mềm có sẵn và mợt sớ framework tích hợp cho thành phần này Đôi khi, những thành phần này là những hệ thống, thực một số chức nào Mơ hình phần mềm hướng thành phần được mơ hình vẽ 2.3

Hình 2.3 Mơ hình phát triển hướng thành phần

Đặc tả yêu cầu

Phân tích thành phần

Phát triển tích hợp

Thiết kế tái sử dụng Thay đổi

yêu cầu

(33)

Trong những yêu cầu phần mềm được xây dựng và việc xác nhận phần mềm được tiến hành song song với giai đoạn khác tiến trình Những giai đoạn trung gian tiến trình dựa tái sử dụng khác Những bước này là:

Phân tích thành phần: bản đặc tả yêu cầu được đưa ra, việc tìm kiếm thành phần có

thể đáp ứng được những yêu cầu này Thơng thường, khơng có thích hợp tuyệt đới giữa yêu cầu và thành phần có sẵn, mà thành phần này cung cấp một phần chức được yêu cầu

Cải tiến yêu cầu: giai đoạn này, những yêu cầu được phân tích và sử dụng những

thông tin thành phần được khám phá Những yêu cầu này sau thường được thay đổi để thích hợp với những thành phần có Khi những thay đổi này khơng thể thực được, hoạt đợng phân tích thành phần được thực lại để tìm mợt giải pháp thích hợp

Thiết kế hệ thống tái sử dụng: giai đoạn này, framework hệ thống được thiết

kế hoặc những framework có sẵn được tái sử dụng Người làm thiết kế có tính đến thành phần tái sử dụng và tổ chức framework để phục vụ điều này Một số phần mềm được thiết kế thành phần tái sử dụng khơng sẵn sàng

Phát triển tích hợp: phần mềm mua được từ bên ngoài sẽ được nhóm phát

triển, những thành phần và hệ thống COST được tích hợp lại tạo thành mợt hệ thớng Việc tích hợp hệ thớng mơ hình này là mợt phần tiến trình phát triển

Cơng nghệ phần mềm dựa việc tích hợp thành phần có ưu điểm bản là việc giảm bớt cơng sức phát triển, giá thành sản phẩm thấp hơn, rủi ro Thơng thường, sản phẩm sớm được bàn giao tới khách hàng Tuy nhiên, việc thỏa hiệp giữa yêu cầu là tránh khỏi, điều này dẫn tới tình trạng hệ thống sẽ không thực phù hợp với yêu cầu thực khách hàng Hơn nữa, một số điều khiển hệ thớng là khơng thích hợp thành phần sử dụng phiên bản khác Do đó, phương pháp này thích hợp cho việc phát triển hệ thớng dựa tích hợp dịch vụ Web mợt nhóm nhà cung cấp 2.2 TIẾN TRÌNH LẶP

Sự thay đổi là điều tránh khỏi những dự án phần mềm lớn Những yêu cầu hệ thống thay đổi hệ thống không đáp ứng những áp lực từ bên ngoài, kỹ thuật sẵn sàng, việc thiết kế và thực thi thay đổi Điều có nghĩa là tiến trình phần mềm khơng phải là mợt tiến trình một lần, nữa, hoạt động tiến trình thường lặp lặp lại để đáp ứng những yêu cầu thay đổi Vì việc phát triển lặp là sở sản xuất phần mềm Phần này đề cập đến mơ hình tiến trình bản được thiết kế riêng cho tiến trình lặp

(34)

hợp có nhiều khách hàng cùng yêu cầu mợt sản phẩm Khi đó, việc thỏa thuận xem thành phần nào sẽ được phát triển trước là một vấn đề đáng được quan tâm

2.2.1 Mơ hình gia tăng

Trong mơ hình thác nước, những yêu cầu khách hàng phải được xác định gần hoàn chỉnh từ đầu, trước tiến hành thiết kế, cả việc thiết kế phải được hoàn thành trước bắt tay vào xây dựng mã nguồn Những thay đổi yêu cầu buộc ta phải thực lại hầu hết bước, từ đặc tả yêu cầu đến thiết kế và thực thi Tuy nhiên, việc phân chia giữa thiết kế và thực thi cần phải được kiểm sốt thơng qua hệ thớng được tài liệu hóa mợt cách rõ ràng và dễ thay đổi Ngược lại, cách tiếp cận tiến hóa, cho phép yêu cầu và định thiết kế được trì hỗn mà phần mềm trở nên tính cấu trúc, khó hiểu và khó bảo trì

Mơ hình gia tăng (hình 2.4) là một cách tiếp cận kết hợp những ưu điểm cả hai mơ hình: mơ hình thác nước và mơ hình tiến hóa Trong tiến trình phát triển tăng dần, khách hàng xác định một cách sơ lược dịch vụ được cung cấp hệ thống Họ sẽ xác định thành phần nào quan trọng nhất, thành phần nào quan trọng với họ Mợt sớ thành phần (increments) được xác định cung cấp một hệ thống chức hệ thống Việc xác định dịch vụ được đưa vào thành phần phụ thuộc vào việc những dịch vụ nào được ưu tiên phát triển trước

Khi một thành phần hệ thống được xác định, những yêu cầu cho những dịch vụ được triển khai thành phần sẽ được xác định chi tiết trước phát triển Trong q trình phát triển, việc phân tích u cầu cho thành phần sẽ được thực hiện, những yêu cầu thay đổi cho thành phần sẽ không được chấp nhận

Khi một thành phần hoàn thành và được bàn giao, khách hàng đưa vào khai thác, điều này có nghĩa là thành phần hoàn thành là một phần hệ thớng Việc sử dụng chúng cho ta những kinh nghiệm định để phát triển thành phần cho phiên bản cuối cùng thành phần Khi một thành phần được hoàn thành, chúng được tích hợp với thành phần có, chức hệ thống dần được hoàn thiện trước được bàn giao thức

Hình 2.4 Mơ hình phát triển gia tăng

Ưu điểm của mơ hình:

Khách hàng không phải đợi hệ thống hoàn thiện, họ thu được lợi nhuận phần mềm được triển khai Thành phần sẽ làm hài lòng hầu hết những yêu cầu quan trọng, họ sử dụng hệ thớng lập tức

Khách hàng sử dụng sớm thành phần là phiên bản mẫu và có được những kinh nghiệm cần thiết để diễn tả yêu cầu thành phần Do đó, thường có rủi ro dự án gặp lỗi Mặc dù một số vấn đề khơng được tính đến

Kiểm thử increment Phát triển

increment

Thiết kế kiến trúc hệ thớng

Tích hợp Increment

Kiểm thử Hệ thống Xác định yêu

cầu sơ lược

Sắp xếp yêu cầu vào increment

Hệ thống chưa hoàn thành

(35)

trong một số thành phần, có khả mợt sớ thành phần khác được bàn giao thành công tới khách hàng

Khi dịch vụ ưu tiên cao được phát triển trước, thành phần sau được tích hợp với chúng, những thành phần quan trọng sẽ được kiểm thử nhiều lần Điều này có nghĩa là khách hàng sẽ tránh được những lỗi phần mềm khơng kiểm sốt được những phần quan trọng hệ thớng

Nhược điểm của mơ hình:

Tuy nhiên, có những vấn đề đới với việc bàn giao gia tăng Các thành phần phải tương đới nhỏ (dưới 20,000 dịng mã nguồn) và thành phần bao gồm một số chức hệ thớng Do đó, đơi khó kết hợp những u cầu khách hàng với thành phần có kích thước hợp lý Hơn nữa, hầu hết hệ thống yêu cầu một tập hợp chức bản được sử dụng phần khác nhau, yêu cầu không được xác định một cách chi tiết thành phần được thực thi nhóm phát triển khó xác định được chức chung mà mọi thành phần cần đến

2.2.2 Mơ hình xoắn ốc

Mơ hình xoắn ớc tiến trình phần mềm được đưa Boehm (1988) Trong mơ hình này, hoạt đợng không phải là hoạt động tuần tự, mà tiến trình phát triển phần mềm vịng theo mợt đường xoắn ớc Mỗi vịng lặp hình xoắn là mợt giai đoạn tiến trình phần mềm (hình 2.5) Vịng cùng thường là hoạt đợng nghiên cứu tính khả thi, vòng là xác định yêu cầu, đến thiết kế, thực thi… Mỗi vòng được chia thành phần:

Thiết lập mục tiêu: mục tiêu cụ thể một giai đoạn dự án được xác định Các ràng ḅc đới với tiến trình và sản phẩm được xác định, bản kế hoạch quản lý chi tiết được đưa Những rủi ro đối với dự án được xác định Các chiến lược xen kẽ, phụ tḥc vào những rủi ro này được lập kế hoạch

Đánh giá giảm thiểu rủi ro: với rủi ro được xác định, người quản lý dự án sẽ đưa một bản phân tích chi tiết Các bước được thực để giảm thiểu rủi ro Ví dụ: có mợt rủi ro là u cầu khơng hợp lý, nhóm phát triển xây dựng mợt phần mềm mẫu để thử nghiệm

(36)

Hình 2.5 Mơ hình xoắn ốc

Ưu điểm của mơ hình xoắn ốc:

Ưu điểm lớn mơ hình xoắn ớc khả phân tích đánh giá rủi ro được đẩy lên một phần thiết yếu vịng lặp (spiral) để tăng mức đợ tin cậy dự án Mơ hình này kết hợp được những tính chất tớt mơ hình thác nước mơ hình tiến hóa Hơn nữa, cho phép thay đổi mơ hình thực thi tùy theo điều kiện thực tế dự án vịng lặp

Đây là mơ hình tổng qt nhất, tất cả mơ hình khác xem mợt thực mơ hình tổng qt này, hay xem mơ hình tổng hợp mơ hình khác Đặc biệt, được ứng dụng khơng phát triển phần mềm mà phát triển phần cứng

Nhược điểm của mơ hình xoắn ốc:

Mơ hình có nhiều ưu điểm phức tạp triển khai, khơng phù hợp cho những dự án nhỏ với rủi ro Nếu đợi dự án khơng có kỹ phân tích rủi ro tớt việc áp dụng mơ hình này khơng hiệu quả

Do đó, mơ hình thích hợp với những dự án lớn có nhiều rủi ro hay thành công dự án khơng có được đảm bảo định, những dự án địi hỏi nhiều tính tốn, xử lý hệ thớng hỗ trợ định Bên cạnh đó, đợi ngũ thực dự án phải có khả phân tích rủi ro tớt

2.3 CÁC HOẠT ĐỘNG TRONG TIẾN TRÌNH

(37)

được tổ chức mợt cách xen kẽ Tóm lại, hoạt đợng này được thực nào phụ thuộc vào kiểu phần mềm, tình hình nhân và cấu trúc tổ chức Ở người ta khơng xem xét tính sai cách tổ chức, mà mục tiêu phần này là cung cấp cho bạn những hướng dẫn bản để tổ chức hoạt động một cách hiệu quả

2.3.1 Đặc tả phần mềm

Đặc tả phần mềm hoặc kỹ nghệ yêu cầu là mợt tiến trình để hiểu và xác định những dịch vụ cần có hệ thớng xác định những ràng buộc đối với việc phát triển và chức hệ thống Công nghệ yêu cầu là một những giai đoạn quan trọng tiến trình phần mềm, lỗi giai đoạn này sẽ không tránh khỏi việc dẫn đến những sai lầm giai đoạn

Tiến trình kỹ nghệ yêu cầu được hình 2.6 Tiến trình này sẽ sinh tài liệu yêu cầu, là bản đặc tả cho hệ thớng Các u cầu thường được trình bày mức độ chi tiết khác tài liệu Khách hàng và người dùng cuối cần những mô tả yêu cầu mức cao, cịn người phát triển hệ thớng lại cần những đặc tả chi tiết

Hình 2-6 Các giai đoạn phân tích yêu cầu

Nghiên cứu tính khả thi: người ta sẽ ước lượng xem liệu những yêu cầu người dùng

(38)

dùng cuối hoặc yêu cầu khách hàng, có mức trìu tượng cao u cầu hệ thống, mô tả chi tiết chức hệ thống

Xác nhận yêu cầu (validation): công việc này kiểm tra yêu cầu xem có mang tính

hiện thực, thớng và đầy đủ khơng Trong q trình đặc tả, những lỗi tài liệu yêu cầu là tránh khỏi Những lỗi này cần phải được khắc phục lập tức để tránh dẫn đến lỗi bước

Tất nhiên, hoạt đợng tiến trình xác định yêu cầu không được thực một cách đơn giản theo mợt thứ tự định Việc phân tích u cầu tiếp tục những yêu cầu xuất Các hoạt đợng nghiên cứu tính khả thi, phân tích và đặc tả yêu cầu được tiến hành xen kẽ Trong một số phương pháp phát triển phần mềm linh hoạt, chẳng hạn phương pháp lập trình cực đại (Extreme Programming), yêu cầu được phát triển dần bước, thứ tự ưu tiên người dùng xác định và người dùng là một thành viên nhóm phát triển

2.3.2 Thiết kế thực thi phần mềm

Giai đoạn này liên quan tới việc chuyển những yêu cầu phần mềm thành những hệ thớng thực thi được Thơng thường liên quan đến việc thiết kế và lập trình Nếu phát triển phần mềm theo phương pháp tiếp cận tiến hóa, việc thực thi phần mềm cịn liên quan tới việc làm mịn yêu cầu

Thiết kế phần mềm là việc mô tả cấu trúc phần mềm được thực thi, dữ liệu hệ thống, giao diện giữa thành phần, và đôi khi, là thuật tốn sẽ được sử dụng Người làm thiết kế không phải lập tức đưa được một bản thiết kế hoàn chỉnh, mà thông thường phải được chỉnh sửa lặp lặp lại nhiều lần

Tiến trình thiết kế liên quan tới việc phát triển một vài mô hình hệ thớng những mức đợ trìu tượng khác Khi thiết kế được phân tích, lỗi và điểm thiếu sót giai đoạn trước sẽ được bộc lộ, điều này giúp cho việc chỉnh sửa bản thiết kế trước

Hình 2.7 mợt tiến trình để đưa một bản thiết kế hoàn chỉnh Sơ đồ này gợi ý bước tiến trình thiết kế là Nhưng thực tế, bước tiến trình thiết kế được thực xen kẽ Những phản hồi bước sẽ làm sở để hoàn thiện những công việc thực những bước trước Mợt bản đặc tả sau bước là đầu hoạt động thiết kế

Thiết kế kiến trúc: hệ thống tạo nên hệ thớng và mới quan hệ giữa chúng

được xác định và tài liệu hóa

Đặc tả trìu tượng: với hệ thống con, người ta phải xây dựng một bản mô tả trìu

tượng dịch vụ và những ràng ḅc

Thiết kế giao diện: với hệ thớng con, giao diện với hệ thống khác

được thiết kế và tài liệu hóa Giao diện phải khơng nhập nhằng và cho phép hệ thống khác sử dụng mà không cần biết hoạt động bên

Thiết kế thành phần: dịch vụ được bớ trí vào thành phần và giao diện

(39)

Thiết kế cấu trúc dữ liệu: cấu trúc dữ liệu sử dụng hệ thống được xác định và thiết

kế một cách chi tiết

Thiết kế giải thuật: giải thuật được sử dụng dịch vụ được xác định và thiết kế

chi tiết

Hình 2.7 Các hoạt đợng tiến trình thiết kế

Đây là tiến trình chung cho giai đoạn thiết kế, nhiên, đới với hệ thớng người ta lại có những biến đổi cho phù hợp Ví dụ: hai giai đoạn ći tiến trình thiết kế là thiết kế cấu trúc dữ liệu và thiết kế giải thuật, người ta thực bắt tay vào lập trình Nếu sử dụng cách tiếp cận mở rợng thiết kế, giao diện hệ thớng thiết kế sau xác định rõ cấu trúc dữ liệu Giai đoạn đặc tả trìu tượng bị bỏ qua, mặc dù quan trọng đới với hệ thớng địi hỏi tính an tồn cao

Khi phương pháp phát triển phần mềm linh hoạt được sử dụng, đầu tiến trình thiết kế sẽ không phải là những tài liệu đặc tả riêng biệt, sẽ được đưa vào mã nguồn chương trình Sau thiết kế kiến trúc, giai đoạn thiết kế sau được thực theo kiểu gia tăng (incremental) Mỗi increment được xem một đoạn mã nguồn chương trình là mợt mơ hình thiết kế

Ngược lại, với tiếp cận theo phương thức cấu trúc, việc thiết kế chủ yếu dựa những mơ hình đồ họa và mợt sớ trường hợp, người ta sinh mã nguồn tự đợng từ mơ hình này Phương pháp cấu trúc được phát triển từ những năm 70s để phục vụ cho việc thiết kế hướng chức năng, sau là hướng đối tượng và xuất một số ngôn ngữ trợ giúp trình thiết kế (UML) Phương pháp cấu trúc bao gồm mợt mơ hình tiến trình thiết kế, khái niệm thiết kế, định dạng báo cáo, quy tắc và hướng dẫn thiết kế Các phương pháp cấu trúc cung cấp một phần hoặc toàn bộ mơ hình sau hệ thớng:

Mơ hình đối tượng lớp đối tượng được sử dụng hệ thống và mối liên hệ giữa chúng

Mơ hình đới tượng tương tác nào với hệ thống Thiết kế kiến trúc Đặc tả trìu tượng Thiết kế giao diện Thiết kế thành phần Thiết kế cấu trúc dữ liệu Thiết kế giải thuật Kiến trúc hệ thống Đặc tả phần mềm Đặc tả giao diện Đặc tả

thành phần trúc dữ liệuĐặc tả cấu

Đặc tả giải thuật Các yêu cầu

được đặc tả

Các hoạt động thiết kế

(40)

được sử dụng một cách thiết kế hệ thống kinh doanh và hệ thớng thời gian thực

Lập trình là mợt hoạt đợng mang tính cá nhân, khơng có mợt tiến trình chung để tn theo Mợt sớ lập trình viên bắt đầu những thành phần mà họ hiểu kỹ càng, sau làm việc với thành phần mà họ chưa hiểu cặn kẽ Cũng có cách tiếp cận khác, họ để lại những thành phần quen thuộc đến cuối, họ biết phải thực thi chúng nào Mợt sớ lập trình viên lại thích xác định dữ liệu sớm tiến trình, và sau sử dụng những dữ liệu này để định hướng cho việc lập trình, mợt sớ lại để việc cấu trúc dữ liệu đến cuối…

Thông thường, lập trình viên thực việc kiểm thử phần mã nguồn mà họ phát triển Thơng thường liên quan đến những lỗi cần phải loại bỏ chương trình Cơng việc này gọi là gỡ lỗi (debugging) Việc phát và sửa lỗi là tiến trình khác Kiểm thử liên quan tới việc phát lỗi tồn tại, gỡ lỗi liên quan tới việc xác định và sửa lỗi Khi gỡ lỗi, Lập trình viên đưa giả thiết cách thực thi mà họ quan sát được, sau kiểm thử giả thiết này với hy vọng sẽ tìm được những lỗi gây những điểm bất thường đầu Người lập trình viết những trường hợp kiểm thử (test case) để xác định vị trí lỗi 2.3.3 Thẩm định phần mềm

Thẩm định hay xác minh và thẩm định phần mềm (verification and validation) là việc hệ thống phù hợp với đặc tả và đáp ứng được những mong đợi từ khách hàng Nó liên quan tới việc kiểm tra tiến trình, chẳng hạn việc kiểm duyệt và xem xét giai đoạn tiến trình phần mềm, từ yêu cầu người dùng đến xây dựng chương trình

Tuy nhiên, chi phí bản việc thẩm định được tính từ hệ thống chức được kiểm thử Trừ những chương trình nhỏ, hệ thớng khơng nên được kiểm thử mợt hệ thớng đơn đợc lập Hình 2.8 mợt tiến trình kiểm thử ba giai đoạn: thành phần hệ thống được kiểm thử, hệ thớng tích hợp được kiểm thử Ći cùng, hệ thống được kiểm thử với dữ liệu khách hàng

Hình 2.8 Tiến trình kiểm thử

Một cách lý tưởng, lỗi thành phần được phát giai đoạn đầu tiến trình và những vấn đề giao diện sẽ được phát hệ thớng được tích hợp Tuy nhiên, lỗi được phát hiện, chương trình phải được sửa lỗi và điều này làm cho giai đoạn khác quy trình kiểm thử phải được thực lại Những lỗi thành phần chương trình xuất śt q trình kiểm thử Tiến trình được lặp lặp lại kết hợp với những phản hồi từ giai đoạn khác

Các giai đoạn tiến trình kiểm thử bao gờm:

Kiểm thử thành phần

Kiểm thử hệ thống

(41)

Kiểm thử thành phần (đơn vị): thành phần độc lập được kiểm thử để đảm bảo chúng được thực thi Mỗi thành phần được kiểm thử đợc lập, khơng có thành phần hệ thớng khác Các thành phần (components) là thực thể đơn, chẳng hạn chức hoặc lớp đới tượng, hoặc là nhóm đồng thực thể này

Kiểm thử hệ thống: thành phần được tích hợp với tạo thành hệ thớng Tiến trình này liên quan tới việc tìm lỗi từ việc tương tác ngoài dự kiến giữa thành phần và vấn đề giao diện giữa thành phần Nó liên quan tới việc thẩm định hệ thớng, xem hệ thớng có đáp ứng được u cầu chức và yêu cầu phi chức năng, kiểm tra những tḥc tính quan trọng hệ thớng Đới với hệ thớng lớn, việc này là mợt tiến trình bao gồm nhiều giai đoạn, thành phần được tích hợp thành hệ thớng con, hệ thớng này sau được tích hợp với thành hệ thống hoàn chỉnh cuối cùng

Kiểm thử chấp nhận: là giai đoạn cuối cùng tiến trình kiểm thử trước hệ thống được đưa vào sử dụng Hệ thống được kiểm thử với dữ liệu khách hàng cung cấp chứ không phải là những dữ liệu mô Kiểm thử chấp nhận phát những lỗi hoặc những điểm cịn thiếu sót xác định u cầu hệ thống, dữ liệu thực sẽ kiểm tra hệ thống khác so với dữ liệu kiểm thử Kiểm thử hệ thớng nói chung liên quan tới những vấn đề yêu cầu, mà chức hệ thống không thực đáp ứng yêu cầu người sử dụng hoặc tính hiệu hệ thớng không được chấp nhận

Thông thường, việc phát triển thành phần và kiểm thử luân phiên Các lập trình viên thường kiểm thử phần mềm dữ liệu họ sau lập trình xong Đây là một cách tiếp cận nhạy cảm và hiệu quả mặt kinh tế Lập trình viên hiểu thành phần mà họ xây dựng một cách rõ ràng nhất, họ là người tớt để tạo trường hợp kiểm thử

Nếu hệ thống phát triển theo cách tiếp cận gia tăng, thành phần nên được kiểm thử phát triển, việc kiểm thử này dựa những yêu cầu đối với thành phần Trong phương pháp lập trình cực đại (XP), Nhóm phát triển sẽ xây dựng trường hợp kiểm thử làm đặc tả, trước tiến hành lập trình Điều này giúp cho kiểm thử viên và người lập trình hiểu rõ yêu cầu, đảm bảo khơng có chậm trễ tạo trường hợp kiểm thử

Những giai đoạn kiểm thử cuối cùng liên quan tới công việc mợt sớ lớn lập trình viên, cần phải có kế hoạch cụ thể Hình 2.9 minh họa kế hoạch kiểm thử kết nối giữa kiểm thử và hoạt động phát triển phần mềm

Đặc tả yêu cầu Đặc tả Hệ thống

Thiết kế

hệ thống Thiết kế chi tiết

Kiểm thử Kế hoạch kiểm

(42)

Khi đưa một hệ thống thị trường thành một sản phẩm phần mềm, tiến trình kiểm thử được gọi là kiểm thử beta Kiểm thử beta liên quan tới việc triển khai hệ thống tới một số khách hàng tiềm và họ đồng ý sử dụng hệ thống Những vấn đề cịn tồn sẽ được báo cáo lại với nhóm phát triển hệ thống Sau những phản hồi này, hệ thớng thay đổi và hoàn thiện lại phiên bản để đưa thị trường

2.3.4 Cải tiến phần mềm

Tính mềm dẻo, linh hoạt phần mềm là một những nguyên nhân dẫn đến việc ngày càng nhiều phần mềm hợp với thành những hệ thống phức tạp Khi định mua phần cứng mới, tốn để thay đổi thiết kế phần cứng Tuy nhiên, đới với phần mềm, ta thay đổi thời điểm nào, cả phần mềm hoàn thành Những thay đổi này đơi tớn kém, dù rẻ là việc thay đổi phần cứng tương đương

Từ trước, người ta tách việc phát triển và bảo trì phần mềm thành giai đoạn khác Người ta cho rằng, việc phát triển phần mềm là một hoạt động sáng tạo, từ khái niệm ban đầu, người phát triển xây dựng thành hệ thống thực thi được Và thế, người ta nghĩ việc bảo trì phần mềm là mợt việc nhàm chán và thú vị Mặc dù chi phí cho bảo trì phần mềm lớn gấp vài lần chi phí phát triển phần mềm, việc bảo trì được coi là mợt cơng việc thách thức so với việc làm

Việc phân biệt này ngày càng trở nên không hợp lý Người ta cho việc cải tiến phần mềm ngày được coi là một giai đoạn tiến trình phát triển phần mềm Hình 2.10 việc thay đổi được tiến hành một cách liên tục vòng đời phần mềm cho phù hợp với yêu cầu khách hàng

Hình 2.10 Tiến trình cải tiến sản phẩm phần mềm

2.4 RUP – TIẾN TRÌNH SẢN XUẤT PHẦN MỀM CỦA RATIONAL

RUP là mợt ví dụ mợt mơ hình tiến trình đại được đưa từ việc kết hợp UML và tiến trình phát triển phần mềm hợp Rumbough Tác giả đưa tiến trình này việc minh họa cho mợt mơ hình tiến trình lặp Nó là kết hợp thành phần tiến trình chung, hỗ trợ việc lặp lặp lại và minh họa một thực tế tốt đặc tả và thiết kế Mợt tiến trình RUP bao gồm phối cảnh sau:

- Một phối cảnh động giai đoạn mơ hình theo thời gian - Mợt phới cảnh tĩnh q trình hoạt động

- Một phối cảnh những gợi ý thực tế tốt được sử dụng suốt tiến trình

Đánh giá hệ thớng tồn Xác định yêu

cầu hệ thống thay đổi hệ thốngĐề xuất những

Thay đổi hệ thống

Hệ thống Các hệ thống

(43)

RUP là mợt mơ hình được phân chia thành giai đoạn tiến trình phần mềm, nhiên, khơng giớng mơ hình thác nước, giai đoạn RUP gần với mục tiêu nghiệp vụ là những vấn đề liên quan tới kỹ thuật Hình 2.11 giai đoạn RUP

Giai đoạn khởi đầu: mục tiêu giai đoạn khởi đầu là sinh mợt tình h́ng nghiệp vụ Ta cần xác định tất cả thực thể bên ngoài (con người và hệ thống) sẽ ảnh hưởng tới hệ thống bạn và định mối tương tác này Sau sử dụng những thơng tin này để đánh giá những đóng góp hệ thớng cho mục tiêu nghiệp vụ Nếu hiệu quả khơng lớn, ta kết thúc dự án sau bước này

Giai đoạn mở rộng: mục tiêu giai đoạn này là tăng cường những hiểu biết lĩnh vực ứng dụng Đưa một framework kiến trúc cho hệ thống, phát triển kế hoạch dự án và xác định những rủi ro quan trọng dự án Khi hoàn thành giai đoạn này, nên có mợt mơ hình u cầu cho hệ thớng (UML sử dụng mơ hình Use-case), mợt bản mơ tả kiến trúc và một bản kế hoạch cho phần mềm

Giai đoạn xây dựng: giai đoạn này chủ yếu liên quan tới việc thiết kế hệ thớng, lập trình và kiểm thử Một phần hệ thống được phát triển song song và được tích hợp giai đoạn này Khi kết thúc giai đoạn này, nên có mợt hệ thống phần mềm thực thi được và tài liệu kèm theo để sẵn sàng chuyển tới người sử dụng

Giai đoạn chuyển giao: giai đoạn cuối cùng RUP liên quan tới việc chuyển giao sản phẩm từ nhóm phát triển sang nhóm người sử dụng và phần mềm được thực thi môi trường thực Giai đoạn này thường được bỏ qua hầu hết mơ hình tiến trình phần mềm khác, thực tế, lại là một giai đoạn tốn và đơi xuất mợt sớ vấn đề Khi hoàn thành giai đoạn này, cần xây dựng một tài liệu hệ thống phần mềm làm việc mơi trường chức

Hình 2.11 Mơ hình tiến trình RUP

Việc lặp lại RUP tiến hành theo hai cách giớng hình 2.11 Mỗi giai đoạn được diễn một cách lặp lặp lại với kết quả phát triển tăng dần Hơn nữa, giai đoạn được diễn một cách tăng dần, từ giai đoạn chuyển giao đến giai đoạn khởi đầu giống hình

Giai đoạn lặp

(44)

- Quản lý yêu cầu: tài liệu hóa những yêu cầu người dùng một cách rõ ràng và theo dõi

những thay đổi yêu cầu này Phân tích ảnh hưởng những thay đổi trước chấp nhận chúng

- Sử dụng kiến trúc hướng thành phần: cấu trúc kiến trúc hệ thống vào thành phần

như thảo luận phần đầu chương này

- Mơ hình hóa phần mềm: sử dụng lược đồ UML để mô tả cấu trúc động và tĩnh

của hệ thống

- Xác minh chất lượng phần mềm: đảm bảo phải đáp ứng được chuẩn chất

lượng tổ chức

- Kiểm soát sự thay đổi của phần mềm: quản lý những thay đổi phần mềm sử dụng

một hệ thống quản lý thay đổi và công cụ, thủ tục quản lý cấu hình

RUP khơng phải là mợt tiến trình phù hợp với tất cả kiểu phát triển, đưa mợt tiến trình chung cho hệ phần mềm Sáng kiến quan trọng là phân chia thành giai đoạn và workflow Điều quan trọng nhận việc triển khai hệ thống là một phần tiến trình phát triển phần mềm, giai đoạn là đợng và có những mục tiêu cụ thể Luồng cơng việc (workflow) là tĩnh và là hoạt đợng mang tính kỹ thuật mà không được kết hợp vào một giai đoạn nào sẽ được sử dụng śt q trình để đáp ứng mục tiêu giai đoạn

2.5 KỸ NGHỆ PHẦN MỀM CÓ MÁY TÍNH TRỢ GIÚP (CASE)

CASE là tên những phần mềm được sử dụng để hỗ trợ hoạt đợng tiến trình sản xuất phần mềm, chẳng hạn kỹ nghệ yêu cầu, thiết kế, phát triển chương trình và kiểm thử Các cơng cụ CASE bao gồm: bợ soạn thảo thiết kế, từ điển dữ liệu, trình biên dịch, gỡ lỗi, công cụ xây dựng hệ thớng…

Kỹ thuật CASE giúp tự đợng hóa mợt sớ hoạt đợng tiến trình sản xuất phần mềm Ví dụ hoạt đợng tự đợng hóa việc sử dụng CASE:

- Xây dựng mơ hình đồ họa hệ thớng là mợt phần đặc tả yêu cầu hoặc thiết kế phần mềm

- Hiểu một bản thiết kế sử dụng từ điển dữ liệu lưu trữ những thông tin thực thể và những mối quan hệ thiết kế

- Bộ sinh giao diện người dùng từ việc mô tả giao diện đồ họa được tạo một cách tương tác người sử dụng

- Gỡ lỗi chương trình qua việc cung cấp thơng tin mợt chương trình được thực thi

- Trình biên dịch tự đợng sinh chương trình từ những phiên bản cũ một ngôn ngữ lập trình, chẳng hạn COBOL sang mợt phiên bản

(45)

- Công nghệ phần mềm là một hoạt động sáng tạo – điều này không dễ dàng để tự đợng hóa

- Công nghệ phần mềm là một hoạt động làm việc theo nhóm, phần lớn thời gian phải làm việc chung với cá nhân khác – CASE không thực hỗ trợ yếu tố này

- Các kỹ thuật CASE ngày có những tiến bợ đáng khích lệ và công cụ CASE mô trường hỗ trợ được cung cấp nhiều nhà cung cấp khác Tuy nhiên, hầu hết chúng tập trung vào cơng cụ hỗ trợ q trình làm đặc tả

1 Tiến trình phần mềm gì? Có những kiểu mơ hình tiến trình chung nào?

2 Với những kiểu dựa án ta nên sử dụng mơ hình thác nước Hãy giải thích sao? Mơ hình phát triển xoắn ốc phù hợp với kiểu dự án nào? Hãy giải thích?

4 Hãy nêu những ưu điểm và nhược điểm mơ hình phát triển tiến hóa Hãy nêu hoạt đợng chung tiến trình phần mềm

(46)

Chương 3:QUẢN LÝ DỰ ÁN PHẦN MỀM

Cuối những năm 1960 và đầu những năm 1970, ngành sản xuất phần mềm rơi vào thời kỳ khủng hoảng, nhiều dự án phần mềm lớn thất bại những bất cập quản lý dự án: phần mềm chuyển giao không thời hạn, không đáp ứng đủ độ tin cậy, chi phí vượt nhiều lần so với dự đốn, sản phẩm không đáp ứng được yêu cầu người sử dụng Theo thống kê Standish Group (2006):

- Có tới 50% sớ dự án phần mềm thất bại

- Chỉ có 16,2% dự án là hoàn thành hạn nằm giới hạn ngân sách, đáp ứng tất cả tính và đặc tính cam kết ban đầu

- Có 52,7% dự án được hoàn thành và vào hoạt động không hoàn thành hạn bội chi, thêm nữa khơng đáp ứng đầy đủ tính và đặc tính thiết kế ban đầu

- Có 31,1% dự án thất bại trước được hoàn thành

- Hơn 83,8% dự án thất bại hoặc không đáp ứng những yêu cầu ban đầu

Năm 1995, công ty Mỹ phải chi 81 tỷ USD cho những dự án bị hủy bỏ, 59 tỷ USD đầu tư thêm cho dự án không kế hoạch

Ở Việt Nam, dự án “Hệ thống điện tử xử lý thông tin SeaGame 22 VN” dự kiến kinh phí 15 tỷ VND, đến tháng 6/2003 chi tới 90 tỷ VND Những dữ liệu cho thấy: dự án phần mềm cần được quản lý để tránh những thất bại, mặc dù quản lý tốt chưa đủ yếu tổ để đảm bảo thành công quản lý chắc chắn sẽ dẫn đến thất bại dự án [3]

Chương này giới thiệu một số khái niệm bản quản lý dự án nói chung dự án CNTT nói riêng Nợi dung chương đề cập đến hoạt động quản lý dự án theo phương pháp truyền thống một hoạt động thiếu quản lý dự án phân tích quản lý rủi ro Đây là mợt những yếu tố định tới thành công dự án 3.1 CÁC KHÁI NIỆM CƠ BẢN

3.1.1 Khái niệm dự án

Theo quan điểm chung, dự án một lĩnh vực hoạt động đặc thù, một nhiệm vụ cần được thực theo một phương pháp riêng, khuôn khổ nguồn lực riêng, kế hoạch tiến độ cụ thể nhằm tạo một sản phẩm Do đó, dự án có tính cụ thể, mục tiêu rõ ràng, xác định để tạo một sản phẩm

Theo PMBOOK® Guide 2000, p.4, dự án là “một nỗ lực tạm thời được cam kết để tạo một sản phẩm hoặc dịch vụ nhất” Theo định nghĩa này, hoạt động dự án tập trung vào khía cạnh:

- Nỗ lực tạm thời: Mọi dự án có điểm bắt đầu kết thúc cụ thể Dự án kết thúc đạt được mục tiêu dự án hoặc dự án thất bại

(47)

Tóm lại, dự án một chuỗi công việc (nhiệm vụ, hoạt động), được một số người thực nhằm đạt được mục tiêu đề điều kiện ràng buộc phạm vi, thời gian ngân sách 3.1.2 Các đặc trưng dự án

- Sản phẩm đơn chiếc, nhất; - Chỉ làm một lần;

- Người tham gia thường có chun mơn khác nhau, được tập hợp lại; - Có lịch trình chặt chẽ, chi phí xác định;

- Kết quả khơng chắc chắn: sản phẩm đáp ứng yêu cầu thỏa mãn ràng buộc nghĩa là dự án thành công, ngược lại dự án thất bại

Các đặc trưng này đặt nhiều vấn đề cần nghiên cứu giải hoạt động triển khai dự án Mặt khác, một dự án thất bại thường nguyên nhân sau:

- Quản lý dự án kém: người quản lý thiếu kiến thức kinh nghiệm quản lý dự án

- Không lường hết được phạm vi, độ phức tạp cơng việc Do đó, dự kiến nguồn lực (người, kinh phí, thời gian) thực khơng xác

- Thiếu thông tin thực hiện, nên không xử lý kịp thời vấn đề nảy sinh

- Các lý khác, nhiều yếu tố bất ngờ từ môi trường công nghệ thay đổi, người cung cấp nguồn lực vi phạm hợp đồng

Ba lý sau cùng liên quan tới lý Vì nói rằng, quản lý dự án nguyên nhân chủ yếu dẫn đến dự án thất bại

3.1.3 Quản lý dự án

Quản lý dự án “ứng dụng kiến thức, kỹ năng, công cụ kỹ thuật vào hoạt động dự án để thỏa mãn yêu cầu dự án” (PMBOK ® Guide, 2000, p.6)

Xét theo khía cạnh khác, quản lý dự án mợt q trình lập kế hoạch, điều phới thời gian, nguồn lực giám sát q trình phát triển dự án nhằm đảm bảo cho dự án hoàn thành thời hạn, phạm vi ngân sách được duyệt và đạt được yêu cầu định kỹ thuật, chất lượng sản phẩm, dịch vụ, phương pháp và điều kiện tốt cho phép

(48)

Hình 3.1 Tiến trình triển khai một dự án

3.2 QUẢN LÝ DỰ ÁN THEO PHƯƠNG PHÁP PHÁT TRIỂN TRUYỀN THỐNG 3.2.1 Các hoạt động quản lý dự án

Rất khó để đưa mợt bảng mơ tả công việc chuẩn cho người làm quản lý dự án phần mềm Công việc này khác nhau, phụ thuộc vào tổ chức và phần mềm sẽ được xây dựng Tuy nhiên, những hoạt động phổ biến quản lý dự án thường bao gồm:

- Viết kế hoạch đề xuất;

- Ước lượng chi phí nguồn lực; - Lựa chọn, đánh giá nguồn lực; - Lập kế hoạch dự án lịch làm việc; - Triển khai kiểm sốt tiến trình dự án; - Viết báo cáo trình bày;

- Tổng kết, đánh giá

Viết kế hoạch đề xuất: Giai đoạn đầu dự án liên quan đến việc viết kế hoạch đề xuất

để giành được hợp đồng thực công việc Bản đề xuất nêu mục tiêu dự án và cách thức thực dự án Thông thường, bao gồm việc ước lượng chi phí và thời gian thực hiện, đồng thời phải chứng minh dự án nên được thực mợt tổ chức hoặc mợt nhóm xác định Việc viết kế hoạch đề xuất là nhiệm vụ quan trọng, có khả định xem dự án có được phê duyệt hay khơng hoặc tổ chức có được chấp nhận để thực dự án hay khơng Nói chung, khơng có những hướng dẫn cụ thể cho việc viết kế hoạch đề xuất, mà phụ thuộc nhiều vào kỹ người viết

Lập kế hoạch dự án lịch làm việc: Xác định hoạt động, mốc quan trọng và

thời gian bàn giao sản phẩm dự án Lập kế hoạch giúp cho trình phát triển phần mềm đáp ứng được mục tiêu dự án Ước lượng chi phí ước lượng tài nguyên cần thiết để thực dự án

Lựa chọn, đánh giá nguồn lực: Người quản lý dự án cần phải lựa chọn nhân thực

dự án Một cách lý tưởng người quản lý lựa chọn được những nhân viên có kinh nghiệm tham gia vào dự án Nhưng cơng việc này thường không đạt được mong muốn, một số lý sau:

Khởi tạo Lập kế

hoạch

Kiểm soát Thực

(49)

- Ngân sách dự án khơng cho phép sử dụng những nhân viên có mức lương cao, phải lựa chọn những nhân viên có kinh nghiệm với mức lương thấp

- Những nhân viên có nhiều kinh nghiệm không phải lúc nào sẵn sàng tham gia dự án Có thể xảy tình trạng khơng thể xây dựng được một đội ngũ nhân viên phù hợp Bên tổ chức, những người có kinh nghiệm thích hợp tham gia vào dự án khác

- Mợt tổ chức phát triển kỹ nhân viên cho dự án phần mềm Những nhân viên khơng có kinh nghiệm được phân công để học và tiếp thu những kinh nghiệm cần thiết

- Người quản lý phải làm việc những ràng buộc này, đặc biệt khơng cịn thời gian để đào tạo nhân viên Tuy nhiên, phải có mợt sớ thành viên dự án có kinh nghiệm kiểu hệ thớng được phát triển Với những kinh nghiệm này, vấn đề mà dự án gặp phải sẽ được giải dễ dàng

Triển khai kiểm soát dự án: Hoạt động giám sát là một hoạt động liên tục, người quản

lý theo dõi xem tiến trình dự án có phù hợp với kế hoạch và kinh phí xác định giai đoạn lập kế hoạch hay không Trong hầu hết tổ chức, một chế đặc biệt được dùng để giám sát dự án Mợt người quản lý nhiều kinh nghiệm đưa vấn đề để thảo luận với nhân viên dự án Các cuộc thảo luận này thường xoay quanh những khó khăn gặp phải q trình thực dự án, từ dự đốn những vấn đề tiềm ẩn sẽ phát sinh Ví dụ: thảo luận hàng ngày với nhân viên dự án để khám phá mợt vấn đề đặc thù việc tìm vài lỗi phần mềm, là ngồi đợi nghe báo cáo tình trạng mục tiêu khơng hoàn thành Người quản lý phần mềm tham khảo những chuyên gia giầu kinh nghiệm để định xem vấn đề sẽ được giải nào

Trong thời gian thực dự án, cần phải thường xun xem xét tiến trình và cơng nghệ được sử dụng để phát triển dự án, kiểm tra xem dự án và mục tiêu tổ chức được giữ vững hay khơng Việc xem xét này dẫn đến việc hủy bỏ dự án Ví dụ: đới với mợt dự án lớn, địi hỏi thời gian phát triển vài năm, thời gian này, mục tiêu tổ chức chắc chắn sẽ có thay đổi Những thay đổi này dẫn đến tình trạng phần mềm khơng cịn mang tính cấp bách hoặc những u cầu bản khơng cịn thích hợp Khi người quản lý định dừng việc phát triển phần mềm hoặc thay đổi dự án cho phù hợp với những thay đổi tổ chức

Viết báo cáo trình bày: Người quản lý dự án thường xuyên phải viết báo cáo cho

(50)

có thể đưa những thơng tin có giá trị liên quan đến tiến trình dự án Bản kế hoạch khởi đầu cần đạt được mục tiêu sau:

- Có thể sắp xếp thời gian cho hầu hết hoạt động quản lý dự án

- Hoạt động liên tục từ thiết kế ban đầu bàn giao hệ thống Kế hoạch phải được xem xét lại một cách thường xun có những thơng tin xuất

- Có nhiều kiểu kế hoạch khác được phát triển để từ đưa kế hoạch bản cho dự án phần mềm liên quan đến thời gian biểu và ngân sách

Bảng 3.1 Các kiểu kế hoạch cần cho dự án

Kế hoạch Mô tả

Kế hoạch chất lượng Mô tả thủ tục và chuẩn sẽ được sử dụng dự án Kế hoạch kiểm thử Mô tả cách tiếp cận, nguồn tài nguyên và lịch trình được sử dụng

để kiểm thử dự án

Kế hoạch quản lý cấu hình Mơ tả thủ tục quản lý cấu hình và cấu trúc được sử dụng Kế hoạch bảo trì Dự đốn những u cầu bảo trì hệ thớng, chi phí cho bảo trì

và yêu cầu cần đạt được

Kế hoạch phát triển nhân lực Mô tả cách thức để phát triển kỹ và kinh nghiệm những thành viên tham gia dự án

a) Tiến trình lập kế hoạch dự án

Biểu đồ hình 3.2 mơ tả tiến trình lập kế hoạch dự án cho phát triển phần mềm Hình vẽ này việc lập kế hoạch là mợt tiến trình liên tục, bắt đầu từ triển khai dự án dự án kết thúc Đây là một thông tin có giá trị śt thời gian thực dự án, kế hoạch dự án cần phải được xem xét lại một cách thường xuyên Mục tiêu tổ chức là vấn đề quan trọng dự án, những mục tiêu này thường xuyên thay đổi, nên kế hoạch dự án có thay đổi là cần thiết

Trong thời gian đầu tiến trình lập kế hoạch, ta cần xem xét đến ràng ḅc có ảnh hưởng đến dự án thời hạn giao nộp sản phẩm, những nhân viên tham gia vào dự án và nguồn ngân sách giành cho dự án Từ ước lượng tham sớ dự án, chẳng hạn như: cấu trúc, kích thước, phân tán chức Tiếp theo người quản lý dự án cần phải xác định được mốc quan trọng và thời gian giao nộp sản phẩm Tiến trình sau rơi vào mợt vịng lặp Người quản lý phải đưa một thời gian biểu ước lượng cho dự án và xác định hoạt động thời gian biểu đưa Sau thỉnh thoảng (khoảng 2-3 tuần) nên xem xét lại tiến trình và ghi lại những điểm không phù hợp với thời gian biểu được lập Vì những ước tính ban đầu là tương đối nên kế hoạch thường phải điều chỉnh

Khi có nhiều thơng tin có ích hơn, cần xem xét lại những tham số ban đầu dự án và thời gian biểu dự án Nếu dự án bị chậm tiến độ, người quản lý thỏa thuận lại với khách hàng những ràng buộc và thời gian bàn giao sản phẩm Nếu thỏa thuận không thành công và thời gian biểu không đáp ứng được, chuyên gia kỹ thuật giúp nhà quản lý khắc phục khó khăn Mục tiêu việc xem xét lại kế hoạch là nhằm giúp tìm những giải pháp tới ưu để khắc phục những vấn đề nảy sinh

(51)

và thời gian biểu ban đầu nên bi quan là lạc quan Khi xây dựng kế hoạch, nên xem xét đủ yếu tố ngẫu nhiên để tránh việc phải đàm phán lại mợt vịng lặp được hoàn thành

Hình 3.2 Tiến trình lập kế hoạch thực dự án

b) Cấu trúc kế hoạch dự án

Kế hoạch dự án thiết lập những tài nguyên sử dụng cho dự án, phân chia công việc lịch trình thực cơng việc Kế hoạch dự án mợt tài liệu nhất, bao gồm nhiều loại khác giới thiệu Trong trường hợp khác, kế hoạch dự án liên quan đến tiến trình phát triển phần mềm Sự thay đổi chi tiết kế hoạch dự án phụ thuộc vào kiểu dự án tổ chức thực dự án Tuy nhiên, hầu hết bản kế hoạch dự án bao gồm thành phần sau:

Giới thiệu: Mơ tả tóm tắt những mục tiêu dự án và đưa những ràng buộc (thời gian,

ngân sách ) có ảnh hưởng tới việc quản lý dự án

Tổ chức dự án: giới thiệu tóm tắt tổ chức phát triển dự án, những người tham gia và

vai trò họ dự án

Phân tích rủi ro: Nêu lên những rủi ro xảy và khả xảy rủi ro này là cao

hay thấp, đồng thời đưa những chiến lược để giảm được tối đa những rủi ro

Thiết lập ràng buộc dự án

Ước lượng tham số ban

đầu

Xác định mốc, sản

phẩm

Lập/điều chỉnh lịch trình

Xử lý rủi ro, định (nếu có)

Triển khai công việc theo lịch

Thỏa thuận lại hạn chế, sản phẩm tới

khách

Theo dõi, xử lý tình h́ng định kỳ

Cập nhật tiến trình, dữ liệu

Xem xét, đánh giá

(52)

Cơ chế kiểm tra giám sát báo cáo: Chỉ việc quản lý báo cáo, nào cần đưa

báo cáo và chế nào được sử dụng để giám sát báo cáo

Kế hoạch dự án cần được định kỳ lặp lại q trình thực dự án Mợt vài thành phần lịch trình dự án sẽ thay đổi thường xuyên, những phần khác tương đối ổn định Tài liệu phải được tổ chức cho phép dễ dàng sửa đổi thay những phần được sử dụng tiếp c) Các mốc quan trọng sản phẩm bàn giao

Vì phần mềm là mợt sản phẩm vơ hình nên thơng tin sản phẩm là những báo cáo và tài liệu mô tả giai đoạn phần mềm được phát triển Thiếu những thông tin này, người quản lý không nắm được tiến trình dự án để có những điều chỉnh phù hợp Các hoạt động một dự án cần phải được tổ chức theo những quy trình rõ ràng, cụ thể cho việc quản lý để đánh giá tiến triển cơng việc

Hình 3.3 Các cợt mốc tiến trình xác định yêu cầu

Khi lập kế hoạch cho một dự án, ta cần đưa những mốc thời gian quan trọng, thời điểm kết thúc mợt hoạt đợng tiến trình cơng việc Với mốc thời gian quan trọng, cần đưa một đầu cụ thể, chẳng hạn là một tài liệu, tài liệu này không cần chi tiết mà đơn giản là tóm tắt được cơng việc hoàn thành mốc này

Thời hạn bàn giao sản phẩm là việc đưa kết quả dự án tới khách hàng Nó thường được bàn giao những giai đoạn chẳng hạn đặc tả hoặc thiết kế Thời hạn bàn giao là một mốc quan trọng, mốc quan trọng lại không phải là thời hạn bàn giao Những mớc quan trọng là những kết quả bên dự án, được người quản lý sử dụng để kiểm tra tiến độ dự án không giao nộp cho khách hàng Để thiết lập mớc, tiến trình phầm mềm cần được phân thành những hoạt động bản với đầu cụ thể kèm hình 3.3

3.2.3 Lập lịch dự án a) Tiến trình lập lịch

Nhìn chung, việc đánh giá thời gian biểu một dự án là mợt cơng việc khó khăn, trừ những dự án tương tự với dự án thực trước đó, việc xác định thời gian biểu dự án thường không chắc chắn và phụ thuộc vào nhiều yếu tớ khác nhau, ví dụ phương pháp thiết kế, mơ hình phát triển hoặc ngơn ngữ thực

Tiến trình lập lịch trình dự án được thể hình vẽ 3.4, liên quan đến việc chia một dự án thành hoạt động riêng rẽ và ước lượng thời gian để hoàn thành hoạt đợng này Tuy nhiên, có mợt sớ hoạt đợng được tiến hành song song, cần phải tính tốn cả phương án lựa chọn nhân cho hoạt đợng cho dự án có hiệu quả nhất, tránh tình trạng dự án bị chậm tiến đợ một công việc quan trọng chưa hoàn thành

Nghiên cứu khả thi Phân tích yêu cầu Phát triển bản mẫu Nghiên cứu thiết kế

Đặc tả yêu cầu

Báo cáo khả thi

Yêu cầu

người dùng Báo cáo tiến hóa

Thiết kế kiến trúc

Yêu cầu hệ thống

Các cột mớc và sản phẩm bàn giao

Hình 3.3 Các cợt mốc tiến trình xác định u cầu

Yêu cầu phần

(53)

Hình 3.4 Tiến trình lập lịch cho hoạt đợng dự án

Sau xác định được công việc, cần ước lượng thời gian thực công việc Nguyên tắc ước lượng thời gian tiến hành cho cơng việc nhỏ, từ ước lượng cho những cơng việc được gợp lại Việc ước lượng thời gian theo kinh nghiệm Trong phương pháp PERT (Program Evaluation and Review Technicques), ước lượng thời gian công việc dựa ba ước lượng:

- Ước lượng khả dĩ (ML – Most likely) thời gian cần thiết để hồn thành cơng việc điều kiện “bình thường”

- Ước lượng lạc quan (Mo – Most Optimistic) thời gian cần thiết để hồn thành cơng việc điều kiện “lý tưởng”

- Ước lượng bi quan (MP – Most Pessimistic) thời gian cần thiết để hồn thành cơng việc điều kiện “tồi nhất”

Ước lượng cuối thời gian thực cơng việc tính theo: tcv = (MO + 4ML + MP)/6 Các hoạt động dự án thường diễn mợt tuần, vậy, việc phân chia công việc hiệu quả là công việc nên thực vòng từ tám đến mười tuần, thời gian này, nên chia thành những công việc nhỏ

Người quản lý phải đánh giá tài nguyên cần thiết để hoàn thành cơng việc Tài ngun là người, dung lượng đĩa cần thiết máy chủ, chi phí cần thiết cho những phần cứng đặc biệt, chi phí lại cần thiết cho nhân viên dự án… Việc dự tốn tài ngun cho cơng việc được tiến hành dựa kinh nghiệm hay số liệu thống kê dự án thực

(54)

Phương pháp đường găng (CMP – Critical Path Method) thường được sử dụng hoạt động lập lịch Phương pháp này sử dụng một sơ đồ mạng công việc, mợt đồ thị có hướng, cung biểu diễn một công việc, đỉnh biểu diễn một kiện là điểm bắt đầu hay kết thúc mợt sớ cơng việc Có mợt đỉnh bắt đầu cho dự án là đỉnh mà cơng việc một đỉnh kết thúc, công việc cuối dự án vào Trên cung có ghi tên cơng việc thời gian thực Hình 3.5 kí hiệu biểu diễn thành phần sơ đồ mạng

Hình 3.5 Các ký pháp sơ đồ mạng

Tiến trình lập lịch được mô tả sơ đồ mô tả hình 3.6

Hình 3.6 Tiến trình lập lịch biểu sơ đồ mạng a) Xác định đỉnh trung gian sơ đồ mạng

Xuất phát từ bảng liệt kê công việc dự án (bảng 3.2), ta tiến hành đánh dấu công việc cột thứ ba (cột “đi sau công việc”) sau:

Bước 1: Duyệt lần lượt từ xuống, đánh dấu khoanh trịn cho chữ (cơng việc) (cặp 2/cặp 3) dòng chưa được đánh dấu và chưa bị xóa Các cơng việc được khoanh mợt dịng sẽ xác định mợt đỉnh trung gian sau chúng sơ đồ mạng

Bước 2: Xóa tên tất cả cơng việc được khoanh mà có mặt dịng khác chứa 2/3 … công việc quay bước

Bước 3: Nếu dịng chứa cơng việc được khoanh hay bị xóa hết, xét đến dịng chứa 2/(3) cơng việc chưa được khoanh và chưa bị xóa Lặp lại bước và khơng cịn cơng việc cợt cịn chưa khoanh hay chưa bị xóa

Áp dụng thuật tốn cho bảng cơng việc, ví dụ ta có kết quả bảng sau:

Bảng 3-2 Bảng liệt kê công việc dự án đánh dấu

Công

việc Thời gian tcv Đi sau công việc Công việc

Thời gian

tcv Đi sau công việc

a _ k , i

b _ m

Tên công việc (thời gian) Công việc

Công việc giả (biểu diễn ràng buộc)

i ; ; n Sự kiện (đỉnh), bắt đầu, kết thúc

Xác định đỉnh trung gian

Vẽ sơ đồ mạng

Tính tham sớ

Tìm đường Gantt

Chuyển sang sơ đồ Gantt

Lịch biểu bước đầu

Lịch biểu cân đối Bảng

công việc

Cân đối sử dụng nguồn

lực

(55)

c _ l

d _ n

e o

f p g, i,

g q g, i,

h r

I s

b) Vẽ sơ đồ mạng 1 Vẽ đỉnh

2 Vẽ công việc từ đỉnh (dựa vào bảng mô tả công việc) xem công việc những công việc sau công việc kết thúc đỉnh xét Trong trường hợp đỉnh là cơng việc khơng sau cơng việc nào (như hình a, b, c, d)

3 Sau công việc vừa được vẽ ta sẽ thêm vào mợt đỉnh trung gian được khoanh riêng rẽ bảng cơng việc Nếu được khoanh với công việc khác mà chúng được vẽ mạng chụm chúng lại và thêm vào mợt đỉnh Ngược lại giữ ngun trạng

4 Xét tiếp một đỉnh vừa được thêm vào quay lại bước

5 Khi vẽ hết công việc bảng, tất cả công việc chưa có đỉnh sau chụm chúng lại đỉnh kết thúc (n) được thêm vào cuối

6 Xét cơng việc bị xóa cột bảng công việc:

- Nếu mợt dịng có cơng việc bị xóa thêm một đỉnh giả công việc giả từ đỉnh kết thúc cơng việc bị xóa đến đỉnh

- Nếu mợt dịng vừa có cơng việc bị xóa, vừa có cơng việc được khoanh thêm mợt cơng việc giả từ đỉnh kết thúc cơng việc được xóa (kể cả đỉnh giả) đến đỉnh kết thúc công việc được khoanh

7 Đánh số đỉnh theo thứ tự tăng dần và đảm bảo đỉnh đầu công việc nhỏ đỉnh cuối công việc

Kết quả vẽ mạng công việc bảng 3.2 được thể hình 3.7a c) Tính tham số thời gian mạng

a b c d e, f

i k l, n

(56)

ts(j) = Max {ts(đỉnh đầu cv) + tcv}

 Thời gian muộn đỉnh: tm(i)

Q trình tính ngược lần lượt từ đỉnh lớn đến đỉnh nhỏ, bắt đầu từ đỉnh n: - tm(n) = ts(n)

- đỉnh i (i = n-1, …, 0):

tm(i) = Min {tm(đỉnh đầu cv) - tcv}

Hình 3.7 a) Sơ đồ mạng vẽ từ bảng công việc (bảng 3.2) b) Sơ đồ mạng với tham số thời gian đường găng

 Thời gian dự phịng cơng việc: tdf(cv)

tdf(cv) = tm(đỉnh cuối cv) - ts(đỉnh đầu cv) - tcv d) Tìm cơng việc găng đường Gantt

Những cơng việc Gantt (nét đậm hình 3.7) những cơng việc có thời gian dự phịng bằng (tdf(cv ) = 0) Khi đường Gantt là đường gồm công việc găng từ đỉnh bắt đầu đến đỉnh kết thúc Độ dài đường (18 ngày hình 3.7b) là đợ dài ngắn cần thiết để thực dự án (vì chưa kể đến điều kiện ràng buộc nguồn lực khác) Nếu kéo dài thời gian thực một công việc nào đường găng dẫn đến việc kéo dài thời gian thực dự án Vì thế, cơng việc Gantt được đặc biệt ý theo dõi giám sát dự án Trong trường hợp cần thiết, chia nhỏ những cơng việc Gantt (nếu có thể), vẽ lại mạng cơng việc tính tốn lại, hy vọng rút ngắn thời gian thực dự án

0

1

3

5

6

8

9 11 12

10 a(1)

b(5) c(6)

d(4) g(3)

f(3) e(4) i(2) k(2) h(4) n(2) i(3) m(6)

0(1) r(2)

s(1)

q(3) p(2)

13

Mỗi cạnh là mợt cơng việc, có chữ là tên và số ngoặc là thời gian thực a)

5

6

8

9 11 12

10 a(1)/3

b(5)/0 c(6)/1

d(4)/5 g(3)/1

f(3)/0 e(4)/2 i(2)/0 k(2)/0 h(4)/5 n(2)/0 i(3)/2 m(6)/3

o(1)/0 r(2)/0

s(1)/0

q(3)/1 p(2)/1

13

2 số đỉnh là thời gian sớm và muộn đỉnh số cạnh là thời gian thực và dự trữ công việc

b) 1/4 5/5 6/7 4/9 10/10

8/8 10/10

14/14 15/15

18/18

17/17

10/13 (mọi cv

vào đỉnh j)

(57)

e) Chuyển sang sơ đồ Gantt

Sau tính tốn tham số công việc và đỉnh mạng cơng việc, ta chuyển sang biểu đồ Gantt (hình 3.8) để dễ quan sát theo dõi quản lý dự án Trong biểu đồ Gantt, cơng việc biểu diễn mợt khới chữ nhật có độ dài thời gian thực công việc Điểm bắt đầu được đặt thời điểm thời gian bắt đầu sớm đỉnh mà công việc Đường nét đứt thời gian dự phịng cơng việc Những cơng việc găng có hai đầu phình to Nhìn biểu đồ ta thấy rõ ngày bắt đầu ngày kết thúc công việc khả kéo dài chúng

Ngoài sơ đồ mạng công việc biểu đồ Gantt, người ta dùng biểu đồ cơng việc dạng khới (hình 3.9) hay dạng lịch trình (bảng 3.3) để trợ giúp hoạt đợng quản lý dự án Các sơ đồ bảng biểu dữ liệu sau chu kỳ quản lý lại được cập nhật lại, phục vụ cho chu kỳ Tất cả sơ đồ, biểu đồ và tính tốn theo vừa nêu tạo một cách tự động phần mềm quản lý dự án

Tên công việc Thời gian thực (ngày)

1 10 11 12 13 14 15 16 17 18

(58)

Hình 3.9 Biểu đồ khối lịch trình cơng việc Bảng 3.3 Bảng phân công công việc

TT Tên công việc Thời gian thực

hiện Ngày bắt đầu Ngày kết thúc Người thực

1 Thiết kế logic 30/6/97 25/7/97 Trần Trung Dũng

2 Thiết kế vật lý 12 28/7/97 17/10/97 Hồng Tùng

3 Mã hóa 20/10/97 28/11/97 Hoàng Lan

4 Kiểm thử 1/12/97 19/12/97 Vũ Trung Dũng

5 Làm tài liệu Trần Quốc Cường

6 Đào tạo Đào Xuân Hưng

7 Chuyển giao 22/12/97 28/12/97 Nguyễn Thành Trung

3.3 QUẢN LÝ RỦI RO ĐỐI VỚI DỰ ÁN PHÁT TRIỂN PHẦN MỀM

Quản lý rủi ro coi là mợt những cơng việc người quản lý dự án Nó liên quan đến việc chớng lại những rủi ro mà ảnh hưởng tới lịch làm việc và chất lượng phần mềm được phát triển, từ có hành đợng để tránh những rủi ro này Kết quả việc phân tích rủi ro nên đưa thành văn bản gắn liền với bản kế hoạch dự án cùng với phân tích hậu quả và nguy xảy rủi ro Việc quản lý rủi ro một cách hiệu quả giúp ta dễ đới phó với những vấn đề phát sinh và không làm cho việc vượt ngân sách hoặc vượt thời hạn trở nên không kiểm soát

3.3.1 Khái niệm rủi ro

Mợt rủi ro là khả mợt vài tình huống bất lợi sẽ xảy ra, đối với dự án phần mềm, rủi ro rơi vào trường hợp sau:

- Rủi ro dự án ảnh hưởng tới thời gian biểu hoặc tài nguyên Ví dụ: mợt người thiết kế có kinh nghiệm

- Rủi ro sản phẩm ảnh hưởng tới chất lượng hoặc hiệu quả phần mềm được phát triển Ví dụ: lỗi mợt thành phần mua để thực không mong muốn

- Rủi ro kinh doanh ảnh hưởng tới tổ chức phát triển phần mềm hoặc người mua sản phẩm phần mềm Ví dụ: Đới thủ cạnh tranh giới thiệu sản phẩm có chức tương tự

Thiết kế logic Tuần 30/6/97 25/7/97

Thiết kế vật lý 12 Tuần 28/7/97 17/10/97

Mã hóa Tuần 20/10/97 28/11/97

Làm tài liệu Tuần

Chuyển giao Tuần 22/12/97 28/12/97 Kiểm thử

4 Tuần 1/12/97 19/12/97

(59)

Tất nhiên những rủi ro này thường xếp chồng lên nhau, mợt lập trình viên có kinh nghiệm rời bỏ dự án, coi là mợt rủi ro dự án thời hạn giao nợp sản phẩm bị chậm lại Nó là một rủi ro sản phẩm việc thay mợt lập trình viên khơng có kinh nghiệm làm cho phần mềm có nhiều lỗi, là mợt rủi ro kinh doanh người lập trình có kinh nghiệm này sẽ khơng tham gia vào những dự án

Sự ảnh hưởng những rủi ro này cịn phụ tḥc vào dự án và môi trường tổ chức phát triển phần mềm Tuy nhiên, có nhiều rủi ro thực chất là mợt và ta phân loại theo bảng 3.4

Bảng 3.4 Bảng phân loại rủi ro

Rủi ro Ảnh hưởng Mô tả

Sự luân chuyển cán bộ

Dự án Nhân viên có kinh nghiệm sẽ rời khỏi dự án trước

nó hoàn thành

Thay đổi quản lý Dự án Có thay đổi ưu tiên quản lý tổ chức Phần cứng không

sẵn sàng

Dự án Trang thiết bị được dự trù là cần thiết cho dự án không được chuyển đến thời hạn

Thay đổi yêu cầu Dự án và sản phẩm Số lượng những thay đổi đối với u cầu lớn dự đốn

Chậm tiến đợ Dự án và sản phẩm Những yếu tố bản không sẵn sàng thời gian biểu

Sự đánh giá thấp dự án

Dự án và sản phẩm Kích thước hệ thớng bị đánh giá thấp so với thực tế Những công cụ

CASE không đủ mạnh

Sản phẩm Công cụ cung cấp cho dự án không đáp ứng được

những yêu cầu ban đầu Thay đổi công

nghệ

Kinh doanh Những công nghệ bản để xây dựng hệ thống bị thay những công nghệ

3.3.2 Tiến trình quản lý rủi ro

(60)

- Kiểm soát rủi ro: Kiểm soát rủi ro śt dự án

Tiến trình quản lý rủi ro việc lập kế hoạch dự án là mợt tiến trình liên tục, xun śt dự án Vì cần phải tài liệu hóa hậu quả tiến trình quản lý rủi ro mợt kế hoạch quản lý rủi ro Tài liệu này bao gồm việc thảo luận những rủi ro mà dự án sẽ phải đới mặt, bản phân tích rủi ro và những chiến lược đưa để kiểm soát những rủi ro này Ở vị trí thích hợp, người quản lý nên đưa kế hoạch tiến trình quản lý rủi ro Tiến trình quản lý rủi ro được minh họa hình 3.10

Hình 3.10 Tiến trình quản lý rủi ro a) Xác định rủi ro

Xác định rủi ro là giai đoạn đầu tiến trình quản lý rủi ro Mục đích giai đoạn khám phá những rủi ro đối với dự án Việc xác định rủi ro được thực cách thành lập mợt nhóm làm việc riêng, sử dụng cách tiếp cận brainstorming (tập hợp những thành viên quan trọng dự án) hoặc đơn giản dựa kinh nghiệm Để giúp cho trình xác định rủi ro, người ta đưa một số loại rủi ro thường gặp:

- Rủi ro mặt công nghệ: liên quan đến công nghệ phần cứng và phần mềm được sử dụng để phát triển dự án Ví dụ: Cơ sở dữ liệu sử dụng hệ thống xử lý nhiều giao dịch cùng một thời điểm; Các thành phần phần mềm được tái sử dụng có chứa những khuyết điểm làm hạn chế chức hệ thống

- Rủi ro nhân lực: liên quan đến những nhân viên làm việc nhóm phát triển Ví dụ: khơng thể thành lập mợt đợi ngũ nhân viên có những kỹ theo yêu cầu; những nhân viên quan trọng bị ốm và làm việc những thời điểm quan trọng; yêu cầu đào tạo huấn luyện nhân viên không được đáp ứng

- Rủi ro mặt tổ chức: xuất phát từ môi trường tổ chức, nơi phát triển dự án Ví dụ: Tổ chức được cấu trúc lại và thay đổi người quản lý dự án; những vấn đề tài dự án gặp khó khăn làm giảm ngân sách giành cho dự án

- Rủi ro công cụ: xuất phát từ những công cụ hỗ trợ việc phát triển hệ thống Chẳng hạn như: mã nguồn được sinh công cụ CASE không hiệu quả; công cụ CASE tích hợp lại với

- Rủi ro yêu cầu phần mềm: xuất phát từ việc yêu cầu phần mềm khách hàng có thay đổi Đặc biệt việc thay đổi yêu cầu địi hỏi phải thiết kế lại những cơng việc chính, yêu cầu không sử dụng được nữa, khách hàng hiểu sai ảnh hưởng những thay đổi yêu cầu

- Rủi ro ước lượng: xuất phát từ việc ước lượng khơng xác thời gian, tài nguyên cần để phát triển dự án Ví dụ: thời gian cần thiết để phát triển phần mềm ngắn, tỷ lệ tài nguyên cần cho việc sửa lỗi bị đánh giá thấp, kích thước phần mềm bị đánh giá thấp…

Xác định rủi ro Phân tích rủi ro Lập kế hoạch rủi ro Kiểm soát rủi ro

Danh sách rủi ro tiềm ẩn

Danh sách rủi ro

(61)

Khi hoàn thành việc xác định những rủi ro, quản lý dự án nên đưa mợt danh sách những rủi ro xảy và đánh giá khả xảy những rủi ro này mức độ ảnh hưởng tới sản phẩm, tới tiến trình và tới mục tiêu kinh doanh tổ chức

b) Phân tích rủi ro

Trong q trình phân tích rủi ro, nhóm quản lý dự án phải xem xét một cách cụ thể trường hợp rủi ro được xác định và đánh giá khả xảy tính nghiêm trọng rủi ro Đây không phải là một công việc đơn giản, người thực phải dựa vào phán xét và kinh nghiệm bản thân, điều này giải thích lại đòi hỏi những người làm quản lý dự án phải có kinh nghiệm Việc ước lượng rủi ro nói chung khơng phải là mợt sớ xác, mà người ta dựa vào mợt khoảng sớ liệu: Khả xảy là thấp (<10%), thấp (10-25%), trung bình (25-50%), cao (50-75%) hoặc cao (>75%) Ảnh hưởng rủi ro là khủng khiếp, nghiêm trọng, bỏ qua được hoặc khơng quan trọng

Bảng 3.5 Bảng đánh giá một số tình rủi ro

Rủi ro Khả

xảy

Ảnh hưởng

Vấn đề tài tổ chức gặp khủng hoảng và phải giảm ngân sách cho dự án

Thấp Rất nghiêm trọng

Không thể thành lập một đợi ngũ nhân viên có những kỹ theo u cầu

Cao Rất nghiêm trọng

Những nhân viên quan trọng bị ốm và làm việc những thời điểm quan trọng

Trung bình Nghiêm trọng Các thành phần phần mềm được sử dụng lại có chứa những

khuyết điểm làm hạn chế khả hệ thớng

Trung bình Nghiêm trọng Việc thay đổi yêu cầu đòi hỏi phải thiết kế lại những cơng

việc

Trung bình Nghiêm trọng Tổ chức được cấu trúc lại và thay đổi người quản lý dự án Cao Nghiêm trọng Cơ sở dữ liệu sử dụng hệ thống xử lý nhiều

giao dịch cùng một thời điểm

Thấp Khủng khiếp

Ước lượng: thời gian cần thiết để phát triển ngắn Cao Nghiêm trọng

Các công cụ CASE khơng thể tích hợp lại với Cao Có thể bỏ qua

Khách hàng hiểu sai ảnh hưởng những thay đổi yêu cầu Trung bình Có thể bỏ qua Yêu cầu đào tạo huấn luyện nhân viên khơng được đáp ứng Trung bình Có thể bỏ qua

Kích thước phần mềm bị đánh giá thấp Cao Có thể bỏ qua

Tỷ lệ việc sửa lỗi bị đánh giá thấp Trung bình Có thể bỏ qua

(62)

c) Lập kế hoạch phòng ngừa – hạn chế rủi ro

Bước lập kế hoạch để phòng ngừa hạn chế rủi ro cần phải xem xét rủi ro được xác định và đưa chiến lược quản lý Các chiến lược quản lý rủi ro nhìn chung phức tạp, cần phải được xem xét cân nhắc trường hợp cụ thể Dưới chiến lược xử lý rủi ro:

- Chấp nhận rủi ro: Khơng làm cả Chiến lược này được sử dụng xác suất xảy rủi ro và tác động chúng tối thiểu, chúng xảy dễ dàng xử lý

- Tránh rủi ro: để tránh rủi ro, ta bỏ phần dự án liên quan đến rủi ro, tức làm thay đổi phạm vi dự án hoặc thay đổi phạm vi nghiệp vụ Ở trường hợp này, những thay đổi cần được chủ dự án khách hàng chấp nhận, hậu quả tất yếu thu nhập chi phí thường giảm

- Giám sát chuẩn bị dự phịng: chọn mợt sớ để xác định xem rủi ro đến hay chưa Ví dụ: rủi ro liên quan đến thầu phụ, cần cập nhật trạng thái tiến độ họ Kế hoạch đáp ứng được chuẩn bị trước rủi ro xảy Cách thường được thực là lưu lại mợt phần kinh phí

- Chuyển rủi ro cho người khác: Chuyển rủi ro cho người khác mua bảo hiểm Có nhiều phương pháp, ký một hợp đồng dịch vụ có giá cớ định Khi chuyển rủi ro cho thầu phụ Tuy nhiên, trường hợp này làm nảy sinh những rủi ro mới, cần phải tính tốn mợt cách cụ thể Phần quan trọng chiến lược này là xác định được điều khoản hợp đồng hiệu quả quản lý tốt nhà thầu phụ

- Hạn chế rủi ro: Hạn chế hay giảm tác động rủi ro biện pháp đầu tư hay nỗ lực nhiều hơn, bao gồm tất cả những mà đợi dự án làm để vượt qua được rủi ro từ mơi trường dự án

d) Kiểm sốt rủi ro

Là việc đánh giá rủi ro được xác định một cách thường xuyên để định khả xảy những rủi ro này là tăng hay giảm, đồng thời đánh giá lại mức độ ảnh hưởng rủi ro Những rủi ro quan trọng cần được thảo luận những cuộc họp quản lý tiến trình

Tất nhiên, những cơng việc này thường không quan sát được một cách trực tiếp, bạn phải nhìn vào những yếu tớ khác để xác định khả xảy và mức độ ảnh hưởng rủi ro Những nhân tớ này ảnh hưởng kiểu rủi ro, bảng 3.6 đưa mợt vài ví dụ nhân tớ giúp bạn đánh giá được rủi ro dựa theo những kiểu rủi ro này

Bảng 3.6 Các yếu tố rủi ro

Kiểu rủi ro Chỉ dẫn

Công nghệ Chậm bàn giao phần cứng hoặc phần mềm trợ giúp, nhiều vấn đề công nghệ gián tiếp

Con người Tinh thần làm việc nhân viên thấp, quan hệ giữa những nhân viên đợi lỏng lẻo, nhân viên có những hoạt động ngoài dự án

Tổ chức Tin đồn nhảm tổ chức, thiếu những hoạt động người quản lý cấp cao Công cụ Các thành viên đội không sẵn sàng sử dụng công cụ, phàn nàn

(63)

Ước lượng Không thực được thời gian biểu, không sửa được báo lỗi khiếm khuyết

3.4 KẾT THÚC DỰ ÁN

Đây là thời điểm hoàn tất dự án Kết thúc dự án diễn sau giai đoạn triển khai thực Giai đoạn bảo trì thường được coi việc tiếp tục dự án khác, dự án sẽ được quản lý riêng Kết thúc dự án bao gồm công việc sau:

- Đóng dự án: Để đánh dấu hồn tất một dự án, cần thực một số hoạt động đánh giá thành viên, kiến nghị lợi ích cho họ, hồn thiện tài liệu chứng từ tốn Cảm ơn những người đóng góp, tham gia và hỗ trợ q trình cơng việc

- Tổng kết sau dự án: Mục tiêu hoạt động xác định và đánh giá được mặt mạnh, mặt yếu sản phẩm dự án, trình phát triển sản phẩm, trình quản lý dự án Từ rút những kinh nghiệm cần thiết cho dự án sau

- Kết thúc mọi hợp đồng: Ký kết bản lý hợp đồng với khách hàng nhà cung cấp

3.5 CẤU TRÚC TÀI LIỆU QUẢN LÝ DỰ ÁN GIỚI THIỆU CHUNG

1.1 Mơ tả tóm tắt dự án 1.2 Các giả thiết ràng buộc TỔ CHỨC DỰ ÁN

2.1 Cấu trúc tổ chức

2.2 Các thành viên đội dự án RỦI RO CỦA DỰ ÁN

3.1 Danh sách rủi ro

3.2 Đánh giá và quản lý rủi ro

4 CÔNG CỤ VÀ CƠ SỞ HẠ TẦNG THỰC HIỆN DỰ ÁN 4.1 Phần cứng

4.2 Phần mềm

4.3 Cơ sở hạ tầng khác

(64)

7.3 Trao đổi thông tin với khách hàng

7.4 Trao đổi thông tin với đối tượng khác CÂU HỎI ƠN TẬP

1 Hãy giải thích cần phải có nhóm chịu trách nhiệm quản lý dự án phần mềm Phân tích những khó khăn quản lý dự án phần mềm so với dự án khác Nêu những công việc bản người làm quản lý dự án

4 Phân tích tiến trình lập kế hoạch dự án Kế hoạch dự án sản phẩm làm một lần hay thường xuyên thay đổi suốt thời gian tồn dự án?

5 Mốc thời gian quan trọng dự án gì? Mợt dự án có những mốc thời gian quan trọng nào? Mốc thời gian quan trọng thời điểm bàn giao sản phẩm phần mềm có phải mợt hay khơng?

6 Vai trị quản lý rủi ro tiến trình phần mềm? Có những loại rủi ro nào?

(65)

Chương 4: XÁC ĐỊNH VÀ ĐẶC TẢ YÊU CẦU PHẦN MỀM

Yêu cầu đối với một hệ thống phần mềm là những mô tả dịch vụ được cung cấp hệ thống, những ràng buộc đối với chức và trình phát triển sản phẩm Những yêu cầu này phản ánh nhu cầu khách hàng đới với hệ thớng Qua sẽ giúp họ giải những vấn đề họ, chẳng hạn hệ thống điều khiển một thiết bị, đặt hàng và tìm kiếm thơng tin sản phẩm, quản lý tài chính, quản lý nhân Tiến trình tìm kiếm, phân tích, tài liệu hóa u cầu phần mềm, kiểm tra dịch vụ và ràng buộc gọi là kỹ nghệ yêu cầu (RE – Requirement Engineering)

Chương này giới thiệu nợi dung sau: định nghĩa kiểu yêu cầu phần mềm; mức hình thức diễn tả yêu cầu phần mềm; tìm hiểu kỹ nghệ yêu cầu và đặc tả tài liệu yêu cầu phần mềm

4.1 TỔNG QUAN VỀ YÊU CẦU PHẦN MỀM 4.1.1 Khái niệm yêu cầu phần mềm

Trước tiến hành xây dựng mợt hệ thớng phần mềm, nhóm phát triển cần phải hiểu được bản chất vấn đề cần giải Đây thường một công việc phức tạp, với những dự án hay một hệ thớng tồn được dùng làm mơ hình cho phần mềm muốn phát triển Trên thực tế, người ta thường không phân biệt được hai khái niệm yêu cầu nhu

cầu, chúng được hiểu Mợt tổ chức định họ “cần hệ thống

phần mềm trợ giúp cơng việc kế tốn” Nhưng việc đưa mợt nhu cầu đơn giản cho nhóm phát triển phần mềm hy vọng có được mợt hệ thống phần mềm chấp nhận được dùng tốt là điều Thông tin vấn đề cần được giải phải được thu thập, phân tích, xác định nội dung vấn đề một cách rõ ràng, đầy đủ có được những u cầu xác cho hệ thớng Khi đưa được mợt giải pháp cho việc thiết kế thực thi hệ thống đáp ứng được những yêu cầu đề

Quá trình thiết lập dịch vụ mà hệ thống phải cung cấp ràng buộc mà hệ thống phải tuân thủ hoạt động hay phát triển gọi tìm hiểu phân tích u cầu Kết quả

của công việc đặc tả yêu cầu, thường là tư liệu thức được tạo tiến trình phần mềm Yêu cầu cho một hệ thống phần mềm mô tả những công việc mà hệ thống sẽ làm những ràng ḅc mà phải tn thủ hoạt đợng Yêu cầu yêu cầu

chức (các chức năng, dịch vụ) hoặc yêu cầu phi chức (các ràng buộc)

(66)

2 Yêu cầu hệ thống (system requirements) nêu dịch vụ hệ thống chi tiết

các ràng ḅc Tài liệu này đơi gọi là đặc tả chức – cần phải rõ ràng xác Nó được sử dụng làm sở cho hợp đồng giữa người mua và người phát triển phần mềm

3 Đặc tả phần mềm (software specification) mô tả khái quát chức phần

mềm trợ giúp hoạt động nghiệp vụ, làm sở để thiết kế triển khai phần mềm sau Tài liệu đặc tả phần mềm được bổ sung thêm chi tiết để trở thành tài liệu đặc tả yêu cầu hệ thống

Hình 4.1 ví dụ u cầu người dùng chức hệ thống quản lý thư viện chi tiết hóa yêu cầu người dùng thành u cầu hệ thớng

Hình 4.1 u cầu người dùng yêu cầu hệ thống

Việc mô tả yêu cầu hệ thống mức trừu tượng khác cần thiết, chúng giúp truyền đạt thơng tin hệ thớng tới đới tượng người đọc khác Hình vẽ 4.2 biểu diễn lớp người đọc tương ứng với mức trừu tượng khác tài liệu yêu cầu

Hình 4.2 Đối tượng đọc tài liệu đặc tả khác

Yêu cầu người dùng phải định hướng tới mức quản lý, tức cả khách hàng ban quản lý hiểu được Trong đó, đặc tả u cầu hệ thớng lại hướng tới nhóm kỹ thuật những người quản lý dự án Người sử dụng hệ thớng đọc cả hai loại tài liệu nói Ći cùng, đặc tả yêu cầu phần mềm tài liệu hướng tới việc triển khai Nó được viết cho kỹ sư phần mềm những người tham gia vào trình phát triển hệ thống

4.1.2 Phân loại yêu cầu phần mềm

Yêu cầu hệ thống thường được phân thành loại: yêu cầu chức năng, yêu cầu phi chức và yêu cầu miền lĩnh vực ứng dụng phần mềm

Yêu cầu người dùng

Đặc tả phần mềm

1 Người quản lý khách hàng Người quản lý thầu

3 Người dùng hệ thống Kỹ sư khách hàng Người thiết kế hệ thống Người phát triển phần mềm

Yêu cầu hệ thống

Yêu cầu người dùng

Hệ thống phải lưu trữ được toàn bộ thông tin cần thiết để quản lý bản quyền tác giả

Đặc tả yêu cầu hệ thống

1.1 Với yêu cầu mượn tài liệu, người sử dụng phải điền vào một mẫu thông tin cá nhân xác 1.2 Mẫu sẽ được lưu trữ vòng năm

1.3 Các mẫu phải được sớ hố người sử dụng, tài liệu được yêu cầu tác giả tài liệu 1.4 Hệ thống phải yêu cầu người sử dụng đăng nhập lần mượn tài liệu

(67)

- Yêu cầu chức năng: là những phát biểu dịch vụ mà hệ thống cần phải cung cấp, hệ thống phản ứng nào với dữ liệu đầu vào cụ thể và hệ thống cần phải ứng xử nào tình h́ng cụ thể Trong mợt sớ trường hợp, u cầu chức có những phát biểu cụ thể những mà chúng khơng thực được

- Yêu cầu phi chức năng: là những ràng buộc đối với dịch vụ hoặc những chức được đưa hệ thống Bao gồm những ràng ḅc thời gian, ràng ḅc tiến trình và chuẩn phải sử dụng Yêu cầu phi chức thường áp dụng cho những hệ thống hoàn chỉnh chứ khơng áp dụng cho mợt tính hoặc mợt dịch vụ hệ thống

- Yêu cầu lĩnh vực: những yêu cầu này đến từ lĩnh vực ứng dụng hệ thớng Nó phản ánh những đặc tính những ràng ḅc lĩnh vực Chúng là yêu cầu chức hoặc yêu cầu phi chức

Trên thực tế, việc phân biệt giữa kiểu yêu cầu thực một rõ ràng định nghĩa Một yêu cầu người dùng liên quan tới tính an toàn, người ta coi là mợt u cầu phi chức Tuy nhiên, phát triển một cách chi tiết hơn, những yêu cầu này sinh những yêu cầu chức khác, chẳng hạn cần phải có chức đăng nhập, phân quyền sử dụng hệ thống

a) Yêu cầu chức

Những yêu cầu chức hệ thống mô tả hệ thớng sẽ làm Những u cầu này phụ thuộc vào kiểu phần mềm sẽ phát triển, đối tượng sử dụng hệ thớng và cách tiếp cận nói chung được tổ chức sử dụng viết yêu cầu Khi diễn tả một yêu cầu người dùng, những yêu cầu này thường được diễn tả một cách trừu tượng Tuy nhiên, những yêu cầu chức hệ thống lại mô tả chức hệ thống một cách chi tiết với đầu vào và đầu ra, trường hợp ngoại lệ… Yêu cầu chức cho mợt hệ thớng phần mềm được diễn tả theo cách khác Ví dụ là chức cho một hệ thống thư viện mợt trường đại học có tên là LIBSYS, được sử dụng sinh viên và giảng viên để đặt trước sách và tài liệu từ thư viện khác nhau:

- Người dùng tìm kiếm tất cả tập hợp thông tin ban đầu CSDL hoặc lựa chọn mợt phần CSDL

- Hệ thớng phải cung cấp mợt giao diện thích hợp để người sử dụng đọc tài liệu kho dữ liệu

- Mỗi hóa đơn đặt sách phải có mợt mã sớ nhất, người dùng chép sang một vùng lưu trữ riêng thuộc tài khoản

(68)

Chúng ta xem xét ví dụ thứ hai cho hệ thớng thư viện có đề cập đến việc “hiển thị hợp lý” tài liệu được cung cấp hệ thống Hệ thớng thư viện phân phới tài liệu qua nhiều định dạng khác Khi quan tâm đến u cầu này, có nghĩa là hệ thớng phải hiển thị được thông tin tất cả loại định dạng khác Tuy nhiên, yêu cầu này được xem là khơng rõ ràng, khơng được một cách cụ thể hệ thống phải cung cấp chức hiển thị cho kiểu định dạng tài liệu khác Người phát triển áp lực là phải hoàn thành nhanh cơng việc, đưa chức hiển thị văn bản và cho thỏa mãn yêu cầu người dùng

Về bản, đặc tả yêu cầu chức một hệ thống phải đầy đủ và đồng Đầy đủ có nghĩa là tất cả dịch vụ mà người dùng yêu cầu phải được xác định Đồng có nghĩa là khơng có những phát biểu mâu thuẫn Trên thực tế, với những hệ thống lớn và phức tạp, khó đưa được yêu cầu đồng và đầy đủ

Một lý khác cho vấn đề này là dễ mắc lỗi và bỏ sót viết đặc tả cho những hệ thống lớn và phức tạp hoặc tác nhân khác hệ thớng sẽ có những u cầu khác nhau, trái ngược Những vấn đề này được phát bước sang giai đoạn phân tích và đơi sau giai đoạn lập trình hoặc tới chuyển giao cho khách hàng

b) Yêu cầu phi chức

Yêu cầu phi chức năng, giớng tên gọi nó, là những yêu cầu không liên quan trực tiếp tới những chức cụ thể mà hệ thống sẽ cung cấp Chúng liên quan tới những tḥc tính hệ thớng, chẳng hạn tính tin cậy, thời gian trả lời và khơng gian lưu trữ Chúng xác định những ràng buộc đối với hệ thống, chẳng hạn khả thiết bị vào và dữ liệu sẽ được hiển thị nào giao diện hệ thống

Những yêu cầu phi chức được kết hợp với những chức cụ thể hệ thống Thông thường, những yêu cầu này hoặc ràng buộc với những tḥc tính hệ thớng Tuy nhiên, chúng xác định tính hiệu năng, tính an toàn, tính sẵn sàng và những tḥc tính bật khác hệ thớng Điều này có nghĩa là chúng thường mang tính phê bình là những yêu cầu chức riêng rẽ Người sử dụng hệ thớng tìm cách làm việc với một chức hệ thống mà không đáp ứng được nhu cầu thực họ

Tuy nhiên, việc không đáp ứng được những yêu cầu phi chức làm cho toàn bợ hệ thớng khơng sử dụng được Ví dụ: một hệ thống điều khiển máy bay không đáp ứng được u cầu tính tin cậy, sẽ không được xác nhận để bán cho người sử dụng; một hệ thống thời gian thực không đáp ứng được yêu cầu tính hiệu năng, chức điều khiển sẽ không thực thi Các yêu cầu phi chức không liên quan tới hệ thống phần mềm được phát triển, một số yêu cầu phi chức ràng ḅc cho cả tiến trình được sử dụng để phát triển hệ thớng Chẳng hạn, những yêu cầu tiến trình bao gồm việc xác định chuẩn chất lượng sẽ được sử dụng tiến trình, mợt bản đặc tả thiết kế phải được sinh một tập công cụ CASE cụ thể và mợt cách mơ tả tiến trình cần phải tuân theo

(69)

chúng ta nhìn thấy hình những yêu cầu phi chức này đến từ những đặc tính phần mềm, đến từ tổ chức phát triển phần mềm hoặc từ nguồn bên ngoài

Hình 4.3 Các kiểu yêu cầu phi chức

- Yêu cầu sản phẩm: những yêu cầu này xác định cách thức thực sản phẩm Chẳng hạn những yêu cầu tính hiệu liên quan tới việc hệ thống phải thực thi nhanh nào, dung lượng bộ nhớ cần là Những yêu cầu độ tin cậy, thiết lập tỷ lệ lỗi chấp nhận được; u cầu tính khả chuyển, yêu cầu tính sử dụng

- Những yêu cầu tổ chức: những yêu cầu này thường xuất phát từ những sách và thủ tục tổ chức khách hàng và nhóm phát triển Ví dụ: ch̉n tiến trình phải được sử dụng, yêu cầu cách thực ngôn ngữ lập trình hoặc phương pháp thiết kế được sử dụng Những yêu cầu việc bàn giao, chẳng hạn việc xác định nào sản phẩm và tài liệu liên quan phải được bàn giao cho khách hàng

- Những u cầu bên ngồi: nhóm này bao gồm tất cả những yêu cầu xuất phát từ những nhân tớ bên ngoài hệ thớng và tiến trình phát triển Chúng bao gồm những yêu cầu tính tương hợp để xác định xem hệ thống sẽ tương tác với hệ thống tổ chức khác, những yêu cầu pháp lý phải tuân thủ để đảm bảo việc thực thi hệ thống tuân theo pháp luật và những yêu cầu mang tính đạo đức Những yêu cầu tính đạo đức là những yêu cầu đối với một hệ thống để đảm bảo sẽ được người sử dụng trực tiếp công chúng chấp nhận

Một vấn đề chung đối với yêu cầu phi chức là chúng khó xác định Người sử dụng và khách hàng thường phát biểu những yêu cầu này mợt cách chung chung, chẳng hạn tính dễ sử dụng, khả hệ thống bao gồm từ việc kiểm soát lỗi người sử dụng đến việc trả lời nhanh yêu cầu người dùng Những mục tiêu mơ hồ này là nguyên nhân dẫn

Per for mance requir ements

Space r equir ements Usa bility

r equir ements

Efficiency requir ements

Relia bility r equir ements

Porta bility requir ements

Inter oper a bility requir ements

Ethical r equir ements

Leg islative requir ements Implementa tion requir ements Standar ds requir ements Deli very requir ements Safety requir ements Pri vacy

r equir ements Product

r equir ements

Organisational requir ements

External r equir ements Non-functional

requir ements

Yêu cầu phi chức

Yêu cầu sản

phẩm Yêu cầu tổ chức

Yêu cầu bên

Yêu cầu tính hiệu quả

Yêu cầu đợ

tin cậy u cầu tính khả chuyển

Yêu cầu tính sử dụng

Yêu cầu hiệu

năng không gian nhớ Yêu cầu

Yêu cầu bàn giao sản phẩm

Yêu cầu thực thi sản phẩm

Yêu cầu chuẩn Yêu cầu liên tổ

chức

Yêu cầu đạo đức

Yêu cầu pháp luật

Yêu cầu bản quyền SP

(70)

Thuộc tính Thước đo

Tốc độ Số giao dịch được xử lý/giây

Thời gian trả lời một kiện/người dùng Thời gian làm màn hình

Kích thước M Bytes

Dung lượng bợ nhớ ROM/RAM

Tính dễ sử dụng Thời gian huấn luyện

Sớ màn hình trợ giúp

Đợ tin cậy Thời gian trung bình kiểm sốt lỗi

Phần trăm thời gian hệ thống không thực Tỷ lệ lỗi xảy

Tính sẵn sàng

Sức kháng cự Thời gian để khởi động lại sau một lỗi

Phần trăm kiện phát sinh lỗi Xác suất việc sai lệch dữ liệu có lỗi

Tính khả chuyển Lựa chọn ngơn ngữ cho giao diện phần mềm

Lựa chọn hệ thống cho việc cài đặt phần mềm

Tuy nhiên, thực tế, khách hàng khó đưa được những u cầu mang tính định lượng Đới với mợt sớ mục tiêu, chẳng hạn tính bảo trì, khơng có thước đo nào sử dụng được Trong trường hợp khác, chí là yêu cầu phi chức mang tính định lượng, khách hàng khơng thể tìm được mối liên hệ giữa nhu cầu họ với những đặc tả này Họ không hiểu được độ tin cậy có nghĩa là kinh nghiệm hàng ngày họ đới với hệ thớng máy tính Hơn nữa, chi phí để xác định tính định lượng cho những yêu cầu phi chức lớn Và khách hàng trả tiền cho hệ thống không nghĩ tới những chi phí này Tuy nhiên, tài liệu yêu cầu thường bao gồm cả mục tiêu lẫn với yêu cầu Những mục tiêu này được sử dụng cho nhà phát triển chúng những ưu tiên khách hàng Ví dụ: yêu cầu dung lượng bộ nhớ tối đa mà hệ thớng sử dụng nhỏ Mbytes Những ràng buộc bộ nhớ là những ràng buộc chung cho hệ thống nhúng Một yêu cầu khác, chẳng hạn chương trình được viết ngôn ngữ Ada, một ngôn ngữ thường được sử dụng cho hệ thống thời gian thực và hệ thống quan trọng, nhiên, ta lại biên dịch mợt chương trình viết Ada với u cầu dung lượng bộ nhớ nhỏ Mbytes Tuy nhiên, ta thương lượng giữa yêu cầu này: phát triển phần mềm ngôn ngữ khác hoặc thêm bộ nhớ cho hệ thống

(71)

năng, khó xác định được những mới liên hệ giữa chúng Nếu những yêu cầu phi chức được kết hợp với những yêu cầu chức khó phân biệt được chúng xác định xem yêu cầu phi chức này là một chức riêng biệt hay toàn bộ hệ thống Tuy nhiên, đối với những yêu cầu rõ ràng, chẳng hạn tính hiệu hoặc đợ tin cậy, ta tách chúng thành những phần riêng biệt tài liệu yêu cầu hoặc phân biệt chúng với u cầu khác hệ thớng

Hình 4.4 Ví dụ yêu cầu phi chức c) Yêu cầu lĩnh vực

Những yêu cầu này xuất phát từ lĩnh vực mà phần mềm sẽ được sử dụng là những yêu cầu người dùng Nó thường bao gồm những thuật ngữ hoặc những khái niệm lĩnh vực Chúng là những yêu cầu chức quyền hạn họ, những ràng buộc yêu cầu chức tồn hoặc tập những tính tốn cụ thể phải được thực Vì những yêu cầu này là cụ thể, nên những kỹ sư phần mềm thường khó hiểu được mối liên hệ giữa chúng với những yêu cầu hệ thống khác

Những yêu cầu lĩnh vực là quan trọng chúng thường phản ánh những vấn đề cốt lõi lĩnh vực ứng dụng Nếu những u cầu này khơng được thỏa mãn, sẽ dẫn tới việc hệ thớng khơng thể làm việc Ví dụ: xét yêu cầu sau đặt cho hệ thớng thơng tin thư viện:

- Có mợt giao diện người dùng chuẩn cho tất cả CSDL dựa chuẩn Z39.50;

- Do hạn chế bản quyền tác giả, một số tài liệu phải được phát người dùng truy cập tới nó;

Yêu cầu sản phẩm:

4.C.8 Nó dùng cho mọi giao tiếp cần thiết giữa APSE và người dùng để thể một tập ký tự chuẩn Ada

6.D.2 Những người dùng kinh nghiệm phải học được cách sử dụng hệ thống tối đa sau đào tạo Sau thời gian đào tạo sớ lỗi trung bình xảy đới với người dùng có kinh nghiệm khơng q lỗi một ngày

Yêu cầu mang tính tổ chức:

9.3.2 Q trình phát triển hệ thớng phân phối tài liệu phải phù hợp với tiến trình sản phẩm được xác định chuẩn XYZCo – SP – STAND95

Những yêu cầu mở rộng:

(72)

4.2 TIẾN TRÌNH KỸ NGHỆ YÊU CẦU

4.2.1 Khảo sát hệ thống phân tích tính khả thi

Sau được khách hàng đặt hàng, nhóm phát triển cần tiến hành khảo sát hệ thống vận hành để thu thập thơng tin phục vụ việc phân tích tính khả thi Trên sở thông tin thu được những yêu cầu khách hàng, nhóm nghiên cứu phải đưa một số phương án việc xây dựng hệ thống được yêu cầu Đối với một dự án, cần đưa ba phương án có thể: phương án thấp, phương án trung bình và phương án cao Các nhà phân tích tiến hành phân tích phương án, lập luận tính khả thi chọn phương án thích hợp Phân tích tính khả thi phân tích rủi ro có liên quan với nhiều khía cạnh, theo nhiều cách khác Nếu rủi ro dự án lớn tính khả thi việc tạo phần mềm chất lượng sẽ giảm Phân tích tính khả thi thường tập trung vào khía cạnh:

1 Khả thi kinh tế: chi phí phát triển cần phải cân xứng với khả và lợi ích ći mà hệ thớng được xây dựng đem lại

2 Khả thi mặt kỹ thuật: Vấn đề chức năng, hiệu và ràng buộc ảnh hưởng tới khả hệ thống được chấp nhận Mặt khác, cần phải xem xét khả kỹ thuật có đủ đảm bảo để thực giải pháp công nghệ được áp dụng cho hệ thống không

3 Khả thi pháp lý: Loại trừ một xâm phạm, vi phạm hay khó khăn nào pháp lý nảy sinh từ việc xây dựng hệ thống

4 Khả thi hoạt động: Đánh giá tính khả thi phương án hệ thống được xây dựng vào hoạt động Trong phương án người ta cần xem xét hệ thớng vận hành trôi chảy hay không khuôn khổ tổ chức và điều kiện quản lý mà tổ chức có

5 Khả thi thời gian: Dự án hồn thành thời gian dự kiến

Nghiên cứu tính khả thi khơng đảm bảo chắc chắn dự án khơng cịn phải đới mặt với rủi ro Tuy nhiên, một những yếu tố không được đáp ứng nguy thất bại dự án lớn cần phải tiến hành nghiên cứu lại Bản nghiên cứu tính khả thi cần phải được cung cấp cho người quản lý cấp cao và đính kèm vào dự án phụ lục

Bản nghiên cứu tính khả thi cần được ban quản lý dự án xem xét và đánh giá độ tin cậy, độ xác nợi dung, sau cấp quản lý cao sẽ xét duyệt để định xem có nên tiến hành dự án hay khơng Trong trường hợp dự án được tiếp tục, là sở để định khác sẽ được đưa bước lập kế hoạch Sau giải pháp và phương án được thơng qua, nhóm phân tích cần lập hồ sơ nhiệm vụ Đây là sở để xây dựng thỏa thuận chưa thức giữa ba bên: người phân tích, nhà đầu tư, khách hàng và người sử dụng

4.2.2 Tiến trình phát phân tích u cầu

Sau có phương án khả thi, đội dự án cần tiếp tục thu thập thông tin, xác định yêu cầu tiến hành phân tích Q trình liên quan tới nhiều đới tượng khác như: người quản lý, kỹ sư dự án, khách hàng, người dùng, chuyên gia, nhà đầu tư… những đối tượng này được gọi chung tác nhân quan trọng (stakeholder)

(73)

theo cách nói riêng, có nhiều thuật ngữ chuyên ngành; nhóm phát triển cần hiểu rõ những yêu cầu chuyển chúng sang mợt hình thức thể thớng Có trường hợp đới tượng người dùng khác có yêu cầu khác nhau, lúc kỹ sư phần mềm phải nhận biết được điểm chung và điểm khác biệt giữa chúng Q trình phân tích diễn một bối cảnh cụ thể tổ chức, đơi bị ảnh hưởng yếu tớ trị kinh tế Hơn nữa, mơi trường kinh doanh ln biến đợng nên u cầu xuất từ những người liên quan mà ban đầu ta khơng xác định hết

Ngồi ra, u cầu phần mềm thường khơng có định nghĩa xác, khơng có cơng thức cho trước Thơng qua việc xử lý thông tin thu thập, hiểu biết người phát triển không ngừng được bổ sung nâng cao, yêu cầu sẽ được thay đổi hoàn thiện Điều này dẫn tới thiếu ổn định u cầu hệ thớng Vì vậy, việc mong chờ xác định rõ ràng bắt tay vào phát triển hệ thớng sẽ khơng thực tế

Hình 4.4 minh họa hoạt đợng tiến trình phân tích yêu cầu Các hoạt động thông thường bao gồm:

- Tìm hiểu miền ứng dụng: Nhóm phát triển cần phải tìm hiểu hoạt đợng nghiệp vụ, nợi dung quy tắc nghiệp vụ cần tuân thủ, sản phẩm và lĩnh vực liên quan

- Thu thập yêu cầu: Tiếp xúc với những người liên quan tới hệ thống để phát những yêu cầu họ đối với hệ thống

- Phân loại yêu cầu: Đây là hoạt động sắp xếp phân loại yêu cầu

- Giải xung đột: hoạt động liên quan tới việc phát xung đột giữa yêu cầu tìm cách giải chúng

- Sắp ưu tiên: Các hệ thớng nói chung có yêu cầu quan trọng yêu cầu quan trọng Bằng cách tiếp xúc tìm hiểu những người liên quan, nhà phân tích sẽ nhận tầm quan trọng yêu cầu sắp xếp chúng một cách hợp lý

- Kiểm tra yêu cầu: Các yêu cầu cần được kiểm tra theo nghiệp vụ để xem chúng có đầy đủ qn khơng, nữa có phù hợp với nhu cầu những người liên quan hay không

Kiểm tra yêu cầu

(74)

Hình 4.5 Tiến trình phát phân tích u cầu

Tiến trình hoạt đợng tiến trình lặp, thông tin phản hồi sẽ được luân chuyển từ hoạt đợng sang hoạt đợng khác nhằm hồn thiện bổ xung thông tin thu thập được

4.2.3 Các phương pháp phát yêu cầu

Phân tích u cầu mợt hoạt đợng khơng đơn giản, nhóm phân tích phải đới mặt với nhiều khó khăn giai đoạn này Dưới là một số phương pháp giúp thu thập phân tích u cầu Mỗi phương pháp có điểm mạnh và điểm yếu riêng, thích hợp để phát yêu cầu dự án này lại khơng thích hợp dự án khác Trên thực tế, người ta kết hợp phương pháp khác để tìm u cầu ći hệ thống cần phát triển

a) Phương pháp DataMining

Phương pháp này sử dụng hệ thống tồn để đưa yêu cầu Do đó, điều kiện tiên nhóm phân tích u cầu truy cập vào hệ thớng, nghiên cứu tất cả chức hệ thớng lấy làm sở để xác định yêu cầu cho hệ thớng

Ưu điểm phương pháp này là người phân tích gần làm việc đợc lập, chủ đợng thời gian cơng việc Sử dụng cơng cụ cũ để khám phá u cầu nên thơng tin thu được nói chung phù hợp với nhu cầu người dùng

Tuy nhiên, phương pháp này tồn một số nhược điểm, ví dụ người phân tích dễ lặp lại những ưu điểm cả nhược điểm hệ thống cũ, không phát được những ràng buộc trình thực dự án quan trọng không khảo sát được những nhu cầu phát sinh khách hàng

b) Phương pháp quan sát (Observation)

Khi sử dụng phương pháp này, nhóm phân tích cần thâm nhập vào thực tế cơng việc người sử dụng Do họ cần phải vào được nơi làm việc người sử dụng và đưa câu hỏi điều tra

Ưu điểm lớn phương pháp này là khám phá được nhu cầu người sử dụng ràng buộc ngầm bên Đã áp dụng thành công dự án điều khiển giao thông hàng không, tàu điện ngầm những cơng việc văn phịng

Tuy nhiên, sử dụng phương pháp này, nhóm phân tích thu thập cả những thông tin không quan trọng, nữa, những thông tin mà họ thu thập được khó xác định giá trị nên việc phân loại sắp xếp thứ tự ưu tiên không đơn giản Ngoài ra, nhóm phân tích khơng nắm được những yêu cầu mang tính tổ chức hoặc lĩnh vực phát triển phần mềm nên khó đánh giá và lường trước những rủi ro, những ràng ḅc tiến trình xây dựng phần mềm

c) Phương pháp phân tích nhiệm vụ

(75)

Ưu điểm phương pháp này là nhóm phân tích thâm nhập vào nơi làm việc khách hàng và đưa được những thông tin chi tiết đối với nhiệm vụ đặc biệt Tuy nhiên, thu thập thông tin kiểu sẽ có những cơng việc khó hiểu, nữa q trình phân tích kéo dài và đơi chi tiết

d) Phương pháp vấn phi cấu trúc

Nhóm phân tích đưa câu hỏi với tác nhân quan trọng mà không cần chuẩn bị trước Khi sử dụng phương pháp này, nhóm phân tích khơng cần thời gian ch̉n bị mà lại cho phép xác định được yêu cầu quan trọng tác nhân

Tuy nhiên, phương pháp này nhiều thời gian vào những câu hỏi không quan trọng, thông tin thu được đơi khó phân tích và phân lớp Hơn nữa, địi hỏi khéo léo kinh nghiệm người làm vấn Phương pháp này không phát giải được xung đột quyền lợi, yêu cầu đối tượng người dùng khác mâu thuẫn

e) Phương pháp vấn cấu trúc

Khi sử dụng phương pháp vấn cấu trúc, nhóm phân tích sẽ đưa cho tác nhân một danh sách những câu hỏi được chuẩn bị trước Những câu hỏi quan trọng phải được xác định trước vấn

Phương pháp này có ưu điểm tất cả tác nhân được hỏi một hệ thống câu hỏi và người vấn là người điều khiển cuộc đối thoại Khi tác nhân được hỏi một hệ thống câu hỏi dễ phát những xung đợt yêu cầu đối tượng người dùng khác Tuy nhiên, hệ thớng câu hỏi đưa thiếu những điểm quan trọng không giải được những vấn đề xung đột

Trong cả hai phương pháp vấn trên, người vấn phải có những kỹ cần thiết sau:

- Khơng có những ý kiến bảo thủ những yêu cầu

- Có khả đưa những ý kiến tranh luận trước một câu hỏi, một giả thiết - Khả lắng nghe

- Khả tạo một cuộc đối thoại:

 Đưa những câu hỏi để bắt đầu c̣c tranh luận

 Nói phần mềm mẫu (Prototype) sẽ làm

 Đưa một ngữ cảnh hẹp để thảo luận

(76)

nhiên, hiệu quả phương pháp lại phụ tḥc nhiều vào tính đợng nhóm những thơng tin thu được thường khơng có tính hệ thớng Vì thế, việc sắp xếp phân loại yêu cầu sẽ gặp khó khăn

g) Phương pháp Rapid application development workshop

Khi muốn thu thập yêu cầu người dùng, nhóm phát triển cần tổ chức những cuộc hội thảo từ 8-20 người, những người có khả định dẫn dắt mợt người có khả đưa những quan điểm độc lập khách quan Để sử dụng phương pháp này nhóm phát triển cần thời gian để chuẩn bị cho cuộc hội thảo (công việc nặng, khoảng tuần), sau tiến hành tập hợp nhóm

Ưu điểm phương pháp này là nhóm sẽ tập hợp được những tác nhân quan trọng, tránh được xung đợt giữa u cầu tìm được thớng giữa tác nhân cuộc hội thảo Những yêu cầu thu thập được thường đảm bảo chất lượng hiệu quả Tuy nhiên, khả thành công phương pháp này phụ tḥc vào khả tập hợp nhóm và tài người chủ trì Hơn nữa lại địi hỏi phải tập hợp những người quan trọng nhiều ngày, có hiệu quả đới với những dự án quan trọng không lớn

h) Phương pháp Rapid rototyping

Phương pháp rapid prototyping thực chất xây dựng phần mềm mẫu cho người dùng dùng thử Do những tác nhân phải tham gia vào việc sử dụng phần mềm mẫu hệ thớng cần phát triển Bên cạnh đó, dự án cần phải có mơi trường để phát triển phiên bản mẫu

Phương pháp này hiệu quả đối với việc phát triển những phần mềm gặp nhiều khó khăn việc tương tác với người sử dụng, những phần mềm có giao diện biến đổi Tuy nhiên, sử dụng phương pháp này sẽ khó đánh giá kinh phí dự án Bên cạnh đó, nhóm phát triển sau này thường có xu hướng xây dựng phần mềm theo phiên bản mẫu, dễ lặp lại cả những điểm yếu kỹ thuật phiên bản mẫu

4.2.4 Các kỹ thuật phân tích yêu cầu

a) Tiếp cận yêu cầu định hướng cách nhìn (viewpoint)

Đối với hệ thống phần mềm vừa lớn, thường có nhiều đới tượng sử dụng khác nhau, đới tượng lại có mợt cách nhìn khác đối với hệ thống Cách tiếp cận ghi nhận những cách nhìn khác những người có liên quan để sử dụng vào tiến trình phát tổ chức yêu cầu Mỗi cách nhìn xem xét góc đợ sau:

- Từ nguồn hay từ đích liệu: Cách nhìn tập trung vào điểm đại diện cho việc tạo hay sử dụng dữ liệu Việc phân tích chủ yếu hướng tới việc xác định xem dữ liệu được tạo ra, được sử dụng xử lý Cách tiệp cận này là điển hình phương pháp phân tích vào/ra (Input – Output analysis)

(77)

- Từ tiếp nhận dịch vụ: Cách nhìn tập trung vào những dịch vụ mà hệ thống sẽ cung cấp tiếp nhận Dựa cách nhìn này, người ta xác định những dữ liệu cho dịch vụ tín hiệu kiểm tra Q trình phân tích bao gồm: kiểm tra dịch vụ nhận được đối tượng sử dụng khác nhau, thu thập giải xung đột

b) Kỹ thuật xác định yêu cầu hướng cách nhìn VORD (Viewpoint Oriented Requirement Definition)

Phương pháp này được đề xuất Ian Sommeville Kotonua, giai đoạn VORD bao gồm:

- Xác định khung nhìn: Tìm kiếm khung nhìn để thu nhận dịch vụ hệ thống xác định dịch vụ cung cấp cho khung nhìn

- Cấu trúc khung nhìn: Nhóm khung nhìn liên quan mợt hệ thớng phân cấp Các dịch vụ chung được cung cấp mức cao hệ thớng này và được khung nhìn mức thấp kế thừa

- Làm tài liệu khung nhìn: làm mịn mơ tả khung nhìn dịch vụ được xác định

- Ánh xạ hệ thống – khung nhìn: xác định đới tượng dùng phương pháp phân tích hướng đới tượng sử dụng thông tin dịch vụ được giới hạn mợt khung nhìn Hình vẽ 4.5 hoạt đợng tiến trình phân tích u cầu theo phương pháp VORD

Hình 4.6 Tiến trình phương pháp VORD c) Kỹ thuật phân tích u cầu dựa mơ hình

Đây là mợt kỹ thuật phổ biến để phân tích u cầu Các loại mơ hình khác được sử dụng và thường theo hướng tiếp cận khác nhau:

- Tiếp cận hướng chức năng: là phương pháp phân tích hướng cấu trúc dựa luồng dữ liệu

- Tiếp cận hướng đối tượng: là phương pháp phân tích hướng cấu trúc dựa thực thể

Để phát yêu cầu, cả hai cách tiếp cận hướng tới nghiệp vụ hệ Xác định

khung nhìn

Cấu trúc khung nhìn

Tài liệu khung nhìn

(78)

chi tiết khác Ở mức thấp nhất, nội dung chức đủ dễ hiểu mơ tả chi tiết Tùy theo cách tiếp cận mà ta có dạng biểu diễn khác

- Mô tả chi tiết chức năng: Mô tả chi tiết chức là cần thiết thực được với chức mức thấp (chức sở) Tuy nhiên, mơ tả chức mức cao (theo phương pháp hướng đối tượng) để dễ hiểu dễ lần vết trình tiếp cận dần Tùy theo cách tiếp cận, nội dung cách mô tả chức khác

- Mô tả các đối tượng dữ liệu: cần cho việc lưu giữ sau Do bản chất cách tiếp cận mà mô tả là khác Tiếp cận theo hướng cấu trúc, mô tả dữ liệu bao gồm tất cả hồ sơ được sử dụng hoạt động nghiệp vụ bản mẫu thực chúng Trong đó, theo định hướng đới tượng, mơ tả lại bao gồm đối tượng khái niệm giới thực

- Mô tả mối liên kết giữa chức dữ liệu: Mô tả cần thiết đối với cách tiếp cận hướng cấu trúc

(79)

d) Các cách biểu diễn mơ hình phân tích

Bảng 4.2 Biểu diễn mơ hình nghiệp vụ theo cách tiếp cận

Các thành phần của mơ hình

phân tích

Thể mơ hình theo định hướng cấu trúc

Thể mơ hình theo định hướng đối tượng

1 Mơ hình ngữ cảnh

Gồm thành phần:

- tiến trình (hình chữ nhật góc trịn) mô tả hệ thống

- Các tác nhân (hình chữ nhật), mơ tả người, tổ chức, hệ thống khác không thuộc hệ thống

- Các luồng dữ liệu (hình mũi tên) liên kết giữa tác nhân hệ thống

Gồm thành phần:

- Các ca sử dụng (hình chữ nhật) mức cao mơ tả hệ thớng

- Các tác nhân (hình người) người, hệ thớng khác có tương tác với hệ thống

- Các liên kết tương tác giữa tác nhân với trường hợp sử dụng giữa trường hợp sử dụng với

2 Mơ hình cấu trúc chức

- Gồm mợt hoặc mợt sớ biểu đồ phân cấp hình cây, nút một chức

- Mỗi chức mức nhận được cách phân rã chức Chức mức thấp chức sở

- Là biểu đồ trường hợp sử dụng (use case) tương ứng với mức khác

- Biểu đồ mức nhận được từ ca phân rã mức

- Ca sử dụng mức thấp mơ tả tương tác

3 Mô tả chi tiết chức

- Chỉ mô tả chức sở

- Mô tả gồm tên chức năng, dữ liệu vào, dữ liệu ra, nguồn, đích, quy tắc nghiệp vụ để thực chức

- Mô tả ca sử dụng luồng tương tác chính/ngoại lệ giữa tác nhân hệ thớng

- Các ràng buộc lên luồng tương tác Mô tả đối

tượng dữ liệu

- Danh sách hồ sơ dữ liệu sử dụng - Các mẫu hồ sơ, từ điển dữ liệu

Mơ hình miền lĩnh vực với đối tượng thực thể hay khái niệm được liên kết với

5 Mô tả liên kết giữa chức

- Ma trận thực thể - chức năng: cột ứng với mợt hồ sơ, dịng ứng với

(80)

4.2.5 Ví dụ phân tích phát yêu cầu a) Ví dụ phân tích hướng cấu trúc

Ví dụ: Hãy phân tích yêu cầu cho mơ hình nghiệp vụ hoạt đợng trơng giữ xe mợt bãi gửi xe

Hình 4.7 Biểu đồ ngữ cảnh hệ thống

Hình 4.8 Biểu đồ phân rã chức hoạt động trông giữ xe

Bảng 4.3 Danh sách hồ sơ liệu sử dụng

a Bảng giá (phân loại xe) e Phiếu toán

b Vé xe f Biên bản cố

c Sổ vào xe g Phiếu chi bồi thường

d Sổ xe

Hình 4.9 Mơ tả u cầu mợt chức sơ cấp

Quản lý trông, gửi xe bãi

1 Nhận xe Trả xe Giải cố

1.1 Nhận dạng xe 1.2 Kiểm tra chỗ

1.3 Ghi vé 1.4 Ghi sổ xe vào

2.1 Kiểm tra vé 2.2 Đối chiếu vé - xe

2.3 Thanh toán 2.4 Ghi sổ xe

3.1 Kiểm tra số

3.2 Kiểm tra trường 3.3 Lập biên bản

3.4 Chi bồi thường

Nhận dạng xe

Bảng phân loại xe

Quy tắc nghiệp vụ: Xe loại là xe thuộc loại ghi bảng phân loại

Thông tin xe Sai loại

Đúng loại Loại xe

KHÁCH HỆ THỐNG QUẢN LÝ

TRÔNG GIỮ XE Thông tin xe

Thông tin phản hồi Vé xe Vé xe

Phiếu tốn Thơng tin cố

(81)

Các thực thể a Bảng giá (phân loại xe) b Vé xe

c Sổ vào xe d Sổ xe

e Phiếu tốn f Biên bản cớ g Phiếu chi bồi thường

Các chức nghiệp vụ a b c d e f

1 Nhận xe R C U R

2 Trả xe R U C

3 Giải cớ R R C C

(Chú thích: C – Create; R – Read; U – Update)

Ma trận mô tả: một chức dịng (nhận xe) tạo (C), Cập nhật (U) hay đọc (R) một thực thể dữ liệu cột (b: Vé xe)

Hình 4.10 Ma trận thực thể - chức b) Phân tích yêu cầu theo định hướng đối tượng

Ví dụ minh họa việc phân tích yêu cầu cho hoạt động một máy ATM ngân hàng cung cấp dịch vụ tín dụng cho khách hàng theo định hướng đới tượng

Hình 4.11 Biểu đồ trường hợp sử dụng mức cao Hệ thớng

Giao dịch tín dụng Khách hàng

Ngân hàng Môi trường

(82)

Các tác nhân liên quan Khách hàng

Hành động tác nhân Phản ứng hệ thống

1 Đưa thẻ vào hệ thống Hiện cửa sổ yêu cầu nhập định danh

3 Nhập định danh Hiện chức giao dịch

5 Chọn chức rút tiền Hiện cửa sổ tài khoản, số tiền rút

7 Nhập tài khoản số tiền rút Trả số tiền cho khách rút, in hóa đơn

9 Nhấn nút kết thúc 10 Trả lại thẻ, đóng hệ thớng

Ngoại lệ:

Bước 2: Nếu định danh sai, chức kết thúc

Bước 4: Nếu tài khoản sai, hệ thống yêu cầu nhập lại

Bước 8: Nếu số tiền rút q sớ dư tài khoản hệ thớng phải có quy tắc nghiệp vụ xử lý

Trừ những trường hợp ngoại lệ, phương pháp cấu trúc thu thập nhiều thông tin tạo một khối lượng lớn tài liệu Vấn đề quản lý thông tin phương pháp này là một vấn đề quan trọng phát triển công cụ CASE

Hình 4.13 Mơ hình miền lĩnh vực hệ thống ATM

4.3 ĐẶC TẢ YÊU CẦU PHẦN MỀM

4.3.1 Khái niệm

Tài liệu xác định yêu cầu một tài liệu mô tả hướng khách hàng và được viết ngôn ngữ khách hàng Khi dùng ngơn ngữ tự nhiên khái niệm trừu tượng Tài liệu đặc tả yêu cầu (đặc tả chức năng) là mô tả hướng người phát triển, là sở hợp đồng làm phần mềm Nó khơng được phép mơ hồ, không sẽ dẫn đến hiểu nhầm khách hàng hoặc người phát triển Với một yêu cầu mơ hồ người phát triển sẽ thực mợt cách rẻ cịn khách hàng khơng ḿn Do đó, khách hàng địi hỏi sửa đổi chức phần mềm gần hồn thiện khiến cho chi phí tăng và chậm thời điểm bàn giao Chi phí cho sửa sai sót phát biểu yêu cầu lớn, đặc biệt là sai sót này được phát bắt đầu xây dựng hệ thớng Theo mợt sớ thớng kê 85% mã phải viết lại thay đổi yêu cầu 12% lỗi phát năm đầu sử dụng là đặc tả u cầu khơng xác Do đó, việc đặc tả xác u cầu mối quan tâm được đặt lên hàng đầu

Khách hàng Mã_khách Tên_khách Địa_chỉ Tài khoản Mã_TK Số_dư Dịch vụ Mã_dịch_vụ Tên_dịch_vụ Giao dịch Mã_giao_dịch Ngày Sớ_tiền Có Sử dụng Thực *

(83)

4.3.2 Các phương pháp đặc tả Có hai phương pháp đặc tả:

- Đặc tả phi hình thức: là đặc tả sử dụng ngơn ngữ tự nhiên Tuy khơng được chặt chẽ đặc tả hình thức được nhiều người biết và dùng để trao đổi với để làm xác hóa điểm chưa rõ, chưa thớng giữa bên phát triển hệ thống

- Đặc tả hình thức: là đặc tả mà từ ngữ, cú pháp, ngữ nghĩa được định nghĩa hình thức dựa vào tốn học Đặc tả hình thức coi là mợt phần hoạt đợng đặc tả phần mềm Các đặc tả yêu cầu được phân tích chi tiết Các mơ tả trừu tượng chức chương trình được tạo để làm rõ yêu cầu

a) Đặc tả hình thức

Đặc tả hình thức là mợt đặc tả được trình bày mợt ngơn ngữ bao gồm: từ vựng, cú pháp và ngữ nghĩa được định nghĩa Định nghĩa ngữ nghĩa đảm bảo ngôn ngữ đặc tả không phải là ngơn ngữ tự nhiên mà dựa tốn học Các chức nhận đầu vào trả lại kết quả Các chức định điều kiện tiền tố và hậu tố Điều kiện tiền tố là điều kiện cần thỏa mãn để có dữ liệu vào, điều kiện hậu tớ là điều kiện cần thỏa mãn sau có kết quả

Có hai hướng tiếp cận đặc tả hình thức để phát triển hệ thống tương đối phức tạp - Tiếp cận đại số, hệ thống được mô tả dạng toán tử và quan hệ

- Tiếp cận mơ hình, mơ hình hệ thớng được cấu trúc sử dụng thực thể toán học là tập hợp và thứ tự

Sử dụng đặc tả hình thức, ta có thuận lợi:

- Cho phép thấy và hiểu được bản chất bên yêu cầu, là cách tốt để làm giảm lỗi, thiếu sót xảy và giúp cho công việc thiết kế được thuận lợi

- Do sử dụng toán học cho việc đặc tả nên dựa vào cơng cụ tốn học phân tích và điều này làm tăng thêm tính chắc chắn và tính đầy đủ hệ thớng

- Đặc tả hình thức, bản thân cho mợt cách thức cho việc kiểm tra hệ thống sau này

Tuy vậy, đặc tả hình thức bợc lợ mợt vài khó khăn:

- Quản lý phần mềm có tính bảo thủ cớ hữu nó, khơng sẵn sàng chấp nhận kỹ thuật

(84)

b) Đặc tả phi hình thức

Đặc tả phi hình thức (ngôn ngữ tự nhiên) thuận tiện cho việc xác định u cầu nhiều khơng thích hợp với đặc tả u cầu vì:

- Khơng phải lúc nào người đọc và người viết đặc tả ngôn ngữ tự nhiên hiểu từ

- Ngơn ngữ tự nhiên q mềm dẻo yêu cầu liên quan đến được biểu diễn hình thức hoàn toàn khác và người phát triển không nhận mối liên quan

- Các yêu cầu khó được phân hoạch mợt cách hữu hiệu hiệu quả việc đổi thay xác định được cách kiểm tra tất cả yêu cầu chứ khơng phải mợt nhóm u cầu liên quan

Các ngơn ngữ đặc tả (đặc tả hình thức) khắc phục được hạn chế trên, nhiên đa số khách hàng lại không thông thạo ngôn ngữ Thêm nữa ngơn ngữ đặc tả hình thức thường phục vụ cho mợt nhóm lĩnh vực riêng biệt việc đặc tả hình thức mợt cơng việc tốn nhiều thời gian công sức

Một cách tiếp cận khác bên cạnh đặc tả hình thức người ta viết giải ngôn ngữ tự nhiên để giúp khách hàng dễ hiểu yêu cầu phần mềm

4.3.3 Cấu trúc tài liệu đặc tả

Kết quả bước phân tích tạo bản đặc tả yêu cầu phần mềm (Software Requirement Specification – SRS) Đặc tả yêu cầu phải rõ được phạm vi sản phẩm, chức cần có, đới tượng người sử dụng ràng buộc vận hành sản phẩm Có nhiều chuẩn khác xây dựng tài liệu, là một định dạng SRS thông dụng (theo chuẩn IEEE 830-1984) Cấu trúc tài liệu đặc tả sau:

1 Giới thiệu

1.1 Mục đích

Mục giới thiệu mục đích tài liệu yêu cầu Thường đơn giản là định nghĩa “đây tài liệu yêu cầu phần mềm XZY”

1.2 Phạm vi

Nêu phạm vi đề cập tài liệu yêu cầu

1.3 Định nghĩa

Định nghĩa khái niệm, từ viết tắt, chuẩn được sử dụng tài liệu yêu cầu

1.4 Tài liệu tham khảo

Nêu danh mục tài liệu tham khảo dùng để tạo bản đặc tả yêu cầu

1.5 Mô tả chung về tài liệu

(85)

2.1 Tổng quan về sản phẩm

Mô tả khái quát sản phẩm

2.2 Chức sản phẩm

Khái quát chức sản phẩm

2.3 Đối tượng người dùng

Mô tả đối tượng người dùng

2.4 Ràng buộc tổng thể

Khái quát ràng buộc phần mềm: ràng buộc phần cứng, môi trường sử dụng, yêu cầu kết nối với hệ thống khác…

2.5 Giả thiết sự lệ thuộc

Mô tả giả thiết áp dụng tài liệu: ví dụ tên phần cứng, phần mềm, hệ điều hành cụ thể

3 Yêu cầu chi tiết

Mô tả yêu cầu

3.1 Yêu cầu chức

Mô tả chi tiết yêu cầu chức 3.1.1 Yêu cầu chức

 Giới thiệu

 Dữ liệu vào

 Xử lý

 Kết quả

3.1.2 Yêu cầu chức …

3.1.n Yêu cầu chức n

3.2 Yêu cầu giao diện

(86)

3.4 Ràng buộc thiết kế

Mô tả ràng ḅc thiết kế, ví dụ ràng ḅc ngơn ngữ, công nghệ, sở dữ liệu chuẩn giao tiếp

3.5 Thuộc tính

Mơ tả tḥc tính phần mềm 3.5.1 Tính bảo mật, an toàn khả phục hồi

Mức độ bảo mật dữ liệu, cách thức truy cập vào hệ thớng Đợ an tồn hệ thớng đối với trường hợp bất thường điện, bị công, bị tải… Khả phục hồi hệ thống sau gặp cố

3.5.2 Tính bảo trì

Các chức năng, giao diện đòi hỏi phải dễ sửa đổi (dễ bảo trì)

3.6 Các yêu cầu khác

Các yêu cầu khác liên quan đến sản phẩm

Phân tích và định rõ yêu cầu là bước kỹ thuật tiến trình cơng nghệ phần mềm Tại bước phát biểu chung phạm vi phần mềm được làm mịn thành một bản đặc tả cụ thể để trở thành tảng cho mọi hoạt động sản xuất phần mềm sau

Việc phân tích phải tập trung vào miền thơng tin, chức và hành vi vấn đề Để hiểu rõ u cầu, người ta tạo mơ hình, phân hoạch vấn đề tạo những biểu diễn mô tả cho bản chất yêu cầu sau vào chi tiết Trong nhiều trường hợp, đặc tả được đầy đủ mọi vấn đề giai đoạn đầu

Việc làm bản mẫu thường giúp cách tiếp cận khác để từ làm mịn thêm yêu cầu Để tiến hành đắn việc làm bản mẫu, cần tới công cụ kỹ thuật đặc biệt Kết quả việc phân tích tạo bản đặc tả yêu cầu phần mềm Đặc tả cần được xét duyệt để đảm bảo người phát triển khách hàng có nhận biết hệ thớng cần phát triển

1 Yêu cầu phần mềm gì? Có những loại u cầu phần mềm gì? Cho ví dụ minh họa đới với hệ thống phần mềm nhúng cho máy rút tiền tự đợng ATM ngân hàng Có những loại tài liệu u cầu phần mềm nào? Đới tượng những loại tài liệu

yêu cầu ai?

3 Trình bày bước tiến trình phát phân tích u cầu Trình bày kỹ thuật khác để nhận biết phân tích yêu cầu

4 Cấu trúc bản tài liệu yêu cầu gồm những mục gì?

5 Đặc tả u cầu phần mềm gì? Có những hình thức đặc tả nào? Khi cần áp dụng những hình thức đặc tả này?

(87)

Chương 5: UML – XÂY DỰNG VÀ THIẾT KẾ CÁC MÔ HÌNH HỆ THỐNG Yêu cầu người dùng thường được viết ngôn ngữ tự nhiên để những người không phải là chuyên gia CNTT hiểu được Tuy nhiên, u cầu hệ thớng chi tiết và được diễn tả theo hướng kỹ thuật nhiều Trong đó, cách được sử dụng nhiều là đặc tả hệ thớng thành mợt tập mơ hình hệ thớng Những mơ hình cách biểu diễn đờ họa dùng

để mơ tả các tiến trình nghiệp vụ, vấn đề cần giải quyết hệ thống được phát triển Thông

thường biểu diễn đồ họa dễ hiểu diễn đạt chi tiết ngơn ngữ tự nhiên Nó là cầu nới quan trọng giữa nhóm phân tích và nhóm thiết kế

Ta sử dụng mơ hình này tiến trình phân tích để hiểu rõ hệ thống tồn cần được thay thế, nâng cấp hay tạo hoàn toàn Bên cạnh ta cần phải sử dụng loại mơ hình khác để diễn tả những khía cạnh khác hệ thống

Chương này giới thiệu ngôn ngữ UML và tìm hiểu mợt sớ loại sơ đồ UML để ứng dụng mơ hình hóa hệ thớng

5.1 GIỚI THIỆU VỀ UML

5.1.1 Mơ hình hóa hệ thống phần mềm

Như trình bày phần trước, mục tiêu giai đoạn phân tích hệ thớng là sản xuất mợt mơ hình tổng thể hệ thớng cần xây dựng Mơ hình này cần phải được trình bày theo hướng nhìn khách hàng và người sử dụng để họ hiểu được Mơ hình này được sử dụng để xác định yêu cầu người dùng đới với hệ thớng và qua giúp đánh giá tính khả thi dự án

Mơ hình thường được mơ tả ngơn ngữ trực quan, điều có nghĩa là đa phần thơng tin được thể ký hiệu đồ họa và mối liên kết giữa chúng, cần thiết một số thông tin được biểu diễn dạng văn bản Việc biểu diễn mơ hình phải thoả mãn yếu tớ sau:

- Chính xác: Mơ tả hệ thống cần xây dựng

- Đồng nhất: Các ngữ cảnh khác không được mâu thuẫn với - Có thể hiểu được: Cho cả người xây dựng lẫn người sử dụng

- Dễ thay đổi, dễ dàng liên lạc với mô hình khác

(88)

5.1.2 Lịch sử hình thành phát triển a) Bối cảnh đời UML

Đầu những năm 1980, lĩnh vực phát triển phần mềm có mợt ngôn ngữ hướng đối tượng là Simula Sang nửa sau thập kỷ 1980, ngôn ngữ hướng đối tượng Smalltalk và C++ xuất Cùng với chúng, nảy sinh nhu cầu mơ hình hố hệ thớng phần mềm theo phương pháp hướng đối tượng Một ngôn ngữ mơ hình hố xuất những năm đầu thập kỷ 90 được nhiều người dùng là:

- Grady Booch’s Booch Modeling Methodology

- James Rambaugh’s Object Modeling Technique – OMT - Ivar Jacobson’s OOSE Methodology

- Hewlett- Packard’s Fusion

- Coad and Yordon’s OOA and OOD

Mỗi phương pháp và ngôn ngữ có hệ thớng ký hiệu riêng, cách thức xử lý riêng, công cụ hỗ trợ riêng làm phát sinh cuộc tranh luận phương pháp nào là tốt Đây là c̣c tranh luận khó có câu trả lời, tất cả phương pháp có điểm mạnh và điểm yếu riêng Vì thế, nhà phát triển phần mềm nhiều kinh nghiệm thường sử dụng phối hợp điểm mạnh phương pháp cho ứng dụng Trong thực tế, khác biệt giữa phương pháp khơng đáng kể Theo cùng tiến trình thời gian, tất cả những phương pháp tiệm cận lại và bổ sung lẫn cho Chính thực này được những người tiên phong lĩnh vực mơ hình hố hướng đới tượng nhận và họ định ngồi lại cùng để tích hợp những điểm mạnh phương pháp, cuối cùng đưa mợt mơ hình hóa thớng

Trong bới cảnh trên, người ta nhận thấy cần thiết phải cung cấp mợt phương pháp tiệm cận được ch̉n hố và thớng cho việc mơ hình hố hướng đới tượng Yêu cầu cụ thể là đưa một tập hợp chuẩn hoá ký hiệu (Notation) và biểu đồ (Diagram) để nắm bắt định mặt thiết kế mợt cách rõ ràng, rành mạch Đã có ba cơng trình tiên phong nhắm tới mục tiêu đó, chúng được thực lãnh đạo James Rumbaugh, Grady Booch và Ivar Jacobson Từ những cố gắng này, ngơn ngữ mơ hình hố thớng thất (Unifield Modeling Language – UML) đời

b) UML (Unifield Modeling Language)

Ngơn ngữ mơ hình hóa thớng (Unifield Modeling Language – UML) là một ngôn ngữ để biểu diễn mơ hình theo hướng đới tượng được, xây dựng ba tác giả với mục đích:

- Mơ hình hố hệ thớng sử dụng khái niệm hướng đối tượng

- Thiết lập một kết nối từ nhận thức người đến kiện cần mơ hình hố - Giải vấn đề mức độ thừa kế hệ thống phức tạp, có nhiều ràng ḅc khác

(89)

5.1.2 UML giai đoạn phát triển hệ thống

- Nghiên cứu tính khả thi (Preliminary Investigation): sử dụng mơ hình trường hợp sử

dụng (use cases) thể yêu cầu người dùng Phần miêu tả mô tả trường hợp sử dụng để xác định yêu cầu, phần mô hình thể mới quan hệ và giao tiếp tác nhân với hệ thớng

- Phân tích (Analysis): Mục đích giai đoạn này là trừu tượng hóa và tìm hiểu

các cấu có phạm vi bài tốn Mơ hình lớp bình diện trừu tượng hóa thực thể ngoài đời thực được sử dụng để làm rõ tồn mối quan hệ chúng Chỉ những lớp nằm phạm vi bài toán đáng quan tâm

- Thiết kế (Design): Kết quả phần phân tích được phát triển thành giải pháp kỹ thuật Các

biểu đồ lớp được mơ hình hóa chi tiết để cung cấp hạ tầng kỹ thuật giao diện, tảng CSDL… Kết quả phần thiết kế là đặc tả chi tiết cho giai đoạn xây dựng phần mềm

- Phát triển (Development): Mơ hình thiết kế được chuyển thành mã nguồn chương trình

Người lập trình sẽ sử dụng mơ hình UML giai đoạn thiết kế để hiểu vấn đề và tạo mã nguồn chương trình

- Kiểm thử (Testing): Sử dụng mơ hình UML giai đoạn trước làm sở cho

việc kiểm thử Có bớn hình thức kiểm thử hệ thớng: kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thớng và kiểm thử chấp nhận

5.2 MỘT SỐ MÔ HÌNH UML DÙNG TRONG PHÂN TÍCH VÀ THIẾT KẾ 5.2.1 Mơ hình ngữ cảnh

(90)

Hình 5.1 Sơ đồ ngữ cảnh hệ thống ATM ngân hàng

Từ hình 5.1, thấy máy ATM được kết nới với một sở dữ liệu tài khoản, một hệ thớng kế tốn chi nhánh, mợt hệ thớng an ninh và mợt hệ thớng hỗ trợ cho việc bảo trì máy Hệ thống được kết nối với một hệ thớng sở dữ liệu kiểm sốt mạng lưới máy ATM được sử dụng và hệ thống kế tốn chi nhánh Hệ thớng kế tốn này cung cấp dịch vụ lưu hoặc in ấn Tất nhiên, khơng nằm hệ thớng máy ATM

Mơ hình kiến trúc mơ tả mơi trường hệ thống, nhiên chúng không mối quan hệ giữa hệ thống khác môi trường với hệ thống được đặc tả Các hệ thớng bên ngoài sinh dữ liệu cho việc tổng hợp dữ liệu từ hệ thớng Chúng chia sẻ dữ liệu với hệ thống, kết nối trực tiếp qua một mạng hoặc không kết nối Chúng được đặt những vị trí khác Tất cả những mới quan hệ này có ảnh hưởng tới yêu cầu hệ thống được định nghĩa và phải tính tới tiến hành phát triển hệ thớng

Tuy nhiên, mơ hình kiến trúc đơn giản thường không được hỗ trợ mơ hình khác, chẳng hạn mơ hình tiến trình, hoạt đợng tiến trình được cung cấp hệ thớng Mơ hình luồng dữ liệu được sử dụng để dữ liệu được truyền giữa hệ thống cùng mợt mơi trường Hình 5.2 minh họa mơ hình tiến trình cho hệ thớng đặt mua mợt thiết bị mợt tổ chức Mơ hình này liên quan tới việc xác định thiết bị được yêu cầu, tìm và lựa chọn nhà cung cấp, đặt trước thiết bị, bàn giao thiết bị và kiểm thử sau bàn giao Khi máy tính hỗ trợ cho tiến trình này, bạn phải định những hoạt động được hệ thống hỗ trợ, những hoạt động nào nằm ngoài giới hạn hệ thớng Hình 5.2 những hoạt đợng nằm hình chữ nhật bao quanh là những hoạt đợng được hệ thống hỗ trợ

Auto-teller sy stem Security

sy stem

Maintenance sy stem

Account da tabase

Usage database Branch

accounting sy stem

Branch counter sy stem

Hệ thống ATM

Cơ sở dữ liệu tài khoản

Cơ sở dữ liệu người dùng Hệ thớng

bảo trì Hệ thớng

an ninh Hệ thớng kế

tốn chi nhánh

(91)

Hình 5.2 Mơ hình tiến trình đặt mua thiết bị

5.2.2 Mơ hình trường hợp sử dụng (USE-CASE)

Trong giai đoạn phân tích, người sử dụng hợp tác cùng nhóm phát triển phần mềm tạo nên một tổ hợp thông tin quan trọng yêu cầu đối với hệ thống Không là người cung cấp thông tin, bản thân người sử dụng cịn là mợt thành phần hết sức quan trọng bức tranh toàn cảnh và nhóm phát triển cần phải phương thức hoạt động hệ thống tương lai theo hướng nhìn người sử dụng Đây là giai đoạn cần thiết để hỗ trợ cho việc xây dựng thành công những hệ thống vừa thỏa mãn u cầu đặt khách hàng, vừa có mơi trường thân thiện với người sử dụng Công cụ giúp ta mơ hình hóa hệ thớng từ hướng nhìn người sử dụng gọi là mơ hình trường hợp sử dụng Mợt mơ hình gồm ba thành phần chính:

- Hệ thớng: được thể mợt hình chữ nhật có chứa tên hệ thớng - Tác nhân: là mợt đới tượng sử dụng hoặc một hệ thống khác Tác nhân là người sử dụng được thể mợt hình người Nếu tác nhân hệ thớng thể mợt hình chữ nhật có ghi tên tác nhân Các tác nhân này giao tiếp với hệ thống thơng qua giao diện Giao diện là giao diện người máy hoặc giao diện hệ thớng (hình 5.3)

- Use Case: là trường hợp sử dụng hay chức hệ thống, được thể mợt hình eclipse kèm với tên chức (use-case)

Mô tả

thiết bị Kiểm tra yêu cầu

Mô tả thiết bị

CSDL

nhà cung cấp cung cấp Tìm nhà Lựa chọn nhà cung cấp thiết bị Đặt

Cài đặt thiết bị

Chấp nhận thiết bị được

bàn giao

CSDL nhà cung cấp

Xác định thiết bị được yêu cầu

Xác nhận yêu cầu

Ước tính chi phí

Chấp nhận bàn

giao thiết bị Kiểm tra danh mục được bàn giao

Kiểm tra và xác nhận vào form đặt hàng Danh sách nhà cung cấp

Lưu ý bàn giao

Đánh giá yêu cầu và

nhà cung cấp Form cho phép đặt hàng Cài đặt Chấp nhận cài đặt Lưu ý bàn giao

(92)

Hình 5.3 Biểu đổ USE-CASE hệ thống ngân hàng

Hình 5.3 mơ hình trường hợp sử dụng hệ thống máy rút tiền tự động ATM Đây là một biểu đồ chứa phần tử mơ hình biểu thị hệ thống, tác nhân, chức và mối quan hệ giữa tác nhân use-case

Kết hợp với mơ hình trường hợp sử dụng là lời mô tả nội dung use-case, mô tả tác nhân hệ thống Các mô tả này thường được cung cấp dạng văn bản Trong UML, lời mơ tả được coi tḥc tính văn bản use-case Lời mô tả này bao gồm những thông tin quan trọng, định nghĩa yêu cầu và chức cụ thể Đây là lời đặc tả đơn giản và quán việc tác nhân use-case tương tác với sao, tập trung vào ứng xử đối ngoại hệ thống và không đề cập tới việc thực nội bộ hệ thống Ngôn ngữ và thuật ngữ được sử dụng lời miêu tả là ngơn ngữ và thuật ngữ được sử dụng khách hàng/người dùng Văn bản miêu tả bao gồm những điểm sau:

- Mục đích use-case: Mục đích ći cùng use-case gì? Các use-case nói chung mang tính hướng mục đích và mục đích use-case cần phải rõ ràng

- Use-case khởi chạy nào: Tác nhân làm use-case thực thi? Thực thi hoàn cảnh nào?

- Chuỗi thông điệp tác nhân use-case: use-case và tác nhân trao đổi thông điệp hay kiện nào để thông báo lẫn cho nhau, cập nhật hoặc nhận thông tin và giúp đỡ thực thi chức năng? Yếu tố nào sẽ miêu tả dịng chảy thơng điệp giữa hệ thớng tác nhân, những thực thể nào hệ thống được sử dụng hoặc bị thay đổi?

- Dòng chảy thay use-case: Mợt use-case có những dịng thực thi thay tùy tḥc vào điều kiện Hãy nhắc đến yếu tố này, ý đừng miêu tả chúng chi tiết đến mức đợ chúng “che khuất” dịng chảy hoạt đợng trường hợp bản Những động tác xử lý lỗi đặc biệt sẽ được miêu tả thành use-case khác

- Use-case kết thúc nào: Hãy miêu tả nào use-case được coi là kết thúc, và kết quả mà cung cấp đến tác nhân

Giao diện người máy

Giao diện hệ thống

Khách hàng

Kỹ thuật viên

<<actor>> Hệ thống ngân

hàng

Hệ thống rút tiền tự động ATM Vấn tin tài khoản

Rút tiền từ tài khoản

(93)

Để bổ sung cho lời miêu tả một use-case, người ta thường đưa một loạt kịch bản cụ thể để minh họa điều sẽ xảy một use-case được thực thi Lời miêu tả kịch bản minh họa một trường hợp đặc biệt, cả tác nhân lẫn use-case được coi là mợt thực thể cụ thể Khách hàng dễ dàng hiểu toàn bộ một use-case phức tạp có những kịch bản được miêu tả thực tiễn hơn, minh họa lại lối ứng xử và phương thức hoạt động hệ thống Tuy nhiên, một lời miêu tả kịch bản là một bổ sung chứ không để thay cho lời miêu tả use-case

Bảng 5.1 Bảng thông tin mô tả Use-case

Tên Use-case: Mức đợ khó:

Tác nhân chính: Tác nhân phụ:

Mơ tả Use-case:

Điều kiện bắt đầu (pre-condition): Điều kiện kết thúc (post-condition): Trình tự thực hiện:

Yêu cầu phi chức năng: Các trường hợp ngoại lệ:

Bảng 5.1 minh họa thông tin cần làm rõ mô tả chi tiết Use-case hệ thống Một số thông tin bảng bỏ trớng Mợt Use-case có nhiều tác nhân và tác nhân phụ

5.2.3 Mơ hình lớp đối tượng

Với số hệ thống, mơ hình đối tượng thường phản ánh thực thể giới thực hệ thống quản lý Điều này là hợp lý hệ thống xử lý những thông tin thực thể hữu hình, chẳng hạn tơ, máy bay, sách… và có những tḥc tính xác định Ở mức trìu tượng hơn, chẳng hạn khái niệm một thư viện, một hệ thống lưu trữ dữ liệu y tế, hoặc một bộ xử lý ngôn ngữ sẽ khó mơ hình hóa theo phương pháp này Chúng khơng cần có mợt giao diện đơn giản gồm tḥc tính và phương thức đợc lập

Việc phát triển mơ hình đới tượng q trình phân tích u cầu thường giúp đơn giản hóa việc chuyển sang lập trình và thiết kế hướng đới tượng Tuy nhiên, những người dùng cuối thường nhận thấy mơ hình đới tượng là khơng tự nhiên và khó hiểu Nhiều người thích sử dụng mơ hình hướng chức để hiển thị việc xử lý dữ liệu

(94)

Hình 5.4 Phân biệt đối tượng lớp đối tượng

Một biểu đồ lớp là mợt dạng mơ hình tĩnh Mợt biểu đồ lớp miêu tả hướng nhìn tĩnh hệ thớng khái niệm lớp và mối quan hệ giữa chúng với Mặc dù có những nét tương tự mơ hình dữ liệu, lớp khơng phải thể cấu trúc thơng tin mà cịn miêu tả cả hành vi

Một mục đích biểu đồ lớp là tạo tảng cho biểu đồ khác, thể khía cạnh khác hệ thớng (ví dụ biểu đồ trạng thái đối tượng hay biểu đồ cộng tác giữa đới tượng) Mợt lớp mợt biểu đồ lớp được thực thi trực tiếp một ngôn ngữ hướng đới tượng có hỗ trợ trực tiếp khái niệm lớp Một biểu đồ lớp lớp, bên cạnh cịn được dùng để đối tượng thật là thực thể lớp này (biểu đồ đối tượng)

a) Biểu diễn đối tượng

UML thể lớp hình chữ nhật có phần Phần thứ chứa tên lớp, phần thứ hai là tḥc tính và dữ liệu thành phần lớp, phần thứ ba là phương thức hay hàm thành phần lớp

- Tên lớp (class name): Tên lớp được in đậm và giữa Tên lớp phải được dẫn xuất từ phạm vi vấn đề và rõ ràng Vì là danh từ, ví dụ tài khoản, nhân viên

- Thuộc tính (attribute): Lớp có tḥc tính miêu tả những đặc điểm đới tượng Giá trị tḥc tính thường là những dạng dữ liệu đơn giản được đa phần ngơn ngữ lập trình hỗ trợ Integer, Boolean, Floats, Char…

Tḥc tính có nhiều mức độ trông thấy được (visibility) khác nhau, miêu tả liệu tḥc tính được truy xuất từ lớp khác với lớp định nghĩa Nếu tḥc tính có tính trơng thấy là cơng cợng (public – kí hiệu “+”), được nhìn thấy và sử dụng ngoài lớp Nếu tḥc tính có tính trơng thấy riêng (private – kí hiệu “-”), bạn sẽ khơng thể truy cập từ bên ngoài lớp Mợt tḥc tính trơng thấy khác là bảo vệ (protected), được sử dụng chung với công cụ khái qt hóa và chun biệt hóa Nó giớng tḥc tính riêng được thừa kế lớp dẫn xuất

Giá trị được gán cho tḥc tính là mợt cách để miêu tả trạng thái đối tượng, giá trị này thay đổi trạng thái đới tượng thay đổi theo

- Phương thức (methods): Phương thức định nghĩa hoạt đợng mà lớp thực Tất cả đối tượng được tạo từ mợt lớp sẽ có chung tḥc tính và phương thức Phương thức được sử dụng để thay đổi giá trị tḥc tính thực cơng việc khác Phương thức thường được gọi là hàm (function), chúng nằm mợt lớp và được áp dụng cho đối tượng lớp này Một phương thức được miêu tả qua tên, giá trị trả và danh sách không hoặc nhiều tham số Lúc thi hành, phương thức được gọi kèm theo tên mợt đới tượng lớp Vì nhóm phương thức miêu tả những dịch vụ mà lớp cung cấp nên chúng được coi là giao diện lớp này Giớng tḥc tính, phương thức có tính trông thấy được công cộng, riêng và bảo vệ

(95)

Hình 5.5 Mợt lớp với tḥc tính tiêu biểu

Hình 5-6 Mợt lớp với thuộc tính chung riêng

Hình 5.7 Mợt lớp với tḥc tính giá trị mặc định

Đối tượng là thực thể lớp nên kí hiệu dùng cho đới tượng là kí hiệu dùng cho

lớp Tuy nhiên, UML đối tượng bao gồm hai phần: tên đới tượng và danh sách tḥc tính đới tượng được gán giá trị cụ thể Hình 5.8 là mợt ví dụ việc biểu diễn đới tượng UML

Hình 5.8 Ký hiệu đối tượng

Hình 5.8 được đọc sau: CAH là đới tượng lớp AccountHolder Các tḥc tính Invoice

+ amount: Real + data: Date + customer: String + specification: String - administrator: String

Invoice + amount: Real

+ data: Current date + customer: String + specification: String

- administrator: String = “Unspecified”

CAH: AccountHolder Name = “Charles” Age = 35

(96)

- Khái qt hóa (Generalization)

- Phụ tḥc (Dependency) và nâng cấp (Refinement)

Một liên hệ là mợt nới kết giữa lớp, có nghĩa là nối kết giữa đối tượng lớp này Trong UML, một liên hệ được định nghĩa là một mối quan hệ miêu tả một tập hợp liên kết (là một liên quan ngữ nghĩa giữa mợt nhóm đới tượng)

Khái qt hóa là mới quan hệ giữa mợt yếu tớ mang tính khái qt cao và mợt yếu tớ mang tính chun biệt Yếu tớ mang tính chun biệt chứa thơng tin bổ sung Một thực thể (một đối tượng là một thực thể mợt lớp) yếu tớ mang tính chuyên biệt được sử dụng bất cứ nơi nào mà đới tượng mang tính khái qt hóa được phép

Sự phụ thuộc là mợt mối quan hệ giữa yếu tố, gồm một yếu mang tính đợc lập và mợt yếu tớ mang tính phụ tḥc Mợt thay đổi yếu tớ độc lập sẽ ảnh hưởng đến yếu tố phụ thuộc Một nâng cấp là mối quan hệ giữa hai lời miêu tả cùng một vật, những mức đợ trừu tượng hóa khác

 Liên hệ (association)

Một liên hệ là một nối kết giữa lớp, một liên quan ngữ nghĩa giữa đối tượng lớp tham gia Liên hệ thường mang tính hai chiều, có nghĩa mợt đới tượng này có liên hệ với mợt đới tượng khác cả hai đới tượng này nhận thấy Một mối liên hệ biểu thị đới tượng hai lớp có nới kết với nhau, ví dụ: "chúng biết nhau", "được nới với nhau", "cứ X lại có mợt Y"… Mới liên kết được thể biểu đồ UML một đường thẳng nới hai lớp Trên đường thẳng này có thích thêm tên vai trị, là mợt chức mà lớp đảm nhận nhìn từ góc nhìn lớp Tên vai trò được viết kèm với một mũi tên từ hướng lớp chủ nhân ra, thể lớp này đóng vai trị nào đối với lớp mà mũi tên đến

Hình 5.9 Vai trị liên hệ Customer Account

Trong ví dụ trên: mợt khách hàng là chủ nhân mợt tài khoản và tài khoản được chiếm giữ khách hàng Đường thẳng thể liên hệ giữa hai lớp

(97)

Hình 5.10 Mợt biểu đồ lớp tiêu biểu

Hình 5.10 là ví dụ cho mợt biểu đồ lớp tiêu biểu Biểu đồ giải thích bợ phận dịch vụ tài khoản tiết kiệm một nhà băng có nhiều tài khoản tiết kiệm tất cả những tài khoản này thuộc bộ phận Mợt tài khoản tiết kiệm lại có nhiều tài liệu, những tài liệu này thuộc một tài khoản tiết kiệm mà Một tài khoản tiết kiệm tḥc từ mợt nhiều là ba khách hàng Mỗi khách hàng có nhiều mợt tài khoản

 Khái quát hóa chuyên biệt hóa (generalization & specialization)

Trong biểu đồ trên, lớp một cấu trúc được nối với một mũi tên rỗng, từ lớp chuyên biệt tới lớp khái quát

Quá trình bắt đầu với một lớp khái quát để sản xuất lớp mang tính chuyên biệt cao hơn được gọi là q trình chun biệt hoá (Specialization) Chun biệt hóa là q trình tinh chế mợt lớp thành những lớp chuyên biệt Chuyên biệt hóa bổ sung thêm chi tiết và đặc tả cho lớp kết quả Lớp mang tính khái quát được gọi là lớp cha (superclass), kết quả chuyên biệt hóa là việc tạo lớp (Subclass)

Chuyên biệt hóa và khái quát hóa là hai đường khác để xem xét cùng một mối quan hệ Một lớp là lớp mợt lớp này đóng vài trị là một lớp cha lớp khác

(98)

Hình 5.11 Khái qt hóa chun biệt hố

Trong hình trên, tài khoản là khái niệm chung loại tài khoản khác và chứa những đặc tả cần thiết cho tất cả loại tài khoản Ví dụ chứa sớ tài khoản và tên chủ tài khoản Ta có hai loại tài khoản đặc biệt suy từ dạng tài khoản chung này, mợt loại mang tính kỳ hạn và mợt loại mang tính giao dịch Yếu tố chia cách hai lớp này với là quy định chuyên ngành hay là phương thức hoạt động hai loại tài khoản

Tương tự vậy, tài khoản đầu tư trung hạn và dài hạn lại là những khái niệm chuyên biệt khái niệm tài khoản có kỳ hạn Mặt khác, tài khoản bình thường và tài khoản tiết kiệm là những trường hợp đặc biệt loại tài khoản giao dịch

5.2.4 Mơ hình (Sequence diagram)

Biểu đồ minh họa đối tượng tương tác với Chúng tập trung vào chuỗi thơng điệp, có nghĩa là thơng điệp được gửi và nhận giữa một loạt đối tượng nào Biểu đồ có hai trục: trục nằm dọc thời gian, trục nằm ngang một tập hợp đới tượng

Từ hình chữ nhật biểu diễn đới tượng có đường gạch rời thẳng đứng biểu thị đường đời đối tượng, tức là tồn đối tượng chuỗi tương tác Trong khoảng thời gian này, đối tượng được thực thể hóa, sẵn sàng để gửi và nhận thơng điệp Q trình giao tiếp giữa đới tượng được thể đường thẳng, thông điệp nằm ngang nối đường đời đối tượng Mũi tên đầu đường thẳng sẽ loại thơng điệp này mang tính đồng bộ, không đồng bộ hay đơn giản Để đọc biểu đồ tuần tự, bắt đầu từ phía bên biểu đồ chạy dọc xuống và quan sát trao đổi thông điệp giữa đối tượng xảy dọc theo tiến trình thời gian

(99)

Hình 5.12 Biểu đồ kịch chức rút tiền mặt máy ATM

Biểu đồ được diễn giải theo trình tự thời gian sau:

- Có ba lớp tham gia kịch bản này: khách hàng, máy ATM và tài khoản - Khách hàng đưa yêu cầu rút tiền vào máy ATM

- Đối tượng máy ATM yêu cầu khách hàng cung cấp mã số - Mã số được gửi cho hệ thống để kiểm tra tài khoản

- Đối tượng tài khoản kiểm tra mã số và báo kết quả kiểm tra đến cho ATM - ATM gửi kết quả kiểm tra này đến khách hàng

- Khách hàng nhập số tiền cần rút

- ATM gửi số tiền cần rút đến cho tài khoản

(100)

Bởi khách hàng ḿn tiếp tục thực giao dịch khác nên đối tượng khách hàng và đối tượng máy ATM tiếp tục tồn tại, điều này được qua việc đường đời đối tượng được kéo vượt đường thẳng thể kiện cuối cùng chuỗi tương tác

Loại tương tác này là hữu dụng mợt hệ thớng có mợt sớ lượng nhỏ đới tượng với một số lượng lớn kiện xảy giữa chúng Mặc dù vậy, số lượng đới tượng mợt hệ thớng tăng lên mơ hình này sẽ khơng cịn thích hợp

Để vẽ biểu đồ tuần tự, xác định đối tượng liên quan và thể kiện xảy giữa chúng Khi vẽ biểu đồ tuần tự, cần ý:

- Sự kiện được biểu diễn đường thẳng nằm ngang - Đối tượng đường nằm dọc

- Thời gian được thể đường thẳng nằm dọc bắt đầu từ biểu đồ Điều có nghĩa là kiện cần phải được thể theo thứ tự mà chúng xảy ra, vẽ từ xuống

5.2.5 Mơ hình trạng thái máy

Mơ hình trạng thái máy mơ tả hệ thớng phản ứng lại kiện bên và bên ngoài Mơ hình trạng thái máy biểu diễn trạng thái hệ thống và kiện gây biến đổi trạng thái này chứ không luồng dữ liệu hệ thớng Kiểu mơ hình này thường được sử dụng hệ thống thời gian thực thông thường hệ thống này được điều khiển việc mô từ môi trường hệ thống

Các mơ hình trạng thái máy là mợt phần phương pháp thiết kế thời gian thực Trong UML có lược đồ trạng thái (StateChart) để biểu diễn mơ hình này

Mơ hình trạng thái máy một hệ thống rằng, thời điểm nào, hệ thớng có mợt tập hợp trạng thái Khi mợt tín hiệu được nhận, biến đổi hệ thớng từ trạng thái này sang trạng thái khác Ví dụ mợt hệ thớng điều khiển van chuyển từ trạng thái van đóng sang trạng thái van mở hệ thớng nhận được lệnh

Cách tiếp cận để mô hình hóa hệ thớng được minh họa hình 5.14 Sơ đồ này mợt mơ hình trạng thái máy mợt lị vi sóng đơn giản có gắn nút chọn nhiệt độ (power) và nút thiết lập thời gian bắt đầu Lị vi sóng đại có nhiều chức phức tạp Tuy nhiên, mơ hình này bao gồm những chức bản hệ thớng Để đơn giản hóa, ta giả sử bước để sử dụng lị vi sóng là:

1 Chọn nhiệt độ Đặt thời gian

3 Ấn nút start, máy sẽ hoạt động thời gian kết thúc

Vì lý an toàn, lị vi sóng sẽ khơng hoạt đợng cánh cửa được mở, hoàn thành việc sử dụng, có mợt âm nhắc nhở Lị vi sóng có nhiều cách hiển thị thơng báo và cảnh báo khác

(101)

tả ngắn gọn hoạt đợng được thực trạng thái này Một mũi tên được gán nhãn tác nhân biến đổi trạng thái

Hình 5.13 Lược đồ trạng thái lị vi sóng

Tuy nhiên, hình 5.13 nhận thấy hệ thống trả lời kiện khởi đầu lựa chọn nút full-power và half-power Người sử dụng thay đổi sau ấn nút khác Thời gian được thiết lập và cửa sổ đóng, nút Start được kích hoạt, hệ thớng sẽ hoạt động thời gian thiết lập hết

Lược đồ UML để hoạt động được thực một trạng thái Trong một đặc tả hệ thống chi tiết, bạn phải cung cấp thông tin chi tiết việc kích hoạt và trạng thái hệ thớng, những thơng tin này được lưu một từ điển dữ liệu hoặc một bách khoa thư được lưu trữ một công cụ CASE được sử dụng để tạo mơ hình hệ thống

Vấn đề nảy sinh với cách tiếp cận này là số lượng trạng thái hệ thớng tăng lên nhanh chóng Đới với những mơ hình hệ thớng lớn, việc cấu trúc hóa mơ hình trạng thái này là cần thiết

(102)

1 Hãy nêu vai trị việc mơ hình hóa hệ thớng tiến trình phát triển phần mềm UML là gì? Vai trị loại biểu đồ UML giai đoạn phát triển phần mềm Hãy xây dựng mơ hình ngữ cảnh và mơ hình trường hợp sử dụng (use-case) hệ thống

máy rút tiền tự động ATM

4 Xác định lớp và xây dựng mơ hình lớp hệ thớng phần mềm nhúng điều khiển hoạt động hệ thống máy rút tiền tự đợng ATM

5 Xây dựng mơ hình chức chuyển tiền từ tài khoản này sang tài khoản khác máy rút tiền tự động ATM

(103)

Chương 6: THIẾT KẾ PHẦN MỀM

Trong phát triển phần mềm, giai đoạn phân tích và đặc tả yêu cầu sẽ xác định những chức bản phần mềm và ràng buộc đối với phần mềm tiến trình phát triển Nói cách khác, giai đoạn này phải trả lời câu hỏi “hệ thớng cần làm gì?” Sau xác định rõ mục tiêu cần thực sẽ chuyển qua giai đoạn thiết kế, giai đoạn này trả lời câu hỏi “làm nào” thông qua việc đưa giải pháp để thực những yêu cầu đề trình đặc tả

Chương này sẽ giới thiệu khái niệm bản thiết kế, vai trị và hoạt đợng bản thiết kế Phần chương đề cập đến một số chiến lược và phương pháp thiết kế Phần trình bày vấn đề bản thiết kế kiến trúc Phần cuối cùng giới thiệu một phương pháp thiết kế được sử dụng rộng rãi bên cạnh phương pháp thiết kế hướng chức mà sinh viên quen thuộc mơn học trước, là phương pháp thiết kế hướng đới tượng Qua sinh viên hiểu được những nguyên tắc, công việc phải thực q trình thiết kế phần mềm Từ có khả ứng dụng đề án thực tế 6.1 TỔNG QUAN VỀ THIẾT KẾ PHẦN MỀM

6.1.1 Giới thiệu chung a Khái niệm thiết kế

“Thiết kế phần mềm trình chuyển đặc tả yêu cầu phần mềm thành biểu diễn thiết kế hệ thống phần mềm cần xây dựng, cho người lập trình dựa sở đó để xây dựng thành chương trình vận hành được”

Cụ thể hơn, người kỹ sư thiết kế phần mềm cần dựa vào mô tả dịch vụ mà phần mềm sẽ cung cấp những ràng buộc cần tuân thủ hoạt động để đưa giải pháp công nghệ thích hợp, sẽ vận hành thực tế, nhằm đáp ứng yêu cầu đặt

Mục tiêu giai đoạn này là đưa một giải pháp cho vấn đề đặt giai đoạn đặc tả và cấu trúc hố giải pháp này mợt cách rõ ràng, đầy đủ, khơng nhập nhằng, khơng có dư thừa Cuối cùng sẽ mô tả phương án thiết kế một tài liệu thiết kế

Để đưa được giải pháp phù hợp, người thiết kế phải thực công việc sau: - Nghiên cứu tìm hiểu vấn đề

(104)

b Vai trò thiết kế

Trong phát triển phần mềm, bỏ qua giai đoạn thiết kế nguy sinh một hệ thống không tin cậy, khả thất bại cao Đặc biệt phần mềm là mợt sản phẩm vơ hình và phức tạp, khó xác định chất lượng trước kiểm thử và vận hành hệ thống Thiết kế là một khâu then chốt định chất lượng sản phầm Về bản, hoạt đợng thiết kế có vai trị:

- Thiết kế là cách để chuyển hóa mợt cách xác yêu cầu khách hàng thành mơ hình hệ thớng phần mềm, làm sở cho việc triển khai chương trình phần mềm

- Tài liệu thiết kế là sở để giao tiếp giữa nhóm cùng tham gia vào việc phát triển sản phẩm Giúp quản lý rủi ro và lập kế hoạch phát triển phần mềm một cách hiệu quả

- Một tài liệu thiết kế bao gồm một tập hợp mơ hình cấu trúc hố, đồng và hoàn thiện, mơ hình này được hiển thị theo nhiều cách khác (bằng ngơn ngữ hình thức hoặc phi hình thức) Do đó, là tài liệu tham khảo quan trọng bước tiến trình phát triển phần mềm như: giai đoạn phát triển, giai đoạn kiểm thử, giai đoạn bảo trì

c Một số khái niệm thiết kế

Mặc dầu có nhiều phương pháp thiết kế phần mềm trình thiết kế sử dụng một số khái niệm làm tảng Chúng được gọi là tảng thiết kế

 Trừu tượng hóa (abstraction)

Khái niệm trừu tượng hóa là cho phép tập trung vào vấn đề mức tổng qt nào đó, khơng xét tới chi tiết mức thấp không liên quan Trừu tượng hoá cho phép ta làm việc với khái niệm và thuật ngữ quen thuộc môi trường vấn đề mà không phải biến đổi chúng thành một cấu trúc không quen thuộc

Khi xét vấn đề cho việc tìm giải pháp module hóa, đặt nhiều mức đợ trừu tượng Tại mức trừu tượng cao nhất: phát biểu ngôn ngữ môi trường vấn đề Tại mức trừu tượng thấp hơn, thường lấy khuynh hướng thủ tục; mức thấp nhất, giải pháp được phát biểu theo cách cài đặt trực tiếp Trong bước tiến trình là làm mịn cho một mức trừu tượng giải pháp

 Phân rã (decomposition)

Phân rã là việc phân chia một đối tượng thành những đối tượng nhỏ Đây là một cách để dễ dàng nghiên cứu đới tượng đơn giản

 Làm mịn (Refinement)

(105)

Cần ý là mọi bước làm mịn kéo theo những định thiết kế nào Người lập trình cần nhận biết tiêu chuẩn tảng cho định thiết kế và tồn giải pháp khác

 Tính module

Phần mềm được chia thành phần có tên riêng biệt và định địa được, gọi là module Các module được tích hợp với để giải yêu cầu vấn đề đặt Khái niệm này có ý nghĩa quan trọng q trình thiết kế: là mợt tḥc tính riêng phần mềm, cho phép tổ chức mợt chương trình trở nên quản lý được theo mợt cách thơng minh

Nếu mợt vấn đề x phân thành hai vấn đề x1, x2 nhỏ để giải thực nghiệm chứng minh được rằng:

C(x1+ x2) > C(x1) + C(x2) E(x1 + x2) > E(x1) + E(x2)

Trong C(x) là hàm xác định độ phức tạp cảm nhận được vấn đề x, và E(x) là hàm xác định nỗ lực cần có để giải vấn đề x Như vậy, chia nhỏ mợt vấn đề việc giải trở nên dễ và cơng sức bỏ để giải

 Thủ tục phần mềm (software procedure)

Thủ tục phần mềm tập trung vào việc mô tả chi tiết bước xử lý cho module riêng biệt Thủ tục phải cung cấp mợt đặc tả xác mợt q trình xử lý, có đầu vào, đầu ra, trình tự kiện, điểm định rẽ nhánh điều khiển, thao tác lặp lại, bao gồm cả cấu trúc/tổ chức dữ liệu được sử dụng

 Che dấu thông tin (information hiding)

Che dấu thông tin là khái niệm module nên được đặc trưng những định thiết kế mà ẩn kín với mọi module khác, thơng tin chứa module này thâm nhập tới được từ module khác không cần đến những thông tin Che dấu thơng tin kéo theo việc xác định một tập module độc lập mà trao đổi giữa module là thông tin thật cần thiết cho việc vận hành phần mềm

Che dấu thông tin là một tiêu chuẩn thiết kế đối với hệ thớng module những lợi ích mà mang lại Khi có sai sót xảy ra, thay đổi sẽ có khả lan truyền sang những vị trí khác bên phần mềm

6.1.2 Thiết kế phần mềm

(106)

Hình 6.1 Mơ hình tiến trình thiết kế

Sau hoạt đợng thiết kế, nhóm thiết kế cần đưa mợt bản đặc tả thiết kế Bản đặc tả này là mợt đặc tả trìu tượng, nửa hình thức, hình thức hay là mợt đặc tả mợt phần nào hệ thớng phải đưọc thực nào Thực chất trình thiết kế là việc bổ sung dần chi tiết vào đặc tả thiết kế Kết quả cuối cùng là đặc tả thuật toán, cấu trúc dữ liệu và đặc tả giao diện được dùng làm sở cho việc mã hóa

Phương pháp tiếp cận hệ thống thường được sử dụng là phương pháp tiếp cận từ xuống: vấn đề được phân chia một cách đệ quy thành vấn đề vấn đề nhận được giải một cách dễ dàng Ngược lại, thiết kế người ta lại thường thực từ lên, vấn đề mức thấp là đủ nhỏ, đủ thơng tin cần thiết để người thiết kế dễ dàng tìm giải pháp cơng nghệ thích hợp và dễ nhận thành phần nào dùng lại được phần khác hay chương trình khác

Quá trình này được lặp lại thành phần hợp thành hệ được xác định để ánh xạ trực tiếp vào thành phần khác (ví dụ gói, thủ tục và hàm) biểu diễn một ngôn ngữ lập trình nào

b Các hoạt động sản phẩm thiết kế

Đối với việc phát triển hệ thống phần mềm lớn, hoạt động thiết kế được tiến hành theo bước sau:

- Thiết kế kiến trúc: Xác định hệ thống tạo nên hệ thống và mối liên hệ giữa chúng

- Đặc tả trìu tượng: Đới với hệ thớng con, mơ tả trìu tượng dịch vụ mà cung cấp và ràng ḅc mà phải tuân thủ cung cấp dịch vụ

- Thiết kế giao diện thành phần: Thiết kế giao diện hệ chúng giao tiếp với hệ khác, hệ thống khác cùng môi trường hoạt động hệ thống cho hệ thực thi dịch vụ hệ khác mà khơng cần biết q trình thực được diễn nào

- Thiết kế cấu trúc dữ liệu: thiết kế và đặc tả cấu trúc dữ liệu được dùng phát triển hệ thống

- Thiết kế giao diện người dùng: Thiết kế giao diện người dùng để người sử dụng tương tác với hệ thớng

- Thiết kế thành phần: Phân chia dịch vụ mà hệ thống cung cấp vào thành phần

- Thiết kế thủ tục: Đặc tả thuật tốn, quy trình thực dịch vụ thành phần cho ánh xạ trực tiếp vào ngơn ngữ lập trình

Phác thảo thiết kế phi

hình thức

Thiết kế phi hình thức

Thiết kế hình thức

(107)

Hình 6.2 Các hoạt đợng thiết kế sản phẩm chúng

c Biểu diễn thiết kế

Một bản thiết kế phần mềm là một mô hình mơ tả mợt hệ thớng giới thực với nhiều thành phần và những mối quan hệ giữa chúng Thơng thường người ta sử dụng ba hình thức sau để biểu diễn thiết kế:

- Các biểu đồ: Các biểu đồ dùng để thể mối liên hệ giữa thành phần tạo nên hệ thớng và là mơ hình mơ tả giới thực Việc sử dụng biểu đồ để mơ hình hóa hệ thớng có nhiều ưu điểm, mơ tả một cách trực quan bức tranh tổng thể hệ thớng

- Ngơn ngữ mơ tả chương trình: Các ngôn ngữ này được dùng để kiểm tra và cấu trúc thiết kế dựa cấu trúc mợt ngơn ngữ lập trình được lựa chọn để phát triển hệ thống

- Dạng văn ngôn ngữ tự nhiên: Dạng biểu diễn này sẽ giúp mô tả những thơng tin khơng thể hình thức hóa yêu cầu phi chức và mô tả khác d Các giai đoạn thiết kế

Trong giai đoạn thiết kế, ta nhìn nhận tiến trình thiết kế phần mềm theo nhiều khía

Đặc tả

các yêu cầu Thiết kế kiến trúc Đặc tả trìu tượng

Thiết kế giao diện thành phần Thiết kế cấu trúc

dữ liệu Thiết kế giao diện người dùng

Thiết kế thành phần

Thiết kế thủ tục

Kiến trúc hệ thống Đặc tả phần

mềm Đặc tả giao diện

thành phần Đặc tả cấu trúc

dữ liệu Đặc tả giao diện

người dùng Đặc tả thành

phần Đặc tả thủ tục

(108)

yếu tớ vật lý mà nhà thiết kế vận dụng nguyên tắc thiết kế và sáng tạo để vẽ lên mợt hệ thớng phần mềm lý tưởng đáp ứng yêu cầu đặt

- Thiết kế vật lý: Lựa chọn giải pháp cơng nghệ có để thực cấu trúc logic cho một cách phù hợp với điều kiện môi trường dự kiến hệ thống phần mềm Giai đoạn này đòi hỏi nhà thiết kế phải có khả lựa chọn giải pháp kỹ thuật và phương tiện thích hợp điều kiện hữu để thực chức hệ thống nhằm đáp ứng tốt yêu cầu người dùng

6.1.3 Các chiến lược phương pháp thiết kế

Hiện có nhiều phương pháp tiếp cận khác được áp dụng cho thiết kế Các tiếp cận này giúp cho trình thiết kế trở nên rõ ràng hơn, theo dõi được và mang tính khoa học Trong đó, có cách tiếp cận phổ biến là thiết kế hướng chức (cấu trúc) và thiết kế hướng đối tượng Tương ứng với cách tiếp cận này là chiến lược cho việc phát triển một hệ thống phần mềm Với chiến lược, đặc trưng cách tiếp cận và đặc thù hệ thống phần mềm mà phương pháp được sử dụng khác Tuy nhiên, có những phương pháp kết hợp cả hai chiến lược thiết kế này Chẳng hạn phương pháp thiết kế giao diện, máy trạng thái hữu hạn…

a Thiết kế hướng chức

Theo cách tiếp cận này, hệ thống được phân chia thành chức năng, bắt đầu mức cao nhất, sau làm mịn dần để thành thiết kế với chức chi tiết Trạng thái hệ thống thể qua sở dữ liệu chung được chia sẻ cho chức thao tác (hình 6.3)

Trong phương pháp hướng cấu trúc (hướng chức năng), phần mềm được thiết kế dựa một hai hướng: hướng dữ liệu hướng hành động

- Cách tiếp cận hướng liệu xây dựng phần mềm dựa việc phân rã theo chức cần đáp ứng dữ liệu cho chức Cách tiếp cận hướng dữ liệu sẽ giúp cho những người phát triển hệ thống dễ dàng xây dựng ngân hàng dữ liệu

- Cách tiếp cận hướng hành động lại tập trung phân tích hệ thống phần mềm dựa hoạt động thực thi chức phần mềm

Cơ sở dữ liệu chung Phần

chương trình

(109)

Hình 6.3 Mơ hình hệ thống hướng cấu trúc

Cách thức thực phương pháp hướng cấu trúc phương pháp thiết kế từ

xuống (top-down) Phương pháp tiến hành phân rã toán thành toán nhỏ hơn,

tiếp tục phân rã toán nhận được tốn cài đặt được ngay, sử dụng hàm ngôn ngữ lập trình hướng cấu trúc Phương pháp hướng cấu trúc có ưu điểm tư phân tích thiết kế rõ ràng, chương trình sáng sủa dễ hiểu Tuy nhiên, phương pháp có mợt sớ nhược điểm sau:

- Không hỗ trợ việc tái sử dụng Các chương trình hướng cấu trúc phụ tḥc chặt chẽ vào cấu trúc dữ liệu toán cụ thể, khơng thể dùng lại mợt module phần mềm cho phần mềm với yêu cầu dữ liệu khác

- Không phù hợp để phát triển phần mềm lớn Nếu hệ thống thông tin lớn, việc phân rã thành toán phân toán thành module quản lý mối quan hệ giữa module sẽ khơng dễ dàng, dễ gây lỗi phân tích thiết kế hệ thớng khó kiểm thử bảo trì

b Thiết kế hướng đối tượng

Hệ thớng được nhìn nhận một bộ đối tượng (chứ không phải là bộ chức năng) Hệ thống được phân rã thành đới tượng, đới tượng có nhsững thơng tin trạng thái riêng Thiết kế hướng đới tượng là dựa việc che dấu thơng tin, nhìn hệ thống phần mềm một bộ đối tượng tương tác với chứ không phải là một bộ chức cách tiếp cận hướng chức Các đới tượng này có mợt trạng thái được che dấu và phép tốn trạng thái Thiết kế biểu thị dịch vụ được yêu cầu và được cung cấp đới tượng có tương tác với

Mặc dù phát triển từ những năm 90 kỷ XX có nhiều phương pháp phát triển hướng đối tượng đời Một ngôn ngữ chuẩn UML và nhiều công cụ mạnh (Jbuilder, Rational Rose) được phát triển để trợ giúp cho phương pháp

6.1.4 Chất lượng thiết kế giải pháp đảm bảo chất lượng

Như đề cập trên, khó để xác định được nào là thiết kế tốt, điều này phụ thuộc vào ứng dụng và vào yêu cầu dự án Một thiết kế tốt phải là một thiết kế mà cho phép sản sinh mã nguồn hữu hiệu; là mợt thiết kế tới thiểu mà theo việc thực càng chặt chẽ càng tớt; hoặc là thiết kế bảo dưỡng được tốt hay là tiêu chuẩn tốt cho người dùng Mợt thiết kế bảo dưỡng tớt thích nghi với việc thay đổi hoặc thêm chức

(110)

tất cả bợ phận phải tham gia vào việc thực này Nếu một thành phần không trực tiếp tham gia vào chức logic mức đợ kết dính là thấp

Theo mợt sớ chun gia, có bảy mức kết dính theo thứ tự tăng dần sau đây:

- Kết dính gom góp (kết dính ngẫu nhiên): Các thành phần mợt module được nhóm lại với mợt cách ngẫu nhiên, khơng có tính logic (ví dụ: module bao gồm tất cả chức năng; kho chứa dữ liệu được sử dụng thành phần khác nhau)

- Kết dính hội hợp logic: Các thành phần cùng thực chức tương tự chẳng hạn vào/ra dữ liệu, xử lý lỗi… được đặt vào cùng một thành phần

- Kết dính theo thời điểm: Tất cả thành phần cùng kích hoạt mợt lúc, chẳng hạn khởi và kết thúc được bó lại với

- Kết dính thủ tục: Các phần tử thành phần được ghép lại một dãy điều khiển - Kết dính truyền thơng: Tất cả phần tử thành phần cùng thao tác một dữ liệu

vào và đưa cùng mợt dữ liệu

- Kết dính tuần tự: Trong một thành phần, đầu phần tử này là đầu vào phần tử khác

- Kết dính chức năng: Mỗi phần thành phần cần thiết để thi hành cùng một chức nào

Trong bảy mức đợ kết dính nói trên, có mức đợ kết dính ći cùng là được khuyến khích sử dụng nhóm thành phần được sử dụng cho một chức hệ thống, thay đổi thành phần này kéo theo việc thay đổi và kiểm định lại module thuộc chức khác có liên quan

b Sự ghép nối

Sự ghép nối (coupling) độ ghép nới giữa đơn vị chương trình Hệ thớng có ghép nới cao sẽ có đợ ghép nới mạnh giữa đơn vị, nói cách khác đơn vị phụ thuộc lẫn Hệ thống nối ghép lỏng lẻo làm cho đơn vị là độc lập hoặc tương đối độc lập với

Sự ghép nối một thành phần với thành phần khác thể số lượng mối liên kết phụ thuộc giữa với thành phần khác Các module là được ghép nối chặt chẽ chúng dùng biến chung và chúng trao đổi thông tin điều khiển (ghép nối chung và ghép nối điều khiển) Ghép nối lỏng lẻo đạt được thông tin biểu diễn được giữ thành phần này và giao tiếp với thành phần khác thông qua danh sách tham sớ Việc tới thiểu hóa ghép nới không phải lúc nào thực được Dưới là loại ghép nới được trình bày theo trình tự từ tớt đến xấu:

- Khơng có liên kết trực tiếp: Các module khơng có mới liên hệ trực tiếp với nhau, khơng có trao đổi thông tin Việc nâng cấp module này không ảnh hưởng tới module khác

(111)

- Ghép nối nhãn: Các module trao đổi dữ liệu dạng có cấu trúc thơng qua giao diện (interface) Ví dụ trường hợp truyền tham số Trong trường hợp này, module thay đổi cấu trúc dữ liệu (thơng qua việc khai báo kiểu) Khi thực chương trình, lưu tham chiếu (con trỏ, địa đối tượng)

- Ghép nối điều khiển: Giao diện cho phép chi phối cách thực bên module Trong trường hợp này, module đưa thơng tin có liên quan đến module khác, hạn chế việc nâng cấp sửa đổi module

- Ghép nối mở rộng: Hai module trao đổi thông tin với phần tử trung gian mơi trường bên ngoài ứng dụng Ví dụ: Hai ứng dụng hệ quản trị trường học là đăng ký học và tính tốn kết quả cần trao đổi thông tin qua người sử dụng trung gian (giáo viên, điểm thi) Trong trường hợp này, kênh trao đổi thông tin khơng được xác định, bị bỏ sót q trình nâng cấp

- Ghép nối chung: Hai module dùng chung biến toàn cục Ví dụ việc trao đổi thông tin qua biến toàn cục cấu trúc COMMON ngôn ngữ Fortran, biến Public Visual Basic Càng nhiều biến toàn cục được sử dụng chung, càng khó nâng cấp cấu trúc

- Ghép nối nội dung: Một module biết và mở rộng nội dung một module khác (truy cập vào biến private, vào cấu trúc logic…) Ví dụ: Sử dụng giá trị sớ; khai thác thông tin không được công khai qua dữ liệu giao diện (một module sử dụng kết quả việc sắp xếp dữ liệu module khác) Trong trường hợp này, nội dung module được triển khai, mở rộng hoặc nâng cấp module

c Tính hiểu

Tính hiểu được liên quan tới một số đặc trưng thành phần sau đây:

- Tính kết dính: Có thể hiểu được thành phần mà khơng cần tham khảo đến mợt thành phần nào khác hay không?

- Đặt tên: Phải mọi tên được dùng thành phần có nghĩa? Tên có nghĩa là những tên phản ánh thực thể giới thực được mơ hình hóa thành phần

- Soạn tư liệu: Thành phần có được soạn thảo tư liệu cho ánh xạ giữa thực thể giới thực và thành phần là rõ ràng?

(112)

hỏi người đọc thiết kế phải nhìn nhiều lớp đới tượng khác thừa kế đợ dễ hiểu thiết kế là được rút gọn

d Sự thích nghi

Nếu mợt thiết kế nhằm tăng tính bảo trì phải sẵn sàng thích nghi được, nghĩa là thành phần hệ thống được ghép nối với mợt cách lỏng lẻo để có thay đổi hoặc bổ sung thành phần thành phần cịn lại bị can thiệp

Bên cạnh đó, phải soạn thảo tớt tài liệu thiết kế, dễ hiểu và đồng với việc xây dựng phần mềm, có mới quan hệ rõ ràng giữa mức khác thiết kế Người đọc bản thiết kế tìm được biểu diễn liên quan lược đồ cấu trúc hay thấy được biển đổi dòng dữ liệu

Cần phải luôn kết hợp chặt chẽ những thay đổi thiết kế toàn bộ tư liệu thiết kế, không tư liệu thiết kế trở nên khơng quán và những thay đổi tiếp sau là khó thực

e Một số hướng dẫn thiết kế

- Linh hoạt đối với những yêu cầu thay đổi không định trước - Dễ thử nghiệm

- Sáng sủa, dễ đọc - Kích thước module nhỏ

- Tính đợc lập module (tính mở/đóng giứa module) - Phải có mới quan hệ chặt chẽ giữa thiết kế và yêu cầu

- Mỗi module hoàn toàn độc lập, thực một chức và thực trọn vẹn chức

- Mọi thứ module ràng buộc với qua việc xử lý nới tiếp cùng mợt dịng dữ liệu

- Mọi thứ module được điều khiển cùng một dữ liệu vào, hay cùng một phức hợp thiết bị, hay cùng thực phần cùng mợt kết xuất

(113)

Hình 6.4 Hướng dẫn thiết kế tránh chia nhỏ module cố gắng co cụm tăng chiều sâu

- Giữ phạm vi hiệu quả một module bên phạm vi kiểm sốt module đó: + Phạm vi hiệu quả module m được định nghĩa là tất cả module khác bị ảnh hưởng một định thực module m

+ Phạm vi kiểm soát module m là tất cả module tḥc cấp m (tính tới mức cùng)

Hình 6.5 Phạm vi hiệu việc kiểm soát module

- Ước lượng giao diện module để giảm đợ phức tạp, dư thừa và tăng tính quán - Xác định module có chức dự kiến được

(114)

6.2.1 Khái niệm – tầm quan trọng thiết kế kiến trúc a Khái niệm

Kiến trúc phần mềm (software architecture) cấu trúc tổng thể phần mềm, qua đó cung cấp tích hợp mặt khái niệm hệ thống Hiểu một cách đơn giản, kiến trúc là cấu trúc phân cấp thành phần chương trình, qua thể tương tác giữa chúng với và với cấu trúc dữ liệu mà chúng sử dụng Theo nghĩa rộng, kiến trúc biểu diễn thành phần lớn, cốt lõi hệ thống và mối quan hệ giữa chúng với được nhìn theo những quan điểm khác

b Vai trò tầm quan trọng kiến trúc

Bass (Software Engineering, 8th Edition) và đồng nghiệp thảo luận những ưu điểm việc thiết kế kiến trúc một cách rõ ràng và việc tài liệu hóa kiến trúc phần mềm:

- Là cơng cụ giao tiếp người có liên quan (Stackeholder communication): Kiến trúc là một cách giới thiệu hệ thớng mức cao, sử dụng mợt tiêu điểm thảo luận nhóm khác có liên quan dự án

- Phân tích hệ thống (System Analysis): Tạo mợt kiến trúc hệ thống rõ ràng giai đoạn đầu q trình phát triển hệ thớng Quyết định thiết kế hệ thống sẽ giúp ta đáp ứng tốt những yêu cầu phi chức hệ thống

- Tái sử dụng quy mô lớn (Large-scale reuse): mợt mơ hình kiến trúc hệ thớng là mợt bản mô tả chắc chắn, dễ sử dụng cách tổ chức hệ thống và tác động qua lại giữa thành phần Kiến trúc hệ thống hệ thớng có u cầu tương tự thường giớng nhau, sử dụng lại phần lớn kiến trúc này

Hofmeister (Software Engineering, 8th Edition) và đồng nghiệp thảo luận việc thiết kế kiến trúc giai đoạn thiết kế phần mềm để xem xét những khía cạnh thiết kế quan trọng giai đoạn đầu tiến trình Họ gợi ý kiến trúc phần mềm được sử dụng mợt bản kế hoạch dự án, dùng để đàm phán những yêu cầu hệ thống và dùng để thảo luận với khách hàng, những người phát triển hệ thống và nhà quản lý Họ gợi ý là mợt công cụ thiết yếu cho công việc quản lý phức tạp, bỏ qua chi tiết hóa và cho phép người thiết kế tập trung vào hệ thống mức trìu tượng

c Kiến trúc đặc điểm hệ thống

Kiến trúc hệ thống ảnh hưởng tới thực thi, tính hiệu quả, tính phân tán và bảo trì hệ thớng Kiểu và cấu trúc được lựa chọn cho mợt ứng dụng phụ thuộc vào những yêu cầu phi chức hệ thớng:

(115)

- Tính bảo mật (security): Nếu bảo mật là một yêu cầu quan trọng, nên sử dụng kiến trúc phân tầng, những thông tin quan trọng sẽ được bảo vệ tầng sâu và việc kiểm tra tính an toàn phải được tiến hành một cách chắc chắn đối với những tầng này

- Tính an tồn (safety): Nếu an toàn là một yêu cầu quan trọng, hệ thống nên được thiết kế cho những chức địi hỏi tính an toàn cao nằm tập trung một hệ thống hoặc nằm một sớ những hệ thớng Việc này sẽ giảm được chi phí và những vấn đề phát sinh việc thẩm định (validation) tính an toàn, đồng thời giảm được chi phí để mua và bảo trì cơng cụ bảo vệ có liên quan

- Tính sẵn sàng (availability): Nếu tính sẵn sàng là một yêu cầu quan trọng, kiến trúc nên được thiết kế có nhiều thành phần dư thừa để thay và cập nhật thành phần mà khơng cần phải dừng hệ thớng

- Tính bảo trì (maintainability): Nếu tính bảo trì là mợt u cầu quan trọng, kiến trúc hệ thống nên được thiết kế việc sử dụng những thành phần nhỏ (fine_grain), những thành phần chứa (self-contained) dễ dàng thay đổi Nên sử dụng phương án chia dữ liệu theo khách hàng, chứ không nên phân chia theo cấu trúc dữ liệu

Có thể nhận thấy xung đột kiến trúc một cách rõ ràng Ví dụ: sử dụng những thành phần kích thước lớn để tăng hiệu suất giảm tính bảo trì; đưa những dữ liệu dư thừa (dự trữ) để nâng cao tính sẵn sàng lại làm cho tính bảo mật khó kiểm sốt hơn; tập trung vào những tính liên quan đến đợ an toàn có nghĩa là tăng nhu cầu trao đổi thơng tin, làm giảm hiệu suất hệ thống Nếu hai yếu tố mâu thuẫn quan trọng với hệ thớng cần phải có thỏa thuận để tìm giải pháp chung

6.2.2 Các định thiết kế kiến trúc

Thiết kế kiến trúc là mợt cơng việc sáng tạo, địi hỏi phải đưa được mợt cách tổ chức hệ thớng đảm bảo được những yêu cầu chức và phi chức Bởi là mợt tiến trình sáng tạo, hoạt đợng bên tiến trình này hoàn toàn khác nhau, phụ thuộc vào kiến trúc hệ thống và những yêu cầu đặc biệt hệ thống

Trong trình thiết kế kiến trúc, người làm thiết kế kiến trúc thực những định bản và có ảnh hưởng sâu sắc tới hệ thớng tiến trình phát triển Dựa kiến thức và kinh nghiệm, họ phải trả lời những câu hỏi bản sau:

- Có kiến trúc ứng dụng chung sử dụng không? - Hệ thống sẽ được phân tán nào?

(116)

a Tái sử dụng mẫu kiến trúc

Mặc dù hệ thống phần mềm là nhất, hệ thớng cùng mợt lĩnh vực có những kiến trúc tương tự phản ánh những khái niệm bản lĩnh vực ứng dụng Các kiến trúc lĩnh vực ứng dụng này có đặc điểm chung rõ ràng, chẳng hạn kiến trúc hệ thống quản lý thông tin được xây dựng quanh một lõi kiến trúc với biến đổi cho phù hợp với yêu cầu khách hàng Khi thiết kế kiến trúc hệ thống, bạn phải định hệ thống bạn là gì, những lớp ứng dụng nào dùng chung và định xem phần trăm kiến thức từ kiến trúc ứng dụng này sử dụng lại được

Đới với những hệ thống nhúng và hệ thống được thiết kế cho máy tính cá nhân, thơng thường chạy một bộ vi xử lý, không sử dụng kiến trúc phân tán Tuy nhiên, hầu hết hệ thống lớn là hệ thống phân tán, được xử lý nhiều máy tính khác Việc lựa chọn kiến trúc phân tán là một định then chốt ảnh hưởng tới hiệu suất và độ tin cậy hệ thống

Kiến trúc một hệ thống phần mềm dựa mợt mơ hình hoặc kiểu kiến trúc riêng biệt Một kiểu kiến trúc là một mẫu (pattern) tổ chức hệ thống Kiến thức, khả ứng dụng, điểm mạnh và điểm yếu những mẫu này quan trọng Tuy nhiên, kiến trúc hầu hết những hệ thớng lớn khơng tương thích với một kiểu kiến trúc riêng lẻ nào Những thành phần khác hệ thớng được thiết kế kiểu kiến trúc khác Trong một số trường hợp, kiến trúc toàn bộ hệ thống được tạo kết hợp kiểu kiến trúc khác

b Phát triển sử dụng mơ hình kiến trúc

Sản phẩm tiến trình thiết kế kiến trúc là tài liệu thiết kế kiến trúc Tài liệu này bao gồm sơ đồ giới thiệu hệ thống kết hợp với những mô tả đoạn văn bản Tài liệu này nên mô tả hệ thống được cấu trúc thành hệ thống nào, hệ thống lại được phân chia thành module nào Mơ hình đồ họa hệ thớng đưa những nhìn khác kiến trúc Các kiểu mơ hình được phát triển tiến trình thiết kế kiến trúc bao gồm:

- Mơ hình cấu trúc tĩnh thành phần bản hệ thống Được phát triển thành đơn vị riêng biệt

- Mơ hình tiến trình động cấu trúc tiến trình hệ thớng Mơ hình này có thể khác với mơ hình tĩnh

- Mơ hình giao diện xác định dịch vụ được cung cấp hệ thống thông qua giao diện công khai

- Mơ hình quan hệ mơ hình luồng dữ liệu data-flow mối quan hệ giữa hệ thớng

- Mơ hình phân tán hệ thống được phân chia nào hệ thớng máy tính

(117)

ADLs được hiểu chun gia và khó sử dụng đới với những chuyên gia lĩnh vực ứng dụng (ví dụ chuyên gia lĩnh vực tài chính) Điều này gây khó khăn việc phân tích Vì thế, ta sử dụng ngôn ngữ thông dụng hơn, chẳng hạn UML dùng để mơ tả kiến trúc hệ thống

6.2.3 Tổ chức hệ thống

Tổ chức hệ thống phản ánh chiến lược bản được sử dụng để cấu trúc hệ thống Ta phải thực định mơ hình tổ chức tổng quát hệ thống giai đoạn đầu tiến trình thiết kế Việc tổ chức hệ thớng được phản ánh trực tiếp thơng qua cách cấu trúc hệ thống Tuy nhiên, mơ hình hệ thớng thường bao gồm những thơng tin chi tiết mơ hình tổ chức và khơng phải lúc nào có mới liên hệ đơn giản giữa hệ thống và tổ chức hệ thống Trong phần này, sẽ cùng thảo luận ba kiểu tổ chức phổ biến nhất:

- Mơ hình kho dữ liệu;

- Mơ hình máy khách/máy chủ; - Mơ hình máy ảo hoặc phân tầng

Trong mợt hệ thớng, ta sử dụng ba kiểu tổ chức này một cách riêng rẽ hoặc phới hợp chúng với

a Mơ hình kho liệu

Các hệ thống tạo thành mợt hệ thớng phải trao đổi thơng tin, chúng làm việc với mợt cách hiệu quả Có hai cách bản để thực điều này:

- Dữ liệu được chia sẻ nằm một kho hoặc một sở dữ liệu tập trung và được truy nhập tất cả hệ thớng Mợt mơ hình hệ thớng dựa một sở dữ liệu được chia sẻ được gọi là mơ hình kho dữ liệu (repository model)

- Mỗi hệ thớng có mợt sở dữ liệu riêng Dữ liệu được trao đổi với hệ thống khác việc gửi thông điệp tới chúng

Phần lớn hệ thống sử dụng một lượng lớn dữ liệu được tổ chức xung quanh một sở dữ liệu được chia sẻ hoặc kho dữ liệu Tuy nhiên, mơ hình này thích hợp với ứng dụng được sinh một hệ thống và được sử dụng một hệ thớng khác Ví dụ hệ thớng bao gồm câu lệnh và hệ thống điều khiển, hệ thống quản lý thông tin, hệ thống CAM/CAD và bợ cơng cụ CASE Hình 6.6 là mợt ví dụ hệ thớng sử dụng mơ hình kho dữ liệu tập trung

(118)

Hình 6.6 Kiến trúc bộ công cụ CASE tích hợp

 Ưu điểm

- Hiệu quả có nhu cầu chia sẻ dữ liệu lớn Không cần phải trao đổi dữ liệu từ hệ thống này tới hệ thống khác

- Các hoạt động lưu dữ liệu, đảm bảo an ninh, kiểm soát truy cập và tìm lỗi được xử lý tập trung Đó là trách nhiệm người quản lý kho dữ liệu Các cơng cụ tập trung vào những chức chứ khơng cần quan tâm đến những vấn đề này

- Mô hình chia sẻ được đưa mợt sơ đồ kho Điều này đơn giản hóa việc tích hợp thêm cơng cụ có cùng mơ hình dữ liệu

 Nhược điểm

- Các hệ thớng phải chấp thuận mơ hình kho dữ liệu; và mợt điều khơng thể tránh khỏi, là việc thỏa hiệp giữa nhu cầu đặc biệt cơng cụ Hiệu hệ thớng sẽ bị những tác động tiêu cực thỏa hiệp này Điều khó hoặc khơng thể tích hợp thêm hệ thớng mơ hình dữ liệu khơng thích hợp với lược đồ được xác nhận

- Việc phát triển sẽ khó khăn một khối lượng lớn thông tin được sinh theo mợt mơ hình dữ liệu được chấp thuận Việc biến đổi những thông tin này sang một mô hình dữ liệu chắc chắn là sẽ tớn kém, khó và đơi là khơng thực được - Các hệ thớng khác có những u cầu khác sách bảo

mật, kiểm soát lỗi và backup dữ liệu Mơ hình kho dữ liệu bắt ḅc hệ thớng phải thực cùng một chế quản lý

- Khó để phân chia mợt cách hiệu quả kho dữ liệu qua một hệ thống máy tính Mặc dù ta phân chia kho dữ liệu tập trung mợt cách logic, có nhiều vấn đề xung đột và dư thừa dữ liệu

b Mơ hình máy khách/chủ (client/server)

Mơ hình kiến trúc Client-Server là mợt mơ hình hệ thống được tổ chức một tập dịch vụ và kết nới giữa Servers với Clients để truy cập và sử dụng dịch vụ Các thành phần mơ hình này là:

- Một nhóm máy chủ (Servers) cung cấp dịch vụ cho hệ thớng Ví dụ máy chủ chuyên thực công việc in ấn Các tệp cần in phải được quản lý một dịch vụ quản lý tệp và một máy chủ biên soạn tài liệu được cung cấp dịch vụ biên soạn

(119)

Máy trạm biết tên máy chủ và dịch vụ máy chủ này cung cấp Tuy nhiên, máy chủ khơng cần biết danh tính có máy trạm tham gia vào hệ thống Các máy trạm truy cập vào dịch vụ được cung cấp máy chủ thông qua một thủ tục gọi từ xa sử dụng giao thức request-reply giống giao thức http sử dụng world wide web Hiển nhiên, một máy trạm đưa một yêu cầu cho máy chủ và đợi nhận được câu trả lời

Hình vẽ 6.7 là mợt ví dụ mợt hệ thớng được xây dựng dựa mơ hình Client-Server Hệ thớng này có nhiều người dùng Web để cung cấp mợt thư viện hình ảnh và phim Trong hệ thống này, một vài máy chủ quản lý và hiển thị kiểu dữ liệu đa phương tiện (phim, nhạc, video, hình ảnh…) Các video cần truyền nhanh và đồng bợ có đợ phân giải tương đới thấp Chúng được nén mợt kho CSDL, Server video thực việc nén và giải nén sang định dạng khác Tuy nhiên, đới với ảnh phải giữ ngun đợ phân giải cao, nên lưu Server riêng rẽ

Hình 6.7 Kiến trúc hệ thống tra cứu ảnh video số

Danh mục phải có khả đáp ứng mợt loạt truy vấn và cung cấp liên kết đến hệ thống thông tin web bao gồm dữ liệu film, video clip và hệ thống thương mại điện tử cho phép tải phim và video clip Các máy khách sử dụng dịch vụ mà máy chủ cung cấp thơng qua thủ tục gọi từ xa (hình 6.7)

Ưu điểm mơ hình này là phân tán dữ liệu khơng phức tạp; tăng hiệu quả sử dụng hệ thớng mạng; địi hỏi phần cứng rẻ đồng thời dễ bổ sung thêm máy chủ hoặc nâng cấp máy chủ tồn mà hệ thớng hoạt đợng bình thường

Tuy nhiên, bên cạnh tồn một số nhược điểm như: không được chia sẻ mơ hình dữ liệu, hệ thớng sử dụng cách tổ chức dữ liệu khác Do việc trao đổi dữ liệu hiệu quả; dư thừa việc quản lý máy chủ và khơng có bợ phận

Client Client Client Client

Mạng với băng thông rộng

Server Danh mục

Server video

Server Ảnh số

(120)

thực tầng máy ảo Bước dịch sẽ chuyển đổi mã máy ảo này thành mã máy thực

Mợt ví dụ kiến trúc phân tầng là mơ hình OSI giao thức mạng hay mơ hình tầng mơi trường hỗ trợ lập trình Ada (APSE - ada programming support environnement)

Hình vẽ 6.8 phản ánh cấu trúc APSE và làm nào mợt hệ thớng quản lý cấu hình được tích hợp sử dụng cách tiếp cận này

Hình 6.8 Mơ hình kiến trúc hệ thống quản lý cấu hình

Hệ thớng quản lý cấu hình quản lý phiên bản đới tượng và cung cấp sở dữ liệu quản lý cấu hình tổng hợp Để cung cấp sở quản lý cấu hình tổng hợp này, sử dụng mợt hệ thống quản lý đối tượng cung cấp những thông tin lưu trữ và quản lý dịch vụ cho bản ghi cấu hình hoặc đới tượng Hệ thớng này được xây dựng bên hệ thống sở dữ liệu để cung cấp kho dữ liệu bản và dịch vụ, chẳng hạn quản lý giao dịch, phục hồi sở dữ liệu trạng thái cũ (rolleback); phục hồi dữ liệu (recovery) và truy nhập điều khiển Việc quản lý sở dữ liệu sử dụng hệ điều hành sở và kho lưu trữ tài nguyên dự án

Cách tiếp cận phân tầng hỗ trợ phát triển tăng dần hệ thống Khi một tầng được phát triển, một số dịch vụ được cung cấp tầng này được người dùng sử dụng Kiến trúc này mang tính thay đổi và tính khả chuyển Vì giao diện khơng đổi, mợt tầng được thay thể tầng khác, tương đương Hơn nữa, giao diện tầng thay đổi hoặc có thêm những dịch vụ được bổ xung vào tầng này có tầng liền kề bị ảnh hưởng

Điểm bất lợi kiến trúc phân tầng là cấu trúc hệ thớng theo cách này khó Các tầng bên cung cấp chức bản, chẳng hạn quản lý tệp, tất cả tầng cần chức này Các dịch vụ mà người sử dụng cần thường tầng cùng, phải xuyên thủng tầng liền kề để truy nhập vào dịch vụ được cung cấp tầng sâu

Hiệu hệ thống là mợt vấn đề cần xem xét đơi lúc có lệnh được thực nhiều tầng Nếu có q nhiều tầng, mợt dịch vụ yêu cầu từ tầng cùng phải thời gian để qua tầng trung gian trước được xử lý Để tránh vấn đề này, ứng dụng phải trao đổi trực tiếp với tầng khác là sử dụng dịch vụ được cung cấp tầng liền kề

Tầng quản lý cấu hình hệ thớng Tầng quản lý đới tượng hệ thớng

(121)

6.2.4 Các mơ hình điều khiển

Các mơ hình cấu trúc hóa mợt hệ thống liên quan đến việc định xem một hệ thống được phân chia thành hệ thống nào Để làm việc một hệ thống, hệ thống phải điều khiển để dịch vụ truyền đến địa điểm và thời gian u cầu Các mơ hình cấu trúc khơng (và khơng nên) tích hợp thêm thơng tin điều khiển Hơn nữa, người kiến trúc sư nên tổ chức hệ thớng theo mợt vài mơ hình điều khiển bổ xung vào mơ hình cấu trúc được sử dụng Các mơ hình điều khiển tầm kiến trúc liên quan đến luồng dữ liệu giữa hệ thớng Có kiểu điều khiển chung được sử dụng hệ thống phần mềm:

Điều khiển tập trung: một hệ thống chịu trách nhiệm điều khiển, khởi động và kết thúc một hoạt động hệ thớng khác Nó ủy thác quyền điều khiển cho một hệ thống khác sẽ chờ để nắm lại quyền kiểm soát

Điều khiển dựa kiện: việc kiểm sốt thơng tin được nhúng mợt hệ thớng con, hệ thớng trả lời kiện được sinh từ bên ngoài Các kiện này đến từ hệ thớng khác hoặc từ môi trường chung hệ thống

Các kiểu điều khiển được sử dụng kết hợp với kiểu cấu trúc Tất cả kiểu cấu trúc mà thảo luận liên quan đến điều khiển tập trung hoặc điều khiển theo kiện a Điều khiểu tập trung

Trong mô hình điều khiển tập trung, mợt hệ thớng được thiết kế một hệ thống điều khiển chịu trách nhiệm quản lý việc thực thi hệ thống khác Các mơ hình điều khiển tập trung chia thành hai lớp, phụ thuộc vào hệ thống được điều khiển một cách hoặc song song

 Mơ hình gọi – trả lời

Mơ hình này tương tự mơ hình thủ tục top-down, điều khiển bắt đầu đỉnh một thứ bậc và thông qua việc gọi thủ tục để xuống mức thấp Mơ hình thủ tục này được ứng dụng hệ thống

(122)

Mơ hình tương tự này được nhúng ngơn ngữ lập trình, chẳng hạn ngơn ngữ C, Ada và Pascal Điều khiển chuyển từ thủ tục mức cao xuống thủ tục mức thấp Sau trả lại trỏ điểm mà thủ tục được gọi Thủ tục được thực thi có trách nhiệm điều khiển và gọi thủ tục khác hoặc trả lại điều khiển cho cha Nó là mợt kiểu lập trình đơn giản trả mợt vài điểm khác chương trình

Mơ hình gọi-trả lời được sử dụng mức module để quản lý chức hoặc đối tượng Các thủ tục mợt ngơn ngữ lập trình được gọi thủ tục khác là chức tự nhiên

Tính chất cứng nhắc và bị giới hạn mơ hình này vừa là điểm mạnh vừa là điểm yếu Nó là điểm mạnh tương đới đơn giản để phân tích luồng điều khiển và cơng việc, là mợt điểm yếu ngoài trừ thao tác thơng thường, khó để điều khiển

 Mơ hình quản lý

Mơ hình này được ứng dụng hệ thớng song song Một thành phần hệ thống được thiết kế một hệ thống quản lý, điều khiển việc bắt đầu, kết thúc và kết hợp tiến trình hệ thớng khác Mợt tiến trình là mợt hệ thớng hay mợt module thực thi song song với tiến trình khác Mợt dạng mơ hình này được ứng dụng hệ thớng mà việc quản lý cuộc gọi thông thường tới hệ thống phụ thuộc vào giá trị mợt sớ biến trạng thái

Hình 6.10 Mơ hình quản lý tập trung cho hệ thống thời gian thực

Hình 6.10 là mợt ví dụ cho mơ hình quản lý tập trung việc điều khiển hệ thớng song song Mơ hình này thường được sử dụng hệ thống thời gian thực “mềm”, khơng có những ràng ḅc q chặt chẽ mặt thời gian Điều khiển trung tâm quản lý việc thực thi mợt tập hợp tiến trình kết hợp với bộ cảm biến và bộ tác động

Tiến trình điều khiển hệ thớng định nào tiến trình được bắt đầu và kết thúc phụ tḥc vào biến trạng thái Nó kiểm tra xem tiến trình khác có sinh thơng tin được xử lý hoặc chuyển thông tin tới chúng để xử lý Điều khiển thông thường lặp liên tục, thu bộ cảm biến và tiến trình khác cho kiện hoặc những thay đổi trạng thái Với lý này, mơ hình này cịn được gọi là mơ hình lặp kiện (event-loop)

Xử lý cảm biến

Xử lý Thao tác

Hệ thống điều khiển

Giao diện người dùng

Quản lý lỗi Xử lý tính

(123)

b Mơ hình điều khiển dựa kiện

Trong mơ hình điều khiển tập trung, định điều khiển thường được xác định giá trị biến trạng thái Ngược lại, mơ hình điều khiển hướng kiện được điều khiển kiện sinh từ bên ngoài

Thuật ngữ “event” – kiện ngữ cảnh này khơng là mợt tín hiệu nhị phân Mà là mợt tín hiệu để lấy mợt tập giá trị hoặc một câu lệnh nhập từ menu Sự khác biệt giữa một kiện và một đầu vào đơn giản là thời gian kiện này nằm ngoài kiểm sốt tiến trình xử lý kiện

Có hai mơ hình điều khiển kiện:

 Mơ hình broadcast (quảng bá)

Trong mơ hình này, mợt kiện là mợt bản thơng báo tới tất cả hệ thống Các hệ thớng được lập trình để trả lời kiện mà nhận được Mơ hình broadcast có hiệu lực hệ thớng tích hợp, được phân bổ vào máy tính khác mợt mạng

Trong hình 6.11, sách điều khiển không được nhúng vào kiện và thông điệp điều khiển Các hệ thống định kiện nào mà chúng yêu cầu, điều khiển kiện và thông điệp phải đảm bảo kiện này được gửi tới địa

Hình 6.11 Mơ hình điều khiển dựa quảng bá có tuyển chọn

Các kiện truyền tới tất cả hệ thống con, điều này là đối với hệ thống lớn Thông thường, với hệ thớng này, hệ thớng có một ghi lưu giữ kiện và thông điệp mà chúng quan tâm Cịn đới với những hệ thớng đơn giản (ví dụ hệ thớng máy tính cá nhân) được điểu khiển kiện thông qua giao diện người dùng sẽ có những hệ thớng riêng để lấy kiện từ cḥt, bàn phím… và biến đổi thành những câu lệnh đặc biệt

Ưu điểm cách tiếp cận quảng bá (broadcast) là việc phát triển và mở rộng đơn giản Một hệ thống độc lập để điều khiển lớp riêng biệt kiện được tích hợp thông qua việc ghi nhớ kiện bợ điều khiển kiện Bất kỳ hệ thớng nào kích hoạt hệ thớng khác mà không cần biết tên vị trí hệ thớng Các hệ thớng được thực hệ thống máy phân tán Việc phân tán

Hệ thống

(124)

 Mô hình điều khiển ngắt (Interrupt-driven)

Các hệ thớng thời gian thực yêu cầu việc tiếp nhận và trả lời kiện mợt cách nhanh chóng Ví dụ: một hệ thống thời gian thực được ứng dụng để điều khiển hệ thống an toàn ôtô Nó phải phát mợt vụ va chạm xảy và đưa tín hiệu cảnh báo sớm trước người lái xe đâm phải chướng ngại vật Để cung cấp chế trả lời kiện mợt cách nhanh chóng, ta phải sử dụng mơ hình điều khiển ngắt

Mơ hình này thường được sử dụng hệ thống thời gian thực, là những hệ thớng cần có phản hồi kiện nhanh phải xử lý kiện lập tức Nó kết hợp với mơ hình điều khiển tập trung Mơ hình điều khiển ngắt được minh họa hình 6.12 Mỗi loại ngắt kết hợp với một bộ nhớ cục bộ để lưu trữ địa điều khiển Khi một ngắt một kiểu đặc biệt được nhận, một ngắt cứng (swich) gây điều khiển được truyền tới điều khiển Điều khiển ngắt này sau bắt đầu hoặc kết thúc mợt tiến trình khác để trả lời kiện mà ngắt này gửi tín hiệu đến

Hình 6.12 Mợt mơ hình điều khiển ngắt

Ưu điểm cách tiếp cận này là cho phép trả lời nhanh chóng để kiện được thực Nhưng điểm bất lợi là khó lập trình và khó kiểm thử Đơi khơng thể tái tạo ngắt thời gian kiểm thử hệ thớng Rất khó để thay đổi hệ thớng được phát triển dựa mơ hình này số lượng ngắt bị giới hạn phần cứng Một giới hạn này được đạt tới, kiểu kiện khác được điều khiển Đơi ta khắc phục nhược điểm này cách bớ trí mợt vài kiểu kiện vào mợt ngắt đơn Tuy nhiên, việc sắp xếp lại ngắt khơng thực tế u cầu trả lời thật nhanh ngắt

6.2.5 Tiến trình thiết kế kiến trúc

Trong trình thiết kế, một hệ thống lớn sẽ được phân rã thành hệ thống độc lập tương đối với Tiến trình xác định hệ thớng mợt hệ thống và thiết lập một khung làm việc cho việc điều khiển và giao tiếp giữa chúng gọi là thiết kế kiến trúc Kết quả hoạt động này là một tài liệu thiết kế kiến trúc, mô tả kiến trúc phần mềm

Thông tin ngắt

Bộ điều khiển

(125)

Thiết kế kiến trúc tập trung vào việc biểu diễn cấu trúc thành phần, thuộc tính mới tương tác giữa chúng Có nhiều cách tiếp cận khác giai đoạn thiết kế Tuy nhiên, ba hoạt đợng chủ chớt tiến trình thiết kế là:

1 Cấu trúc hệ thống: phân chia hệ thống thành hệ thống

2 Mơ hình hóa điều khiển: Thiết lập mợt mơ hình biểu diễn mối quan hệ điều khiển giữa thành phần hệ thống

3 Phân rã module: Mỗi hệ thống được phân rã thành module, bước này người làm thiết kế cần danh sách module và mối liên kết giữa chúng

Ở phần trình bày mợt sớ mơ hình kiến trúc tiêu biểu, mơ hình kiến trúc có ưu điểm và nhược điểm riêng, phù hợp với hệ thớng có đặc điểm khác Trên thực tế, hệ thớng lớn khơng phù hợp với mợt mơ hình kiến trúc đơn, mà thành phần sử dụng một kiểu kiến trúc khác

a Cấu trúc hệ thống

Giai đoạn tiến trình thiết kế kiến trúc thường liên quan tới việc phân rã một hệ thống thành một tập hệ thớng có tương tác với Ở mức đợ trìu tượng cao nhất, người ta sử dụng sơ đồ khối để minh họa việc thiết kế hệ thống con, khối sơ đồ là một hệ thống Khối khối hệ thớng lại bao gồm hệ thống nhỏ Các mũi tên dữ liệu và tín hiệu điều khiển được truyền từ hệ thống này sang hệ thống khác theo hướng mũi tên Sơ đồ khối là bức tranh tổng quan kiến trúc hệ thống, một người lĩnh vực khác nhìn vào sơ đồ này hiểu được

Hình 6.13 Sơ đồ kiến trúc hệ thống điều khiển robot bao gói

Hình vẽ 6.13 là mơ hình kiến trúc một hệ thống điều Robot Sơ đồ này những hệ thống cần được phát triển Hệ thớng robot này đóng gói loại đồ vật khác

Hệ thị giác Hệ nhận

dạng Bộ điều khiển tay nắm Bộ điều khiển gói, gắp

Hệ chọn bao gói

Hệ bao gói Bợ điều khiển

(126)

b Phân chia module

Sau tổ chức hệ thống thành hệ thống con, giai đoạn thiết kế kiến trúc phân rã hệ thớng thành module Có chiến lược bản sử dụng phân chia một hệ thống thành modules:

- Phân chia hướng đối tượng (Object-oriented decomposition): phân tích hệ thống thành một tập hợp đối tượng trao đổi thông tin, liên kết với

- Đường ống hướng chức (Function-oriented pipelining): phân tích hệ thống thành module chức theo chế module nhận dữ liệu đầu vào để xử lý và đưa kết quả

 Mơ hình hướng đối tượng

Trong mơ hình hướng đới tượng, mơ hình kiến trúc phân tích hệ thớng thành một tập đối tượng kết hợp với đôi một thông qua giao diện được định nghĩa rõ ràng Các đối tượng gọi dịch vụ được cung cấp đối tượng khác

Sự phân chia hướng đối tượng liên quan đến việc xác định lớp đới tượng, tḥc tính và phương thức Khi được thực hiện, đới tượng được tạo từ lớp này và mợt vài mơ hình điều khiển được sử dụng để phối hợp phương thức đới tượng

Hình vẽ 6.14 là mợt ví dụ mơ hình kiến trúc hướng đới tượng hệ thống xử lý đơn hàng Hệ thống này tự đợng chuyển đơn hàng đến khách hàng, nhận tiền trả và sinh hóa đơn tốn, đồng thời ghi nhớ đơn hàng chưa được toán Ở tác giả sử dụng lược đồ UML để biểu diễn quan hệ giữa lớp Mỗi lớp có tên, tḥc tính và các phương thức Lớp Đơn hàng có phương thức khác để thực chức hệ thống Lớp này sẽ tạo phương thức để xử lý lớp Hóa đơn, Khách hàng Thanh tốn

Hình 6.14 Mơ hình hướng đối tượng hệ thống xử lý hóa đơn

Ưu điểm cách tiếp cận này là đối tượng được kết nối với một cách lỏng lẻo, mợt đới tượng thay đổi sẽ không ảnh hưởng nhiều đến đối tượng khác Các đối tượng thông thường là thực thể hệ thớng, thế, người ta hiểu chúng mợt cách nhanh chóng Bởi thực thể này được sử dụng những hệ thớng khác nhau, nên có khả tái sử dụng Các ngơn ngữ lập trình hướng đối tượng ngày phong phú để hỗ trợ cách tiếp cận này

Khách hàng Mã_khách# Tên_khách Địa_chỉ Kỳ_tín_dụng Thanh tốn Mã_đơn# Ngày Tổng_Tiền Mã_khách# Đơn hàng Mã_đơn# Ngày Tổng_Tiền Mã_khách# Xuất () Gửi_giấy_nhắc() Hạn_thanh_tốn() Gửi hóa đơn()

(127)

Tuy nhiên, cách tiếp cận hướng đới tượng có những điểm bất lợi Để sử dụng dịch vụ, đối tượng phải tham chiếu một cách rõ ràng đến tên và giao diện đối tượng khác Nếu một giao diện thay đổi, địi hỏi cả hệ thớng phải thay đổi theo, thay đổi này ảnh hưởng đến cả người sử dụng Khi đới tượng liên kết với để thể thực thể giới thực, thực thể phức tạp đơi khó trìu tượng hóa thành đới tượng

 Mơ hình l̀ng dữ liệu (đường ống hướng chức năng)

Trong mơ hình đường ớng hướng chức hay luồng dữ liệu, bộ biến đổi chức xử lý dữ liệu đầu vào và thủ tục đầu Các luồng dữ liệu chuyển từ nơi này sang nơi khác và được biến đổi liên tục Mỗi bước tiến trình được thực mợt bước biến đổi Luồng dữ liệu vào qua bộ biến đổi này sẽ được chuyển thành dữ liệu đầu Sự biến đổi này được thực hoặc song song Dữ liệu được xử lý bước hoặc thành đợt

Mợt ví dụ kiểu hệ thống ứng dụng kiến trúc này được hình 6.15 Mợt tổ chức phát hành hóa đơn cho khách hàng Mợt tuần mợt lần, việc toán phải được thực hợp lý với hóa đơn Với những hóa đơn được tốn, phải đưa giấy biên nhận, với những hóa đơn chưa được toán thời gian trả cho phép, phải có mợt lệnh nhắc nhở

Hình 6.15 Mơ hình đường ống chức hệ thống xử lý hóa đơn

Đây là mợt phần hệ thớng xử lý hóa đơn: biến đổi luân phiên được sử dụng để sinh hóa đơn Mơ hình đới tượng trìu tượng khơng có những thơng tin hoạt đợng Mơ hình luồng dữ liệu có ưu điểm sau:

- Có thể sử dụng lại bộ biến đổi (transformation)

- Trực quan nhiều người nghĩ công việc họ là xử lý dữ liệu đầu vào để thu được kết quả đầu

- Cải tiến hệ thống việc bổ xung thêm những bộ biến đổi sẽ không phức tạp - Đơn giản đối với những hệ thống song song

Vấn đề bản mơ hình này là định dạng chung cho dữ liệu cần biến đổi, cho tất Đơn hàng

Xác định toán

Thanh tốn

Lập hóa đơn

Tìm đơn hàng q hạn

Gửi giấy nhắc Đọc vào

đơn hàng

(128)

6.3 THIẾT KẾ HƯỚNG ĐỐI TƯỢNG

6.3.1 Một số đặc điểm thiết kế hướng đối tượng

a Chiến lược thiết kế hướng đối tượng

Trong chiến lược thiết kế hướng đới tượng, bước phân tích, thiết kế, lập trình hướng đới tượng có quan hệ có những điểm khác biệt:

- Phân tích hướng đới tượng (AOO) liên quan đến việc phát triển mợt mơ hình hướng đới tượng một lĩnh vực ứng dụng Các đối tượng mô hình phản ánh thực thể và phương thức kết hợp với vấn đề được giải

- Thiết kế hướng đối tượng (DOO) liên quan đến việc phát triển mợt mơ hình hướng đới tượng cho một hệ thống phần mềm để thực những yêu cầu đặt Các đối tượng thiết kế hướng đối tượng liên quan tới phương án giải vấn đề Đây là mới quan hệ mật thiết giữa vấn đề và phương án giải quyết, người làm thiết kế tránh được việc phải bổ xung thêm đối tượng và biến đổi đới tượng có để thực giải pháp - Lập trình hướng đới tượng (OOP) liên quan đến việc thực thi một bản thiết kế phần mềm mợt ngơn ngữ lập trình hướng đới tượng, chẳng hạn Java, Pithon, C++ Một ngôn ngữ lập trình hướng đới tượng cung cấp cấu trúc để định nghĩa lớp đối tượng và hệ thống chạy theo thời gian (run-time) để tạo đối tượng từ lớp này

Một cách lý tưởng, chuyển tiếp giữa giai đoạn phát triển là liên tục với khái niệm thích hợp được sử dụng giai đoạn Việc chuyển sang giai đoạn liên quan đến việc làm mịn giai đoạn trước việc thêm chi tiết vào lớp đối tượng tồn và tạo lớp đối tượng để cung cấp chức bổ sung Vì thơng tin ẩn đới tượng, nên định thiết kế chi tiết việc biểu diễn dữ liệu được trì hỗn hệ thống được thực Trong một số trường hợp, định việc phân chia đối tượng, đới tượng hay song song được trì hỗn

b Đặc điểm thiết kế hướng đối tượng

Các đới tượng được trìu tượng hóa từ thực thể hệ thớng hoặc giới thực Các đối tượng là độc lập có ẩn chứa trạng thái và những thơng tin mơ tả cịn chức hệ thớng được diễn tả qua thuật ngữ “dịch vụ đối tượng” Trong phương pháp này, vùng chia sẻ dữ liệu được loại trừ Các đối tượng trao đổi thông tin qua thông điệp (message) Các đới tượng tổ chức phân tán và thực thi hoặc song song

 Ưu điểm của phương pháp hướng đối tượng

Các hệ thống hướng đối tượng dễ thay đổi (bảo trì) hệ thớng được phát triển cách sử dụng cách tiếp cận khác đới tượng là đợc lập Chúng được hiểu và thay đổi thực thể độc lập (standalone – không cần phải cài đặt) Thay đổi việc thực thi đối tượng hoặc thêm dịch vụ sẽ không làm ảnh hưởng tới đối tượng khác hệ thớng Từ nâng được tính dễ hiểu và tăng tính bảo trì cho hệ thớng

(129)

này giúp giảm chi phí cho thiết kế, lập trình và kiểm chứng Nó dẫn đến việc sử dụng đối tượng tiêu chuẩn (từ tăng tính dễ hiểu bản thiết kế) và giảm được những rủi ro liên quan đến việc phát triển phần mềm

Đối với một số hệ thớng, có mới liên hệ rõ ràng giữa thực thể giới thực với đối tượng hệ thống

6.3.2 Đối tượng lớp đối tượng

a Khái niệm đối tượng lớp đối tượng

Thuật ngữ đối tượng và hướng đối tượng được ứng dụng vấn đề khác như: phương pháp thiết kế, hệ thống và ngơn ngữ lập trình Người ta cho rằng, mợt đới tượng là mợt gói thơng tin, điều này được phản ánh định nghĩa đối tượng và lớp đối tượng theo định nghĩa sau:

Một đối tượng là mợt thực thể có mợt trạng thái và một tập thao tác được thực

trong một trạng thái Một trạng thái được mô tả là mợt tập tḥc tính đới tượng Các thao tác kết hợp với đối tượng cung cấp dịch vụ cho đối tượng khác, những đối tượng sẽ có yêu cầu dịch vụ cần phải tính tốn

Các đới tượng được tạo từ một vài định nghĩa lớp đối tượng Một lớp đối tượng xác định dịch vụ, một khuôn mẫu cho đối tượng, bao gồm việc khai báo tất cả tḥc tính và dịch vụ mà mợt đới tượng tḥc lớp cần phải có Hình 6.16 là mợt ví dụ mợt lớp đới tượng được biểu diễn ngơn ngữ UML

Hình 6-16 Mơ hình lớp đối tượng “Tài khoản” với tḥc tính phương thức

b Trao đổi thông tin lớp đối tượng

Các đối tượng trao đổi thông tin qua việc yêu cầu dịch vụ từ đối tượng khác, cần Tài khoản

Số_tài_khoản: String Tên_Khách: String Số_dư: Money

+Tạo_lập (Tên: String, số_tiền: Money) +Gửi (sổ_TK: String, số_tiền: Money)

(130)

Dưới là một số ví dụ thơng điệp và việc truyền thơng điệp giữa lớp đối tượng: // Gọi phương thức với đối tượng đệm sau trả lại giá trị trong đệm

V = circularBuffer.Get

//Gọi phương thức kết hợp với đối tượng máy điều nhiệt để thiết lập nhiệt độ bảo trì Thermostat.setTemp(20);

c Khái quát hóa kế thừa lớp đối tượng

Các lớp đới tượng được sắp xếp một kế thừa để mối quan hệ giữa lớp đối tượng chung và lớp đối tượng đặc trưng Những đối tượng lớp sẽ giữ nguyên phương thức và tḥc tính lớp cha, ngoài cịn bổ sung thêm phương thức và tḥc tính riêng Trong UML, mũi tên từ lớp đến lớp cha thể lớp mà được kế thừa Trong ngơn ngữ lập trình hướng đới tượng, tổng qt hóa được thực cách sử dụng mơ hình kế thừa Các lớp được kế thừa phương thức và tḥc tính lớp cha

Hình 6.17 mợt ví dụ một đối tượng kế thừa lớp nhân viên khác Các lớp thấp kế thừa có tḥc tính và phương thức lớp cha có thêm mợt sớ tḥc tính và phương thức hoặc thay đổi một số thông tin lớp cha

Hình 6-17 Mơ hình kế thừa lớp nhân viên một công ty phần mềm

Lớp Manager hình có tất cả tḥc tính và phương thức lớp Employee, thêm vào đó, có hai tḥc tính để lưu ngân sách được sử dụng người quản lý và ngày mà người quản lý được định để giữ vai trò này Tương tự vậy, lớp lập trình viên được bổ xung thêm tḥc tính để thể dự án mà người tham gia, những kỹ nghề nghiệp người Các đới tượng lớp Manager và Programmer được sử dụng đâu một đối tượng lớp nhân viên được yêu cầu

Employee

Manager budgetsControlled dateAppointed

Programmer Project

progLanguages

Project Manager projects

Dept Manager dept

(131)

Ưu điểm: Mơ hình kế thừa hướng đối tượng giống một máy ảo và được

sử dụng để phân lớp thực thể Đây là một kỹ thuật tái sử dụng cả mức thiết kế và mức lập trình Sơ đồ kế thừa là sở kiến thức tổ chức hệ thống và lĩnh vực ứng dụng

Tuy nhiên, kế thừa có nhược điểm như: lớp đối tượng không độc lập, không thể hiểu được thiếu tham chiếu đến lớp cha Những người làm thiết kế có khuynh hướng sử dụng lại sơ đồ kế thừa được tạo q trình phân tích Có thể dẫn tới việc thực không hiệu quả

6.3.3 Tiến trình thiết kế hướng đối tượng

Để minh họa tiến trình thiết kế hướng đới tượng, cùng phân tích q trình thiết kế mợt phần mềm điều khiển nhúng hệ thống trạm dự báo thời tiết tự động Hoạt động thiết kế hướng đối tượng bản bao gồm bước sau:

 Hiểu xác định ngữ cảnh mô hình việc sử dụng hệ thống;

 Thiết kế kiến trúc hệ thống;

 Xác định đối tượng hệ thống;

 Xây dựng mơ hình thiết kế;

 Đặc tả giao diện đối tượng

Các hoạt động này được mô tả riêng biệt Tuy nhiên thực tế, tất cả những hoạt động nói được đan xen vào nên ảnh hưởng tới những hoạt động khác Các đối tượng được xác định và giao diện được đặc tả một phần hoặc đầy đủ kiến trúc hệ thống được xác định Khi mơ hình đới tượng được sinh ra, định nghĩa đối tượng đặc biệt này được làm mịn dần, điều này làm thay đổi kiến trúc hệ thống

a Giới thiệu hoạt động trạm thời tiết

Phần này sử dụng hệ thống tạo bản đồ thời tiết để minh họa những hoạt động tiến trình thiết kế hướng đới tượng, tập trung chủ yếu vào hệ thống thu thập tự động dữ liệu phục vụ công tác dự báo thời tiết Mơ hình kiến trúc tổng quan hệ thớng được mơ tả tóm tắt sau:

(132)

lưu trữ và tạo bản đồ thời tiết Tuy nhiên, phần này vào phân tích mợt phần hệ thớng xây dựng bản đồ thời tiết, là trạm khí tượng

Mợt trạm khí tượng là mợt gói phần mềm điều khiển thiết bị để thu thập dữ liệu, thực việc xử lý dữ liệu và truyền những dữ liệu này để tiếp tục xử lý Các thiết bị bao gồm dụng cụ đo nhiệt đợ khơng khí và mặt đất, đo tớc đợ gió, bánh lái hướng gió, thiết bị đo áp suất khơng khí, đo lượng mưa Việc thu thập dữ liệu được thực định kỳ Khi một lệnh được đưa để truyền dữ liệu thời tiết, trạm thời tiết xử lý và tóm lược dữ liệu thu thập được Những dữ liệu được tóm lược sẽ được truyền đến máy tính lập bản đồ nhận được yêu cầu b Mơ hình ngữ cảnh mơ hình sử dụng

Giai đoạn tiến trình thiết kế nào là việc tăng cường hiểu biết mối quan hệ giữa phần mềm được thiết kế với môi trường bên ngoài Người làm thiết kế cần phải hiểu điều này để đưa định như: làm nào đáp ứng được những yêu cầu chức hệ thống, làm nào để cấu trúc hệ thống, giúp giao tiếp với mơi trường thực thi Ngữ cảnh hệ thớng và mơ hình sử dụng hệ thớng được biểu diễn hai mơ hình bổ xung qua mối quan hệ giữa hệ thống và mơi trường

- Mơ hình ngữ cảnh: là mợt mơ hình tĩnh mơ tả hệ thớng khác mơi trường, sử dụng mơ hình hệ thống để hệ thống khác

- Mơ hình sử dụng: là mợt mơ hình mơ tả hệ thống tương tác với môi trường nào Để thể điều này, người ta sử dụng biểu đồ Use-case để tương tác

Mơ hình sử dụng (use-case) cho trạm thời tiết được hình 6.18 Hình vẽ này nói lên trạm thời tiết tương tác với thực thể bên ngoài để thực dịch vụ sau:

Hình 6.18 Mơ hình Use-case trạm khí tượng

Mỗi use-case được mô tả ngôn ngữ tự nhiên, điều này giúp cho những người làm thiết kế xác định đối tượng và chức hệ thống Bảng 6.1 là một mẫu chuẩn cho việc mô tả một use-case Trong có những thơng tin chi tiết liên quan tới tên chức

Bảng 6.1 Mô tả một use-case System (hệ thống)

Use-case (chức năng)

Trạm khí tượng

Báo cáo dữ liệu thời tiết thu thập được

Star tup

Shutdown

Repor t

Calibrate

Test - Khởi động hệ thống (Startup)

- Tắt hệ thống (Shutdown) - Báo cáo dữ liệu thời tiết

thu thập được (report)

- Hiệu chỉnh thông số thiết bị trạm (Celibrate)

- Kiểm tra trạng thái thiết bị (test)

(133)

Actor (tác nhân) Data (dữ liệu)

Stimulus

Response

Hệ thống bản đồ thời tiết, trạm khí tượng

Trạm khí tượng gửi mợt bản tóm lược dữ liệu thời tiết mà thu thập được từ thiết bị trạm tới hệ thống bản đồ thời tiết Dữ liệu được thu thập bao gồm: giá trị lớn nhất, giá trị nhỏ và giá trị trung bình nhiệt đợ khơng khí và nhiệt đợ mặt đất; tớc đợ gió, áp suất khơng khí, tổng lượng mưa và hướng gió… phút một lần

Hệ thống thu thập dữ liệu thời tiết có mợt đường tín hiệu kết nới với trạm khí tượng và chuyển yêu việc truyền dữ liệu

Dữ liệu tóm lược được sẽ được gửi tới hệ thống thu thập dữ liệu thời tiết

Comments (chú ý) Các trạm khí tượng thường xuyên được yêu cầu chuyển dữ liệu trung tâm (mỗi một lần) Tuy nhiên tần suất này thay đổi tùy theo vị trí trạm khí tượng

Mơ tả use case giúp ta xác định đối tượng và chức hệ thớng Từ mơ tả use-case Report, người ta hình dung những thiết bị cần để thu thập dữ liệu khí tượng, đới tượng biểu diễn thơng tin, thao tác yêu cầu dữ liệu và gửi dữ liệu được yêu cầu

c Thiết kế kiến trúc

Mối tương tác giữa hệ thống phần mềm được thiết kế và môi trường hệ thống được lấy làm sở cho việc thiết kế kiến trúc Tuy nhiên cần phải kết hợp với những kiến thức bản thiết kế kiến trúc những hiểu biết lĩnh vực dự án Trong trường hợp này, kiến trúc phân tầng là thích hợp cho trạm khí tượng Kiến trúc hệ thớng này được mơ tả hình 6.19

Hình 6.19 Kiến trúc hệ thống trạm khí tượng

Trạm khí tượng

«subsystem» Giao diện «subsystem» Thu thập dữ liệu

«subsystem» Các thiết bị

Quản lý tất cả giao tiếp với môi trường bên ngoài

Thu thập và tóm lược dữ liệu thời tiết

(134)

Nói chung, ta nên phân tích hệ thớng mợt kiến trúc đơn giản Thực tế cho thấy khơng nên có nhiều bảy thực thể bản mợt mơ hình kiến trúc Mỗi thực thể này có thể mơ tả riêng biệt và sử dụng để khám phá cấu trúc bên

d Xác định đối tượng hệ thống

Trong giai đoạn này tiến trình, nên có mợt vài ý tưởng đới tượng hệ thớng được thiết kế Trong hệ thớng trạm khí tượng, thiết bị sẽ là đối tượng, ta cần một đối tượng mức kiến trúc Điều này phản ánh những nét bản mà đới tượng hướng tới q trình thiết kế Tuy nhiên, thường xuyên phải tìm kiếm và tài liệu hố đới tượng có liên quan

Mặc dù phần này có tiêu đề là xác định đới tượng, thực tế, tiến trình này liên quan đến việc xác định lớp đối tượng Việc thiết kế được mô tả thuật ngữ lớp này Hiển nhiên, ta cần phải làm mịn lớp đối tượng xác định từ giai đoạn khởi đầu và xem xét lại giai đoạn này để hiểu sâu việc thiết kế

 Các cách tiếp cận để xác định đối tượng

Có bốn cách tiếp cận để xác định đối tượng hệ thớng:

1 Sử dụng phân tích ngữ pháp ngôn ngữ tự nhiên mô tả hệ thống Các đới tượng và những tḥc tính phải là danh từ, phương thức hoặc dịch vụ phải là động từ Cách tiếp cận này được đưa vào phương pháp HOOD - cho thiết kế hướng đối tượng (Robinson, 1992) được sử dụng rộng rãi lĩnh vực công nghiệp Châu Âu

2 Sử dụng vật thể hữu hình lĩnh vực ứng dụng, chẳng hạn máy bay, vai trò người quản lý, kiện yêu cầu, tương tác gặp gỡ, vị trí văn phịng, tổ chức cơng ty Hỗ trợ cách xác định cấu trúc lưu trữ giải pháp lĩnh vực được yêu cầu để hỗ trợ đối tượng này

3 Sử dụng cách tiếp cận hành vi, người thiết kế hiểu qua cách xử lý hệ thống Những cách thực khác được phân công cho những phần khác hệ thống và hiểu biết được bắt nguồn từ việc khởi động và tham gia vào những công việc này Những người tham gia đóng vai trị có ý nghĩa được xem đối tượng

4 Sử dụng phân tích dựa kịch Khi mợt kịch bản được phân tích, đợi chịu trách nhiệm phân tích phải xác định những đới tượng được u cầu, tḥc tính và phương thức Mợt phương thức việc phân tích được gọi là thẻ CRC, nơi những người làm phân tích dựa vào vai trị đới tượng được hỗ trợ có hiệu quả phương pháp tiếp cận dựa kịch bản này

(135)

Bằng cách tiếp cận lai, nhận thấy hệ thớng trạm khí tượng có năm lớp đới tượng được thể hình vẽ 6.20

Hình 6.20 Các lớp đối tượng hệ thống trạm khí tượng

1 Lớp đối tượng WeatherStation cung cấp giao diện bản trạm dự báo thời tiết với môi trường Tuy nhiên, phương thức phản ánh những tương tác này được hình 6.20 Trong trường hợp này, sử dụng một lớp đối tượng đơn để che dấu tất cả những tương tác, bản thiết kế khác, bạn lựa chọn để thiết kế giao diện hệ thống là lớp khác

2 Lớp đối tượng WeatherData che dấu dữ liệu thu được từ thiết bị trạm dự báo thời tiết Các phương thức đối tượng này liên quan đến việc thu thập và tóm lược dữ liệu được yêu cầu

3 Các lớp đối tượng Ground thermometer, Anemometer Barometer liên quan trực tiếp tới thiết bị hệ thống Chúng phản ánh những thực thể phần cứng hữu hình hệ thống và phương thức liên quan đến việc điều khiển phần cứng

 Làm mịn đối tượng

Trong giai đoạn tiến trình thiết kế, cần phải sử dụng những kiến thức lĩnh vực ứng dụng để xác định đối tượng và dịch vụ Chúng ta biết rằng, trạm khí tượng thường để những nơi xa và có mợt sớ thiết bị mà thỉnh thoảng chúng bị hỏng Các thiết bị bị lỗi cần phải có thơng báo lỗi tự đợng Điều này địi hỏi phải có những tḥc tính và những phương thức để kiểm tra xem thiết bị có hoạt động theo chức mong muốn hay không Như bạn thấy, có nhiều trạm khí tượng từ xa nên phải xác định dữ liệu được thu thập từ trạm, cần phải đánh sớ cho trạm

WeatherStation

identifier reportWeather() celibrate (instruments) test()

startup(instruments) shutdown(instruments)

WeatherData

airTempratures groundTempratures winSpeeds

windDirections pressures rainfall collect() summarise()

Ground thermometer

temperature test() celibrate ()

Anemometer

windSpeed windDirection test()

Barometer

(136)

các lớp đối tượng phải được đưa Bằng việc tạo đối tượng thiết bị đọc yêu cầu, thay đổi nào chiến lược thu thập dữ liệu thực mợt cách dễ dàng mà khơng cần thay đổi đối tượng kết nối với thiết bị

e Xây dựng mơ hình thiết kế

Các mơ hình thiết kế đối tượng hoặc lớp đối tượng hệ thống và mối quan hệ giữa thực thể này Các mơ hình thiết kế có nhiều khả sẽ trở thành bản thiết kế Nó là cầu nới giữa yêu cầu hệ thống và việc thực hệ thớng Điều này có nghĩa là sẽ có những u cầu xung đợt mơ hình này Những xung đợt này được giải cách phát triển mơ hình những mức đợ chi tiết khác Tuy nhiên, một bước quan trọng tiến trình thiết kế là việc định mơ hình nào sẽ được sử dụng và mức độ chi tiết mơ hình Điều này phụ tḥc vào kiểu hệ thống sẽ được phát triển Một hệ thống xử lý sẽ được thiết kế theo một cách khác so với hệ thống nhúng thời gian thực, sẽ sử dụng mơ hình thiết kế khác Có hệ thớng cần đến tất cả mơ hình thiết kế Tới thiểu hóa mơ hình thiết kế sẽ làm giảm chi phí và thời gian cần thiết cho tiến trình thiết kế

Có kiểu mơ hình thiết kế thường được sử dụng thiết kế hướng đối tượng:

- Các mơ hình tĩnh: mơ tả cấu trúc tĩnh hệ thống sử dụng lớp đối tượng và mối quan hệ giữa chúng Các mối quan hệ quan trọng được tài liệu hóa giai đoạn này là mối quan hệ kế thừa và khái qt hóa, sử dụng/được sử dụng mới quan hệ và mối quan hệ hợp thành

- Các mơ hình động: mơ tả cấu trúc đợng hệ thống và mối tương tác giữa đối tượng hệ thống (không phải là lớp đới tượng) Các mới tương tác được tài liệu hóa bao gồm thứ tự dịch vụ yêu cầu được thực đối tượng và cách thức mà trạng thái hệ thống liên quan tới tương tác đối tượng này

UML cung cấp 12 mơ hình đợng và tĩnh khác để giúp cho q trình thiết kế Phần này khơng giới thiệu tất cả mơ hình, mà giới thiệu những mơ hình thích hợp cho ví dụ trạm dự báo thời tiết, là mơ hình sau:

 Mơ hình hệ thống

(137)

Hình 6.21 Mơ hình hệ thống trạm khí tượng

Hình vẽ đới tượng hệ thớng trạm khí tượng Mơ hình mới liên kết giữa đới tượng mơ hình Ví dụ, đới tượng CommsController được kết hợp với đối tượng WeatherStation và đới tượng WeatherStation được kết hợp vào gói Data collection Điều này có nghĩa là đới tượng này được kết hợp với mợt hoặc nhiều đới tượng khác gói Mợt mơ hình gói kết hợp với mợt mơ hình lớp đới tượng mơ tả nhóm logic hệ thớng

 Mơ hình t̀n tự

Các mơ hình thứ tự tương tác đới tượng Các mơ hình này được thể cách sử dụng một lược đồ hoặc song song Các mơ hình là mơ hình đợng, thể mợt tương tác hệ thống và thứ tự tương tác này Trong mợt mơ hình tuần tự:

- Các đối tượng liên quan tương tác này được bố trí theo chiều ngang với mợt đường thẳng đứng được liên kết với đối tượng

- Thời gian được biểu diễn theo chiều thẳng đứng, trình tự tính từ xuống

- Các mũi tên được gán nhãn kết nối giữa trục thẳng đứng biểu diễn tương tác giữa đối tượng Đây không phải là luồng dữ liệu mà biểu diễn thông điệp hoặc những kiện quan trọng tương tác

- Các hình chữ nhật rỗng biểu diễn thời gian mà mợt đới tượng kiểm sốt mợt đối tượng khác hệ thống Một đối tượng lấy quyền điều khiển đỉnh hình chữ nhật và trả lại quyền điều khiển cho đối tượng khác điểm đáy hình chữ nhật Nếu có kế thừa lời

« subsy stem » Inter face

« subsy stem » Data collection

Com m sController

WeatherStation

WeatherData

Instrum ent Status

« subsy stem » Instrum ents

Air therm om eter

Ground therm om eter

RainGauge

Barom eter

Anem om eter

(138)

Hình 6.22 Mơ hình phương thức report() hệ thống trạm khí tượng

Hình 6.22 thứ tự tương tác hệ thống bản đồ bên ngoài yêu cầu dữ liệu từ trạm thời tiết Ta đọc sơ đồ này từ xuống dưới:

1 Một đối tượng là một kiện lớp CommsController (:CommsController) nhận một tín hiệu từ mơi trường (bên ngoài) u cầu thu thập dữ liệu thời tiết Nó báo cho đới tượng gửi yêu cầu là nhận được tín hiệu yêu cầu này Đầu mũi tên thông điệp phản hồi bên gửi thông điệp không mong chờ thông tin phản hồi

2 Đối tượng này gửi một thông điệp tới một đối tượng là một kiện WeatherStation để tạo một bản tin thời tiết Sự kiện CommsController sau rơi vào trạng thái treo Kiểu mũi tên này được sử dụng để một kiện đối tượng CommsController và một kiện đối tượng WeatherStation là đới tượng thực thi đồng thời Đới tượng là một kiện WeatherStation gửi một thông điệp tới đới tượng

WeatherData để tóm lược dữ liệu thời tiết Trong trường hợp này, mũi tên đặc kiện WeatherStation đợi câu trả lời

4 Bản tóm tắt này được tính tốn và điều khiển trả lại cho đới tượng WeatherStation Đường mũi tên nét đứt việc trả điều khiển

5 Đối tượng này gửi một thông điệp cho yêu cầu CommsController để truyền dữ liệu tới một hệ thớng từ xa Đới tượng WeatherStation sau rơi vào trạng thái treo

6 Đối tượng CommsController gửi dữ liệu được tóm lược tới hệ thớng từ xa, nhận mợt thơng tin phản hồi, sau rơi vào trạng thái treo, đợi yêu cầu

(139)

 Mơ hình trạng thái máy

Các mơ hình trạng thái máy cách thức mợt đới tượng thay đổi trạng thái phải trả lời kiện Các mơ hình này được biểu diễn biểu đồ trạng thái Các mơ hình trạng thái là mơ hình đợng được sử dụng cho mơ hình kết hợp hoạt đợng mợt nhóm đới tượng, sử dụng để tóm lược hoạt đợng mợt đới tượng đơn trả lời mợt thơng điệp mà phải xử lý Để làm được điều này, ta sử dụng mơ hình trạng thái máy để đối tượng thay đổi trạng thái nào phụ tḥc vào thơng điệp mà nhận được UML sử dụng lược đồ trạng thái để mơ tả mơ hình trạng thái

Hình 6.23 là một lược đồ trạng thái cho đối tượng WeatherStation làm nào trả lời yêu cầu dịch vụ khác

Hình 6.23 Lược đồ trạng thái đối tượng WeatherStation

Sơ đồ này đọc sau:

1 Nếu trạng thái đới tượng là Shutdown sau trả lời thơng điệp startup(), sẽ được chuyển sang trạng thái chờ thông điệp được gửi đến Đường mũi tên khơng gán nhãn và có hình trịn đầu trạng thái Shutdown là trạng thái khởi đầu

2 Trong trạng thái chờ, hệ thống chờ đợi thơng điệp Nếu nhận được thơng điệp shutdown(), đới tượng trở trạng thái Shutdown

(140)

5 Nếu có mợt tín hiệu từ đồng hồ, hệ thớng sẽ chuyển sang trạng thái Collecting, tiến hành thu thập dữ liệu từ thiết bị Mỗi thiết bị được thị để trả lại kết quả thu thập được

f Đặc tả giao diện đối tượng

Một phần quan trọng tiến trình thiết kế nào là việc đặc tả giao diện giữa thành phần bản thiết kế Giao diện đối tượng và hệ thống cần phải đặc tả trước chúng được thiết kế song song Khi một giao diện được đặc tả, người xây dựng đới tượng khác cho giao diện này sẽ được giữ nguyên giai đoạn lập trình

Trong q trình đặc tả giao diện, cớ gắng tránh thêm chi tiết việc biểu diễn giao diện bản thiết kế giao diện Việc biểu diễn nên để ẩn và phương thức đối tượng được cung cấp để truy nhập và cập nhật dữ liệu Nếu việc biểu diễn được ẩn đi, được thay đổi mà khơng ảnh hưởng tới những đới tượng có sử dụng tḥc tính này Điều này khiến cho bản thiết kế dễ bảo trì Ví dụ, biểu diễn mảng mợt ngăn xếp được thay đổi thành biểu diễn danh sách mà khơng ảnh hưởng tới đới tượng khác có sử dụng ngăn xếp này Ngược lại, một mô hình thiết kế tĩnh, thường thể tḥc tính đới tượng là cách nhỏ gọn để minh họa tính chất bản đới tượng

Khơng thiết phải có mới quan hệ đơn giản 1-1 giữa đối tượng và giao diện Cùng mợt đới tượng có vài giao diện khác nhau, giao diện lại phương thức mà cung cấp Điều này được hỗ trợ trực tiếp Java, giao diện được khái báo riêng rẽ với đối tượng và đối tượng “thực hiện” giao diện Mợt nhóm đới tượng được truy nhập thơng qua mợt giao diện

Việc thiết kế giao diện liên quan đến đặc tả chi tiết giao diện cho một đối tượng hoặc mợt nhóm đới tượng Điều này có nghĩa là xác định ký hiệu và ngữ nghĩa dịch vụ được cung cấp đối tượng hoặc mợt nhóm đới tượng

Các giao diện được đặc tả ngơn ngữ UML cách sử dụng khái niệm giống lược đồ lớp Tuy nhiên, khơng có phần tḥc tính và ký hiệu <interface> nên được thêm vào phần tên lớp

Hình 6.24 Giao diện đối tượng WeatherStation interface WeatherStation {

public void WeatherStation () ;

public void startup () ;

public void startup (Instrument i) ;

public void shutdown () ;

public void shutdown (Instrument i) ;

public void reportWeather ( ) ;

public void test () ;

public void test ( Instrument i ) ;

public void calibrate ( Instrument i) ;

public int getID () ;

(141)

Có thể sử dụng cách tiếp cận xen kẽ, là việc sử dụng mợt ngơn ngữ lập trình để biểu diễn Điều này được minh họa hình 6.24, giao diện đối tượng trạm thời tiết được biểu diễn ngôn ngữ lập trình Java Khi giao diện phức tạp hơn, cách biểu diễn này sẽ hiệu quả hơn, việc kiểm tra cú pháp sẽ dễ dàng biên dịch, dùng để khám phá những lỗi và mâu thuẫn việc mô tả giao diện Việc mô tả Java mợt sớ phương thức lấy số tham số khác Tuy nhiên, phương thức shutdown() được áp dụng cho trạm khơng có tham sớ hoặc có mợt thiết bị

6.3.4 Cải tiến tái sử dụng thiết kế

Sau có định xây dựng mợt hệ thống, chẳng hạn hệ thống thu thập dữ liệu thời tiết, điều khơng tránh khỏi là có những yêu cầu thay đổi hệ thống được đề xuất Một ưu điểm quan trọng cách tiếp cận hướng đối tượng thiết kế là thay đổi thiết kế đơn giản Lý là việc biểu diễn trạng thái đối tượng không ảnh hưởng tới thiết kế Việc thay đổi những chi tiết bên một đối tượng không ảnh hưởng tới đối tượng khác hệ thống Hơn nữa, đối tượng được liên kết với một cách lỏng lẻo, nên thường không phức tạp thêm một đối tượng mà khơng ảnh hưởng tới phần cịn lại hệ thớng

Để làm nào để việc thiết kế hướng đới tượng thay đổi mợt cách dễ dàng, giả sử tính kiểm sốt mức đợ nhiễm được tích hợp thêm vào trạm thời tiết Điều này liên quan đến việc thêm mợt máy đo chất lượng khơng khí để tính tốn đợ nhiễm khơng khí u cầu thu thập dữ liệu mức độ ô nhiễm được truyền cùng thời điểm với dữ liệu thời tiết

Để thay đổi bản thiết kế, phải thay đổi mợt sớ vấn đề sau:

1 Một lớp đối tượng được gọi là “Airquality” được xem là một phần WeatherStation cùng mức với WeatherData

2 Phương thức “reportAirQuality” nên được thêm vào WeatherStation để gửi thơng tin đợ nhiễm tới máy tính trung tâm Phần mềm điều khiển trạm thời tiết phải được thay đổi việc đọc đợ nhiễm được thu thập một cách tự động được yêu cầu đối tượng mức đỉnh “WeatherStation”

(142)

Hình 6.25 Các đối tượng hệ thống sau bổ xung thiết bị đo độ ô nhiễm

Các đới tượng kiểm sốt đợ nhiễm được đóng gói mợt gói riêng được gọi là thiết bị kiểm sốt độ nhiễm (Pollution monitoring instruments) Đới tượng này có mới liên hệ với AirQuality và WeatherStation khơng có liên hệ với đối tượng nào được sử dụng để thu thập dữ liệu thời tiết Hình 6.25 phương thức được thêm vào đối tượng WeatherStation và đối tượng được bổ sung vào hệ thống, thay đổi phần mềm được yêu cầu đới tượng ban đầu trạm khí tượng Việc thêm dữ liệu ô nhiễm không ảnh hưởng tới việc thu thập dữ liệu thời tiết

NOData sm ok eData benz eneData collect () sum m arise ()

Air quality identifier

repor tWeather () repor tAirQuality () calibrate (instrum ents) test ()

star tup (instrum ents) shutdown (instrum ents)

WeatherStation

Pollution m onitoring instrum ents

NOm eter Sm okeMeter

(143)

1 Hãy nêu khái niệm và vai trò thiết kế phát triển phần mềm Phân tích khái niệm thiết kế?

3 Trình bày bước và sản phẩm giai đoạn thiết kế Người ta sử dụng cơng cụ để biểu diễn sản phẩm giai đoạn thiết kế

4 Hãy nêu những điểm quan trọng để đánh giá chất lượng thiết kế Có những phương pháp nào để kiểm sốt chất lượng thiết kế?

5 Hãy phân tích hướng dẫn thiết kế

6 Trình bày vai trò thiết kế kiến trúc Thiết kế kiến trúc ảnh hưởng nào tới yêu cầu phi chức hệ thống?

7 Thiết kế kiến trúc được chia làm giai đoạn? Hãy nêu những nét khái quát giai đoạn

8 Có kiểu mơ hình kiến trúc bản? Hãy nêu những nét chính, ưu điểm và nhược điểm mơ hình Mợt hệ thớng áp dụng nhiều mơ hình kiến trúc hay được lựa chọn mợt mơ hình kiến trúc nhất?

9 Mơ hình hóa điều khiển xác định cách thức hệ thớng trao đổi thông tin và thực dịch vụ hệ thớng Có loại mơ hình điều khiển bản? Những yếu tố ảnh hưởng tới việc lựa chọn mơ hình điều khiển hệ thớng?

10 Có chiến lược phân rã module? Việc lựa chọn chiến lược phân rã module dựa những đặc điểm hệ thớng hay thói quen nhóm phát triển?

11 Chiến lược phát triển hướng đối tượng trải qua bước, bước có quan hệ với nào?

12 Hãy phân biệt hai khái niệm Đối tượng và Lớp đối tượng phát triển phần mềm hướng đối tượng

13 Nêu những ưu điểm và nhược điểm lập trình hướng đới tượng 14 Trình bày bước phân tích và thiết kế hướng đới tượng

(144)

Chương 7: KIỂM THỬ PHẦN MỀM

Kiểm thử và đảm bảo chất lượng phần mềm là mợt q trình liên tục, xun śt giai đoạn phát triển nhằm đảm bảo phần mềm được tạo thỏa mãn yêu cầu thiết kế và yêu cầu đáp ứng được nhu cầu người sử dụng Kiểm thử phần mềm là một hoạt động tốn thời gian tiền bạc và khó phát được hết lỗi Vì vậy, kiểm thử phần mềm địi hỏi phải có chiến lược phù hợp, kế hoạch hợp lý và việc thực phải được quản lý một cách chặt chẽ, nghiêm túc, hiệu quả

Chương này giới thiệu một số khái niệm, mục tiêu và giai đoạn bản tiến trình kiểm thử Phần quan trọng chương trình bày phương pháp xây dựng kịch bản và trường hợp kiểm thử Qua sinh viên nắm được những vấn đề bản và áp dụng để kiểm thử phần mềm phát triển Phần ći cùng chương giới thiệu những đặc điểm bản và mợt sớ module cơng cụ kiểm thử tự động

7.1 GIỚI THIỆU CHUNG

Mợt tiến trình kiểm thử thường bắt đầu việc kiểm thử đơn vị chương trình riêng rẽ, chẳng hạn chức hoặc đối tượng Sau chúng được tích hợp vào hệ thớng và tương tác giữa đơn vị được kiểm thử Cuối cùng, sau bàn giao hệ thống, khách hàng thực mợt loạt kiểm thử chấp nhận để đảm bảo hệ thống thực thi theo đặc tả

Mơ hình này tiến trình kiểm thử thích hợp cho việc phát triển hệ thống lớn, đối với hệ thống nhỏ, hoặc với hệ thớng phát triển theo mơ hình mẫu hoặc tái sử dụng thường khó phân biệt mợt cách rõ ràng giai đoạn tiến trình phát triển phần mềm

Mợt cách nhìn trìu tượng việc kiểm thử được hình 7.1 Hai hoạt động kiểm thử bản là kiểm thử thành phần – kiểm thử một phần hệ thống, và kiểm thử hệ thống – kiểm thử hoạt đợng toàn bợ hệ thớng

Hình 7.1 Các giai đoạn kiểm thử

Mục tiêu kiểm thử thành phần là khám phá lỗi cách kiểm thử thành phần chương trình riêng rẽ Những thành phần này là chức năng, đối tượng hoặc thành phần tái sử dụng

Trong q trình kiểm thử hệ thớng, thành phần được tích hợp với tạo thành hệ thống hoặc một hệ thống hoàn chỉnh Trong giai đoạn này, kiểm thử hệ thống cần tập trung vào việc đánh giá xem hệ thớng có đáp ứng được yêu cầu chức năng, phi chức và những hoạt động không theo mong muốn Một điều tránh khỏi, là lỗi thành phần bị bỏ qua giai đoạn kiểm thử trước và được phát kiểm thử hệ thống

Kiểm thử thành phần

Kiểm thử hệ thống

(145)

7.1.1 Mục tiêu kiểm thử

Kiểm thử phần mềm đáp ứng mục tiêu bản:

- Để chứng minh với nhà phát triển và khách hàng là phần mềm đáp ứng yêu cầu đặt Với khách hàng, điều này có nghĩa là nên có một thử nghiệm cho yêu cầu người sử dụng tài liệu yêu cầu Với những sản phẩm phần mềm dùng chung, cần phải kiểm thử tất cả chức hệ thống sẽ được tích hợp vào sản phẩm ći cùng Mợt sớ hệ thớng cần giai đoạn kiểm thử tích hợp độc lập để khách hàng kiểm tra xem hệ thống được bàn giao có đặc tả khơng

- Để khám phá lỗi phần mềm hoặc những điểm yếu cách hoạt động phần mềm không đúng, không thỏa mãn hoặc không phù hợp với đặc tả Phát lỗi liên quan tới việc khám phá nguyên nhân tất hoạt động không hệ thống, chẳng hạn hệ thống bị phá hủy, những tương tác không mong muốn với hệ thớng khác, việc tính tốn sai và dữ liệu

Mục tiêu được thực kiểm thử thẩm định, người kiểm thử mong hệ thống thực một cách đắn việc đưa một tập hợp trường hợp kiểm thử (test cases) phản ánh những mong muốn người sử dụng đối với hệ thống

Mục tiêu thứ hai là phát khiếm khuyết tồn tại, trường hợp kiểm thử được thiết kế để bộc lộ khiếm khuyết phần mềm:

- Các trường hợp kiểm thử bị che khuất mợt cách có chủ ý và khơng phản ánh xem hệ thống được sử dụng một cách thông thường nào

- Đối với việc kiểm thử thẩm định, một trường hợp kiểm thử thành cơng là hệ thớng thực thi Cịn đới với kiểm thử khiếm khuyết, một kiểm thử thành công là một khiếm khuyết được bộc lộ hệ thống thực thi khơng

Nhìn chung, kiểm thử khơng thể chứng phần mềm hoàn toàn khơng cịn lỗi hoặc thích nghi được mọi mơi trường làm việc Luôn tồn trường hợp kiểm thử mà bạn khám phá lỗi khác hệ thống Tuy nhiên, mục tiêu kiểm thử phần mềm là tạo niềm tin cho khách hàng, phần mềm đủ tớt và sử dụng được Kiểm thử là q trình làm tăng đợ tin cậy phần mềm

7.1.2 Tiến trình kiểm thử phần mềm

(146)

Hình 7.2 Tiến trình kiểm thử phần mềm

Việc kiểm thử toàn diện, hay nói cách khác, câu lệnh chương trình tiến hành được kiểm thử là điều Tuy nhiên, kiểm thử dựa một tập trường hợp kiểm thử là Mợt cách lý tưởng, cơng ty phần mềm nên có những chiến lược để lựa chọn tập dữ liệu kiểm thử là nhóm phát triển Những chiến lược này dựa chiến lược kiểm thử chung (ví dụ, mợt chiến lược kiểm thử mà tất cả câu lệnh chương trình cần phải được thực thi mợt lần) Các chiến lược dựa kinh nghiệm sử dụng hệ thớng và tập trung vào những tính hệ thớng, chẳng hạn như:

- Tất cả chức hệ thống được truy cập thông qua menu phải được kiểm thử - Việc kết hợp chức (ví dụ chức định dạng văn bản) được truy cập qua cùng một menu phải được kiểm thử

- Với dữ liệu được người dùng cung cấp, tất cả chức phải được kiểm thử đối với cả trường hợp dữ liệu và dữ liệu sai

Khi tính phần mềm được sử dụng tách biệt, thường chúng hoạt đợng tớt Vấn đề sẽ nảy sinh tính tích hợp khơng được kiểm thử cùng

Mợt phần tiến trình lập kế hoạch kiểm thử, người quản lý phải định là người chịu trách nhiệm giai đoạn khác tiến trình kiểm thử Đới với hầu hết hệ thớng, người lập trình chịu trách nhiệm kiểm thử thành phần đoạn mã nguồn mà họ tạo Ngay hoàn thành, cơng việc được chuyển qua nhóm tích hợp, nhóm này chịu trách nhiệm tích hợp tính được phát triển từ nhóm khác nhau, hình thành nên phần mềm và kiểm thử toàn hệ thống Đối với hệ thớng quan trọng, nhiều tiến trình hình thức được sử dụng những kỹ sư kiểm thử chịu trách nhiệm đới với tất cả giai đoạn tiến trình kiểm thử Khi kiểm thử hệ thống quan trọng, kịch bản kiểm thử được phát triển riêng rẽ và việc ghi lại chi tiết được trì kết quả kiểm thử

Kiểm thử thành phần người phát triển thường dựa việc hiểu cặn kẽ chức thành phần Tuy nhiên, kiểm thử hệ thống lại phải dựa một bản đặc tả hệ thớng Nó là mợt bản đặc tả yêu cầu chi tiết hệ thống

Trong thực tiễn, tiến hành kiểm thử người ta thường bắt đầu kiểm thử thành phần, sau chuyển sang giai đoạn kiểm thử hệ thống Tuy nhiên, phần này hai nội dung lại được giới thiệu đảo ngược ngày càng nhiều hệ thống được xây dựng cách tích hợp thành phần tái sử dụng và cấu hình lại hệ thớng tồn để đáp ứng được yêu cầu người dùng

Thiết kế trường hợp kiểm

thử

Chuẩn bị dữ liệu

kiểm thử với dữ liệu kiểm thử Chạy chương trình với test-case So sánh kết quả Trường hợp

kiểm thử

Dữ liệu kiểm thử

Kết quả kiểm thử

(147)

7.2 KIỂM THỬ HỆ THỐNG

Kiểm thử hệ thớng liên quan tới việc tích hợp hai hoặc nhiều thành phần để thực thi chức hệ thớng, sau kiểm thử toàn bợ hệ thớng được tích hợp

Trong tiến trình phát triển lặp, kiểm thử hệ thống liên quan tới việc kiểm thử một thành phần (increment) được bàn giao cho khách hàng; mơ hình thác nước, kiểm thử hệ thớng liên quan tới kiểm thử hệ thống hoàn chỉnh

Với hầu hết hệ thống phức tạp, kiểm thử hệ thống được chia thành giai đoạn:

1 Kiểm thử tích hợp: Hệ thớng được kiểm thử thành phần được tích hợp vào hệ thớng Nhóm kiểm thử truy cập vào mã nguồn chương trình Khi mợt vấn đề được phát hiện, nhóm sẽ cớ gắng để tìm nguồn gớc vấn đề và xác định những thành phần gây lỗi Kiểm thử tích hợp hầu hết liên quan đến việc tìm những khiếm khuyết hệ thống

2 Kiểm thử phát hành: là giai đoạn một phiên bản hệ thống hoàn thành và được bàn giao cho khách hàng dùng thử Giai đoạn này liên quan tới việc thẩm định xem hệ thống có đáp ứng yêu cầu và chắc chắn hệ thống là đáng tin cậy Kiểu kiểm thử này thường gọi là kiểm thử hộp đen, nghĩa là nhóm làm kiểm thử cho nhóm phát triển thấy phần mềm này làm việc hợp lý hay không hợp lý Khi khách hàng có liên quan tới giai đoạn kiểm thử này người ta gọi là kiểm thử chấp nhận Nếu phiên bản đủ tốt, người sử dụng chấp nhận sử dụng

Về bản, cho việc kiểm thử tích hợp là kiểm thử mợt nhóm thành phần hệ thống một cách không đầy đủ Kiểm thử phát hành liên quan tới việc kiểm thử một hệ thống được bàn giao cho khách hàng Hiển nhiên, hai kiểu kiểm thử này có những điểm trùng lặp, đặc biệt là phát triển hệ thống theo kiểu gia tăng và hệ thống được chuyển giao là chưa hoàn thiện Nói chung, kiểm thử tích hợp ưu tiên việc khám phá những khiếm khuyết hệ thớng, cịn kiểm thử hệ thống liên quan tới việc đáp ứng những u cầu Tuy nhiên, thực tế, có mợt sớ kiểm thử thẩm định và kiểm thử khiếm khuyết được tiến hành cả hai tiến trình này 7.2.1 Kiểm thử tích hợp

(148)

Ngược lại, ta lựa chọn phương pháp tích hợp thành phần sở hệ thống cung cấp chức chung, chẳng hạn mạng hoặc truy nhập CSDL, sau thêm thành phần chức Đây được gọi là phương pháp tích hợp lên

Trong thực tế, với nhiều hệ thống, chiến lược tích hợp thường kết hợp cả hai phương pháp này, cả những thành phần sở hạ tầng và thành phần chức được thêm vào một cách gia tăng Với cả hai phương pháp này, thường phải phát triển thêm mã nguồn để mô thành phần khác và cho phép hệ thống thực thi

Vấn đề nảy sinh q trình tích hợp là việc xác định vị trí lỗi Việc tương tác phức tạp giữa thành phần hệ thống và một đầu bất thường được khám phá, khó để xác định nơi xảy lỗi Để dễ dàng hơn, người ta thường sử dụng cách tiếp cận gia tăng để tích hợp và thử nghiệm Đầu tiên, tích hợp mợt cấu hình hệ thớng tới thiểu và kiểm thử hệ thớng này, sau lần lượt thêm thành phần và kiểm thử sau bước tích hợp

Ví dụ hình 7.3, A, B, C, D là thành phần và T1-T5 là tập hợp kịch bản kiểm thử chức được kết hợp hệ thống T1, T2, T3 được thực thi một hệ thống bao gồm thành phần A, B phát khiếm khuyết, chúng sẽ được sửa Thành phần C được tích hợp thêm vào và T1-T3 được lặp lại để khơng có bất thường với A và B Nếu có vấn đề nảy sinh trường hợp kiểm thử này, có nghĩa là lỗi sinh tích hợp thành phần Nguồn gớc vấn đề sẽ được xác định, việc phát và sửa lỗi đơn giản Trường hợp kiểm thử T4 được thực thi với hệ thống Và cuối cùng, thành phần D được tích hợp vào hệ thớng và sử dụng kiểm thử có, cợng với mợt trường hợp kiểm thử (T5)

Hình 7.3 Một trường hợp tích hợp tăng dần

Khi lập kế hoạch tích hợp, ta phải định thứ tự việc tích hợp thành phần Chẳng hạn phương pháp phát triển cực đại XP, khách hàng liên quan tới tiến trình phát triển và là người định thành phần nào sẽ được ưu tiên tích hợp trước Trong cách tiếp cập tích hợp thành phần thương mại, khách hàng khơng liên quan và nhóm tích hợp sẽ định thứ tự ưu tiên

Trong trường hợp đó, thơng thường người ta sẽ chọn những thành phần có chức được sử dụng thường xuyên Ví dụ: hệ thống thư viện LIBSYS, bạn nên bắt đầu

T3 T2 T1 T4 T5 A B C D T2 T1 T3 T4 A B C T1 T2 T3 A B

Test sequence Test sequence Test sequence Lượt kiểm

thử

Lượt kiểm

(149)

việc tích hợp chức tìm kiếm Và sau thêm chức cho phép người sử dụng download tài liệu, cuối cùng là thêm thành phần để thực chức khác

Tất nhiên, thực tế, việc tích hợp khơng đơn giản mơ hình gợi ý Thực thi tính hệ thớng được tiến hành nhiều thành phần khác Để kiểm tra mợt tính mới, bạn phải tích hợp vài thành phần khác Việc kiểm thử phát những lỗi tích hợp thành phần đợc lập này Việc sửa lỗi sẽ khó phải thay đổi mợt nhóm thành phần liên quan tới việc thực thi chức này Hơn nữa, việc tích hợp và kiểm thử mợt thành phần thay đổi framework những thành phần tích hợp được kiểm thử Những lỗi khơng bợc lợ những kiểm thử đới với cấu hình hệ thớng đơn giản

Điều này có nghĩa là mợt thành phần được tích hợp, điều quan trọng là phải chạy lại kịch bản kiểm thử được thực thi trước mợt kịch bản mới, là điều bắt buộc để xác nhận một chức hệ thống Việc chạy lại kịch bản trước được gọi là kiểm thử ngược Nếu kiểm thử ngược phát vấn đề, ta phải kiểm tra xem vấn đề phát sinh từ đâu thành phần trước mà việc tích hợp thêm thành phần làm xuất lỗi

Việc kiểm thử ngược là một công việc tốn và thường là thực thi được khơng có cơng cụ kiểm thử tự đợng hỗ trợ Trong phương pháp lập trình cực đại (XP), tất cả kịch bản kiểm thử được viết trước thực thi mã nguồn Khi dữ liệu kiểm thử và kết quả mong đợi được đặc tả và sử dụng phương pháp kiểm thử tự động Khi sử dụng một framework kiểm thử tự động, chẳng hạn JUnit, kịch bản kiểm thử chạy lại một cách tự động Phương pháp này là mợt đặc trưng phương pháp lập trình cực đại, một tập hợp kịch bản kiểm thử hoàn thiện được tiến hành có mã nguồn được tích hợp và mã nguồn này khơng được chấp nhận tất cả kịch bản kiểm thử thực thi thành công

7.2.2 Kiểm thử phát hành

Kiểm thử phát hành là một tiến trình kiểm thử việc phát hành hệ thớng sẽ được chuyển giao cho khách hàng Mục tiêu tiến trình kiểm thử này là làm tăng đợ tin cậy nhà cung cấp, chứng tỏ hệ thống đáp ứng được những yêu cầu khách hàng đặt Nếu đúng, nhóm phát triển phát hành sản phẩm hoặc chuyển giao cho khách hàng Để hệ thống đáp ứng những yêu cầu đặt ra, ta phải thực theo chức đặc tả, hiệu quả, tin cậy và khơng có lỗi sử dụng bình thường

(150)

Trong trình kiểm thử hệ thống phát hành, người kiểm thử nên cố gắng “phá hủy” hệ thống cách lựa chọn kịch bản kiểm thử nằm tập Ie hình 7.4 Điều có nghĩa là mục tiêu kiểm thử là lựa chọn dữ liệu đầu vào cho có nhiều khả hệ thống sinh lỗi (đầu nằm tập Oe)

Hình 7.4 Mơ hình kiểm thử hợp đen

Nhìn chung, q trình kiểm thử hộp đen thường tuân theo hướng dẫn sau: Lựa chọn dữ liệu đầu vào để hệ thống sinh tất cả thông báo lỗi

2 Thiết kế dữ liệu đầu vào cho là nguyên nhân gây lỗi tràn bộ đệm đầu vào Lặp lại với cùng dữ liệu đầu vào hoặc một loạt dữ liệu đầu vào nhiều thời điểm

khác

4 Lựa chọn dữ liệu đầu vào để sinh kết quả sai Kiểm thử đới với dữ liệu tính tốn từ lớn đến nhỏ 7.2.3 Xây dựng kịch kiểm thử hệ thống

Để xác minh hệ thống đáp ứng được những yêu cầu, cách kiểm thử tốt là kiểm thử dựa kịch bản, đưa một số kịch bản và phát triển trường hợp kiểm thử từ những kịch bản này, ví dụ một kịch bản kiểm thử hệ thống phần mềm quản lý thư viện:

Hình 7.5 Mợt kịch mô tả một chức hệ thống thư viện LIBSYS

Từ kịch bản này, sinh mợt sớ trường hợp kiểm thử được ứng dụng cho mục đích kiểm thử phát hành LIBSYS:

Dữ liệu kiểm thử đầu vào

Hệ thống

Kết quả kiểm thử

Dữ liệu vào dẫn đến những tình h́ng bất thường

Kết quả đầu phát lỗi

tồn

(151)

1 Kiểm thử việc đăng nhập với cả trường hợp: đăng nhập và đăng nhập sai để chứng minh rằng, người đăng nhập sẽ được chấp nhận, người đăng nhập sai sẽ bị từ chối

2 Kiểm thử chức tìm kiếm sử dụng mợt truy vấn vào nguồn tài nguyên để kiểm tra xem chức tìm kiếm này có tìm được tài liệu cần dùng hay không

3 Kiểm thử chức hiển thị để kiểm tra thông tin tài liệu được hiển thị xác Kiểm thử chức tải tài liệu sử dụng một truy vấn cho phép người dùng tải tài liệu Kiểm thử email trả lời để tài liệu tải xuống sẵn sàng sử dụng

Với trường hợp kiểm thử, ta nên thiết kế một tập dữ liệu kiểm thử, bao gồm cả trường hợp dữ liệu và sai Ta nên tổ chức việc kiểm thử dựa kịch bản, những trường hợp thích hợp sẽ được kiểm thử trước, sau những trường hợp bất thường hoặc ngoại lệ sẽ được xem xét sau, những thành phần được sử dụng thường xuyên sẽ được kiểm thử nhiều lần

Trong trường hợp đặc tả phần mềm có sử dụng mơ hình trường hợp sử dụng (use-case) những use-case này được kết hợp với lược đồ là sở cho việc kiểm thử Hai loại sơ đồ này được sử dụng cả kiểm thử tích hợp và kiểm thử phát hành

7.2.4 Kiểm thử hiệu

Khi một hệ thớng được tích hợp hoàn chỉnh, kiểm tra hệ thớng với tḥc tính bật hiệu và độ tin cậy Kiểm thử hiệu được thiết kế để đảm bảo hệ thớng xử lý việc tải dữ liệu có dụng ý Loại kiểm thử này thường liên quan tới việc lập kế hoạch cho một loạt trường hợp kiểm thử mà việc tải dữ liệu sẽ tăng dần hệ thống không chấp nhận

Như kiểu kiểm thử khác, kiểm thử hiệu liên quan tới việc chứng minh hệ thống đáp ứng được yêu cầu và khám phá vấn đề và khiếm khuyết hệ thống Để kiểm thử yêu cầu hiệu hệ thống hoàn thành, ta cần phải xây dựng một tập hợp kịch bản kiểm thử phản ánh công việc hỗn hợp sẽ được thực hệ thống Tuy nhiên, 90% giao dịch hệ thống là kiểu A, 5% là kiểu B và phần lại là kiểu C, D, E, ta phải thiết kế tập trường hợp kiểm thử mà phần lớn trường hợp tḥc kiểu A Mặt khác, sẽ khơng có mợt trường hợp kiểm thử xác tính hiệu hệ thớng Tuy nhiên, ta kiểm thử trường hợp thực hệ thống vượt ngoài giới hạn thiết kế hệ thống

(152)

Kiểm thử áp lực thường liên quan tới hệ thống phân tán môi trường mạng Những hệ thống này thường xảy tượng giảm hiệu suất bị tải Mạng trở nên tác dụng phối hợp dữ liệu từ bộ xử lý khác Vì tiến trình ngày càng chậm phải chờ dữ liệu từ bộ xử lý khác

7.3 KIỂM THỬ THÀNH PHẦN

Kiểm thử thành phần (đơi cịn gọi kiểm thử đơn vị) tiến trình kiểm thử các thành phần độc lập hệ thống Như thảo luận phần giới thiệu, đối với hầu hết hệ thống, người phát triển thành phần chịu trách nhiệm kiểm thử thành phần tạo Các kiểu kiểm thử khác được kiểm tra giai đoạn này là:

1 Kiểm thử chức phương thức độc lập lớp đối tượng 2 Kiểm thử lớp đối tượng có mợt sớ tḥc tính và phương thức

3 Kiểm thử thành phần hợp thành từ đối tượng hoặc chức khác Những thành phần hợp thành này có giao diện xác định được sử dụng để truy cập vào chức chúng

7.3.1 Kiểm thử lớp đối tượng

Các chức hoặc phương thức độc lập là kiểu đơn giản thành phần và được kiểm thử một tập những lời gọi phương thức này từ tham sớ đầu vào khác Ta sử dụng cách tiếp cận này để thiết kế trường hợp kiểm thử Khi kiểm thử lớp đối tượng, nên thiết kế kịch bản kiểm thử bao trùm được tất cả tính đối tượng Tuy nhiên, lớp đối tượng kiểm thử thường bao gồm:

1 Kiểm thử cách ly tất cả chức đối tượng Thiết lập và truy vấn tất cả tḥc tính đới tượng

3 Kiểm tra đối tượng với tất cả trạng thái Điều này có nghĩa là tất cả kiện dẫn đến thay đổi trạng thái đối tượng phải mô

Ví dụ, hình 7.6 là giao diện hệ thớng trạm khí tượng được nêu chương trước Đới tượng này có mợt tḥc tính xác định sớ hiệu trạm, là một số được đặt trạm được thiết lập Tuy nhiên, tḥc tính này cần kiểm tra được thiết lập Nhưng ta cần xây dựng trường hợp kiểm thử phương thức đối tượng như: reportWeather, calibrate… Một cách lý tưởng, phương thức phải kiểm tra một cách độc lập, một số trường hợp, kiểm thử là cần thiết Ví dụ, kiểm tra phương thức shutdown, cần phải thực thi phương thức Start

Hình 7.6 Giao diện đối tượng WeatherStation

Để kiểm tra trạng thái trạm thời tiết, ta sử dụng mơ hình trạng thái hình 7.7 Qua mơ hình này ta xác định thứ tự biến đổi trạng thái, phải kiểm tra và xác

WeatherStation

identifier reportWeather() celibrate (instruments) test()

(153)

định thứ tự kiện gây biến đổi trạng thái Về bản, ta cần phải kiểm thử tất cả trạng thái biến đổi có thể, mặc dù thực tế tớn

Hình 7.7 Mơ hình trạng thái đối tượng Weather Station hệ thống trạm thời tiết

Ví dụ thứ tự trạng thái biến đổi nên được kiểm thử trạm thời tiết bao gồm: Shutdown -> waiting -> Shutdown

Waiting ->calibrationg -> Testing -> transmiting – Waiting

Waiting -> Collecting -> Waiting -> Summarising -> Transmitting -> Waiting

Nếu hệ thớng có lớp kế thừa sẽ khó thiết kế trường hợp kiểm thử cho lớp đối tượng Khi một lớp cha cung cấp phương thức được kế thừa cho lớp khác nhau, tất cả lớp phải được kiểm thử phương thức kế thừa này Lý phải kiểm thử lại là những tḥc tính hoặc phương thức kế thừa này thay đổi lớp

7.3.2 Kiểm thử giao diện

Nhiều thành phần hệ thống không phải là những chức hoặc đới tượng đơn giản mà được tích hợp từ mợt sớ đới tượng khác Khi ta cần truy nhập vào những chức thành phần sau kiểm tra xem giao diện thành phần này có tương hợp với đặc tả hay khơng

(154)

Hình 7.8 Tiến trình kiểm thử giao diện

Kiểm thử giao diện đặc biệt quan trọng phát triển phần mềm theo phương pháp hướng đối tượng hoặc hướng thành phần Các đối tượng và thành phần được xác định giao diện và được tái sử dụng việc kết hợp với thành phần khác hệ thống khác Những lỗi giao diện thành phần hợp thành phát kiểm thử đối tượng hoặc thành phần độc lập Những lỗi thành phần hợp thành phát sinh tương tác giữa thành phần

Có kiểu giao diện khác giữa thành phần chương trình, kết quả là có những lỗi giao diện khác xảy ra:

1 Giao diện dạng tham số: giao diện là dữ liệu hoặc là chức được chuyển từ thành phần này sang thành phần khác

2 Giao diện nhớ chia sẻ: là những giao diện mà khối bộ nhớ được chia sẻ giữa thành phần Dữ liệu được đặt bộ nhớ một hệ thống và được đưa từ những hệ thống khác

3 Giao diện thủ tục: là những giao diện mà một thành phần ẩn mợt tập hợp thủ tục được gọi từ những thành phần khác Các đới tượng và thành phần tái sử dụng có dạng giao diện này

4 Giao diện chuyển thông điệp: những giao diện này thực việc chuyển thông điệp từ thành phần này sang thành phần khác Một thông điệp trả sẽ bao gồm kết quả việc thực thi dịch vụ Mợt sớ hệ thớng hướng đới tượng có giao diện dạng này, chẳng hạn hệ thống client-server

Lỗi giao diện thường rơi vào loại sau:

1 Sử dụng sai giao diện: một thành phần gọi thành phần khác qua giao diện và gặp lỗi sử dụng giao diện Kiểu lỗi này thường gặp truyền tham số sai kiểu, sai thứ tự 2 Hiểu sai giao diện: một thành phần gọi một thành phần khác thông qua giao diện

lại hiểu sai hoạt động thành phần đó, gọi thành phần khơng có những hoạt đợng mong đợi Ví dụ: tìm kiếm nhị phân được gọi một mảng không được sắp xếp, việc tìm kiếm sẽ thực sai

(155)

3 Lỗi thời gian: lỗi này xảy hệ thớng thời gian thực có sử dụng việc chia sẻ bộ nhớ hoặc giao diện truyền thông điệp Việc sinh và xử lý dữ liệu không đồng bộ (tốc độ xử lý khác nhau)

Kiểm thử để phát những khiếm khuyết giao diện là khó đơi những lỗi giao diện này sinh trường hợp sử dụng bất thường Một vấn đề nữa nảy sinh tương tác giữa lỗi module hoặc đối tượng khác Lỗi một đối tượng được phát mợt đới tượng khác hoạt động không

Các kỹ thuật kiểm thử tĩnh thường hiệu quả mặt chi phí việc khám phá lỗi giao diện Mợt kiểu ngơn ngữ lập trình mạnh Java cho phép nhiều lỗi giao diện được phát biên dịch Trong ngơn ngữ yếu hơn, chẳng hạn C, sử dụng phân tích tĩnh giúp phát lỗi giao diện Kiểm tra chương trình tập trung vào giao diện thành phần và những câu hỏi giao diện thực trình thẩm tra

7.4 THIẾT KẾ TRƯỜNG HỢP KIỂM THỬ (TEST CASE DESIGN)

Mục tiêu tiến trình thiết kế trường hợp kiểm thử là tạo một tập trường hợp kiểm thử hiệu quả việc phát những lỗi chương trình và hệ thớng đáp ứng được yêu cầu

Để thiết kế một trường hợp kiểm thử, ta cần lựa chọn mợt tính hệ thống hoặc một thành phần kiểm thử, sau chọn mợt tập dữ liệu đầu vào để thực thi tính này

Dưới là một số cách tiếp cận khác được dùng để thiết kế trường hợp kiểm thử:

1 Kiểm thử dựa yêu cầu: trường hợp kiểm thử được thiết kế để kiểm tra yêu cầu hệ thống Kỹ thuật này thường được sử dụng giai đoạn kiểm thử hệ thống Với yêu cầu cần xác định trường hợp kiểm thử để chứng minh yêu cầu hệ thống được đáp ứng

2 Kiểm thử phân vùng (partition): xác định phân vùng dữ liệu đầu vào (input) và phân vùng kết quả đầu (output), thiết kế trường hợp kiểm thử cho hệ thống thực thi từ tất cả phân vùng và sinh tất cả phân vùng kết quả đầu Các phân vùng là những nhóm dữ liệu có tḥc tính chung, chẳng hạn tất cả sớ âm, tất cả những tên có đợ dài <30 kí tự, tất cả kiện sinh chọn một mục menu… 3 Kiểm thử cấu trúc: sử dụng kiến thức cấu trúc chương trình để thiết kế trường hợp

(156)

Kiểm thử dựa yêu cầu là một cách tiếp cận ngữ nghĩa (semantic) để thiết kế trường hợp kiểm thử thông qua việc xem xét yêu cầu và sinh một tập trường hợp kiểm thử cho yêu cầu này Kiểm thử dựa yêu cầu được xem là kiểm thử thẩm định là kiểm thử khiếm khuyết – nghĩa là ta cố gắng chứng minh hệ thống hoạt đợng đặc tả

Ví dụ, xem xét những yêu cầu cho hệ thống quản lý thư viện LIBSYS:

1 Người sử dụng tìm kiếm từ tập hợp sở dữ liệu ban đầu hoặc từ một tập tập sở dữ liệu ban đầu

2 Hệ thớng phải cung cấp công cụ hiển thị hợp lý để người sử dụng xem được tài liệu kho tài liệu

3 Mỗi phiếu đặt sách phải được cấp mợt sớ hiệu để người sử dụng lưu qua tài khoản vùng lưu trữ thường trực cá nhân

Giả sử ta xây dựng kịch bản kiểm thử cho chức tìm kiếm, những trường hợp kiểm thử sinh từ những yêu cầu chức tìm kiếm là:

- Tìm kiếm mợt sở dữ liệu với hai trường hợp: tài liệu có và khơng có sở dữ liệu

- Tìm kiếm hai sở dữ liệu với hai trường hợp: Tài liệu có và khơng có sở dữ liệu

- Tìm kiếm nhiều hai sở dữ liệu với hai trường hợp: Tài liệu có và khơng có sở dữ liệu

- Chọn một những sở dữ liệu từ thiết lập người sử dụng và bắt đầu tìm kiếm tài liệu mà được biết là có mặt khơng có mặt sở dữ liệu chọn - Chọn nhiều một sở dữ liệu tập sở dữ liệu và bắt đầu tìm kiếm tài liệu

mà được biết là có mặt và được biết khơng có mặt sở dữ liệu chọn

Thơng qua ví dụ này, ta nhận thấy việc kiểm thử một yêu cầu không viết một trường hợp kiểm thử mà thông thường ta phải viết vài kịch bản kiểm thử để đảm bảo kịch bản kiểm thử này bao phủ được tất cả trường hợp yêu cầu

Kiểm thử yêu cầu khác hệ thớng LYBSYS được thực giống Với yêu cầu thứ hai, ta sẽ đưa trường hợp kiểm thử để phân phối tất cả kiểu tài liệu được xử lý hệ thống và kiểm tra việc hiển thị tài liệu Với yêu cầu thứ ba, ta đưa vào mợt vài u cầu việc đặt tài liệu, sau kiểm tra định danh yêu cầu được hiển thị phiếu chứng nhận người dùng và kiểm tra định danh yêu cầu có phải là hay không

7.4.2 Kiểm thử phân vùng

(157)

Những lớp này được gọi là phân vùng tương đương Một cách tiếp cận có hệ thớng để thiết kế trường hợp kiểm thử là dựa việc xác định tất cả vùng cho một hệ thống hoặc một thành phần Các trường hợp kiểm thử được thiết kế cho dữ liệu kiểm thử và kết quả đầu nằm những vùng này Kiểm thử phân vùng sử dụng để thiết kế các trường hợp kiểm thử cho hệ thống thành phần

Trong hình 7.9, vùng tương đương được mợt hình ellipse Các vùng dữ liệu kiểm thử tương đương là tập dữ liệu mà tất cả thành viên tập hợp nên được xử lý cùng một cách Vùng kết quả đầu tương đương là chương trình có những đặc tính chung, chúng được xem mợt lớp riêng biệt Ta xác định vùng mà dữ liệu kiểm thử nằm bên ngoài vùng ta lựa chọn Trường hợp kiểm thử này được thực chương trình xử lý dữ liệu đầu vào không một cách hợp lý Dữ liệu và không tạo nên vùng tương đương

Hình 7.9 Phân vùng tương đương

Khi có mợt tập vùng xác định, ta lựa chọn trường hợp kiểm thử từ vùng này Một nguyên tắc nhỏ cho việc lựa chọn trường hợp kiểm thử là nên lựa chọn trường hợp nằm vùng biên là những trường hợp nằm giữa vùng Lý bản cho cách lựa chọn này là người thiết kế và lập trình ý tới những giá trị điển hình dữ liệu đầu vào phát triển hệ thống Ta kiểm tra trường hợp này với dữ liệu thuộc điểm giữa phân vùng Những giá trị ngoại biên thường là khơng kiểu, hay nằm ngoài tầm kiểm sốt người phát triển Lỗi chương trình thường xảy thực thi với những dữ liệu này

Khi xác định phân vùng ta thường sử dụng tài liệu đặc tả hoặc tài liệu người dùng

Hệ thống

Tập đầu

Đầu vào hợp lệ Đầu vào khơng

(158)

Hình 7.10 Các phân vùng tương đương

Để minh họa cho nguồn gốc trường hợp kiểm thử, ta sử dụng đặc tả chương trình tìm kiếm được hình 7.11 Đoạn chương trình này tìm kiếm mợt dãy thành phần đầu ra, mợt thành phần có giá trị định trước Chương trình sẽ trả lại vị trí thành phần dãy tìm thấy Trong trường hợp này, ta xác định phân vùng việc xác định tiền điều kiện, chương trình được gọi và mợt hậu điều kiện, sau chương trình được thực thi

Tiền điều kiện thuật toán tìm kiếm thực với mợt mảng khơng rỗng Hậu điều kiện biến tìm được thiết lập thành phần khóa nằm dãy Vị trí thành phần khóa là L dãy Chỉ số giá trị không được xác định thành phần cần tìm kiếm khơng tồn dãy Từ đặc tả này, bạn nhận thấy vùng tương đương nhau:

1 Input mà thành phần cần tìm nằm dãy (found = true)

2 Input mà thành phần cần tìm khơng nằm dãy (found = false)

Hình 7.11 Đoạn đặc tả chương trình tìm kiếm dãy

Để kiểm thử chương trình này, ta áp dụng dẫn sau:

1 Kiểm thử phần mềm với dãy giá trị đơn Người lập trình thơng thường nghĩ dãy được hình thành mợt sớ giá trị và thỉnh thoảng họ gắn giả thiết này vào chương trình họ Kết quả là chương trình làm việc không hợp lý được thực với một dãy giá trị đơn

2 Sử dụng dãy khác với kích thước khác kịch khác Điều này làm giảm hợi mà mợt chương trình có lỗi sẽ sinh kết quả một cách ngẫu nhiên đặc tính ngẫu nhiên dữ liệu đầu vào

Vì trường hợp kiểm thử với thành phần đầu tiên, giữa, cuối cùng dãy được truy cập Cách tiếp cận này sẽ phát những vấn đề điểm biên phân vùng

Nhỏ Từ đến 10 Lớn 10 Số giá trị đầu vào

Các giá trị đầu vào

Nhỏ 10000 Từ 10000 đến 99999 Lớn 99999

procedure Search (Key : ELEM ; T: SEQ of ELEM;

Found: in out BOOLEAN; L: in out ELEM_INDEX);

Pre-condition

Dãy có mợt phần tử T’FIRST <= T’LAST

Post-condition

Phần tử được tìm thấy và được L ( Found and T (L) = Key)

or

Phần tử không thuộc dãy ( not Found and

(159)

Từ những hướng dẫn trên, có hai phân vùng tương đương cần phải được xác định: Dãy dữ liệu vào có mợt giá trị đơn

2 Số thành phần dãy dữ liệu vào nhiều một thành phần

Sau xác định thêm phân vùng cách kết hợp vùng này – ví dụ, phân vùng mà số thành phần dãy lớn số thành phần không nằm phân vùng

Bảng 7.1 phân vùng phải xác định để kiểm thử chức tìm kiếm Mợt tập trường hợp kiểm thử dựa những phân vùng này được bảng 7.1 Nếu thành phần cần tìm kiếm khơng nằm dãy, giá trị L là không xác định (‘??’) Gợi ý sử dụng dãy với kích thước khác để kiểm thử trường hợp này

Tập hợp giá trị đầu vào để kiểm thử giải thuật tìm kiếm khơng thể bao qt được tất cả khía cạnh Giải thuật sai dãy dữ liệu vào bao gồm giá trị 1, 2, 3,

Bảng 7.1 Các phân hoạch tương đương cho chương trình tìm kiếm

Dãy Phần tử

Có mợt giá trị Tḥc dãy

Có mợt giá trị Không thuộc dãy

Nhiều một giá trị Là phần tử dãy

Nhiều một giá trị Là phần tử cuối cùng dãy

Nhiều một giá trị Là phần tử nằm giữa dãy

Nhiều một giá trị Khơng tḥc dãy

Dãy đầu vào (input) Khóa (Key) Đầu (Found, L)

17 17 True,

17 False, ??

17, 29, 21, 23 17 True,

41, 18, 9, 31, 30, 16, 45 45 True,

17, 18, 21, 23, 29, 41, 38 23 True,

21, 23, 29, 33, 38 25 False, ??

7.4.3 Kiểm thử cấu trúc

Kiểm thử cấu trúc (hình 7.12) là một cách tiếp cận để thiết kế trường hợp kiểm thử biết cấu trúc và mã nguồn phần mềm Cách tiếp cận này đơi cịn gọi là kiểm thử hộp trắng, hộp gương hoặc hộp – để phân biệt với kiểm thử hộp đen

(160)

Hình 7.12 Kiểm thử cấu trúc

Hình 7.13 Các lớp tương đương tìm kiếm nhị phân

Việc hiểu giải thuật được sử dụng chương trình giúp bạn xác định phân vùng và trường hợp kiểm thử Để minh họa cho điều này, ta tiến hành đặc tả thủ tục tìm kiếm (hình 7.11) giải thuật tìm kiếm nhị phân (hình 7.14) Giải thuật này phải có tiền điều kiện chặt chẽ Dãy được thực phải là một dãy được sắp xếp và giá trị cận mảng phải nhỏ giá trị cận

Hình 7.14 Thuật tốn tìm kiếm nhị phân

Bằng việc xem xét đoạn mã giải thuật tìm kiếm, ta thấy việc tìm kiếm nhị phân liên quan tới việc chia khoảng tìm kiếm thành ba phần Mỗi phần là mợt phân vùng tương đương (hình 7.13)

Sau ta thiết kế trường hợp kiểm thử cho khóa nằm biên phân vùng Đây là sở để xây dựng trường hợp kiểm thử cho giải thuật tìm kiếm, bảng 7.2 Dãy dữ liệu đầu vào được sắp xếp theo thứ tự tăng dần và phải thêm vào kiểm thử mà thành phần cần tìm kiếm sát với điểm giữa dãy

Các phần tử < phần tử giữa

Các phần tử > phần tử giữa

Ranh giới giữa lớp tương đương

Điểm giữa

Class BinSearch{

// Đây là hàm tìm kiếm nhị phân được thực mợt dãy đới tượng có thứ tự và mợt khóa // Trả mợt đới tượng với hai tḥc tính là:

// Index – giá trị số khóa dãy

// found – có kiểu logic cho biết có hay khơng có khóa dãy

// Một đối tượng được trả java thông qua kiểu bản tham chiếu // tới một hàm và trả hai giá trị Giá trị Index = -1 khóa khơng có dãy

public static void search(int key, int[] elemArray, Result r) {

1 int bottom = 0;

2 int top = elemArray.length – 1; Int mid;

3 r.found = false; r.index = -1; while (bottom <=top)

{

6 mid = (top + bottom)/2;

7 if(elemArray[mid] = key;

{

8 r,index = mid

9 r.found = true;

10 return;

} //if Else {

11 if(elemArray[mid]<key)

12 bottom = mid + 1;

Else

13 Top = mid – 1;

} } //while loop } //search

(161)

Bảng 7.2 Các trường hợp kiểm thử cho thuật tốn tìm kiếm nhị phân

Dãy đầu vào (input) Khóa (Key) Đầu (Found, L)

17 17 True,

17 False, ??

17, 21, 23, 29 17 True,

9, 16, 18, 30, 31, 41, 45 45 True,

17, 18, 21, 23, 29, 38, 41 23 True,

17, 18, 21, 23, 29, 33, 38 21 True,

12, 18, 21, 23, 32 23 True,

21, 23, 29, 33, 38 25 False, ??

7.4.4 Kiểm thử đường (path testing)

Kiểm thử đường là một chiến lược kiểm thử cấu trúc với mục tiêu thực thi tất cả đường một thành phần hoặc mợt chương trình Trước tiên, mọi đường đợc lập được thực thi, sau tất cả câu lệnh thành phần phải được thực thi một lần Hơn nữa, tất cả điều kiện phải được kiểm thử với hai trường hợp và sai

Trong tiến trình phát triển hướng đới tượng, kiểu kiểm thử này được sử dụng để kiểm thử việc thực thi phương thức đối tượng Số lượng đường độc lập mợt chương trình thường cân xứng với kích thước Khi mợt module được tích hợp vào hệ thớng, trở nên khó sử dụng phương pháp kiểm thử cấu trúc Kỹ thuật kiểm thử đường được sử dụng nhiều kiểm thử đơn vị

(162)

Điểm bắt đầu kiểm thử đường là sơ đồ luồng chương trình, là mợt mơ hình khung tất cả đường chương trình Mợt đồ thị luồng bao gồm điểm biểu diễn lệnh và đường mũi tên biểu diễn luồng điều khiển Đồ thị luồng được xây dựng từ việc thay lệnh điều khiển chương trình lược đồ tương đương Nếu khơng có lệnh goto chương trình, việc xây dựng lược đồ này đơn giản Mỗi nhánh câu lệnh rẽ nhánh (if/case) là một đường riêng biệt Một mũi tên lặp để tới điều kiện câu lệnh lặp Sơ đồ giải thuật tìm kiếm nhị phân được biểu diễn hình 7.15, tương đương với giải thuật được biểu diễn hình 7.14

Mục tiêu kiểm thử đường là đảm bảo đường chạy qua chương trình được thực thi mợt lần Các đường đợc lập là đường có mợt cạnh đồ thị Cả nhánh điều kiện và điều kiện sai phải được thực thi

Đồ thị cho giải thuật tìm kiếm được biểu diễn hình 7.15, đỉnh đồ thị biểu diễn mợt câu lệnh thực thi Ta tìm thấy đường chương trình tìm kiếm nhị phân theo sơ đồ trên:

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 14 1, 2, 3, 4, 5, 14

1, 2, 3, 4, 5, 6, 7, 11, 12, 5… 1, 2, 3, 4, 6, 7, 2, 11, 13, 5…

Nếu tất cả đường được thực thi, chắc chắn mọi lệnh phương thức được thực mợt lần Và nhánh được thực thi với cả hai điều kiện: và sai Thơng thường, ta tính tốn được sớ lượng đường đợc lập chương trình thơng qua luồng đồ thị chương trình Tuy nhiên, chương trình có cấu trúc rẽ nhánh phức tạp, khó xác định được sớ trường hợp kiểm thử được thực Khi đó, sử dụng công cụ kiểm thử tự động để phát cách thức thực thi thực chương trình

Các cơng cụ kiểm thử tự đợng cùng làm việc với trình biên dịch Trong lúc biên dịch, người phân tích thêm thị phụ để sinh mã Chúng đếm số lần câu lệnh được thực Sau chương trình thực hiện, mợt bản phác thảo thực thi được in Nó những phần chương trình được thực thi và chưa được thực thi cách sử dụng trường hợp kiểm thử đặc biệt Qua phát những phần chương trình chưa được thực thi

7.5 CƠNG CỤ KIỂM THỬ TỰ ĐỘNG

Kiểm thử là một giai đoạn tốn và được nghiên cứu nhiều tiến trình phần mềm Do đó, cơng cụ kiểm thử là một những công cụ hỗ trợ việc phát triển phần mềm đời Những công cụ này giúp giảm đáng kể thời gian và công sức cho kiểm thử

(163)

Một môi trường kiểm thử (workbench testing) là một tập cơng cụ được tích hợp hỗ trợ cho tiến trình kiểm thử Hình 7.16 mợt sớ cơng cụ được tích hợp mơi trường kiểm thử

Hình 7.16 Mơ hình mợt cơng cụ tích hợp kiểm thử

1 Bộ phận quản lý kiểm thử quản lý việc thực thi trường hợp kiểm thử chương trình Quản lý kiểm thử lưu vết dữ liệu kiểm thử, kết quả mong muốn và chức chương trình được kiểm thử JUnit là mợt ví dụ người quản lý kiểm thử Bộ sinh dữ liệu kiểm thử: sinh dữ liệu kiểm thử cho việc kiểm thử chương trình

Điều này được hoàn thành việc lựa chọn dữ liệu từ sở dữ liệu hoặc việc sử dụng mẫu (pattern) để sinh dữ liệu ngẫu nhiên

3 Hệ tiên đoán (Oracle): sinh những phán đoán kết quả mong đợi Các hệ tiên đốn là phiên bản chương trình trước hoặc hệ thớng bản mẫu (prototype) Kiểm thử quay lui liên quan tới việc chạy hướng dẫn và chương trình để được kiểm thử song song Những điểm khác kết quả đầu sẽ được lưu ý

4 Bộ so sánh file (File comparator) so sánh kết quả kịch bản kiểm thử chương trình với những kết quả kiểm thử trước và báo cáo những khác biệt Việc so sánh được sử dụng kiểm thử hồi quy, kết quả phiên bản khác được so sánh Bộ sinh báo cáo (Report generator): cung cấp báo cáo và sinh tiện ích cho kết quả

kiểm thử

6 Bợ phận phân tích (Dynamic analyzer): thêm mã nguồn vào chương trình để đếm sớ lần thực thi câu lệnh Sau kiểm thử, sinh bản tổng kết để câu lệnh nào được thực thường xuyên

Mã nguồn chương trình

Phân tích đợng

Báo cáo thực thi

Người quản lý kiểm thử

Chương trình được kiểm thử

Mô

Sinh dữ liệu kiểm thử

Hệ tiên đốn

Bợ so sánh file Bợ sinh báo

cáo Chương trình

được kiểm thử

Chương trình được kiểm thử

(164)

1 Các cơng cụ được thêm vào để kiểm thử đặc trưng một ứng dụng cụ thể, mợt sớ cơng cụ có không được dùng tới

2 Các kịch bản được viết cho việc mơ giao diện người dùng và mẫu (patterns) được xác định cho bộ sinh dữ liệu kiểm thử Các định dạng cho báo cáo phải khai báo

3 Tập hợp kết quả kiểm thử mong ḿn phải so sánh thủ cơng khơng có phiên bản chương trình trước dùng mợt hệ tiên đốn

4 Bợ so sánh tệp tin phải viết thêm vào việc mơ tả cấu trúc kết quả kiểm thử tệp tin

(165)

CÂU HỎI ÔN TẬP Trình bày khái niệm bản kiểm thử

2 Trong trình kiểm thử hệ thớng, người ta sử dụng hình thức kiểm thử nào?

3 Hãy xây dựng kịch bản kiểm thử cho chức rút tiền từ một máy ATM hệ thống ngân hàng

4 Xây dựng kịch bản kiểm thử phân vùng cho chương trình tìm ước chung lớn hai sớ UCLN (a, b)

(166)

Chương 8: BẢO TRÌ PHẦN MỀM VÀ QUẢN LÝ THAY ĐỔI

Bảo trì giai đoạn ći chu trình phát triển phần mềm Các chương trình máy tính ln thay đổi nhu cầu mở rộng, sửa lỗi, tối ưu hố, u cầu người dùng phát sinh, mơi trường vận hành hệ thống thay đổi Theo thống kê bảo trì chiếm đến 70% tồn bợ cơng sức bỏ cho một dự án phần mềm Do vậy, bảo trì là mợt hoạt đợng phức tạp lại vơ cần thiết chu trình sớng sản phẩm phần mềm để đảm bảo phần mềm đáp ứng được yêu cầu người sử dụng

Do nhu cầu phát triển hệ thớng thơng tin, hay khơng ḿn nói là khơng thể có mợt hệ thớng thơng tin khơng có thay đổi śt chu trình sớng Để trì tính đắn, trật tự giai đoạn bảo trì quản lý thay đổi phần mềm là một hoạt động cần thiết

Chương này giới thiệu hoạt đợng bảo trì và loại bảo trì phần mềm Mợt sớ đặc trưng bản hoạt đợng bảo trì, từ sinh viên hiểu được bước bản bảo trì, những khó khăn q trình bảo trì hệ thống phần mềm Phần cuối chương giới thiệu hình thức bảo trì và hoạt đợng quản lý thay đổi tiến trình bảo trì phần mềm 8.1 PHÂN LOẠI HOẠT ĐỘNG BẢO TRÌ PHẦN MỀM

Bảo trì phần mềm là phức tạp và chia hoạt đợng bảo trì làm bớn hoạt đợng sau:

8.1.1 Bảo trì hiệu chỉnh

Hoạt động kiểm thử phần mềm khẳng định được việc loại bỏ hoàn toàn lỗi chương trình có những lỗi ẩn chứa bên một hệ thống phần mềm lớn là khó phát Phần mềm sau kiểm thử sẽ được bàn giao cho khách hàng, trình sử dụng, lỗi nào xuất được báo cho người phát triển

Bảo trì hiệu chỉnh là q trình phân tích hiệu chỉnh mợt hay nhiều lỗi chương trình được đưa vào sử dụng

8.1.2 Bảo trì cải tiến

Hoạt đợng bảo trì cải tiến diễn mơi trường vận hành hệ thống thường xuyên thay đổi Những hệ phần cứng dường được công bố theo chu trình 24 tháng mợt lần Hệ điều hành hay phiên bản hệ điều hành cũ đặn xuất hiện; thiết bị ngoại vi thành phần hệ thống khác liên tục được nâng cấp thay đổi Mặt khác, thời gian hữu dụng một phần mềm ứng dụng dễ dàng vượt qua thời hạn mười năm, lâu môi trường vận hành hệ thớng

Tóm lại, Bảo trì cải tiến hoạt đợng sửa đổi phần mềm để thích ứng được với những thay đổi môi trường

8.1.3 Bảo trì hồn thiện

(167)

trong q trình sử dụng phần mềm, u cầu có thêm chức mới, yêu cầu thay đổi những chức có và mở rợng tổng thể sản phẩm được người dùng đề xuất Để thỏa mãn những yêu cầu phát triển người sử dụng, cần phải tiến hành bảo trì hoàn thiện sản phẩm 8.1.4 Bảo trì phịng ngừa

Bảo trì phịng ngừa là hoạt đợng bảo trì diễn phần mềm được thay đổi để cải thiện tính bảo trì hay đợ tin cậy tương lai hoặc để cung cấp một tảng tốt cho những mở rộng sau Bảo trì phịng ngừa là hoạt đợng cịn xa lạ giới phần mềm

Các thuật ngữ dùng để mơ tả ba hoạt đợng bảo trì Swanson đề xướng Thuật ngữ thứ tư thường được dùng việc bảo trì phần cứng hay hệ thống vật lý khác Tuy nhiên, cần ý những điểm tương tự giữa bảo trì phần mềm và bảo trì phần cứng gây nhầm lẫn Phần mềm khác với phần cứng tận dụng được, hoạt đợng bảo trì phần cứng chủ yếu thay bộ phận bị hỏng hóc hay gãy vỡ - khơng được kể đến

Trong thực tế hoạt đợng bảo trì, nhiệm vụ được thực một phần bảo trì cải tiến bảo trì hồn thiện, giống nhiệm vụ cần làm giai đoạn phát triển mợt chu trình phần mềm Để cải tiến hay hoàn thiện, phải xác định yêu cầu, thiết kế lại, tạo mã kiểm tra phần mềm có được Thơng thường nhiệm vụ được gọi là bảo trì

8.2 ĐẶC ĐIỂM CỦA BẢO TRÌ PHẦN MỀM

Bảo trì phần mềm gần cịn là mợt giai đoạn bị coi nhẹ chu trình phần mềm Kiến thức bảo trì có được so sánh với giai đoạn hoạch định phát triển Có sớ liệu nghiên cứu chế tạo tập trung vào đề tài phương pháp kỹ thuật được đưa Để hiểu được bản chất bảo trì, sẽ xem xét vấn đề từ ba góc đợ khác nhau:

- Các hoạt động cần thiết để hoàn thành giai đoạn bảo trì đảm bảo tính toàn vẹn, ổn định và hiệu quả phần mềm

- Chi phí giai đoạn bảo trì

- Các vấn đề thường gặp phải tiến hành bảo trì phần mềm 8.2.1 Bảo trì có cấu trúc bảo trì khơng cấu trúc

(168)

Nếu có mợt cấu hình phần mềm hồn thiện, nhiệm vụ bảo trì bắt đầu việc đánh giá tài liệu thiết kế Sau xác định đặc điểm thuộc cấu trúc quan trọng, đặc điểm hoạt động giao diện Tính tồn vẹn những sửa đổi hay hiệu chỉnh cần thiết sẽ được đánh giá một kế hoạch sửa đổi sẽ được thiết lập Thiết kế được thay đổi, nhận xét đánh giá giải pháp, mã nguồn được phát triển, sau tiến hành kiểm tra hồi quy sử dụng thông tin chứa phần "đặc tả kiểm tra", cuối cùng phần mềm lại được phát hành

Các mô tả là phép bảo trì cấu trúc và được tiến hành là kết quả những ứng dụng trước khoa học công nghệ phần mềm Mặc dù có mặt mợt cấu hình phần mềm khơng đảm bảo được vấn đề bảo trì nảy sinh, khối lượng công việc được giảm bớt chất lượng chung những thay đổi hoặc hiệu chỉnh được cải thiện 8.2.2 Giá thành bảo trì

Theo thớng kê, giá thành cho việc bảo trì phần mềm tăng lên một cách đặn śt 20 năm qua Trong những năm 1970, bảo trì chiếm từ 35 đến 40% kinh phí phần mềm dành cho tổ chức hệ thống thông tin Tỷ lệ nhảy tới số 60 vào giữa những năm 1980 Nhiều cơng ty chi 80% kinh phí cho việc bảo trì vào giữa những năm 1990

Chi phí cho việc bảo trì rõ ràng Tuy nhiên những chi phí khác khó thấy gây mối quan tâm lớn hơn:

- Một chi phí khó xác định việc bảo trì phần mềm hội phát triển bị bỏ qua tài ngun có sẵn dành cho nhiệm vụ bảo trì

- Sự khơng hài lịng người dùng yêu cầu có vẻ hợp lý cho việc sửa chữa hay sửa đổi không được ý một cách hợp lý

- Việc suy giảm chất lượng nói chung lỗi tạo thay đổi phần mềm được bảo trì

- Một yêu cầu bất chợt làm ngắt quãng trình phát triển mợt nhân viên ḅc tiến hành cơng việc bảo trì

Chi phí ći cho việc bảo trì giảm sút nghiêm trọng suất lao động (được đo theo số dịng lệnh -LOC- mợt người mợt tháng hay sớ tiền chi phí cho dịng lệnh) Sự giảm sút xuất tiến hành bảo trì đới với phần mềm cũ Người ta ghi nhận giảm sút suất lao động theo tỷ lệ 40:1, có nghĩa là chi phí cho việc phát triển trị giá $25.00 mợt dịng lệnh sẽ trị giá tới $1000.00 cho việc bảo trì dịng lệnh

Cơng sức cho việc bảo trì được phân chia thành thao tác làm việc: phân tích, ước lượng, thay đổi thiết kế, sửa chữa chương trình nguồn thao tác lặp lại, cớ gắng hiểu chương trình nguồn làm gì, cớ gắng sáng tỏ cấu trúc dữ liệu, tḥc tính giao diện, giới hạn việc thực Biểu thức cung cấp mợt mơ hình cho cơng việc bảo trì:

M = p + K* exp(c-d),

Với M = toàn bộ công việc cho việc bảo trì; p = cơng việc làm (như miêu tả trên);

(169)

c = đánh giá mức đợ phức tạp được tính cho việc thiếu thiết kế cấu trúc và dữ liệu; d = đánh giá mức đợ hiểu biết phần mềm

Mơ hình cho thấy cơng việc giá thành tăng lên theo cấp số mũ một phương pháp phát triển phần mềm cỏi được sử dụng (tức là thiếu sót cơng nghệ phần mềm), hoặc mợt người hay mợt nhóm dùng phương pháp khơng có giá trị để bảo trì phần mềm Chi phí cho bảo trì phần mềm được phát triển khơng phương pháp được minh hoạ hình 8.1:

Hình 8.1 Chi phí việc phát triển phần mềm khơng có phương pháp 8.2.3 Mợt số khó khăn khác bảo trì

Hầu hết vấn đề liên quan tới bảo trì phần mềm liên quan tới sai lệch cách xây dựng phát triển phần mềm Sự thiếu sót việc điều khiển tổ chức hai giai đoạn mợt chu trình phần mềm gần ln tạo vấn đề giai đoạn cuối Nhiều vấn đề kinh điển liên quan tới việc bảo trì phần mềm được trình bày đây:

- Rất khó hoặc khơng thể theo dõi tiến hóa phần mềm qua phiên bản - Các thay đổi khơng được tư liệu hóa

- Khó theo dõi được q trình xử lý được tạo phần mềm

- Thường xuyên gặp nhiều khó khăn việc tìm hiểu chương trình người khác viết

Những khó khăn tăng lên sớ thành phần cấu hình phần mềm giảm Nếu có chương trình nguồn khơng có tài liệu hướng dẫn khơng nên tìm hiểu phần mềm Những người viết phần mềm thường khơng có mặt để giải thích Chúng ta khơng thể trơng cậy vào những giải thích cá nhân nhà phát triển phần mềm việc bảo trì được yêu cầu

(170)

Việc bảo trì phần mềm khơng được coi mợt cơng việc dễ dàng mà cơng việc bảo trì phần mềm ln liên quan tới sai lệch mức độ cao

8.3 CƠNG VIỆC BẢO TRÌ PHẦN MỀM VÀ MỘT SỐ HIỆU ỨNG LỀ 8.3.1 Khả bảo trì

Khả bảo trì phần mềm coi khả hiểu, hiệu chỉnh, tiếp hợp hoặc thêm vào khả phát triển Khả bảo trì chìa khóa để dẫn đến phương pháp thiết kế xây dựng phần mềm

a) Yếu tố kiểm soát

Khả bảo trì bản bao gồm nhiều yếu tớ Sự thiếu cẩn trọng việc thiết kế, viết chương trình nguồn, kiểm tra có ảnh hưởng tiêu cực đến việc bảo trì có kết quả mợt phần mềm Cấu hình yếu có tác đợng tương tự, chí cả bước kỹ thuật xây dựng phần mềm được xem xét một cách cẩn thận Thêm vào nhiều yếu tớ khác liên quan tới phương pháp phát triển phần mềm, như:

- Chất lượng hiệu quả đội ngũ phát triển phần mềm - Cấu trúc hệ thống dễ hiểu

- Dễ dàng kiểm sốt hệ thớng

- Dùng ngơn ngữ lập trình chuẩn - Dùng hệ điều hành chuẩn - Dùng cấu trúc chuẩn tài liệu - Dùng được tài liệu kiểm tra - Phương tiện gỡ rối kèm

- Dùng được máy tính tớt để thực việc bảo trì

Các yếu tố được đưa phản ánh những đặc điểm phần cứng chương trình nguồn được dùng việc phát triển phần mềm Những yếu tố khác cần thiết để có được phương pháp ch̉n, chương trình nguồn ch̉n Có thể, yếu tố quan trọng tác động tới khả bảo trì kế hoạch cho khả bảo trì Nếu coi phần mềm là mợt hệ thớng thành phần sẽ phải chịu những thay đổi không tránh được, hợi tạo những phần mềm có khả bảo trì sẽ tăng thực

b) Đánh giá định lượng

Khả bảo trì, chất lượng hay độ tin cậy là hết sức khó xác định Tuy nhiên đánh giá khả bảo trì gián tiếp việc xem xét tḥc tính cơng việc bảo trì đánh giá được là:

- Thời gian nhận biết vấn đề

- Thời gian trễ cơng việc hành - Thời gian lựa chọn cơng cụ bảo trì

(171)

- Thời gian xác định thay đổi

- Thời gian hiệu chỉnh (hay sửa đổi) thực - Thời gian chạy thử cục bộ

- Thời gian chạy thử tổng thể - Thời gian tổng kết bảo trì

- Tổng thời gian cơng việc bảo trì

Mỗi đánh giá thực tế dữ liệu cung cấp cho người quản lý cùng với số hiệu quả cơng việc

8.3.2 Các cơng việc bảo trì

Những nhiệm vụ liên quan tới việc bảo trì gồm: tổ chức bảo trì được thiết lập; thủ tục ghi nhận đánh giá được miêu tả một loạt thứ tự chuẩn bước cho yêu cầu bảo trì phải được định nghĩa Thêm vào đó, mợt thủ tục lưu trữ hồ sơ cho hoạt đợng bảo trì được thiết lập và bản tổng kết những tiêu chuẩn đánh giá được vạch rõ

a) Cơ cấu bảo trì

Mặc dù những tổ chức bảo trì ch̉n khơng cần được thiết lập, ủy thác trách nhiệm cần thiết kể cả với tổ chức phát triển phần mềm nhỏ Những yêu cầu bảo trì được chuyển qua cho người kiểm sốt cơng việc bảo trì từ chuyển tiếp yêu cầu tới người quản lý hệ thống để đánh giá, người quản lý hệ thống thành viên nhóm nhân viên kỹ thuật Những nhân viên này có trách nhiệm mợt phần nhỏ chương trình sản phẩm Khi mợt u cầu được đánh giá, người được ủy quyền quản lý việc thay đổi phải định hành động được thực

Cơ cấu được miêu tả phục vụ cho việc thiết lập phạm vi trách nhiệm đới với cơng việc bảo trì Người kiểm sốt người ủy quyền quản lý việc thay đổi là mợt người mợt nhóm quản lý và chuyên gia kỹ thuật cao cấp

b) Báo cáo

(172)

Thường khơng có đầy đủ hồ sơ cho tất cả giai đoạn chu kỳ sống một phần mềm Thêm nữa khơng có hồ sơ việc bảo trì phần mềm Do đó, thường khó tiến hành cơng việc bảo trì có hiệu quả, khơng có khả xác định tính chất chương trình khó xác định được giá bảo trì phần mềm Các thông tin cần phải lưu giữ hồ sơ bảo trì thường là:

- Dấu hiệu nhận biết chương trình

- Sớ lượng câu lệnh chương trình nguồn - Sớ lượng lệnh mã máy

- Ngơn ngữ lập trình được sử dụng - Ngày cài đặt chương trình

- Sớ chương trình chạy từ cài đặt - Số lỗi xử lý xảy

- Mức và dấu hiệu thay đổi chương trình

- Sớ câu lệnh được thêm vào chương trình nguồn chương trình thay đổi - Sớ câu lệnh được xóa khỏi chương trình nguồn chương trình thay đổi - Số người sử dụng cho lần sửa đổi

- Ngày thay đổi chương trình - Dấu hiệu kỹ sư phần mềm - Dấu hiệu đơn yêu cầu bảo trì - Kiểu bảo trì

- Ngày bắt đầu và kết thúc bảo trì

- Tổng sớ người dùng cho việc bảo trì d) Xác định giá bảo trì

Việc xác định giá trị bảo trì thường phức tạp thiếu thông tin Nếu tiến hành việc lưu giữ hồ sơ tiến hành một số cách đánh giá việc thực bảo trì Theo chuyên gia đánh giá việc thực bảo trì dựa vào:

- Sớ lượng trung bình lỗi xử lý cho mợt lần chạy chương trình - Tổng sớ người dùng cho loại bảo trì

- Sớ lượng trung bình thay đổi theo chương trình, theo ngơn ngữ lập trình, theo kiểu bảo trì

- Sớ trung bình người cho mợt dịng lệnh được thêm vào xóa - Sớ trung bình người cho mợt ngơn ngữ lập trình

(173)

8.3.3 Một số hiệu ứng lề cơng việc bảo trì

Sửa đổi phần mềm công việc nguy hiểm, ta thường gặp ba loại hiệu ứng lề sau:

a) Hiệu ứng lề việc thay đổi mã nguồn

Một thay đổi đơn giản tới một câu lệnh đơn đem lại mợt hậu quả thảm khốc Mặc dù không phải ảnh hưởng tiêu cực, việc sửa lỗi dẫn đến vấn đề phức tạp Mặc dù tất cả thay đổi mã lệnh chương trình tạo lỗi, tập hợp thay đổi sau gây nhiều lỗi

- Mợt chương trình bị xóa hay thay đổi - Mợt dịng nhãn bị xóa hay thay đổi

- Mợt biến bị xóa hay thay đổi

- Các thay đổi để tăng khả thực - Việc mở và đóng file bị thay đổi

- Các phép toán logic bị thay đổi

- Việc thay đổi thiết kế chuyển thành thay đổi lớn chương trình - Các thay đổi ảnh hưởng đến việc chạy thử trường hợp biên b) Hiệu ứng lề việc thay đổi liệu

Trong trình bảo trì, việc sửa đổi thường được tiến hành đối với phần tử riêng rẽ cấu trúc dữ liệu Khi dữ liệu thay đổi, việc thiết kế phần mềm sẽ khơng cịn phù hợp với dữ liệu và lỗi có khả xảy Hiệu ứng lề dữ liệu xảy là kết quả việc thay đổi cấu trúc dữ liệu Các thay đổi dữ liệu sau thường gây lỗi:

- Định nghĩa lại số cục bộ và số địa phương - Định nghĩa lại cấu trúc bản ghi hay cấu trúc file

- Tăng hoặc giảm kích thước mợt mảng - Thay đổi dữ liệu tổng thể

- Định nghĩa lại cờ điều khiển trỏ

- Xếp lại tham số vào hay tham số chương trình

(174)

Tài liệu thiết kế phản ánh không trạng thái phần mềm có lẽ cịn tồi tệ khơng có tài liệu Hiệu ứng lề xảy lần bảo trì sau đó, việc nghiên cứu khơng kỹ tài liệu kỹ thuật, dẫn tới đánh giá sai đặc tính phần mềm Đới với người sử dụng, phần mềm tớt có tài liệu hướng dẫn sử dụng chúng

Các hiệu ứng lề tài liệu được giảm bản toàn bợ cấu hình được xem xét trước phát hành phiên bản phần mềm tiếp sau Thực tế mợt vài u cầu bảo hành địi hỏi khơng được thay đổi thiết kế phần mềm hoặc mã chương trình, mà cần thiếu rõ ràng tài liệu người sử dụng Trong những trường hợp nỗ lực bảo trì tập trung vào tài liệu

8.4 MỘT SỐ HÌNH THỨC BẢO TRÌ PHẦN MỀM 8.4.1 Bảo trì mã chương trình xa lạ

Các chương trình được gọi mã chương trình xa lạ nếu:

- Khơng mợt thành viên phịng kỹ thuật tiếp tục phát triển chương trình nữa

- Khơng tiếp tục áp dụng lý thuyết phát triển, tồn vấn đề thiết kế nghèo nàn tài liệu (theo tiêu chuẩn ngày nay)

- Cấu trúc khối chưa được thiết kế theo tiêu chuẩn, khái niệm thiết kế có cấu trúc chưa được áp dụng

Dưới một số đề nghị hữu dụng cho người quản trị hệ thống phải bảo trì chương trình xa lạ:

- Nghiên cứu chương trình trước bạn bị đặt vào "chế độ khẩn cấp" Cố gắng thu nhận được nhiều thông tin sở càng tốt

- Cố gắng làm quen với tồn bợ luồng điều khiển chương trình; trước hết bỏ qua chi tiết mã chương trình Sẽ có ích vẽ riêng sơ đồ cấu trúc sơ đồ luồng hoạt động mức cao, chưa có bản nào tồn

- Đánh giá tình hình hợp lý tài liệu có; bổ sung thêm lời thích bản thân bạn vào chương trình nguồn bạn thấy cần thiết

- Sử dụng tốt danh sách dẫn tham khảo, bảng ký hiệu trợ giúp khác thường được chương trình dịch cung cấp

- Thực sửa đổi chương trình với ý lớn Lưu ý tới kiểu dạng chương trình tất cả chỗ Đánh dấu chương trình những lệnh bạn sửa

- Đừng loại bỏ chương trình trừ bạn chắc chắn khơng được sử dụng nữa - Đừng cố sử dụng chung biến tạm thời vùng nhớ làm việc mà có sẵn chương trình Thêm biến riêng bạn để tránh rắc rối

(175)

8.4.2 Công nghệ phản hồi công nghệ tái sử dụng

Công nghệ phản hồi -Reverse engineering- đối với phần mềm đơn giản Trong nhiều trường hợp, chương trình được tổ chức ngược không phải thuộc nhà cạnh tranh mà thuộc bản thân cơng ty Bí mật cần khám phá khơng cịn giữ được đặc tả Do đó, tổ chức ngược đới với phần mềm q trình phân tích chương trình cớ gắng biểu diễn lại chương trình mức đợ trừu tượng cao mã nguồn Tổ chức lại là trình khám phá thiết kế Các công cụ công nghệ phản hồi lấy dữ liệu, kiến trúc, thông tin thiết kế thủ tục từ chương trình tồn

Công nghệ tái sử dụng, Re-engineering, không đơn phát thơng tin thiết kế mà cịn dùng thông tin để biến đổi hoặc tổ chức lại hệ thớng tồn với mục đích cải thiện chất lượng Trong nhiều trường hợp, phần mềm ứng dụng lại chức hệ thống tồn Nhưng thời điểm, nhà phát triển phần mềm phải thêm chức và/hoặc cải thiện xử lý

8.4.3 Bảo trì dự phịng

Bảo trì dự phịng phần mềm máy tính mợt vấn đề cịn được tranh cãi Thay đợi nhận được yêu cầu bảo trì, tổ chức phát triển hay bảo trì chọn mợt chương trình mà:

- Sẽ được sử dụng một số năm định trước; - Hiện được sử dụng tốt;

- Dễ bị thay đổi hoặc nâng cấp tương lai gần

Thoạt đầu ý kiến đề nghị phát triển lại một chương trình lớn mợt phiên bản làm việc tồn ta thấy dường lãng phí Nhưng xem xét điểm sau:

- Chi phí để bảo trì mợt dịng mã lệnh lớn 20 tới 40 lần chi phí cho phát triển ban đầu dịng lệnh

- Thiết kế lại cấu trúc phần mềm, với sử dụng khái niệm thiết kế làm cho việc bảo hành tương lai dễ dàng

- Bởi khn mẫu phần mềm tồn tại, suất phát triển chương trình chắc sẽ cao mức trung bình nhiều

- Người sử dụng làm quen với phần mềm Vì vậy, địi hỏi và hướng thay đổi tìm dễ dàng nhiều

(176)

8.4.4 Chiến lược phần mềm thành phần

Như đặc tính cổ điển bảo hành phần cứng tháo bỏ phần hỏng và thay phụ tùng Một khái niệm được gọi là nguyên mẫu phần mềm dẫn tới việc phát triển phụ tùng cho chương trình

Nguyên mẫu phần mềm là mợt q trình mơ hình hóa u cầu người dùng một hay nhiều mức chi tiết, bao gồm cả mơ hình làm việc Các tài ngun dự án được xếp đặt để sản xuất phiên bản phần mềm được mô tả theo yêu cầu phải nhỏ Phiên bản nguyên mẫu làm cho người dùng, người thiết kế quản trị xem lại được phần mềm Q trình sẽ tiếp tục được đề nghị, với phiên bản chạy chuẩn bị sẵn sàng phát hành sau vài lần làm lại

Nếu mức nguyên mẫu khác được phát triển, có mợt bợ phụ tùng phần mềm được sử dụng nhận được u cầu bảo trì hiệu chỉnh Ví dụ mợt module phân tích được thiết kế thực theo hai cách khác có giao diện bên ngồi Mợt phiên bản module có được sử dụng phần mềm làm việc Nếu module hỏng, mợt phụ tùng được thay

Mặc dù chiến lược phụ tùng thay cho phần mềm có vẻ khác thường mợt chút, khơng có chứng tỏ tớn kém, tính đến chi phí cho tất cả chu kỳ sống phần mềm

8.5 QUẢN LÝ THAY ĐỔI PHẦN MỀM

Các ứng dụng thường xuyên phải thiết kế lại phân công một nhóm quản lý mới, dự án vượt ngân sách, ứng dụng chậm có nhiều lỗi, thiếu tin tưởng chủ sử dụng việc kỹ sư phần mềm hiểu rõ yêu cầu

Các thay đổi yêu cầu, thiết kế, chương trình, giao diện, phần cứng hoặc phần mềm phải mua Phần lớn thay đổi bắt nguồn từ bên tổ chức phát triển ứng dụng, được kích hoạt từ tác nhân bên ngồi, ví dụ thay đổi luật

Việc quản lý thay đổi ứng dụng giúp cho nhóm triển khai bỏ qua những ý thích chợt nảy người sử dụng cho phép thực yêu cầu hợp lý

8.5.1 Các thủ tục quản lý thay đổi

Quản lý điều khiển thay đổi có hiệu lực từ sản phẩm được chấp nhận hoàn thiện dự án kết thúc Trước tiên, sản phẩm công việc sở được tạo lập để đưa vào quản lý Một sản phẩm công việc sở một sản phẩm được coi là hoàn thiện và sở cho cơng việc khác nhóm triển khai dự án Ví dụ như, mợt tài liệu sở bản quy định yêu cầu chức sau được chấp nhận người sử dụng Dưới ví dụ mợt q trình thao tác yêu cầu thay đổi một đặc tả chức năng:

- Tạo yêu cầu mở; - Khai báo file tác động;

- Phê chuẩn file thời gian chi phí người quản lý, người sử dụng ký;

(177)

mục cập nhật hoàn thiện Nếu thủ tục hoặc thử nghiệm bị thay đổi, xác định ngày mà việc sửa đổi xảy Mẫu yêu cầu đóng file được chủ/người sử dụng thơng qua

- Tóm tắt ngày tháng, q trình chi phí

Trước tiên, tài liệu sở được giữ nguyên, sau thêm vào yêu cầu thay đổi Khi quy định chức được cập nhật để điều tiết thay đổi, được đóng băng lại cơng việc lại tiếp tục Ba yêu cầu trước được thêm vào ứng dụng chúng không làm thay đổi ứng dụng nhiều Chúng bị bỏ qua sau ứng dụng được thực Các thay đổi phân loại theo mợt sớ cách:

- Thứ nhất, chúng được phân theo kiểu loại bỏ lỗi, cải tiến thực hoặc thay đổi chức năng;

- Thứ hai, thay đổi phân loại thành yêu cầu và lựa chọn;

- Thứ ba, phân theo độ ưu tiên khẩn cấp, lệnh với một ngày kết thúc yêu cầu, lệnh với ngày bắt đầu yêu cầu hoặc ưu tiên thấp

Thông thường, kiểu loại bỏ lỗi khẩn cấp theo yêu cầu, thay đổi chức bảo dưỡng lệnh theo yêu cầu cải tiến thực lựa chọn khơng có ưu tiên Việc biết được loại yêu cầu thay đổi định xem liệu có cần phải chịu điều khiển thay đổi hay không Các thay đổi khẩn cấp thường phá vỡ thủ tục điều khiển thay đổi công việc thực chúng lại được tài liệu hoá sau thay đổi kết thúc Tất cả loại thay đổi khác phải tuân theo điều khiển thay đổi Ví dụ thay đổi yêu cầu chức xảy bất cứ lúc nào, quy định yêu cầu chức được thông qua đóng băng ứng dụng hoạt động Các thay đổi phải chịu điều khiển thay đổi: chúng được thêm vào danh sách yêu cầu thay đổi để xem xét tương lai trừ là một thiết kế khẩn cấp

Một thủ tục điều khiển thay đổi yêu cầu người sử dụng phải đệ trình mợt lời u cầu thay đổi thức cho người điều hành dự án:

- Người sử dụng gửi cho người điều hành dự án người chủ một mẫu yêu cầu thay đổi

- Người điều hành dự án kỹ sư phần mềm triển khai mợt khai báo tự đợng Vào lúc đó, danh sách kiểm soát người điều hành dự án được dùng để xác định tất cả hoạt động thay đổi cơng việc có liên quan tới u cầu Yêu cầu thay đổi được thảo luận với chủ sử dụng để vạch thay đổi ưu tiên, tiến trình và chi phí

(178)

- Yêu cầu, ngày dự định hoạt động, thay đổi tiến trình tăng chi phí được thêm vào mợt file q trình dự án Các thay đổi được quản lý một nhân viên điều khiển thay đổi, mợt người có nhiệm vụ bảo dưỡng q trình dự án bản ghi điều khiển thay đổi, hàng tháng in một bản báo cáo điều khiển thay đổi Một tệp điều khiển thay đổi chứa tất cả yêu cầu, thư từ tài liệu thay đổi Mợt u cầu thay đổi mở được tạo yêu cầu được đưa và một số lượng thay đổi được gán Yêu cầu thay đổi mở nằm tệp yêu cầu được hoàn thành, đóng và được báo cáo

Khi thay đổi được thực hiện, mục có ảnh hưởng được cập nhật, bao gồm tư liệu tương ứng, mã nguồn chương trình, Mợt danh sách kiểm sốt người điều hành dự án được dùng để loại bỏ hoạt động được yêu cầu Tài liệu được nhân viên điều khiển thay đổi sắp xếp phân phới cho những người có quan tâm Ngày hoàn thành thay đổi được đưa vào file điều khiển thay đổi Thay đổi được xác định được đóng báo cáo tình trạng tới và u cầu mở được chuyển từ file điều khiển thay đổi sang

Dựa tổ chức này, người điều hành hệ thớng theo dõi u cầu thay đổi dự án để nhận biết thành công nhóm u cầu Chi phí thay đổi chung một năm thường được sử dụng một tiêu để xem ứng dụng có triển vọng hay cần vứt bỏ hay cần cơng nghệ hố lại Trong những trường hợp này, cả chi phí số lượng yêu cầu thay đổi được theo dõi thơng qua q trình điều khiển thay đổi Các báo cáo tổng kết dự án thay đổi một thời kỳ định, hoặc so sánh theo thời kỳ được triển khai

8.5.2 Ghi định theo thời gian

Khi bắt đầu một dự án, người điều hành dự án kỹ sư phần mềm định sử dụng công cụ để lưu trữ q trình định Có nghĩa dùng công cụ điện tử hoặc một phiên bản viết tay định được trì dạng văn bản Với công cụ điện tử, bản điện tử được lưu trữ Với công cụ ghi tay, phiên bản cũ được cập nhật đổi tên mợt tài liệu thay đổi Ví dụ như, quy định chức cơng ty ABC được đặt tên ABCFS-mmddyy, ABC cơng ty, FS viết tắt quy định chức (Functional Specification) mmddyy ngày tháng năm Phần ngày tháng tên sẽ thay đổi một thay đổi quan trọng nào tài liệu Thủ tục quản lý thay đổi sẽ được nói đến phần

8.5.3 Quản lý thay đổi tài liệu

Các thay đổi tài liệu được xác định một bảng nội dung thay đổi đầu tài liệu Bảng nội dung thay đổi bao gồm ngày hiệu lực, phần bị ảnh hưởng tài liệu mợt tóm tắt thay đổi Mục đích bảng nợi dung thay đổi là để tóm tắt tất cả thay đổi cho người đọc

(179)

CÂU HỎI ÔN TẬP Có loại hoạt đợng bảo trì?

2 Khi thực bảo trì phần mềm, những yếu tố nào được đánh giá là quan trọng? Việc bảo trì phần mềm gây những hiệu ứng gì?

4 Hãy nêu hình thức bảo trì

(180)

BÀI TẬP

HỆ THỐNG CHO THUÊ ĐĨA TỰ ĐỘNG AL2010

Một công ty cho thuê đĩa DVD muốn mở rộng mạng lưới kinh doanh nhiều điểm khác cách lắp đặt hệ thớng máy cho th tự đợng có tên AL2010 Các hệ thống này sẽ được lắp đặt những trung tâm thương mại nhỏ, trung tâm vui chơi giải trí

Các hệ thớng máy này phải đợc lập, truy cập 24/24h và dễ sử dụng Công ty can thiệp vào hệ thớng máy những trường hợp đặc biệt Cịn để xác nhận xem hệ thống máy hoạt động tớt hay khơng và mợt vài hoạt đợng bảo trì thường xuyên khác được thực từ xa thơng qua mợt đường tín hiệu riêng Khơng có mới liên hệ giữa hệ thống máy khác được lắp đặt địa điểm khác

AL2010 lưu trữ được tối đa 100 đĩa DVD Việc lựa chọn đĩa DVD để đưa vào hệ thống máy tính nhân viên chi nhánh thực hiện, thông qua một danh sách phim mà công ty có Danh sách này lên tới hàng nghìn bản ghi và cơng ty đưa mợt danh sách phim phát hành tháng

Việc nhận và trả đĩa nhân viên chi nhánh được thực qua bưu điện, những đơn đặt hàng đặc biệt được thực qua bưu điện

Hình thức giao diện của các hệ thống máy tự động

Về mặt vật lý, hệ thống máy này gần giống hệ thống ATM, nhân viên công ty mở được máy để sửa chữa Ở đằng sau máy, có đường giây, mợt đường điện và mợt đường tín hiệu Người sử dụng tiếp xúc với mặt trước máy: (1) màn hình cảm ứng; (2) cửa sổ đĩa DVD; (3) cửa đưa thẻ vào Màn hình đới diện với người sử dụng Đầu đĩa DVD nằm bên màn hình, chỗ đưa thẻ vào nằm bên tay phải màn hình

AL2010 đưa những phiên bản mới, phần mềm phải có khả đáp ứng yêu cầu này với chi phí thấp

Hệ thống máy tự động được cung cấp một cơng ty khác, có tích hợp mợt thẻ có khả xử lý CPU và có cả chức lưu trữ dữ liệu giớng mợt máy tính Cơng ty có nhu cầu xây dựng mợt hệ thớng phần mềm nhúng AL2010 để thực được tất cả chức cho thuê đĩa DVD và cho phép bảo trì hệ thớng (chủ yếu là bảo trì từ xa) Các hoạt đợng bảo trì khơng liên quan đến dự án

Tuy nhiên, thẻ khách hàng lại được cung cấp mợt tổ chức khác Trong thẻ có một thẻ nhớ để lưu số thẻ, thông tin khách hàng và sớ tiền cịn lại thẻ

Giao diện khách hàng

Màn hình cảm ứng cho phép người sử dụng:

- Xem danh sách phim có máy, với phim có tóm tắt, poster, đạo diễn và diễn viên phim

- Xem danh sách phim mà công ty sở hữu và đặt trước ḿn (chức này cung cấp cho những người có thẻ khách hàng)

(181)

- Mượn một hoặc nhiều phim - Yêu cầu một hoặc nhiều phim - Nạp tiền vào thẻ

- Truy cập vào thông tin khác tài khoản khách hàng

Ngay người sử dụng đưa thẻ khách hàng vào, tên, sớ tài khoản và tình trạng thẻ phải được hiển thị Giao diện phải được khách hàng giao tiếp với máy giai đoạn nào (ví dụ lựa chọn phim hay tiến hành bước để mượn DVD) và cho phép quay trở lại bước trước

Danh sách phim mà công ty sở hữu là lớn, khách hàng tìm kiếm theo thứ tự ABC, theo loại phim, theo tên đạo diễn, tên diễn viên Khách hàng có thẻ hệ thớng u cầu một bộ phim nằm danh sách phim mà công ty sở hữu (danh sách này được cài đặt AL2010) Cơng ty cập nhật danh sách phim, công việc này được thực từ xa, một tháng một lần vào ban đêm

Một giao dịch được thực không 10 phút Nếu thời gian này, hệ thống sẽ tự ngắt

Giao diện của người quản trị máy

Người quản trị máy AL2010 truy nhập vào mợt giao diện riêng họ việc nhập vào mật mã, giao diện này cho phép:

- Rút hoặc nhiều đĩa từ máy - Bỏ vào máy một hoặc nhiều đĩa

- Thu được những thông tin tình trạng hoạt đợng máy (ví dụ: sớ lượng đĩa có máy, tỷ lệ yêu cầu bị huỷ bỏ, tỷ lệ thuê đĩa, tiền phạt, tiền thu được, sớ lượng đĩa bị hỏng, tình trạng hỏng )

- Xem xét yêu cầu khách hàng - Xem đĩa bị hỏng

- Xác định giá cho thuê đĩa (tùy thuộc vào loại phim, phim hay cũ )

Khi người quản trị kết nối với máy AL2010 (bằng mật mã), chức hệ thớng phải hiển thị và có thơng báo có đĩa tình trạng bị hỏng

Khách hàng thường xuyên

(182)

Hệ thớng khơng quản lý được sớ tiền cịn lại thẻ, nên trường hợp bị thẻ sẽ không được bồi thường tiền Điều này giúp cho một khách hàng sở hữu nhiều thẻ khác nhau, cho người khác mượn thẻ

Mỗi thẻ khách hàng có lưu những thơng tin mang tính lịch sử danh sách phim được mượn thẻ này (thơng tin này có ích để chủ sở hữu thẻ kiểm duyệt được thông tin trường hợp cho người khác mượn thẻ) Tuy nhiên chức này huỷ bỏ khách hàng thấy không cần thiết

Nếu khách hàng thuê 20 đĩa mợt tháng, họ sẽ có thêm 50.000 tiền khuyến mại vào tài khoản thẻ

Mượn đĩa phim

Khách hàng mượn đĩa thẻ khách hàng hoặc thẻ ngân hàng, tiền phải trả tuỳ thuộc vào thời gian mượn và tình trạng phim (phim phát hành hay phim cũ) Nhìn chung, giá tiền thuê đĩa sử dụng thẻ ngân hàng sẽ cao là sử dụng thẻ khách hàng

Đới với khách hàng có thẻ khách hàng mợt lần mượn tới đa là phim, với người sử dụng thẻ ngân hàng được mượn đĩa/1 lần

Trả đĩa

Khi trả đĩa, trước tiên khách hàng phải đưa vào thẻ khách hàng hoặc thẻ ngân hàng, sau đưa vào đĩa DVD Hệ thớng sẽ kiểm tra tình trạng đĩa Nếu đĩa tình trạng tốt, hệ thống sẽ trả lại tiền đặt cọc vào tài khoản, ngược lại khơng được trả lại tiền

Hệ thớng kiểm tra xem người mượn có mượn thời hạn đăng ký hay không Nếu quá, hệ thớng sẽ tính tốn tiền phạt tuỳ theo số ngày hạn Số tiền này sẽ bị trừ vào tiền đặt cọc

Số tiền thẻ khách hàng âm Khách hàng có ngày để nạp tiền vào thẻ, không tiền thẻ ngân hàng sẽ tự động bị trừ, trường hợp này sẽ phải thêm tiền phạt

Người mượn khai báo tình trạng hỏng cuả đĩa Trong trường hợp này, đĩa DVD sẽ không được mượn nữa và tình trạng hỏng hóc này sẽ được thơng báo đến kỹ thuật viên để xem xét, đĩa không bị hỏng, khách hàng sẽ được trả lại tiền Nếu mã đĩa bị hỏng, khách hàng phải thông báo đến người quản lý hệ thống (địa và số điện thoại được ghi máy AL2010)

1 Hãy xây dựng đội dự án và viết bản kế hoạch dự án để phát triển hệ thống phần mềm AL2010 Viết bản đặc tả phần mềm cho hệ thống AL2010

3 Với hệ thớng ta sử dụng mơ hình kiến trúc nào? Hãy phân tích và xây dưng mơ hình kiến trúc cho hệ thớng phần mềm AL2010

(183)

TÀI LIỆU THAM KHẢO

[1] Project Management Institute (2000) A guide to the Project Management Body of Knowledge 2000

Edition, Newtown Square, Pennsylvania USA

[2] Nguyễn Việt Hà (2007) Bài giảng nhập môn kỹ thuật phần mềm, Đại học Quốc gia Hà nội

[3] Philippe Lalanda (2008) Cours de Génie Logiciel Introduction, Université Joseph Fourier - Grenoble [4] Nguyễn Văn Vị, Nguyễn Việt Hà (2010) Giáo trình Kỹ nghệ phần mềm, NXB giáo dục Việt Nam, 2010

[5] Huỳnh Văn Đức, Đoàn Thiện Ngân (2004) Giáo trình nhập mơn UML, NXB Lao đợng Xã hợi [6] Thạc Bình Cường, Nguyễn Đức Mận (2011) Kiểm thử bảo đảm chất lượng phần mềm, NXB Đại học Bách Khoa Hà Nội

[7] Ngô Trung Việt (2005) Phương pháp luận quản lý dự án CNTT, NXB Khoa học kỹ thuật

[8] Dương Kiều Hoa, Tơn Thất Hịa An (2003) Phân tích thiết kế hệ thống thông tin với UML, NXB Đại học Huế

Định dạng
Số trang	183
Dung lượng	2,81 MB