Tài liệu Quản lý dự án phần mềm docx

Qu¶n lý dù ¸n phÇn mÒm
1
Quản lý dự án phần mềm
2
Mục lục
Lời nói đầu 6
Ch-ơng 1. Nhập môn về quản lý dự án phần mềm
Nhập môn
1.1. Nhu cầu đang gia tăng về phần mềm
1.2. Vai trò của việc quản lý trong phát triển phần mềm
1.3. Một thí dụ
1.4. Giành sự chấp nhận các thủ tục phát triển mới
1.5. Tóm tắt
10
10
11
13
15
17
Ch-ơng 2. Những vấn đề phát triển phần mềm
Một chút phòng xa
2.1. Những vấn đề cơ bản
2.1.1. Những vấn đề liên quan đến các yêu cầu của dự án
2.1.2. Những thay đổi th-ờng xuyên
2.1.3. Dự toán và những vấn đề liên quan
2.1.4. Nguồn lực bên ngoài
2.1.5. Kết thúc một dự án phần mềm
2.1.6. Tuyển dụng nhân viên và thuyên chuyển
2.1.7. Theo dõi và giám sát
2.2. Phân tích rủi ro
2.2.1. Dự kiến những vấn đề cần giải quyết

2.2.2. Pha phân tích
2.2.3. Thực hiện các kế hoạch đối phó bất ngờ
2.3. Tóm tắt
Bài tập
19
19
20
21
21
22
23
24
25
25
26
27
29
31
32
Ch-ơng 3. Phát triển phần mềm theo hợp đồng
Quan hệ khách hàng - nhà phát triển
3.1. Chi phí cộng thêm đối lại với giá cố định
3.1.1. Hợp đồng phí cộng thêm
3.1.2. Hợp đồng giá cố định
3.2. Các mối quan hệ khác gi-ã khách hàng - nhà phát triển
3.3. Yêu cầu đối với một đề xuất (RFP)
3.3.1. Một số vấn đề cơ bản
3.3.2. Chuẩn bị của RFP
3.3.3. Phát yêu cầu đề xuất RFP
3.4. Đề xuất

3.4.1. Đề xuất không do yêu cầu
3.4.2. Đề xuất khi có yêu cầu
3.4.3. Đội ngũ chuẩn bị đề xuất
3.4.4. Khuân dạng đề xuất
3.4.5. Khẳng định công việc (SOW)
3.5. Duyệt xét đề xuất và quá trình lựa chọn
3.5.1. Ban tuyển chọn đề xuất
33
33
34
36
37
38
39
39
42
43
43
44
44
45
48
49
49
Quản lý dự án phần mềm
3
3.5.2. Ph-ơng pháp đánh giá đề xuất
3.6. Một số nhận định bổ sung về đề xuất
3.6.1. Những vấn đề liên quan đến khách hàng
3.6.2. Những vấn đề liên quan đến ng-ời đề nghị

3.7. Tóm tắt
Bài tập
50
52
52
53
54
55
Ch-ơng 4. Chu trình phát triển phần mềm
Các biểu thái về chủ đề thác n-ớc
4.1. Pha quan niệm
4.1.1. Bàu không khí trong pha quan niệm
4.1.2. Những vấn đề trong pha quan niệm
4.2. Pha yêu cầu phần mềm
4.2.1. Bàu không khí trong quá trình pha yêu cầu
4.2.2. Các vấn đề trong pha yêu cầu
4.3. Pha thiết kế
4.3.1. Bàu không khí trong pha thiết kế
4.3.2. Những vấn đề trong pha thiết kế
4.4. Pha thực hiện
4.4.1. Bàu không khí trong pha thực hiện
4.4.2. Những vấn đề trong pha thực hiện
4.5. Pha tích hợp và thử nghiệm
4.5.1. Bàu không khí trong pha tích hợp và thử nghiệm
4.5.2. Những vấn đề trong pha tích hợp và thử nghiệm
4.6. Pha bảo trì
4.6.1. Bàu không khí trong pha bảo trì
4.6.2. Những vấn đề trong pha bảo trì
4.7. Tóm tắt
Bài tập

57
60
61
62
62
63
63
65
66
67
68
70
70
71
73
74
75
76
77
78
79
Ch-ơng 5. Nguyên tắc quản lý các kỹ s- phần mềm
Họ có thực có gì khác nhau không ?
5.1. Cơ cấu tổ chức dự án phần mềm
5.2. Cơ cấu đội ngũ
5.2.1. Lãnh đạo đội
5.2.2. Các đội dân chủ
5.2.3. Các đội kỹ s- tr-ởng
5.2.4. Các đội chuyên gia
5.3. Các kỹ thuật báo cáo cơ bản

5.3.1. Báo cáo tình hình
5.3.2. Các cuộc họp về tình hình dự án
5.4. Những đ-ờng lối chung trong quản lý các kỹ s- phần
mềm
5.5. Tóm tắt
Bài tập
80
81
85
85
87
87
88
89
90
91
92
94
95
Ch-ơng 6. Chia để trị các dự án lớn thế nào: phân chia và
chiếm lĩnh.
Quản lý dự án phần mềm
4
Nhu cầu lớn không có nghĩa khó
6.1. Tinh chế từng b-ớc một
6.1.1. Phân giải chức năng
6.1.2. Phân giải thiết kế
6.2. Cơ cấu phân tích công việc
6.2.1. Phân giải dự án
6.2.2. WBS làm công cụ quản lý dự án

6.3. Xử lý những dự án lớn
6.3.1. Các hệ thống phụ
6.3.2. Đ-ờng lối phân giải chức năng
6.3.3. Đ-ờng lối phân giải thiết kế
6.3.4. Đ-ờng lối phân giải nhiệm vụ công việc
6.4. Tóm tắt
Bài tập
96
96
98
99
102
103
105
106
106
108
109
110
111
112
Ch-ơng 7. Các chức năng hỗ trợ dự án
Hỗ trợ quản lý dự án
7.1. Kiểm tra cấu hình phần mềm (SCC)
7.1.1. Thuật ngữ kiểm tra cấu hình
7.1.2. Nguồn lực kiểm tra cấu hình
7.1.3. Kế hoạch quản lý cấu hình phần mềm
7.1.4. Một số đ-ờng lối chung
7.2. Bảo đảm chất l-ợng phần mềm (SQA)
7.2.1. Cung cấp phần mềm có chất l-ợng

7.2.2. Nguồn lực kiểm tra chất l-ợng
7.2.3. Kế hoạch bảo đảm chất l-ợng phầm mềm
7.2.4. Độ đo chất l-ợng phần mềm
7.2.5. Một số đ-ờng lối chung
7.3. Thử nghiệm phần mềm
7.3.1. Các loại thử nghiệm phần mềm
7.3.2. Các thủ tục thử nghiệm chính thức
7.3.3. Một số đ-ờng lối chung
7.4. Tóm tắt
Bài tập
115
116
118
119
121
123
126
126
128
130
132
133
134
135
137
138
139
140
Ch-ơng 8. Tiêu chuẩn phát triển phần mềm
Tiêu chuẩn phát triển: tai hại cần thiết

8.1. Tổng quan các tiêu chuẩn phát triển phần mềm
8.2. Tiêu chuẩn US DOD 2167
8.2.1. Tổng quan tiêu chuẩn 2167
8.2.2. Rà soát và kiểm toán
8.2.3. Mô tả hạng mục dữ liệu (DIDS)
8.2.4. Lấy kích th-ớc tiêu chuẩn
8.2.5. Lợi và bất lợi của tiêu chuẩn 2167
8.3. Các tiêu chuẩn công nghệ phần mềm IEEE
8.3.1. Tổng quan tiêu chuẩn IEEE
8.3.2. Phân loại IEEE về các tiêu chuẩn công nghệ phần
142
142
145
146
148
148
154
156
156
157
Quản lý dự án phần mềm
5
mềm
8.3.3. Lợi và bất lợi của tiêu chuẩn IEEE
8.3.4. So sánh các tiêu chuẩn IEEE và DOD
8.4. Các tiêu chuẩn Ada
8.4.1. Môi tr-ờng Ada
8.4.2. Tiêu chuẩn IEEE cho các Ada PDL
8.5. Các tiêu chuẩn phát triển phần mềm khác
8.6. Tóm tắt

Bài tập
159
159
164
164
165
165
166
167
168
Ch-ơng 9. Lập trình dự án
Lập trình: vấn đề
9.1. Kế hoạch phát triển dự án
9.2. Các hoạt động theo lập trình và mốc
9.2.1. Danh mục hoạt động theo lập trình
9.2.2. Các cột mốc và đ-ờng mốc chủ yếu
9.3. Các biểu đồ Gantt
9.4. Các biểu đồ PERT và con đ-ờng tới hạn
9.4.1. Đ-ờng tới hạn
9.4.2. Các khối ch-ơng trình PERT và việc tăng c-ờng
9.5. Nhân sự lập trình
9.5.1. Qui mô đội ngũ phát triển
9.5.2. Kỹ năng và kinh nghiệm
9.5.3. Tháng của con ng-ời bất nghì
9.6. Lập lịch các nguồn lực
9.6.1. Lập lịch không gian làm việc
9.6.2. Thiết bị lập trình
9.6.3. Chủ bán các nhà thầu phụ
9.7. Kiểm chứng và cập nhật ch-ơng trình
9.7.1. Báo cáo định kỳ

