Bài giảng kỉ nghệ phần mềm

Hà Nội 8/2002

Nhập môn
Kĩ nghệ phần mềm

Biên soạn
Ngô Trung Việt
Nguyễn Kim Ánh

499

500


499

500


2.1.7 Mô hình phát triển tương tranh . . . . . . . . . .

63

2.2 Phát triển dựa theo cấu phần . . . . . . . . . . . . . . . . . . . . 66
2.3 Kĩ thuật thế hệ thứ tư . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Mục lục
Giới thiệu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

Phần 1 Tổng quan về kĩ nghệ phần mềm. . . . . . . . .
1.1 Khoa học, kĩ nghệ và Thủ công. . . . . . . . . . . . . . .
1.2 Kĩ nghệ phần mềm . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Tiến hoá phần mềm . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Qui trình phần mềm . . . . . . . . . . . . . . . . . . . . . . . . .
1.5 Về cách giải quyết vấn đề . . . . . . . . . . . . . . . . . . . . .
1.5.1 Từ lập trình đi lên… . . . . . . . . . . . . . . . . .
1.5.2 Vấn đề, giải pháp và giải quyết vấn đề . . .
1.5.3 Vòng đời . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.4 Chu kì và pha phát triển . . . . . . . . . . . . . . .
1.5.5 Chu kì và pha lặp . . . . . . . . . . . . . . . . . . . .

11
11
16
20
23
24
24
29
36
41
43

Phần 2 Các mô hình phát triển phần mềm . . . . . . . . .
2.1 Mô hình tiến trình phần mềm . . . . . . . . . . . . . . . . . . .
2.1.1 Mô hình tuần tự tuyến tính . . . . . . . . . . . . .
2.1.2 Mô hình làm bản mẫu . . . . . . . . . . . . . . . . .
2.1.3 Mô hình RAD . . . . . . . . . . . . . . . . . . . . . . .
2.1.4 Mô hình tiến trình phần mềm tiến hoá . . . .

2.1.5 Mô hình tăng dần . . . . . . . . . . . . . . . . . . . .
2.1.6 Mô hình xoáy ốc . . . . . . . . . . . . . . . . . . . .

46
46
48
52
54
57
58
60

Phần 3 Các khái niệm về quản lí dự án . . . . . . . . . . . . .
3.1 Phổ quản lí . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Con người . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2 Sản phẩm . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.3 Tiến trình . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.4 Dự án . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

74
75
75
76
77
77

3.2 Con người . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Người tham dự . . . . . . . . . . . . . . . . . . . . . . .
3.2.2 Người lãnh đạo tổ . . . . . . . . . . . . . . . . . . . . .
3.2.3 Tổ phần mềm . . . . . . . . . . . . . . . . . . . . . . . .

3.2.4 Vấn đề phối hợp và trao đổi . . . . . . . . . . . . .

78
81
82
83
91

3.3 Sản phẩm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
3.3.1 Phạm vi phần mềm . . . . . . . . . . . . . . . . . . . . 92
3.3.2 Phân tách vấn đề . . . . . . . . . . . . . . . . . . . . . . 93
3.4 Tiến trình . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
3.4.1 Trộn lẫn sản phẩm và tiến trình . . . . . . . . . . 94
3.4.2 Phân tách tiến trình . . . . . . . . . . . . . . . . . . . . 95

499

3.5 Dự án . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

96

Phần 4 Kĩ nghệ phần mềm truyền thống . . . . . . . . . . .
4.1 Kĩ nghệ hệ thống . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 Hệ thống dựa trên máy tính . . . . . . . . . . . . .

98
98
99

500

4.1.2 Hệ thống cấp bậc kĩ nghệ hệ thống. . . . . . . .
4.1.3 Kĩ nghệ tiến trình nghiệp vụ: Tổng quan . . .
4.1.4 Kĩ nghệ sản phẩm: tổng quan . . . . . . . . . . .
4.1.5 Kĩ nghệ yêu cầu . . . . . . . . . . . . . . . . . . . .
4.1.6 Mô hình hoá hệ thống . . . . . . . . . . . . . . . . .
4.1.7 Tóm tắt . . . . . . . . . . . . . . . . . . . . . . . . . . . .

102
107
112
114
123
124

4.2 Nền tảng của phân tích yêu cầu . . . . . . . . . . . . . . . . .
4.2.1 Phân tích yêu cầu . . . . . . . . . . . . . . . . . . . .
4.2.2 Lĩnh vực vấn đề . . . . . . . . . . . . . . . . . . . .
4.2.3 Kĩ thuật trao đổi . . . . . . . . . . . . . . . . . . . .
4.2.4 Nguyên lí phân tích . . . . . . . . . . . . . . . . . . . .
4.2.5 Làm bản mẫu phần mềm . . . . . . . . . . . . . . .
4.2.6 Đặc tả . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.7 Kiểm điểm đặc tả . . . . . . . . . . . . . . . . . . . .
4.2.8 Tóm tắt . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

126
127
132
134

136
140
146
155
158

4.3 Phương pháp luận phát triển truyền thống . . . . . . . . . .
4.3.1 Vai trò của tổ chức phát triển hệ thống . . . .
4.3.2 Mô hình phát triển hệ thống . . . . . . . . . . . . .
4.3.3 Vòng đời phần mềm . . . . . . . . . . . . . . . . . . . .

159
159
162
169

4.4 Phân tích yêu cầu và phương pháp thiết kế . . . . . . . . . 184
4.4.1 Phương pháp lập biểu đồ . . . . . . . . . . . . . . . . 184
4.4.2 Lập biểu đồ phân tích/thiết kế . . . . . . . . . . . . 188
4.4.3 Phương pháp thiết kế . . . . . . . . . . . . . . . . . . . .
195
4.5 Ngôn ngữ lập trình . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.1 Thuộc tính chương trình. . . . . . . . . . . . . . . .
4.5.2 Kiểu dữ liệu . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.3 Cấu trúc điều khiển . . . . . . . . . . . . . . . . . . . .
4.5.4 Phân tích cú pháp . . . . . . . . . . . . . . . . . . . . .

212
212
214

215
219
499

4.5.5 Phân loại về ngôn ngữ lập trình . . . . . . . . . .
4.5.6 Kiểu và đặc trưng của ngôn ngữ lập trình . .

226
233

4.6 Kĩ thuật lập trình . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.1 Mô thức lập trình . . . . . . . . . . . . . . . . . . . .
4.6.2 Phong cách lập trình . . . . . . . . . . . . . . . . . . .
4.6.3 Dùng bộ xử lí ngôn ngữ . . . . . . . . . . . . . . . .
4.6.4 Môi trường lập trình . . . . . . . . . . . . . . . . . . .

244
244
249
251
253

4.7 Kiểm thử . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
4.7.1 Tổng quan về kiểm thử . . . . . . . . . . . . . . . . . 255
4.7.2 Kiểm thử đơn vị . . . . . . . . . . . . . . . . . . . . . . 256
4.7.3 Kiểm thử tích hợp . . . . . . . . . . . . . . . . . . . . 257
4.7.4 Kiểm thử hệ thống . . . . . . . . . . . . . . . . . . . . 266
4.7.5 Các kiểm thử khác . . . . . . . . . . . . . . . . . . . . 268
4.7.6 Kế hoạch và nhiệm vụ kiểm thử
.........

269
4.7.7 Phương pháp kiểm điểm
.................
276
4.7.8 Thiết kế kiểm thử và phương pháp quản lí . . . 278
Phần 5 Kĩ nghệ phần mềm hướng sự vật . . . . . . . . . . . .
5.1 Giới thiệu về cách tiếp cận hướng sự vật . . . . . . . . . . .
5.1.1 Khủng hoảng phần mềm . . . . . . . . . . . . . . . .
5.1.2 Cách tiếp cận hướng sự vật . . . . . . . . . . . . . .
5.1.3 Làm tài liệu về các lớp . . . . . . . . . . . . . . . . .
5.1.4 Các hoạt động phân tích và thiết kế . . . . . . . .
5.1.5 Thiết kế cơ sở dữ liệu . . . . . . . . . . . . . . . . . . .
5.1.6 Thiết kế giao diện con người . . . . . . . . . . . . .
5.1.7 Tóm tắt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

282
282
282
291
306
307
312
314
318

5.2 Tổng quan về UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
5.2.1 Kiến trúc . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
500

5.2.2 Siêu mô hình . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.3 Góc nhìn kiến trúc và biểu đồ . . . . . . . . . . . .
5.2.4 Cơ chế . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.5 Vấn đề, giải pháp và giải quyết vấn đề . . . . .
5.2.6 Vấn đề và giải pháp . . . . . . . . . . . . . . . . . . . .
5.2.7 Giải quyết vấn đề . . . . . . . . . . . . . . . . . . . . . .
5.2.8 Chu kì lặp và pha . . . . . . . . . . . . . . . . . . . . . .
5.2.9 Chi tiết hơn về UML . . . . . . . . . . . . . . . . . . .
5.2.10 Tiến trình sử dụng UML . . . . . . . . . . . . . . . .

328
331
333
338
340
344
346
348
374

/nguồn phục vụ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
6.4.3 Thiết kế cho hệ thống khách/nguồn phục vụ . 445
6.5. Kĩ nghệ Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.1 Các thuộc tính của ứng dụng dựa trên Web . .
6.5.2 Một khuôn khổ cho kĩ nghệ Web . . . . . . . . .
6.5.3 Phát biểu/phân tích hệ thống dựa trên Web . .
6.5.4 Thiết kế ứng dụng dựa trên Web . . . . . . . . . .
6.5.5 Kiểm thử ứng dụng dựa trên Web . . . . . . . . .
6.5.6 Vấn đề quản lí . . . . . . . . . . . . . . . . . . . . . . . .

Phần 6 Các chủ đề nâng cao trong Kĩ nghệ phần mềm . 402
6. 1 Phương pháp hình thức . . . . . . . . . . . . . . . . . . . .
402
Kĩ thuật đặc tả hình thức . . . . . . . . . . . . . . . . . . . . 403
6.2 Kĩ nghệ phần mềm phòng sạch . . . . . . . . . . . . . . . . . .
6.2.1 Cách tiếp cận phòng sạch . . . . . . . . . . . . . . .
6.2.2 Đặc tả chức năng . . . . . . . . . . . . . . . . . . . .
6.2.3 Thiết kế phòng sạch . . . . . . . . . . . . . . . . . . . .
6.2.4 Kiểm thử phòng sạch . . . . . . . . . . . . . . . . . . .
6.2.5 Tóm tắt . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

407
408
410
414
414
416

6.3. Kĩ nghệ phần mềm dựa trên cấu phần . . . . . . . . . . . . .
6.3.1 Kĩ nghệ hệ thống dựa trên cấu phần . . . . . . .
6.3.2 Tiến trình CBSE. . . . . . . . . . . . . . . . . . . .
6.3.3 Kĩ nghệ miền . . . . . . . . . . . . . . . . . . . . . . . .
6.3.4 Phát triển dựa trên cấu phần
..........
6.3.5 Phân loại và tìm kiếm cấu phần . . . . . . . . . .
6.3.6 Tóm tắt . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

