Kỹ thuật phần mềm

hướng đối tượng và

cổ điển

Phiên bản thứ tám

 Stephen R. Cờ vua
Đại học Vanderbilt

KỸ THUẬT PHẦN MỀM HƯỚNG ĐỐI TƯỢNG VÀ CỔ ĐIỂN, PHIÊN BẢN THỨ TÁM

Được xuất bản bởi McGraw-Hill, một đơn vị kinh doanh của The McGraw-Hill Companies, Inc., 1221 Avenue
of the Americas, New York, NY 10020. Bản quyền © 2011 của The McGraw-Hill Companies, Inc. Mọi quyền
được bảo lưu. Các phiên bản trước © 2007, 2005 và 2002. Không được sao chép hoặc phân phối bất kỳ phần nào
của ấn phẩm này dưới bất kỳ hình thức hoặc phương tiện nào hoặc được lưu trữ trong cơ sở dữ liệu hoặc hệ
thống truy xuất mà không có sự đồng ý trước bằng văn bản của The McGraw-Hill Companies, Inc. ., bao gồm
nhưng không giới hạn ở bất kỳ mạng nào hoặc nơi lưu trữ hoặc truyền tải điện tử khác hoặc phát sóng để đào tạo
từ xa.

Một số phụ kiện, bao gồm linh kiện điện tử và máy in, có thể không được cung cấp cho khách hàng bên
ngoài Hoa Kỳ.

Cuốn sách này được in trên giấy không chứa axit.

1 2 3 4 5 6 7 8 9 0 DOC/DOC 1 0 9 8 7 6 5 4 3 2 1 0

ISBN 978-0-07-337618-9
Mã số 0-07-337618-3

Phó chủ tịch kiêm tổng biên tập:Marty Long

Nhà xuất bản:Raghothaman Srinivasan
Phó Chủ tịch EDP & Dịch vụ Xuất bản Trung ương:Kimberly Meriwether David
Biên tập viên phát triển:Laura Neyens
Quản lý tiếp thị cấp cao:Curt Reynolds
Quản lý dự án:Melissa M. Leick
Người mua:Kính gửi Kudronowicz
Điều phối viên thiết kế:Brenda A. Rowwes
Thiết kế bìa:Studio Montage, St. Louis, Missouri
Ảnh bìa: ©Hình ảnh đĩa ảnh/Getty
Nhà soạn nhạc:Glyph quốc tế
Kiểu chữ:12/10 Thời La Mã
Máy in:R. R. Donnelley

Tất cả phần ghi công xuất hiện trên trang hoặc ở cuối cuốn sách được coi là phần mở rộng của trang bản quyền.

Dữ liệu Biên mục của Thư viện Quốc hội

Cờ vua, Stephen R.
Kỹ thuật phần mềm cổ điển và hướng đối tượng / Stephen R. Schach. —
tái bản lần thứ 8.
P. cm.
ISBN-13: 978-0-07-337618-9 (giấy kiềm)
ISBN-10: 0-07-337618-3 (giấy kiềm)
1. Kỹ thuật phần mềm. 2. Lập trình hướng đối tượng (Máy tính
khoa học) 3. UML (Khoa học máy tính) 4. C++ (Ngôn ngữ chương trình máy tính) I.
Tiêu đề.
QA76.758.S318 2010
005.1'17—dc22
2010020995

www.mhhe.com

Gửi Jackson và Mikaela

Sau đây là các nhãn hiệu đã đăng ký:
doanh nghiệp Đối tượng C
ADF Excel Mục tiêu-C
Nhà phân tích/Nhà thiết kế Firefox Thư viện
Con kiến Tập trung ObjectWindows
Apache Ford 1-800-flowers.com
Quả táo Thư viện lớp nền tảng Lời tiên tri
NHƯ/400 FoxBASE Bộ phần mềm dành
AT&T GCC cho nhà phát triển
Bộ sản phẩm Hewlett Packard Oracle OS/360
Bachman Phòng thí IBM HĐH/370
nghiệm Bell IMS/360 HĐH/VS2
Borland Số liệu mã nguồn Jackpot Palm Pilot
Với Bugz Java Parasoft
Mô hình trưởng thành về JBuilder Ghi chú sau đó
năng lực Chrome JUnit Xây dựng quyền lực
ClearCase Linux Tiếp đầu ngữ
ClearQuest Hoa sen 1-2-3 TRƯỚC
CMM Công nghệ Lucent Dự án
Ca cao MacApp PureCoverage
Cô-ca Cô-la macintosh PVCS
CORBA Hộp công cụ Macintosh QArun
đơn vị Cpp Dự án Mac Hợp lý
CVS Microsoft Yêu cầu chuyên nghiệp
DB2 họa tiết sử thi ca
nhật thực MS-DOS Hoa hồng
linh kiện điện tử MVS/360 SBC Communications
Emeraude Tự nhiên SilkTest
Máy chủ điện tử Netscape SẬP
JavaBeans dành cho Thời báo New York Phần mềm thông qua
 Pictures Solaris VAX Windows 2000
NguồnAn toàn Thư viện thành phần trực Windows NT
Trạm SPARC quan Visual C++ Từ
Mặt trời Trực quan J++ X11
Doanh nghiệp mặt trời VM/370 Xrunner
Hệ thống vi mô mặt trời VMS XUnit
Sun ONE Studio Tạp chí Phố Wall Đĩa nén
Kiến trúc hệ thống WebSphere Mã Bưu Chính
Cùng nhau Win32 z10
UNIX Windows 95
2.1Phát triển phần mềm trong lý thuyết

Nội dung 372.2Nghiên cứu điển hình nhỏ về Winburg

382.3Bài học từ nghiên cứu điển hình nhỏ ở
Winburg 42

Giả vờ xiii

Chương 1
Phạm vi của Công nghệ phần mềm 1
2.4Nghiên cứu tình huống nhỏ về máy kéo Teal
Mục tiêu học tập 1 422,5Lặp lại và tăng dần 432.6Xem lại nghiên
1.1Khía cạnh lịch sử 2 cứu điển hình nhỏ về Winburg 472.7Rủi ro và các
1.2Khía cạnh kinh tế 5 khía cạnh khác của việc lặp lại và tăng dần 48
1.3Khía cạnh bảo trì 6 2,8Quản lý việc lặp lại và
1.3.1 Quan điểm cổ điển và hiện đại Tăng 51
Bảo trì 9 2.9Các mô hình vòng đời khác 522.9.1 Mô hình
1.3.2 Tầm quan trọng của việc giao hàng sau vòng đời mã hóa và sửa lỗi 52 2.9.2 Mô
Bảo trì 10 hình vòng đời thác nước 53
1.4Các khía cạnh yêu cầu, phân tích và thiết 2.9.3 Vòng đời tạo mẫu nhanh
kế 12 Mẫu 55
1,5Các khía cạnh phát triển nhóm 151.6Tại 2.9.4 Mô hình vòng đời nguồn mở 56 2.9.5
sao không có kế hoạch Giai đoạn 161.7Tại sao Quy trình linh hoạt 59
không có giai đoạn thử nghiệm 161.8Tại sao 2.9.6 Mô hình vòng đời đồng bộ hóa và ổn
không có tài liệu Giai đoạn 17 định 62
1.9Mô hình hướng đối tượng 181.10Mô 2.9.7 Mô hình vòng đời xoắn ốc 62
hình hướng đối tượng theo quan điểm 22 2.10So sánh các mô hình vòng đời 66 Đánh giá
1.11Thuật ngữ 23 chương 67
1.12Vấn đề đạo đức 26 Để đọc thêm 68
Ôn tập chương 27 Các thuật ngữ chính 69
Để đọc thêm 27 Vấn đề 69
Các thuật ngữ chính 28 Tài liệu tham khảo 70
Vấn đề 29
Tài liệu tham khảo 30 Chương 3
Quy trình phần mềm 74
PHẦN A
Mục tiêu học tập 74
KỸ THUẬT PHẦN MỀM
3.1Quá trình thống nhất 76
KHÁI NIỆM 35 3.2Lặp lại và tăng dần
trong Hướng đối tượng
chương 2 Mô hình 76
Mô hình vòng đời phần mềm 37 3.3Yêu cầu Quy trình làm việc 783,4Quy
trình phân tích 80
Mục tiêu học tập 37
 3,5Quy trình thiết kế 82
3.6Quy trình thực hiện 833,7Quy trình kiểm
tra 84 Chương 5
3.7.1 Thành phần yêu cầu 84 Công cụ giao dịch 124
3.7.2 Hiện vật phân tích 84
3.7.3 Hiện vật thiết kế 85 Mục tiêu học tập 1245.1Tinh chỉnh từng bước
3.7.4 Các tạo phẩm triển khai 85 1245.1.1 Nghiên cứu trường hợp nhỏ cải tiến từng
3,8Bảo trì sau giao hàng 87TRONG bước 125
chúng tôiNội dung 5.2Phân tích Chi phí-Lợi ích 1305.3Chia
để trị 1325,4Tách biệt mối quan tâm
1325,5Số liệu phần mềm 133
3,9Hưu trí 88
5.6TRƯỜNG HỢP 134
3.10Các giai đoạn của quá trình thống nhất
5,7Phân loại CASE 1355,8Phạm vi
883.10.1 Giai đoạn khởi động 89 của VỤ 137
3.10.2 Giai đoạn xây dựng 91 5,9Phiên bản phần mềm 141
3.10.3 Giai đoạn xây dựng 92
5.9.1 Sửa đổi 141
3.10.4 Giai đoạn chuyển tiếp 92
5.9.2 Các biến thể 142
3.11Mô hình vòng đời một chiều và hai chiều 92
5.10Kiểm soát cấu hình 1435.10.1 Kiểm
3.12Cải tiến quy trình phần mềm 943.13Mô soát cấu hình
hình trưởng thành năng lực 953.14Các sáng kiến
trong thời gian sau khi giao hàng
​cải tiến quy trình phần mềm khác 98
Bảo trì 145
3,15Chi phí và lợi ích của việc cải tiến quy trình
5.10.2 Đường cơ sở 145
phần mềm 99
5.10.3 Kiểm soát cấu hình trong quá trình
Ôn tập chương 101
Phát triển 146
Để đọc thêm 102
5.11Công cụ xây dựng 146
Các thuật ngữ chính 102
5.12Tăng năng suất nhờ công nghệ CASE
Vấn đề 103
147
Tài liệu tham khảo 104
Ôn tập chương 149
Để đọc thêm 149 Các thuật ngữ chính
Chương 4 150
Đội 107 Vấn đề 150
Mục tiêu học tập 107 Tài liệu tham khảo 151
4.1Tổ chức đội 107
4.2Cách tiếp cận của Nhóm Dân chủ 1094.2.1 Chương 6
Phân tích của Đội Dân chủ Kiểm tra 154
Tiếp cận 110
4.3Nhóm lập trình trưởng cổ điển Phương Mục tiêu học tập 1546.1Vấn đề chất
pháp tiếp cận 110 lượng 155
6.1.1 Đảm bảo chất lượng phần mềm 156 6.1.2 Độc
4.3.1Thời báo New YorkDự án 112 4.3.2 Tính
không thực tế của phương pháp tiếp cận của lập quản lý 1566.2Kiểm tra không dựa trên thực
nhóm lập trình viên trưởng cổ điển 113 thi 1576.2.1 Hướng dẫn 158
4.4Ngoài Lập trình viên trưởng và Nhóm 6.2.2 Quản lý hướng dẫn 158
Dân chủ 113 6.2.3 Kiểm tra 159
4,5Đồng bộ hóa và ổn định nhóm 1174.6Nhóm 6.2.4 So sánh các cuộc kiểm tra
thực hiện quy trình linh hoạt 1184,7Nhóm lập trình và Hướng dẫn 161
Nội dungvii
nguồn mở 1184,8Mô hình trưởng thành năng lực
con người 1194,9Lựa chọn tổ chức nhóm phù hợp
120 6.2.5 Điểm mạnh và điểm yếu của
Ôn tập chương 121
Để đọc thêm 121
Các thuật ngữ chính 122 7.4Đóng gói dữ liệu 199
Vấn đề 122 Đánh giá 162
Tài liệu tham khảo 122 6.2.6 Số liệu kiểm tra 162
 6.3Kiểm tra dựa trên thực thi
1626,4Những gì nên được kiểm tra?
1636.4.1 Tiện ích 164
6.4.2 Độ tin cậy 164
6.4.3 Độ bền 165
6.4.4 Hiệu suất 165
6.4.5 Tính đúng đắn 166
6,5Kiểm tra và chứng minh tính chính xác
1676.5.1 Ví dụ về Chứng minh tính đúng đắn 167 6.5.2
Nghiên cứu tình huống nhỏ về chứng minh tính đúng đắn
171 6.5.3 Chứng minh tính đúng đắn và phần mềm
Kỹ thuật 172
6,6Ai nên thực hiện kiểm thử dựa trên thực thi?
175
6,7Khi dừng kiểm tra 176
Xem lại chương 176
Để đọc thêm 177
Các thuật ngữ chính 177
Vấn đề 178
Tài liệu tham khảo 179
Chương 7
Từ mô-đun đến đối tượng 183
Mục tiêu học tập 183
7.1Mô-đun là gì? 183
7.2Sự gắn kết 187
7.2.1 Sự gắn kết ngẫu nhiên 187
7.2.2 Sự gắn kết logic 188
7.2.3 Sự gắn kết tạm thời 189
7.2.4 Sự gắn kết thủ tục 189
7.2.5 Sự gắn kết trong giao tiếp 190
7.2.6 Sự gắn kết chức năng 190
7.2.7 Sự gắn kết thông tin 191
7.2.8 Ví dụ về sự gắn kết 191
7.3Khớp nối 192
7.3.1 Khớp nối nội dung 192
7.3.2 Khớp nối chung 193
7.3.3 Khớp nối điều khiển 195
7.3.4 Khớp nối tem 195
7.3.5 Khớp nối dữ liệu 196
7.3.6 Ví dụ ghép nối 197
7.3.7 Tầm quan trọng của khớp nối 198
7.4.1 Đóng gói dữ liệu và
Phát triển 201
7.4.2 Đóng gói dữ liệu và
Bảo trì 202
7,5Các kiểu dữ liệu trừu tượng 207
7,6Ẩn thông tin 209
7,7Đối tượng 211
7,8Kế thừa, đa hình và liên kết động 215
7,9Mô hình hướng đối tượng 217 Ôn lại
chương 220
Để đọc thêm 221
Các thuật ngữ chính 221
Vấn đề 221
Tài liệu tham khảo 222
Chương 8
Khả năng tái sử dụng và tính di động 225
Mục tiêu học tập 225
8.1Khái niệm tái sử dụng 226
8.2Những trở ngại cho việc tái sử dụng 228
8.3Nghiên cứu trường hợp tái sử dụng 229
8.3.1 Hệ thống tên lửa Raytheon
Sư đoàn 230
8.3.2 Cơ quan Vũ trụ Châu Âu 231
8,4Đối tượng và tái sử dụng 232
8,5Tái sử dụng trong quá trình thiết kế và
Thực hiện 232
8.5.1 Tái sử dụng thiết kế 232
8.5.2 Khung ứng dụng 234
8.5.3 Mẫu thiết kế 235
8.5.4 Kiến trúc phần mềm 236
8.5.5 Phần mềm dựa trên thành phần
Kỹ thuật 237
8,6Thông tin thêm về Mẫu thiết kế
2378.6.1 Nghiên cứu điển hình nhỏ
của FLIC 238
8.6.2Bộ chuyển đổiMẫu thiết kế 239
8.6.3CầuMẫu thiết kế 240
8.6.4Trình vòng lặpMẫu thiết kế 241
8.6.5Nhà máy trừu tượngMẫu thiết kế
2418,7Danh mục mẫu thiết kế 2458,8Điểm mạnh
và điểm yếu của các mẫu thiết kế 247
8,9Tái sử dụng và World Wide Web 248
viiiiNội dung
8.10Tái sử dụng và bảo trì sau giao hàng
2498.11Tính di động 250
8.11.1 Sự không tương thích về phần cứng 250
8.11.2 Hệ điều hành
Sự không tương thích 251
8.11.3 Phần mềm số
Sự không tương thích 251
8.11.4 Sự không tương thích của trình biên dịch 253
8.12Tại sao tính di động? 255
8.13Các kỹ thuật để đạt được tính di động
2568.13.1 Phần mềm hệ thống di động 257
8.13.2 Phần mềm ứng dụng di động 257
8.13.3 Dữ liệu di động 258
8.13.4 Kiến trúc hướng mô hình 259
Xem lại chương 259
Để đọc thêm 260
Các thuật ngữ chính 261
Vấn đề 261
Tài liệu tham khảo 263
 10.11Kiểm thử dựa trên thực thi và không
CHƯƠNG 9 thực thi 309
10.12Tính mô-đun 310
Lập kế hoạch và Dự toán 268
10.13Tái sử dụng 310
Mục tiêu học tập 268 10.14Kế hoạch quản lý dự án phần mềm 310
9.1Lập kế hoạch và quy trình phần mềm Đánh giá chương 311
2689,2Ước tính thời gian và chi phí 2709.2.1 Các Các thuật ngữ chính 311
thước đo về kích thước của sản phẩm 272 9.2.2 Kỹ thuật Vấn đề 312
ước tính chi phí 275 9.2.3 COCOMO trung cấp 278
9.2.4 COCOMO II 281 chương 11
9.2.5 Thời gian và chi phí theo dõi Yêu cầu 313
Ước tính 282
9,3Các thành phần của Kế hoạch quản lý Mục tiêu học tập 313
dự án phần mềm 282 11.1Xác định những gì khách hàng cần
9,4Khung kế hoạch quản lý dự án phần 31311.2Tổng quan về Quy trình yêu cầu 314
mềm 284 11.3Hiểu tên miền 31511.4Mô hình kinh
9,5Kế hoạch quản lý dự án phần mềm IEEE doanh 316
286 11.4.1 Phỏng vấn 316
9,6Lập kế hoạch Kiểm tra 288 11.4.2 Các kỹ thuật khác 317
9,7Lập kế hoạch dự án hướng đối tượng 11.4.3 Ca sử dụng 318
Nội dungix
2899,8Yêu cầu đào tạo 290
9,9Tiêu chuẩn tài liệu 2919.10CASE
Công cụ lập kế hoạch và 11,5Yêu cầu ban đầu 319
Ước tính 292
9.11Kiểm thử Kế hoạch quản lý dự án phần mềm
292 12.7Máy trạng thái hữu hạn 376
11.6Hiểu biết ban đầu về tên miền: Nghiên cứu
điển hình 320 của Quỹ MSG11.7Mô hình kinh
Xem lại chương 292 doanh ban đầu: Nghiên cứu điển hình của Quỹ
Để đọc thêm 292 MSG 322
Các thuật ngữ chính 293 11.8Yêu cầu ban đầu: Nghiên cứu điển
Vấn đề 294 hình của Quỹ MSG 326
Tài liệu tham khảo 295 11.9Tiếp tục quy trình công việc yêu cầu: Nghiên
cứu điển hình 328 của Quỹ MSG11.10Sửa đổi
các yêu cầu: Nghiên cứu điển hình của Quỹ MSG
PHẦN B 330
QUY TRÌNH LÀM VIỆC CỦA 11.11Quy trình thử nghiệm: Nghiên cứu điển hình
VÒNG ĐỜI PHẦN MỀM 299 của Quỹ MSG 338
11.12Các yêu cầu cổ điển
Chương 10 Giai đoạn 347
Tài liệu chính từ Phần A 301 13/11Tạo nguyên mẫu nhanh 348
14/11Yếu tố con người 349
Mục tiêu học tập 301 11.15Tái sử dụng Nguyên mẫu nhanh
10.1Phát triển phần mềm: Lý thuyết và thực 35116/11Công cụ CASE cho quy trình làm
hành 301 việc yêu cầu 353
10.2Lặp lại và tăng dần 30210.3Quy trình 17/11Số liệu cho Quy trình làm việc
thống nhất 306 Yêu cầu 353
10,4Tổng quan về quy trình làm việc 307 18/11Những thách thức của yêu cầu
10,5Đội 307 Quy trình công việc 354
10.6Phân tích Chi phí-Lợi ích 308 Đánh giá chương 355
10.7Số liệu 308 Để đọc thêm 356
10.8TRƯỜNG HỢP 308 Các thuật ngữ chính 357
10.9Phiên bản và cấu hình 30910.10Thuật Nghiên cứu tình huống Các thuật ngữ
ngữ kiểm tra 309 chính 357 Vấn đề 357
Tài liệu tham khảo 358
Chương 12
Phân tích cổ điển 360
Mục tiêu học tập 360
12.1Tài liệu đặc tả 36012.2Thông số không
chính thức 36212.2.1 Nghiên cứu trường hợp nhỏ
chứng minh tính chính xác Redux 363
12.3Phân tích hệ thống có cấu trúc 36412.3.1
Hộp đựng nhỏ ở cửa hàng phần mềm
của Sally
Nghiên cứu 364
12,4Phân tích hệ thống có cấu trúc: Nghiên cứu
điển hình của Quỹ MSG 372
12,5Các kỹ thuật bán chính thức khác
37312.6Mô hình hóa mối quan hệ thực thể
374
12.7.1 Máy trạng thái hữu hạn: Nghiên cứu
trường hợp bài toán thang máy 378
12.8Mạng Petri 382
12.8.1 Mạng Petri: Nghiên cứu trường hợp bài 13.14Trích xuất các lớp kiểm soát: Nghiên cứu
toán thang máy 385
12.9Từ 387
12.9.1 Z: Trường hợp sự cố thang máy
Nghiên cứu 388
12.9.2 Phân tích Z 390
12.10Các kỹ thuật trang trọng khác
39212.11So sánh các kỹ thuật phân tích cổ
điển 392
12.12Kiểm tra trong quá trình phân tích cổ điển
39313.12Công cụ CASE cho phân tích cổ điển
39412.14Số liệu cho phân tích cổ điển
39512.15Kế hoạch quản lý dự án phần mềm:
Nghiên cứu điển hình 395 của Quỹ MSG
16/12Những thách thức của phân tích cổ điển
396 Xem lại chương 396
Để đọc thêm 397
Các thuật ngữ chính 398
Nghiên cứu điển hình Các thuật ngữ chính 398
Vấn đề 398
Tài liệu tham khảo 400
Chương 13
Phân tích hướng đối tượng 404
Mục tiêu học tập 404
13.1Quy trình phân tích 405
13.2Trích xuất các lớp thực thể 40613.3Phân
tích hướng đối tượng: Nghiên cứu trường hợp
bài toán thang máy 407
13,4Mô hình chức năng: Nghiên cứu
trường hợp bài toán thang máy 407
13,5Mô hình hóa lớp thực thể: Nghiên cứu
điển hình về vấn đề thang máy 410
13.5.1 Trích xuất danh từ 411
13.5.2 Thẻ CRC 413
13.6Mô hình động: Nghiên cứu trường hợp bài
toán thang máy 414
13,7Quy trình kiểm thử: Phân tích hướng
đối tượng 417
13,8Trích xuất các lớp ranh giới và kiểm soát
424
xNội dung
13.9Mô hình chức năng ban đầu: Nghiên cứu
điển hình của Quỹ MSG 425
13.10Sơ đồ lớp ban đầu: Nghiên cứu điển
hình của Quỹ MSG 428
13.11Mô hình động ban đầu: Nghiên cứu điển
hình 430 của Quỹ MSG
13.12Sửa đổi các lớp thực thể: Nghiên cứu
điển hình của Quỹ MSG 432
13.13Trích xuất các lớp ranh giới: Nghiên cứu
trường hợp 434 của Quỹ MSG
điển hình của MSG Foundation 435
13:15Hiện thực hóa ca sử dụng: Nghiên
cứu điển hình của Quỹ MSG 435
13.15.1Ước tính số tiền có sẵn
trong tuầnTrường hợp sử dụng 436
13.15.2Quản lý một tài sảnTrường
hợp sử dụng 442 13.15.3Cập nhật chi
phí hoạt động hàng năm ước tính
Trường hợp sử dụng446
13.15.4Tạo một báo cáoTrường hợp sử dụng
44913.16Tăng cường sơ đồ lớp: Nghiên cứu điển
hình của Quỹ MSG 454
13.17Quy trình kiểm tra: Nghiên cứu điển hình
của Quỹ MSG 456
13.18Tài liệu đặc tả trong Quy trình thống nhất 456
13.19Thông tin thêm về các tác nhân và
trường hợp sử dụng 45713:20Công cụ CASE
cho quy trình phân tích hướng đối tượng 458
13.21Số liệu cho quy trình phân tích hướng đối
tượng 459
13.22Những thách thức của quy trình phân
tích hướng đối tượng 459
Đánh giá chương 460
Để đọc thêm 461
Các thuật ngữ chính 462
Vấn đề 462
Tài liệu tham khảo 463
Chương 14
Thiết kế 465
Mục tiêu học tập 465
14.1Thiết kế và trừu tượng 466
14.2Thiết kế hướng hoạt động 466
14.3Phân tích luồng dữ liệu 467
14.3.1 Nghiên cứu trường hợp nhỏ Đếm từ
468 14.3.2 Phần mở rộng phân tích luồng dữ liệu
47314.4Phân tích giao dịch 473
14,5Thiết kế hướng dữ liệu 475
14.6Thiết kế hướng đối tượng 47614,7Thiết
kế hướng đối tượng: Nghiên cứu trường hợp
bài toán thang máy 477
14.8Thiết kế hướng đối tượng: Nghiên cứu
điển hình của Quỹ MSG 481
14.9Quy trình thiết kế 483
14.10Quy trình kiểm tra: Thiết kế 48714.11Quy
trình thử nghiệm: Nghiên cứu điển hình của Quỹ
MSG 488
14.12Kỹ thuật chính thức cho thiết kế chi tiết
48814.13Kỹ thuật thiết kế thời gian thực
48814.14Công cụ CASE cho thiết kế 49014:15Số
liệu cho thiết kế 490
14.16Những thách thức của quy trình thiết kế 491
Xem lại chương 492
Để đọc thêm 493
Các thuật ngữ chính 493
Vấn đề 494
Tài liệu tham khảo 495
Chương 15
Thực hiện 498
Mục tiêu học tập 498
15.1Lựa chọn ngôn ngữ lập trình 49815.2Ngôn
ngữ thế hệ thứ tư 50115.3Thực hành lập trình tốt
50415.3.1 Sử dụng nhất quán và có ý nghĩa
Tên biến 504
15.3.2 Vấn đề tự ghi chép
Mã 505
15.3.3 Sử dụng tham số 507
15.3.4 Bố cục mã để tăng
Khả năng đọc 507
15.3.5 Lồng nhaunếu nhưBáo cáo 507
15,4Tiêu chuẩn mã hóa 509
15,5Tái sử dụng mã 510
15,6Tích hợp 510
15.6.1 Tích hợp từ trên xuống 511
15.6.2 Tích hợp từ dưới lên 513
15.6.3 Tích hợp bánh sandwich 513
15.6.4 Tích hợp hướng đối tượng
Sản phẩm 514
15.6.5 Quản lý tích hợp 515
15,7Quy trình thực hiện 51615,8Quy trình thực
hiện: Nghiên cứu điển hình 516 của Quỹ MSG
15,9Quy trình kiểm tra: Thực hiện 51615.10Lựa
chọn trường hợp thử nghiệm 517
15.10.1 Thử nghiệm để xác định các cation so với
Kiểm tra mã 517
15.10.2 Tính khả thi của việc kiểm tra
Thông số cation 517
15.10.3 Tính khả thi của việc kiểm tra Mã 51815.11Kỹ
thuật kiểm tra đơn vị hộp đen 52015.11.1 Kiểm tra
tương đương và phân tích giá trị biên 521
15.11.2 Kiểm tra chức năng 522
15.12Các trường hợp kiểm thử hộp đen:
Nghiên cứu điển hình 523 của Quỹ MSG
15.13Kỹ thuật kiểm tra đơn vị hộp thủy tinh
52515.13.1 Kiểm tra cấu trúc: Tuyên bố,
Phạm vi nhánh và đường dẫn 526
15.13.2 Số liệu độ phức tạp 527
15.14Hướng dẫn và kiểm tra mã 52815.15So sánh
các kỹ thuật kiểm tra đơn vị 52815.16Phòng sạch
529
15.17Các vấn đề tiềm ẩn khi kiểm tra đối
tượng 530
15.18Các khía cạnh quản lý của thử nghiệm đơn vị
53315.19Khi nào nên thực hiện lại thay vì gỡ lỗi
một tạo phẩm mã 533
15h20Kiểm tra tích hợp 535
15,21Kiểm tra sản phẩm 535
15,22Kiểm tra chấp nhận 536
15,23Quy trình thử nghiệm: Nghiên cứu điển hình
của Quỹ MSG 537
15,24CASE Công cụ thực hiện 53715.24.1
Công cụ CASE để hoàn thiện
Quy trình phần mềm 538
15.24.2 Phát triển tích hợp
Môi trường 538
15.24.3 Môi trường kinh doanh
Ứng dụng 539
15.24.4 Cơ sở hạ tầng công cụ công cộng 540
15.24.5 Các vấn đề tiềm ẩn với
Môi trường 540
Nội dungxi
15:25Công cụ CASE cho quy trình kiểm tra
54015,26Số liệu cho quy trình thực hiện 541
15,27Những thách thức trong quá trình
thực hiện 542
Đánh giá chương 542
Để đọc thêm 543
Các thuật ngữ chính 544
Vấn đề 545
Tài liệu tham khảo 547
Chương 16
 Bảo trì sau giao hàng 551 17,8Sơ đồ hoạt động 583
17,9Gói 585
Mục tiêu học tập 551 17.10Sơ đồ thành phần 58617.11Sơ đồ
16.1Phát triển và Bảo trì 55116.2Tại sao cần triển khai 58617.12Xem xét sơ đồ UML
phải bảo trì sau giao hàng 553 58717.13UML và lặp lại 587
16.3Lập trình viên bảo trì sau giao hàng Đánh giá chương 587
cần những gì? 553 Để đọc thêm 588 Các thuật ngữ
16,4Nghiên cứu tình huống nhỏ về bảo trì chính 588
sau giao hàng 555 Vấn đề 588
16,5Quản lý sau giao hàng Tài liệu tham khảo 589
Bảo trì 557
16.5.1 Báo cáo lỗi 557 Chương 18
16.5.2 Cho phép Thay đổi đối với Công nghệ mới nổi 590
Sản phẩm 558
16.5.3 Đảm bảo khả năng bảo trì 559 Mục tiêu học tập 59018.1Công nghệ hướng
16.5.4 Vấn đề bảo trì lặp đi lặp lại theo khía cạnh 59118.2Công nghệ dựa trên
55916,6Bảo trì phần mềm hướng đối tượng 560 mô hình 59318.3Công nghệ dựa trên thành
16,7Kỹ năng duy trì sau sinh so với kỹ năng phần 59418,4Công nghệ hướng dịch vụ
phát triển 563 59418,5So sánh hướng dịch vụ và
16,8Kỹ thuật đảo ngược 563 Công nghệ dựa trên thành phần
16,9Kiểm tra trong quá trình sau giao hàng 59518,6Máy tính xã hội 596
Bảo trì 564 18,7Kỹ thuật web 596
16.10Công cụ CASE cho sau giao hàng
Bảo trì 565
16.11Số liệu cho sau giao hàng 18,8Công nghệ đám mây 597
Bảo trì 566 18,9Web 3.0 598
16.12Bảo trì sau giao hàng: Nghiên cứu điển 18.10Bảo mật máy tính 598
hình của Quỹ MSG 566 18.11Kiểm tra mẫu 598
16.13Những thách thức sau giao hàng 18.12Hiện Tại Và Tương Lai 599
Bảo trì 566 Đánh giá chương 599
Đánh giá chương 566 Để đọc thêm 599
Để đọc thêm 567 Các thuật ngữ chính 599
xiiNội dung Tài liệu tham khảo 600

Các thuật ngữ chính 567 Thư mục 601

Vấn đề 567 Phụ lục A
Tài liệu tham khảo 568 Dự án kỳ hạn: Người nghiện sôcôla
Ẩn danh 627
Chương 17 Phụ lục B
Thông tin thêm về UML 571 Tài nguyên kỹ thuật phần mềm
630Phụ lục C
Mục tiêu học tập 57117.1UML Quy trình yêu cầu: Nghiên cứu điển hình của
làKhôngmột phương pháp luận 57117.2Sơ Quỹ MSG 632
đồ lớp 572 Phụ lục D
17.2.1 Tổng hợp 573 Phân tích hệ thống có cấu trúc: Nghiên
17.2.2 Số bội 574 cứu điển hình của Quỹ MSG 633
17.2.3 Thành phần 575 Phụ lục E
17.2.4 Khái quát hóa 576 Quy trình phân tích: Nghiên cứu điển
17.2.5 Hiệp hội 576 hình của Quỹ MSG 636
17.3Ghi chú 577 Phụ lục F
17,4Sơ đồ ca sử dụng Kế hoạch quản lý dự án phần mềm: Nghiên
57717,5Khuôn mẫu 577 cứu điển hình 637 của Quỹ MSG
17,6Sơ đồ tương tác 57917,7Biểu Phụ lục G
đồ trạng thái 581 Quy trình thiết kế: Nghiên cứu điển
hình của Quỹ MSG 642 Phụ lục J
Phụ lục H Quy trình kiểm tra: Nghiên cứu điển
Quy trình triển khai: Nghiên cứu điển hình của hình của Quỹ MSG 649
MSG Foundation (Phiên bản C++) 647
Phụ lục I
Chỉ số tác giả 651
Quy trình triển khai: Nghiên cứu điển hình của
MSG Foundation (Phiên bản Java) 648 Mục lục chủ đề 654

Lời nói đầu

Hầu hết mọi chương trình giảng dạy về khoa học máy tính và kỹ thuật máy tính hiện
nay đều bao gồm một dự án phát triển phần mềm theo nhóm bắt buộc. Trong một số
trường hợp, dự án chỉ kéo dài một học kỳ hoặc một quý, nhưng dự án phát triển phần mềm
dựa trên nhóm kéo dài một năm đang nhanh chóng trở thành tiêu chuẩn.
Trong một thế giới lý tưởng, mọi sinh viên sẽ hoàn thành một khóa học về công nghệ
phần mềm trước khi bắt đầu dự án dựa trên nhóm của mình (“chương trình giảng dạy hai
giai đoạn”). Tuy nhiên, trên thực tế, nhiều sinh viên phải bắt đầu dự án của mình giữa
chừng trong khóa học công nghệ phần mềm, hoặc thậm chí ngay khi bắt đầu khóa học
(“chương trình giảng dạy song song”).
Như được giải thích trong phần tiếp theo, cuốn sách này được tổ chức theo cách có thể sử
dụng được cho cả hai chương trình giảng dạy.

Phiên bản thứ tám được tổ chức như thế nào

Cuốn sách gồm hai phần chính: Phần B hướng dẫn sinh viên cách phát triển một sản
phẩm phần mềm; Phần A cung cấp nền tảng lý thuyết cần thiết cho Phần B. 18 chương
được tổ chức như sau:

Chương 1 Giới thiệu về công nghệ phần mềmPhần AChương 2 đến 9 Khái niệm công nghệ
phần mềm
Phần BChương 10 đến 17 Kỹ thuật công nghệ phần mềm Chương 18 Các công nghệ mới
nổi

Chương 10 mới. Nó bao gồm phần tóm tắt nội dung chính của Phần A. Khi tuân theo
chương trình giảng dạy hai giai đoạn, người hướng dẫn sẽ dạy Phần A đầu tiên và sau đó
là Phần B (bỏ qua Chương 10 vì nội dung của Chương 10 sẽ được trình bày sâu trong
phần này). Phần A). Đối với chương trình giảng dạy song song, trước tiên người hướng
dẫn sẽ dạy Phần B (để học sinh có thể bắt đầu dự án của mình càng sớm càng tốt), sau đó
là Phần A. Tài liệu của Chương 10 giúp học sinh hiểu Phần B mà không cần dạy trước
Phần A. .
Cách tiếp cận sau này có vẻ phản trực giác: Chắc chắn lý thuyết phải luôn được dạy trước
khi thực hành. Trên thực tế, các vấn đề về chương trình giảng dạy đã buộc nhiều giảng
viên đã sử dụng ấn bản thứ bảy của cuốn sách này phải dạy tài liệu của Phần B trước Phần
A. Điều đáng ngạc nhiên là họ hài lòng nhất với kết quả đạt được. Họ báo cáo rằng sinh
viên của họ đánh giá cao hơn tài liệu lý thuyết của Phần A nhờ công việc dự án của họ.
Nghĩa là, công việc dự án theo nhóm làm cho sinh viên dễ tiếp thu và hiểu rõ hơn về các
khái niệm lý thuyết làm nền tảng cho công nghệ phần mềm.
Chi tiết hơn, tài liệu của ấn bản thứ tám có thể được giảng dạy theo hai cách sau: 1.
 Chương trình giảng dạy hai giai đoạn
Chương 1 (Nhập môn công nghệ phần mềm)
Phần A Chương 2 đến 9 (Khái niệm công nghệ phần mềm)
Phần B Chương 11 đến 17 (Kỹ thuật công nghệ phần mềm)
Chương 18 (Các công nghệ mới nổi)
Sau đó, sinh viên sẽ bắt đầu các dự án theo nhóm của mình trong học kỳ hoặc quý tiếp theo.