9.7.2. Các hoạt động kiểm chứng khác
9.7.3. Cập nhật ch-ơng trình
9.8. Một số đ-ờng lối chung cho việc lập trình và qui hoạch
9.8.1. Tinh lọc danh mục hoạt động ban đầu
9.8.2. Giành đ-ợc phê chuẩn ch-ơng trình
9.8.3. Mối quan hệ giữa ch-ơng trình, tài nguyên, chất
l-ợng và tính chức năng
9.9. Tóm tắt
Bài tập
170
171
173
174
176
177
180
182
182
183
184
187
188
189
189
190
191
192
192
193
193

194
194
195
197
198
199
Ch-ơng 10. Chuẩn bị dự toán: ph-ơng pháp và kỹ thuật
Dự toán: vấn đề
10.1. Dự toán dự án
10.2. Dự toán từng b-ớc
10.2.1. Những thành phần đ-a khỏi giá
10.2.2. Những thành phần d- thừa kinh nghiệm
10.2.3. Những thành phần có một phần kinh nghiệm
200
201
202
203
203
205
Quản lý dự án phần mềm
6
10.2.4. Phát triển mới
10.2.5. Phân tích chi tiết dự án ở mức rủi ro
10.3. Uớc định phát triển mới
10.3.1. Những ph-ơng pháp kiểu đầu (nguyên mẫu)
10.3.2. Những ph-ơng pháp thống kê
10.4. Mô hình chi phí xây dựng (Cocomo)
10.4.1. Mức nhân sự
10.4.2. Mức độ phức tạp
10.4.3. Yếu tố độ tin cậy

10.4.4. Môi tr-ờng phát triển
10.4.5. Các thứ hệ
10.4.6. Thuật toán dự toán phí
10.5. Chức năng phân tích điểm
10.5.1. Những b-ớc FPA cơ bản
10.5.2. ứng dụng của FPA
10.6. Dự toán là một lĩnh vực
10.7. Dự toán tài nguyên phần cứng
10.7.1.Tải trọng CPU
10.7.2. L-u trữ dự liệu
10.7.3. Tốc độ
10.8. Tổng phí không phát triển
10.9. Tóm tắt
Bài tập
206
206
207
207
209
210
210
213
215
216
218
219
221
221
224
225

229
229
233
236
238
239
241
Tham khảo 243
Tài liệu đọc thêm
Lời nói đầu
Quản lý dự án phần mềm
7
Đây là cuốn sách về quản lý dự án phần mềm; nó không phải là một
cuốn sách tiếp nữa về công trình phần mềm. Đã có nhiều cuốn sách tham
khảo về công trình phần mềm (coi danh mục tham khảo ở cuối cuốn sách
này). Mục tiêu của sách này là trình bày công việc phát triển phần mềm
theo quan điểm của nhà quản lý chứ không phải theo quan điểm của nhà
phát triển.
Cuốn sách tập trung, trong một cuốn duy nhất nhiều thực tiễn và kỹ
thuật quản lý phần mềm hiện đại đã đ-ợc phát triển và tinh lọc trong suốt
thập kỷ qua. Quản lý dự án đ-ợc trình bày nh- là một kỹ năng lĩnh hội
đ-ợc và chứ không phải nh- là của trời cho. Chắc chắn, việc quản lý dự
án đòi hỏi tài năng quản lý, nh-ng bản thân tài năng không đ-ợc hữu
hiệu. Việc vận dụng thiết thực các thủ tục phát triển phần mềm hiện đại
đòi hỏi có các nhà quản lý chuyên nghiệp.
Vì đây là cuốn sách thực hành (chứ không phải là một công trình lý
thuyết) nên nhiều ph-ơng pháp và kỹ thuật đ-ợc mô tả không có cơ sở lý
thuyết cho riêng nó. Tuy nhiên những tham khảo sẽ đ-ợc cung cấp suốt
cuốn sách dành cho những ai quan tâm đến cơ sở lý thuyết. Danh mục
kèm các tham khảo và tài liệu để đọc đ-ợc gợi ý có ở cuối cuốn sách

này.
Nhất thời, độc giả có thể thấy một số đoạn đ-ợc nhắc lại trong cuốn
sách này. Sở dĩ có điều này là để giải quyết cái th-ờng đ-ợc gọi là tình
huống năm ngón tay. Điều này xảy ra khi mỗi năm ngón tay của độc giả
cần đ-ợc cài vào cuốn sách để đánh dấu trong khi độc giả l-ỡng lự giữa
các ch-ơng nhằm bao quát đ-ợc một chủ đề đặc biệt. Cuốn sách này có
giảm nhu cầu phải đánh dấu bằng cách lặp lại cái giải thích vắn tắt bất cứ
chủ đề chủ yếu nào đ-ợc tham chiếu ngay dù chủ đề đã đ-ợc thảo luận
chi tiết ở đâu đó.
Suốt cuốn sách những hạng mục tháng công và năm công đã đ-ợc sử
dụng thay cho các hạng mục cũ tháng ng-ời và năm ng-ời. Những từ này
đ-ợc thảo luận chi tiết ở phần 9.5.3.
Đối t-ợng đọc đ-ợc chủ định.
Quản lý dữ án phần mềm: Một tiếp cận cho ng-ời thực hành đ-ợc chủ
định cho đối t-ợng đa dạng. Tr-ớc hết và chủ yếu sách đ-ọc chủ định
làm nguồn tham khảo cho các nhà quản lý dự án phần mềm đang thực thi
nhiệm vụ quản lý và trên cơ sở đó nó đ-ợc sắp xếp sao cho đề tài chủ yếu
bao quát ở mỗi ch-ơng (trừ ch-ơng 1). Điều này đ-ợc thảo luận thêm
trong giải thích sau về việc bố trí nội dung sách.
Cuối cùng, cuốn sách có thể dùng làm tham khảo cho các kỹ s- phần
mềm muốn mở rộng kiến thức của minh sang những lĩnh vực quản lý dự
án kỹ thuật.
Bố trí của cuốn sách
Quản lý dự án phần mềm
8
Nói chung, m-ời ch-ơng của cuốn sách xuất hiện theo trình tự lôgíc và
cung cấp cho việc đi đầu vào lĩnh vực quản lý dự án phần mềm. Tham
khảo nhanh đặt ở cuối mỗi ch-ơng có dạng tóm tắt mở rộng. Tóm tắt này
nhằm đ-ợc sử dụng nh- là để ghi nhớ lần nữa hay nh- là một nguồn
thông tin ban đầu.

Ng-ời đọc đ-ợc yêu cầu tìm cách làm một số bài tập ở cuối mỗi
ch-ơng. Các bài tập này sẽ giúp ng-ời đọc hiểu đ-ợc nhiều ý t-ởng và kỹ
thuật trình bày trong ch-ơng đó.
Ch-ơng 1 đề cập quan niệm quản lý dự án phần mềm. Ch-ơng này
cũng tham luận nhiều khó khăn mà các nhà quản lý dự án gặp trong việc
giành hỗ trợ của bộ phận quản lý cấp trên để trình ra những thủ tục phát
triển mới.
Ch-ơng 2 tóm tắt vắn tắt nhiều vấn đề phát triển phần mềm chung
nhất (sau này đ-ợc xây dựng trong suốt cuốn sách). Ch-ơng này đ-ợc
chia làm 2 phần. Phần đầu giành cho độc giả không quen với những vấn
đề cơ bản về quản lý phần mềm. Phần hai giành cho những ngành đang
quản lý dự án cả mới và cả đã có kinh nghiệm. Phần này thảo luận
ph-ơng pháp đấu tranh với những vấn đề đã thảo luận tr-ớc đây, gọi là
phân tích rủi ro.
Các nhà quản lý dự án có kinh nghiệm có thể bỏ qua ch-ơng 1 và phần
đầu của ch-ơng 2.
Ch-ơng 3 thảo luận việc phát triển phần mềm theo hợp đồng. Ch-ơng
này mô tả các hợp đồng dự án phần mềm đ-ợc tiến hành nh- thể nào, các
đề nghị ra sao. Một văn bản đề nghị nên đ-ợc xây dựng thể nào và nên
thiết lập thế nào và những mối quan hệ giữa khách hàng và nhà sản xuất.
Ch-ơng này cũng mô tả các yêu cầu về văn bản đề nghị (RFP) và quá
trình lựa chọn sau khi các đề nghị đã đ-ợc đệ trình.
Ch-ơng 4 mô tả chu trình cơ bản phát triển phần mềm, nhấn mạnh đến
việc tiếp cận theo giai đoạn, phát triển phần mềm. Những ph-ơng pháp
luận khác cũng đ-ợc thảo luận (nh- là tạo mẫu nhanh và mô hình xoắn ốc
- Spiral). Những giai đoạn cơ bản đ-ợc mô tả theo quan điểm của ng-ời
quản lý dự án nhấn mạnh đến không khí và những vấn đè của mỗi giai
đoạn.
Ch-ơng 5 trình bày một số những nguyên tắc cơ bản của việc quản lý
con ng-ời. Ch-ơng này lựa ra một số những mặt đặc thù liên quan đến