418
418
419

421
422
430
434

6.4. Kĩ nghệ phần mềm khách/ nguồnphục vụ . . . . . . . . . . 435
6.4.1 Cấu trúc của hệ thống khách/phục vụ . . . . . . 435
6.4.2 Kĩ nghệ phần mềm cho hệ thống khách
499

500

453
453
455
456
459
469
472


Giới thiệu
Kĩ nghệ phần mềm là vấn đề thời sự và hiện đại cho những
người quản lí và hành nghề CNTT cần hiểu và áp dụng vào trong
thực tế phát triển các sản phẩm CNTT. Kĩ nghệ phần mềm có thể
giúp cho con người có nhiều hiểu biết hơn, cung cấp những nền
tảng cần để xây dựng những sản phẩm và hệ thống chất lượng cao
trong thế kỉ thứ hai mươi mốt. Có thể nói kĩ nghệ phần mềm là lĩnh
vực tri thức và kinh nghiệm được hệ thống hoá để giúp cho mọi
người có thể làm việc theo cách có phối hợp, có bài bản, có kỉ luật

trong các hoạt động sáng tạo ra sản phẩm mang tính kĩ nghệ, công
nghiệp.
Sự phát triển của xã hội loài người đã đi từ nền sản xuất nông
nghiệp và tiểu thủ công qua sản xuất công nghiệp. Đặc trưng chính
của bước phát triển này là việc đưa vào cách làm việc công nghiệp,
tạo ra các dây chuyền sản xuất trong đó máy móc đóng vai trò
chính làm ra sản phẩm hàng loạt và đều nhau, cung cấp sản phẩm
theo qui mô lớn cho xã hội. Con người bị gắn vào các qui trình
công nghiệp và trở thành một bộ phận của nó.
Ngày nay chúng ta lại đang chứng kiến việc chuyển biến trong
nền kinh tế chuyển từ nền sản xuất công nghiệp sang nền sản xuất
thông tin và tri thức. Đặc trưng chính của bước phát triển mới này
là việc khôi phục trở lại vai trò sáng tạo trung tâm của con người
trong mọi hoạt động kinh tế và sản xuất. Khác với nền sản xuất
công nghiệp lấy máy móc làm động lực chính cho sản xuất, nền
sản xuất thông tin và tri thức lấy con người sáng tạo làm động lực
chính cho việc thay đổi kết cấu của các tiến trình sản xuất máy
móc, để từ đó tạo ra sức sản xuất với qui mô toàn cầu và một trình
độ tổ chức cao hơn.
499

Chúng ta đang đứng trước một đòi hỏi lớn lao là làm chuyển
đổi cách suy nghĩ và làm việc của mọi người để bước vào nền kinh
tế thông tin và tri thức, trong khi nền tảng công nghiệp còn chưa
được thiết lập vững chắc. Điều đó đưa tới việc cần nhanh chóng
tạo dựng tác phong kĩ nghệ, tác phong làm việc công nghiệp trong
phát triển nền công nghiệp CNTT nói riêng, trong cả nền kinh tế
nói chung. Do đó kĩ nghệ phần mềm trở thành một đòi hỏi không
thể thiếu trong tri thức cần trang bị cho lực lượng lao động mới.
Cuốn sách này được biên soạn với mục đích trình bày những

nét chính yếu nhất của kĩ nghệ phần mềm, nhằm giúp cho bạn đọc
có một con mắt tổng quan khi tiếp cận tới vấn đề này. Những vấn
đề có tính lí thuyết đã không được đề cập tới nhiều. Tuy nhiên một
tài liệu tóm lược toàn diện các vấn đề của kĩ nghệ phần mềm là cần
thiết cho những người mới làm quen với lĩnh vực này.
Tài liệu chính sử dụng để biên soạn cuốn sách này được rút ra
từ bài giảng trong khoá học Khởi động về kĩ nghệ phần mềm tiến
hành tại Khu công nghệ cao Hoà Lạc tháng 11/2001, một số tư liệu
trong tài liệu đào tạo về kĩ sư CNTT cơ bản của Nhật và cuốn sách
“Kĩ nghệ phần mềm: cách tiếp cận của người thực hành” của
Roger Pressman.
Chúng tôi hi vọng tài liệu này có thể cung cấp cho bạn đọc góc
nhìn bao quát về một lĩnh vực quan trọng đang cần được triển khai
rộng rãi. Việc biên soạn những vấn đề mới này không tránh khỏi có
nhiều thiếu sót và hạn chế, mong được các độc giả và đồng nghiệp
bổ sung đóng góp thêm.
Hà Nội tháng 8/2002

500


Phần 1
Tổng quan về kĩ nghệ
phần mềm

Công nghệ, được hiểu như một tập hợp các kĩ thuật dùng
trong một ngành nào đó, có một cơ sở khoa học thống nhất. Công
nghệ phần mềm được hiểu gồm nhiều loại công nghệ tạo ra phần
mềm khác nhau, mỗi công nghệ có thể có nhiều kĩ thuật làm phần
mềm khác nhau. Công nghệ thông tin (CNTT) vẫn được hiểu bao

gồm một số vấn đề của công nghệ điện tử, công nghệ máy tính,
công nghệ viễn thông, công nghệ phần mềm, công nghệ quản lí...
Một đặc điểm nữa của CNTT là việc các công nghệ đều dựa trên
các chuẩn và có những con người am hiểu những công nghệ đó sử
dụng.
Kĩ nghệ (engineering) nói tới một tập hợp các công nghệ được
bố trí theo một qui trình nhất định, được con người dùng các
phương pháp và thực hiện qua các công cụ để tạo ra những sản
phẩm nhất định.

1.1 Khoa học, kĩ nghệ và thủ công

Kĩ nghệ là việc sử dụng phối hợp các công nghệ cần thiết để
sản xuất ra các sản phẩm của một ngành nào đó (nguyên nghĩa từ
kĩ nghệ cơ khí, engine là một cái máy).

Các định nghĩa
Ba vấn đề cần được xem xét liên quan tới kiến thức nói chung
là: khoa học, công nghệ và kĩ nghệ.
Khoa học (science) là hệ thống các tri thức được con người
khám phá ra từ các tiến trình tự nhiên hay chính các hoạt động của
mình. Khoa học tập trung vào tìm hiểu các qui luật của thực tế,
nghiên cứu những khả năng mô phỏng các qui luật của thực tế để
từ đó nêu ra các nguyên tắc cho con người có thể chế tạo ra các
phương tiện thiết bị mới.
Công nghệ (technology) nói tới cách thức, phương pháp nào
đó do con người phát minh ra để làm một việc gì đó, cụ thể hay
trừu tượng. Công nghệ sử dụng các thành tựu của khoa học để tác
động vào thế giới vật chất và năng lượng, thông tin.

499

Cần phân biệt công nghệ nói đến những kĩ thuật được phát
triển cho một loại vấn đề nào đó, còn kĩ nghệ nói tới các qui trình
nghiêm ngặt phối hợp các công nghệ, phương pháp và công cụ để
làm ra sản phẩm có chất lượng. Triển khai tiếp một số khái niệm
liên quan chúng ta có thể xét thêm: kĩ thuật và công nghiệp.
Kĩ thuật (technique) có nghĩa hẹp nhất chỉ ra một cách thức
tiến hành một công việc nào đó - kĩ thuật phần mềm bao gồm các
kĩ thuật như kĩ thuật viết hệ điều hành, kĩ thuật làm chương trình
điều khiển v.v.
Công nghiệp (industry) là chữ bao trùm cả một ngành lớn,
trong đó bên cạnh yếu tố kĩ nghệ còn có thêm những khía cạnh
kinh tế, tài chính, tổ chức xã hội v.v. Chẳng hạn trong công nghiệp
xe hơi, kĩ nghệ (sản xuất) - sản xuất để trong ngoặc vì kĩ nghệ là đã
500


hàm ý sản xuất rồi - xe hơi sử dụng đến cả các kĩ thuật đúc, hàn ...
của công nghệ cơ khí đến kĩ thuật làm lốp xe của công nghệ cao
su...
Khía cạnh công nghệ thường là cách thức kĩ thuật để tạo ra
những sản phẩm cụ thể đã và đang được dạy tại các đại học, còn
các khía cạnh khác của kĩ nghệ phần mềm, cho đến bây giờ vẫn là
dùng các xemina ngắn ngày để bổ sung và dùng "việc huấn luyện
trong công việc" là chủ yếu, nói tới việc thực hành các tiến trình
sản xuất phần mềm theo qui tắc, kỉ luật và bài bản.
Để chế tạo ra sản phẩm thích hợp, cần phải xác định ra các yêu
cầu về sản phẩm đó và từ đó xác định các tiến trình kĩ nghệ chế tạo
tương ứng. Tiến trình kĩ nghệ tổ hợp các yếu tố con người và các

công nghệ trong những hoạt động quản lí chung để cuối cùng đưa
tới chế tạo ra sản phẩm đáp ứng đúng yêu cầu ban đầu đặt ra.
Nhưng để có được sản phẩm thực tế, chúng ta cần có cách thức tổ
chức phối hợp sự hoạt động của một nhóm người cùng các nguồn
tài nguyên, tài lực, theo các tiến trình kĩ nghệ đó. Cho nên điều cần
được đề cập tới khi nói tới kĩ nghệ phần mềm là việc quản lí các dự
án làm ra sản phẩm đó. Và để quản lí được, để phối hợp các hoạt
động sáng tạo theo qui trình đã đặt ra, người ta cần có ngôn ngữ
chung mô tả cho mọi hoạt động trong tiến trình dự án này.
Trong cuốn sách này chúng ta sẽ tập trung vào một loại sản
phẩm đặc biệt - phần mềm máy tính. Từ vấn đề vừa được trình bầy,
rõ ràng để chế tạo ra sản phẩm phần mềm theo qui mô kĩ nghệ thì
những người tham gia vào quá trình này cần có các hiểu biết tối
thiểu về:
-

tiến trình làm phần mềm
cách quản lí tiến trình này
cách thể hiện và ghi chép lại mọi kết quả phát sinh trong
tiến trình này.

499

-

các công nghệ cụ thể thực hiện các công đoạn trong tiến
trình làm phần mềm.

Tuy nhiên, trước khi đi vào chi tiết về việc chế tạo ra phần
mềm máy tính, chúng ta xem xét một số vấn đề chung về tiến hoá

của kĩ nghệ và phần mềm.

