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

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ị

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

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

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

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

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

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.

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à

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

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

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.

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

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 đó đã

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

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

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 đề

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.

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ố.

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.