xiii
xivLời nói đầu

2. Chương trình giảng dạy song song

Chương 1 (Nhập môn công nghệ phần mềm)
Chương 10 (Tài liệu chính của Phần A)
Bây giờ, sinh viên bắt đầu các dự án theo nhóm của mình, song song với việc nghiên cứu tài
liệu của Phần B.
Phần B Chương 11 đến 17 (Kỹ thuật công nghệ phần mềm)
Phần A Chương 2 đến 9 (Khái niệm công nghệ phần mềm)
Chương 18 (Các công nghệ mới nổi)

Các tính năng mới của phiên bản thứ tám

•Cuốn sách đã được cập nhật xuyên suốt.
•Tôi đã thêm hai chương mới. Như đã giải thích trước đó, Chương 10, bản tóm tắt các
điểm chính của Phần A, đã được đưa vào để cuốn sách này có thể được sử dụng khi
sinh viên bắt đầu các dự án học kỳ theo nhóm song song với khóa học kỹ thuật phần
mềm của họ. Chương mới khác, Chương 18, đưa ra cái nhìn tổng quan về 10 công
nghệ mới nổi, bao gồm
•Công nghệ hướng theo khía cạnh
•Công nghệ dựa trên mô hình
•Công nghệ dựa trên thành phần
•Công nghệ hướng tới dịch vụ
•Điện toán xã hội
•Kỹ thuật web
•Công nghệ đám mây
•Web 3.0
•Bảo mật máy tính
•Kiểm tra mô hình
•Tôi đã mở rộng đáng kể tài liệu về các mẫu thiết kế trong Chương 8, bao gồm cả một
nghiên cứu tình huống nhỏ mới.
•Hai công cụ lý thuyết đã được thêm vào Chương 5: chia để trị và phân tách các mối quan
tâm.
•Phân tích hướng đối tượng của bài toán thang máy ở Chương 13 hiện nay phản ánh một
kiến ​trúc phân tán, phi tập trung hiện đại.
•Các tài liệu tham khảo đã được cập nhật rộng rãi, tập trung vào nghiên cứu hiện
tại.•Có hơn 100 vấn đề mới.
•Có các hộp Just in Case You Want to Know mới.

Các tính năng được giữ lại từ phiên bản thứ bảy
•Quy trình Unifi phần lớn vẫn là phương pháp được lựa chọn để phát triển phần mềm
 hướng đối tượng. Do đó, xuyên suốt cuốn sách này, sinh viên được tiếp xúc với cả lý
thuyết và thực hành của Quy trình Thống nhất.
•Trong Chương 1, những điểm mạnh của mô hình hướng đối tượng được phân tích sâu.
Lời nói đầuxv

•Mô hình vòng đời lặp đi lặp lại và tăng dần đã được giới thiệu sớm nhất có thể, cụ thể là
ở Chương 2. Hơn nữa, giống như tất cả các phiên bản trước, nhiều mô hình vòng đời
khác được trình bày, so sánh và đối chiếu. Đặc biệt chú ý đến các quy trình linh hoạt.
•Trong Chương 3 (“Quy trình phần mềm”), các quy trình công việc (hoạt động) và quy
trình của Quy trình thống nhất được giới thiệu và giải thích nhu cầu về mô hình vòng
đời hai chiều.
•Nhiều cách tổ chức nhóm phần mềm khác nhau được trình bày trong Chương 4
(“Nhóm”), bao gồm các nhóm dành cho quy trình linh hoạt và nhóm phát triển phần mềm
nguồn mở.•Chương 5 (“Công cụ giao dịch”) bao gồm thông tin về các loại công cụ CASE
quan trọng.
•Tầm quan trọng của việc kiểm tra liên tục được nhấn mạnh trong Chương 6 (“Thử
nghiệm”).•Các đối tượng tiếp tục là tâm điểm chú ý trong Chương 7 (“Từ Mô-đun đến
Đối tượng”).•Các mẫu thiết kế vẫn là trọng tâm của Chương 8 (“Khả năng tái sử dụng và
tính di động”).•Tiêu chuẩn IEEE cho các kế hoạch quản lý dự án phần mềm một lần nữa
được trình bày trong Chương 9 (“Lập kế hoạch và Ước tính”).
•Chương 11 (“Yêu cầu”), Chương 13 (“Phân tích hướng đối tượng”) và Chương 14
(“Thiết kế”) phần lớn dành cho các quy trình công việc (hoạt động) của Quy trình
thống nhất. Vì những lý do hiển nhiên, Chương 12 (“Phân tích cổ điển”) hầu như
không thay đổi.
•Tài liệu trong Chương 15 (“Triển khai”) phân biệt rõ ràng giữa thực hiện và tích hợp.
•Tầm quan trọng của việc bảo trì sau giao hàng được nhấn mạnh trong Chương
16.•Chương 17 cung cấp tài liệu bổ sung về UML để chuẩn bị kỹ lưỡng cho sinh viên làm
việc trong ngành công nghiệp phần mềm. Chương này đặc biệt được sử dụng cho những
người hướng dẫn sử dụng cuốn sách này cho chuỗi khóa học kỹ thuật phần mềm kéo dài
hai học kỳ. Trong học kỳ thứ hai, ngoài việc phát triển dự án học kỳ theo nhóm hoặc dự án
capstone, sinh viên có thể tiếp thu thêm kiến ​thức về UML, ngoài những gì cần thiết cho
cuốn sách này.•Như trước đây, có hai nghiên cứu điển hình đang được thực hiện. Nghiên
cứu điển hình của Quỹ MSG và nghiên cứu điển hình về Vấn đề thang máy đã được phát
triển bằng Quy trình Thống nhất. Như thường lệ, việc triển khai Java và C++ có sẵn trực
tuyến tạiwww.mhhe.com/schach.•Ngoài hai nghiên cứu điển hình đang chạy được sử
dụng để minh họa toàn bộ vòng đời, tám nghiên cứu trường hợp nhỏ nêu bật các chủ đề cụ
thể, chẳng hạn như vấn đề mục tiêu di chuyển, sàng lọc từng bước, mẫu thiết kế và bảo trì
sau giao hàng.•Trong tất cả các phiên bản trước, tôi đã nhấn mạnh tầm quan trọng của tài
liệu, bảo trì, tái sử dụng, tính di động, kiểm tra và các công cụ CASE. Trong ấn bản này,
tất cả các khái niệm này đều được nhấn mạnh một cách chắc chắn như nhau. Sẽ chẳng có
ích gì khi dạy sinh viên những ý tưởng mới nhất trừ khi họ đánh giá cao tầm quan trọng
của những kiến ​thức cơ bản về công nghệ phần mềm.
•Như trong phiên bản thứ bảy, sự chú ý đặc biệt được dành cho các mô hình vòng đời
hướng đối tượng, phân tích hướng đối tượng, thiết kế hướng đối tượng, ý nghĩa quản lý
của mô hình hướng đối tượng, và việc kiểm tra và bảo trì phần mềm hướng đối tượng.
Các số liệu cho mô hình hướng đối tượng cũng được bao gồm. Ngoài ra, nhiều tài liệu
tham khảo ngắn gọn hơn được thực hiện cho các đối tượng, một đoạn văn hoặc thậm
chí chỉ một câu dài. Lý do là mô hình hướng đối tượng không chỉ quan tâm đến cách
thực hiện các giai đoạn khác nhau mà còn thấm sâu vào cách chúng ta nghĩ về công
nghệ phần mềm. Công nghệ đối tượng một lần nữa tràn ngập cuốn sách này.
xviLời nói đầu
 •Quy trình phần mềm vẫn là khái niệm làm nền tảng cho toàn bộ cuốn sách. Để kiểm soát
quá trình, chúng ta phải có khả năng đo lường những gì đang xảy ra với dự án. Theo
đó, sự nhấn mạnh vào số liệu vẫn tiếp tục. Về cải tiến quy trình, tài liệu về mô hình
trưởng thành năng lực (CMM), ISO/IEC 15504 (SPICE) và ISO/IEC 12207 đã được
giữ lại.
•Cuốn sách vẫn độc lập về ngôn ngữ. Một số ví dụ mã được trình bày bằng C++ và Java
và tôi đã cố gắng hết sức để làm mượt các chi tiết phụ thuộc vào ngôn ngữ và đảm bảo
rằng các ví dụ mã đó đều rõ ràng như nhau đối với người dùng C++ và Java. Ví dụ,
thay vì sử dụngcoutcho đầu ra C++ vàSystem.out.printlnđối với đầu ra Java, tôi đã sử
dụng lệnh mã giảin. (Một ngoại lệ là nghiên cứu điển hình mới, trong đó chi tiết triển
khai đầy đủ được đưa ra trong cả C++ và Java, như trước đây.)
•Như trong ấn bản thứ bảy, cuốn sách này có hơn 600 tài liệu tham khảo. Tôi đã chọn lọc
những tài liệu nghiên cứu hiện tại cũng như những bài báo và cuốn sách kinh điển mà
thông điệp của chúng vẫn mới mẻ và phù hợp. Không còn nghi ngờ gì nữa rằng công
nghệ phần mềm là một lĩnh vực phát triển nhanh chóng và do đó sinh viên cần biết các
kết quả mới nhất và tìm chúng ở đâu trong tài liệu. Đồng thời, nghiên cứu tiên tiến
ngày nay dựa trên sự thật của ngày hôm qua và tôi thấy không có lý do gì để loại trừ
một tài liệu tham khảo cũ hơn nếu các ý tưởng của nó vẫn có thể áp dụng cho ngày nay
như ban đầu.
•Về các điều kiện tiên quyết, giả định rằng người đọc đã quen thuộc với ngôn ngữ lập
trình cấp cao như C, C#, C++ hoặc Java. Ngoài ra, người đọc phải tham gia một khóa
học về cấu trúc dữ liệu.

Tại sao mô hình cổ điển vẫn được đưa vào

Hiện nay gần như có sự nhất trí rằng mô hình hướng đối tượng vượt trội hơn mô hình cổ
điển. Theo đó, nhiều giảng viên đã áp dụng phiên bản thứ bảy củaKỹ thuật phần mềm
hướng đối tượng và cổ điểnđã chọn chỉ dạy tài liệu hướng đối tượng trong cuốn sách đó.
Tuy nhiên, khi được hỏi, những người hướng dẫn chỉ ra rằng họ thích áp dụng một văn
bản bao gồm mô hình cổ điển hơn.
Nguyên nhân là do ngày càng có nhiều giảng viêndạy bảochỉ có mô hình hướng đối
tượng, họ vẫntham khảođến mô hình cổ điển trong lớp; nhiều kỹ thuật hướng đối tượng
khó hiểu đối với sinh viên trừ khi sinh viên đó có một số ý tưởng về các kỹ thuật cổ điển
mà từ đó các kỹ thuật hướng đối tượng đó bắt nguồn. Ví dụ, hiểu thực thể
mô hình hóa lớp học sẽ dễ dàng hơn đối với sinh viên đã được giới thiệu, thậm chí chỉ là
bề ngoài, về mô hình hóa mối quan hệ thực thể. Tương tự, phần giới thiệu ngắn gọn về
máy trạng thái hữu hạn giúp người hướng dẫn dạy biểu đồ trạng thái dễ dàng hơn. Theo
đó, tôi đã giữ lại tài liệu cổ điển trong ấn bản thứ tám, để người hướng dẫn có sẵn tài liệu
cổ điển cho mục đích sư phạm.

Bộ vấn đề
Như trong lần tái bản thứ bảy, cuốn sách này có năm loại vấn đề. Đầu tiên, có các dự án
phân tích và thiết kế hướng đối tượng đang chạy ở cuối Chương 11, 13 và 14. Những dự
án này được đưa vào vì cách duy nhất để học cách thực hiện các yêu cầu, phân tích và quy
trình thiết kế là từ các quy trình mở rộng. kinh nghiệm thực tế.
Thứ hai, cuối mỗi chương có một số bài tập nhằm nêu bật những điểm chính. Những bài
tập này mang tính khép kín; thông tin kỹ thuật cho tất cả các bài tập có thể được tìm thấy
trong cuốn sách này.
Lời nói đầuxvii
 Thứ ba, có một dự án thuật ngữ phần mềm. Nó được thiết kế để giải quyết bởi những học
sinh làm việc theo nhóm ba người, số lượng thành viên nhỏ nhất trong nhóm không thể
trao đổi qua điện thoại tiêu chuẩn. Thuật ngữ dự án bao gồm 15 thành phần riêng biệt, mỗi
thành phần gắn liền với chương liên quan. Ví dụ, thiết kế là chủ đề của Chương 14, vì vậy
trong chương đó thành phần của thuật ngữ dự án liên quan đến thiết kế phần mềm. Bằng
cách chia một dự án lớn thành những phần nhỏ hơn, được xác định rõ ràng, người hướng
dẫn có thể theo dõi tiến độ của lớp học một cách chặt chẽ hơn. Cấu trúc của dự án theo
thuật ngữ sao cho người hướng dẫn có thể tự do áp dụng 15 thành phần vào bất kỳ dự án
nào khác mà họ chọn.
Bởi vì cuốn sách này được viết để sử dụng bởi các sinh viên đã tốt nghiệp cũng như sinh
viên đại học thuộc tầng lớp thượng lưu, nên loại vấn đề thứ tư dựa trên các tài liệu nghiên
cứu trong tài liệu công nghệ phần mềm. Trong mỗi chương đã chọn ra một bài báo quan
trọng; bất cứ khi nào có thể, một bài báo liên quan đến công nghệ phần mềm hướng đối
tượng đã được chọn. Học sinh được yêu cầu đọc bài báo và trả lời một câu hỏi liên quan
đến nội dung của nó. Tất nhiên, người hướng dẫn có quyền giao bất kỳ bài nghiên cứu nào
khác; phần Đọc thêm ở cuối mỗi chương bao gồm nhiều loại tài liệu liên quan.
Loại vấn đề thứ năm liên quan đến nghiên cứu tình huống. Loại vấn đề này lần đầu tiên
được giới thiệu trong ấn bản thứ ba nhằm đáp lại một số giảng viên cảm thấy rằng sinh
viên của họ học được nhiều hơn bằng cách sửa đổi một sản phẩm hiện có hơn là phát triển
một sản phẩm mới từ đầu. Nhiều kỹ sư phần mềm cao cấp trong ngành đồng ý với quan
điểm đó. Theo đó, mỗi chương trình bày nghiên cứu trường hợp đều có vấn đề đòi hỏi
sinh viên phải sửa đổi nghiên cứu trường hợp theo một cách nào đó. Ví dụ, trong một
chương, sinh viên được yêu cầu thiết kế lại nghiên cứu trường hợp bằng cách sử dụng kỹ
thuật thiết kế khác với kỹ thuật được sử dụng cho nghiên cứu trường hợp. Trong một
chương khác, sinh viên được hỏi tác động của việc thực hiện các bước phân tích hướng
đối tượng theo một thứ tự khác là gì. Để dễ dàng sửa đổi mã nguồn của nghiên cứu điển
hình, nó có sẵn trên Web tạiwww.mhhe.com/schach.
Trang web cũng có tài liệu dành cho giảng viên, bao gồm bộ bài giảng PowerPoint hoàn
chỉnh và lời giải chi tiết cho tất cả các bài tập cũng như dự án học kỳ.

Tài liệu về UML

Cuốn sách này sử dụng đáng kể UML (Ngôn ngữ mô hình hóa thống nhất). Nếu sinh
viên chưa có kiến ​thức trước đây về UML, tài liệu này có thể được dạy theo hai cách. Tôi
thích dạy UML đúng lúc hơn; nghĩa là mỗi khái niệm UML được giới thiệu ngay trước
khi cần đến nó. Bảng sau đây mô tả nơi giới thiệu các cấu trúc UML được sử dụng trong
cuốn sách này.

Phần giới thiệu sơ đồ UML xây dựng tương ứng

Sơ đồ lớp, ghi chú, kế thừa (tổng quát hóa), Mục 7.7
tổng hợp, liên kết, tam giác điều hướng
Ca sử dụng Phần 11.4.3
Sơ đồ use-case, mô tả use-case Phần 11.7
Khuôn mẫu Phần 13.1
Biểu đồ tiểu bang Phần 13.6
Sơ đồ tương tác (sơ đồ trình tự, Mục 13.15
sơ đồ truyền thông)
xviiiLời nói đầu

Ngoài ra, Chương 17 còn có phần giới thiệu về UML, bao gồm tài liệu ở trên và ngoài
những gì cần thiết cho cuốn sách này. Chương 17 có thể được dạy bất cứ lúc nào; nó
không phụ thuộc vào tài liệu trong 16 chương đầu tiên. Các chủ đề được đề cập trong
 Chương 17 như sau:

Phần giới thiệu sơ đồ UML xây dựng tương ứng

Sơ đồ lớp, tập hợp, bội số, Mục 17.2
thành phần, khái quát hóa, liên kết
Lưu ý Mục 17.3
Sơ đồ use-case Phần 17.4
Khuôn mẫu Phần 17.5
Sơ đồ tương tác Phần 17.6
Biểu đồ tiểu bang Phần 17.7
Sơ đồ hoạt động Phần 17.8
Gói thầu Phần 17.9
Sơ đồ thành phần Mục 17.10
Sơ đồ triển khai Phần 17.11

Những nguồn thông tin trên mạng

Một trang web đi kèm với văn bản có sẵn tạiwww.mhhe.com/schach. Trang web này có
các triển khai Java và C++ cũng như mã nguồn cho nghiên cứu điển hình về MSG dành
cho sinh viên. Dành cho người hướng dẫn, bài giảng PowerPoint, lời giải chi tiết cho tất
cả các bài tập và dự án học kỳ cũng như thư viện hình ảnh đều có sẵn. Để biết chi tiết, hãy
liên hệ với đại diện bán hàng của bạn.

Tùy chọn sách giáo khoa điện tử

Sách điện tử là một cách sáng tạo để sinh viên tiết kiệm tiền và đồng thời tạo ra môi
trường xanh hơn. Sách điện tử có thể giúp học sinh tiết kiệm một nửa chi phí so với sách
giáo khoa truyền thống và cung cấp các tính năng độc đáo như công cụ tìm kiếm mạnh
mẽ, đánh dấu và khả năng chia sẻ ghi chú với bạn cùng lớp bằng sách điện tử.
McGraw-Hill cung cấp văn bản này dưới dạng sách điện tử. Để nói về các tùy chọn sách
điện tử, hãy liên hệ với đại diện bán hàng McGraw-Hill của bạn hoặc truy cập trang
webwww.coursesmart.comđể tìm hiểu thêm.

Sự nhìn nhận
Tôi đánh giá rất cao những lời phê bình mang tính xây dựng và nhiều gợi ý hữu ích của
các nhà phê bình bảy lần xuất bản trước. Xin gửi lời cảm ơn đặc biệt đến những người
đánh giá ấn bản này, bao gồm cả
Đại học Nam CaliforniaSaeed Monemi
Ramzi Bualuan Đại học Bách khoa California, Pomona
Đại học Notre DameRuth Dameron Lời nói đầuxix
Đại học Colorado, BoulderWerner
Krandick taehyung wang
Đại học Drexel
Mike McCracken
Viện Công nghệ Georgia Tiểu Quân Tề
Nenad Medvidovic
Đại học bang California, York—Cao đẳng Thành phố
NorthridgeJie Wei Đại học bang Utah
Đại học Thành phố New
 Đối với nhà xuất bản của tôi, McGraw-Hill, tôi rất biết ơn người biên tập Kevin Camp
Bell và nhà thiết kế Brenda Rolwes. Xin gửi lời cảm ơn đặc biệt tới Melissa Welch của
Studio Montage, người đã biến bức ảnh Cầu Cảng Sydney vào ban đêm thành tấm bìa
tuyệt đẹp.
Tôi cũng xin gửi lời cảm ơn đặc biệt đến Jean Naudé (Đại học Công nghệ Vaal, Cơ sở
Secunda) vì là đồng tác giả Sổ tay Giải pháp dành cho Giảng viên. Đặc biệt, Jean đã cung
cấp một giải pháp hoàn chỉnh cho dự án trong thời hạn, bao gồm cả việc triển khai nó trên
cả Java và C++. Trong quá trình làm việc về ISM, Jean đã đưa ra nhiều đề xuất mang tính
xây dựng để cải thiện cuốn sách này. Tôi biết ơn Jean nhất.
Cuối cùng, như thường lệ, tôi cảm ơn vợ tôi, Sharon, vì sự hỗ trợ và động viên liên tục
của cô ấy. Giống như tất cả những cuốn sách trước đây của tôi, tôi đã cố gắng hết sức để
đảm bảo rằng những cam kết với gia đình được ưu tiên hơn việc viết lách. Tuy nhiên, khi
thời hạn đến gần, điều này không phải lúc nào cũng đúng.
có thể. Những lúc như vậy, Sharon luôn thấu hiểu và tôi rất biết ơn vì điều này. Tôi hân
hạnh được dành tặng cuốn sách thứ mười lăm của mình cho các cháu của tôi, Jackson và
Mikaela, với tình yêu thương.

Stephen R. Cờ vua
Trang này cố ý để trống

chương
1
Phạm vi của Công
nghệ phần mềm

Mục tiêu học tập

Sau khi nghiên cứu chương này, bạn sẽ có thể

• Định nghĩa công nghệ phần mềm là gì.

• Mô tả mô hình vòng đời công nghệ phần mềm cổ điển.
• Giải thích tại sao mô hình hướng đối tượng hiện nay được chấp nhận rộng rãi đến vậy.
 • Thảo luận về ý nghĩa của các khía cạnh khác nhau của công nghệ phần mềm.
• Phân biệt quan điểm cổ điển và hiện đại về bảo trì.
• Thảo luận về tầm quan trọng của việc lập kế hoạch, kiểm tra và ghi chép liên tục.
• Đánh giá cao tầm quan trọng của việc tuân thủ quy tắc đạo đức.

Một câu chuyện nổi tiếng kể về một giám đốc điều hành nhận được một hóa đơn do máy
tính tạo ra trị giá 0,00 USD. Sau khi cười vui vẻ với bạn bè về “những chiếc máy tính ngu
ngốc”, vị giám đốc điều hành này đã vứt hóa đơn đi. Một tháng sau, một hóa đơn tương tự
được gửi đến, lần này là 30 ngày. Sau đó đến hóa đơn thứ ba. Hóa đơn thứ tư đến một
tháng sau đó, kèm theo một thông báo gợi ý về vị trí
hành động pháp lý có thể xảy ra nếu hóa đơn $0,00 không được thanh toán ngay lập tức.
Dự luật thứ năm, đánh dấu 120 ngày, không gợi ý bất cứ điều gì - thông điệp thô lỗ và
thẳng thắn, đe dọa mọi hình thức hành động pháp lý nếu hóa đơn không được thanh toán
ngay lập tức. Lo sợ xếp hạng tín nhiệm của tổ chức rơi vào tay cỗ máy điên rồ này, người
điều hành đã gọi điện cho một người quen là kỹ sư phần mềm và kể lại toàn bộ câu
chuyện đáng tiếc. Cố gắng không cười, kỹ sư phần mềm bảo người điều hành gửi một tấm
séc trị giá 0,00 đô la. Điều này đã mang lại hiệu quả như mong muốn và người ta đã nhận
được biên lai trị giá 0,00 USD sau đó vài ngày. Người điều hành đã tỉ mỉ tính toán nó đi đề
phòng trường hợp vào một ngày nào đó trong tương lai, máy tính có thể cáo buộc rằng vẫn
còn nợ 0,00 đô la.

1
2Chương 1Phạm vi của Công nghệ phần mềm

Câu chuyện nổi tiếng này có phần tiếp theo ít được biết đến hơn. Vài ngày sau, vị giám
đốc điều hành này được giám đốc ngân hàng triệu tập. Nhân viên ngân hàng giơ một tấm
séc lên và hỏi: “Đây có phải là tấm séc của bạn không?”
Người điều hành đồng ý rằng đúng như vậy.
“Bạn có phiền cho tôi biết tại sao bạn lại viết một tấm séc trị giá 0,00 đô la không?” nhân
viên ngân hàng hỏi. Thế là toàn bộ câu chuyện đã được kể lại. Khi người điều hành nói
xong, người nhân viên ngân hàng quay sang anh ta và cô ấy nhẹ nhàng hỏi, “Anh có biết
tấm séc 0,00 đô la của anh đã làm gì không?của chúng tôihệ thống máy tính?"
Một chuyên gia máy tính có thể cười vào câu chuyện này, mặc dù có phần lo lắng. Suy
cho cùng, mỗi người trong chúng ta đều đã thiết kế hoặc triển khai một sản phẩm mà ở
dạng ban đầu sẽ dẫn đến kết quả tương đương với việc gửi những bức thư ép giá với giá
0,00 USD. Cho đến nay, chúng tôi luôn gặp phải lỗi này trong quá trình thử nghiệm.
Nhưng tiếng cười của chúng ta có vẻ trống rỗng, bởi vì sâu thẳm trong tâm trí chúng ta là
nỗi sợ hãi rằng một ngày nào đó chúng ta sẽ không phát hiện ra lỗi trước khi sản phẩm
được giao cho khách hàng.
Một lỗi phần mềm ít hài hước hơn đã được phát hiện vào ngày 9 tháng 11 năm 1979. Bộ
Tư lệnh Không quân Chiến lược đã có một cảnh báo khẩn cấp khi mạng máy tính của hệ
thống chỉ huy và kiểm soát quân sự toàn cầu (WWMCCS) báo cáo rằng Liên Xô đã phóng
tên lửa nhằm vào Hoa Kỳ [Neumann , 1980]. thực tế là gì
đồng minh đã xảy ra là một cuộc tấn công mô phỏng được hiểu là cuộc tấn công thực sự,
giống như trong phimNhững trò chơi chiến tranhkhoảng 5 năm sau. Mặc dù có thể hiểu
rằng Bộ Quốc phòng Hoa Kỳ đã không cung cấp thông tin chi tiết về cơ chế chính xác mà
dữ liệu thử nghiệm được lấy làm dữ liệu thực tế, nhưng có vẻ hợp lý khi cho rằng vấn đề
là do lỗi phần mềm. Toàn bộ hệ thống không được thiết kế để phân biệt giữa simula
và thực tế hoặc giao diện người dùng không bao gồm các kiểm tra cần thiết để đảm bảo
rằng người dùng cuối của hệ thống có thể phân biệt được sự thật với hư cấu. Nói cách
khác, một lỗi phần mềm, nếu thực sự vấn đề là do phần mềm gây ra, có thể đã đưa nền
văn minh như chúng ta biết đến một kết cục khó chịu và đột ngột. (Xem Phòng trường hợp
 bạn muốn biết Hộp 1.1 để biết thông tin về các thảm họa do lỗi phần mềm khác gây ra.)
Cho dù chúng tôi đang giải quyết vấn đề thanh toán hay phòng không, phần lớn phần
mềm của chúng tôi đều được giao muộn, vượt quá ngân sách và có nhiều lỗi còn sót lại,
đồng thời không đáp ứng được nhu cầu của khách hàng. Công nghệ phần mềm là một nỗ
lực để giải quyết những vấn đề này. Nói cách khác,kỹ thuật phần mềmlà một ngành có
mục tiêu là sản xuất phần mềm không có lỗi, được giao đúng thời hạn và trong phạm vi
ngân sách, đáp ứng nhu cầu của khách hàng. Hơn nữa, phần mềm phải dễ dàng sửa đổi khi
nhu cầu của người dùng thay đổi.
Phạm vi của công nghệ phần mềm là vô cùng rộng. Một số khía cạnh của công nghệ phần
mềm có thể được phân loại thành toán học hoặc khoa học máy tính; các khía cạnh khác
thuộc lĩnh vực kinh tế, quản lý hoặc tâm lý học. Để trình bày phạm vi rộng lớn của công
nghệ phần mềm, bây giờ chúng ta xem xét năm khía cạnh khác nhau.

1.1 Khía cạnh lịch sử

Thực tế là máy phát điện bị hỏng, nhưng ít thường xuyên hơn so với các sản phẩm trả
lương. Cầu nối đôi khi bị sập nhưng ít thường xuyên hơn so với hệ điều hành. Với niềm
tin rằng thiết kế, triển khai và bảo trì phần mềm có thể được thực hiện giống nhau

Chỉ trong trường hợp bạn muốn biếtHộp 1.1

Trong trường hợp mạng WWMCCS, thảm họa đã được ngăn chặn vào phút cuối. Tuy
nhiên, hậu quả của các lỗi phần mềm khác là rất nghiêm trọng. Ví dụ, từ năm 1985 đến
năm 1987, ít nhất hai bệnh nhân đã chết do dùng quá liều bức xạ do máy gia tốc tuyến
tính y tế Therac-25 cung cấp [Leveson và Turner, 1993]. Nguyên nhân là do phần mềm
điều khiển bị lỗi.
Ngoài ra, trong Chiến tranh vùng Vịnh năm 1991, một tên lửa Scud đã xuyên thủng lá
chắn chống tên lửa Patriot và tấn công một doanh trại gần Dhahran, Ả Rập Saudi. Tổng
cộng có 28 người Mỹ thiệt mạng và 98 người bị thương. Phần mềm dành cho tên lửa
Patriot có lỗi tích lũy về thời gian. Patriot được thiết kế để chỉ hoạt động trong vài giờ mỗi
lần, sau đó đồng hồ được đặt lại. Kết quả là lỗi không bao giờ gây ảnh hưởng đáng kể và
do đó không được phát hiện. Tuy nhiên, trong Chiến tranh vùng Vịnh, dàn tên lửa Patriot ở
Dhahran đã hoạt động liên tục trong hơn 100 giờ. Điều này khiến cho sự chênh lệch về
thời gian tích lũy trở nên đủ lớn để khiến hệ thống không chính xác.
Trong Chiến tranh vùng Vịnh, Hoa Kỳ đã vận chuyển tên lửa Patriot tới Israel để bảo vệ
chống lại tên lửa Scud. Lực lượng Israel đã phát hiện ra vấn đề về thời gian chỉ sau 8 giờ
và ngay lập tức báo cáo vấn đề này cho nhà sản xuất ở Hoa Kỳ. Nhà sản xuất đã sửa lỗi
nhanh nhất có thể, nhưng bi thảm thay, phần mềm mới đã xuất hiện một ngày sau khi bị
Scud tấn công trực tiếp [Mellor, 1994].
May mắn thay, trường hợp tử vong hoặc thương tích nghiêm trọng do lỗi phần mềm là
cực kỳ hiếm. Tuy nhiên, một lỗi lầm có thể gây ra vấn đề lớn cho hàng nghìn, hàng nghìn
người. Ví dụ, vào tháng 2 năm 2003, một lỗi phần mềm đã khiến Bộ Tài chính Hoa Kỳ gửi
50.000 tờ séc An sinh Xã hội được in mà không có tên của ben.
hiệu lực, do đó séc không thể được gửi hoặc chuyển thành tiền mặt [St. Petersburg Thời
báo trực tuyến, 2003]. Vào tháng 4 năm 2003, những người đi vay được SLM Corp.
(thường được gọi là Sallie Mae) thông báo rằng lãi suất cho khoản vay sinh viên của họ đã
bị tính sai do lỗi phần mềm từ năm 1992 nhưng mãi đến cuối năm 2002 mới được phát
hiện. Gần 1 triệu người đi vay được thông báo rằng họ sẽ phải trả nhiều tiền hơn, dưới
hình thức thanh toán hàng tháng cao hơn hoặc thanh toán lãi bổ sung cho các khoản vay
vượt quá thời hạn 10 năm ban đầu của họ [GJSenti
nel.com, 2003]. Cả hai lỗi đều nhanh chóng được sửa chữa, nhưng chúng cùng nhau gây
ra những hậu quả tài chính không hề nhỏ cho khoảng một triệu người.
Chính phủ Bỉ đã đánh giá quá cao ngân sách năm 2007 của mình lên tới 883.000.000 €
(hơn 1.100.000.000 USD vào thời điểm viết bài). Lỗi này là do lỗi phần mềm kết hợp với
việc ghi đè thủ công cơ chế phát hiện lỗi [La Libre Online, 2007a; 2007b]. Cơ quan thuế Bỉ
 sử dụng máy quét và phần mềm nhận dạng ký tự quang học
thiết bị xử lý tờ khai thuế. Nếu phần mềm gặp phải kết quả không thể đọc được, nó sẽ ghi
thu nhập của người nộp thuế là 99.999.999,99 € (hơn 125.000.000 USD). Có lẽ, “con số
ma thuật” €99.999.999,99 đã được chọn để nhân viên của bộ phận xử lý dữ liệu nhanh
chóng phát hiện, do đó, khoản hoàn trả được đề cập sau đó sẽ được xử lý thủ công. Điều
này có tác dụng tốt khi các tờ khai thuế được phân tích cho mục đích đánh giá thuế,
nhưng không hiệu quả khi các tờ khai thuế được phân tích lại vì mục đích ngân sách. Trớ
trêu thay, sản phẩm phần mềm quả thực có bộ lọc để phát hiện loại vấn đề này, nhưng các
bộ lọc này đã được bỏ qua theo cách thủ công để tăng tốc độ xử lý.
Có ít nhất hai lỗi trong phần mềm. Đầu tiên, các kỹ sư phần mềm cho rằng sẽ luôn có sự
giám sát thủ công đầy đủ trước khi xử lý dữ liệu thêm. Thứ hai, phần mềm cho phép ghi
đè các bộ lọc theo cách thủ công.

Chỉ trong trường hợp bạn muốn biếtHộp 1.2

Như đã nêu trong Phần 1.1, mục đích của hội nghị Garmisch là làm cho việc phát triển
phần mềm thành công như kỹ thuật truyền thống. Nhưng không phải tất cả các dự án kỹ
thuật truyền thống đều thành công. Ví dụ, hãy xem xét việc xây dựng cây cầu.
Vào tháng 7 năm 1940, việc xây dựng một cây cầu treo bắc qua Tacoma Narrows, ở bang
Washington, đã hoàn thành. Ngay sau đó, người ta phát hiện ra rằng cây cầu bị lắc lư và
oằn xuống một cách nguy hiểm trong điều kiện có gió. Những chiếc xe đang đến gần sẽ
lần lượt biến mất vào các thung lũng rồi xuất hiện trở lại khi phần cầu đó nhô lên trở lại.
Từ hành vi này, cây cầu đã được đặt cho biệt danh “Galloping Gertie”. Cuối cùng, vào
ngày 7 tháng 11 năm 1940, cây cầu bị sập với sức gió 42 dặm một giờ; may mắn thay, cây
cầu đã bị đóng cửa không cho mọi phương tiện giao thông qua lại vài giờ trước đó. 15
phút cuối cùng trong cuộc đời của nó đã được ghi lại trên phim, hiện được lưu trữ trong
Cơ quan đăng ký phim quốc gia Hoa Kỳ.
Một sự cố xây dựng cây cầu có phần hài hước hơn đã được quan sát vào tháng 1 năm
2004. Một cây cầu mới đang được xây dựng bắc qua sông Thượng Rhine gần thị trấn
Laufenberg của Đức, để nối Đức và Thụy Sĩ. Nửa cầu Đức được thiết kế và thi công bởi
đội ngũ kỹ sư người Đức; nửa Thụy Sĩ của đội Thụy Sĩ. Khi hai phần được kết nối, nó
ngay lập tức xuất hiện
nghĩa là nửa của Đức cao hơn nửa của Thụy Sĩ khoảng 21 inch (54 cm). Cần phải xây
dựng lại để khắc phục vấn đề, nguyên nhân là do sửa sai vì thực tế là “mực nước biển”
được các kỹ sư Thụy Sĩ coi là mực nước trung bình của Biển Địa Trung Hải, trong khi các
kỹ sư Đức sử dụng Biển Bắc. Để bù đắp cho sự chênh lệch mực nước biển, lẽ ra phía
Thụy Sĩ phải nâng lên 10,5 inch. Thay vào đó, nó được hạ xuống 10,5 inch, dẫn đến
khoảng cách là 21 inch [Spiegel Online, 2004].

như các ngành kỹ thuật truyền thống, một nhóm nghiên cứu của NATO vào năm 1967 đã
đặt ra thuật ngữkỹ thuật phần mềm. Tuyên bố rằng việc xây dựng phần mềm tương tự như
các nhiệm vụ kỹ thuật khác đã được xác nhận bởi Hội nghị Kỹ thuật phần mềm NATO
năm 1968 được tổ chức tại Garmisch, Đức [Naur, Randell và Buxton, 1976]. Sự chứng
thực này không quá ngạc nhiên; chính tên của hội nghị đã phản ánh niềm tin rằng sản xuất
phần mềm phải là một hoạt động giống như kỹ thuật (nhưng hãy xem Hộp 1.2 Chỉ trong
trường hợp bạn muốn biết). Một kết luận của các hội nghị là công nghệ phần mềm nên sử
dụng các triết lý và mô hình của các ngành kỹ thuật đã được thiết lập để giải quyết những
gì họ gọi là vấn đềkhủng hoảng phần mềm, cụ thể là chất lượng phần mềm nhìn
chung thấp đến mức không thể chấp nhận được và thời hạn cũng như ngân sách không
được đáp ứng.
Bất chấp nhiều câu chuyện thành công về phần mềm, một tỷ lệ lớn các sản phẩm phần
mềm vẫn được giao trễ, vượt quá ngân sách và có nhiều lỗi còn sót lại. Ví dụ, Standish
Group là một công ty nghiên cứu phân tích các dự án phát triển phần mềm. Nghiên cứu
 của họ về các dự án phát triển hoàn thành năm 2006 được tóm tắt trong Hình 1.1