Kĩ nghệ và thủ công
Đặc điểm chính của sản phẩm thủ công là không phức tạp, và
chất lượng không đều nhau. Sản phẩm làm ra có thể rất tốt, chất
lượng rất cao, tuỳ người làm, và cũng có thể trung bình, có thể
kém. Mặt khác không thể nhiều người làm chung với nhau, hoặc
nếu có nhiều người làm chung thì mỗi người đều cùng làm một
việc giống nhau, như hàng nghìn người đào đất đắp đê chẳng hạn.
Như vậy công việc sản xuất ra sản phẩm thủ công không do nhiều
người làm, làm không nhanh và đầu tư ít.
Trái lại, kĩ nghệ luôn luôn nhằm những sản phẩm phức tạp,
nhằm tạo ra sản phẩm chất lượng cao nhưng không nhằm chất
lượng rất cao, do những cá nhân trung bình làm ra. Kĩ nghệ nhằm
đạt mục đích sản xuất nhanh những sản phẩm phức tạp, nhằm sản
xuất tập thể, theo qui trình chặt chẽ. Kĩ nghệ sẵn sàng đầu tư cao
hơn nhiều so với thủ công. Và kĩ nghệ có thừa hưởng một giai
đoạn lịch sử lâu đời là thủ công. Cái máy dệt hiện đại nhất hiện nay
vẫn sử dụng một số nguyên tắc mà người ta đã khám phá ra từ thời
thủ công.
Tiến hoá kĩ nghệ
Kĩ nghệ đầu tiên được phát triển trong lich sử loài người là kĩ
nghệ cơ khí, có từ nhiều thế kỉ nay. Lấy một thí dụ, nhu cầu thực tế
về giao thông đặt ra vấn đề xây dựng cầu cống qua các con sông.
Trước tiên người ta phải mô tả được các tính năng cần thiết cho
cây cầu dự định xây dựng (chiều dài, chiều rộng, tải trọng) và phải
500


biết khi nào "làm được" bằng những công nghệ hiện có. Bộ môn

thiết kế cầu đã được kiến trúc sư và những kĩ sư cơ khí, các nhà
xây dựng hiểu rõ.
Đặc điểm chung của các hoạt động kĩ nghệ là mọi người tham
dự vào một dự án kĩ nghệ đều phải có hiểu biết chung về phần
công việc của mình và mối liên hệ với công việc của toàn thể
nhóm. Tất cả đều phải có khả năng đọc các tài liệu kĩ nghệ và quản
lí (bản kế hoạch tổng thể, biểu đồ công việc găng, bảng phân việc,
sơ đồ Gantt). Hoạt động kĩ nghệ đòi hỏi có mục tiêu/cột mốc được
thiết lập rõ ràng để có thể đạt tới được trong hoàn cảnh thông
thường.
Mặt khác dự án kĩ nghệ chỉ có thể được thực hiện với một tổ
chức có các nhân viên có kĩ năng. Điều này có nghĩa là cần tập
trung những con người có đủ phẩm chất về chuyên môn vào việc
hoàn thành các nhiệm vụ kĩ nghệ. Do đó phát sinh nhu cầu phối
hợp hoạt động của nhiều người mang các chức năng và chuyên
môn khác nhau.
Thường có hai loại người tham gia vào các dự án kĩ nghệ: kĩ
sư-kiến trúc sư và các nhà chuyên môn. Trong các dự án kĩ nghệ
cần có các kiến trúc sư có bằng, được đào tạo bài bản, biết rõ các
nguyên tắc kĩ thuật cũng như qui trình làm việc: kĩ sư cơ khí/kết
cấu, kĩ sư dân dụng, người quản trị dự án v.v.. Mặt khác các dự án
kĩ thuật cũng cần các chuyên gia có chứng chỉ, nhưng người
chuyên môn trong các hoạt động sản xuất: thợ hàn, thợ bê tông
v.v..

1.2 Kĩ nghệ phần mềm
Kĩ nghệ phần mềm là gì? IEEE - hiệp hội những người kĩ sư
điện và điện tử của Mĩ, năm 1990 đề nghị một định nghĩa kĩ nghệ
phần mềm như sau:
499

Kĩ nghệ phần mềm là sự áp dụng một cách có hệ thống và kỉ
luật những phương pháp có thể định lượng được trong các
khâu phát triển, vận hành, và bảo trì phần mềm. Tức là áp
dụng những nguyên tắc của kĩ nghệ vào phần mềm.
Tại sao lại có kĩ nghệ phần mềm? Thứ nhất là phần mềm
ngày xưa do một số nhỏ người viết, vài người viết trong vòng vài
tháng. Nhưng đến những hệ phần mềm lớn như hệ DOS của IBM
hay hệ mềm dùng cho chương trình không gian của Mĩ, thì không
phải vài người trong vài tháng nữa mà là hàng trăm người trong
nhiều năm, trong mười năm. Hệ mềm như chương trình điều khiển
viễn thông, một công ti quốc tế có thể có 3, 4 nhóm làm việc tại 3,
4 nước khác nhau, mỗi nhóm hai, ba trăm người. Chương trình
điều khiển tổng đài điện thoại hiện bán khắp nơi trên thế giới đã
được phát triển trong vòng 5 năm, bao gồm hàng chục nghìn đơn vị
người làm.
Số người tham gia phát triển đông tới vài trăm, thời gian phát
triển sản phẩm lâu nhưng thời gian sử dụng chúng còn lâu hơn nữa.
Và phần mềm không bao giờ giữ nguyên cả, bao giờ cũng thay đổi.
Nhu cầu của người sử dụng ngày càng tăng, máy móc thiết bị điện
tử ngày càng rẻ và ngày càng làm được nhiều chuyện. Bởi vậy
người ta thấy cần phải có phương pháp tương đối kỉ luật và nhất là
cần có ngôn ngữ chung để trao đổi khi làm ra các sản phẩm.
Và như vậy cần có kĩ nghệ phần mềm vì khách hàng đòi hỏi
những phương pháp và ngôn ngữ ấy. Nếu có một ngôn ngữ mô tả
chung thì khách hàng cũng hiểu ngôn ngữ đó và như vậy nắm được
sản phẩm tốt hơn.
Kĩ nghệ phần mềm có ích lợi gì? Có một vấn đề rất quan
trọng cho các nước đang phát triển là những nước đang phát triển
thì phát triển rất nhanh. Và phát triển có nghĩa là thay đổi. Những

qui trình sản xuất vật phẩm, quản lí những cơ sở thông tin của các
cơ quan, doanh nghiệp, trong các nước đang phát triển cần thay đổi
500


rất nhanh theo tiến độ thay đổi. Và sự thay đổi đó muốn thay đổi
được nhanh thì nó phải sạch sẽ, nó phải vuông tròn đâu ra đấy.
Thêm bớt cái gì thì không ảnh hưởng đến các chuyện khác. Tức là
phải làm được những sản phẩm phần mềm sạch sẽ, đúng tiêu chuẩn
công nghệ.
Một vấn đề khác là để làm gia công cho người khác thì phải
học hỏi cách làm của thế giới. Nếu làm gia công cho người khác
thì cũng nên biết người khác chờ đợi ở người kĩ sư phần mềm
những hiểu biết gì, những phương pháp làm việc như thế nào.
Người làm phần mềm từ hai ba chục năm nay trên thị trường
đã trở thành loại sản phẩm hiếm và quí. Họ thay đổi công việc
luôn, họ tới một công ti tham dự chừng 4-5 năm, làm xong việc rồi,
lại chuyển sang chỗ khác, việc khác. Sản phẩm họ để lại đó làm
sao người tiếp khác tiếp thu được? Cho nên phải có một ngôn ngữ,
một cách trình bày chung để làm sao sản phẩm độc lập với người
sản xuất. Đó là một nguyên tắc tuyệt đối của kinh tế thị trường:
Sản phẩm và người sản xuất độc lập với nhau.
Làm việc tập thể không phải là làm việc riêng của nhóm năm
mười người. Sản phẩm phải phù hợp với yêu cầu chứ không phải là
sản phẩm do một người nào đó nghĩ ra rồi làm và bán được. Trong
thực tế, cũng có trường hợp cá nhân xuất sắc nghĩ ra được sản
phẩm và sau đó sản phẩm này tràn ngập thị trường. Ví dụ rất rõ là
những trang tính điện tử mà bây giờ người ta quen với cái tên là
Excel. Đó là sáng tác của một cá nhân và người đó không phải là
một chuyên gia tin học, chỉ là một người làm kế toán. Anh ta thấy

cần làm những việc mình vẫn làm nhưng trên máy tính, rất đơn
giản: chia cột chia hàng ra rồi thực hiện tính toán. Một ý kiến hết
sức giản dị nhưng phải có một người đầu tiên nêu ra ý kiến này.
Nhưng đấy là những trường hợp đặc biệt. Thông thường muốn sản
phẩm phù hợp yêu cầu thì phải có công tác tiếp thị. Phải tiếp xúc
với khách hàng mới lấy được yêu cầu của khách hàng. Đấy là khâu
499

khó nhất trong áp dụng tin học, không phải là việc viết chương
trình.
Người ta làm gì trong kĩ nghệ phần mềm? Người ta có một
số phương pháp và những phương pháp đó hiện bây giờ chưa phải
đã là chuẩn hoá. Mọi người đã học về tin học đều biết, máy tính là
vạn năng. Nó vạn năng trong ý nghĩa là nếu người ta nghĩ ra được
một cách giải quyết vấn đề nào đó thì máy tính cũng có thể làm
theo cách giải quyết đó. Điều này đã được nhà toán học người Anh
Alain Turing chứng minh. Như vậy nếu nó là vạn năng thì bất cứ
một vấn đề gì nếu mô tả được rõ ràng đều có thể giao cho máy tính
thực hiện.
Tuy nhiên lại không có phương pháp vạn năng nào để theo
đó tự động máy tính giải được tất cả mọi vấn đề. Máy tính chỉ tự
động được khi người ta đã trao cho máy một mô tả cách làm rõ
ràng. Nhưng không có phương pháp vạn năng cho người để giải
quyết mọi vấn đề. Nếu đã có một phương pháp vạn năng để viết
phần mềm thì khi đó không cần người làm nữa. Như vậy, nói riêng
không có phương pháp nào để viết ra được bất cứ phần mềm nào.
Phương pháp để viết phần mềm cho tính toán trong xây dựng
khác với phương viết phần mềm cho quản lí ngân hàng, khác với
phương pháp viết phần mềm cho làm các trang Web chẳng hạn.
Không có phương pháp tuyệt đối cho mọi phần mềm. Và như vậy

cần nắm những phương pháp tuỳ theo kinh nghiệm cụ thể. Cần làm
một số phương pháp trên một số miền vấn đề rồi sau đó người làm
phần mềm có kinh nghiệm sẽ chọn lựa phương pháp thích hợp ở
những bước đầu của dự án của mình.
Tuy nhiên cũng có một điều tương đối tốt là một số nhà làm
về phương pháp đã họp với nhau và đồng ý với nhau để đưa ra một
cái gọi là UML (Unified Modelling Language) - một ngôn ngữ để
mô hình hoá thống nhất. Họ thống nhất với nhau, có 3-4 người và
bây giờ gần như là họ có được sự đồng thuận trong nghề với những
500