việc quản lý các kỹ s- phần mềm, chẳng hạn nh- sự khác nhau đáng kể
về năng suất giữa các kỹ s- phần mềm và tính khí phong độ của các nhà
lập trình nói chung.
Ch-ơng 6 đề cập một trong những vấn đề khó khăn nhất của phát triển
phần mềm: làm sao quản lý đ-ợc những dự án phần mềm lớn. Ch-ơng
này giải thích những dự án lớn có thể đ-ợc phần chia thành những bộ
phận nhỏ dễ quản lý nh- thế nào theo ph-ơng châm chia ra chế ngự.
Quản lý dự án phần mềm
9
Ch-ơng 7 mô tả ba trong những chức năng hỗ trợ quản lý cơ bản:
kiểm tra cấu hình đảm bảo chất l-ợng và thử nghiệm phần mềm. Ch-ơng
này cũng thảo luận mối quan hệ giữa những chức năng đó.
Ch-ơng 8 trình bày tổng quan về các chuẩn phát triển phần mềm. Đặc
biệt hai chuẩn đ-ợc thảo luận chi tiết: chuẩn 2167 của Bộ Quốc phòng
Hoa Kỳ (DOD) và chuẩn IEEE về phát triển phần mềm. Những chuẩn
khác, nh- chuẩn phát triển phần mềm của Anh và Châu Âu, cũng đ-ợc
nhắc tới và so sánh.
Ch-ơng 9 thảo luận việc lập lịch và kế hoạch phát triển dự án (PDP) và
kỹ thuật lập lịch và lập kế hoạch đ-ợc mô tả, kể cả phác đồ Gantt và
PERR cổ điển và cấu trúc phá hủy công việc (WBS).
Ch-ơng 10 chứa một mô tả tăng c-ờng và chi tiết của một vài ph-ơng
pháp và kỹ thuật chuẩn bị dự toán. Ch-ơng này gồm những ph-ơng pháp
dự tính qui mô của dự án và lịch phát triển dự án cũng nh- dự toán kỹ
thuật, chẳng hạn nh- các yêu cầu về đĩa và về bộ nhớ. Ch-ơng này cũng
giải thích kinh nghiệm có thể đ-ợc sử dụng thế nào để cải tiến dự toán và
mô tả các dự toán có thể đ-ợc hoàn thiện thế nào trong quá trình phát
triển dự án tiến triển.
Tri ân
Các tiêu chuẩn DOD-STD 2167a và DOD-STD 2168 và các mô tả hạng
mục dự liệu liên quan của Bộ Quốc phòng Hoa Kỳ đã đ-ợc tham chiếu và

trích dẫn đ-ợc phép của Bộ Quốc phòng Hoa Kỳ, Bộ chỉ huy các hệ
thống chiến tranh không gian và trên biển.
Các tiêu chuẩn công nghệ phần mềm IEEE đã đ-ợc tham chiếu và
những tài liệu sau đây đã đ-ợc trích dẫn đ-ợc phép của Viện tập đoàn kỹ
s- điện và điện tử (IEEE).
Phần nhập môn của F.Buckley cho bản in 1984 của IEEE về tiểu chuẩn
công nghệ phần mềm IEEE.
Phần nhập môn của J.Horch cho bản in 1987 của IEEE về tiểu chuẩn
công nghệ phần mềm.
IEEE stel 729 - 1983 IEEE stel 1022 - 1987
IEEE stel 830 - 1984 IEEE stel 990 - 1986
Giữ bản quyền mọi mặt @ Viện tập đoàn kỹ s- điện và điện tử.
Tôi xin cảm ơn về sự giúp đỡ to lớn của Amir trong việc duyệt và tập
hợp văn bản. Tôi cũng biết ơn về nhiều gợi ý có ích của Ông.
Tôi cũng xin cảm ơn Sharon và Talya đã không xáo trộn bản thảo văn
bản.
Cuối cũng và quan trọng nhất, tôi xin hết sức cảm ơn động viên của
Iril, nếu không văn bản đã chẳng bao giờ đ-ợc viết ra.
Nhãn hiệu th-ơng mại
Ada là nhãn hiệu đã đăng ký của Chính phủ Hoa Kỳ, Ada AJPO
UNIX là th-ơng nhãn của tập đoàn điện thoại và điện báo Mỹ
VMS là th-ơng nhãn của tập đoàn thiết bị số
Quản lý dự án phần mềm
10
MS-DOS là th-ơng nhãn của tập đoàn Microsoft
PC-DOS là th-ơng nhãn của tập đoàn máy móc kinh doanh quốc tế
BYB là th-ơng nhãn của nhóm Gordon.
Quản lý dự án phần mềm
11
Ch-ơng một

Nhập môn về quản lý dự án phần mềm
Nhập môn
Phần mềm là nơi trồng các giấc mơ và thu hái ác mộng một thế giới
những ng-ời hóa sói và những viên đạn bằng bạc Trích dẫn này từ Brad
cox (cox 1990) nhấn mạnh những quan tâm của các nhà quản lý dự án
phần mềm hôm nay. Làm sao có thể kiểm tra đ-ợc con ng-ời hóa sói này
d-ới chi tiết công nghệ phần mềm đây ? Liệu việc phát triển phần mềm
có thật sự là một bộ phận công trình không ?
Việc phát triển phần mềm có thể kiểm tra đ-ợc. Có những ph-ơng
pháp những kỹ thuật nh-ng chuẩn và những công cụ khi đ-ợc vận dụng
đúng đắn chúng sẽ thúc đẩy sự phát triển thắng lợi của dự án phần mềm.
Đó không phải là những viên đạn bằng bạc xuyên qua trái tim của ng-ời
hóa sói: chẳng có gì giữ thật ở trong cả. Những ph-ơng pháp này cung
cấp một cách tiếp cận có hệ thống tới sự phát triển phần mềm bắt đầu là
những giai đoạn qui hoạch ban đầu và kết thúc là việc cung cấp sản phẩm
phần mềm cuối cùng.
Cuốn sách này đề cập đến việc vận dụng những ph-ơng pháp hiện đại
để quản lý các dự án phần mềm. Sách trình bày tiếp cận thực hành làm
thế nào đây hơn là tiếp cận lý thuyết mặc dù có những tham khảo rộng
rãi cho những ai quan tâm đến việc mô tả lý thuyết đằng sau các ph-ơng
pháp. Mục tiêu chủ yếu là tập trung, trong chỉ một cuốn sách, mô tả biết
bao công cụ và qui trình dính líu đến những hoạt động quản lý phần mềm
nh-:
Dự toán chi tiết dự án
Chuẩn bị các lịch trình phát triển
Vận dụng các tiêu chuẩn phát triên thiết thực
Chuẩn bị và đánh giá các đề nghị
Nhà quản lý dự án phần mềm theo thế đ-ợc cung cấp các ph-ơng pháp
và qui tình cần thiết khiến cho việc phát triển phần mềm có hiệu quả hơn
với ba mục tiêu nổi tiếng trong tâm t-ởng: phát triển phần mềm

1. theo ch-ơng trình
2. trong phạm vi ngân sách
3. theo yêu cầu
1.1. Nhu cầu đang gia tăng về phần mềm
Thật có ít lĩnh vực công nghệ hiện đại lại không chứa phần mềm. Điều
này bao gồm xe hơi, hàng không và vệ tinh cũng nh- thang máy, máy
fax, truyền hình và các cơ quan điện tử. Phần mềm vận hành hệ thống an
ninh xã hội, hệ thống chi l-ơng tập đoàn, và trái của nền kinh tế ph-ơng
Quản lý dự án phần mềm
12
Tây - Hệ thống thẻ tín dụng. Phần mềm đ-ợc sử dụng rộng rãi để viết và
in sách.
Việc gia tăng nhu cầu về phần mềm đã trở nên một vấn đề gay cấn. Nó
đã gây ra việc gia tăng nhu cầu về kỹ s- phần mềm. V-ợt rất xa mức độ
các nhà chuyên nghiệp phần mềm tốt nghiệp ở các tr-ờng đại học. Do
đấy sự phát triển phần mềm đ-ợc yêu cầu có năng suất cao lợi hơn, tin
cậy hơn và nói chung thành công hơn.
Những yêu cầu mới đó có thể không đ-ợc đáp ứng ở những ph-ơng
pháp phát triển thô thiển của những ngày đầu của máy vi tính.
Những ph-ơng pháp mới đã đ-ợc đề xuất cải tiến đáng kể con đ-ờng
mà phần mềm đ-ợc phát triển. Tính nghiêm trọng của vấn đề đã đ-ợc
thừa nhận trong khắp cộng đồng công nghệ phần mềm. Một số các liên
công ti và công xoexiom quốc tế đã đ-ợc thành lập ở Hoa Kỳ, Nhật Bản
và Châu Âu với những ngân sách to lớn dành cho việc tìm kiếm những
ph-ơng pháp giảm nhẹ (nếu không phải là loại trừ) vấn đề (coi Bennatan
1987).
Cox (1990), trong một phân tích ph-ơng h-ớng công trình phần mềm
sẽ tiến hành cho thấy rõ một cuộc cách mạng công nghiệp phần mềm lý
thú, ông đã tiên đoán ngày mà các nhà lập trình sẽ thôi không mã hóa
mọi thứ khi xóa và sẽ ghép các ứng dụng trừ những catalô l-u trữ tốt của