[Rubenstein, 2007]. Chỉ 35% dự án được hoàn thành thành công, trong khi 19% dự án bị
hủy trước khi hoàn thành hoặc chưa bao giờ được triển khai. 46% dự án còn lại đã được
hoàn thành và cài đặt trên máy tính của khách hàng. Tuy nhiên, những dự án đó đã vượt
quá ngân sách, bị chậm trễ hoặc có ít tính năng và chức năng hơn so với quy định ban đầu.
Nói cách khác, trong năm 2006, chỉ hơn một phần ba dự án phát triển phần mềm thành
công; gần một nửa số dự án có một hoặc nhiều dấu hiệu của cuộc khủng hoảng phần mềm.
Chương 1Phạm vi của Công nghệ phần mềm5

HÌNH 1.1
Hậu quả
trong số hơn hoàn thành vào
9.000 dự án phát năm 2006 Thành công
triển 35%
Đã hủy 19%
phần mềm.•Trong 56% những trường hợp đó, ngày
giao hàng đã hứa bị trễ nhiều lần.•Trong 45% trường
[Rubenstein, 2007]. hợp đó, lỗi nghiêm trọng đến mức sản phẩm phần
Hoàn thành muộn mềm không thể sử dụng được.
vượt quá ngân sách và/hoặc
với những tính năng còn thiếu Rõ ràng là có quá ít phần mềm được giao đúng thời
46% hạn, trong phạm vi ngân sách, không có lỗi và đáp
ứng được nhu cầu của khách hàng. Để đạt được
những mục tiêu này, một kỹ sư phần mềm phải có
được nhiều kỹ năng, cả về kỹ thuật và quản lý. Những
kỹ năng này phải được áp dụng không chỉ trong lập
trình mà còn trong mọi bước sản xuất phần mềm, từ
yêu cầu đến bảo trì sau giao hàng.
Những tác động tài chính của cuộc khủng hoảng phần Cuộc khủng hoảng phần mềm vẫn còn đeo bám
mềm là khủng khiếp. Trong một cuộc khảo sát được chúng ta khoảng 40 năm sau, cho chúng ta biết hai
thực hiện bởi Cutter Consortium [2002], đã có báo điều. Đầu tiên, phần mềmquá trìnhtức là cách chúng
cáo như sau: ta sản xuất phần mềm có những đặc điểm và vấn đề
•Một con số đáng kinh ngạc là 78% các tổ chức công riêng, mặc dù nó giống với kỹ thuật truyền thống ở
nghệ thông tin đã tham gia vào các tranh chấp dẫn đến nhiều khía cạnh. Thứ hai, cuộc khủng hoảng phần
kiện tụng. mềm có lẽ nên được đổi tên thànhtrầm cảm phần
•Trong 67% các trường hợp đó, chức năng hoặc hiệu mềm, do thời gian kéo dài và tiên lượng xấu.
suất của các sản phẩm phần mềm được phân phối Bây giờ chúng ta xem xét các khía cạnh kinh tế của
công nghệ phần mềm.
không đáp ứng được yêu cầu của các nhà phát triển

1.2 Khía cạnh kinh tế

Một tổ chức phần mềm hiện đang sử dụng kỹ thuật mã hóa CT

cũ phát hiện ra kỹ thuật
mã hóa mới CTmới sẽ dẫn đến việc mã được tạo ra chỉ trong chín phần mười thời gian mà
và do đó, chi phí chỉ bằng chín phần mười. Cảm giác thông thường dường như
CT cầncũ
chỉ ra rằng CT
mới là kỹ thuật thích hợp để sử dụng. Trên thực tế, mặc dù lẽ thường chắc
chắn chỉ ra rằng
6Chương 1Phạm vi của Công nghệ phần mềm

kỹ thuật được lựa chọn càng nhanh thì tính kinh tế của công nghệ phần mềm có thể hàm ý
điều ngược lại.
 mã hóa đó nhanh hơn 10%
•Một lý do là chi phí đưa công nghệ mới vào tổ chức. Sự thật
khi sử dụng kỹ thuật CT
mớiđược sử dụng có thể ít quan trọng hơn chi phí phát sinh khi
giới thiệu CTmới vào tổ chức. Có thể cần phải hoàn thành hai hoặc ba dự án trước khi
tham gia khóa học về CT
thu hồi chi phí đào tạo. Ngoài ra, trong khi mới, nhân viên
phần mềm không thể làm việc hiệu quả. Ngay cả khi họ quay trở lại, họ có thể phải trải
qua một chặng đường học tập dốc; có thể phải mất nhiều tháng luyện tập với
CTmớitrước khi các chuyên gia phần mềm trở nên thành thạo với CTmới như hiện tại họ
đang làm việc với CTcũ . Vì vậy, những dự án ban đầu sử dụng CTmới có thể mất nhiều
thời gian hơn để hoàn thành so với việc tổ chức tiếp tục sử dụng CTcũ. Tất cả những chi
phí này cần phải được tính đến khi quyết định có nên chuyển sang CT hay khôngmới.
•Lý do thứ hai tại sao tính kinh tế của công nghệ phần mềm có thể chỉ ra rằng CTcũ được
giữ lại là kết quả duy trì. Kỹ thuật mã hóa CTmớithực sự có thể nhanh hơn 10% so với
CTcũvà mã kết quả có thể có chất lượng tương đương xét từ quan điểm đáp ứng nhu
cầu hiện tại của khách hàng. Nhưng việc sử dụng kỹ thuật CTmới có thể dẫn đến mã khó
bảo trì, khiến chi phí của CTmớicao hơn trong suốt vòng đời của sản phẩm. Tất nhiên,
nếu nhà phát triển phần mềm không chịu trách nhiệm về bất kỳ hoạt động bảo trì sau
giao hàng nào thì theo quan điểm của chính nhà phát triển đó, CTmới là một đề xuất hấp
dẫn hơn. Tóm lại, việc sử dụng CTmới sẽ có giá thấp hơn 10%. Khách hàng nên nhấn
mạnh rằng kỹ thuật CTcũ được sử dụng và trả chi phí ban đầu cao hơn với mong muốn
tổng chi phí trọn đời của phần mềm sẽ thấp hơn. Thật không may, mục đích duy nhất
của cả khách hàng và nhà cung cấp phần mềm thường là tạo ra mã càng nhanh càng tốt.
Những tác động lâu dài của việc sử dụng một kỹ thuật cụ thể thường bị bỏ qua vì lợi
ích ngắn hạn. Việc áp dụng các nguyên tắc kinh tế vào công nghệ phần mềm đòi hỏi
khách hàng phải lựa chọn các kỹ thuật giúp giảm chi phí dài hạn.
Ví dụ này đề cập đến mã hóa, chiếm ít hơn 10% nỗ lực phát triển phần mềm. Tuy nhiên,
các nguyên tắc kinh tế cũng áp dụng cho tất cả các khía cạnh khác của sản xuất phần
mềm.
Bây giờ chúng tôi xem xét tầm quan trọng của việc bảo trì.

1.3 Các khía cạnh bảo trì

Trong phần này, chúng tôi mô tả việc bảo trì trong bối cảnh vòng đời phần mềm.
MỘTmô hình vòng đờilà mô tả các bước cần thực hiện khi xây dựng một sản phẩm
phần mềm. Nhiều mô hình vòng đời khác nhau đã được đề xuất; một vài trong số chúng
được mô tả trong Chương 2. Bởi vì việc thực hiện một chuỗi các nhiệm vụ nhỏ hầu như
luôn dễ dàng hơn so với một nhiệm vụ lớn nên mô hình vòng đời tổng thể được chia thành
một loạt các bước nhỏ hơn, được gọi làgiai đoạn. Số lượng pha thay đổi tùy theo mẫu
máy—từ ít nhất là bốn đến nhiều nhất là tám. Ngược lại với mô hình vòng đời, mô hình
mô tả lý thuyết về những gì nên làm, chuỗi bước thực tế được thực hiện trên một sản
phẩm phần mềm cụ thể, từ khám phá ý tưởng cho đến ngừng hoạt động cuối cùng, được
gọi là mô hình vòng đời.vòng đờicủa sản phẩm đó. Trong thực tế, các giai đoạn trong
vòng đời của một sản phẩm phần mềm có thể không được thực hiện chính xác như được
chỉ định trong mô hình vòng đời, đặc biệt khi vượt quá thời gian và chi phí.
Chương 1Phạm vi của Công nghệ phần mềm7
của vòng đời cổ điển
người mẫu.
HÌNH 1.2 2. Giai đoạn phân tích (đặc tả)
Sáu giai đoạn
3. Giai đoạn thiết kế
1. Giai đoạn yêu cầu
4. Giai đoạn thực hiện
đoạn xác định. Vào cuối giai đoạn này, một kế
hoạch được lập ra,kế hoạch quản lý dự án phần
5. Bảo trì sau giao hàng mềm, mô tả đầy đủ chi tiết việc phát triển phần mềm
6. Nghỉ hưu được đề xuất.
3.Giai đoạn thiết kế. Các thông số kỹ thuật trải qua
hai quy trình thiết kế liên tiếp trong quá trìnhgiai
đoạn thiết kế. Đầu tiên đếnthiết kế kiến ​trúc,
đang gặp phải. Người ta khẳng định rằng nhiều dự án trong đó toàn bộ sản phẩm được chia thành các thành
phần mềm gặp trục trặc vì thiếu thời gian hơn tất cả phần, được gọi làmô-đun. Sau đó, mỗi mô-đun được
các lý do khác cộng lại [Brooks, 1975]. thiết kế; thủ tục này được gọi làthiết kế chi tiết.
Cho đến cuối những năm 1970, hầu hết các tổ chức Hai kết quảtài liệu thiết kếmô tả “sản phẩm hoạt
đều sản xuất phần mềm bằng cách sử dụng mô hình động như thế nào”.
vòng đời của họ mà ngày nay được gọi làMô hình
4.Giai đoạn thực hiện. Các thành phần khác nhau
thác nước. Có nhiều biến thể của mô hình này,
trải quamã hóavà thử nghiệm (kiểm tra đơn vị)
nhưng nhìn chung, một sản phẩm được phát triển
riêng biệt. Sau đó, các thành phần của sản phẩm được
bằng mô hình vòng đời cổ điển này sẽ trải qua sáu
kết hợp và thử nghiệm tổng thể; điều này được gọi
giai đoạn như trong Hình 1.2. Những giai đoạn này
làhội nhập. Khi các nhà phát triển hài lòng rằng sản
có thể không tương ứng chính xác với các giai đoạn
phẩm hoạt động chính xác, nó sẽ được khách hàng
của bất kỳ một tổ chức cụ thể nào, nhưng chúng đủ
kiểm tra (kiểm tra chấp nhận). Cácdụng cụ
gần với hầu hết các hoạt động phục vụ mục đích của
cuốn sách này. Tương tự, tên chính xác của từng giai giai đoạn chuyển độngkết thúc khi sản phẩm
được khách hàng chấp nhận và cài đặt trên máy tính
đoạn cũng khác nhau tùy theo tổ chức. Những cái tên
của khách hàng. (Chúng ta thấy trong Chương 15
được sử dụng ở đây cho các giai đoạn khác nhau đã
rằng mã hóa và tích hợp nên được thực hiện song
được chọn sao cho càng chung chung càng tốt với hy
song.)
vọng rằng người đọc sẽ cảm thấy thoải mái với
chúng. 5.Bảo trì sau giao hàng.Sản phẩm được sử dụng để
thực hiện các nhiệm vụ mà nó được phát triển. Trong
1.Giai đoạn yêu cầuTrong thời giangiai đoạn yêu thời gian này, nó được duy trì.Bảo trì sau giao
cầu, khái niệm này được khám phá và cải tiến, đồng hàngbao gồm tất cả các thay đổi đối với sản phẩm
thời gợi ra các yêu cầu của khách hàng. sau khi sản phẩm đã được giao và cài đặt trên máy
2.Giai đoạn phân tích (đặc tả).Các yêu cầu của tính của khách hàng và vượt qua bài kiểm tra chấp
khách hàng được phân tích và trình bày dưới dạngtài nhận. Bảo trì sau giao hàng
liệu thiết kế, “sản phẩm sẽ làm được những gì.”
Cácgiai đoạn phân tíchđôi khi được gọi làgiai

Chỉ trong trường hợp bạn muốn biếtHộp 1.3

Một trong những kết quả được trích dẫn rộng rãi nhất trong công nghệ phần mềm là
17,4% nỗ lực bảo trì sau giao hàng có tính chất khắc phục; 18,2 phần trăm là thích ứng;
60,3 phần trăm là hoàn hảo; và 4,1 phần trăm có thể được phân loại là “khác”. Kết quả này
được lấy từ một bài báo xuất bản năm 1978 [Lientz, Swanson, và Tompkins, 1978].
Tuy nhiên, kết quả trong bài báo đó không bắt nguồn từđovề dữ liệu bảo trì. Thay vào đó,
các tác giả đã tiến hành một cuộc khảo sát các nhà quản lý bảo trì, những người được
yêu cầuước lượngbao nhiêu thời gian đã được dành cho từng hạng mục trong toàn bộ tổ
chức của họ và cho biết họ cảm thấy tự tin như thế nào về ước tính của mình. Cụ thể hơn,
những người quản lý bảo trì phần mềm tham gia được hỏi liệu phản hồi của họ dựa trên
dữ liệu có độ chính xác hợp lý, dữ liệu tối thiểu hay không có dữ liệu; 49,3% cho biết câu
trả lời của họ dựa trên dữ liệu khá chính xác, 37,7% dựa trên dữ liệu tối thiểu và 8,7%
không có dữ liệu.
Trên thực tế, người ta nên nghiêm túc đặt câu hỏi liệu có người trả lời nào có “dữ liệu
chính xác hợp lý” về phần trăm thời gian dành cho các hạng mục bảo trì được đưa vào
cuộc khảo sát hay không; hầu hết trong số họ có lẽ thậm chí không có “dữ liệu tối thiểu”.
Trong cuộc khảo sát đó, những người tham gia được yêu cầu cho biết tỷ lệ phần trăm bảo
trì bao gồm các hạng mục như “sửa chữa khẩn cấp” hoặc “gỡ lỗi định kỳ”; từ thông tin thô
này, tỷ lệ bảo trì thích ứng, khắc phục và hoàn thiện đã được suy ra. Công nghệ phần
mềm mới bắt đầu nổi lên như một môn học vào năm 1978, và đó là ngoại lệ đối với các
nhà quản lý bảo trì phần mềm để thu thập thông tin chi tiết cần thiết để đáp ứng cuộc khảo
sát như vậy. Quả thực, theo thuật ngữ hiện đại, vào năm 1978 hầu như mọi tổ chức vẫn ở
CMM cấp độ 1 (xem Phần 3.13).
Do đó, chúng tôi có cơ sở vững chắc để đặt câu hỏi liệu việc phân bổ thực tế các hoạt
động bảo trì sau giao hàng vào năm 1978 có giống với ước tính của những người đàn ông
tham gia cuộc khảo sát hay không. Việc phân bổ các hoạt động bảo trì chắc chắn không
giống như ngày nay. Ví dụ, kết quả về dữ liệu bảo trì thực tế cho nhân Linux [Schach và
cộng sự, 2002] và trình biên dịch gcc [Schach và cộng sự, 2003] cho thấy rằng ít nhất
50% bảo trì sau giao hàng là đúng, trái ngược với con số 17,4%. hình được tuyên bố trong
cuộc khảo sát.

bao gồmbảo trì khắc phục(hoặcsửa chữa phần mềm), bao gồm việc loại bỏ các
lỗi còn sót lại trong khi vẫn giữ nguyên các thông số kỹ thuật, cũng nhưsự nâng
cao(hoặc cập nhật phần mềm), bao gồm các thay đổi về thông số kỹ thuật và việc triển
khai những thay đổi đó. Lần lượt có hai loại nâng cao. Đầu tiên làbảo trì hoàn hảo,
những thay đổi mà khách hàng cho rằng sẽ nâng cao hiệu quả của sản phẩm, chẳng hạn
như chức năng bổ sung hoặc giảm thời gian phản hồi. Thứ hai làbảo trì thích ứng,
những thay đổi được thực hiện để đáp ứng với những thay đổi trong môi trường mà sản
phẩm hoạt động, chẳng hạn như phần cứng/hệ điều hành mới hoặc các quy định mới
của chính phủ. (Để hiểu rõ hơn về ba loại bảo trì sau giao hàng, hãy xem Ô 1.3.) Chỉ
trong trường hợp bạn muốn biết.)
6.Sự nghỉ hưu.Sự nghỉ hưuxảy ra khi sản phẩm bị loại bỏ khỏi dịch vụ. Điều này xảy
ra khi chức năng do sản phẩm cung cấp không còn hữu ích cho tổ chức khách hàng
nữa.
Bây giờ chúng ta xem xét định nghĩa củaBẢO TRÌchi tiết hơn.
Chương 1Phạm vi của Công nghệ phần mềm9

1.3.1Quan điểm cổ điển và hiện đại về bảo trìVào những năm 1970,
sản xuất phần mềm được coi là bao gồm hai hoạt động riêng biệt được thực hiện tuần
tự:phát triểntheo dõi bởiBẢO TRÌ. Bắt đầu từ đầu, sản phẩm phần mềm được phát triển và
sau đó được cài đặt trên máy tính của khách hàng. Bất kỳ thay đổi nào đối với phần mềm
sau khi cài đặt trên máy tính của khách hàng và được khách hàng chấp nhận, dù là để khắc
phục lỗi còn sót lại hay mở rộng chức năng, đều được coi là bảo trì cổ điển [IEEE 610.12,
1990]. Do đó, cách phần mềm được phát triển một cách cổ điển có thể được mô tả làmô
hình phát triển-sau-bảo trì.
Đây là mộtđịnh nghĩa thời gian; nghĩa là, một hoạt động được phân loại là hoạt
động phát triển hoặc hoạt động chính tùy thuộc vào thời điểm nó được thực hiện. Giả sử
một lỗi trong phần mềm được phát hiện và sửa chữa một ngày sau khi phần mềm được cài
đặt. Theo định nghĩa, điều này tạo nên sự bảo trì cổ điển. Nhưng nếu lỗi tương tự được
phát hiện và sửa chữa một ngày trước khi phần mềm được cài đặt, về mặt định nghĩa, đây
là sự phát triển cổ điển. Bây giờ giả sử một sản phẩm phần mềm vừa được cài đặt nhưng
khách hàng muốn tăng thêm chức năng của sản phẩm phần mềm. Về mặt cổ điển, điều đó
được mô tả là sự bảo trì hoàn hảo. Tuy nhiên, nếu khách hàng muốn thực hiện thay đổi
tương tự ngay trước khi cài đặt sản phẩm phần mềm thì đây sẽ là cách phát triển cổ điển.
Một lần nữa, không có sự khác biệt nào giữa bản chất của hai hoạt động, nhưng về mặt cổ
điển, một hoạt động được coi là phát triển, hoạt động còn lại được coi là duy trì hoàn hảo.
Ngoài những mâu thuẫn như vậy, còn có hai lý do khác giải thích tại sao mô hình phát
triển sau đó bảo trì ngày nay không thực tế:
1. Ngày nay, việc xây dựng một sản phẩm phải mất một năm hoặc hơn chắc chắn không
phải là điều bất thường. Trong thời gian này, yêu cầu của khách hàng có thể thay đổi.
Ví dụ: khách hàng có thể yêu cầu rằng sản phẩm hiện phải được triển khai trên bộ xử lý
 nhanh hơn vừa mới ra mắt. Ngoài ra, tổ chức khách hàng có thể đã mở rộng sang Bỉ
trong khi quá trình phát triển đang được tiến hành và sản phẩm hiện phải được sửa đổi
để có thể xử lý việc bán hàng ở Bỉ. Để xem sự thay đổi trong yêu cầu có thể ảnh hưởng
như thế nào đến vòng đời phần mềm, giả sử rằng yêu cầu của khách hàng thay đổi
trong khi thiết kế đang được phát triển. Nhóm kỹ thuật phần mềm phải tạm dừng việc
phát triển và sửa đổi tài liệu đặc tả để phản ánh các yêu cầu đã thay đổi. Hơn nữa, sau
đó cũng có thể cần phải sửa đổi thiết kế nếu những thay đổi về thông số kỹ thuật đòi
hỏi những thay đổi tương ứng đối với những phần của thiết kế đã hoàn thành. Chỉ khi
những thay đổi này được thực hiện thì sự phát triển mới có thể tiếp tục. Nói cách khác,
các nhà phát triển phải thực hiện “bảo trì” rất lâu trước khi sản phẩm được cài đặt.
2. Vấn đề thứ hai với mô hình phát triển-sau-bảo trì cổ điển nảy sinh do cách thức chúng
ta xây dựng phần mềm hiện nay. Trong công nghệ phần mềm cổ điển, một đặc điểm
của quá trình phát triển là nhóm phát triển đã xây dựng sản phẩm mục tiêu ngay từ đầu.
Ngược lại, do chi phí sản xuất phần mềm cao nên
Ngày nay, bất cứ khi nào có thể, các nhà phát triển đều cố gắng sử dụng lại các phần
của sản phẩm phần mềm hiện có trong sản phẩm phần mềm sẽ được xây dựng (việc tái
sử dụng được thảo luận chi tiết trong Chương 8). Vì vậy, mô hình phát triển-sau-bảo trì
ngày nay không phù hợp vì việc tái sử dụng quá phổ biến.
Một cách thực tế hơn để xem xét việc bảo trì được đưa ra trong tiêu chuẩn dành cho các
quy trình vòng đời do Tổ chức Tiêu chuẩn hóa Quốc tế (ISO) công bố.

Chỉ trong trường hợp bạn muốn biếtÔ 1.4

Tổ chức Tiêu chuẩn hóa Quốc tế (ISO) là một mạng lưới các viện tiêu chuẩn quốc gia của
147 quốc gia, với ban thư ký trung ương có trụ sở tại Geneva, Thụy Sĩ. ISO đã xuất bản
hơn 13.500 tiêu chuẩn được quốc tế chấp nhận, từ các tiêu chuẩn về tốc độ quay phim
ảnh (“số ISO”) cho đến nhiều tiêu chuẩn được trình bày trong cuốn sách này. Ví dụ, ISO
9000 được thảo luận ở Chương 3.
ISO không phải là từ viết tắt. Nó có nguồn gốc từ tiếng Hy Lạp, có nghĩa làbình đẳng, gốc
của tiền tố tiếng Anh xiso- tìm thấy trong những từ nhưđồng vị,đẳng áp, Vàcân. Tổ chức
Tiêu chuẩn hóa Quốc tế đã chọn ISO làm tên viết tắt để tránh có nhiều từ viết tắt phát sinh
từ việc dịch tên “Tổ chức Tiêu chuẩn hóa Quốc tế” sang ngôn ngữ của các quốc gia thành
viên khác nhau. Thay vào đó, để đạt được tiêu chuẩn quốc tế, một dạng viết tắt phổ biến
của tên nó đã được chọn.

và Ủy ban Kỹ thuật Điện Quốc tế (IEC). Nghĩa là, bảo trì là quá trình xảy ra khi “phần
mềm trải qua các sửa đổi về mã và tài liệu liên quan do có vấn đề hoặc nhu cầu cải tiến
hoặc thích ứng” [ISO/IEC 12207, 1995]. Về mặt nàyđịnh nghĩa hoạt động, việc bảo
trì diễn ra bất cứ khi nào một lỗi được khắc phục hoặc các yêu cầu thay đổi, bất kể việc
này diễn ra trước hay sau khi lắp đặt sản phẩm. Viện Kỹ sư Điện và Điện tử (IEEE) và
Liên minh Công nghiệp Điện tử (EIA) sau đó đã áp dụng định nghĩa này [IEEE/EIA
12207.0-1996, 1998] khi các tiêu chuẩn IEEE được sửa đổi để tuân thủ ISO/IEC 12207.
(Xem phần Chỉ trong trường hợp bạn muốn biết Ô 1.4 để biết thêm về ISO.)
Trong cuốn sách này, thuật ngữbảo trì sau giao hàngđề cập đến định nghĩa của IEEE năm
1990 về bảo trì là bất kỳ thay đổi nào đối với phần mềm sau khi nó được chuyển giao và
cài đặt trên máy tính của khách hàng, vàbảo trì hiện đạihoặc chỉBẢO TRÌđề cập đến định
nghĩa của ISO/IEC năm 1995 về các hoạt động khắc phục, hoàn thiện hoặc thích ứng
được thực hiện vào bất kỳ lúc nào. Do đó, bảo trì sau giao hàng là một tập hợp con của
bảo trì (hiện đại).

1.3.2Tầm quan trọng của việc bảo trì sau giao hàng
 Đôi khi người ta nói rằng chỉ những sản phẩm phần mềm xấu mới được bảo trì sau khi
giao hàng. Trên thực tế, điều ngược lại mới đúng: Sản phẩm xấu bị vứt đi, trong khi sản
phẩm tốt được sửa chữa và nâng cấp trong 10, 15 hoặc thậm chí 20 năm. Hơn nữa, sản
phẩm phần mềm là mô hình của thế giới thực và thế giới thực luôn thay đổi. Do đó, phần
mềm phải được bảo trì liên tục để phản ánh chính xác thế giới thực.
Chẳng hạn, nếu thuế suất bán hàng thay đổi từ 6 lên 7 phần trăm, hầu hết mọi sản phẩm
phần mềm liên quan đến mua hoặc bán đều phải thay đổi. Giả sử sản phẩm chứa câu lệnh
C++
const phao yến mạchthuế bán hàng 6.0;
hoặc câu lệnh Java tương đương
yến mạch cuối cùng tĩnh công khaithuế doanh thu(trôi nổi)6,0;
của trình soạn thảo văn bản, giá trị6.0được thay thế
bởi7,0và mã được biên dịch lại và liên kết lại. Tuy
nhiên, nếu thay vì sử dụng tênthuế doanh thu, giá trị
thực tế6.0đã được sử dụng trong sản phẩm mà giá trị
của thuế bán hàng được viện dẫn thì sản phẩm đó cực
kỳ khó sửa đổi. Ví dụ: có thể xuất hiện giá trị6.0trong
mã nguồn cần được thay đổi thành7,0nhưng bị bỏ
qua, hoặc các trường hợp6.0không đề cập đến thuế
bán hàng nhưng bị thay đổi không chính xác
thành7,0. Việc tìm ra những lỗi này hầu như luôn khó
khăn và tốn thời gian. Trên thực tế, với một số phần
mềm, về lâu dài, việc vứt bỏ sản phẩm và mã hóa lại
nó có thể ít tốn kém hơn thay vì cố gắng xác định
hằng số nào trong số nhiều hằng số cần được thay đổi
và cách thực hiện các sửa đổi.
Thế giới thực theo thời gian thực cũng liên tục thay
đổi. Các tên lửa mà máy bay chiến đấu phản lực được
trang bị có thể được thay thế bằng một mẫu mới, đòi
hỏi phải thay đổi bộ phận kiểm soát vũ khí của hệ
thống điện tử hàng không liên quan. Động cơ sáu
xi-lanh sẽ được cung cấp như một tùy chọn trên ô tô
bốn xi-lanh phổ biến; điều này ngụ ý việc thay đổi các
máy tính trên tàu điều khiển hệ thống phun nhiên liệu,
thời gian, v.v.
Nhưng bao nhiêu thời gian (= tiền) được dành cho
việc bảo trì sau giao hàng? Biểu đồ hình tròn trong
Hình 1.3(a) cho thấy rằng, khoảng 40 năm trước,
khoảng 2/3 tổng chi phí phần mềm dành cho việc bảo
trì sau chuyển giao; dữ liệu thu được bằng cách lấy
trung bình thông tin từ nhiều nguồn khác nhau, bao
gồm [Elshoff, 1976], [Daly, 1977], [Zelkowitz, Shaw,
và Gannon, 1979], và [Boehm, 1981]. Dữ liệu mới
hơn cho thấy rằng một chuyên gia thậm chí còn lớn
hơn
phần được dành cho việc bảo trì sau giao hàng. Nhiều
HÌNH 1.3Ước tính phần trăm chi phí trung bình của tổ chức dành 70–80 phần trăm hoặc nhiều hơn ngân
Chương 1Phạm vi của Công nghệ phần mềm11 sách phần mềm của họ cho việc bảo trì sau chuyển
giao [Yourdon, 1992; Hatton, 1998], như thể hiện
tuyên bố rằngthuế doanh thulà hằng số dấu phẩy trong Hình 1.3(b) .
động được khởi tạo bằng giá trị6.0.Trong trường hợp Đáng ngạc nhiên là tỷ lệ phần trăm chi phí trung bình
này, việc bảo trì tương đối đơn giản. Với sự trợ giúp của các giai đoạn phát triển cổ điển hầu như không
thay đổi. Điều này được thể hiện trong Hình 1.4, so
sánh dữ liệu được sử dụng để rút ra Hình 1.3(a) với
dữ liệu gần đây hơn về 132 dự án của
Hewlett-Packard [Grady, 1994].

Phát triển
phát triển và bảo trì sau giao 33% 25%
hàng (a) giữa
1976 và 1981 và (b) giữa năm Bưu phẩm đã được giao
1992 và 1998. Bưu phẩm đã được giao BẢO TRÌ
Phát triển BẢO TRÌ 75%
67%

(a) (b)
12Chương 1Phạm vi của Công nghệ phần mềm

HÌNH 1.4So sánh tỷ lệ phần trăm chi phí trung bình gần đúng của cổ điển
giai đoạn phát triển cho các dự án khác nhau từ năm 1976 đến năm 1981 và cho 132 dự án gần
 đây của Hewlett Packard.

Các dự án khác nhau 132 Gần đây hơn Các dự án của Hewlett-Packard từ năm 1976 đến
năm 1981
Yêu cầu và phân tích 21% 18%
(đặc điểm kỹ thuật) giai đoạn
Giai đoạn thiết kế 18 19
Giai đoạn thực hiện
Mã hóa (bao gồm cả kiểm thử đơn vị) 36 34
Tích hợp 24 29

Bây giờ hãy xem xét lại tổ chức phần mềm hiện đang sử dụng kỹ thuật mã hóa CTcũ biết
sẽ giảm thời gian mã hóa xuống 10 phần trăm. Ngay cả khi CT không
được rằng CTmới mới
có quảng cáo
ảnh hưởng đến việc bảo trì, một người quản lý phần mềm sắc sảo sẽ suy nghĩ
kỹ trước khi thay đổi cách viết mã. Toàn bộ nhân viên phải được đào tạo lại, mua các công
cụ phát triển phần mềm mới và có thể thuê thêm những nhân viên có kinh nghiệm về kỹ
thuật mới. Tất cả chi phí và sự gián đoạn này phải được chịu đựng để giảm tối đa 0,85
phần trăm chi phí phần mềm bởi vì, như trong Hình 1.3(b) và 1.4, mã hóa cùng với kiểm
thử đơn vị chỉ chiếm trung bình 34% của 25% hoặc 8,5% tổng chi phí phần mềm.
Bây giờ giả sử một kỹ thuật mới giúp giảm 10% chi phí bảo trì sau giao hàng được phát
triển. Điều này có lẽ nên được áp dụng ngay lập tức vì tính trung bình, nó sẽ giảm chi phí
tổng thể xuống 7,5%. Chi phí chung liên quan đến việc thay đổi kỹ thuật này là một cái
giá nhỏ phải trả cho khoản tiết kiệm tổng thể lớn như vậy.
Bởi vì bảo trì sau giao hàng rất quan trọng nên một khía cạnh chính của công nghệ phần
mềm bao gồm các kỹ thuật, công cụ và thực hành dẫn đến giảm chi phí bảo trì sau giao
hàng.

1.4 Các khía cạnh yêu cầu, phân tích và thiết kế

Các chuyên gia phần mềm cũng là con người và do đó đôi khi mắc sai lầm khi phát triển
sản phẩm. Kết quả là phần mềm sẽ bị lỗi. Nếu mắc lỗi trong khi đưa ra các yêu cầu thì lỗi
dẫn đến có thể cũng sẽ xuất hiện trong các thông số kỹ thuật, thiết kế và mã. Rõ ràng,
chúng ta sửa lỗi càng sớm thì càng tốt.
Chi phí tương đối của việc sửa lỗi ở các giai đoạn khác nhau trong vòng đời phần mềm cổ
điển được thể hiện trong Hình 1.5 [Boehm, 1981]. Hình này phản ánh dữ liệu từ IBM
[Fagan, 1974], GTE [Daly, 1977], dự án Safeguard [Stephenson, 1976] và một số dự án
TRW nhỏ hơn [Boehm, 1980]. Đường liền nét trong Hình 1.5 là phù hợp nhất cho dữ liệu
liên quan đến các dự án lớn hơn và đường đứt nét là phù hợp nhất cho các dự án nhỏ hơn.
Đối với mỗi giai đoạn của vòng đời phần mềm cổ điển, chi phí tương ứng để phát hiện và
sửa lỗi
Chương 1Phạm vi của Công nghệ phần mềm13

HÌNH 1.5Chi phí tương đối của việc sửa lỗi ở mỗi giai đoạn của vòng đời phần mềm cổ điển.
Đường liền nét là phù hợp nhất cho dữ liệu liên quan đến các dự án phần mềm lớn hơn và đường
đứt nét là phù hợp nhất cho các dự án phần mềm nhỏ hơn. (Barry Boehm,Kinh tế kỹ thuật phần
mềm,© 1981, tr. 40. Được điều chỉnh dưới sự cho phép của Prentice Hall, Inc., Englewood Cliffs,
NJ.)
 50 80% phần mềm
Trung bình
(khảo sát TRW)
nhỏ
20
20% hơn[Boehm,
10 BẢO VỆ
tôi
1980]
TRONG
5
Một

là 2
Các dự án
ồ

t
ts

c phần mềm lớn

Nó là
hơnIBM-SSD
TRONG
Nó
Một

các
R

1000 500

200 100 GTE

Các dự án
điểm kỹ thuật
1 Kiểm tra chấp
Yêu cầu và đặc Thực hiện nhận
Thiết kế Hội nhập BẢO TRÌ
Giai đoạn phát hiện lỗi và sửa chữa

lỗi được mô tả trong hình 1.6. Mỗi bước trên đường liền nét trong Hình 1.6 được xây
dựng bằng cách lấy điểm tương ứng trên đường thẳng liền nét của Hình 1.5 và vẽ dữ liệu
theo tỷ lệ tuyến tính.
Giả sử chi phí là 40 USD để phát hiện và sửa một lỗi cụ thể trong giai đoạn thiết kế. Từ
đường liền nét trong Hình 1.6 (các dự án từ năm 1974 đến năm 1980), lỗi tương tự đó sẽ
chỉ tốn khoảng 30 USD để sửa chữa trong giai đoạn phân tích. Nhưng trong quá trình bảo
trì sau giao hàng, lỗi đó sẽ tốn khoảng 2000 USD để phát hiện và sửa chữa. Dữ liệu mới
hơn cho thấy rằng việc phát hiện lỗi sớm thậm chí còn quan trọng hơn. Đường đứt nét
trong Hình 1.6 cho thấy chi phí phát hiện và sửa lỗi trong quá trình phát triển phần mềm
hệ thống cho IBM AS/400 [Kan et al., 1994]. Trung bình, cùng một lỗi sẽ tiêu tốn 3680
USD để sửa chữa trong quá trình bảo trì sau khi giao hàng phần mềm AS/400.
Lý do khiến chi phí sửa lỗi tăng cao liên quan đến những gì phải làm để sửa lỗi. Trong
giai đoạn đầu của vòng đời phát triển, sản phẩm về cơ bản chỉ tồn tại trên giấy và việc sửa
lỗi có thể chỉ đơn giản là thực hiện thay đổi đối với tài liệu. Thái cực còn lại là sản phẩm
đã được giao cho khách hàng. Ít nhất, sửa lỗi lúc đó có nghĩa là chỉnh sửa mã, biên dịch
lại và liên kết lại, sau đó quan tâm.
kiểm tra đầy đủ rằng vấn đề đã được giải quyết. Tiếp theo, điều quan trọng là phải kiểm
tra xem việc thực hiện thay đổi có tạo ra vấn đề mới ở nơi khác trong sản phẩm hay
không. Tất cả các tài liệu liên quan, bao gồm cả sách hướng dẫn, cần phải được cập nhật.
Cuối cùng, sản phẩm đã sửa phải được giao
14Chương 1Phạm vi của Công nghệ phần mềm
Đường đứt nét ồ

t
t

Một
r
100 50
ồ

mô tả dữ liệu c

HÌNH t
tôi

mới hơn. S Tôi

1.6Đường liền ồ
x
d

N
Các dự án từ
c ồ

nét mô tả các r Một năm 1974 đến

điểm trên đường Nó là
trang
MỘT
400 350 300 1980 IBM
TRONG tôi