thng nht ca h. Ngụn ng mụ hỡnh hoỏ thng nht UML l s t
hi ca nhiu cỏch thc mụ t vn , nú khụng cú cỏi tha v cỏi
trựng lp. Nú phc v cho nhiu min vn , nhiu phng phỏp.

1.3 Tin hoỏ phn mm
Tin hoỏ phn mm c xem xột trờn bn gúc nhỡn trong
quỏ trỡnh to ra cỏc phn mm: yờu cu ca vn , c t vn ,
thit k v ci t h thng phn mm. Bn gúc nhỡn ny cho
chỳng ta thy c s tin hoỏ t thp n cao theo chiu thi gian
ca ton b vn .

Đặ
c tả

Thời gian thực,
nối mạ ng cục
bộ,CSDL

Tính toán,
quản lý nhỏ

Yêu cầu

Đ ầu vào + đầu
ra ; dòng chuyển
dữ liệu

Ngôn ngữ
th ờng

Cấu hì
nh hệ
thống,
cấu trúc GT vàDL

Thiết kế

Giải thuật

Cài đặ
t

C.T. đơn giản,
Xử lý Batch

55

60

65

HĐ H, Hệthống
CSDL th ờng
trực

70

75

80

PC, Nối mạ ng
tầm rộng,
Internet
H ớ ng sự vật,
Vòng đời PM,
CASE
Tính mô đun, Sự
vật, Giao thức,
Giao diện
Dù ng lạ i PM đóng
gói, ngôn ngữ
h ớ ng sự vật

85

90

95

2000

Phn mm cú vo khong nhng nm 1955 n nm 2000
hin nay v cú th c chia thnh 3 giai on. Yờu cu ca giai
on th nht t nhng nm 1955 n khong 1965 - 1970 l tớnh
499

toỏn v qun lớ ri rc, qun lớ nh. c t ca nhng yờu cu ú
lỳc ú l dựng ngụn ng thng, vit ra: Tụi mun cú 1 tp d liu
cha nhng iu ny, iu ny... Mi ngy cp nht nú my ln.
Phiu sn phm, bỏn mi sn phm v ghi vo phiu bỏn nhng cỏi
gỡ thỡ chng trỡnh phi c cho vo tp d liu ú v.v... Thit
k lỳc by gi nm luụn trong vic ngi ngi vit chng trỡnh v
hc nhng gii thut vit chng trỡnh cho tt. c d liu vo,
vit d liu ra, sp xp, tỡm kim, xoỏ, cp nht v.v.. Thi ú cỏc
chng trỡnh n gin v thc hin x lớ theo lụ.
Giai on th nhỡ vo khong t nhng nm 1970 n 1985.
Lỳc ny ó cú cỏc nhu cu v phỏt trin cỏc chng trỡnh thi gian
thc, xõy dng cỏc mng cc b v ni cỏc c s d liu vi nhau.
c t thi ú chỳ trng vo c t u vo, u ra, v lung
chuyn d liu. Tc l d liu chuyn t u vo n tp no ri
nú x lớ nh th no n u ra ca mt x lớ, m nú li l u vo
ca mt x lớ khỏc. Thit k thi ú chỳ trng ti cu hỡnh h
thng, system configuration, tc l ó phi cú mỏy tớnh, cú a
cng, cú mỏy c bỡa, v bt u cú vin thụng. Mt ngi lm
chng trỡnh cho mt c quan ln thỡ vn ln i vi h lỳc by
gi l cu hỡnh h thng. Gii thut v d liu lỳc ú cng t ra
vn cú cu trỳc quan trng, vỡ bt u lm vn ln thỡ phi cú

nhng mụ t cú cu trỳc cho d hiu. V nhng phng phỏp ci
t thi ú, ngi ta ý n h iu hnh, nh DOS ca IBM hay
Unix. V ó cú nhng c s d liu thng trc cú th truy nhp
bng vin thụng c.
Giai on th ba bao gm nhng vn quen thuc vi mi
ngi. õy l thi ca mỏy vi tớnh PC, thi ni mng tm rng,
din rng, vi Internet. c t d ỏn c bit nhiu l hng s
vt, nhiu ni gi l hng i tng. Cụng c CASE (Computer
Aided Software Engineering) l nhng cụng c m ngi c t
vn cn phi bit. Tng thit k ý nhiu n tớnh mụ un,
ý n s vt, ý n giao thc (protocol), v giao din (interface).
500


V c bn da trờn mụ hỡnh liờn ni h thng m OSI, cũn giao
thc v giao din thỡ xỏc nh ra vic trao i gia cỏc s vt. V
trong ci t thỡ dựng ngụn ng hng s vt l mt c im. c
im th nhỡ l ngi ta chỳ trng dựng li nhng phn mm úng
gúi. Chng trỡnh x lớ vn bn hay trỡnh duyt Nestcape hay
Internet Explorater, tt c u l phn mm úng gúi. Vn ci
t bõy gi l lm sao tớch hp nhng h mm úng gúi v vn
riờng ca tng nghip v thỡ dựng phn mm c sn xut theo
hng s vt.
Trong lch s vo khong cui nhng nm 60, 60-68, ngi
ta loan bỏo cỏi gi l khng hong phn mm, cho ti nay vn cũn
khng hong phn mm. Tỡnh trng khng hong bõy gi l khng
hong thiu ngi. Khng hong thi by gi l khụng bit cỏch
lm phn mm cho tt. Bi vy ó cú nhng yờu cu k ngh hoỏ
phn mm t thi y.
Mi nm sau, theo kim tra ca k toỏn M thỡ: 50% hp

ng vt quỏ ngõn sỏch, tc l nhng ngi lm phn mm luụn
luụn chi tin quỏ mc, khụng bao gi chi ớt hn. 50% hp ng l
quỏ tin, 60% l tr, 45% l giao np nhng khụng ỳng yờu cu
khỏch hng. 22% trong 45% ú thỡ mt na l khụng th sa cha
nh c na m phi thit k li ton b. V 29% l tht bi hon
ton, khụng bao gi giao np.
Nm 1979 theo thng kờ ca Tom de Marco trong mt cun
sỏch thỡ vn cũn l 25% h mm ln tht bi. Thng kờ ca Copers
Jones, 19 nm sau, 1991: trung bỡnh cỏc h thụng tin qun lý b tr
1 nm v vt ngõn sỏch 100%. iu ny núi lờn l ngi ta cha
qun lớ c phn mm, cỏch õy 10 nm, tuy rng nhng hiu bit
v MIS (Management Information System) l , ớt tht bi, nhng
ngi ta luụn luụn b vt ngõn sỏch.

thng trc. Khụng nhng thng trc m phn mm cũn truy
nhp c khp ni trờn th gii. Thnh ra ngi ta ó phc v
c nhng yờu cu ngy cng cao bng nhng sn phm ngy
cng ln. Nhng t s tht bi, t s m vt quỏ hn qun lớ, quỏ
thi gian v quỏ hn tin thỡ vn nh vy. Tin b l ú, cỏc h
mm ngy cng ln v cht lng ngy cng cao, vỡ cht lng ca
mt h mm thng trc 24 gi trờn 24, 7 ngy trờn 7.
V nh vy nng sut lp trỡnh tớnh theo dũng lnh vo
khong 6% mt u ngi. Hin bõy gi nng sut lp trỡnh bõy
gi khong 20-40 dũng lnh mt ngy tu d ỏn khú hay d.
Nhng 1 dũng lnh bõy gi bng my chc ln dũng lnh thi xa.
ú l vỡ ngụn ng lp trỡnh ngy cng mnh, thỡ tin b ch ú.
V nú mnh bng hng chc ln ngy xa v ngn ti nguyờn bng
hng nghỡn ln ngy xa.

1.4 Qui trỡnh phn mm

Mt s im c bit v quỏ trỡnh phỏt trin phn mm cn
c cp ti vỡ nú khỏc vi qun lớ phỏt trin cỏc sn phm
khỏc. Vic phỏt trin phn mm cn tuõn th theo nhng qui trỡnh
nht nh. Mt trong nhng qui trỡnh thng c ly lm nn tng
l qui trỡnh Thỏc "Waterfall". Tuy rng cú nhiu qui trỡnh phỏt
trin phn mm khỏc v s c gii thiu sau, nhng chỳng u
da trờn qui trỡnh Thỏc , bao gm nhiu khõu ni tip nhau.
Qui trì
nh Thác đổ
Cần làm
gìđó ?

1/ Quản lý tiến
trì
nh phần mềm

Thực hiện
thếnào ?
Thực hiện

Nhng tin b cho n bõy gi l gỡ? Cỏc h mm ngy cng
ln, ngy cng tớch hp. Ngy xa chy n l, bõy gi thỡ chy
499

Và hai vấn đềbao trù m

2/ Ngôn ngữ mô tả
tiến trì
nh (UML)
500

Thử
Sử dụng


Thứ nhất người ta cần đặt câu hỏi : cần làm gì? Sau đó đặt
câu hỏi: trước khi thực hiện thì cần suy nghĩ về cách thực hiện như
thế nào? Rồi mới thực hiện. Thực hiện xong thì thử. Thử xong thì
đưa vào sử dụng. Qui trình này được gọi là "thác đổ" vì nó như
nước chảy xuống và người ta cố gắng không chảy ngược lên. Tức
là mỗi giai đoạn nọ quyết định giai đoạn sau. Đây cũng là một vấn
đề lí thuyết chứ trên thực tế thì không thể hoàn toàn như thế được.
Nhưng dù sao cũng phải có khuôn mẫu để tuân theo.
Xác định cần làm gì chính là việc lấy yêu cầu của người
dùng - user requirement. Phân tích và thiết kế chia nhỏ vấn đề ra
như thế nào. Chung quanh đó có 2 vấn đề bao trùm, ngôn ngữ
UML và quản lí phần mềm. Ngôn ngữ UML bao trùm là vì nó mô
tả tài liệu chạy qua tất cả các khâu. Và quản lí phần mềm cũng là
một vấn đề bao trùm. Dĩ nhiên không phải đến đây ta mới đề cập
về vấn đề quản lí, quản lí phần mềm là một vấn đề cần đề cập tới
từ trước khi làm phần mềm.

1.5 Về cách giải quyết vấn đề
1.5.1 Từ lập trình đi lên
Lập trình đã là trung tâm điểm của tin học trong suốt thời kì
đầu phát triển: xây dựng và hoàn thiện máy tính điện tử, công cụ
xử lí thông tin do con người tạo ra. Mục đích ban đầu của lập trình
là làm ra các chương trình điều khiển máy tính hoạt động xử lí tính
toán. Do đó đối tượng ban đầu của lập trình là các bài toán khoa
học kĩ thuật.

499