các thành phần phần mềm sử dụng lại đ-ợc. Quan niệm này và những
quan niệm cách mạng khác nh- phát triển phần mềm tự động (coi
Frankel 1985) vẫn còn phải mất quãng đ-ờng dài tr-ớc khi trở thành
những ph-ơng tiện thiết thực của phát triển phần mềm.
Xu h-ớng tiến tới công trình phần mềm có máy tính hỗ trợ (CASE) đã
tạo nên nhiều công cụ phát triển tự động nh-ng chẳng may thay những
công cụ đó
1
th-ờng mất nhiều thời gian không xứng với chúng, ở những
lĩnh vực khác của công nghệ các hệ CAD/CAM
2
tự động đã đang đ-ợc sử
dụng để thiết kế và xây dựng các thành phần điện tử nh-ng phát triển
phần mềm vẫn còn hoàn toàn là một cố gắng thủ công.
Cho đến lúc mà phần mềm sử dụng lại và phát triển phần mềm tái tạo
và tự động bắt đầu thay thế đ-ợc các kỹ s- phần mềm thì phần mềm vẫn
còn tiếp tục do con ng-ời phát triển. Trong khi chờ đợi việc gia tăng theo
yêu cầu về năng suất và thuần thục tay nghề và thắng lợi chung của phát
triển phần mềm phải duy trì trách nhiệm vẫn phải là ở nhà quản lý dự án
phần mềm.
1.2. Vai trò của việc quản lý trong phát triển
phần mềm.
Việc quản lý dự án có hiệu quả đòi hỏi nhiều tài năng và kỹ xảo. Tiêu
chuẩn IEEE (IEEE 1987a) cho dịch nghĩa sau về quản lý dự án phần
mềm.
1
Xem Tahvanainen và Smolander An annotated CASE Bibliography (1990)
2
CAD và CAM là thiết kế có máy tính trợ giúp và chế tạo có máy tính trợ giúp.
Quản lý dự án phần mềm

13
Quản lý dự án phần mềm là quá trình qui hoạch, tổ chức, nhân sự điều
khiển, kiểm tra và lãnh đạo dự án phần mềm. Rõ ràng để trở thành nhà
quản lý dự án phần mềm tốt thì là nhà phát triển phần mềm tốt không còn
đủ nữa. Có những kỹ xảo quản lý đặc biệt đ-ợc yêu cẩu- dụng ngay từ
những giai đoạn đầu của dự án, chằng hạn nh- ở các lĩnh vực nh-:
- Giám sát và kiểm tra
Điều này bao gồm việc quản lý có hiệu quả các thành viên đội ngũ
phát triển và đòi hỏi ý thức th-ờng xuyên về tình trạng thực của công việc
của họ về dự án.
- Qui hoạch
Qui hoạch là một trong những hoạt động quản lý quan trọng nhất và
bao gồm việc chuẩn bị dự toán tốt, duy trì lịch trình phát triển và bố trí
nhân sự hiệu quả.
- Quan hệ khách hàng
Trong một số dự án, việc tiếp xúc với khách hàng là hoạt động quản lý
chủ yếu. Điều này bao gồm viết tài liệu về yêu cầu của khách hàng,
khống chế những thay đổi do khách hàng, sử lý việc tham gia của khách
hàng vào quá trình phát triển, cung cấp báo cáo và tổ chức xét duyệt cùng
trình diễn sản phẩm.
- Vai trò lãnh đạo kỹ thuật
Lãnh đạo kỹ thuật tốt th-ờng là một phẩm chất ao -ớc trong việc quản
lý phần mềm có hiệu quả. Điều này th-ờng đòi hỏi khả năng cung cấp chỉ
đạo trong giải pháp của các vấn đề kỹ thuật phát sinh trong quá trình phát
triển dự án. Điều này không cần thiết có nghĩa là dự trữ chung bản thân
một giải pháp đích thực.
Những lĩnh vực quản lý này là vận dụng đ-ợc cho mọi thể loại dự án
Công nghệ cao. Dù sao việc quản lý dự án phần mềm lại khó khăn hơn do
sự thể là phát triển phần mềm ít có tính xác định hơn các lĩnh vực công
nghệ khác. Điều này là do những dự án phần mềm ít đo l-ờng đ-ợc khó

dự toán hơn và phụ thuộc nhiều hơn vào những nhân tố chủ quan của con
ng-ời.
Lịch sử phát triển phần mềm đầy rẫy những tr-ờng hợp mà mức độ
nguồn lực đ-ợc yêu cầu đã đ-ợc qui hoạch và dự toán tốt. Phát triển phần
mềm đã từ lâu đ-ợc nhận định là doanh nghiệp đầy rủi ro. Đã có nhiều
tr-ờng hợp các dự án phần mềm v-ợt quá ngân sách ban đầu của chúng
tới hai, ba hay thậm chí bồn trăm phần trăm. Một số đã phải bỏ bễ sau khi
đã chi hết vốn cơ bản khi thấy rõ là dự toán ngân sách ban đầu không chỗ
nào sát với chi phí phát triển thực sự.
Trong những năm gần đây, đã có ý đồ tiêu chuẩn hoá qui trình phát
triển phần mềm và tạo ra môi tr-ờng phát triển nghiêm ngặt trong đó các
dự án phần mềm dễ dự toán và kiểm tra hơn. Dù sao, điều này đã dẫn đến
một vấn đề mới các nhà sản xuất đã phàn nàn phải mất quá nhiều thời
gian vào việc thiết lập t- liệu và quá ít cho xu h-ớng phát triển hiện nay.
Rõ ràng là cần tìm đ-ợc địa bàn trung độ giữa hai thái cực trong dự án
không có thể lập trình và dự toán và dự án tiêu chaủan quá mức, thu thập
Quản lý dự án phần mềm
14
t- liệu quá mức trong đó chi công sức quá đáng vào tổng phí và công việc
giấy tờ.
Khi phát triển phần mềm bắt đầu dĩnh dáng đến một bộ môin công
trình thì những ph-ơng pháp luận phát triển một cách có hệ thống mới
cũng bắt đầu xuất hiện
3
. Mục đích của những ph-ơng pháp luận mới đó là
làm cho sự phát triển phần mềm thành công hơn. Nếu thắng lợi đ-ợc do
theo mức độ của ba mục tiêu nói tr-ớc đây (theo lịch trình, trong phạm vi
ngân sách, theo yêu cầu) thì sự thất bại hẳn có nghĩa là trong việc hoàn
thành thậm chí một trong những mục tiêu đó. Dù sao, thành công và thất
bại không phải là cái điều đ-ợc định nghĩa một cách dễ dàng.

Đã có nhiều nghiên cứu cho thấy là thất bại của dự án cũng là một vấn
đề của nhận thức (cos Linto và mantel 1990). Một dự án có thể đ-ợc nhận
định là thất bại ở một môi tr-ờng trong khi ở môi tr-ờng khác dự án lại
có thể đ-ợc nhận định là thắng lợi. Nói một cách đơn giản, một khách
hàng có thể hài lòng với đầu ra của một dự án trong khi ng-ời khách khác
lại không. Theo thế thành công hay thất bại của một dự án không chỉ liên
quan đến ba mục tiêu phát triển cơ bản mà cả đến kỳ vọng của khách
hàng.
Sự không rõ ràng của quan niệm thất bại của dự án chắc chẵn có thể
tránh đ-ợc nếu chỉ đặt ra một đích duy nhất. Đây là đích mà khách hàng
đặt ra chứ không phải đội ngũ phát triển đặt ra. Điều đó có nghĩa là:
Thành công hay thất bại của một dự án đ-ợc tối hậu xác định ở sự hài
lòng của bên yêu cầu phát triển (nghĩa là khách hàng) Những quan niệm
đó đ-ợc chứng minh trong thí dụ sau:
1.3. Một thí dụ:
Thí dụ này cho thấy vài sai lầm quản lý thông th-ờng mà nó có thể
cuối cùng dẫn đến thất bại của một dự án phần mềm. Dự án khởi sự với
vài quyết định sai lầm cơ bản liên quan đến việc khởi hành dự án, đến
l-ợt nó, nó lại dẫn đến nhiều quyết định sai lầm hơn khi dự án tiến triển.
Công ty liên kết công nghệ (TAI) là một công ty chuyên môn hóa
trong việc phát triển và chế tạo thiết bị truyền thông. TAI là một ban phần
mềm lớn chịu trách nhiệm về sự phát triển phần mềm cho thiết bị truyền
thông. Ng-ời quản lý ban phần mềm đã đ-ợc biết là quản lý công ty đang
tìm kiếm một công ty phần mềm bền ngoài để phát triển một hệ thống
bảo d-ỡng và thời gian cho TAI.
Ban phần mềm của TAI đã chủ động nắm bắt ý kiến, chuẩn bị một đề
nghị phát triển hệ thống và đệ trình quản lý công ty. Căn cứ ở đề nghị này
hai tháng đ-ợc giành tham khảo ý kiến của ban nhân sự, ban tài chính và
tr-ởng ban để xác định các yêu cầu của hệ thống. Đội ngũ phát triển sau
đó phát triển hệ thống trong 6 tháng sau đó (toàn bộ thời gian phát triển

3
Xem Shaw (1990) về một thảo luận đầy đủ trên vấn đề tiến hoá của phần mềm trong bộ môn công
trình học.
Quản lý dự án phần mềm
15
kể ra phải là 8 tháng). Ban phần mềm dự tính cần đội ngũ 4 ng-ời để
cung cấp các yêu cầu và phát triển hệ thống.
ý kiến sử dụng một công ty phần mềm bên ngoài đ-ợc gác lại và đề
nghị của ban phần mềm đ-ợc quản lý công ty chấp nhận. Ngân sách phát
triển đ-ợc thông qua để đáp ứng 2 năm r-ỡi nhân công hay 4 ng-ời trong
8 tháng. Ban phần mềm tiến hành lập đội ngũ dự án và chọn một ng-ời
quản lý dự án, trong số các ng-ời quản lý dự án truyền thông để lãnh đạo
đội ngũ này.
Khi cuối đợt hai tháng ban đầu gần kề, nhà quản lý dự án thấy rõ là
phải cần nhiều thời gian hơn để xác định và viết t- liệu về các yêu cầu.
Ph-ơng án chọn lựa của nhà quản lý dự án là:
1. Hoặc là yêu cầu nói rộng thời gian và bổ sung ngân sách phát triển
2. Hoặc là sử dụng một phần những yêu cầu hiện có.
Ng-ời quản lý ban muốn chứng minh là ban của mình có khả năng
phát triển cả các hệ thông tin và phần mềm truyền thông đ-ợc lồng vào.
Do đó ng-ời quản lý dự án và đội ngũ đã thúc chọn ph-ơng án 2. Điều
này dựa trên tiền đề là nếu dự án bị chậm và v-ợt quá ngân sách thì dự án
phải bị coi là thất bại và các hệ thống thông tin sau này hẳn sẽ phải đ-ợc
hợp đồng với một công ty phần mềm bền ngoài.
Tất cả các ban khác thấy có nhiều vấn đề chủ yếu của hệ thống. Nói
tóm lại hệ thống thiếu cái mà công ty cần.
Ban phần mềm đề nghị sửa chữa các sai sót và yêu cầu ngân sách cho
việc phát triển một version cải tiến mới. Dù sao, sự bất bình đã đến mức
mà quản lý công ty quyết định đ-a việc phát triển một hệ thống hòan
toàn mới cho một công ty phần mềm bền ngoài. Công ty phần mềm đ-ợc