liền nét của t

Tôi

t
AS/400 [Kan và
cộng sự,1994]
TRONG

Hình 1.5 được c

Nó là
Một

tôi
Một

f
250 200 150
vẽ theo tỷ lệ t Nó là Một

Nó là r

tuyến tính. d
tc
Nó là
Nó là
r
 368

52
30

200

134
Thiết kế phân tích hàng
Triển khai sau giao
Yêu cầu
(sự chỉ rõ) BẢO TRÌ

và được cài đặt lại. Ý nghĩa của câu chuyện là thế này: Chúng ta phải sớm tìm ra lỗi lầm,
nếu không chúng ta sẽ phải trả giá đắt. Do đó, chúng ta nên sử dụng các kỹ thuật để phát
hiện lỗi trong các giai đoạn yêu cầu và phân tích (đặc tả).
Có một nhu cầu hơn nữa cho các kỹ thuật như vậy. Các nghiên cứu đã chỉ ra [Boehm,
1979] rằng khoảng 60 đến 70 phần trăm tất cả các lỗi được phát hiện trong các dự án lớn
là lỗi về yêu cầu, phân tích hoặc thiết kế. Các kết quả mới hơn từ các cuộc kiểm tra chứng
minh ưu thế này của các yêu cầu, phân tích hoặc lỗi thiết kế (kiểm tra là việc kiểm tra tỉ
mỉ tài liệu của một nhóm, như được mô tả trong Phần 6.2.3). Trong 203 lần kiểm tra phần
mềm Phòng thí nghiệm Sức đẩy Phản lực dành cho chuyên gia không gian liên hành tinh
không người lái của NASA
gram, trung bình, khoảng 1,9 lỗi được phát hiện trên mỗi trang của tài liệu đặc tả, 0,9 lỗi
trên mỗi trang của thiết kế, nhưng chỉ có 0,3 lỗi trên mỗi trang mã [Kelly, Sherif, và Hops,
1992].
Vì vậy, điều quan trọng là chúng ta phải cải thiện các yêu cầu, kỹ thuật phân tích và thiết
kế của mình, không chỉ để có thể tìm thấy lỗi càng sớm càng tốt mà còn vì các lỗi yêu cầu,
phân tích và thiết kế chiếm tỷ lệ lớn trong tất cả các lỗi. Đúng như ví dụ ở Phần 1.3 cho
thấy rằng việc giảm 10% chi phí bảo trì sau giao hàng sẽ giúp giảm tổng chi phí khoảng
7,5%, giảm các yêu cầu, phân tích và thiết kế.
lỗi 10 phần trăm làm giảm tổng số lỗi từ 6–7 phần trăm. Việc có quá nhiều lỗi xuất hiện
sớm trong vòng đời phần mềm làm nổi bật một khía cạnh quan trọng khác của công nghệ
phần mềm: các kỹ thuật mang lại yêu cầu, thông số kỹ thuật và thiết kế tốt hơn.
Hầu hết phần mềm được sản xuất bởi một nhóm kỹ sư phần mềm chứ không phải bởi một
cá nhân duy nhất chịu trách nhiệm về mọi khía cạnh của vòng đời phát triển và bảo trì.
Bây giờ chúng ta xem xét ý nghĩa của việc này.
nhóm
Chương 1Phạm vi của Công nghệ phần mềm15
1.5 Các khía cạnh phát triển

Chi phí phần cứng tiếp tục giảm nhanh chóng. Một chiếc máy tính lớn của những năm
1950 có giá hơn một triệu đô la trước lạm phát sẽ kém mạnh hơn về mọi mặt so với một
chiếc máy tính xách tay ngày nay có giá dưới 1000 đô la. Kết quả là, các tổ chức dễ dàng
 có đủ khả năng mua phần cứng có thể chạy các sản phẩm lớn, tức là các sản phẩm quá lớn
(hoặc quá phức tạp) để một người có thể triển khai trong giới hạn thời gian cho phép. Ví
dụ: nếu một sản phẩm phải được giao trong vòng 18 tháng nhưng sẽ cần một phần mềm
duy nhất
sional 15 năm để hoàn thành thì sản phẩm phải được một nhóm phát triển. Tuy nhiên, việc
phát triển nhóm dẫn đến các vấn đề về giao tiếp giữa các thành phần mã và các vấn đề về
giao tiếp giữa các thành viên trong nhóm.
Ví dụ: mô-đun mã Jeff và JulietPVàq, tương ứng, trong đó mô-đunPmô-đun cuộc gọiq.
Khi Jeff viết mãP, anh ấy chèn một cuộc gọi đếnqvới năm đối số trong danh sách đối số.
Mã Julietqvới năm lập luận, nhưng theo thứ tự khác với thứ tự của Jeff. Một số công cụ
phần mềm, chẳng hạn như trình thông dịch và trình tải Java, hoặcxơ vảiđối với C (Phần
8.11.4), hãy phát hiện vi phạm loại đó nhưng chỉ khi các đối số được hoán đổi có khác
biệt
các loại khác nhau; nếu chúng cùng loại thì vấn đề có thể không được phát hiện trong một
thời gian dài. Có thể tranh luận rằng đây là một vấn đề về thiết kế và nếu các mô-đun
được thiết kế cẩn thận hơn thì vấn đề này đã không xảy ra. Điều đó có thể đúng, nhưng
trong thực tế, một thiết kế thường bị thay đổi sau khi bắt đầu viết mã và thông báo về sự
thay đổi có thể không được phân phối tới tất cả các thành viên của nhóm phát triển. Do
đó, khi một thiết kế ảnh hưởng đến hai hoặc nhiều lập trình viên bị thay đổi, kết quả kém.
giao tiếp có thể dẫn đến các vấn đề về giao diện mà Jeff và Juliet gặp phải. Loại vấn đề
này ít có khả năng xảy ra khi chỉ có một cá nhân chịu trách nhiệm về mọi khía cạnh của
sản phẩm, như trường hợp trước khi những chiếc máy tính mạnh mẽ có thể chạy những
sản phẩm khổng lồ trở nên có giá cả phải chăng.
Nhưng các vấn đề về giao tiếp chỉ là phần nổi của tảng băng trôi khi đề cập đến các vấn
đề có thể phát sinh khi phần mềm được phát triển bởi các nhóm. Trừ khi nhóm được tổ
chức hợp lý, nếu không sẽ lãng phí rất nhiều thời gian trong các cuộc họp giữa các thành
viên trong nhóm. Giả sử một sản phẩm cần một lập trình viên duy nhất phải mất 1 năm để
hoàn thành. Nếu cùng một nhiệm vụ được giao cho một nhóm gồm sáu lập trình viên, thời
gian hoàn thành nhiệm vụ thường xuyên sẽ gần hơn 1 năm so với 2 tháng dự kiến ​và chất
lượng của mã kết quả có thể thấp hơn so với khi toàn bộ nhiệm vụ được giao. cho một cá
nhân (xem Phần 4.1). Bởi vì một tỷ lệ đáng kể phần mềm ngày nay được các nhóm phát
triển và duy trì nên phạm vi của công nghệ phần mềm phải bao gồm các kỹ thuật để đảm
bảo rằng các nhóm được tổ chức và quản lý hợp lý.
Như đã được trình bày trong các phần trước, phạm vi của công nghệ phần mềm là vô
cùng rộng. Nó bao gồm mọi bước của vòng đời phần mềm, từ yêu cầu cho đến ngừng hoạt
động sau khi phân phối. Nó cũng bao gồm các khía cạnh con người, chẳng hạn như tổ
chức nhóm; khía cạnh kinh tế; và các khía cạnh pháp lý, chẳng hạn như luật bản quyền.
Tất cả những khía cạnh này được kết hợp ngầm trong định nghĩa về công nghệ phần mềm
được đưa ra ở đầu chương này, rằng công nghệ phần mềm là một ngành có mục tiêu là tạo
ra các phần mềm không có lỗi.
hàng hóa được giao đúng thời hạn, trong phạm vi ngân sách và đáp ứng nhu cầu của
người dùng. Chúng ta quay lại các giai đoạn cổ điển của Hình 1.2 để hỏi tại sao không có
giai đoạn lập kế hoạch, thử nghiệm hoặc ghi chép.
16Chương 1Phạm vi của Công nghệ phần mềm

1.6 Tại sao không có giai đoạn lập kế hoạch

Rõ ràng là không thể phát triển một sản phẩm phần mềm mà không có kế hoạch. Theo
đó, dường như điều cần thiết là phải có mộtgiai đoạn lập kế hoạchngay từ đầu của dự
án.
Điểm mấu chốt là, cho đến khi biết chính xác những gì sẽ được phát triển thì không có
cách nào có thể lập được một kế hoạch chi tiết, chính xác. Do đó, ba loại hoạt động lập kế
hoạch diễn ra khi một sản phẩm phần mềm được phát triển bằng cách sử dụng mô hình cổ
điển:
 1. Khi bắt đầu dự án, việc lập kế hoạch sơ bộ sẽ được thực hiện để quản lý các yêu cầu và
giai đoạn phân tích.
2. Một khi đã biết chính xác những gì sẽ được phát triển,kế hoạch quản lý dự án phần
mềm(SPMP) được soạn thảo. Điều này bao gồm ngân sách, yêu cầu về nhân sự và lịch
trình chi tiết. Thời gian sớm nhất chúng ta có thể lập kế hoạch quản lý dự án là khi tài
liệu đặc tả đã được khách hàng phê duyệt, tức là vào cuối giai đoạn phân tích. Cho đến
thời điểm đó, việc lập kế hoạch phải mang tính sơ bộ và từng phần.
3. Trong suốt dự án, ban quản lý cần giám sát SPMP và theo dõi mọi sai lệch so với kế
hoạch.
Ví dụ: giả sử SPMP cho một dự án cụ thể nêu rõ rằng toàn bộ dự án sẽ mất 16 tháng và
giai đoạn thiết kế sẽ mất 4 tháng trong số đó. Sau một năm, ban quản lý nhận thấy rằng
toàn bộ dự án dường như đang tiến triển chậm hơn nhiều so với dự đoán. Một cuộc điều
tra chi tiết cho thấy, đến nay, giai đoạn thiết kế đã được dành 8 tháng, vẫn chưa hoàn
thành. Dự án gần như chắc chắn sẽ phải bị bỏ dở và số tiền bỏ ra cho đến nay sẽ bị lãng
phí. Thay vào đó, ban quản lý lẽ ra phải theo dõi tiến độ theo từng giai đoạn và nhận thấy,
sau tối đa 2 tháng, một vấn đề nghiêm trọng trong giai đoạn thiết kế. Vào thời điểm đó,
một quyết định có thể đã được đưa ra về cách tốt nhất để tiến hành. Bước đầu tiên thông
thường trong tình huống như vậy là gọi tư vấn để xác định xem dự án có khả thi hay
không và xác định xem nhóm thiết kế có đủ năng lực để thực hiện nhiệm vụ hay rủi ro khi
tiến hành là quá lớn. Dựa trên báo cáo của nhà tư vấn, nhiều giải pháp thay thế khác nhau
hiện đang được xem xét, bao gồm giảm phạm vi của sản phẩm mục tiêu, sau đó thiết kế và
triển khai một sản phẩm ít tham vọng hơn. Chỉ khi tất cả các lựa chọn thay thế khác được
coi là không thể thực hiện được thì dự án mới phải bị hủy bỏ. Trong trường hợp của một
dự án cụ thể, việc hủy bỏ này lẽ ra đã diễn ra sớm hơn khoảng 6 tháng nếu ban quản lý
giám sát kế hoạch chặt chẽ, tiết kiệm được một khoản tiền đáng kể.
Tóm lại, không có giai đoạn lập kế hoạch riêng biệt. Thay vào đó, các hoạt động lập kế
hoạch được thực hiện trong suốt vòng đời. Tuy nhiên, có những lúc các hoạt động lập kế
hoạch chiếm ưu thế trước. Chúng bao gồm việc bắt đầu dự án (lập kế hoạch sơ bộ) và
ngay sau khi tài liệu đặc tả được khách hàng ký duyệt (kế hoạch quản lý dự án phần
mềm).

1.7 Tại sao không có giai đoạn thử nghiệm

Điều cần thiết là phải kiểm tra một sản phẩm phần mềm một cách tỉ mỉ sau khi nó được
phát triển. Theo đó, thật hợp lý khi đặt câu hỏi tại sao không có giai đoạn thử nghiệm sau
khi sản phẩm đã được triển khai.
Chương 1Phạm vi của Công nghệ phần mềm17

Thật không may, việc kiểm tra một sản phẩm phần mềm khi nó đã sẵn sàng được giao
cho khách hàng là quá muộn. Ví dụ, nếu có lỗi trong tài liệu đặc tả, lỗi này sẽ được chuyển
sang thiết kế và triển khai. Đôi khi trong quy trình phần mềm, việc kiểm thử được thực
hiện gần như loại trừ hoàn toàn các hoạt động khác. Điều này xảy ra vào cuối mỗi giai
đoạn (xác minh) và đặc biệt đúng trước khi sản phẩm được bàn giao cho khách hàng
(Thẩm định). Mặc dù có những lúc việc kiểm tra chiếm ưu thế nhưng không bao giờ có
những lúc không có thử nghiệm nào được thực hiện. Nếu thử nghiệm được coi là riêng
biệt (thử nghiệm)giai đoạn, thì có một mối nguy hiểm thực sự là việc thử nghiệm sẽ
không được thực hiện
liên tục trong mọi giai đoạn của quá trình phát triển và bảo trì sản phẩm. Nhưng ngay cả
điều này vẫn chưa đủ. Điều cần thiết là liên tục kiểm tra một sản phẩm phần mềm. Việc
kiểm tra tỉ mỉ sẽ tự động đi kèm với mọi hoạt động phát triển và bảo trì phần mềm. Một
giai đoạn thử nghiệm riêng biệt không tương thích với mục tiêu đảm bảo rằng sản phẩm
phần mềm luôn không có lỗi nhất có thể.
 Mỗi tổ chức phát triển phần mềm nên có một nhóm độc lập có trách nhiệm chính là đảm
bảo rằng sản phẩm được giao là thứ khách hàng cần và sản phẩm được xây dựng chính
xác về mọi mặt. Nhóm này được gọi làĐảm bảo chất lượng phần mềm(SQA) nhóm.
Cácchất lượngcủa phần mềm là mức độ nó đáp ứng các đặc tả của nó. Chất lượng và
đảm bảo chất lượng phần mềm được mô tả chi tiết hơn trong Chương 6, cũng như vai trò
của SQA trong việc thiết lập và thực thi các tiêu chuẩn.

1.8 Tại sao không có giai đoạn lập tài liệu

Cũng như không bao giờ nên có một giai đoạn lập kế hoạch hoặc giai đoạn thử nghiệm
riêng biệt, cũng không bao giờ nên có một giai đoạn riêng biệt.giai đoạn tài liệu. Ngược
lại, tài liệu của sản phẩm phần mềm luôn phải đầy đủ, chính xác và cập nhật. Ví dụ, trong
giai đoạn phân tích, tài liệu đặc tả phải phản ánh phiên bản hiện tại của đặc tả và điều này
cũng đúng với các giai đoạn khác.
1. Một lý do tại sao cần đảm bảo rằng tài liệu luôn được cập nhật là do sự thay đổi nhân
sự lớn trong ngành công nghiệp phần mềm. Ví dụ: giả sử rằng tài liệu thiết kế không
được cập nhật và nhà thiết kế trưởng rời đi để nhận công việc khác. Hiện nay việc cập
nhật tài liệu thiết kế để phản ánh tất cả những thay đổi được thực hiện trong khi hệ
thống đang được thiết kế là cực kỳ khó khăn.
2. Hầu như không thể thực hiện các bước của một giai đoạn cụ thể trừ khi tài liệu của giai
đoạn trước đó đầy đủ, chính xác và cập nhật. Ví dụ, một tài liệu đặc tả không đầy đủ
chắc chắn sẽ dẫn đến một thiết kế không đầy đủ và sau đó là việc triển khai không đầy
đủ.
3. Hầu như không thể kiểm tra xem một sản phẩm phần mềm có hoạt động chính xác hay
không trừ khi có sẵn các tài liệu nêu rõ sản phẩm phần mềm đó phải hoạt động như thế
nào. 4. Hầu như không thể bảo trì trừ khi có bộ tài liệu đầy đủ và chính xác mô tả chính
xác chức năng của phiên bản hiện tại của sản phẩm.
Do đó, cũng như không có giai đoạn lập kế hoạch hoặc giai đoạn thử nghiệm riêng biệt
nên không có giai đoạn ghi chép tỷ lệ riêng biệt. Thay vào đó, việc lập kế hoạch, kiểm tra
và lập tài liệu phải là những hoạt động đi kèm với tất cả các hoạt động khác trong khi sản
phẩm phần mềm đang được xây dựng. Bây giờ chúng ta xem xét mô hình hướng đối
tượng.
18Chương 1Phạm vi của Công nghệ phần mềm

1.9 Mô hình hướng đối tượng

Trước năm 1975, hầu hết các tổ chức phần mềm đều không sử dụng các kỹ thuật cụ thể;
mỗi cá nhân làm việc theo cách riêng của mình. Những bước đột phá lớn đã được thực
hiện trong khoảng thời gian từ năm 1975 đến năm 1985, với sự phát triển của cái gọi làcó
cấu trúchoặcmô hình cổ điển. Các kỹ thuật cấu thành mô hình cổ điển bao gồm phân
tích hệ thống có cấu trúc (Phần 12.3), phân tích luồng dữ liệu (Phần 14.3), lập trình có cấu
trúc và kiểm thử có cấu trúc (Phần 15.13.2). Những kỹ thuật này có vẻ cực kỳ hứa hẹn khi
được sử dụng lần đầu tiên. Làm sao
Tuy nhiên, theo thời gian, họ tỏ ra kém thành công hơn ở hai khía cạnh:
1. Các kỹ thuật đôi khi không thể đáp ứng được kích thước ngày càng tăng của các sản
phẩm phần mềm. Nghĩa là, các kỹ thuật cổ điển đã phù hợp khi xử lý các sản phẩm quy
mô nhỏ (thường là 5000 dòng mã) hoặc thậm chí các sản phẩm quy mô trung bình gồm
50.000 dòng mã. Tuy nhiên, ngày nay, các sản phẩm quy mô lớn gồm 500.000 dòng mã
là tương đối phổ biến; ngay cả những sản phẩm có từ 5 triệu dòng mã trở lên cũng
không được coi là bất thường. Tuy nhiên, các kỹ thuật cổ điển thường không thể mở
 rộng quy mô đủ để đáp ứng sự phát triển của các sản phẩm lớn hơn ngày nay.
2. Mô hình cổ điển đã không đáp ứng được những kỳ vọng trước đó trong thời gian thuê
chính sau giao hàng. Động lực chính đằng sau sự phát triển của mô hình cổ điển
khoảng 40 năm trước là, trung bình, hai phần ba ngân sách phần mềm được dành cho
việc bảo trì sau chuyển giao (xem Hình 1.3). Thật không may, mô hình cổ điển đã
không giải quyết được vấn đề này; như đã chỉ ra trong Phần 1.3.2, nhiều tổ chức vẫn
dành 70-80% thời gian và công sức hoặc nhiều hơn cho việc bảo trì sau giao hàng
[Yourdon, 1992; Hatton, 1998].
Lý do chính cho sự thành công hạn chế của mô hình cổ điển là ở chỗ các kỹ thuật cổ điển
hoặc là hướng hoạt động hoặc hướng thuộc tính (dữ liệu) chứ không phải cả hai. Các
thành phần cơ bản của một sản phẩm phần mềm là các hoạt động của sản phẩm và các
thuộc tính trênmà các hoạt động đó hoạt động. Ví dụ,xác định_trung bình_height 1 là
một phép toán hoạt động trên một tập hợp các độ cao (thuộc tính) và trả về giá trị trung
bình của các độ cao (thuộc tính) đó. Một số kỹ thuật cổ điển, chẳng hạn như phân tích
luồng dữ liệu (Phần 14.3), được định hướng hoạt động. Nghĩa là, những kỹ thuật như vậy
tập trung vào hoạt động của sản phẩm; các thuộc tính có tầm quan trọng thứ yếu. Ngược
lại, các kỹ thuật như phát triển hệ thống Jackson (Phần 14.5) là hướng thuộc tính. Sự nhấn
mạnh ở đây là các thuộc tính; các thao tác thực hiện trên các thuộc tính ít có ý nghĩa hơn.
Ngược lại, mô hình hướng đối tượng coi cả thuộc tính và thao tác đều quan trọng như
nhau. Một cách đơn giản để xem xét một đối tượng là một tạo phẩm phần mềm thống nhất
kết hợp cả các thuộc tính và các thao tác được thực hiện trên các thuộc tính (mộthiện
vậtlà một thành phần của sản phẩm phần mềm, chẳng hạn như tài liệu đặc tả, mô-đun mã
hoặc sách hướng dẫn). Định nghĩa này về một đối tượng chưa đầy đủ và được trình bày rõ
ràng ở phần sau của cuốn sách.di sảnđã được xác định (Phần 7.8). Tuy nhiên, định nghĩa
này nắm bắt được phần lớn bản chất của một đối tượng.

1
Trong cuốn sách này, tên của một biến trong một sản phẩm phần mềm cổ điển được viết bằng cách sử dụng
quy ước cổ điển là tách các phần của tên biến bằng dấu gạch dưới, ví dụ:this_is_a_classical_variable. Một
biến trong sản phẩm phần mềm hướng đối tượng được viết bằng cách sử dụng quy ước hướng đối tượng là sử
dụng chữ in hoa để đánh dấu sự bắt đầu của một phần mới trong tên của biến; Ví
dụ,thisIsAnObjectOrientedVariable.
Chương 1Phạm vi của Công nghệ phần mềm19

HÌNH 1.7So sánh việc triển khai tài khoản ngân hàng bằng cách sử dụng (a) mô hình cổ điển và (b) mô hình hướng
đối tượng. Đường màu đen liền nét bao quanh vật thể biểu thị chi tiết đó về cách thứcsố dư tài khoảnđược thực hiện
không được biết đến bên ngoài đối tượng.

xác địnhSố dư
số dư tài khoản
tin nhắn
tin nhắn
tiền gửi rút tiền gửi
tin nhắn
rút
số dư tài khoản
xác định_cân bằng

(a) (b)

Tài khoản ngân hàng là một ví dụ về một đối tượng (xem Hình 1.7). Thành phần thuộc
tính của đối tượng làsố dư tài khoản. Các hoạt động có thể được thực hiện trên số dư tài
khoản đó bao gồmtiền gửitiền trong tài khoản,rúttiền từ tài khoản, vàxác địnhSố dư.
 Đối tượng tài khoản ngân hàng kết hợp một thuộc tính với ba opera
các hoạt động được thực hiện trên thuộc tính đó trong một tạo phẩm duy nhất. Từ quan
điểm của mô hình cổ điển, một sản phẩm liên quan đến ngân hàng sẽ phải kết hợp một
thuộc tính,số dư tài khoảnvà ba phép toán,tiền gửi,rút, Vàxác định_cân bằng. Cho đến
nay, dường như có rất ít sự khác biệt giữa hai cách tiếp cận này. Tuy nhiên, điểm mấu chốt
là cách thức triển khai một đối tượng. Cụ thể, chi tiết về cách các thuộc tính của một đối
tượng được lưu trữ không được biết từ bên ngoài đối tượng. Đây là một trường hợp “che
giấu thông tin”, được thảo luận chi tiết hơn trong Phần 7.6. Trong trường hợp đối tượng
tài khoản ngân hàng được hiển thị trong Hình 1.7(b), phần còn lại của sản phẩm phần
mềm nhận thức được rằng có một thứ gọi là số dư trong đối tượng tài khoản ngân hàng,
nhưng nó không biết về định dạng củasố dư tài khoản. Nghĩa là, không có kiến ​thức nào
bên ngoài đối tượng về việc số dư tài khoản được thực hiện dưới dạng số nguyên hay số
dấu phẩy động hay trường (thành phần) của một cấu trúc lớn hơn nào đó. Rào cản thông
tin xung quanh đối tượng này được biểu thị bằng đường liền nét màu đen trong Hình
1.7(b), mô tả việc triển khai sử dụng mô hình hướng đối tượng. Ngược lại, một đường đứt
nét bao quanhsố dư tài khoảntrong Hình 1.7(a) , bởi vì tất cả các chi tiết củasố dư tài
khoảnđược các mô-đun biết đến trong quá trình triển khai bằng cách sử dụng mô hình cổ
điển và giá trị củasố dư tài khoảndo đó có thể được thay đổi bởi bất kỳ ai trong số họ.
Quay lại Hình 1.7(b), cách triển khai hướng đối tượng, nếu khách hàng gửi 10 USD vào
tài khoản thìtin nhắnđược gửi đếntiền gửiphương thức của đối tượng liên quan yêu cầu
nó tăngsố dư tài khoảnthuộc tính thêm $10 (aphương pháplà việc thực hiện một hoạt
động). Cáctiền gửiphương thức nằm trong đối tượng tài khoản ngân hàng và biết cáchsố
dư tài khoảnđược thực thi; điều này được biểu thị bằng đường tròn nét đứt bên trong
20Chương 1Phạm vi của Công nghệ phần mềm

sự vật. Nhưng không có thực thể nào bên ngoài đối tượng cần kiến ​thức này. Rằng ba
phương pháp trong Hình 1.7(b) che chắnsố dư tài khoảntừ phần còn lại của sản phẩm
tượng trưng cho việc bản địa hóa kiến ​thức này. Thực tế là các chi tiết triển khai mang tính
cục bộ đối với một đối tượng minh họa điểm mạnh đầu tiên trong số nhiều điểm mạnh của
mô hình hướng đối tượng:
1. Xem xét việc bảo trì sau giao hàng. Giả sử rằng sản phẩm ngân hàng được xây dựng
theo mô hình cổ điển. Nếu theo cách đósố dư tài khoảnđược biểu diễn sẽ được thay
đổi từ (giả sử) một số nguyên thành một trường của cấu trúc, sau đó mọi phần của sản
phẩm đó có liên quan đến mộtsố dư tài khoảnphải được thay đổi và những thay đổi
này phải được thực hiện một cách nhất quán. Ngược lại, nếu mô hình hướng đối tượng
được sử dụng thì các thay đổi chỉ cần được thực hiện trong chính đối tượng tài khoản
ngân hàng. Không có phần nào khác của sản phẩm có kiến ​thức về cách thứcsố dư tài
khoảnđược triển khai nên không phần nào khác có thể truy cập vàosố dư tài khoản.
Do đó, không có phần nào khác của sản phẩm ngân hàng cần phải thay đổi. Theo đó,
mô hình hướng đối tượng làm cho việc duy trì
tài chính nhanh hơn và dễ dàng hơn, đồng thời có cơ hội giới thiệu mộtlỗi hồi
quy(nghĩa là lỗi vô tình xuất hiện ở một bộ phận của sản phẩm do tạo ra một thay đổi
dường như không liên quan đến bộ phận khác của sản phẩm) sẽ được giảm đi đáng kể.
2. Ngoài việc bảo trì, mô hình hướng đối tượng còn giúp việc phát triển trở nên dễ dàng
hơn. Trong nhiều trường hợp, một đối tượng có một đối tượng vật lý. Ví dụ: đối tượng tài
khoản ngân hàng trong sản phẩm ngân hàng tương ứng với tài khoản ngân hàng thực tế
trong ngân hàng mà sản phẩm này đang được triển khai. Như sẽ được trình bày trong Phần
B, mô hình hóa đóng một vai trò quan trọng trong mô hình hướng đối tượng. Sự tương
ứng chặt chẽ giữa các đối tượng trong sản phẩm và đối tượng tương ứng của chúng trong
thế giới thực sẽ dẫn đến phần mềm có chất lượng tốt hơn.
3. Các đối tượng được thiết kế tốt là những đơn vị độc lập. Như đã được giải thích, một
đối tượng bao gồm cả các thuộc tính và các thao tác được thực hiện trên các thuộc tính
đó. Nếu tất cả các thao tác được thực hiện trên các thuộc tính của một đối tượng đều
 được bao gồm trong đối tượng đó thì đối tượng đó có thể được coi là một thực thể độc
lập về mặt khái niệm. Mọi thứ trong sản phẩm liên quan đến phần thế giới thực được
mô hình hóa bởi đối tượng đó đều có thể được tìm thấy trong chính đối tượng đó. Sự
độc lập về mặt khái niệm này đôi khi được gọi làđóng gói
(Mục 7.4). Nhưng còn có một hình thức độc lập bổ sung, sự độc lập về thể chất. Trong
một đối tượng được thiết kế tốt, việc ẩn thông tin đảm bảo rằng các chi tiết triển khai
được ẩn khỏi mọi thứ bên ngoài đối tượng đó. Hình thức giao tiếp được phép duy nhất
là gửi tin nhắn đến đối tượng để thực hiện một hoạt động cụ thể. Cách thức thực hiện
thao tác hoàn toàn thuộc trách nhiệm của chính đối tượng. Vì lý do này, thiết kế hướng
đối tượng đôi khi được gọi làthiết kế hướng tới trách nhiệm[Wirfs-Brock,
Wilkerson và Wiener, 1990] hoặcthiết kế theo hợp đồng[Meyer, 1992]. (Để có một
góc nhìn khác về thiết kế định hướng trách nhiệm, hãy xem Hộp 1.5 Chỉ trong trường
hợp bạn muốn biết, lấy từ một ví dụ trong [Budd, 2002].) Một cách khác để xem xét cả
việc đóng gói và che giấu thông tin là các trường hợp tách biệt giữa mối quan tâm
(Phần 5.4).
4. Một sản phẩm được xây dựng bằng mô hình cổ điển được triển khai dưới dạng một tập
hợp các mô-đun, nhưng về mặt khái niệm, về cơ bản nó là một đơn vị duy nhất. Đây là
một lý do tại sao mô hình cổ điển ít thành công hơn khi áp dụng cho các sản phẩm lớn
hơn. Ngược lại, khi mô hình hướng đối tượng được sử dụng đúng cách, sản phẩm thu
được bao gồm một số đơn vị nhỏ hơn, phần lớn độc lập. Mô hình hướng đối tượng làm
giảm mức độ phức tạp của một sản phẩm phần mềm và do đó đơn giản hóa cả việc
phát triển và bảo trì.

Chỉ trong trường hợp bạn muốn biếtÔ 1.5

Giả sử bạn sống ở New Orleans và bạn muốn gửi bó hoa Ngày của Mẹ cho mẹ bạn ở
Chicago. Một chiến lược là tham khảo các trang vàng của Chicago (trên World Wide Web),
xác định người bán hoa nào ở gần căn hộ của mẹ bạn nhất và đặt hàng với người bán
hoa đó. Một cách thuận tiện hơn là đặt hoa tại1-800-flowers.com,để lại toàn bộ trách
nhiệm giao hoa cho công ty đó. Không liên quan ở chỗ nào1-800-fl owers.comcó vị trí
thực tế hoặc người bán hoa nào được bạn yêu cầu giao hàng. Trong mọi trường hợp,
công ty không tiết lộ thông tin đó, đây là một trường hợp che giấu thông tin.
Tương tự như vậy, khi một tin nhắn được gửi đến một đối tượng, không những cách thức
thực hiện yêu cầu đó hoàn toàn không liên quan mà đơn vị gửi tin nhắn thậm chí còn
không được phép biết cấu trúc bên trong của đối tượng. Bản thân đối tượng hoàn toàn
chịu trách nhiệm về từng chi tiết thực hiện thông điệp.

5. Mô hình hướng đối tượng thúc đẩy việc tái sử dụng; bởi vì các đối tượng là những thực
thể độc lập nên nhìn chung chúng có thể được sử dụng trong các sản phẩm trong tương
lai (nhưng hãy xem Vấn đề 1.17). Việc tái sử dụng các đối tượng này làm giảm thời
gian và chi phí cho cả việc phát triển và bảo trì, như được giải thích trong Chương 8.
Khi mô hình hướng đối tượng được sử dụng, vòng đời phần mềm cổ điển trong Hình 1.2
phải được sửa đổi. Hình 1.8 so sánh mô hình vòng đời của mô hình cổ điển với mô hình
hướng đối tượng.
Sự khác biệt đầu tiên dường như hoàn toàn là về mặt thuật ngữ; từgiai đoạnđược sử dụng
cho mô hình cổ điển, trong khiquy trình làm việcđược sử dụng cho mô hình hướng đối
tượng. Trên thực tế, như sẽ được giải thích chi tiết trong Chương 2, không có sự tương
ứng nào giữa một giai đoạn và một quy trình công việc. Ngược lại, hai thuật ngữ này hoàn
toàn khác biệt và sự khác biệt này thể hiện sự khác biệt giữa các mô hình vòng đời làm
nền tảng cho hai mô hình.
Trong chương này, chúng ta xem xét sự khác biệt khác giữa hai mô hình, vai trò của các
mô-đun (trong mô hình cổ điển) so với vai trò của các đối tượng (trong mô hình hướng
đối tượng). Đầu tiên hãy xem xét giai đoạn thiết kế của mô hình cổ điển. Như đã nêu trong
 Phần 1.3, giai đoạn này được chia thành hai giai đoạn phụ: thiết kế kiến ​trúc và sau đó là
thiết kế chi tiết. Trong giai đoạn thiết kế kiến ​trúc, sản phẩm được phân tách thành các
thành phần, được gọi làmô-đun. Sau đó, trong giai đoạn thiết kế chi tiết, cấu trúc dữ liệu
và thuật toán của từng mô-đun lần lượt được thiết kế. Cuối cùng, trong giai đoạn triển
khai, các mô-đun này sẽ được triển khai.
Nếu mô hình hướng đối tượng được sử dụng thay thế, một trong các bước của quy trình
phân tích hướng đối tượng là xác định các lớp. Bởi vì lớp là một loại mô-đun, thiết kế
kiến ​trúc được thực hiện trong luồng công việc phân tích hướng đối tượng.
đoạn phân tích (đặc tả) 2. Quy trình phân tích hướng đối
tượng 3. Giai đoạn thiết kế 3 . Quy trình thiết kế hướng đối
HÌNH 1.8So sánh các mô hình vòng đời của tượng 4. Giai đoạn thực hiện 4 . Quy trình triển khai hướng
mô hình cổ điển và đối tượng đối tượng 5. Bảo trì sau giao hàng 5. Bảo trì sau giao hàng
định hướng 6. Nghỉ hưu 6. Nghỉ hưu
mô hình.
Mô hình hướng đối tượng cổ điển

1. Giai đoạn yêu cầu 1. Quy trình công việc yêu cầu 2. Giai
22Chương 1Phạm vi của Công nghệ phần

mềmHÌNH 1.9

Sự khác biệt giữa cổ điển dụng mô hình cổ điển, hầu như luôn có sự chuyển tiếp
mô hình và đối tượng rõ ràng giữa giai đoạn phân tích và giai đoạn thiết kế.
định hướng Cuối cùng, mục đích của giai đoạn phân tích là xác
mô hình. địnhGìsản phẩm sẽ làm, trong khi mục đích của giai
Mô hình hướng đối tượng cổ điển đoạn thiết kế là quyết địnhLàm saođể làm điều đó.
2. Phân tích (đặc tả) giai đoạn 2 . Quy trình phân tích hướng Ngược lại, khi sử dụng phân tích hướng đối tượng,
đối tượng • Xác định sản phẩm sẽ làm gì • Xác định sản các đối tượng sẽ bước vào vòng đời ngay từ đầu. Các
phẩm sẽ làm gì • Trích xuất các lớp đối tượng được trích xuất trong quy trình phân tích,
3. Giai đoạn thiết kế 3. Quy trình thiết kế hướng đối tượng • được thiết kế trong quy trình thiết kế và được mã hóa
Thiết kế kiến ​trúc (trích xuất các module) • Thiết kế chi tiết trong quy trình triển khai. Do đó, mô hình hướng đối
• Thiết kế chi tiết tượng là một cách tiếp cận tích hợp; quá trình chuyển
4. Thực hiện giai đoạn 4. Quy trình triển khai hướng đối đổi từ quy trình công việc này sang quy trình công
tượng • Mã hóa các mô-đun một cách thích hợp • Mã hóa việc khác suôn sẻ hơn nhiều so với mô hình cổ điển,
các lớp bằng ngôn ngữ lập trình thích hợp Ngôn ngữ lập giảm số lượng lỗi phát sinh trong quá trình phát triển.
trình hướng đối tượng • Tích hợp • Tích hợp Như đã đề cập, sẽ không đủ nếu định nghĩa một đối
tượng chỉ đơn thuần là một tạo phẩm phần mềm đóng
gói cả thuộc tính và hoạt động cũng như thực hiện
Do đó, phân tích hướng đối tượng đi xa hơn giai đoạn nguyên tắc ẩn thông tin. Một định nghĩa đầy đủ hơn
phân tích (đặc tả) tương ứng của mô hình cổ điển. được đưa ra trong Chương 7, trong đó các đối tượng
Điều này được thể hiện trong Hình 1.9. Sự khác biệt được xem xét sâu hơn.
giữa hai mô hình này có những hậu quả lớn. Khi sử

1.10 Mô hình hướng đối tượng trong phối cảnh