Khi những tiến bộ kĩ thuật đã cho phép chế tạo ra các máy tính
điện tử ngày một hoàn thiện hơn thì việc ứng dụng các máy tính
này vào sản xuất kinh doanh cũng bắt đầu phát triển theo. Từ đó
đối tượng của việc lập trình bắt đầu có sự thay đổi, mặc dầu vẫn
nhắm vào việc làm cho máy hoạt động tốt hơn và dễ dùng hơn,
phần lớn việc lập trình chuyển sang nhằm giải quyết các bài toán
ứng dụng trong kinh doanh và quản lí trên máy tính.
Yêu cầu của thực tế không ngừng nâng lên khi các máy tính
xử lí thông tin được đưa vào sử dụng trong sản xuất thường ngày.
Vai trò của máy tính tham dự trong các hoạt động quản lí thông tin
của mọi tổ chức không ngừng tăng lên. Điều này dẫn tới một sự
dịch chuyển nữa từ việc lập trình cho các bài toán quản lí riêng lẻ
sang việc xây dựng các hệ thống phần mềm lớn mô phỏng cho các
hệ thống thực tế trong máy tính.
Đi kèm với sự thay đổi về đối tượng của việc lập trình như vậy
là sự thay đổi tương ứng trong cách thức người ta nghĩ và giải
quyết vấn đề thông qua việc sử dụng máy tính. Nếu như trong
những ngày đầu của máy tính, việc lập trình là công việc chủ yếu
của một vài người, quan niệm toàn bộ mọi vấn đề và triển khai mọi
hoạt động lập trình, thì ngày nay mô thức làm việc ấy không còn
thích hợp nữa. Bây giờ thực tế yêu cầu cần có những hệ thống phần
mềm lớn mà việc tạo ra nó phải cần công sức của nhiều người cùng
làm việc, không ai một mình có thể xây dựng ra được các hệ thống
như vậy.
Chúng ta sẽ xem xét ở đây về kĩ nghệ phần mềm, được phát
triển ra từ nền tảng lập trình trước đây. Để nhìn một cách toàn
cảnh, chúng ta bắt đầu từ việc xem xét cách thức giải quyết vấn đề

của lập trình và từ đó chuyển sang xem xét theo góc độ kĩ nghệ.
Các tri thức chính liên quan tới lập trình là:

500




Tri thức về cách hoạt động của công cụ xử lí thông tin, cách
thức máy móc làm việc, từ cụ thể tới trừu tượng, từ máy tính cụ
thể tới các ngôn ngữ lập trình cấp cao. Nói cách khác đó là tri
thức về các vấn đề cú pháp và ngữ nghĩa của công cụ xử lí
thông tin. Tư duy giải thuật, tư duy thuật toán chiếm vị trí chủ
yếu ở đây.



Tri thức về cách triển khai giải quyết vấn đề bằng máy tính,
cách thức con người làm việc với máy tính để giải quyết các
bài toán đặt ra. Nói cách khác đó tri thức về cách thức triển
khai chương trình điều khiển máy tính hoàn thành một chức
năng, nhiệm vụ tính toán xử lí nào đó. Tư duy hướng vấn đề, tư
duy hệ thống chiếm vị trí chủ yếu ở đây.

Như vậy bất kì ai muốn làm chủ và sử dụng được hữu hiệu
công cụ xử lí thông tin máy tính cũng cần phải am hiểu đầy đủ hai
loại tri thức trên: tri thức về bản thân công cụ và tri thức về việc sử
dụng công cụ để giải quyết các bài toán, vấn đề thực tế. Cả hai loại
tri thức này mỗi ngày đều một tiến hoá và cao cấp hơn. Tri thức về
công cụ tính toán, về máy tính, thường do các tiến bộ của CNTT

trên thế giới đem lại. Chúng ta được thừa hưởng những thành tựu
khoa học công nghệ lớn lao của cả nhân loại được cụ thể hoá trong
các thiết bị máy móc ngày càng mới này. Nhưng điều quan trọng
hơn là chúng ta phải có tri thức vận dụng hữu hiệu những công cụ
này vào thực tế thì mới có thể đóng góp thêm phần tri thức gia tăng
của mình. Nhìn rộng ra, nếu xã hội nào biết phát huy và thúc đẩy
việc sử dụng hữu hiệu công cụ mới thì sẽ phát triển nhanh hơn.
Các tri thức về ngôn ngữ lập trình, về các vấn đề liên quan tới
việc tổ chức chương trình trong các ngôn ngữ lập trình đã là những
tri thức được đưa vào giảng dạy trong các giáo trình cơ sở về tin
học. Đấy là loạt vấn đề liên quan tới bản thân công cụ máy tính,
cũng quan trọng nhưng chưa đủ.

499

Nay một vấn đề cần được bàn luận chi tiết hơn là cách giải
quyết bài toán, vấn đề trên máy tính, thường vẫn được hiểu là việc
lập trình. Thời kì đầu của việc phát minh ra máy tính, lập trình chỉ
là việc mã hoá một thuật toán theo ngôn ngữ lệnh của một máy nào
đó, rồi sau đó chỉnh chương trình để cho máy chạy được cho ra kết
quả. Như vậy việc lập trình cho máy tính phải trải qua các giai
đoạn sau:
1.
2.
3.
4.
5.

Nhận yêu cầu tính toán.
Tìm hiểu bài toán đặt ra.

Phát triển thuật toán giải bài toán đó.
Chuyển thuật toán này thành chương trình của máy tính.
Cho chương trình chạy trên máy để kiểm thử xem đã
chương trình chạy đúng chưa và chỉnh cho chương trình
chạy đúng.
6. Thực hiện tính toán và chuyển giao kết quả tính toán cho
nơi yêu cầu.
Tiến trình thực hiện việc lập trình này mang nặng tính chất
phụ thuộc vào máy tính. Các yêu cầu tính toán thì không mấy bị
phụ thuộc vào máy tính, nhưng các bước phát triển kế tiếp ngày
càng chứng tỏ sự lệ thuộc vào kết cấu hoạt động của máy móc. Từ
trình tự trên chúng ta thấy rằng việc lập trình nếu được xét theo
quan điểm mã hoá thì thực sự chỉ là một bước (bước 4) trong toàn
bộ tiến trình giải quyết vấn đề. Do vậy điều cần được đề cập tới ở
đây là làm sao người ta có thể đi từ các vấn đề, yêu cầu của thực tế
để tìm ra giải pháp cho vấn đề và cuối cùng thực hiện giải pháp đó
trên máy tính. Như vậy hai khía cạnh khác nhau cần phải được
xem xét tới: khía cạnh phát hiện vấn đề và mô tả vấn đề thực tế, và
khía cạnh mô tả và thực hiện giải pháp cho vấn đề trong máy tính.
Khi ứng dụng của tin học được mở rộng, không chỉ giải quyết
các vấn đề tính toán khoa hoch kĩ thuật mà chuyển sang các vấn đề
về quản lí, kinh doanh, tổ chức và xử lí dữ liệu, thì có sự thay đổi
500


căn bản trong thái độ con người tiếp cận tới máy tính. Máy tính,
mặc dầu vẫn được hoàn thiện thêm, không còn là mối quan tâm
nghiên cứu chủ chốt của tin học nữa mà trở thành công cụ giúp cho
con người nhận thức và làm chủ các tiến trình điều khiển trong các
hoạt động kinh tế và xã hội.

Sự quan tâm của người ta chuyển dần sang việc xây dựng các
hệ thống hoạt động lâu dài trên máy tính, mô phỏng các hoạt động
quản lí và xử lí thông tin của con người trong thực tế. Từ đó xuất
hiện nhu cầu cần chính xác hoá và làm rõ ràng thành những qui
trình kĩ nghệ để giúp cho con người khắc phục được độ phức tạp
của các bài toán thực tế. Một điều ngày càng trở nên hiển nhiên là
các hệ thống mô phỏng trên máy tính ngày càng phức tạp, đòi hỏi
sự phối hợp hoạt động của rất nhiều người trong một thời gian dài.
Do đó, song song với việc hình thành các qui trình phát triển hệ
thống, phần mềm thì cũng hình thành nhu cầu quản lí các tiến trình
phát triển phần mềm và nhu cầu phát triển ngôn ngữ chung để mô
tả cho mọi hoạt động phát sinh trong tiến trình này.
Phân tích trình tự làm việc trên đây đối với máy tính, chúng ta
thấy có những điểm tương đồng với trình tự kĩ nghệ phần mềm
hiện nay. Bước thứ nhất phản ánh việc nhận biết vấn đề, bài toán
thực tế, chưa động chạm gì tới cách giải quyết cũng như cách thực
hiện trên máy tính. Bước này được đặc trưng bởi việc tìm hiểu và
mô tả được về yêu cầu đặt ra. Theo ngôn ngữ hiện đại đây là bước
xác định yêu cầu hệ thống và phần mềm.
Bước thứ hai đi sâu thêm một chút để có thể mô tả được vấn
đề là gì và xác định có thể tiến hành giải quyết được hay không.
Theo ngôn ngữ hiện đại đây là bước phân tích hệ thống để tìm hiểu
khả năng giải quyết và phác thảo cách giải quyết.
Bước thứ ba là việc xây dựng giải pháp, từ không gian vấn đề
đặt ra, chuyển sang không gian giải pháp cho vấn đề. Theo ngôn
ngữ hiện đại thì đây là bước thiết kế hệ thống. Thực sự bước này
499

bao gồm hai thành phần tương đối khác biệt: thiết kế kiến trúc
chung của hệ thống, và thiết kế chi tiết. Thiết kế kiến trúc thực hiện

phân chia ra các hệ con và xác định mối quan hệ trao đổi thông tin
giữa chúng nhằm đưa ra một giải pháp tổng thể cho vấn đề, chưa bị
lệ thuộc vào các yếu tố chi tiết của máy tính. Các thiết kế chi tiết
đề cập tới những thiết kế về dữ liệu, mô đun và giao diện xác định
ra cách thực hiện hệ thống trên máy tính.
Bước thứ tư thường được mô tả là bước lập trình hay mã hoá
cho giải pháp, xây dựng một hệ thống thực hiện được trên máy tính
dựa theo các thiết kế đã được vạch ra. Trước đây bước này vẫn
được coi là chủ chốt và chủ yếu nhất đối với các chuyên viên lập
trình. Ngày nay, với một số ứng dụng tiêu biểu, đã có các công cụ
sinh chương trình, và mối quan tâm của người làm phần mềm được
dồn nhiều hơn vào các bước thu thập yêu cầu, phân tích và thiết kế
hệ thống.
Bước thứ năm là bước kiểm thử giải pháp, cho phép thẩm định
lại tính đúng đắn của giải pháp được thực hiện trên máy tính theo
các yêu cầu ban đầu đã đặt ra. Có nghĩa là xem xét lại xem hệ
thống được xây dựng ra có đáp ứng đúng cho các yêu cầu ban đầu
hay không. Thường bước này được thực hiện trong hai pha. Pha
thứ nhất là người xây dựng ra hệ thống trực tiếp kiểm thử đề đảm
bảo hệ thống chạy thông và đáp ứng những yêu cầu thiết kế. Pha
thứ hai là người thuê làm hệ thống trực tiếp kiểm thử xem hệ thống
có đáp ứng đúng cho yêu cầu của mình hay không.
Bước thứ sáu tương ứng với bước cuối cùng là vận hành và
bảo trì hệ thống đã được xây dựng. Với việc hiện nay các ứng dụng
của máy tính không còn chỉ là giải quyết các vấn đề riêng lẻ mà
chủ yếu là mô phỏng và điều khiển các hoạt động thực tế, việc bảo
trì phần mềm và hệ thống trở thành công việc chủ yếu và thường
xuyên, để đảm bảo cho hệ thống tiến hoá kịp với những thay đổi
của thực tế. Do đó chính bước này dần trở thành rất quan trọng và
500