lựa chọn phát triển thành công hệ thống. Ngạc nhiên là lần này kinh phí
lại ít hơn là ngân sách mà ban phần mềm TAI yeue cầu để sửa chữa các
sai sót trong hệ thống ban đầu.
Thí dụ (có thật) này thuyết minh một số sai lầm chủ yếu trong quản lý
dự án.
- Kinh nghiệm trong một lĩnh vực phần mềm (các hệ viễn thông đ-ợc
lồng vao) khong đủ cho việc phát triển thành công phần mềm ở một lĩnh
vực hoàn toàn khác (hệ thông tin).
- Nhà quản lý dự án nêu trách nhiệm cam kết vào lịch trình phát triển
hay ngân sách tr-ớc khi dự án đ-ợc xác định đủ. Trong phần lớn tr-ờng
hợp cam kết của công ty chỉ có thể có khi các yêu cầu đã đ-ợc kết luận.
- Nếu yêu cầu của một dự án không đ-ợc đáp ứng thì việc tham gia vào
lịch trình và ngân sách trở lên vô nghĩa.
- Khách hàng hay ng-ời dùng sẽ không phải bao giờ cũng cung cấp
đ-ợc những yêu cầu đúng (thí dụ chủ yếu giao liên ban). Th-ờng là trách
nhiệm của ng-ời sản xuất phải hỏi những câu hỏi thích đáng nhằm thu
thập thông tin cần thiết.
- Đôi khi tốt nhất là nên phát triển một hệ thống mới bằng việc xóa bỏ
còn hơn là tìm cách cứu vãn một hệ thống đã đ-ợc phát triển tồi.
Quản lý dự án phần mềm
16
1.4. Giành sự chấp nhận các thủ tục phát triển
mới.
Một trong những trở ngại mà các nhà quản lý dự án th-ờng phải khắc
phục là tình trạng thiếu hỗ trợ ở quản lý cấp cao hơn đối với những
ph-ơng pháp phát triển hiện đại. Vận dụng các ph-ơng pháp luận hiệu
quả không dễ khi quản lý cấp cao hơn còn tranh luận về nhu cầu của họ.
Điều này dẫn đến các nhà quản lý dự án đến một tình trạng tiến thoái
l-ỡng nam, làm sao chấp nhận đ-ợc cái mà họ tin là tốt nhất trong khi
vẫn giữ đ-ợc c-ơng vị nhà quản lý dự án.

Rõ ràng là nhiều ph-ơng pháp và kỹ thuật đ-ợc mô tả trong cuốn sách
này chỉ có hiệu lực khi chúng đ-ợc sử dụng. Mục tiêu của phần này là
giúp nhà quản lý dự án giành đ-ợc sự chấp nhận ở quản lý cấp cao hơn
trong việc ứng dụng những ph-ơng pháp mới.
Quản lý cấp cao hơn (và đôi khi là các kỹ s- phần mềm khác) có khi
dùng những lập luận sau chống lại việc sử dụng các ph-ơng pháp luận
phát triển phần mềm hiện đại.
1. Những ph-ơng pháp mới này đều là lý thuyết trong thế giới thực
sự việc diễn ra khác.
2. Những nhà quản lý dự án quá hình thức chủ nghĩa; họ đòi hỏi mọi
thứ bằng văn bản và không đồng ý về mọi thay đổi nhỏ.
3. Chúng ta không có thì giờ cho mọi công việc giấy tờ đó.
4. Chúng ta không thể mất công sức về sự xa phí trong mọi qui trình
dài dặc đó. Chúng ta vẫn luôn phát triển đ-ợc phần mềm mà chẳng cần
những tổng phí đó.
5. Đây là kinh doanh chứ không phải tr-ờng đại học. Chúng ta mất tiền
và mất khách nều chúng ta bắt đầu với việc lãng phí thời gian vào mọi
ph-ơng pháp đó.
6. Ph-ơng pháp là tốt, nh-ng bất hạnh là bây giờ không phải lúc thực
hiện chúng. Chúng ta mong rằng có thể sử dụng chúng một ngày nào đó
nh-ng không phải đúng lúc này.
7. không có kỹ s- nào của chúng ta quen với những ph-ơng pháp mới
này. Nh- thế sẽ mất nhiều thời gian và mất nhiều kinh phí để bắt đầu đào
tạo lại họ.
Sau đây là một số trả lời gợi ý cho những lập luận trên.
1. Hồ sơ phát triển phần mềm trong thế giới thực ch-a phải là quá tốt.
Trên thực tế, các ph-ơng pháp cổ th-ờng chỉ dẫn đến thảm họa. Có thành
công đấy nh-ng tỷ số thành công so với thất bại lại quá thấp.
Bất cứ ph-ơng pháp thiết thực nào đều có đôi chút lý thuyết đúng nh-
những ph-ơng pháp phát triển phần mềm đó những ph-ơng pháp đó đã

đ-ợc các công ty t-ơng tự khác vận dụng thành công và đã giảm mạnh
kinh phí phát triển phần mềm và tăng đáng kể chất l-ợng phần mềm.
2.Việc duy trì nề nếp hồ sơ viết là có lợi cho mọi ng-ời cho đội ngũ
phát triển cho khách hàng và cho quản lý cấp cao. Nó đảm bảo là những
Quản lý dự án phần mềm
17
giao tiếp miệng đ-ợc hiểu đúng đắn. Nếu những thay đổi hay các h-ớng
dẫn khác không ghi thành văn bản và không đ-ợc chấp nhận, thì sự phát
triển có thể tiến hành theo h-ớng sai không ai có thể chắc chắn là mọi
thay đổi, cả lớn và nhỏ, sau này sẽ đ-ợc nhớ lại khi dự án hoàn thành.
Danh mục thành văn bản các thay đổi đ-ợc chấp nhận giúp khả năng theo
dõi và hạch toán.
3. Đây có thể là khiếu lại đáng l-u ý; công việc giấy tờ phải đ-ợc duy
trì ở mức tổi thiểu (có khi nó quá mức). Dù sao, đáng ngạc nhiên là công
việc giấy tờ có mức độ hiện nay thực sự lại tiết kiệm thời gian và không
gây lãng phí. Chẳng hạn những quyết định không ghi thành văn bản
th-ờng khi cần đ-ợc lặp đi lặp lại và những đặc tả nói miệng dẫn đến
những lý giải gây tranh cãi. Việc thiếu t- liệu th-ờng mất nhiều thời gian
nhất trong các pha thích hợp và thử nghiệm khi bản thiết kế hệ thống chỉ
đ-ợc l-u trong trí nhớ của ng-ời.
Cũng vậy, một dự án không thành văn bản là một ác mộng trong việc
duy tu. Sau khi hoàn thành dự án, khi các nhà sản xuất đã phân tán đi, tất
cả những gì còn lại là sản phẩm và t- liệu. Không có t- liệu sản phẩm
không gì hơn là một bí mật.
4. Một câu hỏi cần phản ảnh là: liệu và đúng vậy liệu phát triển phần
mềm của chúng ta đã thực sự thành công thế nào? Lập luận này đ-ợc thử
thách tốt nhất với bộ hồ sơ t- liệu đ-ợc chuẩn bị cho biết những vấn đề
mà công ty đã có kinh nghiệm ở những dự án tr-ớc. Mục tiêu là chứng
minh tiếp cận mới với phát triển phần mềm đâu phải là xa xỉ mà là cần
thiết.