Hình 1.1 là bằng chứng cho thấy nhiều thiếu sót của mô hình (có cấu trúc) cổ điển. Tuy
nhiên, mô hình hướng đối tượng không phải là thuốc chữa bách bệnh cho mọi bệnh tật:
•Giống như tất cả các cách tiếp cận sản xuất phần mềm, mô hình hướng đối tượng phải
được sử dụng đúng cách; thật dễ dàng để sử dụng sai mô hình hướng đối tượng như bất kỳ
mô hình nào khác.•Khi được áp dụng đúng cách, mô hình hướng đối tượng có thể giải
quyết một số (nhưng không phải tất cả) các vấn đề của mô hình cổ điển.
•Mô hình hướng đối tượng có một số vấn đề riêng của nó, như được mô tả trong Phần
7.9.•Mô hình hướng đối tượng là cách tiếp cận tốt nhất hiện nay. Tuy nhiên, giống như tất
 cả các công nghệ, nó chắc chắn sẽ bị thay thế bởi một công nghệ vượt trội hơn trong
tương lai.
Trong cuốn sách này, điểm mạnh và điểm yếu của cả mô hình cổ điển và mô hình hướng
đối tượng đều được chỉ ra trong bối cảnh chủ đề cụ thể đang được thảo luận. Do đó, việc
so sánh hai mô hình không xuất hiện ở một chỗ duy nhất mà trải rộng khắp toàn bộ cuốn
sách.
Bây giờ chúng ta định nghĩa một số thuật ngữ công nghệ phần mềm.
Chương 1Phạm vi của Công nghệ phần mềm23

1.11 Thuật ngữ

Cáckhách hànglà cá nhân mong muốn một sản phẩm được xây dựng (phát triển).
Cácnhà phát triểnlà thành viên của một nhóm chịu trách nhiệm xây dựng sản phẩm đó.
Các nhà phát triển có thể chịu trách nhiệm về mọi khía cạnh của quy trình phần mềm, từ
các yêu cầu trở đi, hoặc họ
có thể chỉ chịu trách nhiệm thực hiện một sản phẩm đã được thiết kế. Cả khách hàng và
nhà phát triển đều có thể là thành viên của cùng một tổ chức. Ví dụ: khách hàng có thể là
người đứng đầu chuyên gia tính toán của một công ty bảo hiểm và các nhà phát triển là
một nhóm do phó chủ tịch phụ trách phát triển phần mềm của công ty bảo hiểm đó đứng
đầu. Điều này được gọi làphát triển phần mềm nội bộ. Mặt khác, vớiphần mềm
hợp đồngkhách hàng và nhà phát triển là thành viên của các tổ chức hoàn toàn độc lập.
Ví dụ: khách hàng có thể là quan chức cấp cao của Bộ Quốc phòng và là nhân viên phát
triển của một nhà thầu quốc phòng lớn chuyên về phần mềm cho hệ thống vũ khí. Ở quy
mô nhỏ hơn nhiều, khách hàng có thể là kế toán viên hành nghề một người và nhà phát
triển là sinh viên kiếm thu nhập bằng cách phát triển phần mềm bán thời gian. Bên thứ ba
tham gia sản xuất phần mềm làngười dùng. Người dùng là người hoặc những người mà
khách hàng thay mặt họ ủy quyền sử dụng sản phẩm và sẽ sử dụng phần mềm. Trong ví
dụ về công ty bảo hiểm, người dùng có thể là đại lý bảo hiểm, họ sẽ sử dụng phần mềm để
lựa chọn các chính sách phù hợp nhất. Trong một số trường hợp, khách hàng và người
dùng là cùng một người (ví dụ: kế toán viên đã thảo luận trước đó). Ngược lại với phần
mềm tùy chỉnh đắt tiền được phát triển cho một khách hàng, nhiều bản sao của phần mềm,
chẳng hạn như trình xử lý văn bản hoặc bảng tính, được bán với giá thấp hơn nhiều cho số
lượng lớn người mua. Nghĩa là, các nhà sản xuất phần mềm như vậy (như Microsoft hay
Borland) thu hồi chi phí phát triển sản phẩm bằng cách bán số lượng lớn. Loại phần mềm
này thường được gọi làPhần mềm thương mại sẵn có (COTS). Thuật ngữ trước đây
cho loại phần mềm này làphần mềm thu nhỏbởi vì hộp chứa đĩa CD hoặc đĩa mềm,
sách hướng dẫn và thỏa thuận cấp phép hầu như luôn được bọc màng co. Ngày nay, phần
mềm COTS thường được tải xuống qua World Wide Web—không có hộp để đóng gói. Vì
lý do này, phần mềm COTS ngày nay đôi khi được gọi làphần mềm nhấp chuột. Phần
mềm COTS được phát triển cho “thị trường”; nghĩa là, phần mềm không được nhắm mục
tiêu đến một khách hàng hoặc người dùng cụ thể cho đến khi nó được phát triển và có sẵn
để mua.
Phần mềm mã nguồn mởđang trở nên cực kỳ phổ biến. Một sản phẩm phần mềm
nguồn mở được phát triển và duy trì bởi một nhóm tình nguyện viên và bất kỳ ai cũng có
thể tải xuống và sử dụng miễn phí. Các sản phẩm nguồn mở được sử dụng rộng rãi bao
gồm hệ điều hành Linux, trình duyệt Web Firefox và máy chủ Web Apache. Thuật ngữmã
nguồn mởđề cập đến tính sẵn có của mã nguồn cho tất cả mọi người, không giống như hầu
hết các sản phẩm thương mại chỉ bán phiên bản thực thi được. Bởi vì bất kỳ người dùng
sản phẩm nguồn mở nào cũng có thể xem xét kỹ lưỡng mã nguồn và báo cáo lỗi cho nhà
phát triển nên nhiều sản phẩm phần mềm nguồn mở có chất lượng cao. Hậu quả mong đợi
 của tính chất công khai của các lỗi trong phần mềm nguồn mở đã được Raymond chính
thức hóa trongNhà thờ và chợBẰNGĐịnh luật Linus, được đặt theo tên của Linus
Torvalds, người tạo ra Linux [Raymond, 2000].Định luật Linustuyên bố rằng “nếu có đủ
nhãn cầu, mọi con bọ đều nông cạn.” Nói cách khác, nếu có đủ cá nhân xem xét kỹ lưỡng
mã nguồn của một sản phẩm phần mềm nguồn mở, thì ai đó sẽ có khả năng xác định được
lỗi đó và đề xuất cách khắc phục nó (nhưng hãy xem Ô Chỉ trong trường hợp bạn muốn
biết Hộp 1.6). Một nguyên tắc liên quan là “Phát hành sớm. Phát hành thường xuyên”
[Raymond, 2000].

Chỉ trong trường hợp bạn muốn biếtÔ 1.6

Rõ ràng là càng có nhiều người kiểm tra cẩn thận một đoạn mã thì càng có nhiều khả
năng ai đó sẽ tìm thấy và sửa lỗi trong mã đó. Theo đó, Định luật Linus có lẽ nên được gọi
là “Chân lý của Torvalds”.

Nghĩa là, các nhà phát triển nguồn mở có xu hướng dành ít thời gian hơn cho việc thử
nghiệm so với các nhà phát triển nguồn đóng, họ thích phát hành phiên bản mới của sản
phẩm hầu như ngay sau khi nó hoàn thành, giao lại phần lớn trách nhiệm thử nghiệm cho
người dùng.
Một từ được sử dụng trên hầu hết các trang của cuốn sách này làphần mềm. Phần mềm
không chỉ bao gồm mã ở dạng máy có thể đọc được mà còn bao gồm tất cả tài liệu là
thành phần nội tại của mọi dự án. Phần mềm bao gồm tài liệu đặc tả, tài liệu thiết kế, các
loại tài liệu pháp lý và kế toán, kế hoạch quản lý dự án phần mềm và các tài liệu quản lý
khác cũng như tất cả các loại sổ tay.
Kể từ những năm 1970, sự khác biệt giữachương trìnhvà mộthệ thốngđã trở nên mờ
nhạt. Vào “ngày xưa tốt đẹp”, sự khác biệt rất rõ ràng. Một chương trình là một đoạn mã
tự động, thường ở dạng một cỗ bài đục lỗ có thể được thực thi. Một hệ thống là một tập
hợp các chương trình có liên quan. Một hệ thống có thể bao gồm các chương trìnhP,Q,R,
VàS. Băng từT1 đã được gắn kết và sau đó lập trìnhPđã chạy. Nó khiến cho một bộ thẻ dữ
sau đó được tua lại và
liệu được đọc vào và tạo ra dưới dạng băng đầu raT2 VàT3. băngT2
chuyên nghiệp
gramQđã được điều hành, sản xuất băngT4 như đầu ra. Chương trìnhRbây
giờ đã hợp nhất các băngT3 VàT4 vào băngT5;T5 làm đầu vào cho chương trìnhS, đã in
một loạt báo cáo.
Hãy so sánh tình huống đó với một sản phẩm chạy trên một máy có bộ xử lý truyền thông
mặt trước và trình quản lý cơ sở dữ liệu mặt sau, thực hiện kiểm soát thời gian thực đối
với nhà máy thép. Một phần mềm duy nhất điều khiển nhà máy thép có thể làm được
nhiều việc hơn hệ thống lỗi thời, nhưng xét về các định nghĩa cổ điển về chương trình và
hệ thống, phần mềm này chắc chắn là một chương trình. Để thêm vào sự nhầm lẫn, thuật
ngữhệ thốngnow cũng được dùng để biểu thị sự kết hợp phần cứng-phần mềm. Ví dụ: hệ
thống điều khiển chuyến bay trên máy bay bao gồm cả máy tính trên máy bay và phần
mềm chạy trên chúng. Tùy thuộc vào người sử dụng thuật ngữ này, hệ thống điều khiển
chuyến bay cũng có thể bao gồm các bộ phận điều khiển, chẳng hạn như cần điều khiển,
gửi lệnh đến máy tính và các bộ phận của máy bay, chẳng hạn như cánh tà, do máy tính
điều khiển. Hơn nữa, trong bối cảnh phát triển phần mềm truyền thống, thuật ngữphân
tích hệ thốngđề cập đến hai giai đoạn đầu tiên (các yêu cầu và giai đoạn phân tích)
vàthiết kế hệ thốngđề cập đến giai đoạn thứ ba (giai đoạn thiết kế).
Để giảm thiểu sự nhầm lẫn, cuốn sách này sử dụng thuật ngữsản phẩmđể biểu thị một
phần mềm không tầm thường. Có hai lý do cho quy ước này. Cách đầu tiên chỉ đơn giản là
tránh nhầm lẫn giữa chương trình và hệ thống bằng cách sử dụng thuật ngữ thứ ba. Lý do
thứ hai quan trọng hơn. Cuốn sách này đề cập đến quy trình sản xuất phần mềm, tức là
cách chúng tôi sản xuất phần mềm và kết quả cuối cùng của quy trình được gọi làsản
 phẩm. Cuối cùng, thuật ngữhệ thốngđược sử dụng theo nghĩa hiện đại, tức là phần cứng và
phần mềm kết hợp hoặc là một phần của toàn cầu
các cụm từ được chấp nhận, chẳng hạn như hệ điều hành và hệ thống thông tin quản lý.
Hai từ được sử dụng rộng rãi trong bối cảnh công nghệ phần mềm làphương pháp
luậnVàmô hình. Vào những năm 1970, từphương pháp luậnbắt đầu được sử dụng với
nghĩa “một cách phát triển sản phẩm phần mềm”; từ này thực sự có nghĩa là “khoa học về
phương pháp”. Sau đó, vào những năm 1980, từmô hìnhđã trở thành một từ thông dụng
trong giới kinh doanh, như trong cụm từ “Đó là một mô hình hoàn toàn mới”. Ngành công
nghiệp phần mềm sớm

Chỉ trong trường hợp bạn muốn biếtÔ 1.7

Lần đầu tiên sử dụng từ nàysâu bọđể biểu thị lỗi được cho là của cố Chuẩn đô đốc Grace
Murray Hopper, một trong những nhà thiết kế của COBOL. Vào ngày 9 tháng 9 năm 1945,
một con bướm bay vào máy tính Mark II mà Hopper và các đồng nghiệp của cô sử dụng ở
Harvard và đậu giữa các tấm tiếp xúc của một rơle. Theo đó, thực sự đã có một lỗi trong
hệ thống. Hopper đã ghi lỗi vào sổ nhật ký và viết, “Trường hợp lỗi thực tế đầu tiên được
tìm thấy.” Cuốn nhật ký vẫn còn dính con bướm, nằm trong Bảo tàng Hải quân tại Trung
tâm Vũ khí Bề mặt Hải quân, ở Dahlgren, Virginia.
Mặc dù đây có thể là lần đầu tiên sử dụngsâu bọtrong bối cảnh máy tính, từ này được sử
dụng trong tiếng lóng kỹ thuật vào thế kỷ 19 [Shapiro, 1994]. Ví dụ, Thomas Alva Edison
đã viết vào ngày 18 tháng 11 năm 1878, “Cái này phát ra rồi cái kia—‘Lỗi’—như những lỗi
nhỏ và khó khăn như vậy được gọi là . . .” [Josephson, 1992]. Một trong những định nghĩa
củasâu bọtrong ấn bản năm 1934 củaTừ điển tiếng Anh mới của Websterlà “Một khiếm
khuyết trong bộ máy hoặc hoạt động của nó
sự." Nhận xét của Hopper cho thấy rõ rằng cô ấy cũng đã quen với việc sử dụng từ này
trong bối cảnh đó; nếu không thì cô ấy đã giải thích ý cô ấy rồi.

bắt đầu sử dụng từmô hìnhtrong các cụm từmô hình hướng đối tượngvà cổ điển
(hoặctruyền thống)mô hìnhcó nghĩa là “một phong cách phát triển phần mềm.” Đây là
một sự lựa chọn thuật ngữ không may mắn khác, bởi vì một khung mẫu là một mô hình
hay một khuôn mẫu. Những độc giả uyên bác bị xúc phạm bởi sự hư hỏng của ngôn ngữ
tiếng Anh này được nồng nhiệt mời thay mặt tác giả tiếp nhận những lời khuyên về tính
chính xác của ngôn ngữ; anh ấy mệt mỏi với việc nghiêng nghiêng trước cối xay gió. Một
phương pháp hay một mô hình là một thành phần của toàn bộ quy trình phần mềm. Ngược
lại, mộtkỹ thuậtlà một thành phần của một phần của quy trình phần mềm. Ví dụ bao gồm
kỹ thuật mã hóa, kỹ thuật tài liệu và kỹ thuật lập kế hoạch.
Khi một lập trình viên thực hiện mộtsai lầm, hậu quả của sai lầm đó làlỗitrong mã. Việc
thực thi sản phẩm phần mềm sẽ dẫn đến mộtsự thất bại, tức là hành vi không đúng được
quan sát thấy của sản phẩm do hậu quả của lỗi. MỘTlỗilà số tiền mà kết quả không chính
xác. Các điều khoảnsai lầm,lỗi,sự thất bại, Vàlỗiđược định nghĩa trong IEEE Stan dard
610.12, “Bảng chú giải thuật ngữ kỹ thuật phần mềm” [IEEE 610.12, 1990], được tái
khẳng định vào năm 2002 [Tiêu chuẩn IEEE, 2003]. từkhuyết điểmlà một thuật ngữ
chung dùng để chỉ một lỗi, sự cố hoặc sai sót. Vì lợi ích của sự chính xác, trong cuốn sách
này chúng tôi giảm thiểu việc sử dụng thuật ngữ chungkhuyết điểm.
Một thuật ngữ nên tránh càng xa càng tốt làsâu bọ(lịch sử của từ này có trong Just in
Case You Want to Know Box 1.7). Thuật ngữsâu bọngày nay chỉ đơn giản là một uyển
ngữ cho mộtlỗi. Mặc dù nhìn chung việc sử dụng uyển ngữ không thực sự có hại, nhưng
từ nàysâu bọcó những âm bội không có lợi cho việc sản xuất phần mềm tốt. Cụ thể, thay
vì nói
ing, “Tôi đã mắc lỗi,” một lập trình viên sẽ nói, “Một lỗi đã len lỏi vào mã” (không
phảiCủa tôimã nhưngcácmã), từ đó chuyển trách nhiệm về lỗi từ người lập trình sang lỗi.
Không ai đổ lỗi cho một lập trình viên khi mắc bệnh cúm, bởi vì bệnh cúm là do vi trùng
cúm gây ra. Coi sai lầm là lỗi là một cách chối bỏ trách nhiệm. Ngược lại, lập trình viên
 nói: “Tôi đã mắc lỗi” là một chuyên gia máy tính chịu trách nhiệm về hành động của
mình.
Sự nhầm lẫn đáng kể xung quanh thuật ngữ hướng đối tượng. Ví dụ, ngoài thuật
ngữthuộc tínhđối với một thành phần dữ liệu của một đối tượng, thuật ngữbiến số đưa
rađôi khi được sử dụng trong tài liệu hướng đối tượng. Trong Java, thuật ngữ này làbiến
thể hiện. Trong C++ thuật ngữcánh đồngđược sử dụng và trong Visual Basic .NET,
thuật ngữ này làtài sản. Liên quan đến việc thực hiện các hoạt động của một đối tượng,
thuật ngữphương phápthường được sử dụng; TRONG
26Chương 1Phạm vi của Công nghệ phần mềm

Tuy nhiên, C++ thuật ngữ này làhàm thành viên. Trong C++, mộtthành viêncủa một
đối tượng đề cập đến một thuộc tính (“trường trường”) hoặc một phương thức. Trong
Java, thuật ngữcánh đồngđược sử dụng để biểu thị một thuộc tính (“biến thể hiện”) hoặc
một phương thức. Để tránh nhầm lẫn, bất cứ khi nào có thể, các thuật ngữ hình họcthuộc
tínhVàphương phápđược sử dụng trong cuốn sách này.
May mắn thay, một số thuật ngữ được chấp nhận rộng rãi. Ví dụ, khi một phương thức
trong một đối tượng được gọi, điều này gần như được gọi phổ biếngửi tin nhắntới đối
tượng.

1.12 Vấn đề đạo đức

Chúng tôi kết thúc chương này bằng một lưu ý cảnh báo. Sản phẩm phần mềm được phát
triển và duy trì bởi con người. Nếu những cá nhân đó chăm chỉ, thông minh, nhạy bén, cập
nhật và trên hết,đạo đức, thì rất có thể cách mà các sản phẩm phần mềm mà họ phát triển
và duy trì sẽ đạt yêu cầu. Thật không may, điều ngược lại cũng đúng như vậy.
Hầu hết các hiệp hội dành cho các chuyên gia đều có quy tắcđạo đứcmà tất cả các thành
viên của nó phải tuân theo. Hai hiệp hội lớn dành cho các chuyên gia máy tính, Hiệp hội
Máy tính (ACM) và Hiệp hội Máy tính của Viện Kỹ sư Điện và Điện tử (IEEE-CS) đã
cùng phê duyệt Bộ quy tắc đạo đức và chuyên môn về kỹ thuật phần mềm.
Thực hành chuyên nghiệp như là tiêu chuẩn cho việc giảng dạy và thực hành công nghệ
phần mềm [IEEE/ACM, 1999]. Nó dài nên một phiên bản ngắn, bao gồm lời mở đầu và
tám nguyên tắc, cũng được tạo ra. Đây là phiên bản ngắn:
Quy tắc đạo đức và thực hành nghề nghiệp trong công nghệ phần mềm2(Phiên bản 5.2)

theo khuyến nghị của Lực lượng đặc nhiệm chung IEEE-CS/ACM về
Đạo đức kỹ thuật phần mềm và thực hành chuyên môn
Phiên bản ngắn
Lời mở đầu
Phiên bản ngắn của mã tóm tắt nguyện vọng ở mức độ trừu tượng cao; các điều khoản có
trong phiên bản đầy đủ đưa ra các ví dụ và chi tiết về cách những khát vọng này thay đổi cách
chúng ta hành động với tư cách là các chuyên gia kỹ thuật phần mềm. Nếu không có những
khát vọng, các chi tiết có thể trở nên nặng nề và mang tính pháp lý; không có chi tiết, những
khát vọng có thể trở nên cao siêu nhưng trống rỗng; cùng nhau, nguyện vọng và chi tiết tạo
thành một mã gắn kết.
Các kỹ sư phần mềm phải cam kết biến việc phân tích, đặc tả, thiết kế, phát triển, thử nghiệm
và bảo trì phần mềm trở thành một nghề có lợi và được tôn trọng. Theo cam kết của họ đối
với sức khỏe, sự an toàn và phúc lợi của cộng đồng, các kỹ sư phần mềm phải tuân thủ Tám
Nguyên tắc sau:

1.Công cộng—Các kỹ sư phần mềm phải hành động nhất quán vì lợi ích công cộng.
2.Khách hàng và Nhà tuyển dụng—Các kỹ sư phần mềm phải hành động theo cách có lợi
nhất cho khách hàng và người sử dụng lao động của họ, phù hợp với lợi ích công cộng.
 2
© 1999 của Viện Kỹ sư Điện và Điện tử, Inc., và Hiệp hội Máy tính, Inc.
hành nghề nghiệp của mình và phải thúc đẩy cách tiếp cận
có đạo đức trong thực hành nghề nghiệp.

Các quy tắc đạo đức của các hiệp hội khác dành cho
chuyên gia máy tính cũng bày tỏ quan điểm tương tự.
Điều quan trọng đối với tương lai nghề nghiệp của
chúng ta là chúng ta phải tuân thủ nghiêm ngặt các
quy tắc đạo đức như vậy.
Trong Chương 2, chúng tôi xem xét các mô hình
vòng đời khác nhau để làm sáng tỏ hơn về sự khác
biệt giữa mô hình cổ điển và mô hình hướng đối
tượng.

Công nghệ phần mềm được định nghĩa (Phần 1.1) là một
ngành có mục đích là sản xuất phần mềm không có lỗi, đáp
ứng nhu cầu của người dùng và được giao đúng thời hạn và
trong phạm vi ngân sách. Để đạt được mục tiêu này, các kỹ
thuật thích hợp phải được sử dụng trong suốt quá trình sản
xuất phần mềm, bao gồm cả khi thực hiện phân tích (đặc tả)
và thiết kế (Phần 1.4) và bảo trì sau phân phối (Phần 1.3).
Đánh giá chương Công nghệ phần mềm giải quyết tất cả các bước của vòng
đời phần mềm và kết hợp các khía cạnh của nhiều lĩnh vực
kiến ​thức khác nhau của con người, bao gồm kinh tế học
(Phần 1.2) và khoa học xã hội (Phần 1.5). Không có giai
đoạn lập kế hoạch riêng biệt (Phần 1.6), không có giai đoạn
thử nghiệm (Phần 1.7) và không có giai đoạn lập tài liệu
(Phần 1.8). Trong Phần 1.9, các đối tượng được giới thiệu
và so sánh giữa các lớp
mô hình hướng đối tượng và cal được thực hiện. Sau đó, mô
hình hướng đối tượng được đánh giá (Phần 1.10). Tiếp theo,
trong Phần 1.11, thuật ngữ được sử dụng trong cuốn sách
này sẽ được giải thích. Cuối cùng, các vấn đề đạo đức được
thảo luận ở Phần 1.12.
Vì
Đọc thêm
Chương 1Phạm vi của Công nghệ phần mềm27
Nguồn thông tin sớm nhất về phạm vi công nghệ phần mềm
3.Sản phẩm—Các kỹ sư phần mềm phải đảm bảo rằng sản là [Boehm, 1976]. Tương lai của công nghệ phần mềm được
phẩm của họ và các sửa đổi liên quan đáp ứng các tiêu thảo luận trong [Finkelstein, 2000]. Thực trạng thực hành
chuẩn chuyên môn cao nhất có thể. công nghệ phần mềm hiện nay được mô tả trong nhiều bài
4.Phán quyết—Các kỹ sư phần mềm phải duy trì tính chính viết khác nhau trên tạp chíPhần mềm IEEE.Một cuộc điều
trực và độc lập trong phán đoán chuyên môn của mình. tra về các yếu tố dẫn đến phát triển phần mềm thành công
5.Sự quản lý—Các nhà quản lý và lãnh đạo kỹ thuật phần xuất hiện trong [Procac cino, Verner, và Lorenzet, 2006].
mềm phải đăng ký và thúc đẩy cách tiếp cận có đạo đức đối Để có cái nhìn về tầm quan trọng của bảo trì sau chuyển
với việc quản lý phát triển và bảo trì phần mềm. 6.Nghề giao trong công nghệ phần mềm và cách lập kế hoạch cho
nghiệp—Các kỹ sư phần mềm phải nâng cao tính chính trực nó, xem [Parnas, 1994]. Phát triển phần mềm cho các sản
và danh tiếng của nghề nghiệp phù hợp với lợi ích công phẩm dựa trên COTS là chủ đề của [Brownsword,
cộng. Oberndorf, và Sledge, 2000]. Việc thu thập các thành phần
7.Đồng nghiệp—Các kỹ sư phần mềm phải công bằng và COTS được mô tả trong [Ulkuni emi và Seppanen, 2004] và
hỗ trợ đồng nghiệp của mình. số 8.Bản thân-Các kỹ sư phần trong [Keil và Tiwana, 2005]. Quản lý rủi ro khi phần mềm
mềm phải tham gia vào quá trình học tập suốt đời về thực được phát triển bằng cách sử dụng các thành phần COTS
được mô tả trong [Li et al., 2008]. Số tháng 7-tháng 8 năm
2005 của tạp chíPhần mềm IEEEchứa sáu bài viết về việc
tích hợp các thành phần COTS vào các sản phẩm phần
mềm, bao gồm [Donzelli et al., 2005] và [Yang, Bhuta,
Boehm, and Port, 2005]. Việc đánh giá lại việc quản lý rủi
ro xuất hiện trong [Bannerman, 2008].
28Chương 1Phạm vi của Công nghệ phần mềm
Rủi ro trong hệ thống doanh nghiệp được mô tả trong
[Scott và Vessey, 2002] và trong hệ thống thông tin nói
chung trong [Longstaff, Chittister, Pethia, và Haimes, 2000].
Zvegintzov [1998] giải thích rằng có rất ít dữ liệu chính xác
về thực hành công nghệ phần mềm hiện có.