có ánh hưởng nhiều tới cách tiếp cận giải quyết vấn đề. Việc xây
dựng hệ thống một lần rồi thôi là khác xa với việc xây dựng hệ
thống để hoạt động được lâu dài và luôn hữu ích.
Chúng ta thấy rằng như vậy để giải quyết các vấn đề của thực
tế thì cần phải tiến hành theo trình tự trên đây, dù cho vấn đề là lập
trình hay rộng hơn, vấn đề mô phỏng thực tế trên máy tính. Điều
này đưa tới việc chúng ta cần xem xét kĩ hơn về các vấn đề có liên
quan tới không gian vấn đề, không gian bài toán, không gian các
giải pháp và bước chuyển từ không gian vấn đề sang không gian
giải pháp, tức là việc giải quyết vấn đề. Trên cơ sở xem xét qui mô
lớn này mà có thể thấy rõ hơn các vấn đề của phương pháp luận.

1.5.2 Vấn đề, giải pháp và giải quyết vấn đề
Các tổ chức tạo ra và chuyển giao sản phẩm và dịch vụ để đáp
ứng cho nhu cầu và đòi hỏi của khách hàng. Các yêu cầu có thể
được đặc trưng là vấn đề hay bài toán. Sản phẩm và dịch vụ giải
quyết cho những yêu cầu đó được đặc trưng là giải pháp. Để
chuyển giao giải pháp có giá trị (chất lượng tối đa với chi phí tối
thiểu trong phạm vi thời gian tối thiểu), tổ chức phải nắm bắt (thu
nhận), trao đổi (dùng chung), và sử dụng tri thức. Giá trị của giải
pháp được xác định bởi phẩm chất của sản phẩm hay dịch vụ, chi
phí của sản phẩm hay dịch vụ, và thời gian cần để tạo ra sản phẩm
hay cung cấp dịch vụ. Các tổ chức giải quyết vấn đề cho khách
hàng của mình, các nhân viên giải quyết vấn đề cho người chủ lao
động, các bác sĩ giải quyết vấn đề cho bệnh nhân, vân vân. Bên
trong những kiểu quan hệ này, tri thức là nhân tố thành công chủ
chốt.
Các tổ chức dùng công nghệ để phát tán và trao đổi thông tin

để cho nhân viên của mình có thể giải quyết các vấn đề nghiệp vụ.
Công nghệ chỉ là công cụ; không có con người biết cách áp dụng
499

nó và hiện thực hoá tiềm năng của nó, thì nó là vô dụng. Bởi vì thế
giới nghiệp vụ và thế giới công nghệ là trong một luồng biến đồi
thường hằng, nên chúng ta được yêu cầu phải quản lí độ phức tạp
đang tăng lên bên trong những nỗ lực đang tiếp diễn. Tuy nhiên,
chúng ta không nên quên rằng công nghệ là phương tiện cho mục
đích chứ không phải là bản thân mục đích.
Để thực hiện việc giải quyết vấn đề, giữa khách hàng và người
cung cấp giải pháp cần có một số văn bản pháp lí ràng buộc, dưới
dạng các dự án và hợp đồng. Dự án là nỗ lực giải quyết vấn đề.
Chúng bao gồm việc hiểu hay quan niệm về vấn đề, giải quyết vấn
đề, và thực hiện hay hiện thực giải pháp. Các thực thể người hay tổ
chức tham gia vào trong một dự án được biết tới là những người
tham dự. Một số người tham dự là người mà vấn đề được giải
quyết cho. Họ chịu trách nhiệm đóng góp tri thức của mình để hiểu
vấn đề và kiểm chứng lại giải pháp. Những người tham dự khác
chịu trách nhiệm đóng góp tri thức của mình để thực hiện giải
pháp. Kết quả của một dự án được biết tới như là việc chuyển giao
sản phẩm làm việc. Chúng là các sản phẩm hay dịch vụ giải quyết
cho một vấn đề.
Ta hãy xét một tổ chức gặp khó khăn trong việc phân bổ tối ưu
nhân viên của mình cho các dự án khác nhau. Tổ chức muốn có
một hệ thông tin để duy trì thông tin về nhân viên và dự án. Giải
pháp phải cung cấp khả năng để phân bổ nhân viên cho các dự án
dựa trên kĩ năng của họ và nơi họ có thể được sử dụng tốt nhất.
Trong khi giải quyết vấn đề này, một cách tiếp cận tổng thể phải đề
cập tới cách chúng ta sẽ hiểu và quan niệm vấn đề, suy diễn ra giải

pháp cho vấn đề, và thực hiện hay hiện thực hoá giải pháp. Cách
tiếp cận này sẽ xác định cách chúng ta xem xét vấn đề (mô thức)
với mục đích để hiểu nó. Chúng ta sẽ áp dụng tri thức của mình về
tình huống và các qui tắc cơ bản khác (trực cảm) thu được từ kinh
nghiệm khác để suy diễn ra giải pháp này (thông qua các vật
phẩm). Nỗ lực của chúng ta sẽ được tổ chức (vòng đời) như một
500


chuỗi các bước (hoạt động) (có thể tương tranh) để cho nó có thể
được quản lí để phát triển sản phẩm có kết quả.
Vấn đề xuất hiện bên trong một khung cảnh (miền hay không
gian) nghiệp vụ. Giải pháp phải được thực hiện để khớp với bên
trong kết cấu nền (miền hay không gian) công nghệ thông tin của
tổ chức. Vấn đề (hệ thống) nghiệp vụ phải được hoàn toàn hiểu rõ
dưới dạng các yêu cầu của nghiệp vụ, và sản phẩm hay hệ thông tin
phải được hiểu đầy đủ dưới dạng các cách thức nó đáp ứng cho
những yêu cầu đó. Hệ thông tin kết quả hay sản phẩm phần mềm
cũng phải được tổ chức (kiến trúc) để khớp vào trong kết cấu nền
công nghệ của tổ chức. Khi chúng ta quan niệm vấn đề và làm việc
hướng tới việc thực hiện giải pháp này thì chúng ta sẽ nắm được tri
thức (mô hình) về vấn đề nghiệp vụ và hệ thông tin, ra quyết định
(góc nhìn kiến trúc) về cách chúng ta sẽ đề cập tới các vấn đề khác
nhau, và nên có khả năng mô tả và trao đổi thông tin này (các biểu
đồ).
Phương pháp xác định ra cách tiến hành các nỗ lực giải quyết
vấn đề. Chúng xác định cách tiếp cận giải quyết vấn đề và các cấu
phần của nó. Chúng xác định cách vấn đề và giải pháp được xem
xét trong mối quan hệ với cách tiếp cận giải quyết vấn đề; điều này
được biết như khía cạnh mô tả của phương pháp vì nó mô tả cho

cách thức tri thức được nắm bắt và trao đổi đối với vấn đề và giải
pháp. Các phương pháp cũng xác định ra cách tiếp cận giải quyết
vấn đề được dùng để giải vấn đề và suy dẫn ra giải pháp; điều này
được biết tới như khía cạnh qui tắc của phương pháp vì nó mô tả
cho cách thức tri thức được bẩy ra để giải quyết vấn đề. Phương
pháp xác định về mặt mô tả cách thức vấn đề và giải pháp được
xem xét, và xác định về mặt qui tắc cách thức nỗ lực giải quyết vấn
đề có thể được thực tế hoá.

đề và thực hiện giải pháp. Các tiến trình được xác định bởi phương
pháp; điều này được biết như khía cạnh tĩnh của tiến trình vì nó là
mô tả về cách vấn đề có thể được giải quyết. Các tiến trình áp dụng
các phương pháp bên trong dự án để giải quyết các vấn đề; điều
này được biết như khía cạnh động của tiến trình.
Vì các dự án có thể rất phức tạp nên các phương pháp nên
được dùng để cung cấp một kết cấu nền cho tiến trình giải quyết
vấn đề. Chúng nên được xem xét như các gợi ý và khuyến cáo tổ
chức và tạo điều kiện cho tiến trình giải quyết vấn đề hơn là được
xem xét như các qui tắc không linh động và cứng nhắc, hạn chế
nghệ thuật giải quyết vấn đề. Phương pháp luận là việc phân loại,
hay tuyển tập có tổ chức tốt của các phương pháp có liên quan; do
đó, phương pháp có thể là một phần của phương pháp luận.
Vấn đề thường được nói tới như những tình huống như là vì
chúng biểu diễn cho các điều kiện hiện tại; giải pháp tương tự được
nói tới như các tình huống sẽ là vì chúng biểu thị cho các điều kiện
đích mà chúng ta đang cố gắng đạt tới, xem Hình 1.1.
Mô tả

Thông minh

Quan niệm

Giải quyết Vấn
đề
Vấn đề

Các yêu cầu
do vấn đề áp
đặt lên giải
pháp

Tiến trình là việc thực hiện của phương pháp. Chúng dùng
cách tiếp cận giải quyết vấn đề của phương pháp để giải quyết vấn
499

500
Qui tắc

Thực hiện
Giải pháp

Tri thức
Thu nhận
Trao đổi
Sử dụng

Đặc tả giải
pháp thoả
mãn cho yêu
cầu

Hình 1.1 Góc nhìn chung về giải quyết vấn đề
Một tình huống không gây ra khó khăn có thể vẫn được xử lí
như một vấn đề để hiểu nó; tuy nhiên, giải pháp lại không là gì
khác hơn việc hiểu về tình huống. Điều này phát sinh trong việc
xác định các đặc trưng, thay vì các yêu cầu, của tình huống và cung
cấp một góc nhìn mô tả thuần khiết về tình huống mà không có bất
kì góc nhìn mô tả hay qui tắc nào về giải pháp. Điều này thường
được tiến hành khi một giải pháp cho vấn đề là tồn tại, và giải pháp
hiện có cần được hiểu hay được đánh giá. Việc giải quyết vấn đề
(Hình 1.2) bao gồm các nỗ lực hay tiến trình hợp tác giải quyết vấn
đề. Những nỗ lực như vậy bao gồm các điều sau:


Quan niệm và biểu diễn vấn đề dưới dạng dễ uốn nắn và
trao đổi được. Điều này cho phép vấn đề được biểu diễn
trong một ngôn ngữ nào đó để cho nó có thể được thao tác
và trao đổi với người khác.