5. Những lập luận khó đ-ơng đầu nhất khi có yếu tố sự thực trong
chúng, đặc biệt khi công ty có định ý phát triển ph-ơng pháp luận mới
của chính họ. Mổc dù nhiều công ty có tiến hành nghiên cứu trong công
trình phần mềm điều này thật khó là cần thiết ở mọi công ty đã có những
ph-ơng pháp luận những tiêu chuẩn và những h-ớng dẫn đ-ợc ghi thành
văn bản thỏa đáng (coi IEEE 1987b) để cho chúng có thể đ-ợc vận dụng
dễ dàng ở mọi công ty mà không cần thiết phải phát triển chúng lại.
Mất khách hàng không chỉ do lịch trình phát triển kéo dài mà còn do
chất l-ợng kém và nhu cầu kỹ thuật không đ-ợc thỏa mãn. Càng cần
nghiêm lệnh hẳn về phía lịch trình phát triển lâu hơn chứ không phải về
phía sản phẩm phần mềm tốt hơn.
Nh- vậy, lịch trình phát triển ngắn th-ờng dễ bị lạc lối do thời gian bổ
sung đòi hỏi để bổ chính sản phẩm phần mềm kém cỏi, sau khi đã tung
nó ra lần đầu (coi thí dụ ở phần 1.3).
6. Tại sao lại ch-a làm ngay? Liệu có cơ sở thực sự nào cho việc kêu ca
là thời gian thích hợp hơn sẽ xuất hiện sau này? Trái lại càng thêm thời
gian và công sức đầu t- vào những ph-ơng pháp phát triển nghèo nàn thì
lại càng khó mà thay đổi đ-ợc. Cái cách tốt nhất trả lời cho lập luận này
là cung cấp những lý do kinh doanh để giải thích vì sao những ph-ơng
pháp phát triển mới lại nêu đ-ợc chấp nhận càng nhanh càng tốt. Bộ hồ
sơ đã chuẩn bị, nêu trong trả lời cho lập luận 4, sẽ có ích cùng với thông
Quản lý dự án phần mềm
18
tin thu thập từ các công ty khác. Mục tiêu là bày tỏ rằng những qui tình
phát triển có thứ tự sẽ làm tăng chất l-ợng sản phẩm phần mềm của công
ty trong khi giảm chi phí phát triển.
7. Tầm quan trọng của việc đầu t- trong đào tạo ít khi cần đ-ợc nêu:
đây là một quan niệm đ-ợc chấp nhận rộng rãi. Lập luận này khó có thể
bác bỏ khi các ph-ơng pháp phát triển mới đ-ợc đ-a ra coi nh- một thay
đổi chủ yếu về ph-ơng h-ớng. Câu trả lời tốt nhất tùy thuộc ở tình hình

thực tế. Nếu những ph-ơng pháp mới thực sự tiêu biểu cho thay đổi chủ
yếu là ph-ơng h-ớng thì chắc chắn là công ty đã có thí nghiệm nhiều vấn
đề phát triển phần mềm. Nh- thế câu trả lời cho các lập luận 4 và 5 là
thích đáng.
Nếu những ph-ơng pháp mới không thực sự tiêu biểu thay đổi chủ yếu
về ph-ơng h-ớng thì điều này nêu đ-ợc chứng minh có sử dụng dữ liệu
của các dự án tr-ớc đây. T- t-ởng cơ bản là chứng minh rắng mặc dù
nhiều qui trình phát triển hiện nay là tinh vi, việc cải tiến đáng kể có thể
đ-ợc thực hiện thông qua việc giới thiệu một số ph-ơng pháp mới.
Mọi lập luận chống lại các ph-ơng pháp luận phát triển mới chỉ có thể
bác bỏ đ-ợc sau khi có chuẩn bị đầy đủ. Điều này th-ờng nghĩa là:
- S-u tập dữ liệu về các dự án phát triển phần mềm tr-ớc đây trong
phạm vi vông ty.
- S-u tập dự liệu về các công ty t-ơng tự đã chấp nhận ph-ơng pháp
phát triển mới.
- S-u tập các báo cáo có dẫn t- liệu, văn bản và các chứng cớ khác
thành văn (cần đề phòng quá lý thuyết).
- Có đ-ợc hỗ trợ của các chuyên gia phát triển phần mềm khác hoặc ở
trong phạm vi công ty hoặc ở ngoài.
Mọi dữ liệu cấn đ-ợc nghiên cứu và các ghi chú đ-ợc chuẩn bị chứng
minh nhu cầu của các ph-ơng pháp phát triển mới. Dòng cuối phải là việc
vận dụng những qui tình mới, thiết thực phát triển phần mềm là vì lợi ích
của công ty.
Đã giành đ-ợc sự phê chuẩn cần thiết của quản lý cấp trên, những nhà
quản lý dự án phần mềm có thể chuyển sang vận dụng các ph-ơng pháp
mô tả trong các ch-ơng sau. B-ớc đầu trong việc tìm hiểu những vấn đề
cơ bản trong việc phát triển phần mềm đ-ợc thảo luận ở ch-ơng 2.
1.5. Tóm tắt.
Việc phát triển phần mềm có thể khống chế đ-ợc. Có những ph-ơng
pháp, những kỹ thuật, những tiêu chuẩn và các công cụ khi đ-ợc vận

dụng đúng thì chúng thúc đẩy việc phát triển thắng lợi dự án phần mềm
với ba mục tiêu trứ danh trong trí óc để phát triển phần mềm.
1. Theo đúng lịch trình.
2. Trong phạm vi ngân sách.
3. Theo yêu cầu.
Quản lý dự án phần mềm
19
Thắng lợi hay thất bại của dự án không chỉ liên quan đến ba mục tiêu
phát triển cơ bản đó nh-ng cũng cả đến kỳ vọng của khách hàng: một
khách hàng có thể hài lòng với đầu ra của một dự án trong khi khách
hàng khác lại có thể không. Do đấy, thành công của dự án đ-ợc xác định
tối hậu ở sự hài lòng của khách hàng.
Một trong những trở ngại mà các nhà quản lý dự án th-ờng phải khắc
phục là thiếu hỗ trợ của quản lý cấp trên đối với những ph-ơng pháp phát
triển hiện đại. Rõ ràng là nhiều ph-ơng pháp và kỹ thuật mô tả trong
cuốn sách này, có hiệu lực chỉ khi chúng đ-ợc sử dụng.
Mọi lập luận chống lại các ph-ơng pháp luận phát triển mới chí có thể
bác bỏ sau khi có sự chuẩn bị đầy đủ.
Thông tin về thành công và thất bại của phát triển phần mềm trong quá
khứ trong phạm vi một công ty cần đ-ợc thu thập cùng với các minh
chứng hỗ trợ khác bằng văn bản. Mọi dự liệu cần đ-ợc nghiên cứu và các
chi chú cần đ-ợc chuẩn bị để chứng minh cho nhu cầu về ph-ơng pháp
phát triển mới. Dòng cuối nên là việc ứng dụng các chu trình phát triển
phần mềm hữu hiệu mới là vì lợi ích của công ty.
Quản lý dự án phần mềm
20
Ch-ơng hai
Những vấn đề phát triển phần mềm
Một chút phòng xa
Tại một lớp học mới đầy về quản lý dự án phần mềm, một trong các

học viên đã hỏi:
Chúng tôi có một số vấn đề chủ yếu trong một dự án mà tôi đang
quản lý. Chúng tôi không có đ-ợc t- liệu có hệ thống hay có đ-ợc một kế
hoạch phát triển nào và dự án đang trên đ-ờng v-ợt ngân sách và chậm
hơn lịch trình. Vậy tôi phải vận dụng mọi ph-ơng pháp và kỹ thuật học ở
đây ra sao nhằm làm cho dự án trở lại đúng lịch trình ?
Đây không phải là một tình huống không phổ biến ở đó, một ph-ơng
thuốc thấn kỳ đã tìm cho một tình huống gần gây thảm họa. Những dự án
quản lý tối có thể đi đến trì trệ và ngân sách v-ợt đến hai thậm chí ba
trăm phần trăm và trong vài tr-ờng hợp lại có thể bị bãi bỏ. Hầu hết
những ph-ơng pháp quản lý dự án hiện đại ban đầu bao giờ cũng quan
tâm phòng xa (chứ không phải là hiệu chính) những vấn đề loại đó.
Việc phòng ngừa những vấn đề thì dễ hơn và ít tốn kém hơn là giải
quyết chúng. Những biện pháp phòng ngừa thiết thực hẳn là:
- Định vị sớm vấn đề và những vấn đề tiềm ẩn.
- Giải quyết vấn đề tr-ớc khi chúng tuột khỏi tầm tay.
- Lập kế hoạch tr-ớc (đối phó) với những vấn đề tiểm ẩn. Những vấn
đề sẽ trở nên tốn kém hơn giải quyết khi dự án tiến triển đến những giai
đoạn phát triển cao hơn. Những vấn đề bị lãng quên cũng có thể lan
truyền sang các lĩnh vực khác của dự án làm cho việc hiệu chính chúng
trở nên khó khăn hơn. Do đấy việc thiết lập những qui trình để định vị
sớm và hiệu chính các vấn đề là quan trọng.
Ch-ơng này giải quyết nguyên nhân của một số thể loại rất thông
th-ờng của vấn đề phát triển phần mềm và thảo luận tác động của chúng
đến quá trình phát triển. Ch-ơng này cũng thảo luận việc dự kiến những
vấn đề nhằm giảm thiểu tác động của chúng tới dự án. Các ch-ơng sau đề
ra những ph-ơng pháp phòng ngừa các vấn đề mô tả ở đây khỏi xảy ra.
2.1. Những vấn đề cơ bản.
Có rất nhiều vấn đề cơ bản mà nhà quản lý dự án hình nh- tìm thấy
trong bất cứ dự án phầm mềm nào. Những vấn đề cơ bản đó gây ra bởi