Thực tế là toán học làm nền tảng cho công nghệ phần mềm được nhấn mạnh trong [Devlin, 2001].
Tầm quan trọng của kinh tế học trong công nghệ phần mềm được thảo luận trong [Boehm và
Huang, 2003]. Số tháng 11-tháng 12 năm 2002 của tạp chíPhần mềm IEEEchứa một số bài viết về
kinh tế công nghệ phần mềm.
Hai cuốn sách kinh điển về khoa học xã hội và công nghệ phần mềm là [Weinberg, 1971] và
[Shneiderman, 1980]. Cả hai cuốn sách đều không yêu cầu kiến ​thức sẵn có về tâm lý học hay khoa
học hành vi nói chung.
Tác phẩm vượt thời gian của Brooks [1975],Tháng thần thoại, là phần giới thiệu rất được khuyến
khích về thực tế của công nghệ phần mềm. Cuốn sách bao gồm tài liệu về tất cả các chủ đề được đề
cập trong chương này.
Lời giới thiệu tuyệt vời về phần mềm nguồn mở là [Raymond, 2000]. Paulsen, Succi và Eberlein
[2004] trình bày một nghiên cứu thực nghiệm so sánh các sản phẩm phần mềm nguồn mở và nguồn
đóng. Việc tái sử dụng các thành phần nguồn mở được mô tả trong [Madanmohan và De', 2004].
Một loạt các bài viết về phần mềm nguồn mở xuất hiện trong số tháng 1/tháng 2 năm 2004 của tạp
chíPhần mềm IEEEvà trong số 2 năm 2005 củaTạp chí hệ thống IBM. Vấn đề liệu phần mềm nguồn
mở có dẫn đến tăng cường bảo mật hay không được thảo luận trong [Hoepman và Jacobs, 2007]. Sự
tương tác giữa doanh nghiệp và phần mềm nguồn mở là chủ đề của [Watson và cộng sự, 2008],
[Ven, Verelst, và Mannaert, 2008] và [Wesselius, 2008].
Lời giới thiệu tuyệt vời về mô hình hướng đối tượng là [Budd, 2002]. Ba dự án thành công được
thực hiện bằng cách sử dụng mô hình hướng đối tượng được mô tả trong [Capper, Colgate, Hunter
và James, 1994], kèm theo phân tích chi tiết. Một cuộc khảo sát về thái độ của 150 nhà phát triển
phần mềm có kinh nghiệm đối với mô hình hướng đối tượng được báo cáo trong [Johnson, 2000].
Liên quan đến đạo đức
ics, một quy tắc đạo đức chung cho cả chuyên gia kinh doanh và phần mềm được trình bày trong
[Payne và Landry, 2006].
8khuyết điểm25 tin nhắn19
thiết kế theo hợp hàm thành viên26
đồng20thiết kế văn bản7 phương pháp19
giai đoạn thiết kế7 phương pháp luận24
thiết kế chi tiết7 sai lầm25
nhà phát triển23 mô-đun7
Điều khoản quan
mô hình phát triển rồi bảo mô hình hướng đối
trọng trì9giai đoạn tài liệu17đóng tượng25phần mềm mã
kiểm tra chấp nhận7bảo trì gói20 nguồn mở23định nghĩa vận
thích ứngsố 8giai đoạn phân sự nâng caosố 8 hành (bảo trì)10
tích7 lỗi25 mô hình24
thiết kế kiến ​trúc7hiện vật18 đạo đức26 bảo trì hoàn hảosố 8giai
thuộc tính25 sự thất bại25 đoạn6
sâu bọ25 lỗi25 giai đoạn lập kế hoạch16
mô hình cổ điển18phần cánh đồng25 Bưu phẩm đã được giao
mềm nhấp chuột23 giai đoạn thực hiện7biến thể phát triển23 BẢO TRÌ7
khách hàng23 hiện25hội nhập7 vòng đời6 quá trình5
mã hóa7 phần mềm nội bộ mô hình vòng đời6 sản phẩm24
phần mềm thương mại sẵn Định luật Linus23 chương trình24
có (COTS)23phần mềm hợp BẢO TRÌ10 tài sản25
đồng23bảo trì khắc phụcsố
Chương 1Phạm vi của Công nghệ phần mềm29
thiết kế hướng tới trách phần mềm23
nhiệm20sự nghỉ hưusố 8 phần mềm24
chất lượng17
Gửi tin nhắn26 khủng hoảng phần mềm4
lỗi hồi quy20
bọc co lại trầm cảm phần mềm5
giai đoạn yêu cầu7
 kỹ thuật phần mềm2kế hoạch mô hình có cấu trúc18hệ mô hình truyền thống25kiểm
quản lý dự án phần mềm7 thống24 tra đơn vị7
sửa chữa phần mềmsố 8 phân tích hệ thống24 người dùng23
tài liệu thiết kế7giai đoạn xác thiết kế hệ thống24 Thẩm định17
định7 kỹ thuật25 xác minh17
biến số đưa ra25 định nghĩa thời gian (bảo Mô hình thác nước7
trì)9giai đoạn thử nghiệm17
Veloria, bạn đưa những điều khoản nào vào hợp đồng với
các nhà phát triển phần mềm?
1.5 Bạn là một kỹ sư phần mềm có nhiệm vụ giám sát việc
phát triển phần mềm trong Bài toán 1.4. Liệt kê những cách
Các vấn đề mà công ty của bạn có thể không đáp ứng được hợp đồng
1.1 Bạn chịu trách nhiệm tự động hóa quá trình thực hành với hải quân. Nguyên nhân có thể xảy ra của những thất bại
kiến ​trúc trên nhiều địa điểm. Chi phí phát triển phần mềm như vậy là gì?
ước tính là 530.000 USD. Sẽ cần thêm bao nhiêu tiền để
1.6 Chín tháng sau khi giao hàng, một lỗi được phát hiện
bảo trì phần mềm sau khi giao hàng?
trong phần mềm của sản phẩm phân tích mRNA bằng thuốc
1.2 Có cách nào để dung hòa định nghĩa duy trì thời gian thử Stein–Röntgen. Chi phí sửa lỗi là 18.900 USD. Nguyên
cổ điển với định nghĩa vận hành mà chúng ta hiện đang sử nhân lỗi là do câu văn không rõ ràng trong tài liệu quy định.
dụng không? Giải thich câu trả lơi của bạn. Chi phí để sửa lỗi trong giai đoạn phân tích sẽ tốn khoảng
1.3 Bạn là nhà tư vấn kỹ thuật phần mềm. Giám đốc thông bao nhiêu?
tin của một tập đoàn phân phối xăng dầu khu vực muốn bạn 1.7 Giả sử lỗi trong Vấn đề 1.6 đã được phát hiện trong
phát triển một sản phẩm phần mềm có thể thực hiện tất cả giai đoạn thực hiện. Khi đó sẽ tốn khoảng bao nhiêu tiền để
các chức năng kế toán của công ty và cung cấp thông tin sửa x?
trực tuyến cho nhân viên trụ sở chính về các đơn đặt hàng
1.8 Bạn là chủ tịch của một tổ chức xây dựng phần mềm
và hàng tồn kho trong các kho lưu trữ khác nhau của công quy mô lớn. Bạn đưa Hình 1.6 cho nhân viên của mình
ty. xe tăng. Cần có máy tính cho 21 nhân viên kế toán, 15 xem, thúc giục họ sớm tìm ra lỗi trong vòng đời phần mềm.
nhân viên đặt hàng và 37 nhân viên bể chứa. Ngoài ra, 14 Có người phản hồi rằng mong đợi ai đó sửa lỗi trước khi
nhà quản lý cần truy cập vào dữ liệu. Công ty sẵn sàng trả đưa vào sản phẩm là điều vô lý. Ví dụ, làm thế nào người ta
30.000 USD để lắp ráp phần cứng và phần mềm và muốn có thể loại bỏ một lỗi trong khi thiết kế đang được tạo ra
có được sản phẩm phần mềm hoàn chỉnh trong 4 tuần. Bạn nếu lỗi được đề cập là lỗi mã hóa? Bạn trả lời gì?
nói gì với anh ấy? Hãy nhớ rằng công ty của bạn muốn hoạt
động kinh doanh của công ty anh ấy, bất kể yêu cầu của anh 1.9 Mô tả tình huống trong đó khách hàng, nhà phát triển
ấy có vô lý đến đâu. và người dùng là cùng một người. 1.10 Những vấn đề gì có
thể phát sinh nếu khách hàng, nhà phát triển và người dùng
1.4 Bạn là phó đô đốc của Hải quân Velorian. Người ta đã
quyết định mời một tổ chức phát triển phần mềm để phát là cùng một người? Làm thế nào những vấn đề này có thể
triển phần mềm điều khiển cho thế hệ tên lửa đối hạm mới. được giải quyết?
Bạn chịu trách nhiệm giám sát dự án. Để bảo vệ chính phủ
30Chương 1Phạm vi của Công nghệ phần mềm

1.11 Những lợi thế tiềm năng nào sẽ tích lũy nếu khách hàng, nhà phát triển và người dùng là cùng
một người? 1.12 Tra từhệ thốngtrong một cuốn từ điển. Có bao nhiêu định nghĩa khác nhau? Viết ra
những định nghĩa có thể áp dụng được trong bối cảnh công nghệ phần mềm.
1.13 Đây là ngày đầu tiên bạn đi làm. Người quản lý của bạn đưa cho bạn một danh sách chương
trình và nói: “Hãy xem liệu bạn có thể tìm ra lỗi hay không”. Bạn trả lời gì?
1.14 Bạn chịu trách nhiệm phát triển sản phẩm ở Vấn đề 1.1. Bạn sẽ sử dụng mô hình hướng đối
tượng hay mô hình cổ điển? Đưa ra lý do cho câu trả lời của bạn.
1.15 Thay vì triển khai thành phầnc9của một sản phẩm phần mềm, các nhà phát triển quyết định
mua một thành phần COTS có cùng thông số kỹ thuật như thành phần đó.c9. Ưu điểm và
nhược điểm của phương pháp này là gì?
1.16 Thay vì triển khai thành phầnc37của một sản phẩm phần mềm, các nhà phát triển quyết định
sử dụng một thành phần nguồn mở có cùng đặc điểm kỹ thuật như thành phần đó.c37. Ưu
điểm và nhược điểm của phương pháp này là gì?
1.17 Đối tượngPgọi phương thứcm1của đối tượngQ. Giả sử chúng ta muốn sử dụng lại đối
tượngPtrong một sản phẩm phần mềm mới. Có thểPđược tái sử dụng mà không cần tái sử
dụngQcũng? Điều này nói gì về các đối tượng như “các thực thể độc lập” (như đã nêu trong
Phần 1.9)?
 1.18 Có đúng không khi khẳng định rằng, do Luật Linus, tất cả phần mềm nguồn mở đều có chất
lượng cao?
1.19 (Dự án dài hạn) Giả sử sản phẩm dành cho Người nghiện rượu ẩn danh thuộc Phụ lục A đã
được triển khai đúng như mô tả. Bây giờ sản phẩm phải được sửa đổi để bao gồm các chuyên
gia nội tiết làm nhà cung cấp. Sản phẩm hiện tại sẽ phải được thay đổi theo những cách nào?
Sẽ tốt hơn nếu vứt bỏ mọi thứ và bắt đầu lại từ đầu?
1.20 (Bài đọc về Kỹ thuật phần mềm) Người hướng dẫn của bạn sẽ phân phát các bản sao của
Schach et al. [2003]. Bạn có ý kiến ​gì về giá trị tương đối của kết quả dựa trên ước tính của
người quản lý so với kết quả được tính toán từ dữ liệu thực tế?
yếu của Đại hội máy tính thế giới IFIP lần thứ tám,Tháng
10 năm 1980, IFIP, tr. 321–26.
Người giới thiệu [Boehm, 1981] B.W.BOEHM,Kinh tế kỹ thuật phần mềm,Hội
[Bannerman, 2008] P. L. BANNERMAN, “Rủi ro và quản lý trường Prentice, Vách đá Englewood, NJ, 1981.
rủi ro trong các dự án phần mềm: Đánh giá lại,”Tạp chí Hệ [Boehm và Huang, 2003] B. BOEHM VÀL. G. HTIỀN BẠC,
thống và Phần mềm81(Tháng 12 năm 2008), trang 2118–33. “Kỹ thuật phần mềm dựa trên giá trị: Một nghiên cứu điển
[Boehm, 1976] B.W.BOEHM, "Kỹ thuật phần mềm,"Giao hình,”Máy tính IEEE36(tháng 3 năm 2003), trang 33–41.
dịch IEEE trên máy tínhC-25(tháng 12 năm 1976), tr. [Brooks, 1975] F. P. BROOKS, JR.,Tháng thần thoại: Các bài
1226–41. tiểu luận về Kỹ thuật phần mềm,Addison-Wesley, Reading,
[Boehm, 1979] B.W.BOEHM, “Kỹ thuật phần mềm, Xu MA, 1975; Phiên bản kỷ niệm 20 năm, Addison-Wesley,
hướng R&D và Nhu cầu quốc phòng,” trong:Hướng nghiên Reading, MA, 1995.
cứu về Công nghệ phần mềm, P. Wegner (Biên tập), Nhà [Brownsword, Oberndorf, và Sledge, 2000] L.
xuất bản MIT, Cambridge, MA, 1979. BROWNSWORD, ĐẾNBERNDORF,VÀC. A. SĐÈN LED, “Phát
[Boehm, 1980] B.W.BOEHM, “Phát triển các sản phẩm phần triển quy trình mới cho các hệ thống dựa trên COTS,”Phần
mềm ứng dụng quy mô nhỏ: Một số kết quả thử nghiệm,”Kỷ mềm IEEE17(Tháng 7–tháng 8 năm 2000), trang 40–47.
Chương 1Phạm vi của Công nghệ phần mềm31

[Budd, 2002] T. A. BUDD,Giới thiệu về lập trình hướng đối tượng, tái bản lần thứ 3, Addison
Wesley, Reading, MA, 2002.
[Capper, Colgate, Hunter và James, 1994] N. P. CỨNG DỤNG, R. J. COLGATE, J. C. HDƯỚI,VÀM. F.
JAME, “Tác động của công nghệ hướng đối tượng đến chất lượng phần mềm: Ba ​trường hợp lịch
sử,”Tạp chí hệ thống IBM33(Số 1, 1994), trang 131–57.
[Cutter Consortium, 2002] Cutter Consortium, “78% các tổ chức CNTT đã kiện tụng,”Cạnh
cắt,www.cutter.com/research/2002/edge020409.html,3 Ngày 09 tháng 4 năm 2002. [Daly,
1977] E. B. DALY, “Quản lý phát triển phần mềm,”Giao dịch của IEEE về Kỹ thuật phần
mềmSE-3(tháng 5 năm 1977), tr. 229–42.
[Devlin, 2001] K.DEVLIN, “Lý do thực sự tại sao kỹ sư phần mềm cần môn toán,”Thông báo của
ACM44(tháng 10 năm 2001), tr. 21–22.
[Donzelli và cộng sự, 2005] P.S.ONZELLI, M.ZELKOWITZ, V. BTHIÊN NHIÊN, D. ALARD,VÀK.N.MYÊN
XE, “Đánh giá độ tin cậy của thành phần COTS trong bối cảnh,”Phần mềm IEEE22(Tháng
7–tháng 8 năm 2005), trang 46–53.
[Elshoff, 1976] J. L. ELSHOFF, “Phân tích một số chương trình PL/I thương mại,”Giao dịch của
IEEE về Kỹ thuật phần mềmSE-2(tháng 6 năm 1976), trang 113–20.
[Fagan, 1974] M. E. FNGƯỜI ANH EM, “Kiểm tra thiết kế và mã cũng như kiểm soát quy trình trong
quá trình phát triển chương trình,” Báo cáo kỹ thuật IBM-SSD TR 21.572, Tập đoàn IBM, tháng 12
năm 1974. [Finkelstein, 2000] A. FĐÁ INCEL(Biên tập viên),Tương lai của Kỹ thuật phần mềm, Nhà
xuất bản Hiệp hội Máy tính IEEE, Los Alamitos, CA, 2000.
[GJSentinel.com, 2003] “Lỗi của Sallie Mae tăng gấp đôi số hóa
đơn,”www.gjsentinel.com/news/content/coxnet/headlines/0522_salliemae.html, ngày 22
tháng 5 năm 2003.
[Grady, 1994] R. B. GKHUYÊN BẢO, “Áp dụng thành công các số liệu phần mềm,”Máy tính
IEEE27(Tháng 9 năm 1994), trang 18–25.
[Hatton, 1998] L. HATTON, “OO có đồng bộ với cách chúng ta suy nghĩ không?”Phần mềm
IEEE15(tháng 5–tháng 6 năm 1998), trang 46–54.
[Hoepman và Jacobs, 2007] J.-H. HOEPMAN VÀB.JACOBS, “Tăng cường bảo mật thông qua nguồn
 mở,”Truyền thông của ACM50(Tháng 1 năm 2007), trang 79–83.
[IEEE 610.12, 1990] “Bảng chú giải thuật ngữ kỹ thuật phần mềm,” IEEE 610.12-1990, Insti tute
of Electrical and Electronic Engineers, Inc., 1990.
[Tiêu chuẩn IEEE, 2003] “Báo cáo tình trạng sản phẩm và dự
án,”Standard.ieee.org/db/status/status.txt,Ngày 3 tháng 6 năm 2003.
[IEEE/ACM, 1999] “Quy tắc đạo đức và thực hành nghề nghiệp trong kỹ thuật phần mềm, Phiên
bản 5.2, được khuyến nghị bởi Lực lượng đặc nhiệm chung của IEEE-CS/ACM về đạo đức kỹ
thuật phần mềm và thực hành nghề nghiệp,”www.computer.org/tab/seprof/code.htm, 1999.
[IEEE/EIA 12207.0-1996, 1998] “IEEE/EIA 12207.0-1996 Triển khai Công nghiệp Tiêu chuẩn
Quốc tế ISO/IEC 12207:1995,” Viện Kỹ sư Điện và Điện tử, Liên minh Công nghiệp Điện tử,
New York, 1998.
[ISO/IEC 12207, 1995] “ISO/IEC 12207:1995, Công nghệ thông tin—Quy trình vòng đời phần
mềm,” Tổ chức Tiêu chuẩn hóa Quốc tế, Ủy ban Kỹ thuật Điện Quốc tế, Geneva, 1995.

3
URL này và các URL khác được trích dẫn trong cuốn sách này là chính xác tại thời điểm xuất bản. Tuy nhiên,
các địa chỉ Web có xu hướng thay đổi quá thường xuyên và không có thông báo trước hoặc sau đó. Nếu điều này
xảy ra, người đọc nên sử dụng công cụ tìm kiếm để tìm URL mới. Ngày được đưa ra trong tham chiếu tới URL
là ngày xuất bản.
32Chương 1Phạm vi của Công nghệ phần mềm

[Johnson, 2000] R. A. JOHSON, “Những thăng trầm của việc phát triển hệ thống hướng đối
tượng,”Truyền thông của ACM43(Tháng 10 năm 2000), trang 100-1 69–73.
[Josephson, 1992] M.JOSEPHSON,Edison, Tiểu sử, John Wiley và các con trai , New York , 1992MỘT,
S. D. DULL, D. N. Acho phép, R.J.LINDNER,VÀR.J.HEDGER, “Quản lý chất lượng phần mềm
AS/400,”Tạp chí hệ thống IBM33(Số 1, 1994), trang 62–88.
[Keil và Tiwana, 2005] M. KLÀ VÀTẠITÔI MUỐN, “Vượt quá chi phí: Yếu tố thúc đẩy giá trị ứng
dụng COTS,”Phần mềm IEEE22(tháng 5–tháng 6 năm 2005), trang 64–69.
[Kelly, Sherif và Hops, 1992] J. C. KELLY, J. S. SCHÀNG TRAI,VÀJ.HOPS, “Phân tích mật độ lỗi được
tìm thấy trong quá trình kiểm tra phần mềm,”Tạp chí Hệ thống và Phần mềm17(Tháng 1 năm
1992), trang 111–17.
[La Libre Online, 2007a] “Lalibre.be—Một lỗi trị giá 883 triệu euro,”www.lalibre.be/index.
php?view=bài viết&art_id=305607.
[La Libre Online, 2007b] “Lalibre.be—Đó là lỗi của CNTT,”www.lalibre.be/index.
php?view=bài viết&art_id=307021.
[Leveson và Turner, 1993] N. G. LEVESON VÀC.S.TĐỊA CHỈ, “Cuộc điều tra về vụ tai nạn
Therac-25,”Máy tính IEEE26(tháng 7 năm 1993), tr. 18–41.
[Li và cộng sự, 2008] J.LTÔI, O. P. N. SLYNGSTAD, M. TORCHIANO, M.MORISIO,VÀC. Bđược xức dầu,
“Khảo sát thực tiễn về quản lý rủi ro trong quá trình phát triển với các thành phần phần mềm có
sẵn,”Giao dịch của IEEE về Kỹ thuật phần mềm34(Tháng 3–tháng 4 năm 2008), trang 271–86.
[Lientz, Swanson, và Tompkins, 1978] B. P. LIENTZ, E. B. SWANSON,VÀLẤYOMPKIN, “Các hoạt
động bảo trì phần mềm ứng dụng,”Truyền thông của ACM21(tháng 6 năm 1978), trang 466–71.
[Longstaff, Chittister, Pethia, và Haimes, 2000] T. A. LKHÔNG NHÂN VIÊN, C.CHITTISTER,
R.PETHIA,VÀY.Y.HTÌNH YÊU, “Có phải chúng ta đang quên đi những rủi ro của công nghệ thông
tin?”Máy tính IEEE33(tháng 12 năm 2000), tr. 43–51.
[Madanmohan và De', 2004] T. R. MADANMOHAN VÀRDVÀ’, “Tái sử dụng nguồn mở trong các công
ty thương mại,”Phần mềm IEEE21(Tháng 11–Tháng 12 năm 2004), trang 62–69.
[Mellor, 1994] P.MELLOR, “CAD: Thảm họa do máy tính hỗ trợ,” Báo cáo kỹ thuật, Trung tâm Độ
tin cậy của Phần mềm, Đại học Thành phố, Luân Đôn, tháng 7 năm 1994.
[Meyer, 1992] B.MYÊN XE, “Áp dụng ‘Thiết kế theo hợp đồng’,”Máy tính IEEE25(tháng 10 năm
1992), tr. 40–51.
[Naur, Randell và Buxton, 1976] P. NVÀNG, B.RANDELL,VÀJ. N. BUXTON(Biên tập viên),Kỹ thuật
phần mềm: Các khái niệm và kỹ thuật: Kỷ yếu của Hội nghị NATO, Hiến chương Petrocelli, New
 York, 1976.
[Neumann, 1980] P.G.NEUMANN, Thư của Biên tập viên,Ghi chú Kỹ thuật Phần mềm ACM
SIGSOFT5(tháng 7 năm 1980), tr. 2.
[Parnas, 1994] D. L. PHƠI THỞ, “Lão hóa phần mềm,”Kỷ yếu Hội thảo Quốc tế về Kỹ thuật Phần
mềm lần thứ 16, Sorrento, Ý, tháng 5 năm 1994, IEEE, trang 279–87.
[Paulson, Succi, và Eberlein, 2004] J.W.PAULSON, G.SUCCI,VÀA.EBERLEIN, “Nghiên cứu thực
nghiệm về các sản phẩm phần mềm nguồn mở và nguồn đóng,”Giao dịch của IEEE về Kỹ thuật
phần mềm30(tháng 4 năm 2004), trang 101-1 246–56.
[Payne và Landry, 2006] D. PAYNE VÀB. J. L. LANDRY, “Quy tắc đạo đức thống nhất: Đạo đức nghề
nghiệp trong kinh doanh và CNTT,”Truyền thông của ACM49(Tháng 11 năm 2006), trang 81–84.
[Procaccino, Verner và Lorenzet, 2006] J. D. PROCACCINO, J. M. VERNER,VÀS.J.LORENZET, “Xác
định và đóng góp vào thành công của việc phát triển phần mềm,”Truyền thông của ACM(Tháng
8 năm 2006), trang 79–83.
Chương 1Phạm vi của Công nghệ phần mềm33

[Raymond, 2000] E. S. RAYMOND,Nhà thờ và chợ: Những suy ngẫm về Linux và mã nguồn mở của
một nhà cách mạng tình cờ, O'Reilly & Associates, Sebastopol, CA, 2000; cũng có sẵn
tạiwww.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/.
[Rubenstein, 2007] D. RUBENSTEIN, “Báo cáo của Standish Group: Ngày nay ít hỗn loạn hơn trong
phát triển,”www.sdtimes.com/content/article.aspx?ArticleID=30247, ngày 1 tháng 3 năm 2007.
[Schach và cộng sự, 2002] S.R.STẤT CẢ, B.JTRONG, D.R.WPHẢI, G. Z. HHOẶC,VÀA.J.OĐÚNG, “Khả
năng chính của hạt nhân Linux,”Thủ tục tố tụng IEE—Phần mềm149(tháng 2 năm 2002), trang
101-1 18–23. [Schach và cộng sự, 2003] S.R.STẤT CẢ, B.JTRONG, G. Z. HHOẶC,
L.YTRONG,VÀJ.OĐÚNG, “Xác định phân bổ các hạng mục bảo trì: Khảo sát và đo lường,”Nghiên cứu
kỹ thuật phần mềm thực nghiệmsố 8(tháng 12 năm 2003), tr. 351–66.
[Scott và Vessey, 2002] J. E. SCOTT VÀI.VESSEY, “Quản lý rủi ro trong các đề xuất triển khai hệ
thống doanh nghiệp,”Truyền thông của ACM45(tháng 4 năm 2002), trang 101-1 74–81.
[Shapiro, 1994] F. R. SSAPPHIRE, “Lỗi đầu tiên,”Byte19(tháng 4 năm 1994), tr. 308. [Shneiderman,
1980] B. SHNEIDERMAN,Tâm lý học phần mềm: Yếu tố con người trong máy tính và hệ thống thông
tin, Nhà xuất bản Winthrop, Cambridge, MA, 1980.
[Spiegel Online, 2004] “Cầu sông Rhine có cầu thang - chênh lệch chiều cao 54
cm,”www.spiegel. de/panorama/0,1518,281837,00.html.
[St. Petersburg Times Online, 2003] “Hàng nghìn tờ séc liên bang không thể thanh toán bằng tiền
mặt,”www.sptimes. com/2003/02/07/Worldandnation/Thousands_of_federal_.shtml, Ngày
07 tháng 2 năm 2003. [Stephenson, 1976] W. E. STEPHENSON, “Phân tích các nguồn lực được sử
dụng trong phát triển phần mềm hệ thống bảo vệ,” Phòng thí nghiệm Bell, Bản thảo, tháng 8 năm
1976.
[Ulkuniemi và Seppanen, 2004] P. UHọ của tôi,VÀV.SEPPANEN, “Mua lại thành phần COTS tại một thị
trường mới nổi,”Phần mềm IEEE21(Tháng 11-Tháng 12 năm 2004), tr. 76–82. [Ven, Verelst, và
Mannaert, 2008] K. VTRONG, I.VERELST,VÀH.MANNAERT, “Bạn có nên áp dụng phần mềm nguồn mở
không?”Phần mềm IEEE25(tháng 5–tháng 6 năm 2008), trang 54–59.
[Watson và cộng sự, 2008] R.T.WATSON, M.-C. BOUDREAU, P. T. YORK, M. E. GREINER,VÀD.WNN,
“Kinh doanh nguồn mở,”Truyền thông của ACM51(Tháng 4 năm 2008), trang 41–46. [Weinberg,
1971] G.M.WEINBERG,Tâm lý học lập trình máy tính, Van Nostrand Reinhold, New York, 1971.
[Wesselius, 2008] J.WEsselius, “Chợ bên trong Nhà thờ: Mô hình kinh doanh cho thị trường nội
địa,”Phần mềm IEEE25(tháng 5–tháng 6 năm 2008), trang 60–66.
[Wirfs-Brock, Wilkerson và Wiener, 1990] R. WIRFS-BĐÁ, B.WILKERSON,VÀL.WIENER,Thiết kế
phần mềm hướng đối tượng, Prentice Hall, Englewood Cliffs, NJ, 1990. [Yang, Bhuta, Boehm, và
Port, 2005] Y. YCÁC, J.BNGHỈ NGƠI, B.BOEHM,VÀD. N. PVỊ TRÍ, “Quy trình dựa trên giá trị cho các
ứng dụng dựa trên COTS,”Phần mềm IEEE22(Tháng 7–tháng 8 năm 2005), trang 1–11. 54–62.
[Yourdon, 1992] EYOURDON,Sự suy tàn và sa ngã của lập trình viên người Mỹ, Nhà xuất bản
Yourdon, Thượng Saddle River, NJ, 1992.
[Zelkowitz, Shaw, và Gannon, 1979] M. V. ZELKOWITZ, A. C. SHAW,VÀJ.D.GTÔI CHO,Nguyên tắc
 thiết kế và kỹ thuật phần mềm,Hội trường Prentice, Vách đá Englewood, NJ, 1979. [Zvegintzov,
1998] N. ZVEGINTZOV, “Những câu hỏi thường gặp và cách trả lời chúng,”Phần mềm IEEE15(tháng
1/tháng 2 năm 1998), trang 93–96.
Trang này cố ý để trống

Ộ
Phần mềm
Khái niệm kỹ
thuật

Phần
MT
 Các chương từ 2 đến 9 của cuốn sách này đóng một vai trò kép: Chúng giới

thiệu cho người đọc về quy trình phần mềm và cung cấp nền tảng cho tài liệu trong nửa
sau của cuốn sách, trong đó mô tả các quy trình công việc (hoạt động) phát triển phần
mềm. Quy trình phần mềm là cách chúng tôi sản xuất phần mềm. Nó bắt đầu bằng việc
khám phá khái niệm và kết thúc khi sản phẩm cuối cùng ngừng hoạt động. Trong giai
đoạn này, sản phẩm trải qua một loạt các bước như yêu cầu, phân tích (đặc tả), thiết kế,
triển khai, tích hợp, bảo trì sau giao hàng và cuối cùng là ngừng hoạt động. Quy trình
phần mềm bao gồm các công cụ và kỹ thuật mà chúng tôi sử dụng để phát triển và bảo trì
phần mềm cũng như các chuyên gia phần mềm có liên quan.
Nhiều mô hình vòng đời phần mềm khác nhau sẽ được thảo luận chi tiết trong Chương
2, “Mô hình vòng đời phần mềm”. Chúng bao gồm mô hình cây tiến hóa, mô hình thác
nước, mô hình tạo mẫu nhanh, mô hình đồng bộ hóa và ổn định, mô hình nguồn mở, mô
hình quy trình linh hoạt, mô hình xoắn ốc và quan trọng nhất là mô hình lặp và -Mô
hình tăng dần Để giúp người đọc có thể quyết định một mô hình vòng đời thích hợp cho
một dự án cụ thể, các mô hình vòng đời khác nhau sẽ được so sánh và đối chiếu.
“Quy trình phần mềm” là tiêu đề của Chương 3. Điểm nhấn trong chương này là Quy
trình Thống nhất, hiện là cách phát triển phần mềm hứa hẹn nhất. Các quy trình linh hoạt,
một cách tiếp cận thay thế để phát triển phần mềm đang trở nên phổ biến, cũng được xử
lý chi tiết. Chương này kết thúc với tài liệu về cải tiến quy trình phần mềm. Chương 4 có
tựa đề là “Các đội”. Các dự án ngày nay quá lớn để có thể hoàn thành bởi một cá nhân
trong khoảng thời gian nhất định. Thay vào đó, một nhóm chuyên gia phần mềm cộng tác
trong dự án. Chủ đề chính của chương này là các nhóm nên được tổ chức như thế nào để
các thành viên trong nhóm làm việc cùng nhau hiệu quả. Nhiều cách tổ chức nhóm khác
nhau được thảo luận, bao gồm các nhóm dân chủ, các nhóm lập trình viên trưởng, các
nhóm đồng bộ hóa và ổn định, các nhóm nguồn mở và các nhóm quy trình linh hoạt.
36Phần AKhái niệm công nghệ phần mềm

Một kỹ sư phần mềm cần có khả năng sử dụng một số công cụ khác nhau, cả phân tích và
thực tế. Trong Chương 5, “Các công cụ giao dịch”, người đọc được giới thiệu về nhiều
công cụ kỹ thuật phần mềm. Một công cụ như vậy là cải tiến từng bước, một kỹ thuật
phân rã một vấn đề lớn thành những vấn đề nhỏ hơn, dễ xử lý hơn. Một công cụ khác là
 phân tích chi phí-lợi ích, một kỹ thuật để xác định liệu một dự án phần mềm có khả thi về
mặt tài chính hay không. Sau đó, các công cụ kỹ thuật phần mềm hỗ trợ máy tính (CASE)
được mô tả. Công cụ CASE là một sản phẩm phần mềm giúp các kỹ sư phần mềm phát
triển và bảo trì phần mềm. Cuối cùng, để quản lý quy trình phần mềm, cần phải đo lường
nhiều đại lượng khác nhau để xác định xem dự án có đi đúng hướng hay không. Những
biện pháp (số liệu) này rất quan trọng đối với sự thành công của một dự án.
Hai chủ đề cuối cùng của Chương 5, các công cụ và thước đo CASE, được đề cập chi
tiết trong Chương 11 đến Chương 16, mô tả các quy trình công việc cụ thể của vòng
đời phần mềm. Có phần thảo luận về các công cụ CASE hỗ trợ từng quy trình công
việc cũng như mô tả các số liệu cần thiết để quản lý quy trình công việc đó một cách
đầy đủ.
Chương 6, “Thử nghiệm” thảo luận về các khái niệm cơ bản của thử nghiệm. Việc xem
xét các kỹ thuật kiểm thử cụ thể cho từng quy trình công việc của vòng đời phần mềm
được hoãn lại cho đến Chương 11 đến Chương 16.
Chương 7, “Từ mô-đun đến đối tượng,” đưa ra lời giải thích chi tiết về các lớp và đối
tượng cũng như lý do tại sao mô hình hướng đối tượng lại tỏ ra thành công hơn mô
hình cổ điển. Các khái niệm của chương này được sử dụng trong phần còn lại của cuốn
sách, đặc biệt là Chương 11, “Yêu cầu”; Chương 13 , “Phân tích hướng đối tượng”; và
Chương 14, “Thiết kế”, trong đó trình bày về thiết kế hướng đối tượng.
Các ý tưởng của Chương 7 được mở rộng trong Chương 8, “Khả năng tái sử dụng và
tính di động”. Điều quan trọng là có thể triển khai phần mềm tái sử dụng có thể được
chuyển sang nhiều loại phần cứng khác nhau. Phần đầu tiên của chương được dành cho
việc tái sử dụng; các chủ đề bao gồm nhiều nghiên cứu điển hình về tái sử dụng cũng như
các chiến lược tái sử dụng như các khuôn mẫu và khung hướng đối tượng. Tính di động
là chủ đề chính thứ hai; chiến lược di động được trình bày ở một mức độ sâu sắc. Chủ đề
định kỳ của chương này là vai trò của các đối tượng trong việc đạt được khả năng sử
dụng lại và tính di động.
Chương cuối cùng trong Phần A là Chương 9, “Lập kế hoạch và Dự toán”. Trước khi bắt
đầu một dự án phần mềm, điều cần thiết là phải lập kế hoạch chi tiết cho toàn bộ hoạt
động. Khi dự án bắt đầu, ban quản lý phải theo dõi chặt chẽ tiến độ, ghi nhận những sai
lệch so với kế hoạch và thực hiện hành động khắc phục khi cần thiết. Ngoài ra, điều quan
trọng là khách hàng phải được cung cấp ước tính chính xác về thời gian thực hiện dự án
và chi phí là bao nhiêu. Các kỹ thuật ước lượng khác nhau được trình bày, bao gồm các
điểm chức năng và COCOMO II. Một mô tả chi tiết về kế hoạch quản lý dự án phần mềm
được đưa ra. Tài liệu của chương này được sử dụng trong Chương 12 và 13. Khi mô hình
cổ điển được sử dụng, các hoạt động lập kế hoạch và ước tính chính diễn ra vào cuối giai
đoạn phân tích cổ điển, như được giải thích trong Chương 12. Khi phần mềm được phát
triển bằng cách sử dụng mô hình hướng đối tượng, việc lập kế hoạch này diễn ra ở cuối
quy trình phân tích hướng đối tượng ( Chương 13 ).

chương
2
 Mô hình vòng đời
phần mềm

Mục tiêu học tập

Sau khi nghiên cứu chương này, bạn sẽ có thể

• Mô tả cách phát triển sản phẩm phần mềm trong thực tế.
• Hiểu mô hình vòng đời cây tiến hóa.
• Đánh giá cao tác động tiêu cực của sự thay đổi đối với sản phẩm phần mềm.
• Sử dụng mô hình vòng đời lặp đi lặp lại và tăng dần.
• Hiểu được tác động của Định luật Miller đối với sản xuất phần mềm.
• Mô tả điểm mạnh của mô hình vòng đời lặp đi lặp lại và tăng dần.
• Nhận thức được tầm quan trọng của việc sớm giảm thiểu rủi ro.
• Mô tả các quy trình linh hoạt, bao gồm cả lập trình cực đoan.
• So sánh và đối chiếu nhiều mô hình vòng đời khác nhau.

Chương 1 mô tả các sản phẩm phần mềm sẽ được phát triển như thế nào trong một thế
giới lý tưởng. Chủ đề của chương này là những gì xảy ra trong thực tế. Như sẽ được giải
thích, có sự khác biệt rất lớn giữa lý thuyết và thực hành.

2.1 Phát triển phần mềm về mặt lý thuyết

Trong một thế giới lý tưởng, một sản phẩm phần mềm được phát triển như mô tả trong
Chương 1. Như được mô tả dưới dạng sơ đồ trong Hình 2.1, hệ thống được phát triển từ
đầu; biểu thị tập rỗng. (Xem Phòng trường hợp bạn muốn biết Hộp 2.1 nếu bạn muốn biết
nguồn gốc của thuật ngữ nàytừ đầu.) Đầu tiên là khách hàng’SYêu cầuđược xác định và
sau đóPhân tích

37

Chỉ trong trường hợp bạn muốn biếtHộp 2.1

Thuật ngữtừ đầu, có nghĩa là “bắt đầu từ con số không”, xuất phát từ thuật ngữ thể thao
thế kỷ 19. Trước khi đường (và đường chạy) được trải nhựa, các cuộc đua phải được tổ
chức trên bãi đất trống. Trong nhiều trường hợp, vạch xuất phát chỉ là một vết xước trên
cát. Một vận động viên chạy không có lợi thế hoặc khuyết tật phải xuất phát từ vạch đó,
tức là “từ đầu”.
Thuật ngữcàongày nay có một ý nghĩa thể thao khác. “Người chơi gôn cào” là người có
điểm chấp khi chơi gôn bằng 0.
 HÌNH 2.1Lý tưởng hóa
phần mềm
phát triển. C
 Yêu cầu

Phân tích

Thiết kế

Thực hiện

Phát triển

được thực hiện. Khi các tạo phẩm phân tích hoàn tất,Thiết kếđược sản xuất. Tiếp theo đó
làThực hiệncủa sản phẩm phần mềm hoàn chỉnh, sau đó được cài đặt trên máy
khách’máy tính của bạn.
Tuy nhiên, việc phát triển phần mềm trong thực tế có sự khác biệt đáng kể vì hai lý do.
Đầu tiên, các chuyên gia phần mềm cũng là con người và do đó có thể mắc sai lầm. Thứ
hai, khách hàng’yêu cầu của nó có thể thay đổi trong khi phần mềm đang được phát triển.
Trong chương này, cả hai vấn đề này đều được thảo luận sâu hơn, nhưng trước tiên chúng
tôi trình bày một nghiên cứu trường hợp nhỏ, dựa trên nghiên cứu trường hợp trong
[Tomer và Schach, 2000], minh họa các vấn đề liên quan.

Nghiên cứu nhỏ

Nghiên cứu điển hình nhỏ về Winburg

2.22.2

Để giảm tắc nghẽn giao thông ở trung tâm thành phố Winburg, Indiana, thị trưởng
thuyết phục thành phố thiết lập hệ thống giao thông công cộng. Các làn đường dành
riêng cho xe buýt sẽ được thiết lập và người đi lại sẽ được khuyến khích “đỗ và đi”;
nghĩa là, đỗ xe ở các bãi đậu xe ở ngoại ô rồi bắt xe buýt từ đó đi làm và quay về với
chi phí một đô la cho mỗi chuyến đi. Mỗi xe buýt phải có một máy bán vé chỉ chấp
nhận tiền đô la. Hành khách nhét hóa đơn vào khe khi họ bước vào xe buýt. Các
cảm biến bên trong máy tính tiền sẽ quét hóa đơn và phần mềm trong máy sử dụng
tính năng nhận dạng hình ảnh
chương 2Mô hình vòng đời phần mềm39

thuật toán để quyết định xem hành khách có thực sự nhét tờ đô la hợp lệ vào khe
hay không. Điều quan trọng là máy bán vé phải chính xác vì một khi có thông tin
cho rằng bất kỳ mảnh giấy nào cũng có tác dụng, thu nhập từ vé sẽ giảm mạnh
xuống mức 0. Ngược lại, nếu máy thường xuyên từ chối những tờ đô la hợp lệ, hành
khách sẽ ngần ngại sử dụng xe buýt. Ngoài ra, máy tính tiền phải nhanh chóng.
Hành khách cũng sẽ miễn cưỡng sử dụng xe buýt nếu máy dành 15 giây để đưa ra
quyết định về tính hợp lệ của tờ đô la - ngay cả một số lượng hành khách tương đối
nhỏ cũng phải mất nhiều phút để lên xe buýt. Do đó, yêu cầu đối với phần mềm máy
tính giá vé bao gồm thời gian phản hồi trung bình dưới 1 giây và độ chính xác trung
bình ít nhất là 98%.
 Tập 1Phiên bản đầu tiên của phần mềm được triển khai.
Tập 2Các thử nghiệm cho thấy rằng không đạt được giới hạn yêu cầu về thời gian
phản hồi trung bình là 1 giây để quyết định tính hợp lệ của tờ đô la. Trên thực tế,
trung bình phải mất 10 giây để nhận được phản hồi. Quản lý cấp cao phát hiện ra
nguyên nhân. Có vẻ như để đạt được độ chính xác 98% cần thiết, một lập trình viên
đã được người quản lý của cô ấy hướng dẫn sử dụng các số có độ chính xác kép cho
tất cả các phép tính toán học.
các kết luận. Kết quả là mỗi thao tác mất ít nhất gấp đôi thời gian so với các số có
độ chính xác đơn thông thường. Kết quả là chương trình chậm hơn nhiều so với
bình thường, dẫn đến thời gian phản hồi lâu. Các tính toán sau đó cho thấy rằng, bất
chấp những gì người quản lý đã nói với người lập trình, độ chính xác quy định là
98% có thể đạt được.
vẫn được duy trì ngay cả khi sử dụng các số có độ chính xác đơn. Lập trình viên bắt
đầu thực hiện những thay đổi cần thiết trong quá trình triển khai.
Tập 3Trước khi lập trình viên có thể hoàn thành công việc của mình, các thử
nghiệm sâu hơn về hệ thống cho thấy rằng, ngay cả khi những thay đổi được chỉ
định đối với việc triển khai được thực hiện, hệ thống vẫn sẽ có thời gian phản hồi
trung bình trên 4,5 giây, không bằng 1 giây quy định. Vấn đề là thuật toán nhận
dạng hình ảnh phức tạp. May mắn thay, một thuật toán nhanh hơn vừa được phát
hiện nên phần mềm máy tính giá vé đã được thiết kế lại và triển khai lại bằng thuật
toán mới. Điều này dẫn đến thời gian phản hồi trung bình đạt được thành công.
Tập 4Hiện tại, dự án đang chậm tiến độ và vượt quá ngân sách rất nhiều. Thị
trưởng, một doanh nhân thành đạt, có ý tưởng sáng suốt là yêu cầu nhóm phát triển
phần mềm cố gắng tăng độ chính xác của thành phần nhận dạng hóa đơn đô la của
hệ thống càng nhiều càng tốt để bán gói hàng thu được cho các công ty máy bán
hàng tự động. Để đáp ứng yêu cầu mới này, một thiết kế mới đã được áp dụng nhằm
cải thiện độ chính xác trung bình lên hơn 99,5%. Ban quản lý quyết định cài đặt
phiên bản phần mềm đó vào máy tính tiền. Tại thời điểm này, quá trình phát triển
phần mềm đã hoàn tất. Thành phố sau đó có thể bán hệ thống của mình cho hai công
ty máy bán hàng tự động nhỏ, bù đắp khoảng một phần ba chi phí vượt mức.
Lời kếtVài năm sau, các cảm biến bên trong máy tính tiền trở nên lỗi thời và cần
được thay thế bằng mẫu mới hơn. Ban quản lý đề nghị tận dụng sự thay đổi để nâng
cấp phần cứng cùng một lúc. Các chuyên gia phần mềm chỉ ra rằng việc thay đổi
phần cứng có nghĩa là cần có phần mềm mới. Họ đề nghị triển khai lại phần mềm
bằng một ngôn ngữ lập trình khác. Tại
40Phần AKhái niệm công nghệ phần mềm

HÌNH 2.2Mô hình vòng đời cây tiến hóa cho nghiên cứu điển hình nhỏ ở Winburg. (Hình chữ nhật được vẽ
bằng đường chấm chấm biểu thị việc triển khai chưa hoàn thành.)

Phát triển

BẢO TRÌ
Yêu cầu4 Phân tích4

Yêu cầu1 Phân tích1

Thiết kế4

Thiết kế1
Thiết kế3

Thực hiện1Thực hiện4

 Thực hiện2 Thực hiện3

Tập 1 Tập 2 Tập 3 Tập 4

Tại thời điểm viết bài, dự án chậm tiến độ 6 tháng và vượt 25% ngân sách. Tuy
nhiên, tất cả những người liên quan đều tự tin rằng hệ thống mới sẽ đáng tin cậy
hơn và có chất lượng cao hơn, bất chấp “những khác biệt nhỏ” trong việc đáp ứng
các yêu cầu về thời gian phản hồi và độ chính xác.
Hình 2.2 mô tảmô hình vòng đời cây tiến hóacủa nghiên cứu trường hợp nhỏ.
Các hộp ngoài cùng bên trái đại diện choTập 1. Như thể hiện trong hình, hệ thống
được phát triển từ đầu ( ). Các yêu cầu (Yêu cầu1 ), Phân tích (Phân tích1 ), thiết
kế (Thiết kế1 ), Và thực hiện (Thực hiện1 ) lần lượt theo sau. Tiếp theo, như đã mô
tả trước đây, các thử nghiệm phiên bản đầu tiên của phần mềm cho thấy không thể
đạt được thời gian phản hồi trung bình là 1 giây và việc triển khai phải được sửa đổi.
Việc triển khai được sửa đổi xuất hiện trong Hình 2.2 dưới dạngThực hiện2 . Tuy
chưa bao giờ được hoàn thành. Đó là lý do tại sao hình chữ nhật
nhiên,Thực hiện2
đại diện
gửiThực hiện2 được vẽ bằng một đường chấm chấm. TRONGTập 3, thiết
kế phải được thay đổi. Cụ thể, thuật toán nhận dạng hình ảnh nhanh hơn đã được sử
) dẫn đến một ý nghĩa được sửa đổi
dụng. Thiết kế được sửa đổi (Thiết kế3 đề cập
)
(Thực hiện3 ). Cuối cùng, trongTập 4, các yêu cầu đã được thay đổi (Yêu cầu4
để ở
tăng độ chính xác. Điều này dẫn đến các thông số kỹ thuật được sửa đổi (Phân
tích4 ), thiết kế sửa đổi (Thiết kế4 ) và thực hiện sửa đổi (Thực hiện4 ).
Trong Hình 2.2, các mũi tên liền biểu thị sự phát triển và các mũi tên nét đứt biểu
thị sự bảo trì. Ví dụ: khi thiết kế được thay đổi trongTập 3,Thiết kế3 thay thếThiết
kế1 như thiết kế củaPhân tích1 .
Mô hình cây tiến hóa là một ví dụ vềmô hình vòng đời(hoặcngười mẫu, viết
tắt), tức là một loạt các bước được thực hiện trong khi sản phẩm phần mềm được
phát triển và bảo trì. Một mô hình vòng đời khác có thể được sử dụng cho mô hình
mini
chương 2Mô hình vòng đời phần mềm41

HÌNH 2.3

Một biên tập đơn giản

phiên bản của
cuộc sống thác nước
mô hình chu kỳ
Yêu cầu

Phân tích

Thiết kế

Thực hiện

Phát triển
 BẢO TRÌ

nghiên cứu trường hợp làmô hình vòng đời thác nước[Royce, 1970]; một
phiên bản đơn giản hóa của mô hình thác nước được mô tả trong Hình 2.3. Mô hình
vòng đời cổ điển này có thể được xem như mô hình tuyến tính của Hình 2.1 với các
vòng phản hồi. Sau đó, nếu tìm thấy lỗi trong quá trình thiết kế do lỗi trong yêu cầu,
theo các mũi tên hướng lên trên nét đứt, thì nhà phát triển phần mềm có thể quay lại
từ thiết kế đến phân tích và từ đó đến các yêu cầu và thực hiện các chỉnh sửa cần
thiết ở đó. Sau đó, họ chuyển sang phân tích, sửa tài liệu đặc tả để phản ánh những
sửa đổi đối với các yêu cầu và lần lượt sửa tài liệu thiết kế. Các hoạt động thiết kế
giờ đây có thể tiếp tục ở nơi chúng đã bị tạm dừng khi phát hiện ra lỗi. Một lần nữa,
các mũi tên liền biểu thị sự phát triển; mũi tên nét đứt, bảo trì.
Mô hình thác nước chắc chắn có thể được sử dụng để trình bày trường hợp nghiên
cứu nhỏ của Winburg, nhưng, không giống như mô hình cây tiến hóa trong Hình
2.2, nó không thể hiển thị thứ tự của các sự kiện. Mô hình cây tiến hóa có lợi thế
hơn mô hình thác nước. Vào cuối mỗi tập chúng ta có mộtđường cơ sở, nghĩa là
một bộ tạo tác hoàn chỉnh (hãy nhớ lại rằng mộthiện vậtlà một thành phần cấu
thành của một sản phẩm phần mềm). Có bốn đường cơ sở trong Hình 2.2. họ đang
Ở cuối củaTập 1:Yêu cầu1,Phân tích1,Thiết kế1,Thực hiện1 Ở cuối củaTập
2:Yêu cầu1,Phân tích1,Thiết kế1,Thực hiện2 Ở cuối củaTập 3:Yêu cầu1,Phân
tích1,Thiết kế3,Thực hiện3 Ở cuối củaTập 4:Yêu cầu4,Phân tích4,Thiết
kế4,Thực hiện4 Đường cơ sở đầu tiên là tập hợp các tạo tác ban đầu; đường cơ sở
thứ hai phản ánh sự sửa đổi
(nhưng chưa bao giờ hoàn thành)Thực hiện2 củaTập 2, cùng với các yêu cầu, phân
tích và thiết kế không thay đổi củaTập 1. Đường cơ sở thứ ba giống như đường cơ
sở thứ nhất nhưng có thay đổi về thiết kế và triển khai. Đường cơ sở thứ tư là tập
hợp đầy đủ các tạo phẩm mới được hiển thị trong Hình 2.2. Chúng ta xem lại khái
niệm đường cơ sở trong Chương 5 và 16.
42Phần AKhái niệm công nghệ phần mềm

2.3 Bài học từ nghiên cứu điển hình nhỏ ở Winburg

Nghiên cứu trường hợp nhỏ của Winburg mô tả quá trình phát triển một sản phẩm phần
mềm gặp trục trặc vì một số nguyên nhân không liên quan, chẳng hạn như chiến lược triển
khai kém (sử dụng số có độ chính xác kép không cần thiết) và quyết định sử dụng thuật
toán quá chậm. Cuối cùng, dự án đã thành công. Tuy nhiên, câu hỏi rõ ràng là, việc phát
triển phần mềm có
opment thực sự hỗn loạn như vậy trong thực tế? Trên thực tế, nghiên cứu trường hợp nhỏ
ít gây tổn thương hơn nhiều so với nhiều dự án phần mềm, nếu không muốn nói là phần
lớn. Trong nghiên cứu điển hình nhỏ ở Winburg, chỉ có hai phiên bản mới của phần mềm
do lỗi (sử dụng số có độ chính xác kép không phù hợp; sử dụng thuật toán không đáp ứng
được yêu cầu về thời gian phản hồi) và chỉ có một phiên bản mới do một thay đổi do
khách hàng thực hiện (nhu cầu tăng độ chính xác).
Tại sao cần có nhiều thay đổi đối với một sản phẩm phần mềm? Đầu tiên, như đã nêu
trước đây, các chuyên gia phần mềm cũng là con người và do đó sẽ mắc sai lầm. Thứ hai,
sản phẩm phần mềm là mô hình của thế giới thực và thế giới thực luôn thay đổi. Vấn đề
này sẽ được thảo luận chi tiết hơn ở Phần 2.4.

Nghiên cứu nhỏ

C
 Nghiên cứu tình huống nhỏ về máy kéo Teal
2.4

Teal Tractors, Inc., bán máy kéo ở hầu hết các vùng của Hoa Kỳ. Công ty đã yêu
cầu bộ phận phần mềm của mình phát triển một sản phẩm mới có thể xử lý tất cả
các khía cạnh kinh doanh của mình. Ví dụ: sản phẩm phải có khả năng xử lý doanh
số bán hàng, hàng tồn kho và hoa hồng trả cho nhân viên bán hàng, cũng như cung
cấp tất cả các chức năng kế toán cần thiết. Trong khi sản phẩm phần mềm này đang
được triển khai, Teal Tractors mua một công ty máy kéo của Canada. Ban quản lý
của Teal Tractors quyết định rằng, để tiết kiệm tiền, các hoạt động ở Canada phải
được tích hợp vào các hoạt động ở Hoa Kỳ. Điều đó có nghĩa là phần mềm phải
được thay đổi trước khi hoàn thiện:
1. Nó phải được sửa đổi để xử lý các khu vực bán hàng bổ sung.
2. Nó phải được mở rộng để giải quyết những khía cạnh kinh doanh được xử lý
khác ở Canada, chẳng hạn như thuế.
3. Nó phải được mở rộng để xử lý hai loại tiền tệ khác nhau, đô la Mỹ và đô la
Canada.
Teal Tractors là một công ty đang phát triển nhanh chóng với triển vọng tuyệt vời
trong tương lai. Việc tiếp quản công ty máy kéo Canada là một diễn biến tích cực,
có thể mang lại lợi nhuận thậm chí còn lớn hơn trong những năm tới. Tuy nhiên, từ
quan điểm của bộ phận phần mềm, việc mua lại công ty Canada có thể là một thảm
họa. Trừ khi các yêu cầu, phân tích và thiết kế đã được thực hiện nhằm mục đích kết
hợp các phần mở rộng có thể có trong tương lai, công việc liên quan đến việc bổ
sung các khu vực bán hàng ở Canada có thể tuyệt vời đến mức có thể hiệu quả hơn
nếu loại bỏ mọi thứ đã thực hiện cho đến nay và bắt đầu lại từ đầu. Lý do là việc
thay đổi sản phẩm ở giai đoạn này cũng tương tự như việc cố gắng sửa chữa một sản
phẩm phần mềm ở giai đoạn cuối của vòng đời của nó (xem Hình 1.6). Mở rộng
phần mềm sang
chương 2Mô hình vòng đời phần mềm43

việc xử lý các khía cạnh cụ thể đối với thị trường Canada cũng như đồng tiền
Canada có thể khó khăn như nhau.
Ngay cả khi phần mềm đã được tính toán kỹ lưỡng và thiết kế ban đầu thực sự có
thể mở rộng, thì thiết kế của sản phẩm được chắp vá lại với nhau không thể gắn kết
như lẽ ra nếu nó được phát triển ngay từ đầu để phục vụ cho cả Hoa Kỳ. Các bang
và Canada. Điều này có thể có tác động nghiêm trọng đến việc bảo trì trong tương
lai.
Bộ phận phần mềm của Teal Tractors là nạn nhân củavấn đề mục tiêu chuyển
động. Nghĩa là, trong khi phần mềm đang được phát triển thì các yêu cầu sẽ thay
đổi. Không có vấn đề gì nếu lý do thay đổi là cực kỳ đáng giá. Thực tế là việc tiếp
quản công ty Canada có thể gây bất lợi cho chất lượng của phần mềm đang được
phát triển.

Trong một số trường hợp, lý do khiến mục tiêu di chuyển ít lành tính hơn. Đôi khi một
nhà quản lý cấp cao đầy quyền lực trong một tổ chức liên tục thay đổi quan điểm của mình
về chức năng của một sản phẩm phần mềm đang được phát triển. Trong các trường hợp
khác, cótính năng leo, một loạt các bổ sung nhỏ, gần như tầm thường, vào các yêu cầu.
Nhưng bất kể lý do là gì, những thay đổi thường xuyên, dù chúng có vẻ nhỏ đến đâu, đều
có hại cho sức khỏe của sản phẩm phần mềm. Điều quan trọng là sản phẩm phần mềm
phải được thiết kế như một tập hợp các thành phần độc lập nhất có thể, sao cho sự thay đổi
đối với một phần của phần mềm không gây ra lỗi ở phần mã dường như không liên quan,
 cái gọi làlỗi hồi quy. Khi nhiều thay đổi được thực hiện, hiệu quả là tạo ra sự phụ thuộc
trong mã. Cuối cùng, có quá nhiều sự phụ thuộc đến nỗi hầu như bất kỳ thay đổi nào cũng
gây ra một hoặc nhiều lỗi hồi quy. Khi đó, điều duy nhất có thể làm là thiết kế lại toàn bộ
sản phẩm phần mềm và triển khai lại nó.
Thật không may, không có giải pháp nào được biết đến cho vấn đề mục tiêu chuyển động.
Liên quan đến những thay đổi tích cực về yêu cầu, các công ty đang phát triển sẽ luôn
thay đổi và những thay đổi này phải được phản ánh trong các sản phẩm phần mềm quan
trọng của công ty. Đối với những thay đổi tiêu cực, nếu cá nhân yêu cầu những thay đổi
đó có đủ ảnh hưởng thì không thể làm gì để ngăn cản những thay đổi được thực hiện, gây
phương hại đến khả năng bảo trì thêm của sản phẩm phần mềm.

2.5 Lặp lại và tăng dần

Do hậu quả của cả vấn đề mục tiêu di động và nhu cầu sửa chữa những lỗi không thể
tránh khỏi trong quá trình phát triển một sản phẩm phần mềm, vòng đời của các sản phẩm
phần mềm thực tế giống với mô hình cây tiến hóa trong Hình 2.2 hoặc mô hình thác nước
trong Hình 2.2. 2.3 , thay vì chuỗi lý tưởng hóa của Hình 2.1 . Một hậu quả của thực tế
này là việc nói về (nói) chẳng có ý nghĩa gì nhiều “cácgiai đoạn phân tích.” Thay vào đó,
các hoạt động của giai đoạn phân tích được trải đều trong suốt vòng đời. Tương tự, Hình
2.2 cho thấy bốn phiên bản triển khai khác nhau, một trong số đó (Thực hiện2 ) chưa bao
giờ được hoàn thành do vấn đề mục tiêu di chuyển.
Xem xét các phiên bản kế tiếp của một tạo phẩm, ví dụ: tài liệu đặc tả hoặc mô-đun mã.
Từ quan điểm này, quá trình cơ bản là lặp đi lặp lại. Nghĩa là, chúng tôi tạo ra phiên bản
đầu tiên của hiện vật, sau đó chúng tôi sửa lại nó và tạo ra phiên bản thứ hai, v.v. Của
chúng tôi
44Phần AKhái niệm công nghệ phần mềm

Mục đích là mỗi phiên bản gần với mục tiêu của chúng tôi hơn so với phiên bản trước đó
và cuối cùng chúng tôi xây dựng một phiên bản phù hợp.Lặp lạilà một khía cạnh nội tại
của công nghệ phần mềm và các mô hình vòng đời lặp đi lặp lại đã được sử dụng trong
hơn 30 năm [Larman và Basili, 2003]. Ví dụ, mô hình thác nước được đưa ra lần đầu tiên
vào năm 1970, có tính lặp lại (nhưng không tăng dần).
Khía cạnh thứ hai của việc phát triển phần mềm trong thế giới thực là sự hạn chế đối với
chúng tôi bởiĐịnh luật Miller. Năm 1956, George Miller, giáo sư tâm lý học, đã chỉ ra
rằng, tại bất kỳ thời điểm nào, con người chúng ta chỉ có khả năng tập trung vào khoảng
bảy khối (đơn vị thông tin) [Miller, 1956]. Tuy nhiên, một tạo phẩm phần mềm điển hình
có nhiều hơn bảy phần. Ví dụ: một tạo phẩm mã có thể có nhiều hơn bảy biến và một tài
liệu yêu cầu có thể có nhiều hơn bảy biến. Một cách mà con người chúng ta xử lý hạn chế
về lượng thông tin chúng ta có thể xử lý bất cứ lúc nào là sử dụngtinh chỉnh từng
bước. Nghĩa là, chúng ta tập trung vào những khía cạnh hiện tại quan trọng nhất và hoãn
lại những khía cạnh hiện ít quan trọng hơn. Nói cách khác, mọi khía cạnh cuối cùng đều
được xử lý nhưng theo thứ tự quan trọng hiện tại. Điều này có nghĩa là chúng tôi bắt đầu
bằng cách xây dựng một tạo phẩm chỉ giải quyết được một phần nhỏ những gì chúng tôi
đang cố gắng đạt được. Sau đó, chúng tôi xem xét các khía cạnh khác của vấn đề và thêm
các phần mới thu được vào tạo phẩm hiện có. Ví dụ: chúng ta có thể xây dựng một tài liệu
yêu cầu bằng cách xem xét bảy yêu cầu mà chúng ta cho là quan trọng nhất. Sau đó,
chúng tôi sẽ thỏa thuận
sắp xếp bảy yêu cầu quan trọng nhất tiếp theo, v.v. Đây là một quá trình tăng dần.Tăng
dầncũng là một khía cạnh nội tại của công nghệ phần mềm; phát triển phần mềm gia tăng
đã hơn 45 tuổi [Larman và Basili, 2003].
Trong thực tế, phép lặp và phép tăng được sử dụng kết hợp với nhau. Nghĩa là, một tạo
phẩm được xây dựng từng phần một (gia tăng) và mỗi gia tăng trải qua nhiều phiên bản
 (lặp lại). Những ý tưởng này được minh họa trong Hình 2.2, thể hiện vòng đời của nghiên
cứu trường hợp nhỏ Winburg (Phần 2.2 và 2.3). Như thể hiện trong hình đó, không có một
“giai đoạn yêu cầu” nào như vậy. Thay vào đó, các yêu cầu của khách hàng được trích
xuất và phân tích hai lần, đưa ra các yêu cầu ban đầu (Yêu cầu1 ) và các yêu cầu được sửa
đổi (Yêu cầu4 ). Tương tự, không có “giai đoạn triển khai” duy nhất mà có bốn giai đoạn
riêng biệt trong đó mã được tạo ra và sau đó được sửa đổi.
Những ý tưởng này được khái quát hóa trong Hình 2.4, phản ánh các khái niệm cơ bản
làm nền tảng chomô hình vòng đời lặp đi lặp lại và tăng dần[Jacobson, Booch và
Rumbaugh, 1999]. Hình này cho thấy sự phát triển của một sản phẩm phần mềm theo bốn
giai đoạn, được dán nhãnTăng A,Tăng B,Tăng C, VàTăng. Trục ngang là thời gian và
trục tung là giờ người (một giờ người là khối lượng công việc mà một người có thể làm
trong 1 giờ), do đó, vùng tô bóng dưới mỗi đường cong là tổng nỗ lực cho mức tăng đó.
Điều quan trọng cần đánh giá cao là Hình 2.4 chỉ mô tả một cách khả thi mà một sản
phẩm phần mềm có thể được chia thành các phần tăng dần. Một sản phẩm phần mềm khác
có thể được xây dựng chỉ với 2 bước, trong khi sản phẩm thứ ba có thể yêu cầu 14. Hơn
nữa, hình này không nhằm mục đích thể hiện chính xác cách thức phát triển một sản phẩm
phần mềm. Thay vào đó, nó cho thấy sự nhấn mạnh thay đổi như thế nào từ lần lặp này
sang lần lặp khác.
Các giai đoạn tuần tự của Hình 2.1 là các cấu trúc nhân tạo. Thay vào đó, như được phản
ánh rõ ràng trong Hình 2.4, chúng ta phải thừa nhận rằng sự khác biệtquy trình công
việc(hoạt động) được thực hiện trong toàn bộ vòng đời. Có nămquy trình công việc
cốt lõi, cácquy trình làm việc yêu cầu,quy trình làm việc phân tích,quy trình
công việc thiết kế,quy trình thực hiện, Vàkiểm tra quy trình làm việcvà, như đã
nêu ở câu trước, cả năm điều này đều được thực hiện trong suốt cuộc đời
chương 2Mô hình vòng đời phần mềm45

HÌNH 2.4Việc xây dựng một sản phẩm phần mềm theo bốn giai đoạn.

Mức tăng A Mức tăng B Mức tăng C Mức tăng D

Yêu cầu
quy trình làm việc
khai
S

Bài kiểm tra

r

TRONG

ồ quy trình làm việc

h-

Nó là

Phân tích
quy trình làm việc

Thiết kế Thời gian

quy trình làm việc

Quy trình triển

chu kỳ của một sản phẩm phần mềm. Tuy nhiên, có những lúc một quy trình công việc
chiếm ưu thế hơn bốn quy trình còn lại.
Ví dụ, khi bắt đầu vòng đời, các nhà phát triển phần mềm rút ra một bộ yêu cầu ban đầu.
Nói cách khác, khi bắt đầu vòng đời lặp lại và tăng dần, quy trình công việc yêu cầu chiếm
 ưu thế. Các tạo phẩm yêu cầu này được mở rộng và sửa đổi trong suốt phần còn lại của
vòng đời. Trong thời gian đó, bốn quy trình công việc còn lại (phân tích, thiết kế, triển
khai và kiểm tra) chiếm ưu thế. Nói cách khác, quy trình công việc yêu cầu là quy trình
công việc chính ở đầu vòng đời, nhưng mối quan hệ của nó
tầm quan trọng của nó giảm dần sau đó. Ngược lại, quy trình triển khai và kiểm thử chiếm
nhiều thời gian của các thành viên trong nhóm phát triển phần mềm ở cuối vòng đời hơn
so với lúc ban đầu.
Các hoạt động lập kế hoạch và tài liệu được thực hiện trong suốt vòng đời lặp đi lặp lại và
tăng dần. Hơn nữa, kiểm thử là một hoạt động chính trong mỗi lần lặp và đặc biệt là vào
cuối mỗi lần lặp. Ngoài ra, toàn bộ phần mềm đều được kiểm tra kỹ lưỡng sau khi hoàn
thành; tại thời điểm đó, việc kiểm tra và sau đó sửa đổi việc triển khai dựa trên kết quả của
các thử nghiệm khác nhau hầu như là hoạt động duy nhất của nhóm phần mềm. Điều này
được phản ánh trong quy trình thử nghiệm của Hình 2.4.
Hình 2.4 cho thấy bốn mức tăng. Coi nhưTăng A, được mô tả bởi cột bên trái. Khi bắt
đầu giai đoạn tăng trưởng này, các thành viên trong nhóm yêu cầu sẽ xác định các yêu cầu
của khách hàng. Khi hầu hết các yêu cầu đã được xác định, phiên bản đầu tiên của phần
phân tích có thể được bắt đầu. Khi quá trình phân tích đã đạt được tiến bộ đầy đủ, phiên
bản đầu tiên của thiết kế có thể được bắt đầu. Thậm chí một số mã hóa thường được thực
hiện trong lần tăng đầu tiên này, có lẽ dưới dạng nguyên mẫu chứng minh khái niệm để
kiểm tra tính khả thi của một phần sản phẩm phần mềm được đề xuất. Cuối cùng, như đã
đề cập trước đó,
46Phần AKhái niệm công nghệ phần mềm

HÌNH 2.5 Tăng B

Bộ ba
Lặp lại B.1 Lặp lại B.2 Lặp lại B.3
lặp đi lặp lại của
Tăng B
quy trình làm việc
của sự lặp đi lặp lại
và-tăng dần Bài kiểm tra
quy trình làm việc
mô hình vòng đời
của Hình 2.4 .
S

TRONG

Nó là

Yêu cầu
quy trình làm việc

Phân tích
quy trình làm việc
Thời gian
Thiết kế
quy trình làm việc Đường cơ sở

Thực hiện

các hoạt động lập kế hoạch, kiểm tra và ghi tài liệu bắt đầu từ Ngày thứ nhất và tiếp tục từ
đó trở đi cho đến khi sản phẩm phần mềm cuối cùng được giao cho khách hàng.
Tương tự, nồng độ chính trong quá trìnhTăng Blà về yêu cầu và quy trình phân tích, sau
đó là quy trình thiết kế. Sự nhấn mạnh trong thời gianTăng CĐầu tiên là quy trình thiết
 kế, sau đó là quy trình triển khai và quy trình kiểm tra.
Cuối cùng, trong thời gianTăng, quy trình triển khai và quy trình kiểm tra chiếm ưu thế.
Như được phản ánh trong Hình 1.4, khoảng 1/5 tổng nỗ lực được dành cho các yêu cầu và
quy trình phân tích (cùng nhau), 1/5 khác cho quy trình thiết kế và khoảng 3/5 cho việc
triển khai. quy trình làm việc. Tổng kích thước tương đối của các vùng tô bóng trong Hình
2.4 phản ánh những giá trị này.
Có sự lặp lại trong mỗi lần tăng của Hình 2.4. Điều này được thể hiện trong Hình 2.5, mô
tả ba lần lặp trongTăng B. (Hình 2.5 là hình ảnh phóng to của cột thứ hai trong Hình 2.4).
Như được hiển thị trong Hình 2.5, mỗi lần lặp lại bao gồm tất cả năm luồng công việc
nhưng lại ở các tỷ lệ khác nhau.
Một lần nữa, cần phải nhấn mạnh rằng Hình 2.5 không nhằm mục đích chỉ ra rằng mỗi
lần tăng bao gồm chính xác ba lần lặp. Số lần lặp thay đổi theo từng mức tăng. Mục đích
của Hình 2.5 là hiển thị quá trình lặp trong mỗi lần tăng và nhắc lại rằng tất cả năm quy
trình công việc (yêu cầu, phân tích, thiết kế, triển khai và thử nghiệm, cùng với việc lập kế
hoạch và tài liệu) đều được thực hiện trong hầu hết mỗi lần lặp, mặc dù ở các mức độ khác
nhau. tỷ lệ mỗi lần.
Như đã giải thích trước đây, Hình 2.4 phản ánh sự gia tăng nội tại trong quá trình phát
triển của mọi sản phẩm phần mềm. Hình 2.5 hiển thị rõ ràng phép lặp nằm dưới phần tăng
dần. Cụ thể, Hình 2.5 mô tả ba bước lặp liên tiếp, trái ngược với một bước tăng lớn. Chi
tiết hơn,Lặp lại B.1gồm các yêu cầu,
chương 2Mô hình vòng đời phần mềm47

phân tích, thiết kế, triển khai và kiểm tra các quy trình công việc, được biểu thị bằng hình
chữ nhật nét đứt ngoài cùng bên trái với các góc tròn. Việc lặp lại tiếp tục cho đến khi các
thành phần của mỗi quy trình trong năm quy trình công việc đều đạt yêu cầu.
Tiếp theo, tất cả năm bộ tạo tác được lặp lại trongLặp lại B.2.Lần lặp thứ hai này có bản
chất tương tự như lần đầu tiên. Nghĩa là, các tạo phẩm yêu cầu được cải thiện, từ đó kích
hoạt các cải tiến đối với các tạo phẩm phân tích, v.v., như được phản ánh trong lần lặp thứ
hai của Hình 2.5, và tương tự cho lần lặp thứ ba.
Quá trình lặp lại và tăng dần bắt đầu từ đầuTăng Avà tiếp tục cho đến hếtTăng.Sản
phẩm phần mềm hoàn chỉnh sau đó sẽ được cài đặt trên máy tính của khách hàng.

Nghiên cứu nhỏ

C
2.6Xem lại nghiên cứu điển hình nhỏ về Winburg

Hình 2.6 cho thấy mô hình cây tiến hóa của nghiên cứu điển hình nhỏ ở Winburg (
Hình 2.2 ) được xếp chồng lên mô hình lặp và tăng dần (quy trình kiểm tra không
được hiển thị vì mô hình cây tiến hóa giả định thử nghiệm liên tục, được giải thích
trong Phần 1.7) . Hình 2.6 làm sáng tỏ thêm bản chất của việc tăng dần:
•Tăng Atương ứng vớiTập 1,Tăng Btương ứng vớiTập 2, và như thế.

HÌNH 2.6Mô hình vòng đời cây tiến hóa cho nghiên cứu điển hình nhỏ ở Winburg ( Hình 2.2 ) được áp dụng trên
mô hình vòng đời lặp đi lặp lại và tăng dần.

Phát triển
BẢO TRÌ
Mức tăng A Mức tăng B Mức tăng C Mức tăng D
 tích4

Quy trình triển

khai
S Yêu cầu1 Phân Thiết kế4
r

TRONG

h-

tích1 Thiết kế3

Thực hiện4 Tập
ồ

Nó là

Quy trình làm 4

việc yêu cầu Thực hiện2 Tập Thực hiện3
Thiết kế1

2 Tập 3
Phân tích
quy trình làm Thời gian
việc Thực hiện1 Tập
Yêu cầu4 Phân

1
Thiết kế
quy trình làm
việc
48Phần AKhái niệm công nghệ phần mềm

•Từ quan điểm của mô hình lặp và tăng dần, hai trong số các phần tăng thêm không
bao gồm tất cả bốn quy trình công việc. Chi tiết hơn,Tăng B(Tập 2) TRONG
chỉ bao gồm quy trình thực hiện vàTăng C(Tập 3) bao gồm
chỉ có quy trình công việc thiết kế và quy trình công việc thực hiện. Sự lặp lại-và
mô hình gia tăng không yêu cầu mọi quy trình công việc phải được thực hiện trong
mỗi lần tăng.
•Hơn nữa, trong Hình 2.4 hầu hết quy trình công việc yêu cầu được thực hiện
trongTăng AVàTăng B, trong khi ở Hình 2.6 nó được thực hiện trong
Tăng AVàTăng. Ngoài ra, trong Hình 2.4 hầu hết các phân tích đều dựa trên
Hình thành trongTăng B, trong khi ở Hình 2.6, quy trình phân tích được thực hiện
TRONGTăng AVàTăng. Điều này chỉ ra rằng cả Hình 2.4 và
Hình 2.6 thể hiện cách xây dựng từng sản phẩm phần mềm. Thay vào đó, mỗi
hình hiển thị cách xây dựng một sản phẩm phần mềm cụ thể, làm nổi bật các
mục bên dưới.
nằm lặp đi lặp lại và tăng dần.
•Quy mô nhỏ và sự chấm dứt đột ngột của quy trình triển khai trong quá trình thực
hiệnTăng B(Tập 2) của Hình 2.6 cho thấyThực hiện2 không phải
hoàn thành. Phần màu xám phản ánh một phần của quy trình triển khai
đã không được thực hiện.
•Ba mũi tên nét đứt của mô hình cây tiến hóa cho thấy rằng mỗi mức tăng tạo thành
sự duy trì mức tăng trước đó. Trong ví dụ này, mức tăng thứ hai và thứ ba là các
trường hợp bảo trì khắc phục. Cái đó
nghĩa là mỗi lần tăng sẽ sửa các lỗi ở lần tăng trước đó. Như trước đây
giải thích,Tăng B(Tập 2) sửa quy trình thực hiện bằng cách
thay thế các biến có độ chính xác kép bằng các biến có độ chính xác đơn thông
thường.Tăng C(Tập 3) sửa quy trình thiết kế bằng cách sử dụng hình ảnh nhanh
hơn
thuật toán nhận dạng, từ đó cho phép đáp ứng được yêu cầu về thời gian đáp
ứng. Sau đó phải có những thay đổi tương ứng trong công tác thực hiện
chảy. Cuối cùng, trongTăng(Tập 4) các yêu cầu được thay đổi thành
 quy định cải thiện độ chính xác tổng thể, một ví dụ về bảo trì hoàn hảo. Cor
Sau đó, những thay đổi đáp ứng sẽ được thực hiện đối với quy trình công việc
phân tích, quy trình công việc thiết kế và quy trình công việc triển khai.

2.7 Rủi ro và các khía cạnh khác của việc lặp lại
và tăng dần
Một cách khác để xem xét sự lặp lại và tăng dần là toàn bộ dự án được chia thành các dự
án nhỏ hơn (hoặc các phần tăng dần). Mỗi dự án nhỏ mở rộng các yêu cầu, phân tích, thiết
kế, triển khai và thử nghiệm các tạo phẩm. Cuối cùng, tập hợp các tạo phẩm tạo thành sản
phẩm phần mềm hoàn chỉnh.
Trên thực tế, mỗi dự án nhỏ không chỉ bao gồm việc mở rộng các tạo phẩm. Điều cần
thiết là phải kiểm tra xem mỗi tạo phẩm có chính xác hay không (quy trình kiểm tra) và
thực hiện bất kỳ thay đổi cần thiết nào đối với các tạo phẩm có liên quan. Quá trình kiểm
tra và sửa đổi, sau đó kiểm tra lại và sửa đổi, v.v., rõ ràng là có bản chất lặp đi lặp lại. Nó
tiếp tục cho đến khi các thành viên của
chương 2Mô hình vòng đời phần mềm49

nhóm phát triển hài lòng với tất cả các thành phần của dự án nhỏ (hoặc phần tăng thêm)
hiện tại. Khi điều đó xảy ra, họ tiến tới bước tăng tiếp theo.
So sánh Hình 2.3 (mô hình thác nước) với Hình 2.5 (xem các bước lặp trongTăng B) cho
thấy mỗi lần lặp có thể được xem như một mô hình thác nước nhỏ nhưng hoàn chỉnh.
Nghĩa là, trong mỗi lần lặp lại, các thành viên của nhóm phát triển sẽ trải qua các giai
đoạn yêu cầu, phân tích, thiết kế và triển khai cổ điển trên một phần cụ thể của sản phẩm
phần mềm. Từ quan điểm này, mô hình lặp và tăng dần của Hình 2.4 và 2.5 có thể được
xem như một chuỗi các mô hình thác nước liên tiếp.
Mô hình lặp và tăng dần có nhiều điểm mạnh:

1. Có nhiều cơ hội để kiểm tra xem sản phẩm phần mềm có đúng không. Mỗi lần lặp lại
đều kết hợp quy trình kiểm thử, vì vậy mỗi lần lặp lại là một cơ hội khác để kiểm tra tất
cả các tạo phẩm đã được phát triển cho đến thời điểm này. Các lỗi được phát hiện và
sửa chữa càng muộn thì chi phí càng cao, như trong Hình 1.6. Không giống như mô
hình thác nước cổ điển, mỗi lần lặp trong số nhiều lần lặp của mô hình lặp và tăng dần
mang lại cơ hội hơn nữa để tìm ra lỗi và sửa chúng, từ đó tiết kiệm tiền.
2. Sự vững chắc của kiến ​trúc cơ bản có thể được xác định tương đối sớm trong vòng đời.
Cácngành kiến ​trúccủa một sản phẩm phần mềm bao gồm các thành phần khác nhau
và cách chúng khớp với nhau. Một sự tương tự là kiến ​trúc của một cathe dral, có thể
được mô tả là theo phong cách La Mã, Gothic hoặc Baroque, cùng với những khả năng
khác. Tương tự, kiến ​trúc của một sản phẩm phần mềm có thể được mô tả là hướng đối
tượng ( Chương 7 ), các đường dẫn và bộ lọc (các thành phần UNIX hoặc Linux) hoặc
máy khách-máy chủ (với một máy chủ trung tâm cung cấp khả năng lưu trữ tệp cho
mạng máy tính khách). Kiến trúc của một sản phẩm phần mềm được phát triển bằng
mô hình lặp và tăng dần phải có đặc tính là nó có thể được mở rộng liên tục (và, nếu
cần, có thể dễ dàng thay đổi) để kết hợp với phần tăng dần tiếp theo. Có thể xử lý các
phần mở rộng và thay đổi như vậy mà không bị hỏng được gọi làsự vững chãi. Tính
mạnh mẽ là một phẩm chất quan trọng trong quá trình phát triển một sản phẩm phần
mềm; nó rất quan trọng trong quá trình bảo trì sau giao hàng. Vì vậy, nếu một sản phẩm
phần mềm tồn tại qua quá trình bảo trì sau giao hàng 12, 15 hoặc hơn thông thường thì
kiến ​trúc cơ bản phải mạnh mẽ. Khi sử dụng mô hình lặp và tăng dần, sẽ sớm thấy rõ
liệu kiến ​trúc đó có mạnh mẽ hay không. Nếu, trong quá trình kết hợp (chẳng hạn)
bước tăng thứ ba, rõ ràng là phần mềm được phát triển cho đến nay phải được tổ chức
 lại một cách quyết liệt và triển khai lại các phần lớn, thì rõ ràng là kiến ​trúc đó không
đủ mạnh mẽ. Khách hàng phải quyết định có nên từ bỏ dự án hay bắt đầu lại từ đầu.
Một khả năng khác là thiết kế lại kiến ​trúc để mạnh mẽ hơn, sau đó tái sử dụng càng
nhiều tạo phẩm hiện tại càng tốt trước khi tiếp tục giai đoạn tăng trưởng tiếp theo. Một
lý do khác tại sao một kiến ​trúc mạnh mẽ lại quan trọng đến vậy là vấn đề mục tiêu
chuyển động (Phần 2.4). Gần như chắc chắn rằng các yêu cầu của khách hàng sẽ thay
đổi, do sự phát triển trong tổ chức của khách hàng hoặc do khách hàng liên tục thay đổi
ý kiến ​về những gì phần mềm mục tiêu phải làm. Kiến trúc càng mạnh mẽ thì phần
mềm càng có khả năng thay đổi linh hoạt hơn. Không thể thiết kế một kiến ​trúc có thể
đương đầu với quá nhiều thay đổi mạnh mẽ. Tuy nhiên, nếu những thay đổi cần thiết có
phạm vi hợp lý thì một kiến ​trúc mạnh mẽ sẽ có khả năng kết hợp những thay đổi đó
mà không cần phải cơ cấu lại mạnh mẽ.
50Phần AKhái niệm công nghệ phần mềm

3. Mô hình lặp lại và gia tăng cho phép chúng tôi sớm giảm thiểu rủi ro.Rủi roluôn tham
gia vào việc phát triển và bảo trì phần mềm. Ví dụ, trong nghiên cứu điển hình nhỏ ở
Winburg, thuật toán nhận dạng hình ảnh ban đầu không đủ nhanh; luôn có nguy cơ
rằng một sản phẩm phần mềm đã hoàn thiện sẽ không đáp ứng được những hạn chế về
thời gian của nó. Việc phát triển từng bước một sản phẩm phần mềm cho phép chúng
tôi sớm giảm thiểu những rủi ro như vậy trong vòng đời. Ví dụ: giả sử một mạng cục
bộ (LAN) mới đang được phát triển và có lo ngại rằng phần cứng mạng hiện tại không
đủ cho sản phẩm phần mềm mới. Sau đó, một hoặc hai lần lặp đầu tiên hướng tới việc
xây dựng các phần của phần mềm có giao diện với phần cứng mạng. Nếu hóa ra, trái
ngược với lo ngại của các nhà phát triển, mạng có đủ khả năng cần thiết thì các nhà
phát triển có thể tiến hành dự án với niềm tin rằng rủi ro này đã được giảm thiểu. Mặt
khác, nếu mạng thực sự không thể đáp ứng được lưu lượng bổ sung mà mạng LAN
mới tạo ra thì điều này sẽ được thông báo cho khách hàng sớm trong vòng đời, khi chỉ
một phần nhỏ ngân sách được chi tiêu. Giờ đây, khách hàng có thể quyết định có nên
hủy dự án hay không, mở rộng khả năng của mạng hiện tại, mua mạng mới và mạnh
hơn hoặc thực hiện một số hành động khác.
4. Chúng tôi luôn có phiên bản phần mềm hoạt động được. Giả sử một sản phẩm phần
mềm được phát triển sử dụng mô hình vòng đời cổ điển trong Hình 2.1. Chỉ đến cuối
dự án mới có phiên bản hoạt động của sản phẩm phần mềm. Ngược lại, khi sử dụng mô
hình vòng đời lặp và tăng dần, ở cuối mỗi lần lặp, sẽ có một phiên bản hoạt động của
một phần của sản phẩm phần mềm mục tiêu tổng thể. Khách hàng và những người
dùng dự kiến ​có thể thử nghiệm phiên bản đó và xác định những thay đổi nào là cần
thiết để đảm bảo rằng phiên bản này sẽ được triển khai hoàn chỉnh trong tương lai.
tâm trí đáp ứng được nhu cầu của họ. Những thay đổi này có thể được thực hiện cho
lần tăng tiếp theo, sau đó khách hàng và người dùng có thể xác định xem có cần thay
đổi thêm hay không. Một biến thể của điều này là cung cấp một phần phiên bản của
sản phẩm phần mềm, không chỉ để thử nghiệm mà còn để tạo thuận lợi cho việc giới
thiệu sản phẩm phần mềm mới trong tổ chức khách hàng. Sự thay đổi hầu như luôn
được coi là một mối đe dọa. Thông thường, người dùng lo sợ rằng việc giới thiệu một
sản phẩm phần mềm mới tại nơi làm việc sẽ khiến họ mất việc vào tay máy tính. Tuy
nhiên, việc giới thiệu dần dần một sản phẩm phần mềm có thể mang lại hai lợi ích. Đầu
tiên, phần dưới
nỗi sợ bị thay thế bởi máy tính đã giảm đi. Thứ hai, nhìn chung sẽ dễ dàng hơn để tìm
hiểu chức năng của một sản phẩm phần mềm phức tạp nếu chức năng đó được giới
thiệu từng bước trong khoảng thời gian vài tháng chứ không phải toàn bộ.
5. Có bằng chứng thực nghiệm cho thấy vòng đời lặp đi lặp lại và tăng dần có hiệu quả.
Biểu đồ tròn của Hình 1.1 thể hiện kết quả báo cáo của Standish Group về các dự án
hoàn thành năm 2006 [Rubenstein, 2007]. Trên thực tế, báo cáo này (còn gọi là Báo
cáo CHAOS—xem phần Phòng trường hợp bạn muốn biết Hộp 2.2) được xuất bản 2
năm một lần. Hình 2.7 cho thấy kết quả từ năm 1994 đến năm 2006. Tỷ lệ sản phẩm
 thành công tăng đều đặn từ 16% năm 1994 lên 34% năm 2002, nhưng sau đó giảm
xuống còn 29% vào năm 2004. Trong cả hai năm 2002 [Softwaremag.com, 2004] và
2004 [Hayes, 2004] báo cáo, một trong những yếu tố gắn liền với sự thành công của dự
án là việc sử dụng quy trình lặp đi lặp lại. (Các lý do được đưa ra dẫn đến sự sụt giảm
tỷ lệ dự án thành công trong năm 2004 bao gồm: nhiều dự án lớn hơn năm 2002, việc
sử dụng mô hình thác nước, thiếu sự tham gia của người dùng và thiếu sự hỗ trợ từ các
nhà điều hành cấp cao [Hayes, 2004].) , tỷ lệ dự án thành công lại tăng lên trong
nghiên cứu năm 2006 lên 35%. Chủ tịch của Standish Group, Jim Johnson, cho rằng sự
gia tăng này là do ba yếu tố: quản lý dự án tốt hơn, cơ sở hạ tầng Web mới nổi và (một
lần nữa) sự phát triển lặp đi lặp lại [Rubenstein, 2007].

Chỉ trong trường hợp bạn muốn biếtHộp 2.2

Thuật ngữSỰ HỖN LOẠNlà một từ viết tắt. Vì một số lý do không rõ, Nhóm Standish giữ
bí mật từ viết tắt. Họ tuyên bố [Standish, 2003]:

Chỉ một vài người ở The Standish Group và bất kỳ ai trong số 360 người đã nhận và
đã cứu những chiếc áo phông chúng tôi phát sau khi họ hoàn thành cuộc khảo sát đầu tiên vào năm 1994, biết những gì
Chữ CHAOS tượng trưng.

HÌNH 2.7
Kết quả của
Báo cáo CHAOS của Standish 34% 51% 15% 28% 49% 23%
Group từ năm 1994 đến năm 2006.
2006 2004 2002 2000 1998 0% 20% 40% 60% 80% 100%

26% 46% 28% Hoàn thành đúng thời hạn và

trong ngân sách
1996 1994 Trễ, vượt ngân sách hoặc thiếu
tính năng
27% 33% 40%
Đã hủy trước khi hoàn thành
35% 46% 19% 29% 53% 18%

16% 53% 31%

2.8 Quản lý việc lặp lại và tăng dần

Thoạt nhìn, mô hình lặp và tăng dần của Hình 2.4 và 2.5 trông hoàn toàn hỗn loạn. Thay
vì tiến trình có trật tự từ yêu cầu đến triển khai mô hình thác nước ( Hình 2.3 ), có vẻ như
các nhà phát triển làm bất cứ điều gì họ thích, có thể là viết mã vào buổi sáng, một hoặc
hai giờ thiết kế sau bữa trưa và sau đó là nửa giờ chỉ định trước khi về nhà. Đó
làkhôngtrường hợp. Ngược lại, mô hình lặp và tăng dần cũng được tổ chức giống như mô
hình thác nước, bởi vì như đã chỉ ra trước đó, việc phát triển một sản phẩm phần mềm
bằng mô hình lặp và tăng dần không gì khác hơn là phát triển một loạt các sản phẩm phần
mềm nhỏ hơn. , tất cả đều sử dụng mô hình thác nước.
52Phần AKhái niệm công nghệ phần mềm

Chi tiết hơn, như trong Hình 2.3, việc phát triển một sản phẩm phần mềm bằng mô hình
thác nước có nghĩa là thực hiện liên tục các giai đoạn yêu cầu, phân tích, thiết kế và triển
khai (theo thứ tự đó) trên toàn bộ sản phẩm phần mềm. Nếu gặp sự cố, thực hiện theo các
vòng phản hồi trong Hình 2.3 (mũi tên nét đứt); nghĩa là việc lặp lại (bảo trì) được thực
hiện. Tuy nhiên, nếu cùng một sản phẩm phần mềm được phát triển
Được vận hành bằng cách sử dụng mô hình lặp và tăng dần, sản phẩm phần mềm được coi
là một tập hợp các phần tăng dần. Đối với mỗi lần tăng dần, các giai đoạn yêu cầu, phân
 tích, thiết kế và triển khai (theo thứ tự đó) được thực hiện lặp đi lặp lạitrên mức tăng
đócho đến khi rõ ràng là không cần lặp lại nữa. Nói cách khác, toàn bộ dự án được chia
thành một loạt các dự án nhỏ về thác nước. Trong mỗi dự án nhỏ, việc lặp lại được thực
hiện khi cần thiết, như trong Hình 2.5. Vì vậy, lý do đoạn trước
đồ thị cho biết rằng mô hình lặp và tăng dần được tổ chức giống như mô hình thác nước vì
mô hình lặp và tăng dầnlàmô hình thác nước, được áp dụng lần lượt.

2.9 Các mô hình vòng đời khác

Bây giờ chúng ta xem xét một số mô hình vòng đời khác, bao gồm mô hình xoắn ốc và
mô hình đồng bộ hóa và ổn định. Chúng ta bắt đầu với mô hình code-and-fi x khét tiếng.

2.9.1Mô hình vòng đời viết mã và sửa lỗi

Thật không may là có quá nhiều sản phẩm được phát triển bằng cách sử dụng cái có thể
gọi làmô hình vòng đời mã hóa và sửa lỗi. Sản phẩm được triển khai mà không có
yêu cầu hoặc thông số kỹ thuật hoặc bất kỳ nỗ lực thiết kế nào. Thay vào đó, các nhà phát
triển chỉ cần ghép mã lại với nhau và làm lại nó nhiều lần nếu cần để làm hài lòng khách
hàng. Cách tiếp cận này được thể hiện trong Hình 2.8, hiển thị rõ ràng sự thiếu vắng các
yêu cầu, thông số kỹ thuật và thiết kế. Mặc dù cách tiếp cận này có thể hoạt động tốt trên
các bài tập lập trình ngắn dài 100 hoặc 200 dòng, nhưng mô hình code-and-fi x hoàn toàn
không đạt yêu cầu đối với các sản phẩm có kích thước hợp lý. Hình 1.6 cho thấy chi phí
thay đổi một sản phẩm phần mềm là tương đối nhỏ nếu
khách hàng hài lòng

HÌNH 2.8Mô hình vòng đời mã và sửa

lỗi. Bưu phẩm đã được giao
Thực hiện các BẢO TRÌ
phiên bản đầu tiên

Sự nghỉ hưuBảo trì phát triển

Sửa đổi cho đến khi

chương 2Mô hình vòng đời phần mềm53

thay đổi được thực hiện trong các giai đoạn yêu cầu, phân tích hoặc thiết kế nhưng sẽ trở
nên lớn đến mức không thể chấp nhận được nếu thay đổi được thực hiện sau khi sản phẩm
đã được mã hóa hoặc tệ hơn là nếu nó đã được chuyển giao và cài đặt trên máy tính của
khách hàng. Do đó, chi phí của phương pháp viết mã và sửa chữa thực sự lớn hơn nhiều
so với chi phí của một sản phẩm được thiết kế tỉ mỉ và được xác định rõ ràng. Ngoài ra,
việc bảo trì một sản phẩm có thể cực kỳ khó khăn nếu không có tài liệu đặc tả hoặc thiết
kế và khả năng xảy ra lỗi hồi quy sẽ lớn hơn đáng kể. Thay vì cách tiếp cận code-and-fi x,
điều cần thiết là trước khi phát triển
bắt đầu hình thành một sản phẩm, một mô hình vòng đời thích hợp sẽ được lựa chọn.
Đáng tiếc là có quá nhiều dự án sử dụng mô hình code-and-fi x. Vấn đề đặc biệt nghiêm
trọng ở những tổ chức chỉ đo lường tiến độ dựa trên dòng mã, vì vậy các thành viên của
nhóm phát triển phần mềm bị áp lực phải tạo ra càng nhiều dòng mã càng tốt, bắt đầu từ
Ngày đầu tiên của dự án. Mô hình code-and-fi x là cách dễ nhất để phát triển phần
mềm—và cho đến nay là cách tồi tệ nhất.
Một phiên bản đơn giản hóa của mô hình thác nước đã được trình bày ở Phần 2.2. Bây
giờ chúng ta xem xét mô hình đó một cách chi tiết hơn.

2.9.2Mô hình vòng đời thác nước

 Mô hình vòng đời thác nước lần đầu tiên được đưa ra bởi Royce [1970]. Hình 2.9 cho
thấy các vòng phản hồi để bảo trì trong khi sản phẩm đang được phát triển, như được phản
ánh trong Hình 2.3, mô hình thác nước được đơn giản hóa. Hình 2.9 cũng cho thấy các
vòng phản hồi để bảo trì sau giao hàng.
Một điểm quan trọng liên quan đến mô hình thác nước là không có giai đoạn nào được
hoàn thành cho đến khi tài liệu cho giai đoạn đó được hoàn thành và các sản phẩm của
giai đoạn đó đã được nhóm đảm bảo chất lượng phần mềm (SQA) phê duyệt. Điều này
chuyển thành những sửa đổi; nếu các sản phẩm của giai đoạn trước phải thay đổi do hậu
quả của việc tuân theo

HÌNH 2.9đầy đủ
mô hình vòng đời thác
nước

Yêu cầu
Thiết kế
Đã thay đổi
yêu cầu
Phân tích
Thực hiện

Bưu phẩm đã được giao

BẢO TRÌ

Sự nghỉ hưu

Bảo trì phát triển

54Phần AKhái niệm công nghệ phần mềm

một vòng phản hồi, giai đoạn trước đó chỉ được coi là hoàn thành khi tài liệu về giai đoạn
đó đã được sửa đổi và các sửa đổi đó đã được nhóm SQA kiểm tra. Cố hữu trong mọi giai
đoạn của mô hình thác nước là thử nghiệm. Kiểm thử không phải là một giai đoạn riêng
biệt chỉ được thực hiện sau khi sản phẩm đã được xây dựng, cũng không phải chỉ được
thực hiện vào cuối mỗi giai đoạn. Thay vào đó, như đã nêu trong Phần 1.7, việc kiểm tra
nên tiến hành
dần dần trong suốt tiến trình phần mềm. Đặc biệt, trong quá trình bảo trì, cần phải đảm
bảo không chỉ phiên bản sửa đổi của sản phẩm vẫn thực hiện những gì phiên bản trước đã
làm—và vẫn thực hiện chính xác (kiểm tra hồi quy)—mà còn đáp ứng mọi yêu cầu mới
được đặt ra. bởi khách hàng.
Mô hình thác nước có nhiều điểm mạnh, bao gồm cách tiếp cận có tính kỷ luật bắt buộc -
quy định rằng tài liệu phải được cung cấp ở mỗi giai đoạn và yêu cầu rằng tất cả các sản
phẩm của từng giai đoạn (bao gồm cả tài liệu) phải được SQA kiểm tra tỉ mỉ. Tuy nhiên,
thực tế là mô hình thác nước dựa trên tài liệu cũng có thể là một điểm yếu. Để thấy điều
này, hãy xem xét hai tình huống có phần kỳ lạ sau đây.
Đầu tiên, Joe và Jane Johnson quyết định xây một ngôi nhà. Họ tham khảo ý kiến ​của một
kiến ​trúc sư. Thay vì cho họ xem các bản phác thảo, sơ đồ và có lẽ là một mô hình tỷ lệ,
kiến ​trúc sư đưa cho họ một tài liệu đánh máy dài 20 trang mô tả ngôi nhà bằng những
thuật ngữ kỹ thuật cao. Mặc dù cả Joe và Jane đều không có kinh nghiệm kiến ​trúc trước
đó và hầu như không hiểu tài liệu nhưng họ vẫn nhiệt tình ký tên và nói: “Hãy tiếp tục,
xây nhà!”
Một tình huống khác như sau: Mark Marberry mua bộ vest của mình bằng cách đặt hàng
qua thư. Thay vì gửi cho anh ấy những bức ảnh về bộ vest của họ và các mẫu vải có sẵn,
công ty gửi cho Mark một bản mô tả bằng văn bản về đường cắt và vải của sản phẩm của
họ. Sau đó, Mark đặt mua một bộ đồ chỉ dựa trên mô tả bằng văn bản.
Hai kịch bản trước rất khó xảy ra. Tuy nhiên, chúng mô tả chính xác cách phần mềm
thường được xây dựng bằng mô hình thác nước. Quá trình bắt đầu với các thông số kỹ
thuật. Nhìn chung, các tài liệu đặc tả dài, chi tiết và khá nhàm chán khi đọc. Khách hàng
thường thiếu kinh nghiệm trong việc đọc các đặc tả phần mềm, và khó khăn này còn tăng
thêm bởi thực tế là các tài liệu đặc tả thường ở dạng văn bản.
mười theo một phong cách mà khách hàng không quen thuộc. Khó khăn thậm chí còn tệ
hơn khi các đặc tả được viết bằng ngôn ngữ đặc tả hình thức như Z [Spivey, 1992] (Phần
12.9). Tuy nhiên, khách hàng vẫn tiếp tục ký vào tài liệu đặc tả, cho dù đã hiểu đúng hay
chưa. Theo nhiều cách, có rất ít sự khác biệt giữa việc Joe và Jane Johnson ký hợp đồng
xây dựng một ngôi nhà từ một bản mô tả bằng văn bản mà họ chỉ hiểu một phần và việc
khách hàng phê duyệt một sản phẩm phần mềm được mô tả dưới dạng một tài liệu đặc tả
mà họ chỉ hiểu một phần.
Mark Marberry và những bộ quần áo đặt hàng qua thư của anh ấy có vẻ cực kỳ kỳ quái,
nhưng đó chính xác là những gì xảy ra khi mô hình thác nước được sử dụng trong phát
triển phần mềm. Lần đầu tiên khách hàng nhìn thấy một sản phẩm đang hoạt động chỉ là
sau khi toàn bộ sản phẩm đã được mã hóa. Chẳng có gì đáng ngạc nhiên khi các nhà phát
triển phần mềm lại sống trong nỗi sợ hãi trước câu nói: “Tôi biết đây là điều tôi đã yêu
cầu, nhưng nó không thực sự là điều tôi muốn”.
Điều gì đã xảy ra? Có sự khác biệt đáng kể giữa cách khách hàng hiểu về sản phẩm được
mô tả trong tài liệu mô tả và sản phẩm thực tế. Các thông số kỹ thuật chỉ tồn tại trên giấy
tờ; do đó khách hàng không thể thực sự hiểu được bản thân sản phẩm sẽ như thế nào. Mô
hình thác nước, tùy thuộc vào cách nó thực hiện chủ yếu trên văn bản
chương 2Mô hình vòng đời phần mềm55

các thông số kỹ thuật có thể dẫn đến việc tạo ra các sản phẩm không đáp ứng được nhu
cầu thực sự của khách hàng.
Công bằng mà nói, cần phải chỉ ra rằng, giống như kiến ​trúc sư có thể giúp khách hàng
hiểu cái gì sẽ được xây dựng bằng cách cung cấp các mô hình tỷ lệ, bản phác thảo và kế
hoạch, thì kỹ sư phần mềm cũng có thể sử dụng các kỹ thuật đồ họa, chẳng hạn như sơ đồ
luồng dữ liệu (Phần 12.3) hoặc sơ đồ UML ( Chương 17 ) để giao tiếp với khách hàng.
Vấn đề là những công cụ hỗ trợ bằng đồ họa này không mô tả được sản phẩm hoàn thiện
sẽ hoạt động như thế nào. Ví dụ, có một sự khác biệt đáng kể
sự liên hệ giữa sơ đồ (mô tả sơ đồ của sản phẩm) và bản thân sản phẩm đang hoạt động.
Trong cuốn sách này, hai giải pháp được đưa ra để giải quyết vấn đề mà tài liệu đặc tả
thường không mô tả sản phẩm theo cách giúp khách hàng xác định xem sản phẩm được đề
xuất có đáp ứng được nhu cầu của mình hay không. Giải pháp hướng đối tượng được mô
tả trong Chương 11 và 13. Giải pháp cổ điển là mô hình tạo mẫu nhanh, được mô tả trong
Phần 2.9.3.

2.9.3Mô hình vòng đời tạo nguyên mẫu nhanh

MỘTnguyên mẫu nhanhlà một mô hình hoạt động có chức năng tương đương với
một tập hợp con của sản phẩm. Ví dụ: nếu sản phẩm mục tiêu xử lý các tài khoản phải trả,
tài khoản phải thu và lưu kho thì nguyên mẫu nhanh có thể bao gồm một sản phẩm thực
hiện xử lý màn hình để thu thập dữ liệu và in báo cáo nhưng không cập nhật tệp hoặc lỗi.
sự điều khiển. Một nguyên mẫu nhanh cho sản phẩm mục tiêu nhằm xác định nồng độ
enzyme trong dung dịch có thể thực hiện tính toán và hiển thị câu trả lời nhưng không
thực hiện bất kỳ xác nhận hoặc kiểm tra tính hợp lý nào của dữ liệu đầu vào.
 Bước đầu tiên trongmô hình vòng đời tạo mẫu nhanhđược mô tả trong Hình 2.10 là
xây dựng một nguyên mẫu nhanh và để khách hàng cũng như những người dùng tương lai
tương tác và thử nghiệm với nguyên mẫu nhanh. Một khi khách hàng hài lòng rằng
nguyên mẫu nhanh chóng thực sự thực hiện được hầu hết

HÌNH 2.10
Sự nhanh chóng
cuộc sống nguyên mẫu
mô hình chu kỳ
Thiết kế
Nhanh
nguyên mẫu
Đã thay đổi
Phân tích yêu cầu
Thực hiện

Bưu phẩm đã được giao

BẢO TRÌ

Sự nghỉ hưu

Bảo trì phát triển

56Phần AKhái niệm công nghệ phần mềm

những gì được yêu cầu, các nhà phát triển có thể soạn thảo tài liệu đặc tả với sự đảm bảo
nào đó rằng sản phẩm đáp ứng được nhu cầu thực sự của khách hàng.
Sau khi tạo ra nguyên mẫu nhanh, quy trình phần mềm tiếp tục như trong Hình 2.10.
Điểm mạnh chính của mô hình tạo mẫu nhanh là sự phát triển của sản phẩm về cơ bản là
tuyến tính, tiến hành từ nguyên mẫu nhanh đến sản phẩm được giao; các vòng phản hồi
của mô hình thác nước ( Hình 2.9 ) ít có khả năng cần thiết hơn trong mô hình tạo mẫu
nhanh. Có một số lý do cho việc này. Đầu tiên, các thành viên của nhóm phát triển sử
dụng nguyên mẫu nhanh để xây dựng tài liệu đặc tả. Bởi vì nguyên mẫu hoạt động nhanh
đã được xác nhận thông qua tương tác với khách hàng, nên có lý khi hy vọng rằng tài liệu
đặc tả kết quả sẽ chính xác. Thứ hai, hãy xem xét thiết kế. Mặc dù nguyên mẫu nhanh
chóng đã được lắp ráp một cách vội vã (hoàn toàn chính xác), nhóm thiết kế vẫn có thể
hiểu rõ hơn về nó - tệ nhất là nó sẽ thuộc loại "làm thế nào để không làm điều đó". Một
lần nữa, các vòng phản hồi của mô hình thác nước ít có khả năng cần thiết ở đây.
Việc thực hiện tiếp theo. Trong mô hình thác nước, việc triển khai thiết kế đôi khi dẫn
đến phát hiện ra lỗi thiết kế. Trong mô hình tạo mẫu nhanh, thực tế là phiên bản hoạt động
sơ bộ của sản phẩm phần mềm đã được xây dựng có xu hướng làm giảm nhu cầu sửa chữa
thiết kế trong hoặc sau khi triển khai. Nguyên mẫu đã cung cấp một số hiểu biết sâu sắc
cho nhóm thiết kế, mặc dù nó có thể chỉ phản ánh một phần chức năng của sản phẩm mục
tiêu hoàn chỉnh.
Sau khi sản phẩm đã được khách hàng chấp nhận và lắp đặt, quá trình thuê chính sau khi
giao hàng sẽ bắt đầu. Tùy thuộc vào nhiệm vụ bảo trì cụ thể phải được thực hiện, chu trình
được thực hiện lại ở giai đoạn yêu cầu, phân tích, thiết kế hoặc triển khai.
 Một khía cạnh thiết yếu của một nguyên mẫu nhanh chóng được thể hiện trong từnhanh.
Các nhà phát triển nên nỗ lực xây dựng nguyên mẫu nhanh nhất có thể để tăng tốc quá
trình phát triển phần mềm. Suy cho cùng, mục đích sử dụng duy nhất của nguyên mẫu
nhanh là xác định nhu cầu thực sự của khách hàng là gì; một khi điều này đã được xác
định, việc triển khai nguyên mẫu nhanh chóng sẽ bị loại bỏ nhưng các bài học kinh
nghiệm sẽ được giữ lại và sử dụng trong các giai đoạn phát triển tiếp theo. Vì lý do này,
cấu trúc bên trong của nguyên mẫu nhanh là không phù hợp. Điều quan trọng là nguyên
mẫu phải được xây dựng nhanh chóng và được sửa đổi nhanh chóng để phản ánh nhu cầu
của khách hàng. Vì vậy, tốc độ là điều cốt yếu.
Tạo nguyên mẫu nhanh sẽ được thảo luận chi tiết hơn trong Chương 11.

2.9.4Mô hình vòng đời nguồn mở

Hầu như đều thành côngphần mềm mã nguồn mởdự án trải qua hai giai đoạn không
chính thức. Đầu tiên, một cá nhân có ý tưởng về một chương trình, chẳng hạn như hệ điều
hành (Linux), trình duyệt Net (Firefox) hoặc máy chủ Web (Apache). Anh ta hoặc cô ta
xây dựng phiên bản đầu tiên, sau đó sẽ được cung cấp để phân phối miễn phí cho bất kỳ ai
muốn có một bản sao; ngày nay, việc này được thực hiện thông qua Internet, tại các trang
web nhưNguồnForge.mạng lướiVàFreshMeat.net. Nếu ai đó tải xuống bản sao của
phiên bản đầu tiên và cho rằng chương trình đáp ứng được nhu cầu thì người đó sẽ bắt đầu
sử dụng chương trình đó.
Nếu có đủ sự quan tâm đến chương trình, dự án sẽ chuyển dần sang giai đoạn hai không
chính thức. Người dùng trở thành người đồng phát triển, trong đó một số người dùng báo
cáo lỗi và những người khác đề xuất cách khắc phục những lỗi đó. Một số người dùng đưa
ra ý tưởng để mở rộng chương trình,
hoàn thiện và thích ứng
bảo trì sau giao hàng
chương 2Mô hình vòng đời phần mềm57
HÌNH 2.11Khai mạc
mô hình vòng đời nguồn.
Thực hiện các
phiên bản đầu tiên
Thực hiện khắc phục,

Sự nghỉ hưuPhát triển

BẢO TRÌ

và những người khác thực hiện những ý tưởng đó. Khi chương trình mở rộng về chức
năng, nhưng những người dùng khác sẽ chuyển chương trình để chương trình có thể chạy
trên các tổ hợp hệ điều hành/phần cứng bổ sung. Một khía cạnh quan trọng là các cá nhân
thường làm việc trong một dự án nguồn mở trong thời gian rảnh rỗi trên cơ sở tự nguyện;
họ không được trả tiền để tham gia.
Bây giờ hãy xem xét kỹ hơn ba hoạt động của giai đoạn không chính thức thứ hai:
 1. Báo cáo và sửa lỗi là bảo trì khắc phục.
2. Thêm chức năng bổ sung là bảo trì hoàn hảo.
3. Chuyển chương trình sang môi trường mới là bảo trì thích ứng.
Nói cách khác, giai đoạn không chính thức thứ hai của mô hình vòng đời nguồn mở chỉ
bao gồm việc bảo trì sau giao hàng, như trong Hình 2.11. Trên thực tế, thuật ngữngười
đồng phát triểntrong đoạn thứ hai của phần này nên làngười đồng bảo trì. Có một số điểm
khác biệt chính giữa mô hình vòng đời phần mềm nguồn đóng và nguồn mở:
•Phần mềm nguồn đóng được duy trì và kiểm thử bởi các nhóm nhân viên của tổ chức sở
hữu phần mềm. Người dùng đôi khi gửi báo cáo lỗi. Tuy nhiên, những điều này bị hạn
chế ởbáo cáo thất bại(báo cáo về hành vi không đúng được quan sát); người dùng
không có quyền truy cập vào mã nguồn, vì vậy họ không thể gửibáo cáo lỗi(báo cáo
mô tả mã nguồn sai ở đâu và cách sửa).
Ngược lại, phần mềm nguồn mở thường được duy trì bởi các tình nguyện viên không
được trả lương. Người dùng được khuyến khích gửi báo cáo lỗi. Mặc dù tất cả người
dùng đều có quyền truy cập vào mã nguồn nhưng chỉ một thiểu số mới có khuynh
hướng và thời gian cũng như các kỹ năng cần thiết để đọc mã nguồn và gửi báo cáo lỗi
(“sửa lỗi”); do đó hầu hết các báo cáo lỗi đều là báo cáo lỗi. Nhìn chung có mộtnhóm
chủ chốtnhững người bảo trì tận tâm chịu trách nhiệm quản lý dự án nguồn mở. Một
số thành viên củanhóm ngoại vi, nghĩa là, những người dùng không phải là thành
viên của nhóm cốt lõi, thỉnh thoảng chọn gửi báo cáo lỗi. Các thành viên của nhóm
nòng cốt có trách nhiệm đảm bảo rằng những khiếm khuyết này được sửa chữa. Chi
tiết hơn, khi một báo cáo lỗi được gửi đi, một thành viên nhóm cốt lõi sẽ kiểm tra xem
bản sửa lỗi có thực sự giải quyết được vấn đề hay không và sửa đổi mã nguồn một cách
thích hợp. Khi báo cáo lỗi được gửi, một thành viên của nhóm nòng cốt sẽ tự mình xác
định cách khắc phục hoặc giao nhiệm vụ đó cho một tình nguyện viên khác,
58Phần AKhái niệm công nghệ phần mềm

thường là thành viên của nhóm ngoại vi mong muốn được tham gia nhiều hơn vào dự
án nguồn mở. Một lần nữa, quyền cài đặt bản sửa lỗi trong phần mềm bị hạn chế đối
với các thành viên của nhóm cốt lõi.
•Các phiên bản mới của phần mềm nguồn đóng thường được phát hành khoảng một năm
một lần. Mỗi phiên bản mới đều được nhóm đảm bảo chất lượng phần mềm kiểm tra
kỹ lưỡng trước khi phát hành; một loạt các trường hợp thử nghiệm được chạy.
Ngược lại, một châm ngôn của phong trào nguồn mở là “Phát hành sớm. Phát hành
thường xuyên” [Raymond, 2000]. Nghĩa là, nhóm cốt lõi sẽ phát hành phiên bản mới
của sản phẩm nguồn mở ngay khi nó sẵn sàng, có thể là một tháng hoặc thậm chí chỉ
một ngày sau khi phiên bản trước đó được phát hành. Phiên bản mới này được phát
hành sau quá trình thử nghiệm tối thiểu; người ta cho rằng thử nghiệm rộng rãi hơn sẽ
được thực hiện bởi các thành viên của nhóm ngoại vi. Một phiên bản mới có thể được
hàng trăm nghìn người dùng cài đặt trong vòng một hoặc hai ngày sau khi phát hành.
Những người dùng này không chạy các trường hợp thử nghiệm như vậy. Tuy nhiên,
trong quá trình sử dụng phiên bản mới trên máy tính của mình, họ gặp phải lỗi và họ
báo cáo qua e-mail. Bằng cách này, các lỗi trong phiên bản mới (cũng như các lỗi sâu
hơn ở các phiên bản trước) sẽ được phát hiện và sửa chữa.

So sánh các Hình 2.8, 2.10 và 2.11, chúng ta thấy rằng mô hình vòng đời nguồn mở có
các đặc điểm chung với cả mô hình code-and-fi x và mô hình tạo nguyên mẫu nhanh.
Trong cả ba mô hình vòng đời, một phiên bản hoạt động ban đầu đều được tạo ra. Trong
trường hợp mô hình tạo mẫu nhanh, phiên bản ban đầu này bị loại bỏ và sản phẩm mục
tiêu sau đó được xác định và thiết kế trước khi được mã hóa. Trong cả code-and-fi x và
open
mô hình vòng đời nguồn, phiên bản ban đầu sẽ được làm lại cho đến khi nó trở thành sản
phẩm mục tiêu. Theo đó, trong một dự án nguồn mở, nhìn chung không có thông số kỹ
thuật hoặc thiết kế nào cả.
Ghi nhớ tầm quan trọng to lớn của việc có các thông số kỹ thuật và thiết kế, làm thế nào
mà một số dự án nguồn mở lại thành công đến vậy? Trong thế giới nguồn đóng, một số
chuyên gia phần mềm có kỹ năng cao hơn và một số có kỹ năng kém hơn (xem Phần 9.2).
Thách thức của việc sản xuất phần mềm nguồn mở đã thu hút một số chuyên gia phần
mềm. Nói cách khác, một dự án nguồn mở có thể thành công, bất chấp việc thiếu thông số
kỹ thuật hoặc thiết kế, nếu kỹ năng của các cá nhân làm việc trong dự án đó quá xuất sắc
đến mức họ có thể hoạt động hiệu quả mà không cần thông số kỹ thuật hoặc thiết kế.
Mô hình vòng đời nguồn mở bị hạn chế về khả năng ứng dụng. Một mặt, mô hình nguồn
mở đã được sử dụng cực kỳ thành công cho một số dự án phần mềm cơ sở hạ tầng nhất
định, chẳng hạn như hệ điều hành (Linux, OpenBSD, Mach, Darwin), trình duyệt Web
(Firefox, Netscape), trình biên dịch (gcc), Máy chủ web (Apache) hoặc hệ thống quản lý
cơ sở dữ liệu (MySQL). Mặt khác, thật khó để hình dung việc phát triển nguồn mở của
một sản phẩm phần mềm chỉ được sử dụng trong một tổ chức thương mại. Chìa khóa để
phát triển phần mềm nguồn mở là các thành viên của cả nhóm cốt lõi và nhóm ngoại vi
đều là người dùng phần mềm đang được phát triển. Do đó, mô hình vòng đời nguồn mở
không thể áp dụng được trừ khi sản phẩm mục tiêu được nhiều người dùng xem là hữu ích
đối với họ.
Tại thời điểm viết bài, có khoảng 350.000 dự án nguồn mở tạiNguồnForge. mạng
lướiVàFreshMeat.net. Khoảng một nửa trong số họ thậm chí chưa bao giờ thu hút được
một nhóm làm việc cho dự án. Trong số những nơi công việc đã bắt đầu, ưu thế áp đảo
chưa bao giờ được hoàn thành và khó có thể tiến xa hơn nữa. Nhưng khi mô hình nguồn
mở
chương 2Mô hình vòng đời phần mềm59

đã có hiệu quả, đôi khi nó còn thành công ngoài sức tưởng tượng. Các sản phẩm nguồn
mở được liệt kê trong ngoặc đơn ở đoạn trước được sử dụng rộng rãi; hầu hết chúng được
sử dụng thường xuyên bởi hàng triệu người dùng.
Những giải thích cho sự thành công của mô hình vòng đời nguồn mở được trình bày
trong Chương 4 trong bối cảnh các khía cạnh tổ chức nhóm của các dự án phần mềm
nguồn mở.

2.9.5Quy trình linh hoạt

Lập trình cực đỉnh[Beck, 2000] là một cách tiếp cận mới gây nhiều tranh cãi trong
phát triển phần mềm dựa trên mô hình lặp và tăng dần. Bước đầu tiên là nhóm phát triển
phần mềm xác định các tính năng khác nhau (những câu chuyện) khách hàng muốn
sản phẩm được hỗ trợ. Đối với mỗi tính năng như vậy, nhóm sẽ thông báo cho khách hàng
sẽ mất bao lâu để triển khai tính năng đó và chi phí sẽ là bao nhiêu. Bước đầu tiên này
tương ứng với các yêu cầu và quy trình phân tích của mô hình lặp và tăng dần ( Hình 2.4 ).
Khách hàng chọn các tính năng sẽ được đưa vào mỗi bản dựng kế tiếp bằng cách sử dụng
phân tích chi phí-lợi ích (Phần 5.2), tức là trên cơ sở thời lượng và ước tính chi phí do
nhóm phát triển cung cấp cũng như những lợi ích tiềm năng của đặc trưng cho doanh
nghiệp của mình. Việc xây dựng đề xuất được chia thành các phần nhỏ hơn được gọi
lànhiệm vụ. Đầu tiên, một lập trình viên sẽ đưa ra các ca kiểm thử cho một nhiệm vụ;
điều này được gọi làhướng phát triển thử nghiệm(TDD). Hai lập trình viên làm việc
cùng nhau trên một máy tính (lập trình cặp) [Williams, Kessler, Cunningham, và
Jeffries, 2000], thực hiện nhiệm vụ và đảm bảo rằng tất cả các trường hợp kiểm thử đều
hoạt động chính xác. Hai lập trình viên thay đổi
gõ nate cứ sau 15 hoặc 20 phút; lập trình viên không gõ cẩn thận sẽ kiểm tra mã trong khi
đối tác của họ nhập nó. Nhiệm vụ sau đó được tích hợp vào phiên bản hiện tại của sản
phẩm. Lý tưởng nhất là việc triển khai và tích hợp một nhiệm vụ sẽ không mất quá vài
giờ. Nói chung, một số cặp sẽ thực hiện các nhiệm vụ song song, do đó việc tích hợp về
cơ bản là liên tục. Các thành viên trong nhóm thay đổi phần mã hóa
ners hàng ngày, nếu có thể; học hỏi từ các thành viên khác trong nhóm sẽ nâng cao trình
độ kỹ năng của mọi người. Các trường hợp kiểm thử TDD được sử dụng cho nhiệm vụ
này sẽ được giữ lại và sử dụng trong tất cả các thử nghiệm tích hợp tiếp theo.
Một số hạn chế của lập trình cặp đã được quan sát thấy trong thực tế [Drobka, Noftz và
Raghu, 2004]. Ví dụ, lập trình theo cặp yêu cầu khối thời gian lớn không bị gián đoạn và
các chuyên gia phần mềm có thể gặp khó khăn trong việc tìm ra khối thời gian từ 3 đến 4
giờ. Ngoài ra, lập trình theo cặp không phải lúc nào cũng hiệu quả với những cá nhân nhút
nhát hoặc hống hách.
als, hoặc với hai lập trình viên thiếu kinh nghiệm.
Một số tính năng của lập trình cực đoan (XP) hơi khác so với cách phát triển phần mềm
thường:
•Các máy tính của nhóm XP được bố trí ở trung tâm của một căn phòng lớn có các ngăn
nhỏ xếp dọc.
•Đại diện khách hàng luôn làm việc với nhóm XP.
•Không cá nhân nào được phép làm thêm giờ trong hai tuần liên tiếp.
•Không có chuyên môn. Thay vào đó, tất cả thành viên của nhóm XP đều làm việc dựa
trên các yêu cầu, phân tích, thiết kế, viết mã và thử nghiệm.