Xác định các yêu cầu do vấn đề áp đặt lên giải pháp của
nó, tức là, các yêu cầu được gây ra bởi vấn đề mà giải pháp
của nó phải thoả mãn.



Nhận diện hay xác định giải pháp thoả mãn các yêu cầu do
vấn đề áp đặt.



Đạt tới một mô tả về giải pháp bằng việc nhắm tới các câu
hỏi sau: Giải pháp là gì? Đặc tả cho giải pháp thoả mãn các
yêu cầu do vấn đề áp đặt là gì? Bên trong một dự án, nếu
các vấn đề này có thể được trả lời tối thiểu với đủ mức chi
tiết, thì nỗ lực đã đạt tới góc nhìn mô tả của giải pháp.

Mô tả

Giải quyết vÊn ®Ò
Yêu cầu

Đặc tả
Giải
pháp

Vấn đề

Đạt tới một mô tả về vấn đề bằng việc nhắm tới các câu
hỏi sau: Vấn đề là gì? Các yêu cầu về vấn đề mà giải pháp
của nó phải thoả mãn là gì? Trong một dự án, nếu các vấn
đề này có thể được trả lời tối thiểu với đủ mức chi tiết, thì
nỗ lực đã đạt tới góc nhìn mô tả của vấn đề.

499



Vấn đề
con

Vấn đề
con

Vấn đề
con

Vấn đề
con

Thu gọn (Phân tích)

Giải
pháp con

Giải
pháp con

Giải
pháp con

Giải
pháp con

Mở rộng (Hợp thành)

Qui tắc

Hình 1.2 Góc nhìn chi tiết về giải quyết vấn đề

500


Nếu giải pháp không thể được định ra cho một vấn đề, thì các
yêu cầu do vấn đề ấn định lên giải pháp của nó được nhóm lại,
phân loại, và tổ chức thành các vấn đề cấp dưới, được giải quyết
tương tranh. Một vấn đề cấp trên có thể được dẫn về hay phân tách
một cách đệ qui thành các vấn đề cấp dưới. Các vấn đề cấp dưới có
thể được giải quyết tương tranh, và giải pháp cho vấn đề nguyên
thuỷ có thể được mở rộng hay hợp thành đệ qui từ các giải pháp
cấp dưới. Tiến trình dẫn về tiếp tục cho tới khi giải pháp cho vấn
đề nguyên thuỷ được suy dẫn ra. Bởi vì tiến trình này là đệ qui nên
góc nhìn mô tả được dùng để phát hiện ra góc nhìn qui tắc. Hơn
nữa, việc phân tách cho phép rất nhiều việc giải quyết vấn đề song
song và tương tranh cho nên toàn bộ tiến trình được giải quyết.
Việc giải quyết vấn đề tiếp tục như sau:




khi các phần tử tri thức được thu nhận, dùng chung hay sử dụng
bên trong nỗ lực giải quyết vấn đề.
Thông minh là khả năng tiến hành tiến trình giải quyết vấn đề
bằng việc tổ chức tri thức trong một phân loại và áp dụng tri thức
một cách có chiến lược qua nỗ lực giải quyết vấn đề để suy ra giải
pháp.

1.5.3 Vòng đời

Cách tiếp cận giải quyết vấn đề được tổ chức (theo vòng đời)
để đưa ra viễn cảnh quản lí và viễn cảnh phát triển. Hai viễn cảnh
này làm cho các nỗ lực phát triển hệ thống được quản lí và thực
hiện.

Đạt tới việc qui định về các bước bên trong một giải pháp giải
quyết cho vấn đề bằng việc đề cập tới câu hỏi sau: giải pháp có
yêu cầu của riêng nó (hay các vấn đề phụ thuộc) được thoả mãn
như thế nào? Trong phạm vi một dự án, nếu những câu hỏi này
có thể được trả lời một cách tối thiểu với đủ mức chi tiết cần
thiết, thì nỗ lực đã được đạt tới một góc nhìn qui tắc về giải
pháp.
Thực hiện việc biểu diễn cho giải pháp trong một dạng cụ thể
và dùng được.

Vòng đời
Giai đoạn tiến hoá
Vòng lặp

Giai đoạn
quan niệm

Tri thức là cấu phần chèn lấp lên cần phải được thâu tóm (thu
nhận), truyền trao (dùng chung), và làm đòn bẩy (sử dụng) để tạo
điều kiện thuận tiện cho tiến trình này. Toàn bộ tri thức được bao
gồm trong một nỗ lực như vậy có thể được phân mảnh ra thành
những nhóm, với mỗi nhóm được liên kết với một phần nào đó của
nỗ lực (quan niệm, vấn đề, giải pháp, việc giải quyết vấn đề hay
thực hiện) tại bất kì điểm nào trong thời gian đã nêu. Mối liên kết
này có ý nghĩa khi các phần tử tri thức ảnh hưởng tới nỗ lực; tức là

499

Pha lặp

Giai đoạn
dừng

Pha phát
triển

Khởi đầu

500

Lập kế hoạch
Thực hiện
Kiểm soát

Kết thúc


Hình 1.3 Vòng đời
Vòng đời (Hình 1.3) có thể được chia ra như sau. Vòng đời là
tuyển tập các giai đoạn phân chia nỗ lực thành nhiều giai đoạn nỗ
lực, quản lí và kiểm soát được. Mỗi giai đoạn bên trong vòng đời
đều là phần rời rạc của một luồng logic duy nhất để giải quyết vấn
đề. Mỗi giai đoạn đều có cái vào, cái ra và đòi hỏi áp dụng các
nguyên tắc, kĩ thuật và công cụ lên các cái vào để sinh ra cái ra; có
tiêu chuẩn vào cho việc đưa vào hay khởi đầu giai đoạn; có tiêu

chuẩn ra để đi ra hay kết thúc giai đoạn này. Điều này làm nảy sinh
việc kiểm điểm sản phẩm có đạt chất lượng không và từ đó để ra
quyết định liệu có tiếp tục hay bỏ dở toàn bộ nỗ lực. Nhìn chung
người ta phân là ba giai đoạn: giai đoạn quan niệm, giai đoạn tiến
hoá và giai đoạn dừng.
Giai đoạn quan niệm bao gồm việc nhận ra vấn đề hay cơ hội
và cam kết giải quyết vấn đề.
Giai đoạn tiến hoá bao gồm nhiều chu kì tiến hoá từ việc khởi
đầu, lập kế hoạch, thực hiện, kiểm soát và kết thúc nỗ lực.
Giai đoạn dừng bao gồm việc nhận ra rằng một giải pháp
không còn được yêu cầu nữa và kết thúc việc áp dụng giải pháp
này theo một cách thức có trật tự.



Kiểm soát bao gồm việc điều phối và đo tiến trình sao cho các
biện pháp sửa đổi có thể được tiến hành khi cần.



Kết thúc bao gồm việc chính thức hoá chấp nhận chu kì hiện tại
và ra nghị quyết cho vấn đề để theo đó chu kì sau được khởi
đầu.

Giai đoạn tiến hoá bao gồm một hay nhiều chu kì phát triển (chu kì
tiến hoá), nơi từng chu kì phát triển lại bao gồm một nỗ lực được
phân phối giữa các cấu phần của chu kì phát triển. Nó bao gồm
việc tiến hoá của một sản phẩm khi nó trưởng thành và chín muồi
qua sự tồn tại của nó.

1.5.4 Chu kì và pha phát triển
Chu kì và pha phát triển (xem Hình 1.4) có đặc trưng: Mỗi chu
kì phát triển bao gồm bốn pha (khởi đầu, soạn thảo, xây dựng và
chuyển giao) và làm phát sinh ra một thế hệ sản phẩm. Góc nhìn
vòng đời này thường được gọi là viễn cảnh quản lí vì nó cung cấp
các chỉ báo mức cao về tiến độ dự án.

Quan
niệm

Riêng trong giai đoạn tiến hoá, các chu kì tiến hoá cụ thể của
nó là:


Khởi đầu bao gồm việc nhận ra rằng một chu kì tiến hoá là cần
trong việc đề cập tới vấn đề mới hay hiện có.



Lập kế hoạch bao gồm thiết kế và duy trì một sự sắp xếp để
thực hiện việc giải quyết vấn đề.



Thực hiện bao gồm việc phối hợp các nguồn tài nguyên để tiến
hành kế hoạch và giải quyết vấn đề.

499

Vấn đề

Khởi đầu

500

Giải quyết
Vấn đề

Soạn thảo

Giải pháp

Xây dựng

Chu kì phát triển

Thực
hiện

Chuyển giao

Thế hệ sản phẩm


chứng nền tảng cho giải pháp toàn thể (thiết kế kiến trúc), và
phân phối các yêu cầu trong các chu kì lặp của pha phát triển
xây dựng (lập kế hoạch)
Pha phát triển xây dựng (thực hiện) thường dùng nhiều chu kì
lặp và bao gồm các hoạt động sau:
Hình 1.4 Các pha phát triển bên trong chu kì phát triển

1. Cập nhật các trường hợp nghiệp vụ bằng việc quản lí các
rủi ro đang xảy ra và duy trì kế hoạch và lịch biểu.

Pha phát triển khởi đầu thường dùng một chu kì lặp và bao
gồm các hoạt động sau:

2. Xây dựng và phát triển các sản phẩm bằng việc thực hiện
nhiều chu kì lặp.

1. Xác định và định ra phạm vi giới hạn, các mục tiêu và các yêu
cầu.
2. Thiết lập một trường hợp hay luận cứ nghiệp vụ, bao gồm việc
xác định tầm nhìn, xác định các tiêu chuẩn thành công, định giá
các rủi ro, ước lượng thời gian và chi phí, và xác định kế
hoạch.
3. Hội tụ vào việc hiểu hay hình thành khái niệm về vấn đề và
luận cứ để giải quyết nó (định phạm vi và trường hợp nghiệp
vụ).

Pha này tập trung vào những điều sau:

Pha phát triển soạn thảo (lập kế hoạch) thường dùng một chu
kì lặp và bao gồm các hoạt động sau:
1. Soạn thảo đặc tả về nỗ lực từ pha trước đó.
2. Lập vạch ranh giới và phạm vi giới hạn đầy đủ, các mục tiêu và
yêu cầu.
3. Lập vạch ranh giới trường hợp nghiệp vụ bằng việc làm đông
cứng góc nhìn, đông cứng tiêu chuẩn thành công, và làm dịu
bớt rủi ro cao nhất. Lập vạch ranh giới kế hoạch với lịch biểu.

4. Phân phối các yêu cầu trong nhiều chu kì lặp bên trong pha xây
dựng.
5. Hội tụ vào việc hiểu hay hình thành một khái niệm về vấn đề
để xác định các yêu cầu mà vấn đề áp đặt lên giải pháp cho nó
(nắm bắt các yêu cầu và phân tích yêu cầu), thiết lập và kiểm
499