những tình huống sau đây bao giờ cũng có thể phòng tr-ớc sẽ phát sinh:
- Yêu cầu ban đầu không đầy đủ.
- Phụ thuộc ở các nguồn bên ngoài (các ng-ời bán hàng, các chủ thầu
phụ v.v )
- Các khó khăn trong kết thúc dự án.
- Thay thế th-ờng xuyên nhân sự thực hành phát triển (xáo trộn đội
ngũ).
Quản lý dự án phần mềm
21
Các vấn đề cơ bản khác th-ờng nảy sinh do sai lầm quản lý thông
th-ờng nh-:
- Dự toán tồi.
- Theo dõi và giám sát không đầy đủ.
- Thay đổi không kiểm soát đ-ợc.
Con đ-ờng tốt nhất để định vị một vấn đề sớm là đi tìm nó. Rõ ràng,
đầu tiên là tìm xem vần đề th-ờng nảy sinh nhiều nhất ở đâu. Chẳng hạn
thay đổi th-ờng xuyên và không kiểm tra đ-ợc với việc đặc tả các yêu
cầu th-ờng hiển nhiên là nguồn chủ yếu của những vấn đề thiết kế.
Những chủ thầu phụ và ng-ời bán hàng không giám sát đ-ợc là một trong
những nguồn bất ngờ, thông th-ờng nhất đặc biệt là lúc họ báo cáo các
vấn đề kỹ thuật và trì hoãn vào, chính những phút cuối cùng đối với các
nhà quản lý dự án thì việc biết phải kiếm ở đâu do đó quan trọng nh- việc
biết phải làm gì.
2.1.1. Những vấn đề liên quan đến các yêu cầu của dự án.
Đặc tả các yêu cầu của dự án sẽ mô tả sản phẩm phải đ-ợc sản sinh ra
bởi nhóm phát triển (coi ch-ơng 4). Nếu những yêu cầu không đ-ợc đặc
tả đầy đủ thì chỉ các may mắn thuần túy mới đảm bảo đ-ợc là sản phẩm
đáp ứng yêu cầu của khách hàng
4
. Sau đây là một số thí dụ các vấn đề

liên quan đến đặc tả yêu cầu nghèo nàn.
- Quên các đặc điểm.
Khách hàng tin chắc là một số đặc điểm bị bỏ quên hẳn phải nằm trong
sản phẩm căn cứ ở những thảo luận không chính thức (th-ờng với ng-ời
không đúng). Ghi chép, bình luận và nhận xét ở các cuộc họp nh-ng
không căn cứ ở đặc tả yêu cầu chính thức.
- Có những đặc điểm không cần thiết đ-ợc đ-a vào.
Đội ngũ phát triển đã tin chắc là khách hàng hẳn hết sức vui thích về
những đặc điểm ngoại hạng đ-ợc thêm vào sản phẩm (th-ờng không hỏi
ý kiến khách hàng). Một thí dụ hẳn là thêm sự truy nhập hệ thống bằng
khẩu ngữ khi khách hàng lại muốn hệ thống sẵn sàng cho bất cứ ai.
- Đặc điểm mà chúng hoạt động khác với điều mong đợi.
Khách hàng giải thích không đầy đủ về mộ đặc điểm cần thiết và thế là
đội ngũ phát triển hiểu cái yêu cầu đó theo cách hiểu của mình. Một thí
dụ có thể là yêu cầu "cập nhật th-ờng xuyên cơ sở dữ liệu". Các nhà phát
triển đã tạo ra một hệ thống cập nhật cơ sở dự liệu mỗi lần một ngày
trong khi khách hàng muốn nói là một giờ mỗi lần.
- Những đặc điểm cần thiết mà chẳng ai nghĩ đến.
Khách hàng không cần thiết là một chuyên gia máy tính và do đó có
thể không ý thức đ-ợc là một đặc điểm, đặc biệt nào đó phải cần đến. Thí
dụ có thể là nhu cầu về bade up đầy đủ; khách hàng có thể cho là bade up
là không cần thiết vì rằng nếu dịch vụ máy tính bị giám đoạn (thí dụ do
4
Từ khách hàng ở đây đ-ợc sử dụng theo nghĩa rất rộng bao gồm khách hàng chính thức, ban tiếp
thị, nhóm ng-ời dùng, quản lý v.v
Quản lý dự án phần mềm
22
mất điện) thì việc mất một hay hai giao dịch l-u trữ trong bộ nhớ sẽ
chẳng thành vấn đề. Thế nh-ng khách hàng có thể đã không xem xét sự
việc là những điều khiển đĩa cũng có thể đổ vỡ và mất đi mọi dự liệu của

họ.
Rõ ràng là những yêu cầu đ-ợc đặc tả kém lại là vấn đề cho nhà phát
triển nhiều cũng nh- cho khách hàng. Dù sao, nhà sản xuất th-ờng ở vị
thế tốt hơn để biên soạn những yêu cầu hơn là khách hàng. Thông th-ờng
đặc tả yêu cầu tốt nhất là kết quả của sự cố gắng phối hợp của cả nhà phát
triển lần của khách hàng với văn bản thực đ-ợc soạn thành văn của nhà
phát triển và đ-ợc chấp nhận bởi khách hàng.
2.1.2. Những thay đổi th-ờng xuyên.
Thật cực kỳ hiếm khi tìm đ-ợc một dự án phần mềm qui hoạch tốt lại
đi đến kết cục thắng lợi với đặc tả yêu cầu đ-ợc dán nhãn. Ph-ơng án 1.0.
Thay đổi là không tránh khỏi suốt chu trình phát triển phần mềm. Dù sao,
trong phần lớn tr-ờng hợp một thay đổi đ-ợc đ-a ra chậm thì thực hiện
thay đổi lại càng tốn kém.
Một số thay đổi thỏa đáng hẳn là phải quản lý đ-ợc. Khi dòng các thay
đổi đổ vào nh- thác lũ thì chúng trở thành vấn đề. Ngay chỉ một thay đổi
có thể thành vấn đề nếu nó đ-ợc yêu cầu ngay trong phát triển của dự án
và nếu nó dẫn đến thay đổi chủ yếu về ph-ơng h-ớng. Những thay đổi
quá mức tạo nên cái vẫn th-ờng đ-ợc coi là hội chứng mục tiêu di động.
Nhà quản lý dự án không những thay đổi ph-ơng h-ớng và đội ngũ phát
triển trở thanh vừa bối rối vừa mất mục tiêu.
Thay đổi có thể phá vỡ dự án nếu chúng không đ-ợc ghi thành văn bản
và giám sát đầy đủ. Những thay đổi với số l-ợng thỏa đáng, phải đ-ợc
quản lý, vận dụng cơ chế kiểm tra sự thay đổi một cách có hệ thống.
Ph-ơng pháp đó trong phạm vi tổ chức kiểm tra cấu hình, đ-ợc thảo luận
ở ch-ơng 7.
2.1.3. Dự toán và các vấn đề liên quan.
Dự toán tốt là quan trọng vì chúng tạo thành nền móng của kế hoạch
phát triển dự án tốt. Kế hoạch đó, do nhà quản lý dự án chuẩn bị đ-ợc lập
thành trong các giai đoạn ban đầu của dự án và bao gồm dự toán liên
quan đến.

- Ngân sách phát triển dự án
- Lịch trình phát triển dự án
- Tài nguyên phát triển cần đến (đội ngũ phát triển thiết bị phát triển
v.v )
Những dự toán kỹ thuật cũng đ-ợd hình thành trong pha thiết kế và
bao gồm:
- Các đặc tính của phần mềm (dự toán về cỡ bộ nhớ, cơ sở dữ liệu
v.v ).
Quản lý dự án phần mềm
23
- Các đặc tính của phần cứng về cỡ mục tiêu cần đến (dự toán tốc độ
CPU, khả năng đầu vào, đầu ra; khả năng điều khiển đĩa v.v ).
Dự toán là cơ sở cho nhiều quyết định kỹ thuật và quản lý dự toán tồi
dẫn đến quyết định dở. Dự toán tồi có thể hiểu là quá cao hoặc là quá
thấp và quyết định theo đó hoặc là tạo ra lãng phí hoặc thiếu tài nguyên
phát triển. Điều này hình thành sai lầm trong qui hoạch, nh-:
- Lịch trình quá ngắn hoặc cao thái quá.
- Ngân sách quá thấp hay quá tăng giả tạo.
- Quá thiếu hay quá thừa ng-ời làm và những sai lầm trong thiết kế kỹ
thuật, nh-:
- Những máy tính trong mục tiêu quá nhiều (và đắt hơn) hơn cần thiết
hoặc không thể hỗ trợ ứng dụng đ-ợc phát triển. Những vấn đề nảy sinh
từ dự toán thấp th-ờng gay cấn hơn là những vấn đề nảy sinh từ dự toán
cao. Hiểu rõ điều này, các nhà dự toán th-ờng thêm vào một số yếu tố bất
trắc (cho rằng đến 30%) trong dự toán của minh, giả định rằng quá cao
còn hơn quá thấp. Dù sao dự toán cao có thể không gây ra thất bại của dự
án nh-ng có thể ngăn cản dự án chẳng bao giờ đ-ợc khởi công. Đã có
nhiều ph-ơng pháp đ-ợc phát triển nhằm tạo ra các loại dự toán khác
nhau ở các giai đoạn khác nhau của dự án (coi các ch-ơng 9 và 10). Dù
sao, ngay những dự toán chuẩn bị tốt có thể dẫn đến những vấn đề nếu