hiểu hay làm tiến hoá các yêu cầu mà vấn đề áp đặt lên giải
pháp của nó (các yêu cầu) sao cho vấn đề có thể được soạn
thảo và giải pháp có thể được xác định,



soạn thảo đặc tả giải pháp (phân tích),



cập nhật nền tảng cho giải pháp toàn thể (thiết kế kiến trúc)
và nền tảng cần để hỗ trợ cho giải pháp đặc biệt (thiết kế
chi tiết) đối với các yêu cầu chu kì lặp,



sinh ra giải pháp (cài đặt) cho các yêu cầu chu kì lặp,



kiểm chứng giải pháp (làm hợp lệ và tích hợp) theo các

yêu cầu chu kì lặp, và



đưa ra hay tích hợp (hay chuyển giao) giải pháp (triển
khai) hay tập con của cái đó.

Pha phát triển chuyển giao (đóng) thường dùng một chu kì lặp và
bao gồm các hoạt động sau:
1. Triển khai sản phẩm cuối cùng của nỗ lực hay giải pháp
cho vấn đề.

500


2. Định giá và phân loại các sản phẩm chuyển tiếp của nỗ
lực.



Mỗi chu kì lặp đều bao gồm hai cấu phần hỗ trợ (quản lí và hỗ
trợ) và sáu cấu phần phát triển (yêu cầu, phân tích, thiết kế,
thực hiện, làm hợp lệ và triển khai). Nó làm phát sinh ra việc
phát hành sản phầm. Cách nhìn vòng đời này thường được gọi
là viễn cảnh phát triển vì nó đưa ra những chỉ báo mức thấp về
tiến độ của dự án.



Pha quản lí (kiểm soát) bao gồm việc quản lí chu kì lặp tổng

thể.



Pha hỗ trợ (kiểm soát) bao gồm việc hỗ trợ cho nhu cầu và các
yêu cầu của người tham dự trong chu kì lặp; điều này bao gồm
hỗ trợ môi trường phát triển và lập cấu hình, định nghĩa chuẩn,
và các hướng dẫn.



Bên trong pha phát triển soạn thảo (lập kế hoạch), các pha lặp
sau đây được dùng tới:

3. Tập trung vào việc cung cấp và tích hợp hay chuyển giao
giải pháp (triển khai).

1.5.5 Chu kì và pha lặp
Chu kì và pha lặp (hình 1.5) có các đặc trưng sau:

Quan
niệm

Vấn đề

Yêu
cầu

Phân
tích

Giải quyết
Vấn đề

Thiết
kế

Thực
hiện

Giải pháp

Kiểm
chứng

Thực
hiện

Pha yêu cầu (nắm bắt yêu cầu) và phân tích (phân tích
yêu cầu) bao gồm việc hiểu hay hình thành một khái
niệm về vấn đề để xác định các yêu cầu của giải pháp
và phân phối các yêu cầu trong các chu kì lặp của pha
phát triển xây dựng (lập kế hoạch).

-

Pha thiết kế (thiết kế kiến trúc) bao gồm việc thiết lập
và kiểm chứng nền tảng cho giải pháp toàn thể.

Triển

khai

Cấu phần phát triển
Quản lí



Hỗ trợ
Cấu phần hỗ trợ
Chu kì phát triển

-

Bên trong pha phát triển xây dựng (thực hiện) các pha lặp sau
đây được áp dụng:
-

Thế hệ sản phẩm

-

Hình 1.5 : Tập trung vào pha lặp bên trong chu kì lặp
499

500

Pha yêu cầu bao gồm việc hiểu hay soạn thảo các yêu
cầu mà vấn đề áp đặt lên giải pháp của nó sao cho vấn
đề có thể được soạn thảo và giải pháp có thể được xác
định.

Pha phân tích bao gồm việc soạn thảo đặc tả giải pháp.
Pha này xoay quanh việc áp dụng tri thức.


-

-

Pha thiết kế bao gồm việc cập nhật nền tảng cho giải
pháp tổng thể (thiết kế kiến trúc) và nền tảng cần để hỗ
trợ cho giải pháp đặc thù (thiết kế chi tiết) cho các yêu
cầu chu kì lặp. Pha này xoay quanh việc áp dụng tri
thức.
Pha thực hiện bao gồm việc sinh ra giải pháp cho các
yêu cầu chu kì lặp.
Pha làm hợp lệ (và tích hợp) bao gồm việc kiểm chứng
giải pháp đối với các yêu cầu chu kì lặp.
Pha triển khai bao gồm việc cung cấp và tích hợp hay
chuyển giao giải pháp hay tập con của nó.

499

500


Phần 2
Các mô hình qui trình
phát triển phần mềm

biệt được gặp phải: hiện trạng, định nghĩa vấn đề, phát triển kĩ

thuật, và tích hợp giải pháp. Hiện trạng "biểu diễn cho trạng thái
hiện thời của sự việc"; định nghĩa vấn đề nhận diện vấn đề đặc biệt
cần giải quyết; phát triển kĩ thuật giải quyết vấn đề qua việc áp
dụng công nghệ nào đó, còn tích hợp giải pháp thì chuyển giao kết
quả (như tài liệu, chương trình, dữ liệu, chức năng nghiệp vụ mới,
sản phẩm mới) cho những người yêu cầu giải pháp. Các pha kĩ
nghệ phần mềm tổng quát và các bước dễ dàng được ánh xạ vào
các giai đoạn này.
Định
Định nghĩa
nghĩa
vấn
vấn đề
đề

Phát
Phát triển
triển
kĩ
kĩ thuật
thuật

Hiện
trạng

Tích
Tích hợp
hợp
giải
giải pháp

pháp

a

2.1 Mô hình tiến trình phần mềm
Để giải quyết các vấn đề thực tế trong khung cảnh công
nghiệp, người kĩ sư phần mềm hay một tổ các kĩ sư phải hợp nhất
vào một chiến lược phát triển bao quát cả các tầng tiến trình,
phương pháp và công cụ cùng các pha thực hiện tổng quát. Chiến
lược này thường được nói tới là mô hình tiến trình hay mô thức kĩ
nghệ phần mềm. Mô hình tiến trình cho kĩ nghệ phần mềm được
chọn lựa dựa trên bản chất của dự án và ứng dụng, phương pháp và
công cụ được dùng, và việc kiểm soát và việc chuyển giao được
yêu cầu.

Hiện
trạng

b

Mọi việc phát triển phần mềm đều có thể được đặc trưng như
chu trình giải quyết vấn đề (hình 2.1a) trong đó bốn giai đoạn phân
499

500


Hình 2.1 (a) Các pha của chu trình giải quyết vấn đề
và (b) Các pha bên trong chu trình giải quyết vấn đề
Chu trình giải quyết vấn đề này áp dụng cho công việc kĩ nghệ

phần mềm tại nhiều mức độ giải pháp khác nhau. Nó có thể được
dùng tại mức vĩ mô khi toàn bộ ứng dụng được xem xét, tại mức
trung khi cấu phần chương trình được đưa vào bố trí, và thậm chí
tới mức lập trình. Do đó cách biểu diễn lồng nhau có thể được
dùng để cung cấp một góc nhìn lí tưởng hoá về tiến trình. Trong
Hình 2.1b, mỗi giai đoạn trong chu trình giải quyết vấn đề lại chứa
một chu trình giải quyết vấn đề giống thế, rồi bên trong nó lại chứa
chu trình giải quyết vấn đề khác (điều này tiếp tục tới một biên giới
hợp lí nào đó; với phần mềm thì tới dòng mã lệnh).
Trong thực tế, khó mà đóng gói được thật rõ rệt như Hình 2.1b
bởi vì có những việc đan chéo bên trong và xuyên ngang các giai
đoạn. Vậy góc nhìn đơn giản hoá này dẫn tới một ý tưởng rất quan
trọng: bất kể tới mô hình tiến trình nào được chọn cho dự án phần
mềm, tất cả các giai đoạn - hiện trạng, định nghĩa vấn đề, phát triển
kĩ thuật và tích hợp giải pháp - đều cùng tồn tại đồng thời ở mức
độ chi tiết nào đó. Với bản chất đệ qui của Hình 2.1b bốn giai đoạn
được thảo luận ở trên được áp dụng như nhau cho việc phân tích
ứng dụng đầy đủ và cho việc sinh ra các đoạn mã nhỏ.

minh hoạ cho mô hình tuần tự tuyến tính cho kĩ nghệ phần mềm.
Được mô hình hoá theo chu kì kĩ nghệ qui ước, mô hình tuần tự
tuyến tính bao gồm các hoạt động sau:
Kĩ nghệ và mô hình hoá hệ thống/thông tin. Bởi vì phần mềm
bao giờ cũng là một phần của một hệ thống (hay nghiệp vụ) lớn
hơn nên công việc bắt đầu từ việc thiết lập yêu cầu cho mọi phần
tử hệ thống và rồi phân bổ một tập con các yêu cầu đó cho phần
mềm. Quan điểm hệ thống này là điều bản chất khi phần mềm phải
tương tác với các cấu phần khác như phần cứng, con người và
CSDL. Kĩ nghệ và phân tích hệ thống bao gồm việc thu thập yêu
cầu ở mức hệ thống với một lượng nhỏ thiết kế và phân tích mức

đỉnh. Kĩ nghệ thông tin bao gồm việc thu thập yêu cầu tại mức
nghiệp vụ chiến lược và tại mức lĩnh vực nghiệp vụ.

Kĩ nghệ hệ
thống/ thông tin
Phấn
Phấn
tích
tích

Trong mục sau đây nhiều mô hình tiến trình khác nhau về kĩ
nghệ phần mềm sẽ được thảo luận. Mỗi mô hình biểu diễn cho một
nỗ lực để đem trật tự vào một hoạt động mang tính hỗn loạn có
sẵn.

2.1.1 Mô hình tuần tự tuyến tính
Đôi khi còn được gọi là vòng đời cổ điển hay mô hình thác đổ,
mô hình tuần tự tuyến tính gợi ý một cách tiếp cận tuần tự, có hệ
thống tới việc phát triển phần mềm bắt đầu từ mức hệ thống và tiến
dần qua phân tích, thiết kế, mã hoá, kiểm thử và hỗ trợ. Hình 2.2
499

Thiết
Thiết
kế
kế

Lập
Lập
trình

trình

Kiểm
Kiểm
thử
thử

Vận
Vận
hành
hành

Hình 2.2 Mô hình tuần tự tuyến tính
Phân tích yêu cầu phần mềm. Tiến trình thu thập yêu cầu được
tăng cường và hội tụ đặc biệt vào phần mềm. Để hiểu được bản
chất của các chương trình phải xây dựng, kĩ sư phần mềm ("nhà
phân tích") phải hiểu về lĩnh vực thông tin đối với phần mềm cũng
như chức năng cần có, hành vi, hiệu năng và giao diện. Các yêu
500