chúng không đ-ợc cập nhật trên một cơ sở định kỳ và đều đặn. Rõ ràng là
thông tin tốt hơn và đầy đủ hơn tạo nền dự toán tốt hơn. Do đó khi dự án
tiến triển và có nhiều thông tin hơn, dự toán cần đ-ợc xem xét lại và hiệu
chỉnh. Điều này dẫn đến việc giám định lại các quyết định phát triển, tạo
cho các vấn đề tiềm ẩn đ-ợc đề cập sớm tr-ớc khi chúng trở thành gay
cấn (coi phần 2.2 về phân tích rủi ro).
2.1.4. Nguồn lực bên ngoài.
Các vấn đề phát triển dự án th-ờng dễ quản lý nhất khi mọi nhân tố
phát triển đ-ợc điều khiển bởi quản lý dự án. Dù sao, điều này không
phải bao giờ cũng có đ-ợc. Nhiều dự án phụ thuộc ở nhiều nguồn bên
ngoài nh-:
- Chủ thầu phụ
- Ng-ời bán thiết bị
- Những dự án phát triển song hành
- Những ng-ời cung cấp dịch vụ (bảo trì, huấn luyện, lắp đặt v.v )
- Các chức năng hỗ trợ (thông tin điện thoại mạng, những cung cấp dự
liệu. Dự phụ thuộc vào các nguồn bên ngoài hẳn phải đ-ợc phản ánh
trống).
Kế hoạch phát triển dự án. Điều này có nghĩa trong phạm vi các giao
-ớc và dự toán nhận đ-ợc từ các nguồn khác. Theo thế, dự toán trong kế
hoạch không thể tốt hơn dự toán nhận từ các nguồn khác.
Việc trông cậy vào các nguồn bền ngoài có thể gây ra những vấn đề
sau:
Quản lý dự án phần mềm
24
- Chậm trễ lịch trình, do việc giao chậm các thành phần dự án.
- Sự kém cỏi quá chất l-ợng và thiết kế thiết bị phát triển và các thành
phần dự án bên ngoài.
- Thành phần bên ngoài không t-ơng hợp do vì sự sai lệch của nhà phát
triển bên ngoài hay bán hàng với đặc điểm đã thỏa thuận hay đã công bố.

- Hỗ trợ sản phẩm nghèo nàn đối với các thành phần bên ngoài. Do có
ý thức đ-ợc những vấn đề tiềm ẩn đó, nhà quản lý dự án có thể đảm bảo
rằng họ đ-ợc định vị thích hợp trong hợp đồng hay thỏa thuận với nguồn
bên ngoài. Những vấn đề đó có thể đ-ợc ngăn ngừa nều đ-a vào trong
hợp đồng những mức phát về chậm trễ trong giao hàng hay khuyết tật
trong sản phẩm (coi các ch-ơng 3 và ch-ơng 9). Những đề phòng sớm có
thể đ-ợc phát hiện khi th-ờng xuyên xét duyệt lại công việc đ-ợc phát
triển bởi chủ thầu phụ và đòi hỏi sẽ báo cáo tiến độ th-ờng kỳ.
2.1.5. Kết thúc một dự án phần mềm.
Nh- mọi nhà quản lý dự án đều biết, các dự án khó mà bắt đầu đ-ợc
kinh nghiệm cho thấy là chúng th-ờng không ít khó khăn để đi đến kết
thúc. Đi tới đoạn kết của dự án, luôn luôn các bên quan tâm khác nhau
phát sinh những yêu cầu. Nh- phê phán những thay đổi mới và những
hoạt động phút chót khác nữa. Điều này là đặc biệt có thực với những dự
án giá cố định phát triển cho khách hàng theo hợp đồng (coi ch-ơng 3).
Những vấn đề chính liên quan đến việc kết thúc dự án là:
- Tranh chấp giữa khách hàng và nhà phát triển về việc lý giải và cung
ứng mọi đặc điểm đ-ợc yêu cầu
- ý đồ đ-a vào những thay đổi ở phút chót.
- Thất bại của hệ thống và khuyết tật thiết kế xác định trong quá trình
cài đặt và thử nghiệm hệ thống.
- Khó khăn trong việc giữ cho đội ngũ phát triển hợp lực lại với nhau
và năng động. Khi tình hình căn thẳng giảm đi vào gần cuối dự án có tình
trạng sút giảm nhiệt tình t-ơng ứng trong những thành viên còn lại của
đội phát triển.
Trách nhiệm của nhà quản lý dự án là đảm bảo cho việc kết thúc dự án
có trật tự và thắng lợi. Điều này đ-ợc thực hiện nhờ việc qui hoạch chi
tiết lúc ban đầu dự án và quản lý dự án có hiệu quả xuyên suốt dự án. Đặc
biệt, điều này đòi hỏi rằng:
- Kế hoạch thử nghiệm thu phải đ-ợc chuẩn bị lập tài liệu và đ-ợc

khách hàng phê chuẩn tr-ớc khi kêt thúc dự án. Mức độ nhân sự và sự
phân công công việc phải đ-ợc lập lịch trình, có tính đến việc giảm dần
trong qui mô đội ngũ phát triển vào cuối dự án.
-Việc đ-a ấn phẩm ra thị tr-ờng phải đ-ợc lập kế hoạch tốt, kể cả đóng
gói soạn thảo t- liệu, huấn luyện, cài đặt và chuyển tiếp có trật tự sang
pha bảo trì và hỗ trợ.
Sự kết thúc thắng lợi của dự án là bắt đầu của chu trình phát triển khác:
Những đặc tả yêu cầu, những kế hoạch thử nghiệm hay những kế hoạch
Quản lý dự án phần mềm
25
phát triển nghèo nàn, tất cả đều dẫn đến những vấn đề chủ yếu lúc kết
thúc dự án.
2.1.6. Tuyển dụng nhân viên và thuyên chuyển.
Khó khăn trong việc tuyển dụng các thành viên đội ngũ phát triển là
một trong những vấn đề đầu tiên mà ng-ời quản lý dự án phần mềm gặp
phải. Tr-ớc khi bất cứ dự án nào đ-ợc tung ra, đội ngũ phát triển ban đầu
phải đ-ợc thiết lập và các vấn đề này sẽ không kết thúc một khi đội ngũ
tại vị. Giữ đ-ợc đội ngũ th-ờng khó nh- thiết lập nó.
Frenkel (1985) báo cáo là nhu cầu kỹ s- phần mềm tăng theo hàm số
mũ trong khi năng suất tăng theo mức khoảng 5% mỗi năm. Các tr-ờng
đại học Hoa kỳ và châu Âu đang không cung cấp kỹ s- phần mềm đủ để
bù đắp lỗ hổng giữa cung và cầu. Trên thực tế không những lỗ hổng
không đ-ợc lấp kín mà lại đang rộng ra ở mức đáng lo ngại.
Khối l-ợng thời gian bình quân mà một kỹ s- phần mềm ở lại nghề
giảm khi yêu cầu kỹ s- tăng. Điều này không chỉ gây ra bởi sự thuyên
chuyển của kỹ s- phần mềm giữa các công ty mà cơ sở sự thuyên chuyển
trong phạm vi các công ti. Vì các công ty này đang tìm cách sử dụng hữu
hiệu hơn các kỹ s- của mình. Sự thuyên chuyển trong phạm vi các công
ty không chỉ do tình trạng thiếu kỹ s- phần mềm mà còn do chi phí về họ
có thể vẫn ngăn trở thành việc tuyển bổ sung.

5
Thuyên chuyển nhân sự bản thân nó là một vấn đề trọng yếu. Sự ổn
định có của đội ngũ và do đó vào thắng lợi của dự án.
Các vấn đề liên quan đến tuyển nhân sự và thuyên chuyển luôn bao
gồm:
- Việc đầu t- đáng kể đ-ợc đòi hỏi trong đ-ờng biểu diễn học tập và
đào tạo thành viên đội ngũ phát triển mới.
- Thuyên chuyển nhân sự luôn luôn sẽ giảm đi tinh thần đội ngũ và tác
động không lợi đến động cơ đội ngũ.
- Tuyển chọn th-ờng tốn kém và mất thì giờ nó đòi hỏi nhiều cuộc
phỏng vấn và cả phí tuyển dụng.
- Thuyên chuyển nhân sự luôn tạo ra tình trạng thiếu kiện định trong
phát triển dự án.
Trong các vấn đề phát triển phần mềm, những gì liên quan đến phát
triển đội ngũ th-ờng đ-ợc nhận thức là gay cấn nhất. Các thành viên đội
là nguồn phát triển quan trọng nhất cỡ chính họ đóng góp nhiều nhất cho
sự thành công hay thất bại của dự án.
5
Kinh tế học cơ bản chỉ ra rằng khi có đ-ợc kỹ s- thì chi phí về họ sẽ
giảm (căn cứ ở cung và cầu trong phạm vi thị tr-ờng nghề nghiệp. Dù
sao, trong những năm gần đây, việc cung các kỹ s- phần mềm không bao
giờ đủ lớn để tạo ra tác động đó ngoại trừ ở những khoảng thời gian ngắn
ngủi tại các địa điểm cô lập).