Giaotrinhquanlyduanphanmempdf

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.54 MB, 243 trang )

(1)<div class='page_container' data-page=1></div>
(2)<div class='page_container' data-page=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. Nhng vn 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 ngoi

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 phn mm theo hp 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 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

</div>
(3)<div class='page_container' data-page=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 tt

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 biu 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 u cầu phần mềm

4.2.1. Bàu khơng khí trong q 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 tt
Bi tp
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

</div>
(4)<div class='page_container' data-page=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

</div>
(5)<div class='page_container' data-page=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

Lp trỡnh: vn

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 ti hn

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. Kim chng v cp nht 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 mc hot 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: vn
10.1. D toỏn d ỏn
10.2. D toỏn tng 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

</div>
(6)<div class='page_container' data-page=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. Tht 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

Ti liu c thờm

</div>
(7)<div class='page_container' data-page=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.

Cun sỏch tp trung, trong mt 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ý chun 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 dng. 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.

Ci cïng, cn 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ü tht.

</div>
(8)<div class='page_container' data-page=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 ri 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à nhng vn ố ca mi giai
on.

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

</div>
(9)<div class='page_container' data-page=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 nng ú.

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: chn 2167 cđa Bé Qc 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 tho lun 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 thut chun 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ự tốn và
mơ tả các dự tốn có thể đ-ợc hồn thiện thế nào trong q 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à in 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 cm ơ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 ó chng bao gi -c vit ra.

NhÃn hiệu th-ơng mại

</div>
(10)<div class='page_container' data-page=10>

MS-DOS là th-ơng nhÃn của tập đoàn Microsoft

</div>
(11)<div class='page_container' data-page=11>

Ch-ơng một

Nhập môn về quản lý dự án phần mềm

Nhập môn

Phn mm l ni trng cỏc gic 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

Chun 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

</div>
(12)<div class='page_container' data-page=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 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 đố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/CAM2 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 hồn tồ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.

Vic qun 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.

</div>
(13)<div class='page_container' data-page=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 lnh vc 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 xun 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ự tố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 mt s d ỏn, vic tip xỳc vi 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 q 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ự tố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ự tố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 hố 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.

</div>
(14)<div class='page_container' data-page=14>

t- liệu quá mức trong đó chi cơng sức q đá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ện3. 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 hồ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 chun 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 đó (tồn bộ thời gian phát triển

3Xem Shaw (1990) về một thảo luận đầy đủ trên vấn đề tiến hố của phần mềm trong bộ mơn công

</div>
(15)<div class='page_container' data-page=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 ngồ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 la ca nh qun 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 qun lý ban mun chng 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 ngồ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
tồn mới cho một cơng ty phần mềm bền ngồ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 nghim trong mt lnh 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 hồn tồ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 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 cn thit.

</div>
(16)<div class='page_container' data-page=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 thố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 trin phn mm 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-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.

</div>
(17)<div class='page_container' data-page=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 tố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 phi phỏt trin chỳng li.

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

</div>
(18)<div class='page_container' data-page=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 tp d liu 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ý thuyt).

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

</div>
(19)<div class='page_container' data-page=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 đủ.

</div>
(20)<div class='page_container' data-page=20>

Ch-ơng hai

Nhng vn phỏt trin phn mm

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:

- u cầu ban đầu khơng đầy đủ.

- Phơ thc ë c¸c ngn 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.

</div>
(21)<div class='page_container' data-page=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ì hỗ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 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àng4. 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ả 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 chun 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

4Từ 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

</div>
(22)<div class='page_container' data-page=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ự tố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 gm 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 thit b phỏt trin
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:

</div>
(23)<div class='page_container' data-page=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ự tốn tồi có thể hiểu là q 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 ngun
phát triển. Điều này hình thnh sai lm trong qui hoch, 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ự tố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. Ngn 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 nhiu ngun bờn
ngoi nh-:

- Chủ thầu phụ
- Ng-ời bán thiết bị

- Những dự án phát triển song hành

- Nhng 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 ngồ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.

</div>
(24)<div class='page_container' data-page=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.

- Thnh phn bờn ngoi 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 ngồ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 ngồ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- mi nh qun 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ợ.

</div>
(25)<div class='page_container' data-page=25>

phát triển nghèo nàn, tất cả đều dẫn đến những vấn đề chủ yu lỳc kt
thỳc d ỏn.

2.1.6. Tuyển dụng nhân viên và thuyªn chun.

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

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 tun bỉ sung.5

Thun 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 ln 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ự ln 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 ca 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ẽ

</div>
(26)<div class='page_container' data-page=26>

2.1.7. Theo dõi và giám sát.

Theo dõi và giám sát là những nhiệm vụ quản lý. Khi các vấn đề phát
sinh ở những lĩnh vực này và liên quan, chúng th-ờng là hậu quả của các
qui trình quản lý dự án khơng thích hợp và khơng hiệu lực. Một trong
những kết quả thông th-ờng nhất là nhà quản lý dự án khơng có ý thức về
sự tồn tại của những vấn đề chủ yếu ở giai đoạn mà chúng có thể đ-ợc
kiềm chế và hiệu chỉnh tốt nhất. Việc theo dõi và giám sát có hiệu quả
đòi hỏi sự tiếp xúc trực tiếp giữa quản lý dự án và đội ngũ phát triển (coi
ch-ơng 7). Một trong những nguyên nhân chủ yếu của các vấn đề theo
dõi và giám sát là hội chứng tháp ngà nơi tồn tại kẽ nứt th-ờng trực giữa
quản lý dự án và phần còn lại của đội ngũ phát triển. Điều này dẫn đến:

- Lng thơng tin khơng chính xác hay khơng có. Đóng góp đáng kể
vào những quyết định quản lý tồi.

- Phát triển khơng phối hợp: tình huống này th-ờng đ-ợc mô tả khi
một đội ngũ phát triển đang triển khai hai dự án khác nhau. Điều này xảy
ra khi các thành viên đội ngũ phát triển không phối hợp và không đ-ợc
giám sát lại đã tiến hành theo những h-ớng khác nhau.

- Trí tuệ lịch trình và bội chi ngân sách, điều này gây ra do dự toán tồi

dựa vào các thông tin không đúng.

Thông tin là thành phần cơ bản của bất cứ thể loại quản lý nào. Do đấy,
giám sát tồi đi đối với luông thông tin khơng thích hợp là cốt lõi của quản
lý dự án tồi. Cả ba vấn đề trên mô tả hậu quả chung của quản lý tồi. Danh
mục các vấn đề kéo theo hẳn đúng là bao trùm hầu hết các kiểu vấn đề
phát triển dự án. Các ph-ơng pháp tạo lập những kênh thơng tin có hiệu
lực và những qui trình báo cáo đ-ợc tổ chức tốt sẽ đ-ợc mơ tả ở ch-ơng
5.

2.2. Ph©n tÝch rđi ro.

</div>
(27)<div class='page_container' data-page=27>

hạn, giá của một bộ phận thay thế của thiết bị phát triển. Trong mọi
tr-ờng hợp, một vấn đề đã đ-ợc phân tích và giải quyết sớm hơn thì đơn
giản hơn rất nhiều so với việc giải quyết vấn đề sau khi phát sinh bất ngờ.

2.2.1. Dự kiến những vấn đề cần giải quyết.

Giai đoạn đầu tiên của phân tích rủi ro đòi hỏi duyệt xét mọi kế hoạch
quản trị và kỹ thuật của dự án nhằm minh định các vấn tim n nú bao
gm:

- Kế hoạch phát triển dự án.
- Đặc tả yêu cầu.

- Đặc tả thiết kế.

Bng 2.1. Thí dụ về danh sách vấn đề dự liệu

Vấn đề Mơ tả

1. ChËm giao m¸y tÝnh

để phát triển Nếu máy tính để phát triển khơng đ-ợc giao vào1/6 nh- kế hoạch, giai đoạn thích hợp sẽ bị
chậm.

2. Bộ nhớ khơng đủ Cỡ của phân l-u trữ bộ nhớ của hệ thống có thể
v-ợt 8 mêga baitơ (cỡ bộ nhớ tối a -c vi tớnh
cp d-ng).

3. Không có chuyên gia

h thng điều hành Hệ thống đòi hỏi thay đổi cho hệ thống điềuhành chuẩn J.Adams là chuyên gia hệ điều hành
duy nhất trong cơng ty và ơng có thể bận khơng
đ-ợc sử dụng cho hệ thống này.

4. Thời gian đáp ứng của

hệ thống quá chậm Thời gian đáp ứng của hệ thống yêu cầu cho đầuvào có thể quá 5 giây so vi c t trong yờu
cu.

5. Thuyên chuyển nhân

sự nhiều Lịch trình là xát xao với thời gian trống tốithiểu. Nếu có sự thay thể nhân sự quá mức bình
quân trong phát triển chúng ta sẽ tr-ợt thêm lịch
trình.

6. Truyền thông quá

chậm Góc truyền thông chuẩn quá chậm. Thiết kế dựatrên gói truyền thông nhị phân mới. Góc này

ch-a bao giờ đ-ợc sử dụng với hệ thống này và
có thể không thích hợp.

7. Chậm giao và hệ

thng ph c s dữ liệu Hệ thống phụ cơ sở dữ liệu đ-ợc hợp đồng phụvới tập đoàn phát triển phần mềm (SOI) cam kết
giao hàng 15-4. SOI có thể khơng giao đúng
thời hạn nên làm chậm sự thích hợp và pha thử
nghiệm cuối.

</div>
(28)<div class='page_container' data-page=28>

nh-chủ thầu phụ, ng-ời bán hàng, nhà cung cấp và các nhà làm dịch vụ. Các
vấn đề sẽ nảy sinh nếu các hợp phần hay dịch vụ bên ngồi khơng đ-ợc
cung cấp kịp thời hay khơng hoạt động nh- trông đợi.

Đặc tả thiết kế dự án là một kế hoạch chi tiết về việc làm thế nào để
các yêu cầu đ-ợc thực hiện. Các quyết định về sự thực hiện đ-ợc địi hỏi
có thể chứa các vấn đề tiềm năng. Chẳng hạn, các vấn đề sẽ nảy sinh ra
nếu phần cứng đ-ợc lựa chọn lại hóa ra khơng thích hợp, chẳng hạn
nh-CPU q chậm, mạng cục bộ không đủ tin cây, hoặc bộ nhớ không đủ.

Sau đó mọi vấn đề dự liệu đ-ợc tập hợp lên danh sách, mỗi vấn đề
đ-ợc minh định và mô tả về tác động tiềm ẩn ảnh h-ởng tới dự án. Bảng
2.2. cho một thí dụ về danh sách vấn đề dự liệu.

Danh sách vấn đề dự liệu nên đ-ợc tập hợp nhờ có sự tham gia của các
thành viên chính của đội ngũ phát triển dự án. Những ng-ời khác có thể
cũng đ-ợc mời đóng góp cho danh sách đó, căn cứ ỉw kinh nghiệm cùng
kiến thức kỹ thuật hay quản trị của họ; Có thể bao gồm cả những ng-ời từ
các đội ngũ dự án khác, các nhóm hỗ trợ phòng pháp chế hay phòng mua
sắm (kinh doanh) của công ty.

Trong khi mục tiêu không phải là liệt kế mọi vấn đề nhận thức đ-ợc
mà mỗi dự án có thể kinh qua, cần thiết là minh định những vấn đề hẳn
đ-ợc xem một cách hợp lý là có liên quan đến dự án. Trong mọi tình
huống, giai đoạn phân tích sau đây đ-ợc nhằm để cách ly chỉ những vấn
đề nào có thể tác động lớn lao đến dự án và có thể một cách hợp lý đ-ọc
xem là hẳn sẽ xảy ra

2.2.2. Pha ph©n tÝch

Việc phân tích danh sách những vấn đề dự liệu đòi hỏi đánh giá mỗi
vấn đề nhằm:

1. Dự toán xác suất vấn đề sẽ xảy ra.
2. Dự toán sáo động của vấn đề tới dự án
3. Quy cho mức độ nghiêm trọng của vấn đề.

Xác suất đó và tác động đó nếu đ-ợc dự toán bởi quá một ng-ời. Mọi
hạng mục trong danh sách đ-ợc dự toán tốt nhất trong một cuộc họp duy
nhất đánh giá vấn đề để đảm bảo tính t-ơng đối của mức độ nghiêm
trọng, giữa các vấn đề không bị lệch lạc. Mục tiêu là tránh những tình
huống khi việc chậm giao của bên cung cấp A đ-ợc một ng-ời dự toán là
0.8 và việc chậm giao của bên cung cấp B đ-ợc một ng-ời khác dự toán
là 0.6 trong khi cả 2 nhà dự toán hẳn đồng ý là hai xác suất này là bằng
nhau. Nếu hai ng-ời ở trong cùng 1 phịng trong cùng 1 lúc thì sự lệc lạc
t-ơng đối đó giảm đi.

Một cách đơn giản và hiệu quả để tính mức độ nghiêm trọng của mỗi
vấn đề đ-ợc dự liệu là:

</div>
(29)<div class='page_container' data-page=29>

2. Gán một số giữa 1 và 10 căn cứ ở tác động của vấn đề với dự án với
10 biểu thị tác động cao và 1 tác động thấp.

3. Nhân trị giá có đ-ợc ở b-ớc (1) với tự giá có đ-ợc ở b-ớc (2) để tính
mức độ nghiêm trọng cho vấn đề.

Bảng 2.2. giới thiệu một thí dụ về cách tính mức độ nghiêm trọng có sử
dụng các vấn đề dự liệu mơ tả ở bảng 2.1.

Bảng 2.2. Thí dụ về cách tính mức độ nghiêm trọng.
ST

T Vấn đề vọngKỳ độngTác Nghiêmtrọng

1 Chậm giao máy tính để phát
triển

6 5 30

2 Bộ nh khụng 4 2 8

3 Không có chuyên gia hệ điều
hành

5 5 25

4 Thi gian ỏp ng ca h thng

quá chậm 5 3 15

5 Thuyên chuyển nhân sự cao 5 8 40

6 Truyền thông quá chậm 2 8 16

7 Chậm giao hệ thống phụ cơ sở
dữ liệu

3 9 27

Sau khi mức độ nghiêm trọng đã đ-ợc tính cho mỗi vấn đề dữ liệu,
danh sách đ-ợc phân loại theo dự nghiêm trọng của vấn đề trong đó vấn
đề nghiêm trọng nhất đứng đầu danh sách. Sau đó có thể quyết định xem
vấn đề nào có mức độ nghiêm trọng ít hơn một trị giá nào đó (thí dụ 10)
sẽ khơng đ-ợc xem xét. Sau đây những vấn đề còn lại đ-ợc đánh giá và
tiến trình hành động chi tiết, gọi là kế hoạch đối phó bất ngờ đ-ợc lựa
chọn cho mỗi vấn đề. Rồi thông tin đ-a vào bảng đối phó bất ngờ. Với
mỗi lần đ-a vào bảng, một thành viên của đội ngũ phát triển đ-ợc bố trí
là ng-ời theo dõi để theo dõi vấn đề và báo động quản lý dự án khi kế
hoạch đối phó bất ngờ cần đ-a vào hoạt động giai đoạn này đ-ợc trình
diễn ở bảng 2.3.

</div>
(30)<div class='page_container' data-page=30>

B¶ng 2.3. ThÝ dơ vỊ bảng ngẫu nhiên

Vn Nghiờm

trng K hoch i phú bt ng theo dừiNg-i

5 Thuyên chuyển

nhân sự cao 40 Cho tiền th-ởng hoàn thànhdự án thắng lợi. J.Smith

1 Chậm giao máy

tớnh để phát triển 30 Yêu cầu làm ca đêm về hệthống phát triển của dự án
khác.

H.Brown
7 ChËm giao hƯ

thèng phơ cơ sở
dữ liệu

27 Thit k mt mụ phng h
thng ph c s d liu
dựng tớch hp.

W.Alda
3 Không có chuyên

gia hệ điều hành 25 Bố trí chuyên gia hệ điềuhành ngoài công ty và thuê
làm t- vấn

H.Brown
6 Truyền thông quá

chm 16 Hợp đồng với cơng ty đãphát triển gói truyền thơng
nhị phân thích nghi cho gói
vói dự án này.

H.Troy

4 Thời gian đáp ứng
của hệ thống quá
chậm

15 Cho vào điều khỏan thỏa
thuận nâng cấp CPU trong
hợp đồng mua máy tính.

Y.Krot
2 Bé nhớ không đầy

8 (khụng xem xột)

2.2.3. Thc hin cỏc kế hoạch đối phó bất ngờ.

Các kế hoạch đối phó bất ngờ đ-ợc thực hiện ở một trong những
tr-ờng hợp sau:

1. Vấn đề dữ liệu diễn ra hay sắp xảy đến đến nơi.

2. Kế hoạch đối phó bất ngờ địi hỏi đ-ợc chuẩn bị tr-ớc.

Nói chung, các kế hoạch đối phó bất ngờ có thể đ-ợc nhìn nhận theo
nh- cái kế hoạch, hành động đ-ợc xếp vào ngăn kéo để phòng khi dùng
đến sau này. Dù sao, trong vài tr-ờng hợp, kế hoạch đ-ợc thực hiện tr-ớc
khi vấn đề dự liệu xảy ra nh- phát triển một bộ mô phỏng tr-ờng hợp việc
giao một hợp phần quyết định bị chậm trễ. Sau đó, nếu họpw phần đ-ợc
giao đúng hạn thì bộ mơ phỏng đó có thể bị bỏ đi.

Lấy thí dụ về q trình hồn chỉnh chúng ta thử xem xét một dự án

truyền thơng cần đến một máy tính trung tâm nối bằng mạng diện rộng
với vài vị trí máy tính nhỏ, có hai vấn đề tiềm ẩn đ-ợc minh định.

</div>
(31)<div class='page_container' data-page=31>

- Công ty điện thoại đ-ợc chọn có thể khơng có khả năng lắp đặt
đ-ờng dây thử nghiệm đún ghẹn cho pha tích hợp.

Bảng 2.4. Danh mục vấn đề dữ liệu

Vấn đề Mơ tả

1. thĨ thøc trun th«ng

khơng t-ơng hợp. Hai máy tính có kiến trúc khác nhau có thểdiễn giải thể thức truyền thơng đã thiết kế là
khác nhau.

2. Đ-ờng dây thử
nghiệm có chậm để tích
hợp.

Cơng ty điện thoại đ-ợc chọn có thể khơng có
khă năng lắp đặt đ-ờng dây thử nghiệm đúng
hạn để tích hợp.

Bảng 2.5. Đo mức độ nghiêm trọng

Vấn đề Kỳ

vọng độngTác nghiờmtrng

1. Thể thức truyền thông không

t-ơng hợp

5 8 40

2. §-êng d©y thư nghiƯm cã chËm

để tích hợp. 8 6 48

Bảng 2.6. Bảng đối phó bất ngờ

Vấn đề Độ

nghiªm
träng

Kế hoạch đối phó

bÊt ngê theo dâiNg-êi

1. Đ-ờng dây thử
nghiệm có chậm tớch
hp.

48 Đặt hàng đ-ờng dây
từ 2 công ty điện
thoại phụ

Will Doo
2. Thể thức truyền thông

không t-ơng hợp.

40 Sử dụng gãi th«ng tin
ASCII

I.Hope

Các bảng 2.4; 2.5 và 2.6 là các bảng phân tích rủi ro cho dự án truyền
thơng đó. Nừu khả năng có đ-ợc đ-ờng dây truyền thơng bị chậm lại,
điều này sẽ gây ít tác hại cho dự án hơn là vấn đề thể thức không t-ơng
hợp. Việc theo dõi vấn đề này đã đ-ợc giao cho Wieliam Joo.Trách
nhiệm của ông là đảm bảo những đ-ờng dây này đ-ợc đặt hàng từ hai
công ty điện thoại khác (chỉ cho pha tích hợp thơi). Nếu cơng ty điện
thoại có -u tiên thế sẵn sàng đúng hẹn thì những đơn đặt hàng từ hai công
ty khác đ-ợc hủy và khả năng phí hủy bỏ phải trả.

</div>
(32)<div class='page_container' data-page=32>

A.SCII đơn đ-ợc đặt cho cả hai máy tính phí về gói áCII sẽ là lãng phí
nếu thể thức nhị phân đ-ợc chọn sẽ hoạt đồng. Giải phóng áCII thay thế
hầu nh- chắc chắn chậm hơn nhiều, nh-ng nó sẽ cung cấp giải pháp tạm
thời cho đến khi vấn đề không t-ơng hợp đ-ợc giải quyết.

2.3. Tãm t¾t

Các ph-ơng pháp quản lý dự án hiện đại lúc đầu quan tâm đến việc
các vấn đề phát triển dự án (việc phịng ngừa khơng hiệu chỉnh). Phịng
ngừa các 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 có hiệu quả nêu là:

- Định vị các vấn đề và các vấn đề tiềm ẩn sớm.
- Giải quyết vấn đề tr-ớc khi tuột khỏi tầm tay.

- Lập kế hoạch tr-ớc cho những vấn đề tiềm ẩn

Có rất nhiều vấn đề cơ bản chung cho hầu hết các dự án phầm mềm.
Phần lớn những vấn đề đó dẫn xuất từ:

- Xác định yêu cầu không đầy đủ.
- Thay i luụn

- Dự toán tồi

- Tùy thuộc ở nguồn bên ngoài (ng-ời bán, chủ thầu phụ v.v...)
- Khó khăn trong kÕt thóc dù ¸n.

- Ln ln thay thế nhân sự phát triển (thuyên chuyển nhân sự)
- Theo dõi và giám sát không đầy đủ.

Cách tốt nhát để định vị một vấn đề là sớm đi tìm kiếm nó. Rõ ràng,
tr-ớc hết là tìm xem ở đâu vấn đề hay diễn ra nhất. Chẳng hạn những
thay đổi đặc tả yêu cầu luôn luôn và không kiểm tra là không thuận lợi
đ-ợc coi nh- nguồn gốc chủ yếu của những vấn đề thiết kế. Những chủ
thầu phụ và ng-ời bán không giám sát đ-ợc là một trong hầu hết những
nguồn gốc bất ngờ, những vấn đề kỹ thuật l-u lại và chậm chễ vào phút
chót. Với nhà quản lý dự án thì biết đ-ợc ở đây phải tìm là quan trọng
nh- biết đ-ợc phải làm gì.

Biết phải làm gì bao gồm cả việc chuẩn bị tr-ớc sự xuất hiện của vấn
đề. Trong nhiều tr-ờng hợp, các vấn đề có thể đ-ợc dự liệu. Nhà quản lý
dự án có thể lập kế hoạch về khả năng vấn đề sẽ xảy ra bằng cách dự tính
xác suất của nó, -ớc l-ợng tác động của nó và chuẩn bị giải pháp thay
thế. Cái đó đ-ợc gọi là phân tích rủi ro và là biện pháp có hiệu quả trong

việc đấu tranh với những vấn đề phát triển tiềm ẩn.

</div>
(33)<div class='page_container' data-page=33>

mọi tr-ờng hợp vấn đề đã đ-ợc phân tích giải quyết tr-ớc lại đơn giản
hơn là giải quyết vấn đề đã xảy ra bất ngờ.

Bµi tËp

1. Một cơng ty dịch vụ truyền hình cáp đang chuẩn bị thiết lập dịch vụ
trong thời gian 8 tháng. Công ty cung cấp dịch vụ cho các khách hàng với
phí cố định hàng tháng tùy thuộc ở qui mô dịch vụ mà họ yêu cầu. Công
ty cũng cho chiếu những phim mới mỗi phim có thể cho một khách hàng
xem theo yêu cầu qua điện thoại với công ty.

Giờ cơng ty đang trong q trình đặt mua thiết bị, mua các ph-ơng tiện
và ký với khách hàng. Một công ty phần mềm đã hợp đồng phát triển một
hệ thống làm hóa đơn cho các khách hàng. Hệ thống này sẽ giao diện với
thiết bị để nhận thông tin về các buổi chiếu phim mói trên màn ảnh và sẽ
giao diện với cơ sở dữ liệu của khách hàng để thơng tin đều đặn về hóa
đơn hàng tháng.

Bạn hãy chuẩn bị một danh mục m-ời vấn đề gay cấn nhất mà bạn chi
liệu trong phát triển dự án làm hóa đơn. Hãy thỏa thuận lý do của việc
chọn lựa vấn đề của bạn.

2. Bạn hãu tính mức độ nghiêm trọng cho mỗi một vấn đề tiềm ẩn mà
bạn đã định ở bài tập 1. Hãy giải thích việc phân định của bạn về tác
động của dự án và các trị giá xác suất.

Hãy gợi ý một ph-ơng pháp thay thế phân định mức độ nghiêm trọng
cho những vấn đề dự liệu mà nó cũng tính cả chi phí chuẩn bị các kế

hoạch đối phó bất ngờ.

3. Bạn hãy gợi ý những kế hoạch đối phó bất ngờ cho những vấn đề dự
liệu mà bạn đã định ở bài tập 1. Hãy xét hai kế hoạch thay thế khác nhau
cho mỗi một vấn đề. Xét chi phí của mỗi kế hoạch thay thế và sau đó
chọn kế hoạch tốt nhất dựa trên ph-ơng pháp thay thể để phân định mức
độ nghiêm trọng mà bạn gợi ý ở bài tập 2.

Hãy chuẩn bị một bảng đối phó bất ngờ có chứa các kế hoạch đối phó
bất ngờ mà bạn đã chọn.

4. Bài tập ở lớp: Chia lớp thành các nhóm 3 hay 4 sinh viên. Giao các
bài tập 1, 2, 3 cho mỗi hóm. Yêu cầu mỗi nhóm trình bày phân tích rủi ro
của mình cho số nhóm còn lại trong líp.

Th¶o ln :

a) Các danh mục vấn đề dự liệu khác nhau.
b) Các kế hoạch ngẫu nhiên khác nhau.

</div>
(34)<div class='page_container' data-page=34>

Ch-¬ng ba

Phát triển phần mềm theo hợp đồng

Mối quan hệ khách hàng - nhà phát triển

Do những thay đổi nhanh chóng trong cơng nghệ trong vài thập niên
gần đây, các tổ chức công nghệ cao ngày càng thấy cần thiết phải chuyển
hóa trong các lĩnh vực đặc chủng, xác định rõ việc chuyển hóa khơng chỉ
xác định nhiều nhánh mới của cơng trình học mà cịn xác định những
lĩnh vực chuyên môn trong phạm vi các bộ môn công trình học. Điều này

đặc biệt đúng với cơng trình phần mềm.

Thơng th-ờng, các tổ chức khơng chun hóa trong phát triển phần
mềm lại thuê các tổ chức khác phát triển phần mềm cho họ. Ngay cả
những tổ chức có phát triển phần mềm của chính mình có thể quyết định
th các chuyên gia bên ngoài ở những lĩnh vực đặc chủng. IBM đã thuê
Mirosoft phát triển hệ điều hành PC DOS, vì Microft đã có kinh nghiệm
trong phát triển các hệ thống vi tính cịn IBM thì khơng.

Ch-ơng này đề cập đến mối quan hệ giữa khách hàng và nhà phát triển
phần mềm và cung cấp một số h-ớng dẫn làm sao tránh những cái bẫy cổ
điển do những lợi ích mẫu thuẫn nhau. Mổc dù nhiều những vấn đề đó là
chung cho mọi quan hệ khách hàng, nhà phát triển một số vấn đề tranh
cãi là đặc biệt cho phát triển phần mềm. Việc phát triển phần mềm là rất
ít xác định hơn và nhiều rủi ro hơn các lĩnh vực khác của công nghệ. Điều
này th-ờng dẫn đến những hiểu lầm và bất đồng đáng ra đã có thể tránh
đ-ợc nếu đ-ợc dự liệu và kiềm chế đủ sớm.

Để tiêu chuẩn hóa thuật ngữ của chúng ta, tổ chức mà đề nghị đ-ợc đệ
trình sẽ đ-ợc coi là khách hàng và tổ chức đệ trình đề nghị sẽ đ-ợc coi là
ng-ời đề nghị. Các từ khác th-ờng đ-ợc sử dụng ở nơi khác cho ng-ời đề
nghị bao gồm ng-ời đấu thầu, ng-ời bán hàng hay chủ thầu và cho khách
hàng là ng-ời yêu cầu hay ng-ời đề xuất yêu cầu. Tổ chức đ-a ra đề nghị
đ-ợc thẳng thầu sau khi lựa chọn, sẽ đ-ợc coi là nhà phát triển.

3.1. Chi phí cộng thêm đối lại với giá cố định.

Th-ờng vẫn có mâu thuẫn về quyền lợi thực sự hay t-ởng t-ợng giữa
khách hàng với ng-ời phát triển. Khách hàng thì muốn chi phí ít hơn và
ng-ời phát triển lại muốn thu nhập nhiều hơn. Nh- chúng ta sẽ thấy mối

quan hệ tốt giữa ng-ời phát triển và khách hàng không cần thiết phải dẫn
đến tranh chấp về quyền lợi nh- thế.

Cơ bản có 2 loại quan hệ theo hợp đồng giữa khách hàng và ng-ời sản
xuất.

</div>
(35)<div class='page_container' data-page=35>

2. Giá cố định

Hầu hết các quan hệ khác là một hình thức phối hợp nào đó giữa hai
loại đó.

3.1.1. Hợp đồng phí cộng thêm

Phí cộng thêm là mối quan hệ theo hợp đồng theo đó ng-ời phát triển
đ-ợc trả cho chi phí dịch vụ đã làm và thêm vào đấy đ-ợc phép h-ởng
mức lời thỏa thuận. Điều này thực ra giống nh- cho thuê ô tô: khách hàng
trả cho số thời gian xe đ-ợc sử dụng (theo giờ, ngày, tuần v.v...) và cho
mọi chi phí khác nh- bảo hiểm và xăng. Theo thế trong một hợp đồng phí
cộng thêm, tổng phí của một dự án chỉ đ-ợc biết sau khi dự án đã hồn
thành.

Lấy thí dụ, cơng ty Alpha có thể hợp đồng với cơng ty phần mềm Bêta
để phát triển một hệ thống. Công ty Bêta sẽ đ-ợc công ty Alpha trả cho
180 cho mỗi giờ các kỹ s- của minh đầu t- cho dự án một khoản 20% bổ
sung có thể đ-ợc thêm vào để bù đắp dịch vụ quản lý th- ký hay văn
phòng khác. Các chi phí phụ phát sinh bởi cơng ty Bêta vì lợi ích của dự
án sau đó đ-ợc cơng ty Alpha bồi hồn các chi phí đó có thể bù đắp các
lĩnh vực nh-:

- Thiết bị phát triển của mục đích đặc tr-ng (máy tính, các bộ dịch,

các mạng v.v...)

- Chi phí đi lại phát sinh bởi nhân viên công ty Bêta vì lợi ích của dự
án.

- Thiết bị mục tiêu do công ty Bêta cung cáp cho công ty Alpha sử
dụng.

- Dịch vụ từ các nguồn bên ngoài khác do công ty Bêta yêu cầu cho dự
án.

</div>
(36)<div class='page_container' data-page=36>

-c ban cho hợp đồng phí cộng thêm cho giai đoạn yêu cầu về công ty
khác đ-ợc ban cho các hợp đồng giá cố định với giai đoạn cịn lại.

Phí cộng thêm có thể đ-ợc chuộng ở khác hàng muốn nắm quyền kiểm
sốt q trình phát triển. Trong một số tr-ờng hợp, ng-ời sản xuất đ-ợc
coi nh- phần mở rộng của tổ chức của khách hàng và các hoạt động phát
triển do khách hàng quản lý.

Hợp đồng phí cộng thêm phải bao gồm các điều sau:
- Danh sách những ng-ời đ-ợc giao làm dự án

- Xác định cơng việc

- Tû lƯ phần trăm giao việc cho mỗi ng-ời

- Mức công việc hàng giờ hay hàng ngày cho mỗi ng-ời
- Tổng phí hµnh chÝnh

- Chi phí đ-ợc phép để đ-ợc bồi hồn

- Thủ tục làm hóa đơn

- Thđ tơc thanh to¸n
- Thđ tơc kÕt thóc

Phần trăm giao việc liên quan đến số thời gian mà mỗi ng-ời sẽ giành
cho dự án. Nó có thể là 100% cho một số kỹ s-, và 50-60% cho các
chuyên gia trong các lĩnh vực đặc biệt. Tỷ lệ phần trăm giao việc cũng có
thể đ-ợc tính hiểu theo tối đa hay tối thiểu, có nghĩa, chẳng hạn, một kỹ
s- bảo hành chất l-ợng sẽ giành không q 20 giờ mỗi tuần cho dự án và
khơng ít hơn 10 giờ mỗi tuần cho dự án.

Giá suất lập phiếu có thể là giá suất cố định cho mọi ng-ời đ-ợc giao
việc của dự án hay mức cá nhân có thể đ-ợc đặt cho từng lớp ng-ời.
Chẳng hạn với mỗi giờ làm việc cho dự án, ng-ời sản xuất sẽ lập phiếu
thanh toán $80, bất kể ai làm việc cho giờ đó. Hay hợp đồng có thể qui
định là kỹ s- thiết kế đ-ợc lập phiếu thanh toán $120 một giờ, ng-ời lập
mã $60 một giờ, ng-ời viết t- liệu $50 một giờ và cứ tiếp tục. Ph-ơng
pháp giá suất lập phiếu hợp đồng phí cộng thêm hầu nh- khó nhất là
ph-ơng pháp lập phiếu thanh tốn cá nhân theo Franh Jones đ-ợc lập
phiếu thanh toán $90 một giờ John Shith $75 v.v... Điều này có nghĩa mỗi
khi một ng-ời đ-ợc thay thế hay bổ sung cho dự án thì giá suất theo giờ
lại phải th-ơng thảo lại.

Đối với một tổ chức phát triển phần mềm, có thể có những thuận lợi
thiết thực trong các hợp đồng phí cộng thờm bao gm:

- Không có rủi ro tài chính hay kinh doanh

- Thu thËp biÕn thøc vµ kinh nghiƯm dùa vào một tổ chức khác.

Dự sao, nh- trong phn ln tr-ờng hợp, những thuận lợi đó lại đi đối
với một số bật lợi bao gồm:

- Lỵi tøc kihnh doanh thËp

- Có thể có sự bất bình trong nhân sự
- Kiểm tra nhân sự và công việc phát triển

- Bt ng tiềm ẩn với khách hàng do thiếu các bị giảm đi, mục đích
đ-ợc xác định rõ và nhân tố thúc đẩy.

</div>
(37)<div class='page_container' data-page=37>

Hầu hết nhân viên chuộng có đ-ợc xác định rõ ràng về tôn ti mà họ tùy
thuộc. Trong hợp đồng phí cộng thêm, nhân viên làm việc trong phạm vi
tôn ti của khách hàng nh-ng lại thuộc về tơn ti của ng-ời phát triển và
điều này có thể gây ra bất mãn.

Nói chung, theo quan điểm của ng-ời phát triển, hợp đồng phí cộng
thêm là mối quan hệ kinh doanh vững chãi, lợi tức thấp, không rủi ro.

Theo quan điểm của khách hàng thuận lợi của hợp ng phớ cng thờm
l:

- Duy trì sự khống chế phát triĨn

- Khơng cần cam kết cho tồn bộ hợp đồng dự án

- Rủi ro kinh doanh có thể giảm đ-ợc (do khả năng kết thúc hợp đồng
bất cứ lúc nào)

BÊt lợi có thể có của khách hàng là:
- Chi phí phát triển gia tăng

- Khỏch hng phi m nhn ri ro trong phát triển
- Tham gia nhiều hơn trong phát triển

- Bất đồng tiềm ẩn với ng-ời do thiếu mục đích xác định rõ và nhân tố
thúc đẩy.

Với khách hàng, khó xác nhận sự hấp dẫn của hợp đồng phí cộng
thêm. Rõ ràng điều này thùy thuộc ở loại dự án và điều kiện để dự án
phát triển cũng nh- ở nhận định kinh doanh không kỹ thuật khác.

3.1.2. Hợp đồng giá cố định

Hợp đồng giá cố định là một cam kết của ng-ời phát triển sẽ cung cấp
sản phẩm hay dịch dụ thỏa thuận với phí thỏa thuận trong phạm vi lịch
trình thỏa thuận. Điều này t-ơng tự với mua tíc kê xe bt theo đó cơng
đi xe bt thỏa thuận đ-a khách hàng đến nơi nhất định trong phạm vi
thời gian biểu đã cơng bố với phí thỏa thuận. Tờt nhiên, du khách có thể
chọn thuê xe chứ khơng mua tic kê xe bt và rồi tự mình lái đến nơi của
mình. Dù sao, điều này có thể trở nên tốn kém hơn và đòi hỏi ở ng-ời du
khách đôi chút kỹ năng và kiến thức tr-ớc nh- kỹ năng lái xe và kiến
thức về hành trình đến nơi. Nừu du khách (hay khách hàng) phải quyết
định giữa việc tự mình tạo ra dịch vụ và việc hợp đồng với ai đó để cung
cấp dịch vụ.

Hợp đồng giá cố định chỉ có thể đ-ợc vận dụng cho một dự án xác
định rõ. Cả khách hàng và ng-ời sản xuất phải có khả năng xác định sản
phẩm hay dịch vụ cuối cùng mong muốn. Một khi điều này để thực hiện

đ-ợc, một trong những yếu kém chính của hợp đồng cố định sẽ đ-ợc
khắc phục.

Lợi ích của hợp đồng giá cố định cho ng-ời phát triển là:
- Khống chế đầy đủ quá trình phát triển

</div>
(38)<div class='page_container' data-page=38>

- Cam kết cho dự án trọn vẹn là -u việt đáng kể so với hợp đồng phí
cộng thêm ở đó nó có thể kết thúc bất cứ lúc nào tùy sự xét đoán của
khách hàng.

Tất nhiên, hợp đồng giá cố định cũng có một số bất lợi cho ng-ời phát
triển, bao gồm:

- Đảm nhận rủi ro kinh doanh và phát triển
- Bất đồng tiềm ẩn với khách hàng do:
+ thay đổi yờu cu liờn tip

+ tiêu chuẩn hoàn thành dự án
+ giải thích yêu cầu

Mt t chc phn mm thng li sẽ th-ờng chuộng hợp đồng giá cố
định. Đó th-ờng là những dự án tạo dựng danh tiếng chuyên môn của
công ty và phát sinh lợi tức đảm bảo tăng tr-ởng. Bất hạnh là những dự
án này cũng gây ra lỗ và th-ờng tác hại nghiêm trọng cho công ty cạnh
tranh gay gắt để có hợp đồng quan trọng đơi khi làm cho công ty nhận
thầu giá thấp cuối cùng gây ra lỗ cho ng-ời phát triển.

Hầu nh- không thể tránh khỏi trong bất kỳ dự án nào ng-ời phát triển
đ-ợc địi hỏi thay đổi u cầu trong q trình phát triển. Những thay đổi
nh- thế th-ờng đi liền với chi phí bổ sung địi khánh hàng và bao giờ

cũng là nguyên nhân bất đồng giữa ng-ời sản xuất và khách hàng. Điều
này th-ờng là do yêu cầu không rõ hay mơ hồ và nó lại dẫn đến bất đồng
về chỉ tiêu trong việc hoàn thành dự án. Về cơ bản, điều này làm cho hợp
đồng trở lại trạng thái không đ-ợc xác định đầy đủ.

Theo quan điểm của khách hàng, -u việt của hợp đồng giá cố định bao
gồm:

- Ngân sỏch c nh cho d ỏn

- Hầu hết các rủi ro phát triển đ-ợc chuyển sang ng-ời phát triển
+ tham gia tối thiểu trong quá trình phát triển

Bất lợi cho khách hàng là:
- Rủi ro chậm giao sản phẩm

- Gim sự khống chế quá trình phát triển
- Bất đồng tiềm ẩn với ng-ời sản xuất do:
+ chi phí cao về thay i yờu cu

+ chỉ tiêu hoàn thành dự án không rõ ràng
- giải thích yêu cầu

Ngay dự quyn li của ng-ời sản xuất và khách hàng có thể khác nhau,
với hợp đồng giá cố định vẫn th-ờng đ-ợc cả hai bên -a chuộng. Nừu dự
án là chi tiết đủ mức và rõ ràng và nếu quan hệ giữa hai bên đ-ợc xác
định rõ thì các hợp đồng giá cố định có thể có lợi cho cả ng-ời phát triển
lẫn khách hàng.

</div>
(39)<div class='page_container' data-page=39>

Phí cộng thêm và giá cố định là hai trong số mối quan hệ theo hợp

đồng cổ truyền giữa ng-ời phát triển và khách hàng. Có nhiều biến thức
của hai mối quan hệ cơ bản đó kể cả các ghép nối phù hợp với các dự án
đặc tr-ng. Một số trong những quan hệ đó liên kết với vai trò của khách
hàng và ng-ời phát triển nhằm tạo nhiều yếu tố kích thích hơn cho ng-ời
phát triển hỗ trợ mục tiêu của khách hàng ngoài những tránh nhiệm theo
hợp đồng.

Những loại khác của quan hệ khách hàng - ng-ời phát triển bao gồm:
- Phối hợp giá cố định và phí cộng thêm

- Liªn doanh

- Tháa thn bản quyền
- Cam kết lâu dài

phn 3.1. chỳng ta đã xem xét một thí dụ về dự án phối hợp phí cộng
thêm và giá cố định trong đó phần các yêu cầu đ-ợc phát triển theo phí
cộng thêm và các phần còn lại của dự án phát triển theo gớa c nh.

Liên doanh là những tr-ờng hợp mà ranh giới giữa khách hàng và
ng-ời phát triển có thể trở nên mờ ảo và phiền những thuận lợi và bất lợi
thảo luận tr-ớc đây có thể không vận dụng đ-ợc. Có nhiều tr-ờng hợp mà
một số hình thức liên doanh có thể là mong muốn cho hai bên nh- khi
ng-ời phát triển muốn duy trì quyền về sản phẩm, hay khi ng-ời phát
triển chung sức với khách hàng tài trợ một phần của cố gắng phát triển.

Cú mt cỏch m khách hàng có thể chào ng-ời phát triển tham gia vừa
phải vào mặt kinh doanh của dự án là bằng cách thay thế bản quyền coi
nh- thanh toán một phần. Điều này tạo nên qui mô bổ sung cho lợi ích
của ng-ời phát triển trong thành công của dự án. Bản quyền thông th-ờng

là ở chỗ thất bại của dự án có thể tạo nên ít lợi nhuận cho ng-ời phát triển
hơn là một hợp đồng giá cố định thẳng thừng và thắng lợi của dự án sẽ
làm tăng lợi nhuận của ng-ời phát triển.

Mối quan hệ lâu dài th-ờng là quan trọng cho ng-ời phát triển. Trong
nhiều tr-ờng hợp, những cam kết dài hạn cũng nằm trong lợi ích của
khách hàng. Điều này xảy ra khi ng-ời phát triển do gắn bó ở hợp đồng
ban đầu, giành đ-ợc lợi thế chủ yếu, qua kiến thức thu l-ợm, đối với
những ng-ời khác cho công việc phát triển tiếp sau. Rõ ràng khi ng-ời
phát triển hoàn thành thắng lợi một dự án lớn và phức tạp, anh ta có đ-ợc
một lợi thế đáng kể so với các công ty khác về các tăng c-ờng trong
t-ơng lai của dự án đó. Cam kết lâu dài theo đó có thể có lợi ích t-ơng hỗ
cho cả hai bên trong đó khách hàng đảm bảo các dịch vụ sau này của
ng-ời phát triển và ng-ời sản xuất đảm bảo cam kết thu nhập lâu dài.

3.3. Yêu cầu đối với một đề xuất (RFP).

</div>
(40)<div class='page_container' data-page=40>

RFP cần đ-ợc chuẩn bị thế nào, tr-ớc hết chúng ta hãy duyệt lại các b-ớc
dẫn tới một quyết định đ-a ra yêu cầu về đề nghị.

Trong ph-ơng pháp tiếp cận theo pha để phát triển phần mềm, thì pha
tiềm dự án th-ờng đ-ợc xem là pha thai nghén. Đây là giai đoạn mà ý
t-ởng đằng sau dự án kết tinh và hình thành dự án.

Đây cũng là giai đoạn mà tổ chức quyết định xem dự án có thể đ-ợc
phát triển nội bộ hay sẽ phải hợp đồng với một công ty khác. Các RFP
không chỉ đ-ợc phát ra cho các dự án hồn chỉnh; chúng cũng có thể
đ-ợc phát ra để bảo d-ỡng phần mềm của một hệ thống hiện có hay cho
riêng một pha đơn lẻ của dự án. Mọi RFP chuẩn bị kỹ phải có cũng thơng
tin cơ bản; các RFP khơng hồn chỉnh cho kết quả là các đề nghị khơng

hồn chỉnh.

3.3.1. Một số vấn đề cơ bản.

Tr-ớc khi thuê các dịch vụ phát triển của một tổ chức khác, một số vấn
đề cơ bn cn -c xem xột ti:

- Các mục tiêu của dự án là gì ?

- Cỏc t chc no l gì đ-ợc xem xét cho cơng việc đó ?

- Loại hợp đồng nào sẽ đ-ợc chào (giá cố định, phí cộng thêm v.v...)
- Phải nhận đ-ợc các đáp ứng nào từ các nhà phát triển sao cho đáp
ứng đó có thể đ-ợc xem xét ?

- Khi nào quá trình lựa chọn ng-ời phát triển phải đ-ợc hòan tất ?
- Khi nào dự án phải hoàn thành và khi nào các hợp đồng trung gian
phải sẵn sàng ?

- Ai, trong tæ chức, đ-ợc ủy thác trách nhiệm lựa chọn ng-ời phát triÓn
?

- Mức ngân sách nào đ-ợc giành cho hợp đồng ?

Tất cả những vấn đề trên phải đ-ợc nêu ra đầy đủ tr-ớc khi sang b-ớc
sau: việc chuẩn bị các RFP.

3.3.2. Chuẩn bị các RFP.

Yờu cu tt vi ngh là yêu cầu sẽ lôi cuốn đ-ợc những đáp ứng tốt

nhất (đề nghị). Chuẩn bị RFP tốt th-ờng đòi hỏi sự cộng tác của nhiều
ng-ời, mỗi một ng-ời đ-ợc giao trách nhiệm về những phần đặc biệt của
RFP.

Một RFP phải bao gồm những phần sau:
1. Phát triển vấn đề và các mục tiêu dự án.

Phần này cung cấp thông tin nền tảng chung, kể cả mô tả vấn đề cần
đ-ợc giải quyết. Phần này phải cung cấp mọi chi tiết thích đáng cần thiết
để hiểu vấn đề, kể cả biểu , bỏo cỏo v thớ d.

2. Các yêu cầu kỹ thuật.

</div>
(41)<div class='page_container' data-page=41>

- Yêu cầu cơ sở dự liệu (nh- khả năng yêu cầu, các quan hệ dữ liệu
v.v...)

- Truyền thông và kiến trúc mạng

- Các chuẩn quân sự, chuẩn chính quyền hay các chuẩn đ-ợc yêu cầu
khác

- Ph-ơng pháp luận phát triển yêu cầu
- Độ tin cậy của hệ thống

- Ràng buộc về thời gian
- Ngôn ngữ lập trình

- Máy tính chủ (host computer)
3. Thông tin quân sự

Phn này cung cấp thơng tin liên quan đến việc trình bày về thể chất đề
nghị nh-:

- Ai cã thĨ tr¶ lêi cho RFP

- Yêu cầu làm sáng tỏ và các thông tin bổ sung thế nào
- Ngày tháng và địa điểm họp theo lịch với các nhà đề nghị
- Chỉ tiêu lựa chọn đề nghị

Phần này cũng có dự phịng về kết quả là tổ chức đ-a ra RFP sẽ khơng
bị bắt buộc lựa chọn đề nghị chi phí thấp nht hay bt c ngh no
khỏc.

4. Yêu cầu chi phÝ

Mọi vấn đề tài chính đ-ợc nêu ở phần này. Điều này bao gồm cơ cấu
giá yêu cầu trong đề nghị cũng nh- mọi thông tin đặc tr-ng đ-ợc nêu
trong đề nghị (nh- giải trình chi phí tổng cộng hay lập giá riêng cho mỗi
pha). Phần này cũng có thể nêu rõ loại hợp đồng phát triển nào đ-ợc chào
(bản quyền, phí cộng thêm, giá cố định v.v...)

5. T- liƯu tham khảo

Phần này bao gồm danh sách mọi t- liệu nªu trong RFP nh- tiªu
chn, t- liƯu hƯ thèng hiƯn có, tài liệu về sản phẩm khác v.v...

6. Những thứ giao đ-ợc có yêu cầu

Phn ny bao gm gii thớch ban đầu về tuyến bố công việc (Sow).
Chủ yếu đây là danh sách những thứ giao đ-ợc chính của dự án nh-

t-liệu, phần mềm, đào tạo và mọi phần cứng hay thiết bị thích đáng. Phần
này cũng thảo luận việc bảo đảm theo yêu cầu cho hệ thống sẽ đ-ợc giao.

7. Định dạng đề nghị yêu cầu

Định dạng tiêu chuẩn yêu cầu cho đề nghị đ-ợc mô tả ở phần này.
Điều này bao gồm nội dung yêu cầu về:

- Đề nghị kỹ thuật
- Đề nghị quản lý
- Đề nghị về giá cả
- Tuyên bố về công việc

Thớ d v một phác họa đề nghị có nêu ở phần 3.4

</div>
(42)<div class='page_container' data-page=42>

báo cáo tài chính mới nhất của tổ chức ng-ời đề nghị hay ủy nhiệm
th-kỹ thuật của ng-ời đề nghị.

8. Đệ trình lịch trình và lịch quyết định

Những thời hạn quyết định liên quan đến RFP đ-ợc mơ tả ở phần này.
Nó bao gồm thời gian chậm nhất cho việc đệ trình một đề nghị và ngày
dự kiến tiến hành lựa chọn. Nó cũng có thể bao gồm lcịh trình mong
muốn để hồn thành cơng việc phát triển.

Một trong những mục tiêu của RFP là làm cho nhiệm vụ so sánh các
đề nghị đ-ợc dễ dàng. Nhiệm vụ này có thể trở nên cực kỹ khó nếu mọi
đề nghị đ-ợc cấu tạo khác nhau hay nếu các đề nghị đó đ-ợc dựa trên
những giả định rất khác nhau. Phần 3 của phác thảo nói đến cuộc họp với
mọi ng-ời đề nghị. Cuộc họp này tạo cơ hội đảm bảo là mọi ng-ời đề

nghị đều có một cơ sở chung về hiểu biết và kết quả trong các đề nghị
của họ dễ so sánh hơn. Nó cũng thành đạt khi u cầu khn dạng đề
nghị tiêu chuẩn hóa, nêu ở phần 7 của RFP. Bảng 3.1. có nêu phỏc tho
i khỏi ca mt RFP.

Bảng 3.1. Phác thảo khái qu¸t cho mét RFP

1. Tuyên bố vấn đề và mục tiờu d ỏn
- Mụ t hin trng

- T- liệu hỗ trợ

các báo cáo

cỏc biu

cỏc thớ d
- Mụ t vn

- Các mục tiêu
2. Yêu cầu kỹ thuật

- Giao diện với các hệ thống hiện có
- Truyền thông và kiến trúc mạng
- Độ tin cậy của hệ thống

- Ngôn ngữ lập trình
- Yêu cầu cơ sở dữ liệu

- Tiêu chuẩn quân sự hay chính quyền

- Ràng buộc thời gian

- Máy tính chủ
3. Thông tin quản trị

- Ai cú th ỏp ứng cho RFP

- Ngày tháng và địa điểm cuộc họp theo lịch với mọi ng-ời đề nghị
ng-ời đ-ợc chọn- Làm sao yêu cầu sáng tỏ hay thông tin bổ sung

- Tiêu chuẩn lựa chọn đề nghị
- Các thông tin quản tr khỏc
4. Yờu cu chi phớ

</div>
(43)<div class='page_container' data-page=43>

các dịch vụ
các sản phẩm
cung cấp

- Biện minh cho chi phí
- Lập giá riêng từng pha

- Loi hp ng phỏt trin -a cho

- So sánh chi phí của các giải pháp thay thế
5. T- liệu tham khảo

- Các tiêu chuẩn

- T- liệu vỊ hƯ thèng hiƯn cã
- T- liƯu vỊ s¶n phÈm

6. Yêu cầu chuyển giao
- T- liệu

- Phần mềm

- Phần cứng hay thiết bị thích ứng
- Bảo hành hệ thống sẽ chun giao
- T- liƯu vỊ s¶n phÈm chun giao
- Hn lun

- Các cơng cụ phát triển và thử nghiệm
7. Định dng ngh

- Đề nghị kỹ thuật
- Tuyên bố công việc
- Đề nghị quản lý
- Bổ sung và phụ lục

+ báo cáo tài chính của tổ chức đề nghị
+ ủy nhiệm th- kỹ thuật của ng-ời đề nghị
+ Tóm tắt nhõn s ch lc

- Đề nghị lập giá

8. Lch trình và lịch quyết định
- Hạn cuối cùng phải đệ trình đề nghị
- Hạn dự kiến tiến hành lựa chọn

- Lịch mong muốn hoàn thành công việc phát triển

3.3.3. Phỏt yờu cu xut RFP

Có pha ph-ơng pháp cơ bản trong phần phát một RFP
- Theo một danh mục phân phát hạn chế

- Theo một danh mục phân phát rộng
- Cho mọi ai yêu cầu

</div>
(44)<div class='page_container' data-page=44>

danh mục các công ty đ-ợc công nhận cho mỗi lớp RFP. Ph-ơng pháp
này loại trừ các tổ chức ít có cơ may, ®-ỵc lùa chän.

Danh mục phân phát rộng bao gồm bất cứ tổ chức nào có chút ít cơ
may đ-ợc lựa chọn. Với một tổ chức đ-ợc bổ sung vào danh mục chỉ yêu
cầu điều đó. Các danh mục phân phát rộng có thể thích hợp cho những dự
án nhỏ, những dự án khơng địi hỏi giám định đặc biệt nào hay những dự
án mà ít tổ chức thích hợp đã nhắm vào.

Không phải không phổ biến là thông tin RFP ban đầu đ-ợc quảng cáo
trong báo chí hay tạp chí chuyên ngành. Những quảng cáo đã mô tả vắn
tắt RFP và mời các cơng ty u cầu bản sao tồn bộ RFP. Sự tiếp cận này
th-ờng là thích hợp khi phải tìm kiếm những ng-ời đề nghị tiềm ẩn mới.

Bất kể ph-ơng pháp phân phát nào đ-ợc chọn lựa, tổ chức đề xuất RFP
phải nhớ là thủ tục đề xuất không kết thúc cùng với sự phân phát RFP. Tổ
chức phân phát phải sẵn sàng cung cấp mọi thông tin bổ sung và làm
sáng tỏ những điều có thể đ-ợc yêu cầu. Có một cách để thực hiện điều
này là (nh- đã nêu). Định lịch họp với mọi ng-ời đề nghị tiềm ẩn nhằm
làm sáng tỏ và trả lời mọi câu hỏi. Cuộc họp này cũng là một cơ hội cho
các ng-ời đề nghị đi xem một l-ợt các thiết bị mục tiêu và biết đ-ợc tận

mắt những vấn đề s -c d ỏn gii quyt.

3.4. xut

Các loại kiến nghị có thể phần thành 2 phạm trù cơ bản:
- Kiến nghị do yêu cầu

- Kiến nghị không yêu cầu

Kin nghị do yêu cầu đáp ứng hoặc RFP chính thức hoặc lời mời đặc
biệt để trình kiến nghị trong khi kiến nghị không do yêu cầu thông
th-ờng do ng-ời đề nghị x-ớng xuất. Tất nhiên có nhiều tổ hợp của hai
biểu đó ví nh- tình huống kỳ dị nh-ng th-ờng thấy khi một kiến nghị
không do yêu cầu làm nảy sinh vic xut RFP chớnh thc.

3.4.1. Đề xuất không do yêu cầu

Nhng kin ngh khụng do yờu cu ớt chính thức hơn nhiều so với kiến
nghị do yêu cầu và th-ờng khơng là gì hơn là một b-ớc đầu dẫn đến
những th-ơng thảo chính thức hơn. Kiến nghị khơng do yêu cầu phải có
những phần cơ bản sau:

1. Biện minh việc đệ trình kiến nghị
2. Mơ tả vấn đề phải giải quyết
3. Mơ tả giải pháp đề nghị

4. M« tả tổ chức của ng-ời kiến nghị

5. Tng quan chung về kinh phí của giải pháp đề nghị

</div>
(45)<div class='page_container' data-page=45>

lời cho câu hỏi của khách hàng: “Vì sao cơng ty lại tiếp cận tơi và vì sao
đọc kiến nghị này là lợi ích cho tơi vậy ?”

Các phần 2 và 3, mô tả cách mà kiến thức chuyên môn hóa của ng-ời
đề nghị đ-ợc vận dụng vào các vấn đề của tổ chức khách hàng. Điều này
đòi hỏi ng-ời đề nghị nghiên cứu tổ chức của khách hàng nhằm đảm bảo
là kiến nghị cung cấp một giải pháp thực cho một vấn đề thực.

Chi phí chính xác của giải pháp không cần nêu ở giai đoạn này. Một
kiến nghị không do yêu cầu hiến khi đ-ợc chấp nhận ngày vịng đầu.
Mục tiêu chính của nó là tạo dựng một mối quan tâm. Nếu kiến nghị tạo
đủ mối quan tâm thì ng-ời đề nghị sẽ đ-ợc mời thảo luận kiến nghị đó và
sau đó sẽ đệ trình lại cho khách hàng một bản trình bày kiến nghị chi tiết
hơn.

3.4.2. §Ị xuất khi có yêu cầu

Kin ngh do yờu cu m khách hàng x-ớng xuất coi nh- đáp lại RFP
chính thức hay một hình thức mời nào khác đệ trình kiến nghị. Trái với
tính chất khơng chính thức của kiến nghị khơng do u cầu, kiến nghị do
u cầu là hồn chỉnh và chi tiết và nội dung th-ờng ràng buộc cho ng-ời
đề nghị (kiến nghị coi nh- văn bản ràng buộc đ-ợc thảo luận thêm và
minh họa ở lời nói đầu ch-ơng 10). Cùng với yêu cầu đệ trình kiến nghị,
khách hàng cũng có thể dẫn chính xác kiến nghị phải đ-ợc chuẩn bị thể
bào và đệ trình ra sao. Một thí dụ về dạng kiến nghị chính thức có ở bảng
3.2.

Một lĩnh vực cơ bản khiến kiến nghị do yêu cầu và không do yêu cầu
khác nhau là ở nhu cầu cạnh tranh. Các kiến nghị do yêu cầu phải có khả
năng cạnh tranh thắng lợi với các kiến nghị khác. Điều này có nghĩa là

việc chuẩn bị kiến nghị do yêu cầu phải đ-ợc coi bản thân nó là một dự
án mini và nh- thế địi hỏi hình thành một đội ngũ chuẩn bị kiến nghị.

3.4.3. Đội ngũ chuẩn bị đề xuất.

Việc hình thành ban kiến nghị là cơ bản cho bất cứ tổ chức nào dự tính
đáp ứng thành công một RFP. Ban này chỉ định ng-ời có nhiệm vụ định
vị những RFP thích hợp và độ trình để thảo luận căn cứ đ-ờng lỗi chỉ đạo
do ban đề ra. Đ-ờng lối chỉ đạo phải nhằm vào cỏc RFP m:

- nằm trong phạm vi đ-ờng lỗi kinh doanh cđa c«ng ty

- nằm trong phạm vị giới hạn kích th-ớc đặc tr-ng (dự án khơng q
nhỏ và khơng q lớn).

- khơng hiển nhiên loại trừ chính cơng ty (thí dụ u cầu giám định
đặc biệt hay hồn thành về an ninh).

Căn cứ ở đánh giá của ban về các RFP đek trình, ban kiến nghị quyết
định RFP nào là đáp ứng đ-ợc bởi công ty.

</div>
(46)<div class='page_container' data-page=46>

mäi nhân viên công ty và nếu cần có thể sử dụng dịch vụ của các chuyên
gia bên ngoài hỗ trợ trong viƯc chn bÞ kiÕn nghÞ.

Kiến nghị cơ bản u cầu trong phạm vi đội ngũ chuẩn bị kiến nghị
bao gồm:

- Kiến thức kỹ thuật liên quan đến mỗi lĩnh vực riêng rẽ do kiến nghị
l-u ý

- Qu¶n lý dù án kể cả dự toán và lập kế hoạch

- Kin thức tài chính, kể cả định ngân sách và lập kế hoạch tài chính
cho tồn bộ dự án

- Quen thc với tổ chức của khách hàng
- Kinh nghiệm trong soạn thảo kiến nghị

Mt thnh viờn ca i ng s -c ban chỉ định lãnh đạo đội hay điều
phối viên. Sau khi đội ngũ đã hình thành, hai việc ủy thác u tiờn ca nú
l:

1. Duyệt xét b-ớc đầu RFP

2. Chun bị lịch trình cho việc hồn thành dự án và giao trách nhiệm.
Việc chuẩn bị kiến nghị tốt tốn tiền và phải đ-ợc coi nh- là một đầu t-.
Nừu việc này làm tốt, nó có thể tạo ra lợi nhuận, ngân sách kiến nghị
khơng thích hợp sẽ giảm cơ may tạo ra kiến nghị thắng đ-ợc các thành
viên của đội ngũ chuẩn bị kiến nghị phải đ-ợc tập trung vào nhiệm vụ và
họ phải đ-ợc cung cấp nguồn lực thích hợp.

Theo Silver (1986), các kiến nghị trong công nghệ cao và các công
nghiệp hành không vũ trụ đ-ợc cấp ngân sách khoảng 2% trị giá hợp
đồng, dù sao, phạm vi chi phí. Kiến nghị là 1% đến 10%. Chi phí hợp
đồng càng cao, phần trăm dành cho chuẩn bị kiến nghị càng thấp.6

3.4.4. Khuôn dạng đề xuất

Kiến nghị tốt phải trả lời đ-ợc 6 câu hỏi cơ bản: ai, cái gì. tại sao, thế
nào, khi nào, và bao nhiêu. Đáp án cho các câu hỏi đó đơn giản liên quan

đến:

1. Ai là tổ chức đệ trình kiến nghị ?
2. Cái gì đ-ợc đề nghị ?

3. Tại sao kiến nghị đ-ợc trỡnh ?

4. Làm sao công việc kiến nghị đ-ợc thực hiện ?
5. Khi nào nó sẽ đ-ợc phát triển xong và bàn giao ?
6. Bao nhiêu chi phí ?

6 Silver đ-a ra, phạm vi hợp đồng dự án $10K đén $2B với phạm vi chi

</div>
(47)<div class='page_container' data-page=47>

Câu hỏi tại sao là quan trọng cho một kiến nghị không do yêu cầu và
tạo cơ sở cho việc đệ trình nó. Đáp án cho một RFP chỉ cần khẳng định 
Kiến nghị này đ-ợc đệ trình để phúc đáp yêu cầu đ-ợc kiến nghị cuả
công ty Acme Inc số 456 ngy 5/6....

Năm câu hỏi khác đ-ợc nhằm vào 5 hợp phần chính của kiến nghị
1. Kiến nghị kỹ thuật (cái gì, làm sao)

2. Kin ngh qun lý (lm sao, khi nào)
3. Kiến nghị định giá (bao nhiêu)
4. Tuyên bố công vic (cỏi gỡ, khi no)

5. Tóm tắt điều hành và trong phần bổ sung bao gồm:
- Nền tảng và kinh nghiƯm cđa c«ng ty (ai)

- Trình độ chun mơn của nhân sự chủ lực
- Các chứng vật và văn bản thớch hp

Bảng 3.2. Một khái lựợc cho một kiến nghị kü thuËt

1. Tổng quan về vấn đề cần giải quyết
2. Tổng quan về giải pháp kiến nghị
3. Hợp phần cần mua

4. Hợp phần cần phát triển
5. Thiết bị

- Cơ sở hạ tầng

- Phn cng mỏy tớnh
- Truyn thụng v mng
- Thiết bị thử và kiển nghiệm
- Thiết bị đặc biệt khác
- Giao diện với các hệ khác
6. Hợp phần phần mm
- Mụ t chung h phn mm

- Mô tả chi tiết từng hợp phần, phần mềm chủ yếu
- Các giao diện với các hệ khác

- Các cơ sở dữ liệu

- Sử dụng các hợp phần, phần mềm hiện có

- Khả năng sử dụng lại các hợp phần, phần mềm cần phát triển
7. Công trình nhân văn và giao diện ng-ời sư dơng

8. Nhận xét đặc biệt
- Độ tin

</div>
(48)<div class='page_container' data-page=48>

Bảng 3.3. Một khái l-ợc cho kiến nghị quản lý

1. Công cụ và tiện ích phát triển
2. Môi tr-ờng phát triÓn

3. Yêu cầu nhân sự và cơ cấu đội ngũ phát triển
4. Ph-ơng pháp luận phát triển

5. C¸c pha ph¸t triển
6. Xét duyệt

7. Báo cáo

- Các loại báo cáo
- Khuôn dạng báo cao
- Chu kỳ báo cáo
- Danh mục phân phối
8. Các chủ thầu phụ
9. Các tiêu chuẩn
10. Thử nghiệm:

- Các giai đoạn thử nghiệm
- Thủ tục thử nghiệm chính thức
- Phát hiện và hiệu chỉnh sai
11. Kiểm tra chất l-ợng
12. Quản lý cấu hình
13. Bảo d-ỡng

14. Lịch

- Danh mc hoạt động chủ u
- Các cột mốc

- C¸c phơ thc

- Bố trí và cung cấp nhân lực
15. Quản lý rủi ro

Bảng 3.4. mẫu khái l-ợc cho kiến nghị định giá

1. Loại hợp đồng (phí cộng thêm, giá cố định v.v...)
2. Chi phí phát triển do hợp đồng phần dự án

3. Các chi phí chủ thầu phụ
4. Các chi phí mua sắm
5. Tổng phí

6. Bảo hành
7. Lợi nhuận

8. Tổng chi phí dự án

9. Loại tài trợ (không có, có)
10. Lịch thanh to¸n

</div>
(49)<div class='page_container' data-page=49>

Tóm tắt điều hành là đặc biệt quan trọng cho những kiến nghị lớn và
phức tạp vì không phải tất cả thành viên ban tuyển chọn đều sẽ đọc kiến

nghị. Tóm tắt phải dài khoảng 1 đến 6 trang và nên có tham chiếu tới các
lĩnh vực đặc tr-ng trong dự án tồn bộ ở đó có đầy đủ chi tiết hơn.

Các bảng 3.2; 3.3 và 3.4 giới thiệu các thí dụ khái l-ợc cho các kiến
nghị kỹ thuật, quản lý và định giá của một dự án phần mềm.

3.4.5. Khẳng định công việc (Sow)

Khẳng định công việc là cơ sở của hợp đồng giữa ng-ời đề nghị và
khách hàng và th-ờng đ-ợc lồng trong hợp đồng Sow bao gồm danh mục
chi tiết mọi công việc mà ng-ời đề nghị phải thực hiện vì lợi ích của
khách hàng Sow bắt đầu bằng danh mục chung các thứ bàn giao theo yêu
cầu trong RFP. Bản chi tiết hơn của sow đ-ợc đệ trình coi nh- bộ phận
của kiến nghị và vẫn chỉ đ-ợc coi là mô tả b-ớc đầu của cơng việc phải
hồn thành. Bản giải thích có tính chất ràng buộc của sow đ-ợc kết thúc
trong quá trình th-ơng thảo hợp đồng hay sau khi các yêu cầu chi tiết của
dự án đã hoàn tất.

Bảng 3.5. Giới thiệu một thí dụ về đại thể Sow cho một dự án phần
mềm.

Danh sách hạng mục thay đổi nhiều, tùy thuộc ở loại dự án đ-ợc phát
triển. Chẳng hạn không phải mọi dự án đều bao gồm việc bàn giao các
hợp phần phần cứng và không phải mọi dự án ũi hi hun lun hay lp
t.

Bảng 3.5. Một phác thảo SOW mẫu cho một dự án phần mềm

1. Văn bản tham chiếu
- Đặc tả yêu cầu

- Mô tả hệ thống hiện có
- RFP của khách hàng

- Đề nghị của ng-ời phát triển

- Tài liệu kỹ thuật của ng-ời bán và ng-ời phát triển
2. Các phần bàn giao đ-ợc về phần mỊm

- Tính chức năng (nh- dẫn trong đặc tả u cầu)
- Danh mục hợp phần phần mềm chủ yếu

3. Các phần bàn giao đ-ợc về thiết bị và phần cứng
- Tính chức năng (nh- dẫn trong đặc tả yêu cầu)
- Danh mục hợp phần phần cứng chủ yếu

4. HuÊn luyÖn

- Các lớp cho ng-ời sử dụng
- Huấn luyện ng-ời vận hành
- Huấn luyện lắp đặt

</div>
(50)<div class='page_container' data-page=50>

7. Gi¸m s¸t các chủ thầu phụ
8. T- liệu

- T- liệu phát triển
- T- liƯu cđa ng-êi dïng
- T- liƯu b¶o d-ìng
- T- liƯu kü tht kh¸c
9. Thư nghiƯm

- Thư nghiƯm alpha
- Thư nghiƯm beta

- Thử nghiệm nghiệm thu (ATP)
10. Lắl đặt

11. C¸c dịch vụ bảo d-ỡng

12. Các dịch vụ khác và hạng mục bàn giao đ-ợc khác
13. Ph-ơng pháp bàn giao

- Phần mỊm
- T- liƯu
- PhÇn cøng

H-ớng dẫn cơ bản cho việc chuẩn bị Sow là bất cứ hoạt động nào, dịch
vụ hay sản phẩm nào mà khách hàng yêu cầu và đ-ợc ng-ời sản xuất thỏa
thuận phải có trong Sow. Điều này có nghĩa là có thể có hạng mục cơng
việc khơng bắt buộc đ-ợc hiểu một cách khơng chính thức hay thỏa thuận
miệng mà khơng có trong Sow. Sow chính thức phải bao gồm tồn bộ
cơng việc phải hồn thiện và chỉ các cơng việc đó thơi. Điều kiện này
phịng ngừa hiểu lầm và bất đồng sau này sau khi dự án bắt đầu.

3.5. Duyệt xét đề xuất và quá trình lựa chọn.

Sau khi kiến nghị đ-ợc đệ trình, quá trình duyệt xét theo quan điểm kỹ
thuật. Khơng thể chối cãi là, q trình duyệt xét cịn lâu mới trở thành kỹ
thuật thuần túy. Có ít q trình tuyển chọn kiến nghị là hoàn toàn khách
quan. Các ban tuyển chọn bao gồm những con ng-ời, tất cả họ đều có

những sở thích riêng và khuynh h-ớng riêng của mình.

Trên thực tế, có nhiều tr-ờng hợp mà q trình tuyển chọn kiến nghị là
hoàn toàn chủ quan, Điều này bao gồm những tr-ờng hợp do ảnh h-ởng
cá nhân, sự quen thuộc và tính bạn bè giữa khách hàng và chủ thầu (định
kiến) khơng có cơ sở có lợi cho 1 cơng ty hay thành kiến khơng có cơ sở
chống cơng ty khác. Những tình huống đó khó mà khắc phục đ-ợc và
th-ờng khó phát hiện hơn. Những tình huống này có thể bị đấu tranh
khắc phục với ít nhiều hiệu quả thông qua việc bán hàng theo tâm lý và
kỹ thuật marketing, ngoài phạm vi cuốn sách này.

</div>
(51)<div class='page_container' data-page=51>

Ban tuyển chọn kiến nghị là một nhóm ng-ời đ-ợc chỉ định duyệt xét
và đánh giá các dự án và khuyên dùng một trong những kiến nghị theo bộ
tiêu chí xác định tr-ớc. Điều này có thể là bộ h-ớng dẫn chung hay một
bộ các yếu tố và thủ tục đánh giá cực kỳ hình thức.

Nhiều tổ chức lớn đã hình thức hóa thủ tục đánh giá kiến nghị.7 Điều

này thơng th-ờng bao gồm ba kênh riêng biệt về quản lý kỹ thuật và đánh
giá chi phí. Mỗi hợp phần của kiến nghị đ-ợc phân cấp theo các thủ tục
đánh giá đặc biệt và sự phối hợp các cấp cá biệt tạo nên cấp cuối cùng
cho kiến nghị.

Các kiến nghị về các dự án nhỏ cũng nh- lớn hẳn nên đ-ợc đánh giá
theo một thủ tục có tính hệ thống và t-ơng đối khách quan. Căn cứ ở việc
đánh giá kiến nghị, ban tuyển chọn kiến nghị mới đệ trình lời của mình
cùng với một tóm tắt các dữ liệu các tính tốn và các giá dẫn đến việc
tuyển chọn đó. Th-ờng khi có 2 hay 3 lời tiền cử đ-ợc độ trình và việc tái
diễn lần hai đ-ợc bắt đầu với những công ty đã đ-ợc chọn nhằm chọn ra
đ-ợc kiến nghị thắng cuộc.

Danh sách các công ty tuyển chọn lại lần hai th-ờng đ-ợc gọi là danh
mục vắn và vòng hai của các thảo luận về kiến nghị đ-ợc gọi là vòng
chọn đề nghị tốt và cuối cùng.

3.5.2. Ph-ơng pháp đánh giá đề xuất.

Bảng 3.6. Trang định mức mẫu trong vic ỏnh giỏ kin ngh.

Cấp Loại Mô tả

9-10 Xut sắc Mức độ kiến thức hay tài năng chuyên môn cao;
xứng đáng đ-ợc chấp nhận, dễ hiểu, điều chê trách
rất ít.

7-8 Tốt Trình độ chun mơn hay kiến thức khả quan;
chấp nhận đ-ợc, dễ hiểu, nói chung khơng địi hỏi
bổ sung thêm thơng tin hay làm sáng tỏ.

5-6 Đ-ợc Trình độ chuyên môn hay kiến thức chấp nhận ở
mức tối thiểu; địi hỏi bổ sung thêm thơng tin hay
làm sáng tỏ

3-4 Nghèo nàn Trình độ d-ới mức tối thiểu chấp nhận đ-ợc, địi
hỏi cải tiến đáng kể, cho thấy trình độ chuyên môn
hay kiến thức thấp.

0-2 Bác bỏ Thiếu khả năng hồn thiện cơng việc; dữ liệu
khơng thể đánh giá hay khơng có.

7Chẳng hạn, US DOD đã phát ra Directives 5000.1 Major Systems Acquisition, và 4105-62

</div>
(52)<div class='page_container' data-page=52>

Hầu hết các ph-ơng pháp đánh gía kiến nghị dựa trên một số biến thể
của kỹ thuật gắn trọng số, trong đó một số yếu tố tính điểm đ-ợc gán
trọng số và phối hợp với nhau để tạo nên một cấp bậc tổng thể cho kiến
nghị Silver (1986) gợi ý một kỹ thuật xếp loại cho mỗi yếu tố là t-ơng tự
nh- ở bảng 3.6. Chú ý là việc mô tả các loại thấp hơn có tính đến rằng
một cơ hội có thể có cho ng-ời đề nghị dùng để hiệu chỉnh hạng mục đã
đ-ợc chấm điểm.

Sau đó, kỹ thuật xếp loại mô tả ở bảng 3.6 đ-ợc vận dùng cho mỗi hợp
phần chủ yếu của kiến nghị và trọng số trung đ-ợc tính. Lấy thí dụ, bốn
hợp phần chủ yếu của kiến nghị có thể đ-ợc gán trọng số nh- sau:

Kü thuật 35%

Quản lý 25%

Chi phí 30%

Nền tảng học vấn và trí thức công ty 10%

Điều này có nghĩa là hợp phần kỹ thuật của kiến nghị có tầm quan
trọng hơn bất kỹ hợp phần nào khác.

Bng 3.7. Cỏc hng mc đề nghị về quản lý - mức độ đánh giá

1 Lịch trình 23%

Ngày tốt 12%

Kh nng ỳng 5%

Ct mc (phỏt triển) 4%
Mức độ chi tiết hóa 2%

2 Nh©n sù 16%

Nh©n sù chñ lùc 12%

Cơ cấu đội ngũ phát triển 5%

3 Khống chế phát triển 17%

Kiểm tra chất l-ợng 7%

Thử nghiệm 7%

Quản lý cấu hình 3%

4 Chủ thầu phụ 12%

5 Bảo d-ỡng 10%

6 Quản lý rủi ro 8%

7 Ph-ơng pháp luận phát triển 5%

8 Môi tr-ờng phát triển 5%

9 Công cụ và tiện ích phát triển 4%

Trọng số trung bình 100%

</div>
(53)<div class='page_container' data-page=53>

trong bất cứ 1 hợp phần chủ yếu nào đều bị kh-ớc từ bất kể số điểm cuối
cùng tính đ-ợc của nó. Điều này có nghĩa, chẳng hạn mặc dù các kiến
nghị kỹ thuật, quản lý, chi phí tốt nh- thế nào chăng nữa, nếu cơ sở học
vấn và kinh nghiệm của cơng ty yếu, thì kiến nghị tổng thể vẫn bị bác.

Bảng 3.7. cho một thí dụ về các hạng mục đ-ợc gán trọng số trong
phạm vi hợp phần quản lý của kiến nghị. Các bảng t-ơng tự cần đ-ợc
chuẩn bị cho các hạng mực tạo thành một trong những hợp phần chủ yếu
của kiến nghị. Cả hai danh sách hạng mục để đ-ợc tính điểm cũng
nh-các trọng số của cá thể cần đ-ợc khâu nối cho mỗi RFP những việc khâu
nối này phải đ-ợc tiến hành tr-ớc quá trình đánh giá và tuyển chọn. Một
bản dẫn tả chủ yếu khái quát bản đầu bảng chung của các bảng đánh giá
nên đ-ợc duy trì làm cơ sở cho mỗi dự án mới.

3.6. Một số nhận định bổ xung về đề xuất.

Việc phát triển phần mềm ít có tính chất xác định hơn các lĩnh vực
khác của cơng nghệ cao. Thơng th-ờng dự tính các yếu tố của dự án phát
triển phần cứng hay điện tử là dễ hơn những yếu tố của dự án phần mềm
kinh nghiệm cho thấy là tình trạng v-ợt trội của dự án phần mềm. Bản
chất đã th-ờng xuyên hơn và tốn kém hơn ở những lĩnh vực khác của
công nghệ. Điều này có nghĩa là các kiến nghị phần mềm địi hỏi có sự
quan tâm đặc biệt ở những lĩnh vực đặc tr-ng nh- lập lịch trình, phân tích
rủi ro, quản lý nhân sự và tính kinh phí. Những lĩnh vực này là quan trọng
ở bất cứ lĩnh vực phát triển công nghệ nào nh-ng lại càng quan trọng hơn
nhiều trong phát triển phần mềm.

Cả khách hàng và ng-ời đề nghị phải có ý thức về những đặc điểm này
và những đặc điểm riêng biệt khác của phát triển phần mềm. Khách hàng
phải giành quan tâm đặc biệt đến những lĩnh vực này khi đánh giá kiến
nghị đúng nh- ng-ời đề nghị phải quan tâm đặc biệt đến chúng khi chuẩn
bị kiến nghị.

3.6.1. Những vấn đề liên quan đến khách hàng.

Khi chuẩn bị một RFP, một trong những song đề thông th-ờng nhất
của khách hàng chính là phải cung cấp chi tiết đến thế nào đây. Quá
nhiều chi tiết có thể làm những ng-ời đề nghị nản lòng khi đ-a chào
những giải pháp của chính họ trong khi quá ít chi tiết có thể phát sinh
những giải phá khơng thích hợp do thiếu thơng tin. Khách hàng thơng
th-ờng có đơi chút ý t-ởng là vấn đề nên đ-ợc giải quyết ra sao. Nừu ý
t-ởng của khách hàng là kiên quyết thì những ý th-ởng đó cần đ-ợc chi
tiết hóa trong RFP. Dù sao, nếu những ng-ời đề nghị đ-ợc tự do đề nghị
giải pháp của chính họ thì một trong những giải pháp đó có thể tốt hơn rất
nhiều giải pháp mà khách hàng đã nhìn thấy rõ.

</div>
(54)<div class='page_container' data-page=54>

cho một dự án khẩn chỉ đơn thuần khơng có đủ thời gian để hồn thành
đ-ợc thủ tục qui trình đánh giá kiến nghị tốt.

Điều sau đây tóm tắt những vấn đề này nọ hẳn nên l-u tâm đến tr-ớc
khi đ-a ra RFP.

1. Mức độ chi tiết.

Những vấn đề đặc biệt thơng th-ờng địi hỏi những giải pháp đặc hiệu.
Nếu vấn đề là hẹp và đ-ợc xác định rõ hay nếu khách hàng có giải pháp

đặc hiệu trong óc thì phải cung cp chi tit ỏng k trong RFP.

2. Đánh giá các kiến nghị.

Vic ỏnh giỏ khỏch quan cỏc kin ngh khơng phải dễ thành cơng, ít
ra hai ng-ời phải đánh giá và tính điểm mỗi hạng mục trong các kiến
nghị và phải tính điểm trung bình. Nếu các điểm đ-ợc tính khác nhau
nhiều, thì ng-ời thứ ba (và ngay cả ng-ời thứ t-) phải nêu tính điểm hạng
mục đó và cả hai điểm đ-ợc tính (hay ba) sát nhau nhất nên đ-ợc lấy
trung bình.

3. Thay đổi u cầu

Thỏa thuận chính thức về dự án giữa ng-ời sản xuất và khách hàng
phải cho phép có một số thỏa đáng các thay đổi (sớm trong dự án). Yêu
cầu này có thể đ-ợc đ-a vào là bộ phận của RFP. Việc vận dụng từ thỏa
đáng phải xem xét một mặt nhu cầu, có cơ sở của khách hàng để hiệu
chỉnh sai lầm trong các yêu cầu dự án, mặt khác nhu cầu của ng-ời phát
triển để tránh sự đổ vỡ trong tính tốn chi phí và lịch trình.

4. TiÕt kiƯm thêi gian.

Q trình đề xuất RFP, đánh giá các kiến nghị và hoàn thành th-ơng
thảo có thể mất thì giờ. Trong một số tr-ờng hợp, dự án có thể là khẩn với
cơng việc phát triển lệ thuộc ở khoảng thời gian căng thẳng. Một trong
những cách tiết kiệm thời gian đối với khách hàng là cho phép công việc
phát triển bắt đầu ngay khi lựa chọn kiến nghị đ-ợc thắng. Điều này
th-ờng làm khi gửi th- định ý (LOL) cho ng-ời sản xuất đ-ợc chọn. Rủi
ro của khách hàng trong 1 LOL có thể giảm khi giới hạn ng-ời sản xuất ở
ngân sách đặc biệt cho đến khi hợp đồng cuối cùng đ-ợc ký.

5. Các kiến nghị chung nhau.

Mt trong nhng vn chính với kiến nghị chung nhau là thiều xác
định trách nhiệm rõ ràng. Các kiến nghị chung nhau bao giờ cũng phải
giao trách nhiệm chung cho một bên. Các bên tham gia khác trong kiến
nghị, đóng vai trị chủ thầu phụ, cũng phải đ-ợc xác định.

3.6.2. Những vấn đề liên quan đến ng-ời đề nghị.

Khơng có ph-ơng pháp chắc chắn nào để viết kiến nghị chắc thắng.
Những câu hỏi liên quan đến các vấn đề kiến trúc và kỹ thuật, bao gồm
các ph-ơng án chọn lựa hay đệ trình giải pháp nhiều mối tùy thuộc ở loại
kiến nghị và hoàn cảnh đệ trình. Sau đây là một số h-ớng dẫn chung cho
việc chuẩn bị một kiến nghị.

</div>
(55)<div class='page_container' data-page=55>

VỴ ngoài của kiến nghị hầu nh- cũng quan trọng nh- néi dung cđa nã.

ít có kiến nghị lộn xộn vụng về, cầu thả nào đ-ợc tuyển chọn là kiến
nghị, chắc thắng. Ng-ời đề nghị quan tâm rất nhiều đến mỹ học của văn
bản, đồ họa, nơ buộc, phim đèn chiếu v bt c dn gii ming no i
kốm.

2. Các yêu cÇu tïy chän.

Một RFP cũng có thể bao gồm cả các yêu cầu tùy chọn, Có những đặc
điểm hay khả năng phụ khơng nhất thiết cần cho việc hồn thành dự án
nh-ng lại là cái mà th-ờng đ-ợc coi là có thì đẹp. Kiến nghị có đặc điểm
tùy chọn có thể giành đ-ợc điểm ở ban duyệt xét kiến nghị.

Những đặc điểm tùy chọn đ-ợc chú ý nhất trong phần bổ sung của
kiến nghị và nên đ-ợc định giá, lập lch trỡnh riờng r.

3. Mọi yêu cầu.

Mt kin ngh khụng nhất thiết đáp ứng mọi yêu cầu của RFP. Dù sao,
phải có tham chiếu mọi yêu cầu nhằm chứng minh là chúng không bị bỏ
qua. Những chệch h-ớng với RFP phi -c bin minh v gii thớch.

4. Giải pháp thay thÕ.

Một kiến nghị có thể có hơn một giải pháp đề nghị. Dù sao những giải
pháp thay thế phải đ-ợc đệ trình riêng rẽ sao chúng có thể đ-ợc l-u ý và
đánh giá riêng rẽ. Các giải pháp thay thể không cần thiết phải nhắc lại
trọn vẹn các phần trong giải pháp đề nghị thứ nhất, chúng có thể tham
chiếu những phần đó (thí dụ "tổ chức đội ngũ phát triển cho giải pháp của
xử lý phân tán vẫn sẽ là nh- với giải pháp Hệ thống tập tâm”.)

5. C¸c công cụ chuyên nghiệp.

Cỏc tin ớch v cụng c t động nên đ-ợc dùng để hỗ trợ trong việc
chuẩn bị một kiến nghị, ngoài các bộ xử lý văn bản và kiểm tra chính tả
tất yếu, những cơng cụ nh- bộ trọn gói lập trình, bộ sinh sản thiết kế và
yêu cầu , bộ trọn gói đồ thị v.v... Có thể tiết kiệm khối l-ợng đáng kể
công sức và thời gian trong chuẩn bị kiến nghị chuyên nghiệp. Một danh
mục các cơng cụ và tiện ích có trong th- mục mà Tahvanainen cùng cộng
sự cơng bố (1990).

3.7. Tãm t¾t.

Ch-ơng này đề cập đến quan hệ giữa khách hàng và nhà sản xuất phần
mềm và đến việc chuẩn bị, đệ trình và đánh gía kiến nghị. Nó cũng cung
cấp một số h-ớng dẫn về việc làm sao tránh đ-ợc những bẫy cổ điển do
quyền lợi mâu thuẫn nhau của khách hàng và nhà sản xuất. Mổc dù nhiều
những vấn đề này là thông th-ờng cho mọi quan hệ khách hàng, nhà phát
triển một số vấn đề là đặc tr-ng cho sự phát triển phần mềm.

Về cơ bản có hai thể loại hệ hợp đồng giữa khách hàng và nhà phát
triển.

</div>
(56)<div class='page_container' data-page=56>

Hầu hết các quan hệ khác là một hình thức phối hợp của hai quan hệ
này.

Phớ cng thờm l quan hệ hợp đồng mà nhà phát triển đ-ợc trả tiền cho
chi phí dịch vụ cung cấp và thêm vào đấy đ-ợc phép một mức lợi tức thỏa
thuận, phí cộng th-ờng là thích hợp cho các dự án nhỏ, khơng xác định
khi khó minh định các yêu cầu của dự án. Phí cộng thêm có thể đ-ợc
chuộng ở khách hàng muốn giữ quyền kiểm tra quá trình phát triển.

Hợp đồng giá cố định là cam kết của nhà phát triển trong việc cung cấp
một sản phẩm hay dịch vụ thảo thuận với phí thỏa thuận trong lịch trình
thảo thuận. Nừu dự án đủ chi tiết và rõ và nếu quan hệ giữa hai bên đ-ợc
xác định rõ thì giá cố định có lợi cho cả 2 bên.

Có nhiều biến thể của 2 quan hệ cơ bản đó kể cả nhiều biến thể đ-ợc
"cắt may" thích hợp với dự án đặc tr-ng.

Phát triển phần mềm theo hợp đồng bắt đầu bằng việc khách hàng
tuyển chọn nhà phát triển phần mềm. Điều này thông th-ờng đ-ợc thực
hiện khi phát ra một yêu cầu cho kiến nghị (RFP).

Có 2 phạm trù kiến nghị cơ bản: kiến nghị di yêu cầu và kiến nghị
không do yêu cầu. Kiến nghị di yêu cầu đáp ứng cả RFP chính thức cũng
nh- lời mời đặc biệt yêu cầu đệ trình kiến nghị trong khi kiến nghị khơng
do yêu cầu thông th-ờng do ng-ời đề nghị khởi x-ớng.

Sau khi đệ trình kiến nghị cho khách hàng, mọi kiến nghị đ-ợc ban
tuyển chọn duyệt xét. Các kiến nghị cho dự án nhỏ cũng nh- lớn phải
đ-ợc đánh giá theo 1 thủ tục có hệ thống và t-ơng đối khách quan.
Th-ờng hai hay ba lời khuyên đ-ợc đệ trình và việc lặp lại lần hai đ-ợc
bắt đầu với các công ty đã đ-ợc tuyển chọn để tìm ra kiến nghị thắng và
tạo dựng hợp đồng phát triển thỏa thuận.

Bµi tËp.

1. Cơng ty xe tải Acme có 1 đội 500 xe tải với 30 kho chứa xe tải khắp
n-ớc. Acme đ-a các xe tải trên tuyến giao nhận. Mỗi cuộc hành trình bắt
đầu ở kho gần đầu tuyến nhất và ở đó đã sẵn có xe và kết thúc ở kho gần
nhất cuối tuyến. Acme muốn phát triển một hệ thông đ-a xe đi trên vi
tính để tối -u hóa việc sử dụng xe của họ.

Thảo luận lợi và bất lợi cho Acme và cho nhà phát triển dự án, đảm
nhiệm các loại hợp đồng phát triển khác nhau.

2. ChuÈn bÞ RFP cho dự án lịch trình xe tải của Acme. Bao gồm phần
yêu cầu kỹ thuật, phần bàn giao đ-ợc theo yêu cầu và phần thông tin
quản trị và cho mọi phần RFP chủ yếu khác.

3. Chun b mt kin nghị đêk trình Acme về dự án lịch xe tải bao gồm
kiến nghị kỹ thuật, tuyên bố công việc và tóm tắt điều hành cùng phác

thảo cho mọi phần chủ yếu khác (kể cả bổ sung).

</div>
(57)<div class='page_container' data-page=57>

Thảo luận mọi tiêu chí duyệt xét và tuyển chọn đặc biệt nh- mức tối
thiểu cho một số hạng mục hay hợp phần chủ yếu.

5. Bài tập ở lớp: lựa chọn một trong những RFP chuẩn bị ở bài tập 2 là
RFP cho dự án lập lịch xe tải cho Acme. Chỉ định ba đến năm đỗi ngũ
chuẩn bị kiến nghị để chuẩn bị kiến nghị đáp ứng RFP chỉ định ban tuyển
xét kiến nghị để duyệt xét các kiến nghị và tuyn chn kin ngh thng.

</div>
(58)<div class='page_container' data-page=58>

Ch-ơng bốn

Chu trình phát triển phần mềm

Cỏc bin thỏi v ch thỏc n-ớc

Phát triển phần mềm đúng nh- hầu hết các hoạt động khác có khởi
đầu, trung đoạn và kết thúc. Kết thúc của một hoạt động phát triển đơi
khi đ-ợc nhìn nhận là đ-ợc tiếp nối với khởi đầu của một hoạt động phát
triển mới và bởi vậy tạo ra một chu trình khởi đầu - trung đoạn - kết thúc,
tiếp nối, khởi đầu, trung đoạn - kết thúc , tiếp nối và cứ thế mãi cách nhìn
đó về phát triển phần mềm đ-ợc coi là chu kỳ cuộc đời (vòng đời) của
phát triển phần mềm.

Có nhiều biến thức của chu kỳ cuộc đời của phát triển phần mềm. Hình
4.1 cho thấy một vịng đời đơn giản thơng th-ờng trong vài thập kỷ đầu
của phát triển phần mềm . Vào những ngày đầu đó của phát triển phần
mềm, nhà lập trình hẳn đã sáng tạo ra những ch-ơng trình bằng cách lặp
lại từ mã đến phạm trù rồi trở lại mã và rồi lại phạm trù nữa đến khi có
chút gì chấp nhận đ-ợc (mong nh- vậy) sản sinh ra khởi đầu chu trình đó

th-ờng khơng có quan niệm rõ ràng về cái gì đ-ợc yêu cầu và qui trình
phát triển cơ bản là một hình thức tiếp cận '' hãy để xem chúng ta có thể
làm đ-ợc gì''.

Ph-ơng pháp phát triển phần mềm biểu thị bằng chu trình phát triển ở
hình 4.1 th-ờng đ-ợc coi là ph-ơng pháp mã về phạm trù (vì những lý do
hiển nhiên). Những ph-ơng pháp luận phát triển phần mềm đã đi một
chặng đ-ờng dài từ những ngày “code and fix” mặc dù rằng thật ngạc
nhiên ở chỗ có biết bao nhiêu phần mềm vẫn cịn đ-ợc phát triển theo
cách đó. Việc quản lý thắng lợi bất cứ dự án nào, đặc biệt các dự án phần
mềm, địi hỏi phải lập kế hoạch và khơng thể lập kế hoạch với ''mã và
phạm trù, nó hồn tồn khơng thể tiên liệu đ-ợc gì. Quản lý phát triển
phần mềm trong bộ mơn cơng trình lại dựa trên một bộ pha phát triển
ngăn nắp hơn. Những pha đó khơng do chỉ riêng các nhà lập trình thực
hiện, chúng địi hỏi có các kỹ s- phần mềm. Trên thực tế, lập trình đã trở
thành một bộ phận t-ơng đối nhỏ của chu trình phát triển phần mềm hiện
đại nh- ta thy bng 4.1.

Hình 4.1

Ph-ơng pháp Code và Fix.

</div>
(59)<div class='page_container' data-page=59>

Những con số ở bảng 4.1 lấy từ sơ đồ chung có nhấn mạnh đến qui
hoạch phần mềm (yêu cầu và thiết kế) và thử nghiệm. Những hệ thống xử
lý dữ liệu th-ơng mại, trừ một số ngoại lệ, vẫn cịn phải tiêu phí một khối
l-ợng đáng kể thời gian phát triển trong pha lập trình và thử nghiệm đơn
vị. Các hệ thống thời gian thực th-ờng phức tạp hơn nhiều và có thể bao
gồm sự tích hợp bao qt phần cứng/phần mềm. Điều này thơng th-ờng
địi hỏi qui hoạch nhiều hơn và tích hợp cùng thử nghiệm nhiu hn.

Bảng 4.1 phần trăm dự tích về thời gian hao phí trong pha phát
triển phần mềm chủ yếu.

Qui hoạch m· vµ thư

nghiệm đơn vị nhất thể và thửnghiệm
Xử lý d liu

th-ơng mại 25% 40% 35%

Các hệ thống thời

gian thực 35% 25% 40%

Các hệ thống
quân sự

40% 20% 40%

Hình 4.2

Mụ hỡnh pha của vòng đời phát triển phần mềm

ThiÕt kÕ
møc cao
Tãm bắt

yêu cầu
Hình

thành ý
niệm

Thử
nghiệm

Bảo trì

Thực thi
Tích

hợp

</div>
(60)<div class='page_container' data-page=60>

Cỏc h thng quân sự đòi hỏi độ tin cậy cao và th-ờng đ-ợc khách
hàng giám sát chặt chẽ dẫn đến gia tăng đáng kể thời gian cần để qui
hoạch.

Tất nhiên các dữ liệu trong bảng 4.1 biểu thị một sự khái quát hố; các
hệ thống xử lý dữ liệu th-ơng mại có thể đúng là phức tạp nh- hệ thống
thời gian thực ( coi phần 4.4 thảo luận thêm về chuyên mục này)

H .4.2 cho thấy mơ hình các pha của một vịng đời phát triển phần
mềm. Mơ hình đó gọi là mơ hình thác n-ớc có tên nh- vậy do cách mà
mỗi pha rồn rập thác để sang giai đoạn sau ( do sự gối đầu) nh- minh hoạ
ở hình 4.3.

Một số lý giải về mơ hình thác n-ớc nh- lý giải sau đây, phối hợp các
pha thiết kế mức đỉnh và thiết kế chi tiết thành một pha thiết kế duy nhất
và các pha tích hợp và thử nghiệm vào một pha duy nhất. Trên thực tế có
nhiều biến thể của mơ hình thác n-ớc cổ điển nh-ng tất cả đều dựa trên

sự chuyển tiếp có hệ thống từ một pha phát triển này sang pha sau cho tận
đến khi d ỏn -c hon thnh.

Hình thành ý niệm
Tóm bắt yêu cầu

Thiết kế mức cao
Thiết kế chi tiết

Thực thi

Tích hợp

Thử nghiệm

Bảo tr×

T
H×nh 4.3

Mơ hình thác n-ớc của vịng đời phát triển phần mềm

</div>
(61)<div class='page_container' data-page=61>

Mơ hình xoắn ốc đ-ợc Boehm mô tả (1988) là ph-ơng pháp phát triển
khác lặp lại giữa các pha yêu cầu thiết kế và thực hiện. Dù sao, mơ hình
xoắn ốc tiếp tục lặp lại đến khi hệ thống cuối cùng hoàn thành. Trong
mỗi lần lặp lại, mơ hình xoắn ốc theo cách tiếp cận chia pha t-ng t mụ
hỡnh thỏc n-c.

H.4.4

Tạo nguyên mẫu nhanh tiếp theo là ph-ơng pháp chia pha

Hu ht cỏc h bin hoá hiện đại phát triển phần mềm bao gồm một số
hạng của mơ hình chia pha cơ bản. Do đấy quan trọng là phải hiểu đ-ợc
các pha khác nhau và biết chúng liên quan với nhau nh- thế nào. Ch-ơng
này mô tả một số vấn đề quản lý liên kết với mơ hình chia pha kể cả
khơng khí và những vấn đề đặc tr-ng mỗi pha.

4.1 Pha quan niƯm

Mơ hình thác n-ớc bắt đầu bằng pha quan niệm khởi thuỷ, trong pha
đó nhu cầu về hệ thống phầm mềm. Pha này cũng còn đ-ợc IEEE gọi là
pha thăm dò quan niệm8 nó tạo cơ sở cho :

- Chuẩn bị yêu cầu cho kiến nghị (RFP); RFP là có ích khi các dự án
đ-ợc hợp đồng với các nhà phát triển khác (coi ch-ơng 3) ở bên ngoài

- Xác định các yờu cu phn mm (pha).

- Qui hoạch ban đầu và chuẩn bị dự toán; điều này th-ờng đ-ợc dùng
làm bản đầu của kế hoạch phát triển của dự án.

- Pha quan niệm tạo nên hai loại văn bản dự án :

- Mô tả sản phẩm tr-ớc hết là t- liệu tiếp thị và đ-ợc dùng nh- là một
bản công bố sau này cho sản phẩm hay nh- là một tổng quan chung của
sản phẩm. T- liệu quan niệm là t- liệu kỹ thuật và tạo thành cơ sở cho
những hoạt động kỹ thuật chính của pha này (RFP kế hoạch ban đầu )
T-8Từ vựng chuẩn cho thuật ngữ công trình phần mềm của IEEE (Std729-1983) (1987b) mặc dù thừa

nhận thiếu sự thoả thuận chung về các pha yêu cầu tạo ra chu kỳ sống của phầnf mềm vẫn cho một thí
dụ gồm có khai thác quan niệm u cầu, thiết kế, thực hiện, thử nghiệm, lắp đặt và kiểm thử, vận hành
và bảo trì và một giai đoạn lý thỳ gi l rỳt lui .

Vòng tạo mẫu nhanh

Hình thành
ý niệm

Tạo nguyên mẫu Yêu cầu

Thiết kế

Thực thi
Tích hợp

</div>
(62)<div class='page_container' data-page=62>

liệu quan niệm cũng là một trong những nguồn tham chiến chính cho
việc tạo lập các yêu cầu phần mềm trong pha sau của dự án.

Pha quan niêm không phải là pha phát triển chính thức uỷ thác. Nó
th-ờng đ-ợc tiến hành không chính thức tr-ớc khi có bất cứ cam kết nào
cho sự phát triển sau này của dự án

4.1.1 Bầu không khí trong pha quan niệm.

Bu khụng khớ của pha quan niệm biến đổi trên cơ sở tăng lên, giảm
xuống của sự thiếu quả quyết và sự do dự. Theo thế pha đầu này của dự
án th-ờng đ-ợc đặc tr-ng ở :

- Ao -ớc của đội ngũ kỹ thuật muốn nắm đ-ợc sự vận động của dự án

- Thiếu cam kết đầy đủ về phía quản lý : Chỉ có những ngân sách ban
đầu th-ờng đ-ợc phân vào giai đoạn này.

- Sự thất vọng trong quản lý do tình trạng bất lực của đội ngũ kỹ thuật
khơng giúp cho quản lý đ-ợc gì ngồi dự tốn thơ thiển.

- Thất vọng của đội phát triển : do bất lực của khách hàng ( kể cả quản
lý tiếp thị và những ng-ời sử dụng) Khơng cho đ-ợc những định nghĩa
chính xác của hệ thống mà họ yêu cầu.

Tất cả những điều đó là sản phẩm của việc thiếu cam kết của các bên
liên quan khách hàng và quản lý vẫn cịn ch-a có quyết định chắc chắn
về việc liệu họ có muốn tiến b-ớc tiếp với dự án nữa khơng . Thêm vào
đấy, họ lại ch-a hoàn toàn đ-ợc thuyết phục về tầm quan trọng của pha
quan niệm khi mà rất ít kết quả nhìn thấy đ-ợc . Các bên có xu h-ớng
dính líu chứ khơng hồn tồn cam kết9 với dự án và do đó chỉ trơng đợi

kết quả mà chẳng chịu cung cấp đủ nguồn lực.

ViÖc bè trÝ ngân sách luôn là một dấu hiệu cam kết chắc chắn nhất vào
dự án và ngân sách , khởi thuỷ càng lớn thì sự cam kết càng chắc chắn.
Việc kiểm ra ngân sách ban đầu của dự án th-ờng là nhiệm vụ chủ yếu
đầu tiên của ng-ời quản lý dự án. Điều này có thể đ-ợc thực hiện coi
nh-kết qu¶ cđa :

- Việc chuẩn bị một t- liệu quan niệm tốt. Một t- liệu quan niệm tốt là
kết quả của việc phân tích thị tr-ờng và khảo sát ng-ời dùng dễ hiểu. Và
nó bao gồm tổng quan soạn thảo tốt về các yêu cầu chức năng của hệ
thống t- liệu này cũng phải đề cập đến tính khả thi của dự án.

- Hình thành nhu cầu rõ ràng cho hệ thống cần đ-ợc phát triển một
trong những cách tốt nhất để có đ-ợc sụ phê duyệt cho dự án phát triển là
minh định và mô tả rõ ràng vấn đề mà dự án này đ-a ra một giải pháp cho
vn ú.

- Cung cấp những dự toán ban đầu đầy thuyết phục cho sự phát triển
của dự án. Không cã tỉ chøc nµo cã thĨ cam kÕt cho mét phí tổn không

</div>
(63)<div class='page_container' data-page=63>

biết. Nếu dự toán ban đầu10 không thể chuẩn bị đ-ợc thì vào phút cuối

cng phải đệ trình đ-ợc dự tốn cho giai đoạn u cầu

4.1.2 Những vấn đề trong pha quan niệm.

Có nhiều vấn đề trong pha quan niệm là do khó khăn trong việc đảy dự
án tiến lên. Rõ ràng điều này là kết quả của khơng khí biến động mơ tả
trong phần tr-ớc. Điều này dẫn đến khó khăn trong việc nhận đ-ợc cam
kết ràng buộc từ khách hàng và từ quản lý hàng đầu.

Những vấn đề sau là thông th-ờng trong pha quan niệm.

- Có nhiều vấn đề liên quan đến việc thành lập đội ngũ phát triển dự án
ban đầu. Đặt đúng ng-ời vào đội ngũ dự án hiếm khi là một việc dễ dàng.
Thật vậy, bố trí ng-ời quản lý dự án thích hợp khơng phải bao giờ cũng là
một việc dễ dàng.

- Vấn đề thông th-ờng hoặc là thiếu hoặc là thừa lãnh đạo dự án. Trong
nhiều tr-ờng hợp , pha quan niệm do nhiều ng-ời chỉ đạo, ng-ời này có

thể chịu trách nhiệm về phân tích thị tr-ờng, ng-ời kia về dự toán và lại
ng-ời khác nữa về soạn thảo các t- liệu quan niệm. Điều này có thể gây
ra tình trạng thiếu phối hợp giữa những ng-ời có trách nhiệm về các hoạt
động khác nhau, tạo nên nhiều mâu thuẫn và những quyết định ban đầu
tồi.

- Khi đội ngũ ban đầu đã yên vị và kế hoạch phát triển sơ bộ đã
đ-ợc soạn thảo, không phải khơng phổ biến có chuyện nhiều ý kiến khác
nhau về việc sản phẩm nên phải thực sự nh- thế nào tạo ra t- liệu quan
niệm đ-ợc thoả thuận th-ờng có thể trở nên một vấn đề chủ yếu . Vấn đề
này th-ờng đ-ợc giải quyết thông qua vận dụng các hệ thống trình diễn
hay nguyên mẫu.

Việc tạo nguyên mẫu nhanh có thể giúp ích khi thoả thuận chung về
quan niệm khó đạt đ-ợc. Các quan niệm th-ờng dễ thơng nhất hơn khi có
một cái gì đó cụ thể đ-ợc trình ra và duyệt lại bởi các bên liên quan.

4.2 Pha yêu cầu phần mềm.

Giai on yờu cu phn mm, cng gọi là pha xác định, là giai đoạn
chính thức uỷ thác đầu tiên của phát triển phần mềm. Giai đoạn này cung
cấp mô tả chi tiết về hệ thống phần mềm đ-ợc phát triển. Điều này là căn
cứ ở đặc tả yêu cầu sao cho sản phẩm phần mềm đ-ợc thử nghiệm vào
cuối dự án nhằm chứng minh rắng sản phẩm đ-ợc yêu cầu thực tình đã
đ-ợc sản ra. Đặc tả yêu cầu trả lời “cái gì” trong khi tìm cỏch trỏnh cõu
hi th no.

Pha yêu cầu tạo thành cơ sở cho :

- Đ-ờng lối đầu tiên chủ yếu của hÖ thèng11

- Thiết kế hệ thống ( giai đoạn tiếp)
10Việc chuẩn bị dự toán đ-ợc bàn đến chi tiết ở ch-ơng 10

</div>
(64)<div class='page_container' data-page=64>

- Thủ tục thử nghiệm để nghiệm thu (ATP)

Pha yêu cầu soạn thảo một t- liệu sản phẩm chính :
- T- liệu đặc tả yêu cầu phn mm

và hai t- liệu qui hoạch dự án
- Kế hoạch phát triển dự án
- Kế hoạch thử nghiệm dự ¸n

Pha yêu cầu chính thức kết thúc với việc duyệt xét chủ yếu đầu tiên
cho dự án : Duyệt xét yêu cầu phần mềm (SRR) chính việc duyệt xét này
kết thúc việc đặc tả yêu cầu và chính thức tuyên bố t- liệu yêu cầu nh- là
đ-ờng lối cơ bản d ỏn u tiờn -c phờ duyt.

4.2.1 Bầu không khí trong quá trình pha yêu cầu.

Pha yêu cầu th-ờng đ-ợc nhận thức là giai đoạn quan trọng nhất của
chu trình phát triển phần mềm. Chắc chắn rằng nó là một trong những
phần khó khăn nhất, một phần do khó khăn trong việc lập t- liệu một mô
tả đ-ợc chấp thuận cho yêu cầu phần mềm . Bao giờ cũng có mâu thuẫn
cơ bản về quyền lợi giữa khách hàng12 và ng-ời phát triển. Khách hàng

min c-ng kt thỳc yờu cu vì nhận biết rằng một khi đã làm điều này,
mọi thay đổi sau này có thể phải trả giá. Mặt khác, ng-ời phát triển cần

kết thúc yêu cầu cáng sớm càng tốt vì tiến triển sẽ chậm đi chừng nào sản
phẩm cịn ch-a hồn tồn đ-ợc xác định và cũng chính điều này là tốn
kém. Nên bầu khơng khí của pha yêu cầu có thể đ-ợc đặc tr-ng nh- là
một hình thức của trị kéo co giữa khách hàng và ng-ời phát triển.

Hợp đồng phí cộng thêm theo đó ng-ời phát triển đ-ợc trả theo giờ hay
theo ngày (coi ch-ơng 3) có xu h-ớng có ít tranh chấp thuộc loại này. Dù
sao hợp đồng phí cộng thêm để trách nhiệm chính cho việc kết thúc sớm
các yêu cầu với khách hàng.

Do đấy giai đoạn yêu cầu đ-ợc đặc tr-ng ở :

- Mâu thuẫn giữa ng-ời phát triển và khách hàng trong việc kết thúc
đặc tả yêu cầu.

- Bất đồng về các dự toán sửa đổi và ràng buộc và cũng :

- Bối rối do trách nhiệm chuyển giao và bố trí lực l-ợng không chuyên
môn.

Yờu cu kt thỳc vic khơng phải bao giờ cũng dễ dàng và địi hỏi kinh
nghiệm kiên nhẫn và kiên quyết. Đấy là việc của ng-ời quản lý dự án một
mặt c-ơng quyết và dứt khoát trong việc yêu cầu các bên kết thúc yêu cầu
về dự án. Điều này đ-ợc thực hiện tốt nhất khi giải thích cho khách hàng
là khơng kết thúc gây ra chậm trễ lịch trình và chậm trễ là tốn kém.

4.2.2 Các vấn đề trong pha yêu cầu

12 Từ khách hàng sử dụng ở đây theo nghĩa rộng nhất của nó và liên quan đến tổ chức mà dự án yêu

</div>
(65)<div class='page_container' data-page=65>

Đôi khi xảy ra các tranh chấp, bất đồng và lẫn lộn biểu thị khơng khí
của giai đoạn yêu cầu chính là nguồn gối chủ yếu của các vấn đề. Danh
sách thì dài nh-ng những vấn đề thông th-ờng nhất là :

- Thay đổi yêu cầu luôn : Trong pha này, th-ờng có luồng thay đổi có
vẻ vô tận làm cho việc thu thập đặc điểm yêu cu thờm khú khn.

- Chấp thuận yêu cầu và ký: pha này không thể hoàn tất nếu không có
t- liệu yêu cầu đ-ợc phê duyệt chính thức.

- Tớnh kh thi của u cầu : đơi khi điều này khó xác định tr-ớc giai
đoạn thực hiện.

- Bố trí nhân sự : Việc sắp xếp thành viên đội ngũ phát triển thích hợp
có thể là một nhiệm vụ khó. Việc bố trí các thành viên đội ngũ phải đ-ợc
hoàn tất trong pha yêu cầu.

- Cung cấp thiết bị : Những vấn đề ngân sách và sẵn sàng sử dụng đ-ợc
có thể làm đứt đoạn kế hoạch bố trí thiết bị.

- Nh÷ng dù ¸n b¾t buéc

Nếu nh- những việc này ch-a đ-ợc đâỳ đủ thì chúng phải đ-ợc hồn
tất tr-ớc khi kết thúc pha này.

Nh- chúng ta đã thấy, có đ-ợc sự phê duyệt chính thức về đặc tả yêu
cầu là nhiệm vụ khó khăn nhất của giai đoạn này. Th-ờng các yêu cầu
tiến triển dần dần với nhiều ph-ơng án dự thảo của đặc tả tập trung vào
t-liệu đ-ợc phê duyệt cuối cùng. Dù sao nếu những thay đổi chủ yếu đ-ợc
đ-a ra liên tục thì sẽ khó lên kế hoạch. Trong những tình hình nh- thế,

việc tạo nguyên mẫu nhanh có thể có ích nhất trong việc giúp khách hàng
xác định yêu cầu.

Tính khả thi của yêu cầu phải đ-ợc xác định nếu có thể tr-ớc khi hồn
tất các u cầu. Bao giờ cũng tốn kém khi phát hiện những yêu cầu bất
khả thi trong quá trình những pha sau này của dự án.

Tính khả thi của các yêu cầu có thể trở nên tốt hơn nhờ.
- Sử dụng nguyên mẫu để thử nghiệm u cầu

- Sư dơng nhÊt thêi các chuyên gia vào thủ tục phân tích tính khả thi
- Yêu cầu phê duyệt các yêu cầu thay thế nếu yêu cầu chính không khả
thi.

- To ra nhng yờu cầu mơ hồ tuỳ theo một số kết quả. (thí dụ bộ nhớ
đủ, hay khả năng xử lí CPU có sẵn). Bất kỳ chỗ nào có thể đ-ợc những
yêu cầu mơ hồ hay khả nghi phải đ-ợc loại bỏ. Lập kế hoạch dự án tiến
triển song song với phát triển các yêu cầu. Những vấ đề liên quan với việc
bố trí tài ngun con ng-ời và kỹ thuật có thể làm dự án trì trệ. Tìm đ-ợc
những thành viên tốt cho đội ngũ bào giờ cũng là một vấn đề cho ng-ời
quản lý dự án. Dù sao, một khi họ đã đ-ợc bố trí và uỷ thác, thiết bị phát
triển thoả đáng phải sẵn sàng.Do đó những vấn đề liên kết với việc cung
cấp thiết bị càng trở nên nghiêm trọng hơn khi đội ngũ phát triển lớn lên.

Những vấn đề nhân sự th-ờng có thể giải quyết bằng cách:
- Sử dụng nhân lực tạm thời

</div>
(66)<div class='page_container' data-page=66>

Các vấn đề thiết bị cũng thế, có thể đ-ợc giải quyết bằng cách:
- Sử dụng thiết bị tạm thời ( vay hay thuê).

- Sử dụng phần mềm mô phỏng thay thế cho thiết bị đắt tiền.
- Có đ-ợc ngân sách ban đầu tài trợ thiết bị phát triển cơ bản .

Những vấn đề thiết bị và nhân sự th-ờng tác động đến dự tốn và lịch
trình trong kế hoạch phát triển dự án. Nếu thiết bị chậm hay nếu bố trí
nhân sự chậm thì dự tốn sẽ cần đ-ợc xem lại và lịch cần đ-ợc điều
chỉnh. Những vấn đề này đ-ợc bàn chi tiết ở ch-ơng 9.

4.3 pha thiÕt kÕ.

Trong pha thiết kế, các yêu cầu đ-ợc phân tích và ph-ơng pháp thực
hiện đ-ợc xác định. Pha yêu cầu tr-ớc đây đặt câu hỏi “cái gì?”, pha thiết
kế đặt câu hỏi “thế nào?” Việc trả lời cho câu hỏi này đ-ợc có trong
t-liệu đặc tả thiết kế phần mềm.

Pha thiết kế th-ờng đ-ợc chia lạm hai pha riêng biệt: thiết kế mức đỉnh
và thiết kế chi tiết. Đ-ờng phân chia giữa hai pha này đ-ợc đặt có một cái
gì đó không nhất thiết và căn cứ ở mức độ phân hệ thống thành các thành
phần (coi ch-ơng 6) hình 6.5 cho một thí dụ của sự phân chia thiết kế
một hệ thống thành thiết kế mức điểm và thiết kế chi tiết.

Một trong những lợi thế trong việc sử dụng hai pha thiết kế so với thiết
kế một pha là ở chỗ thiết kế mức đỉnh thứ nhất cung cấp một mốc bổ
sung ở mốc đó có thể đánh giá và phê duyệt cách tiếp cận thiết kế . Điều
này là đặc biệt quan trọng ở các dự án vừa và lớn (nghĩa là hơn 18 năm
cơng) mà do đó những sai lầm thiết kế chủ yếu phải đ-ợc xác định càng
sớm càng tốt. Khi tìm đ-ợc sai lầm chủ yếu ở cuối pha thiết kế mức đỉnh
thì sẽ dễ dàng sửa nó hơn là nếu tìm thấy nó sau khi toàn bộ thiết kế đã
hoàn thanhf . Hãy xét thí dụ sau :

Một hệ thơng phần mềm đang đ-ợc thiết kế cho một máy tính đặc thù
có cấu hình cơ bản 8 megabai bộ nhớ và 256 mêgabai đĩa cứng. Bộ nhớ
có thể tăng thêm một mêgabai và đĩa cứng có thể tăng thêm 256 mêgabai.
Thiết kế ban đầu của hệ thống đ-ợc phát triển đã không khớp vào cấu
hình bộ nhớ cơ bản và do đó hệ thống đ-ợc thiết kế để sử dụng ovlray.
Việc sử dụng overlay là một quyết định thiết kế chủ yếu và nó tác dộng
đến việc định giờ, tính phức tạp sử dụng bộ nhớ và đĩa. Nhiều quyết định
thiết kế tiếp theo chịu ảnh h-ởng của quyết định nay về việc sử dụng
overlay. Hoá ra là sử dụng overlay là một quyết định thiết kế tồi vì sử
dụng đĩa cũng cao. Điều đó có nghĩa phải cần đến bộ đọc đĩa 256
mêgabai thứ hai và rõ ràng tốn kém hơn 2 megabai phụ của bộ nhớ cần
có để khắc phục nhu cầu về ove rlay.

</div>
(67)<div class='page_container' data-page=67>

sẽ là tối thiểu và nh- thế sẽ có cơ may tốt hơn là thay đổi cấu hình máy
tính tr-ớc khi giao hàng.

Pha thiÕt kÕ tạo cơ sở cho :

- Đ-ờng mốc, hệ thống chủ u thø hai cđa hƯ thèng
- Thùc hiƯn hƯ thèng ( giai đoạn sau)

- Ch-ơng trình phát triển đ-ợc cập nhật.
Pha thiết kế tạo nên những văn bản sau :

- Đặc tả thiết kế (với những dự án lớn : đặc tả thiết kế mức đỉnh và đặc
tả thiết kế chi tit)

- Kế hoạch tích hợp

- Đặc tả tr-ờng hợp thử nghiệm, mô tả chi tiết mỗi thử nghiệm mức

thấp cho tõng c¸ thĨ.

Văn bản đặc tả thiết kế tạo lập đ-ờng mốc chủ yếu thứ hai của dự án.
Tr-ờng hợp hai pha thiết kế thì đặc tả thiết kế chi tiết đ-ợc coi là đ-ờng
mốc chủ yêú của thiết kế và đặc tả thiết kế mức đỉnh đ-ợc coi là đ-ờng
mộc thứ yếu (Các đ-ờng mốc sẽ đ-ợc thảo luận ở ch-ơng 9).

Vào cuối pha này, nhiều cái ch-a biết của dự án lại trở nên đã biết, do
đó tạo nên cải tiến đáng kể trong dự toán kế hoạch phát triển các thông số
phát triển dự án khác nhau nh- tài nguyên và lịch tích hợp và các tr-ờng
hợp thử nghiệm thực cho pha thử nghiệm, giờ đây có thể đ-ợc lập kế
hoạch đ-ợc kế hoạch phát triển dự án đ-ợc cập nhật do đấy có thể coi
rằng ở giai đoạn nay kế hoạch đó là đáng tin cậy hơn nhiều.

Theo thế, song song với thiết kế của hệ thống, các hoạt động sau đây
cũng tiến triển :

- Nền tảng, tích hợp và phát triển đ-ợc thiết lập bao gồm mọi thiết bị
yêu cầu cho phát triển và tÝch hỵp hƯ thèng .

- Dự tốn đ-ợc cải tiến ỏng k.

- phân tích rủi ro của dự án đ-ợc duyệt xét lại và cập nhật.
- Lịch phát triển của hệ thống đ-ợc cập nhật.

Mi thụng tin trờn -c -a vào trong việc sửa đổi mới chủ yếu của kế
hoạch phát triển dự án.

Pha thiết kế kết thúc với việc ký kết t- liệu đặc tả thiết kế. Điều này
thông th-ờng xảy ra trong việc duyệt xét thiết kế chinh thức, đ-ợc gọi là

duyệt xét thiết kế có phê phán (CDR). Nếu một đặc tả thiết kế mức đỉnh
trung gian đ-ợc chuẩn bị, thì t- liệu này đ-ợc dừng ở việc duyệt xét thiết
kế sơ bộ (PDR) ban đầu.

4.3.1 BÇu kh«ng khÝ trong pha thiÕt kÕ.

Pha thiết kế th-ờng là một phần t-ơng đối lạc quan và tin t-ởng của dự
án phát triển. Giai đoạn này đặc tr-ng ở :

- Sự nhiệt tình : dự án đã có đà, ngân sách đã đ-ợc duyệt và giờ đây
đang đ-ợc chi tiền và một đội ngũ phát triển mới đã yên vị .

</div>
(68)<div class='page_container' data-page=68>

- ý kiÕn chËm

- tÝnh bÊt kh¶ thi của yêu cầu

- Thông tin mới bổ sung

- Sự bối rối : Đội ngũ phát triển nhanh, tôn ti dự án và trách nhiệm
còn ch-a rõ.

Pha thit k, i với ng-ời quản lý dự án, là thời kỳ, tổ chức trong thời
gian đó cơ cấu đội ngũ dự án đ-ợc hoàn tất và việc phân trách nhiệm đã
xong. Những nhiệm vụ đó phải đ-ợc ng-ời quản lý dự án hồn thanmhf
tr-ớc khi kết thúc giai đoạn thiết kế vì sự lẫn lộn có thể có trong hai pha
đầu của dự án không thể đ-ợc chuyển sang giai đoạn thực hiện.

4.3.2 Những vấn đề trong pha thiết kế

Những vấn đề chính của giai đoạn thiết kế liên quan đến :

- Nhng tranh cói v thit k k thut

- Khó khăn về nhân sự

- Cung cấp nguồn lực phát triển
- Các quan hệ khách hàng

Nhng vn thit k k thut liên quan cả đến những gì do các yêu
cầu bất khả thi cũng nh- những gid do những quyết định thiết kế và thực
hiện phức tạp. Chính trong pha thiết kế tất cả những vấn đề đó phải đ-ợc
giải quyết vì việc giải quyêtd chúng sẽ trở nên tốn kém hơn khi dự án
tiến triển.

Đôi khi, những vấn đề nhân sự đ-ợc chuyển từ giai đoạn yêu cầu tr-ớc
đây. Việc tuyển ng-ời cho một số nhiệm vụ là khó hay chậm do đấy quan
trọng cho ng-ời quản lý dự án là phải tìm cách bố trí nhân viên vào mọi
vị trí dự án cáng sớm càng tốt thậm chí tr-ớc những ng-ời hiện nay đ-ợc
yêu cầu. Trên thực tế, đây là một thói quen tốt trong việc bắt đâu bố trí
nhân viên vào những vị trí tr-ớc ngày mà nhân viên đó thực sự tham gia
dự án . Nhiều vấn đề liên quan đên việc cung câó nguồn ực phát triển
đ-ợc tiến hành từ giai đoạn tr-ớc song ở pha này của dự án những vấn đề
này thwng đ-ợc phối hợp hoặc với những ng-ời bán hàng bên ngoài và
những ng-ời cung cấp hoặc thiết bị cơng ty hiện có mà nó vẫn cịn ràng
buộc với các dự án khác. Nh- đã nêu tr-ớc đây, nhiều những vấn đề đó
th-ờng có thể đ-ợc giải quyết bằng cho vay hay thuê thiết bị. Dù sao tác
động không lợi của những giải pháp tạm thời nh- thế lại tăng lên khi dự
án chuyển sang những giai đoạn phát triển tiên tiến hơn. Trên thực tế,
những giải pháp đó, nếu khơng đ-ợc xử lý thận trọng, có thể dẫn đến
những vấn đề mới :

- Thuê có thể tốn kém và có thể hao phí những số tiền đáng kể ở ngân
sách phát triển.

</div>
(69)<div class='page_container' data-page=69>

- Những giải pháp thay thế tạm thời có thể dẫn đến chất l-ợng sút giảm
và thời gian phát triển kéo dài. Rút cục điều này lại dẫn đến tình trạng
lịch trình bị tr-ợt

Một số vấn đề liên quan khách hàng, ng-ời sản xuất vẫn cịn có thể
xảy ra trong pha thiết kế. Với những yêu cầu giờ đây đ-ợc chấp thuận
.Phần lớn căng thẳng đã giảm đi nh-ng khi pha thiết kế kết thúc với việc
tổng duyệt chính thức, khách hàng chia xẻ trách nhiệm về thiết kế
đó.Điều này tăng thêm dính líu của khách hàng trong pha thiết kế và có
thể dẫn đến những bất đồng về hệ thống phải đ-ợc thực hiện thế nào.

Những loại vấn đề đó đ-ợc giải quyết tốt nhất bằng cách chỉ định một
thành viên đội ngũ (có thể là ng-ời quản lý dự án) hành động nh- mối
liên lạc với khách hàng. Điều này giảm những điểm tiếp xúc giữa đội ngũ
và khách hàng trong khi vẫn đảm bảo rằng khách hàng có một địa chỉ
duy nhất cho mọi yêu cầu và nhận xét.

4.4 Pha thùc hiÖn.

Trong pha thực hiện, các mơ đun phần mềm đ-ợc mã hố và các thử
nghiệm đơn vị ban đầu đ-ợc tiến hành. Thử nghiệm đơn vị đ-ợc ng-ời
lập trình tiến hành trên mỗi mơ đun cá thể ngay sau khi mơ đun đó đ-ợc
mã hố. Sau đó các mơ đun đ-ợc bộ phận kiểm tra chất l-ợng phần mềm
phê chuẩn và đ-ợc đệ trình bộ phận kiểm tra cấu hình (coi ch-ơng 7 về
thảo luận các chức năng kiểm tra đó). Sau đó bộ phận kiểm tra cấu hình
chuyển các mơ đun để hợp nhất.

Đặc tả thiết kế chi tiết và cấu trúc tốt dẫn đến việc lập mã t-ơng đối
trơn chu và thẳng băng13. Theo thế việc lập mã (hay lập trình) thoạt kì

thuỷ đ-ợc nhận thức là đồng nghĩa với phát triển phần mềm , nay đã trở
thành một pha riêng rẽ trong chu trình phát triển phần mềm . Trên thực tế
pha thực hiện lại cũng không là pha dài nhất. Một kinh nghiêm thơng
th-ờng đề dự tính các pha của chu trình phát triển phần mềm sử dụng
cách phân chia theo tỉ lệ 40-20-40 công sức và thời gian (coi bảng 4.1).
Điều này có nghĩa khoảng 40% thời gian đ-ợc giành cho đặc tả (yêu cầu
và thiết kế ) 20% cho thực hiện (lập trình và thử nghiệm đơn vị) và 40&
cho tích hợp và thử nghiệm xu h-ớng chung là tìm cách giảm 20% giành
cho thực hiện trong khi tăng 40% gianh cho đặc tả ? . Một khía canh của
lập luận đằng sau tiếp cận đó là các giai đoạn phát triển sớm hơn ít tốn
kém hơn các giai đoạn sau. Các pha đặc tả th-ờng có nhân lực thấp và ít
thiết bị phát triển hơn pha thực hiện. Cũng vậy nh- th-ờng đã chứng
minh khi công sức đ-ợc giành nhiều hơn cho yêu cầu và thiết kế, pha tích
hợp dễ dàng hơn và hiệu quả hơn.

Pha thực hiện là cầu nối các pha thiết kế và tích hợp hệ thống và
th-ờng gối đầu rõ rệt với mỗi một trong hai pha đó (coi hình 4.5). tình
trạng gối đầu sẽ th-ờng xảy ra khi nhiều bộ phận của thiết kế hệ thống
13Điều này đ-ợc thuyết minh qua nhiều cố gắng để phát triển các máy sinh mã tự động tạo lập mã

</div>
(70)<div class='page_container' data-page=70>

đ-ợc thực hiện t-ơng đối nhanh để lại một số vấn đề thiết kế bỏ ngỏ một
thời gian kha khá. Trong những tr-ờng hợp đó gối đầu có thể rút ngắn
đáng kể lịch phát triển.

Tình trạng gối đầu của các pha thiết kế và thực hiện đòi hỏi phải rất
thận trong trong việc đảm bảo chỉ những mơ đun thiết kế hồn chỉnh
đ-ợc phê chuẩn để thực hiện sớm. Có rủi ro là mọi thay đổi chậm sau này

về thiết kế của những mô đun đó có thể địi hỏi phải lập mã lại. Theo thế
lãng phí tài ngun . Cũng có rủi ro là thiết kế thay đổi và mã không thay
đổi. Dù sao những rủi ro đó th-ờng vẫn nắm bắt đ-ợc tốt. Với qui hoạch
và khống chế kiểm tra cấu hình tốt những vấn đề đó có thể đ-ợc khắc
phục

T
H×nh 4.5

Sù gối đầu của các pha

Mt khỏc ca pha thc hin, tình trạng gối đầu của lập mã và ích hợp
th-ờng ít rủi ro và nếu đ-ợc qui hoạch đúng đắn có thể là một sự tiết
kiệm thời gian tuyệt hảo. Trình tự thực hiện của các mơ đun phải đ-ợc
qui hoạch tốt đảm bảo chúng đ-ợc đ-a ra theo trình tự u cầu để tích
hợp . Điều này cũng có nghĩa những sai lầm trong thực hiện có thể định
vị trong q trình tích hợp và đ-ợc hồi tiếp lại pha thực hiện .

Pha thực hiện bao gồm những hoạt động chính sau đây :
- Phát triển mã phần mềm

- Chuẩn bị cho sự tích hợp và thử nghiệm hệ thống (giai đoạn sao)
- phát triển kế hoạch bảo trì

Ngoài mÃ hiện tại đ-ợc viết (vá mong đ-ợc bình tốt) một số t- liệu
khác đ-ợc phát triển trong pha này bao gåm :

- Sổ ghi của ng-ời lập trình dẫn ghi lại các quyết định lập mã những
thử nghiệm đơn vị và giải pháp cho những vấn đề thực hiện .

- Kế hoạch bảo trì và thu thập t- liệu, kể cả t- liệu cốt yếu cần thiết
cho việc bảo trÞ hƯ thèng.

Pha thiÕt kÕ

Pha thùc thi

</div>
(71)<div class='page_container' data-page=71>

- Các bản ban đầu về t- liệu cho ng-ời dùng, kể cả sổ tay tham khảo
và h-ớng dẫn cho ng-ời ®iỊu hµnh.14

Trong pha thực hiện, dự án b-ớc vào thời kỳ hoạt động khẩn tr-ơng.
Nhiều hoạt động khác diễn ra bao gồm :

- Pha thiết kế đ-ợc hoàn tất sớm trong q trình pha thực hiện .
Nền tích hợp đ-ợc định vị và việc tích hợp bắt đầu.

Nền của thử nghiệm (môi tr-ờng và thiết bị thử nghiệm) đ-ợc định vị
để chuẩn bị cho việc thử nghiệm hệ thống

- Các tình huống củi ro có thể đ-ọc trở thành hiện thực và khi đó các
kế hoạch dự phịng bất trắc -c -a vo hot ng.

- Kế hoạch dự án đ-ợc duyệt lại và cập nhật.

4.4.1 Bàu không khí trong pha thùc hiÖn

Nh- chúng ta đã thấy, việc tổ chức nhân sự đạt đến đỉnh cao trong các
pha thực hiện và hợp nhất. Trong lúc thực hiện bầu không khi chịu ảnh
h-ởng bởi nhiều hoạt động khác tiến hành song song. Bàu khơng khí này
đặc tr-ng ở .

- áp lực đ-ợc tiếp tục và đ-a ra cái gì đó. điều này th-ờng là kết quả
của viẹc gia tăng đáng kể về mức độ tăng chi phí nh-ng vẫn cịn ít chỉ ra
đ-ợc chi phí phát triển.

- Tranh chấp với các tổ chức bảo hiểm chất l-ợng phần mềm (SQA) và
kiểm tra cấu hình. Những tranh chấp này là do sự dính líu gia tăng của
các tổ chức giám sát đó và vai trò của họ trong việc thúc ép các tiêu
chuẩn và các thủ thục phát triển có trình tự

- Hoath động của đội ngũ phát triển gia tăng chỉ còn thì gió cịn lại
trong ngày giao sản phẩm đã tới gàn và trở nên thục tiễn hơn.

Nói chung, pha thực hiện là thời kỳ chuyển tiếp từ đặc tả sang xây
dựng. Bầu khơng khí tuỳ thuộc rất nhiều ở thành công của các pha đặc tả
tr-ớc đây và thành công trơng đợi ở các pha tích hợp và thử nghiệm.
Những nhân tố đóng góp bao gồm :

- Yêu cầu có thể còn ch-a đ-ợc xác định đầy đủ.
- Tài nguyên khơng đủ đ-ợc bố trí

- Thời gian phát triển khơng đủ.

- Một số vấn đề kỹ thuật có thể cịn ch-a đ-ợc giải quyết
- Hỗ trợ quản lý có thể thiu

- Quan hệ khách hàng có thể căng .

4.4.2 Nhng vấn đề trong pha thực hiện

Nếu pha thiết kế đ-ợc thực hiện tốt, hầu hết những vấn đề kỹ thuật
phải đ-ợc giải quyết vào cuối dợt thiết kế. Nếu không đ-ợc nh- thế có
thể dẫn đến lẫn lộn do sự cần thiết phải lập trình và giải quyết đồng thời

14 Nhiều tiêu chuẩn mô tả nội dung của t- liệu có đ-ợc trong dự án phần mềm. USMilstd- 2167a

</div>
(72)<div class='page_container' data-page=72>

những vấn đề kỹ thuật. những tình huống nh- thế th-ờng rơi vào ph-ơng
pháp mã và định vị (coi hình 4.1)

Các vấn đề khác của giai đoạn thực hiện bao gồm :

- Các thay đổi phút chót : Đây là một vấn đề chỉ có thể đ-ợc giải quyết
bằng cách đảm bảo thủ tục khống chế các thay đổi một cách nghiêm ngặt
và có trình tự

- Giao tiếp và phối hợp giữa các thành viên đội ngũ, vấn đề này đặc
biệt nghiêm trọng trong các dự án lớn

- KiÓm tra và điều khiển các chủ thầu phụ và ng-ời phụ và ng-ời bán
hàng .

Lung thay i l tai ha của cơng trình nói chung và của phát triển
phần mềm nói riêng. Rõ ràng thay đổi phải đ-ợc phép trong một chừng
mức nh-ng luồng thay đổi khơng kiểm sốt đ-ợc có thể làm cho dự án
sụp đổ. (quị).

Cững có nguy cơ là ở các đội ngũ lớn, một số thành viên có thể khơng
nhận thức đ-ợc một thay đổi đặc biệt.

Truyền thơng chính thức khi đó đ-ợc xá định giữa các đội nhỏ.

Trong một số tr-ờng hợp các hệ con có thể đ-ợc uỷ thác cho những
chủ thầu phụ. Dù sao việc khống chế những chủ thầu phụ và những ng-ời
bán có thể trở thành một cơng việc trọn thời gian. Những báo cáo miệng
và viết ít khi là đủ, những cuộc thăm viếng th-ờng xuyên tại chỗ phát trển
th-ờng là cần thiết để đảm bảo tính sẵn sàng của thơng tin chính xác.
Trong những tr-ờng hợp đó, ng-ời sản xuất trở thành khách hàng trong
hệ với ng-ời bán hay ch tu ph.

4.5 Pha tích hợp và thử nghiệm.

Trong cỏc pha tích hợp và thử nghiệm, các mơ đun phần nền đ-ợc phối
hợp thành một hệ duy nhất và tính chức năng của hệ đ-ợc thử nghiệm về
mặt đáp ứng với yêu cầu. Tích hợp bắt đầu bằng dạng ban đầu của hệ
thống mà hệ thống này tăng dần về chức năng cho đến khi một thệ thống
đầy đủ đ-ợc lắp gộp lại . Sau đó mỗi giai đoạn thử nghiệm đánh giáo sự
hoàn thiện của hệ thống nhằm minh định các vấn đề phải chỉnh lý tr-ớc
khi hệ thống cú th -c -a ra.

Giai đoạn tích hợp và thử nghiệm tạo có sở cho :

- Việc xây dựng hệ thông phần mềm từ các thành phần phần mềm
khác nhau.

- Tích hợp thiết bị phần mềm và phần cứng

- Xỏc định xem hệ thống có đ-ợc xây dựng theo những c t yờu cu
hay khụng

-Tạo ra chất l-ợng của hệ thèng.

</div>
(73)<div class='page_container' data-page=73>

những ng-ời sản xuất. trong những dự án nhỏ, điều hợp lý đắng sau sự
phối hợp của hai hoạt động vào một pha là sự tích hợp khơng thể thành
cơng nếu khơng có thử nghiệm rộng rãi đ-ợc tiến hành song song. do đấy
nếu hai hoạt động đó đ-ợc cùng một đội ngũ thực hiện, th-ờng tốt nhất là
phối hợp chung trong một pha duy nhất (coi ch-ơng 7 có thảo luận chi
tiết hơn về đội ngũ th nghim phn mm).

Có nhiều kỹ thuật và ph-ơng pháp tích hợp
- Từ trên xuống

- Từ d-ới lên

và một cách tiếp cận lý thú đ-ợc gọi là
- Từ trong ra

Tip cận trfên xuống đòi hỏi cốt lõi của hệ thống (th-ờng là các mô
đun đuều hành trung tâm) phải đ-ợc thực hiện tr-ớc. Rồi chúng đ-ợc
phối hợp một hệ thống cực nhỏ sử dụng những thủ tụcvỏ rỗng thay cho
các mơ đun ch-a đ-ợc thực hiện. Những vỏ rỗng đó của mã trả lại những
giá trị cố định và chẳng có tính lơgic gì cả, th-ờng đ-ợc gọi là cuống. Sau
đó các cuống đ-ợc thay dần bằng các mơ đun thực, theo một cách xây
dựng tăng tiến có kế hoạch tốt của hệ thống sao mỗi lần thệ thông đ-a ra
mới, lại tăng thêm nhiều chức năng hơn.

Tiếp cận d-ới lên bắt đầu từ các mô đun cá thể ở cấp thấp nhất (thí dụ :
- bộ điều khiển đầu vào đầu ra, bộ định khuôn,dạy thao tác,dữ liệu, bộ
đối thoại ng-ời dùng,máy v.v..) và dần dần gép chúng thành những nhóm
mỗi lúc mỗi lớn hơn cho đến khi tồn bộ hệ thống đ-ợc ghép lại.

- Cách tiếp cận d-ới lên ít khi đ-ợc khuyên dùng làm chiến tích hợp dễ
hiểu, trong hầu hết tr-ờng hợp cách tiếp cận trên xuống đễ hơn và tự
nhiên hơn. Dù sao trên thực tế, hầu hết các chiến l-ợc tích hợp hệ thống
thành công là một phối hợp của cách tiếp cận trên xuống và lác đác đôi
chỗ theo cách tiếp cận từ d-ới lên.

Tích hợp từ trong ra (indide out integration) là thông th-ờng trong sự
phát triển của các hệ cơ sở dữ liệu lớn khi các cấu trúc file nội bộ đ-ợc
xây dựng tr-ớc sau đó là logic xử lý dữ liệu và cuối cùng giao diện với
con ng-ời. tiếp cận này là tốt nhất khi hệ thống về mặt logic là các tấng
chức năng kế tiếp nh-ng điểm yếu chính của nó là giao diện với con
ng-ời lại th-ờng là đ-ợc tích hợp cuối cùng. Điều này có thể địi hỏi viết
mã thử nghiệm tạm thời để đầu ra có thể đ-ợc duyệt xét lại. Do đấy thử
nghiệm th-ờng chậm hơn và khó hơn so với tiếp cận từ trong ra.Việc thử
nghiệm bắt đầu bằng việc tích hợp và tiếp tục tới khi cuối cùng hệ thống
đ-ợc bàn giáo cho khách hàng. Các loại thử nghiệm bao gồm :

- Thö nghiệm tích hợp : Thực hiên bằng các máy tích hỵp cđa hƯ
thèng.

- Thử nghiệm độc lập : Thực hiện bơi nhóm thử nghiệm bên ngồi để
đảm bảo thử nghiệm khách quan không thiên lệch.

</div>
(74)<div class='page_container' data-page=74>

trong một môi tr-ờng điều hành. Nhiều hệ thống bao gồm một bộ thử
nghiệm lắp đặt để đảm bảo hệ thống đ-ợc lắp t thnh cụng .

- Thử nghiệm alpha và bêta.

cỏc th nghiệm nàytiến hành trong hệ thống trong một môi tr-ờng thực
(khơng phải thử nghiệm trong phịng thí nghiệm test). Thử nghiệm alpha

thử nghiệm hệ thống khơng có dữ liệ sống. Thử nghiệm beta thử nghiệm
hệ thống có sử dụng dữ liệu sóng có giám sát th-ờng xuyên để chỉnh lý
mọi vấn đề có thể phát sinh.

- Thư nghiƯm nghiƯm thu. Đây là cột mốc cuối cùng của dự án và sự
hoàn tất thắng lợi của nó có nghĩa lá sự nghiêm thu của khách hàng về
sản phẩm đ-ợc phát triển.

Vo lúc kết thúc pha tích hợpvà thử nghiệm mọi t- liệu phả đâỳ đủ và
sẵn sàng để giao bao gồm :

- T- liệu bảo trì

- T- liệu của ng-ời dùng ci cïng
- Mäi t- l;iƯu ph¸t triĨn cËp nhËt

- T- liệu thử nghiệm và báo cáo thử nghiệm

Song song vi tích hợp và thử nghiệm, các hoạt động quản lý và không
phát triển sau đây diễn ra :

- Lập ngân sách cuối cùng của dự án, phí tổn cho các thay đổi (phát
minh) đ-ợc xác định hoạt dộng dự phòng rủi ro đ-ợc đánh giá và ngân
sách đ-ợc cập nhật .

- Việc huấn luyện đ-ợc tiến hành cho ng-ời dùng, ng-ời vận hành,
khách hàng, ng-ời lắp đặt, kỹ s- bảo trì và sỹ s- tiếp thị.

- Địa điểm lắp đặt đ-ợc chuẩn bị và hạ tầng có sở cho phần cứng cà
thiết bị đặc biệt đ-ợc lập kế hoạch và lắp đặt.

- Qui mô đội ngũ phát triển đ-ợc giảm i.

4.5.1 Bầu không khí trong pha tích hợp và thử nghiƯm

Cho đến điểm này trong vịng dời của dự án văn bản đã đ-ợc soạn
thảo, mã đ-ợc phát triển và thiết bị phát triển đ-ợc lắp đặt không kể các
nguyên mẫu thì chela có chức năng nào là đã đ-ợc phát triển xong pha
tích hợp và thử nghiệm bắt đầu lúc chi phí nhân sự và ngân sách đạt đỉnh
cao. Do đấy hợp nhất và thử nghiệm th-ờng đ-ợc biểu thị bằng :

- áp lực có đ-ợc cái gì làm việc . Điều này đã bắt đầu trong pha thực
hiện tr-ớc đây và giờ đang gia tăng. Quản lý đã ít nhìn thấy một chút
thực chất để biện minh cho đầu t- của họ. Mọi chậm trễ lịch trình ở điểm
này có thể nghiêm trọng quan trọng đối với ng-ời quản lý dự án,là phải
tạo đ-ợc phiên bản ban đầu ca h thng cng sm cng tt.

- áp lực hoàn thành dự án. áp lực này xuất hiện vào lúc cuối dự án và
trở thành mÃnh liệt hơn nếu lịch trình bắt đầu tr-ợt.

</div>
(75)<div class='page_container' data-page=75>

- Tranh chấp với khách hàng. Cuối cùng khách hàng có thể nhìn thấy
phiên bản ban đầu của cái mà sản phẩm sẽ có dáng vẻ thế nào. Về điều
này, có những lý giải yêu cầu khác nhau nảy sinh ra và th-ờng cần đ-ợc
giải quyết ở cấp quản lý cao hơn.

- Tht vng. Những giải pháp cho các vấn đề tích hợp và các lỗi thực
hiên th-ờng khs nắm bắt và có thể địi hỏi trở lại pha thiết kế.

Pha tích hợp và thiết kế vẫn là khó lập kế hoạch nhất. Đó cũng lại là
quan trọng nhất trong lập kế hoạch vì hiện đã có qủ tránh đ-ợc tốt nhất

khi đảm bảo.

- Thiết kế tốt

- Kế hoạch lập mÃ môđun hiệu quả
- §éi ngị ph¸t triĨn cã tỉ chøc tèt
Mét kÕ hoạch tích hợp tốt

-Nên cho tích hợp và thử nghiệm là tích hợp

4.5.2 Nhng vn trong pha tớch hợp và thử nghiệm

Chính là trong pha tích hợp và thử nghiệm hều hết những vấn đề phát
triển xuất hiện. Những sự cố mô tả tr-ớc đây trong dự án nh- là các rủi ro
thì bây giờ đã thành hiện thực và những vấn đề bất ngờ khác nảy sinh
không thể tránh đ-ợc . Những vấn đề đó gồm :

- Phá sản vào phút chót : sai lầm thiết kế và những vấn đề thực hiện
nảy sinh. Đó là những loại vấn đề khó khám phá nếu khơng có phiên bản
vận hành của hệ thống. Dp đấy chúng không đ-ợc phát hiện sớm trong dự
án.

- Những vấn đề về bên thứ ba kể cả giao chậm về phía ng-ời bán và
chủ thầu phụ và khuyết tật trong hệ thống phụ và thành phần của họ

- Thay đổi phút chót. Vấn đề này tồn tại ở mọi pha nh-ng càng trở nên
nghiêm trọng hơn khi dự án cáng tiến triển. Giờ đây thay đổi trở nên tốn
kém hơn.

- V-ợt quá ngân sách (thậm chí, bội chi) vấn đề này là do những thay

đổi và sai lầm thiết kế cũng nhu sai lầm trong qui hoạch dự án.

- Những vấn đề động viên nhân sự. Điều này th-ờng xảy ra vào cuối dự
án trong các giai đoạn thử nghiệm cuối cùng.

- Những vấn đề nghiệm thu dự án. Vấn đề này đặc biệt phổ biến lở
những dự án giá cố định (coi ch-ơng 3) khi các tranh chấp nảy sinh liên
quan đến việc hồn thành dự án

Nhiều những vấn đề đó có thể tránh đ-ợc hay ít ra tính nghêm trọng
của chúng có thể giảm đi khi chuẩn bị đón chúng sớm trong dự án chính
vì quản lý rủi ro bao gồm cả chuẩn bị kế hoạch dự phòng trong tr-ờng
hợp sự cố rủi ro diễn ra thì tính nghiêm trọng của bất cứ vấn đề nào
th-ờng có thể đ-ợc giảm đi khi có kế hoạch cho nó.

</div>
(76)<div class='page_container' data-page=76>

Điều này có nghĩa khơng có thay đổi nào khơng ngoại lệ có thể đ-ợc
chấp nhận trừ phi đ-ợc đệ trình thơng qua các kênh khống chế thay đổi.

Qui hoạch cho những thất bại ở phút chót và sai lầm thiết kế lại càng
khó khăn hơn. Giải pháp fthơng th-ờng cho những loại vấn đề này là
chấp nhận rằng thất bại và sai lầm là khơng tránh đ-ợc . Điều này có
nghĩa chúng phải đ-ợc tính đến trong lịch trình dự án ngay dù chúng
không thể đ-ợc minh định tr-ớc. Cách cổ truyền trong việc lập lịch các
vấn đề ch-a biết là thêm một phần trăm cố định vào lịch trình phát triển.
Kinh nghiệm là cộng thêm 30% cho những chậm trể không l-ờng đ-ợc
và những vấn đề không dự kiến đ-ợc mặc dù một tổ chức phát triển sẽ
cuối cùng tích luỹ thơng tin cần thiết xác định những dự phịng lịch trình
của riêng mình, bảng 4.2 là một khởi điểm tốt. Ch-ơng 10 thảo luận về
những biện pháp phực tạp hơn nhằm cải tiến dự toán dựa trên loại dự ỏn
-c phỏt trin.15

Loại phần mềm Bổ sung vào lịch trình

Hệ thống xử lý dữ liệu th-ơng mại nhỏ 10%
Hệ thống xử lý dữ liệu th-ơng mại loại vừa 15%
Hệ thống xử lý dữ liệu th-ơng mại loại lớn 20%

Hệ thống truyền thông 33%

Các hệ thống khoa học, bộ biên dịch v.v. 25%

Các hệ thốngđiều hành 25%

Các hệ thống thời gian thực 33%
Các giao diện của ng-ời dùng 15%
Phát triển phần cứng,phần mềm 35%

Bảng 4.2

Những nhân tố dự phòng lịch trình của dự án phần mềm

4.6 Pha bảo trì

Pha bo trỡ hoàn tất chu kỳ phát triển phần mềm và dẫn đến việc cung
cấp cho thị tr-ờng sản phẩm phần mềm hoàn chỉnh với việc phát triển sản
phẩm mới. Từ bảo trì phần mềm là có thể gây tranh cãi vì nó bao hàm
nhu cầu sửa chữa đã bị h-. Trong các hệ thống cơ học hay điện tử, việc
bảo trì có thể địi hỏi sửa chữa hay thay thế những thành phần bị h- hại
và việc bảo trì dự phịng có thể địi hỏi việc dịch vụ với các thành phần
phịng ngừa h- hỏng. Dù sao phần mềm khơng h-. Bộ máy mang phần

</div>
(77)<div class='page_container' data-page=77>

mềm có thể h- nh-ng bản thân phần mềm xẽ không thay đổi16nếu không

cã can thiƯp cđa con ng-êi.

Định nghĩa của IEEE về bảo trì phần mềm (IE E 19876) bao gồm cả
việc hiệu chỉnh lỗi đã có trong phần mềm tr-ớc khi đ-ợc giao hàng. Cũng
nh- những thay đổi nhằm cải tiến cho hồn mỹ hay thích ứng snả phẩm
với một mơi tr-ờng bị đổi.

Hai hoạt động khác là một phần của bảo d-ỡng đó là
- Duy trì thơng tin cập nhật

-CËp nhËt nh÷ng líp hn lun ng-êi dïng

Khơng giống nh- bảo trì phần cứng, khơng có một hoạt động nào trong
đó lại làm cho phần mềm trở lại trạng tháo ban đầu của nó.

Điều trái lại mới hồn tồn đúng : mục tiêu ở đây là sửa đổi phần mềm
sửa đổi phần mềm bao gồm mọi đặc điểm của phát triển phần mềm.
Những điều sửa đổi cần đ-ợc mô tả, thiết kế, thực hiệnm hồ nhập và thử
nghiệm chính thức, và tất nhiên,những sửa đổi cần đ-ợc tái trợ . Do đấy
đó là thực hành cơng trình vững chắc để thực hiện giai đoạn bảo trì coi
nh- một loạt những dự án phần mềm nhỏ.

Kiểm tra cấu hình là đặc biệt quan trọng trong thời gian bảo trì để quản
lý những thay đổi với phần mềm và kiểm tra những đợt phát hành và
phiên bản của hệ thống. Điều này đảm bảo những đợt phát hành định kỳ

có trật tự của phần mềm và tránh đ-ợc hỗ trợ phiêu l-u và cố định tại chỗ
có thể trở thành cơn ác mộng cơng trình.

Quản lý dự án khơng phải bao giờ cũng đ-ợc tiến hành từ phát triển
sản phẩm phần mềm sang giai đoạn bảo trì bảo trì địi hỏ một đội nhỏ
hơn nhiều và quản lý kiểu khác. Trên thực tế, một nhóm bảo trì duy nhất
có thể đ-ợc thiết lập để bảo trì nhiều sản phẩm với quản lý chung, khống
chế cấu hình kỹ s- lắp đặt và hiện tr-ờng và bo trỡ t- liu.

T- liệu cần đ-ợc cập nhật trong giai đoạn này bao gồm :
- T- liệu phát hành phiên bản

- Cỏc bỏo cỏo vn
- Mi t- liu phát triển
- Mọi t- liệu của ng-ời dùng

- nhËt ký bảo trì và báo cáo dịch vụ khách hàng

Bo trỡ đ-ợc tiếp đọc chừng nào sản phẩm phầm mềm đ-ợc lắp đặt và
hoạt động. Khi hệ thống già đi, các kế hoạch đ-ợc chuẩn bị cho một dự
án phát triển mới thay thế cho hệ thống lão hoá. Vào lúc đó, các cố gắng
bảo trì đ-ợc giảm tới mức tối thiểu do kỳ vọng là mọi sửa đổi yêu cầu và
hiệu chỉnh sai kỹ thuật sẽ đ-ợc có trong hệ thng mi.

4.6.1 Bầu không khí trong pha bảo trì

16Theo mt nghĩa nào đó, phần mềm có thể đ-ợc coi là đang thay đổi nếu do sai sót về con rệp hay

</div>
(78)<div class='page_container' data-page=78>

Trong nhiều tr-ờng hợp, bảo trì khơng tạo ra thách đố phát triển mới.
điều này có thể dẫn đến đội ngũ bảo trì khơng ổn định với số kỹ

s-th-ờng xuyên nhập và rời bỏ đội ngũ. Dù sao bảo trì có thể tạo ra nhiều
thách đố chẳng hạn nhận biết những vấn đề gay cấn, tạo ra giải pháp và
gợi ý các cải tiến. Nói chung, giai đoạn bảo trì đặc tr-ng ở.

- Thiếu nhiệt tình, trong nhiều tr-ờng hợp, do thiếu thách đố kỹ thuật
xác định cụ thể.

- áp lực tạo ra định vị nhanh chóng. Trong mơut mơi tr-ờng bảo trì có
trật tự, hiệu chỉnh vấn đề th-ờng hiếm khi nhanh đ-ợc .

- Vỡ mộng do thiếu ngân sách đầy đủ. Các hoạt động bảo trì khơng
phải bao giờ cũng đ-ợc cơng nhận là quan trọng và do đó th-ờng khơng
đủ ngân sách để chi

4.6.2 Những vấn đề trong pha bảo trì

Nh- chúng ta đã thấy, bảo trì phần mềm bao gồm mọi pha của tồn bộ
dự án phát triển. Do đó nhiều vấn đề phát triển th-ờng thấy trong các pha
phát triển cơ bản lại cũng là thơng th-ờng trong pha bảo trì.

Các vấn đề khác đặc tr-ng cho pha này bao gồm :

-Khơng đủ kỹ s- bảo trì có đủ kiến thức do khó khăn trong việc tuyển
kỹ s- tự nguyện nhận cơng việc bảo trì

- Những vấn đề ngân sách liên kết với những phát hành mới của hệ
thống.

- Chắp vá chằng đụp của hệ thống hiện có. Sau một thời gian, ngay cả
thủ tục bảo trì có trật tự cũng có thể tạo ra một hệ thống phần mềm chắp

vá. Điều nàyth-ờng nhắc nhở sự phát triển hệ thống mới.

- Thiếu thiết bị hỗ trợ và nền thử nghiệm. Vấn đề này lại cũng th-ờng
là kết quả của ngân sách khơng đủ cho các hoạt động bảo trì.

Với ng-ời quản lý bảo trì, tuyển đội ngũ bảo trì chủ yếu là vấn đề tạo
lập sự bổ nhiêm lý thú và thách thức. Điều này th-ờng có thể thực hiện
bằng cách giao trách nhiệm về một dự án đơn giản hay một bộ phận xác
định rõ của một dự án lớn cho một kỹ s- phần mềm. việc uỷ nhiệm này
bao gồm cả việc minh định vấn đề, cung cấp giải pháp và gợi ý cải tiến
trong phạm vi trách nhiệm của kỹ s- đó.

Cách tiếp cận này thúc đảy sự tận tuỵ của kỹ s- với nhiệm vụ và sự
đồng nhất của anh (hay chị) với sự thành công của cố giắng bảo trì.
Khơng giống nh- động cơ nhân lực đội ngũ, những vấn đề ngân sách và
thiết bị không phụ thuộc tr-ớc hết ở ng-ời quản lý bảo trì ngân sách phải
đ-ợc đảm bảo từ quản lý cấp cao và th-ờng đ-ợc tài trợ bởi các ng-ời
dùng hệ thống cần đ-ợc bảo trì. Lệ phí hàng tháng hay hàng năm là cách
thông th-ờng cho việc tạo ngân sách để bảo trì.

</div>
(79)<div class='page_container' data-page=79>

Nh- chúng ta đã thấy, bảo trì mà khơng khống chế cấu hình có thể trở
nên cực kỳ khó khăn cho quản lý

4.7 Tãm t¾t .

Vịng đời phát triển phần mềm bao gồm mọi pha phát triển

Từ quan niệm ban đầu tới bàn giao cuối cùng của hệ thống. Có nhiều
cách tiếp cận khác nhau tới chu kỳ phát triển phần mềm kể cả ph-ơng
pháp mã và cố định, những ph-ơng pháp lặp (nh- tạo nguyen mẫu nhanh)

và cách tiếp cận theo pha

Cách tiếp cận theo pha tới phát triển phần mềm phân chia vòng đời
phát trin thnh

- Pha quan niệm
- pha yêu cầu
- Pha thiết kế
- Pha thực hiện

- Pha tích hợp và thử nghiệm
- Pha bảo trì

Tip cn theo pha (cng gi l mụ hình thác n-ớc) đ-ợc bao gồm trong
hầu hết các ph-ơng pháp luận phát triển phần mềm khác. Trên thực tế có
nhiều biến thể của mơ hình thác n-ớc cổ điển, nh-ng tất cả đều căn cứ ở
một quá độ có hệ thống tự một pha phát triển này sang pha sau cho đến
khi dự án hồn thành.

Mơ hình thác n-ớc bắt đầu bằng pha quan niệm ban đầu, trong quá
trình đó nhu cầu về hệ thống phần mềm đ-ợc xác định và quan niệm cơ
bản của hệ thống phần mềm tiến triển. Tiếp theo là pha yêu cầu nó cung
cấp mô tả chi tiết hệ thống phần mềm cần đ-ợc phát triển..Pha yêu cầu
quy định đ-ờng mốc chủ yếu đầu tiên của dự án. Sau xác định của yêu
cầu pha thiết kế sẽ phân tích các yêu cầu và xác định ph-ơng pháp thực
hiện, pha thiết kế th-ờng đ-ợc phân làm hai pha riêng biệt: Thiết kế mức
đỉnh và thiết kế chi tiết. Đ-ờng phân chia giữa hai pha này đ-ợc đặt ra
đôi phần tuỳ ý, căn cứ ở mức phân giải của hệ thống. Thiết kế của hệ
thống quy định đ-ờng mốc chủ yếu thứ hai của dự án trong pha sau (pha
thực hiện) các mô đun phần mềm đ-ợc mã hoá và các thử nghiệm đơn vị

ban đầu đ-ợc tiến hành. Sau đó, các mơ đun đ-ợc kiểm tra chất l-ợng
phần mềm chấp thuận và đ-ợc đệ trình lên kiểm tra cấu hình. Rồi kiểm
tra cấu hình phát hành những mơ đun để tích hợp

Trong pha tích hợp và thử nghiệm các mô đun phần mềm đ-ợc tập hợp
lại và hệ thống dần dà đ-ợc hình thành. Sau đó hệ thống đ-ợc thử nghiệm
xem có đáp ứng đặc điểm yêu cầu.

</div>
(80)<div class='page_container' data-page=80>

Bµi tËp

1. Một hãng sản xuất máy bay lớn đã quyết định cho các kỹ s- làm
việc tại nhà mình. Các kỹ s- đ-ợc cung cấp máy đầu cuối và mô đun và
họ sẽ liên lạc tự nhà với máy vi tính của cơng ty. Hãng sản xuất máy bay
cần bộ ch-ơng trình phần mềm truyền thông và giám sát để quản lý công
việc của kỹ s-. Bộ ch-ơng trình phải có đ-ợc đặc tr-ng an tồn tinh vi
phịng ngừa ng-ời khơng đ-ợc phép nhập vào hệ thống của công ty và sẽ
làm khởi động các hệ thống báo động nếu có có một truy nhập không
đ-ợc phép nh- thế. Hệ thống cũng phải giám sát giờ giấc kỹ s- làm việc
tại nhà và phải cung cấp nguồn lực chia xẻ hồ sơ dữ liệu chung và các
tiện ích phần mềm. Cuối cùng bộ ch-ơng trình phải có chứa cả trực tuyến
và mode theo bộ báo cáo các đặc điểm để cung cấp thông tin về việc
dùng hệ thống đó bởi các kỹ s- từ nhà họ.

Hãy phân tích bộ ch-ơng trình phần mềm và khảo sát các ph-ơng pháp
thực hiện khác nha. Đặc biệt, hãy so sánh cách tiếp cận tạo nhanh
nguyên mẫu với tiếp cận thác n-ớc. Giải thích lợi và bất lợi của mỗi cách
tiếp cận đối với dự án đó.

2. Xem xét sự chồng chéo các pha khi vận dụng ph-ơng pháp thác
n-ớc với hệ thống mô tả trong bài tập 1. Đặc biệt xem xét sự chồng chéo

của pha thực hiện với pha thiết kế. Chuẩn bị kế hoạch lập mÃ các mô đun
sao cho pha thực hiện có thể bắt đầu càng sớm càng tốt. Giải thích những
mô đun nào có thể đ-ợc tích hợp an toàn tr-ớc và bình luận rủi ro có thể
có.

3. Nh- ở bài tập 2 h·y xem xÐt rñi ro chång chÐo pha thùc hiện với pha
hợp nhất.

Chuẩn bị một kế hoạch tích hợp các mô đun phần mềm sao cho tích
hợp có thể bắt đầu càng sớm càng tốt. HÃy giải thích những mô đun nào
có thể đ-ợc tích hợp an toàn tr-ớc và bình luận rủi ro có thể có .

So sánh việc sử dụng kế hoạch tích hợp từ trên xuống với kế hoạch từ
d-ới lên và kế hoạch từ trong ra ngoài. Mô tả tiếp cận nào bạn có thể
khuyên nên dùng cho dự án này.

4. Hóy tho lun nhng vấn đề chính mà bạn có thể đợi chờ trong việc
phát triển hệ thống mô tả ở bài tập 1. Đặc biệt hãy xem xét những vấn đề
liên kết với việc xác định yêu cầu. Ai là khách hàng ?

Cũng xem xét những vấn đề tích hợp và thử nghiệm trong dự án này và
thảo luận những thay đổi yêu cầu có thể xảy ra. Các vấn đề đó sẽ đ-ợc sử
lý tốt nhất thế nào ?

5. Hãy xem xét ít ra 6 đặc điểm bổ sung và cải tiến cho hệ thống mô tả
ở bài tập 1. Chuẩn bị kế hoạch bảo trì dài hạn bao gồm việc phát hành các
hệ thống mới đã có hiệu chỉnh sai sót kỹ thuật và một số đặc điểm mới
trong mỗi lần -a ra phỏt hnh.

</div>
(81)<div class='page_container' data-page=81>

Ch-ơng năm

Nguyên tắc quản lý các

kỹ s- phần mềm

Liệu họ có thực sự có gì khác ?

Theo nhiu nghiờn cu, qun lý k s- phần mềm khó khăn hơn quản lý
kỹ s- ở hầu hết các lĩnh vực công nghệ khác. Kỹ s- phần mềm điển hình
(nếu có con ng-ời nh- thế) th-ờng đ-ợc biểu thị là vừa tài tử vừa lôgic
cũng nh- vừa phục tùng vừa thất th-ờng. Những nét đó có thể thấy ở bất
cứ nhóm ng-ời nào nh-ng có vẻ trội hơn trong các kỹ s- phần mềm.

Các kỹ s- phần mềm cũng lại rất đa dạng trong mức độ hiệu suất của
họ. Xa x-a, năm 1968, Sackman và cộng sự đã có t- liệu về sự chênh lệch
to lớn về hiệu suất giữa các nhà lập trình phần mềm. Sackman đã báo cáo
về tỉ lệ hiệu suất tới 25:1 về lập trìnhvà 28:1 về gỡ rối (ch-ơng trình).Tất
cả những nhà lập trình tham gia vào thí nghiệm đều quen thuộc với các
lĩnh vực ứng dụng của ch-ơng trình, khiến Sackman lý giải kết quả coi
nh- phạm vi tinh thông của h

Hình 5.1

Bốn cột mốc quản lý

Cỏc kt qu ca Sackman có thể có đơi chút cực đoan. Dù sao trong
một dự án trung bình khơng phải khơng phổ biến có tỉ lệ hiệu suất 1:5
một trong những mục tiêu của công nghệ phần mềm thời hiện đại đã là
giảm phạm vi hiệu suất kinh khủng đó giữa các nhà phát triển phần mềm.
Điều này đã làm đ-ợc thông qua việc phát triển có tổ chức và có hệ thống
hơn vốn khơng đ-ợc sự hài lịng của những ng-ời đứng đầu (cha tinh

thần) ở đầu cao của phạm trù hiệu suất. Những ph-ơng pháp luận phát
triển phần mềm đó cũng đã giảm đi tác động của những nét nhân bản
khác tới quá trình phát triển. Điều này đ-ợc thực hiện qua việc vận dụng
t- liệu, báo cáo, tiêu chí phát triển và các cuộc họp qui chế rộng rãi, bao
quát. Dù sao những thủ tục đó chỉ là số ít ph-ơng tiện quản lý con ng-ời.
Con ng-ời đ-ợc quản lý thông qua cơ cấu tổ chức. Cơ cấu tơn ti đó căn cứ

3 ThÈm qun Authority 4 Tr¸ch nhiƯm Responsibility
2 Gi¸m s¸t Supervision

</div>
(82)<div class='page_container' data-page=82>

trên bốn cột mốc quản lý : uỷ quyền, thẩm quyền, trách nhiệm và giám
sát. (coi hình 5.1). Uỷ quyền trao thẩm quyền, và thẩm quyền lại tạo ra
(và đòi hỏi) trách nhiệm. Cả thẩm quyền và trách nhiệm địi hỏi giám sát
và giám sát có hiệu quả lại địi hỏi cơ cấu tổ hức thích ứng.

Hầu hết các dự án đ-ợc tổ chức thành đội ngũ với mỗi đội ngũ đ-ợc
giao phó những chức năng đặc thù trong phạm vi dự án. Các loại dự án
khác nhau đòi hỏi những loại cơ cấu đội ngũ khác nhau nh- chẳng hạn
đội ngũ các nhà lập trình trung cấp đòi hỏi lãnh đạo đội ngũ kỹ thuật
trong khi đội ngũ chun gia có thể chỉ địi hỏi lãnh đạo đội ngũ hành
chính. Đó là trách nhiệm của ng-ời quản lý dự án trong việc chọn lựa cơ
cấu thích ứng nhất cho dự án.

Ch-ơng này đề cập đến những vấn đề đó về quản lý con ng-ời. Xuyên
suốt ch-ơng nhấn mạnh chủ yếu những vấn đề liên quan đến dự án phần
mềm. Về thảo luận khái quát hơn các ph-ơng pháp quản lý và động viên
con ng-ời, bạn đọc vui lòng tham chiếu cuốn lý thú do văn phịng thực
hành kinh doanh s-u tập (1981).

5.1 C¬ cÊu tỉ chức dự án phần mềm

Cú nhiu cỏch t chc d án phần mềm. Dự án càng lớn thì cơ cấu tổ
chức càng trở nên gay cấn hơn. Những dự án tổ chức tồi gieo rắc lộn xộn
và lộn xộn dẫn đến dự án thất bại.

H.5.2

Biểu đồ tổ chức dự án lớn phần mềm/ phần cứng

H.5.2 mô tả cơ cấu cơ bản của dự án trong đó bên d-ới ng-ời quản lý
dự án đúng là có 2 chức năng tổng quát phát triển và hỗ trợ.

Cơ cấu dự án phần mềm rất cơ bản này không phải không phổ biến
những năm 50 và 60. Đó vẫn cịn là cơ cấu dự án có giá trị cho những dự
án rất nhỏ (có đến năm nhà sản xuất) mặc dù có khi ngày nay vẫn cịn
thấy ở những dự án lớn.

H.5.3 Mơ tả biểu đồ tổ chức chi tiết kể cả những chức năng hỗ trợ chủ
yếu. Cơ cấu tổ chức này thích ứng với những dự án lớn (với nhân sự trên
20). Những dự án nhỏ có thể khơng địi hỏi phó quản lý dự án hay các
nhóm kiểm tra cấu hình và bảo hiểm chất l-ợng riêng biệt (coi ch-ơng 7
thảo luận chi tiết về các chuyên đề này). Những dự ỏn rt ln (nhõn s

Ng-ời quản lý dự án

Đội phát triĨn
dù ¸n

</div>
(83)<div class='page_container' data-page=83>

v-ợt qua 40) th-ờng có thể đ-ợc quản lý dễ dàng hơn khi phân dự án
thành những dự án phụ. Hình 5.4 cho thấy biểu đồ tổ chức một dự án lớn.

Biểu đồ này bao gồm cả đội ngũ phát triển phần cứng và phần mềm và
nhóm hợp nhất trong phạm vị mỗi nhóm.

H×nh 5.3

Biểu đồ tổ chức dự án phần mềm

H×nh 5.4

Biểu đồ tổ chức dự án phần mềm/phần cứng lớn

Lấy thí dụ, ta hãy xét tổ chức của 1 dự án vệ tinh lớn. Nguời quản lý dự
án trên thực tế chịu trách nhiệm về một số dự án. Trạm kiểm tra mặt đất,
bản thân trạm vệ tinh và trạm hoả tiễn. Phần mềm cho mọi dự án phụ đó
đ-ợc quản lý trong phạm vi văn phòng dự án duy nhất rồi mỗi dự án phụ
lại do một ng-ời quản lý dự án phụ, phụ trách. Biểu đồ tổ chực t-ơng tự
nh- mô tả ở hình 5.4 có thể đ-ợc áp dụng cho dự án vệ tinh, biểu đồ kết
quả đ-ợc mô tả ở hỡnh 5.5.

Chánh quản lý dự án

Phó quản lý dự án

Kỹ

s-hệ thống nghiệm độc lậpNhóm thử Bảo hiểm chất l-ợng Khng ch cu hỡnh
Th- ký

Đội phát triển 1 Đội phát triển 2 Đội phát triển n

Đội1 Đội2 Đội3 Đội1 Đội 2 Đội 1 Đội 2 Đội3
Chánh quản lý dự án

Phó quản lý dự án

Kỹ
s-hệ thống

Nhúm th
nghim c lp

Bảo hiểm chất l-ợng Khống chế cấu hình
Th- ký

</div>
(84)<div class='page_container' data-page=84>

Hình 5.5

Biểu đồ tổ chức dự án vệ tinh

Rõ ràng cơ cấu tổ chức của dự án tuỳ thuộc ở loại dự án đ-ợc phát
triển. Một số vấn đề phải xem xét là :

- Qui mô dự án : dự án càng lớn, tổ chức càng quan trọng. Những dự án
lớn có tổng phí thơng tin và phối hợp đáng kể về con ng-ời do đó địi hỏi
nhiều chức năng hỗ trợ hơn.

- Dự án phát triển phần mềm/phần cứng. Việc phát triển liên tiếp phần
cứng và phần mềm không dễ dàng. việc lập kế hoạch, hợp nhất và thử
nghiệm lại càng phức tạp hơn và địi hỏi những nhóm hỗ trợ tận tuỵ

Các gi/đốc dự án

Các gi/đốc chức năng

H×nh 5.6

Biểu t chc

Chánh quản lý dự án

Phó quản lý dự ¸n

Kü

s-hệ thống nghiệm độc lậpNhóm thử Bảo hiểm chất l-ng Khng ch cu hỡnh
Th- ký

Đội phát triển 1 Đội phát triển 2 Đội phát triển n

Đội1 Đội2 Đội3 Đội1 Đội 2 Đội 1 Đội 2 Đội3

Đội1

G/đ.
Dự án B
G/đ.

Dự án A

G/đ. thử nghiệm

Đội thử nghiệm

Đội bảo hiểm
ch/l.
Đội thử nghiệm

Đội bảo hiểm
ch/l.
G/đ. công trình

f/m.
G/đ. bảo hiểm c/l

nghiệm

Đội3
Đội2

Đội1
Đội3

</div>
(85)<div class='page_container' data-page=85>

- Cỏc hệ thống tin cậy cao. Bất cứ hệ thống nào nhạy cảm với các vấn
đề độ tin (nh- hệ thống quân sự hay cứu mạng) đòi hỏi cố gắng chủ yếu
về bảo hiểm chất l-ợng. Chất l-ợng cũng là một nhận định quan trong
trong nhiều sản phẩm phần mềm đ-a ra thị truờng (thí dụ bộ ch-ơng trình
thơng tin). Những loại dự án đó địi hỏi một tổ chức bảo hiểm chất l-ợng
riêng.

- Cơ cấu tập đoàn. Tổ chức dự án phụ thuộc rất nhiều vào cơ cấu tổng
thể của cơng ty trong đó dự án đ-ợc phát triển. Nhiều những chức năng
hỗ trợ dự án có thể đ-ợc các nhóm tập trung hố trong cơng ty cung cấp.

Trên thực tế, những dịch vụ cơ bản nh- dịch vụ tài chính văn phịng pháp
lý th-ờng do tổ chức bà con hay của tập đoàn cung cấp.

Cơ cấu tập đoàn th-ờng định ra một trong hai loại tổ chức dự án cơ bản
: ma trận hay khối tháp. Hình 5.6 mơ tả cơ cấu của một tổ chức ma trận
(so sánh với cơ cấu khối tháp trong hình 5.4).Trong một tổ chức ma trận
tập đoàn, ng-ời quản lý dự án quản lý những hoạt động kỹ thuật của đội
ngũ dự án trong khi dính líu của anh hay chị ấy tong những vấn đề nhấn
sự phi kỹ thuật (thí dụ duyệt l-ơng, đề bạt, đào tạo) thì rất ít.

Lỵi Ých cđa tỉ chøc ma trËn lµ :

- Tinh thơng hơn: Một tổ chức ma trận có thể giữ chuyên gia trong
những lĩnh vực đặc thù (thông tin, cơ sở dữ liệu, đồ hoạ.v.v) rồi những
ng-ời đó đ-ợc uỷ nhiệm vào các dự án khác nhau. Dự án đơn độc không
bao giờ có thể tự cho có đ-ợc điều xa xỉ trong việc giữ chuyên gia ở mọi
lĩnh vực.

- Cơ động : dễ chuyển ng-ời hơn từ dự án này đến dự án khác. Điều
này dẫn đến sử dụng đ-ợc tốt hơn sự tinh thơng có đ-ợc.

- Chú trọng về quản lý dự án: Ng-ời quản lý dự án đ-ợc rảnh rang về
nhiều những nhiệm vụ quản lý đội ngũ, giành đ-ợc nhiều thời gian hơn
tập trung vào những khía cạnh kỹ thuật của dự án. Dù sao tổ chức ma trận
cũng có những bất lợi đáng kể.

- ít biện pháp quản lý hơn. Một trong những công cụ đầu tiên trong
việc hình thành động cơ, đề bạt là tuột ra khỏi tay ng-ời quản lý dự án.
Nguời quản lý ít có ảnh h-ởng hơn đến l-ơng của ng-ời sản xuất và vai
trị chun mơn trong tổ chức.

- Tính trung thành của đội ngũ thấp hơn. Mọi nhân viên đều muốn biết
chính xác ai là cấp trên của họ. Trong một tổ chức ma trận, nhân viên có
hơn một cấp trên. Điều này tạo ra sự phân hoá trung thành và mối liên kết
yếu hơn giữa nhân viên và ng-ời quản lý.

Những bất lợi đó th-ờng lấn át những lợi điểm của tổ chức ma trận tập
đoàn. Động cơ là yếu tố chủ đạo cho sự thành công của dự án và mọi điều
gì xói mịn động có th-ờng đi ng-ợc lại lợi ích tốt nhất của dự án. Bất
hạnh là lợi ích tốt nhất của dự án lại khôngluôn luôn trùng hợp với những
lợi ích tốt nhất của cơng ty.

</div>
(86)<div class='page_container' data-page=86>

những ng-ời trên và d-ới họ. Khi đề bạt và qui chế đóng vai trị chủ yếu
trong hình thành động cơ : (và họ đã th-ờng làm thế) thì tổ chức khối
tháp là có hiệu quả nhất. Nhiều những yếu tố khác hình thành động cơ ý
thức hồn thành khen ngợi và quí trọng và đấy mới chỉ là một vài (coi
phần 5.4 thảo luận thêm về chuyên đề này). Mặc dù đề bạt và qui chế
không phải luôn luôn ;à động cơ hiệu quả nhất, ng-ời quản lý dự án rất
hiếm khi từ bỏ bất cứ công cụ tổ chức khối tháp th-ờng là tốt nhất.

5.2 Cơ cấu đội ngũ.

Trừ với những dự án rất nhỏ (số ng-ời sản xuất ít hơn 5) thì những dự
án phần mềm đ-ợc tổ chức tốt nhất là thành những đội ngũ phát triển
nhỏ. Qui mô lý t-ởng của một đội ngũ phát triển là khoảng bốn và sáu
ng-ời sản xuất. Những đội ngũ lớn hạn chế khả năng của lãnh đạo đội
đ-ợc hoạt động là ng-ời sản xuất và do đó tăng tổng phí quản lý và hạn
chế dính líu kỹ thuật của lãnh đạo đội vào dự án

Các đội ngũ đem lại cho ng-ời quản lý dự án nhiều lợi điểm, bao gồm :

- Quản lý dễ dàng và tốt hơn : Cơ cấu đội ngũ hỗ trợ việc uỷ nhiệm
thẩm quyền.

- Trao đổi thông tin và ý kiến hiệu quả hơn do làm quen đ-ợc rộng hơn
trong đội ngũ với nhiệm vụ của mỗi thành viên.

Đội ngũ giảm khả năng kỹ s- không thay thế đ-ợc khi chia xẻ kiến
thức duy nhất trong phạm vi đội khơng có ng-ời đơn độc nào trở thành
nguồn thông tin gay cấn cả.

Trong các dự án nhỏ, có sự đồng nhất mạnh hơn với dự án. ở những dự
án lớn những ng-ời sản xuất có xu h-ớng cảm thấy họ chính là một trong
số rất nhiều và đóng góp của họ cho dự án sẽ tiến hành khơng ai hay.
Nhỏ hơn, gắn bó hơn, đội ngũ có thể hình thành tận tuỵ hơn.

5.2.1 Lãnh đạo đội.

Lãnh đạo đội ngũ đ-ợc coi là kênh thơng tin chính giữa ng-ời quản lý
dự án với các thành viên đội. Điều này khơng có nghĩa là khơng có
thơng tin trực tiếp giữa ng-ời quản lý dự án với các thành viên đội. Dù
sao nếu mọi thông tin là trực tiếp thì nh- thế điều này hẳn làm cho những
mục đích chính của cơ cấu đội bị thất bại: uỷ nhiệm thẩm quyền và trách
nhiệm đ-ợc hiệu quả (coi hình 5.1).

Vai trị của lãnh đạo đội là :

- Đại diện quản lý dự án thông qua uỷ nhiệm thẩm quyền
- Đại diện đội tr-ớc ng-ời quản lý dự án

</div>
(87)<div class='page_container' data-page=87>

thuật. Cả đội ngũ dân chủ và đội ngũ kỹ s- tr-ởng đòi hỏi khả năng lãnh

đạo đội về hành chính.

H×nh 5.7.a

Tổ chức đội phát triển theo kiểu dân chủ

H×nh 5.7.b

Tổ chức đội phát triển theo kiểu k s- tr-ng

Đội
viên

Đội
tr-ởng

Đội
viên
Đội

viên

Đội
viên

Kỹ
s-Tr-ởng

Đội
viên

Đội

viên
Đội

</div>
(88)<div class='page_container' data-page=88>

õy l trỏch nhim của ng-ời quản lý dự án trong việc tuyển chọn các
đội ngũ và uỷ nhiệm những vai trò của lãnh đạo đội. Điều này có thể (và
th-ờng phải) đ-ợc tiến hành qua tham vấn các lãnh đạo đội có kinh
nghiệm và các thành viên dự án thâm niên khác. Cơ cấu tổ chức và uỷ
nhiệm những nhiệm vụ chủ chốt là một phần của kế hoạch phát triển dự
án và phải đ-ợc hoàn thành càng sớm càng tốt trong chu kỳ phát triển dự
án (bàn chi tiết về chu kỳ phát triển coi ch-ơng 4).

Các lãnh đạo đội tr-ớc hết phải đ-ợc tuyển chọn trên có sở khả năng
lãnh đạo cơ bản của họ. Nếu khả năng này không phải là cố hữu trong
tính tình của cá nhấn thì việc đào tạo ít khi là đỉ. Sai lầm chung là đề bạt
một kỹ s- tốt trở thành lanh đạo đội tồi17.

Lãnh đạo đội ngũ, tr-ớc hết và trên hết là một chức năng quản lý và
nh- vậy đòi hỏi đ-ợc đào tạo. Mọi lãnh đạo đội phải đ-ợc đào tạo chính
thức về kỹ năng quản lý cơ bản cần thiết cả cho việc quản lý đội và cho
việc đối diện với quản lý dự án. Lãnh đạo đội có khả năng đ-ợc đào tạo
tốt trở thành việc triển khai thắng lợi ng-ời quản lý dự án.

5.2.2 Các đội dân chủ.

Nghiêm túc mà nói, các đội dân chủ khơng có lãnh đạo, chức năng của

vai trò lành đạo đội là điều phối viên nhiều hơn. ở các đội dân chủ, các
lãnh đạo đội giành một phần nhỏ thời gian của họ cho :

- việc đại diện đội trong thông tin với quản lý dự án và các đội khác.
- Phối hợp hoạt động trong đội

- Sử lý các nhiệm vụ hành chínhkhác nh- báo cáo, lập trình và giám sát
hoạt động.

Mọi quyết định kỹ thuật trong một đội dân chủ đ-ợc cả đội thực hiện
lãnh đạo đội triệu tập các cuộc họp trong đó những vấn đề gay cấn và cấp
thiết đ-ợc đ-a ra thảo luận. Nh-ng mọi thành viên đội tham gia trong quá
trình ra quyết định và chịu trách nhiệm về đầu ra.

Các đội dân chủ th-ờng thích ứng cho các nhóm nhà sản xuất thâm
niên có kinh nghiệm. Theo đó vai trị của lãnh đạo đội giảm tổng phí
hành chính bằng cách giao nhiệm vụ hành chính của đội cho một thành
viên duy nhất. Cơ cấu đội dân chủ đặc biệt khơng thích hợp cho các
nhóm hỗn hợp, hay nhóm bao gồm chủ yếu những ng-ời sản xuất thanh
niên. Trong cả hai tr-ờng hợp đó, vai trị lãnh đạo rõ ràng là cần thiết.

5.2.3 Các đội kỹ s- tr-ởng.

Đọi kỹ s- tr-ởng (cũng gọi là đội các tr-ờng lập trình) tiến hành lãnh
đạo đội phát triển. Vai trị của lãnh đạo đội vừa là điều phối viên
(nh-trong tr-ờng hợp đội dân chủ) vừa là h-ớng dẫn (nh-trong những dự án phức
tạp, lãnh đạo đội có thể đ-ợc yêu cầu giành đến 50% thời gian vào những
hoạt động kỹ thuật và hành chính.

</div>
(89)<div class='page_container' data-page=89>

Hoạt động chính của lãnh đạo đội kỹ s- tr-ởng là:

- Giao nhiệm vụ và trách nhiệm cho các thành viên đội
-Giám định cơng việc của các thành viên đội.

- Góp ý và h-ớng dẫn các thành viên đội.

- Hoạt động hành chính và phối hợp (t-ơng tự nh- lãnh đạođội dân
chủ). Các đội kỹ s- tr-ờng là thích ứng cho đội hỗn hợp và đội chủ yếu
có những ng-ời sản xuất than niên hay khơng có kinh nghiệm. chức năng
của lãnh đạo đội với t- cách ng-ời quản lý hàng đầu và do đó phải đ-ợc
đàp tạo thích hợp về kỹ thuật quản lý cơ bản. Các đội kỹ s- truởng cũng
có thể thành công trong những đội ng-ời sản xuất đàn anh và có kinh
nghiệm nh-ng vai trị th-ờng khơng cần thiết khi cơ cấu này đ-ợc vận
dụng cho một đội các kỹ s- có kinh nghiệm thì việc ng-ời lãnh đạo đội
có những kỹ năng quản lý cơ bản lại quan trọng gấp hai nếu khơng ffụng
chạm có thể phát triển giữa thành viên đội và ng-ời lãnh đạo đội. Về mặt
này, lãnh đạo đội ngũ ng-ịi chun mơn có kinh nghiệm lại khó hơn là
lãnh đạo đội ngũ ng-ời mời vào nghề.

5.2.4 Các đội chuyên gia.

Đội ngũ chuyên gia là những đội ngũ nhỏ đ-ơịc thành lập để giải quyết
những vấn đề đặc thù trong một dự án. Một đội ngũ chuyên gia có thể
đ-ợc thành lập trong quá trình phát triển dự án khi có vấn đề phức tạp
nảy sinh và sau đó đội đội có thể đ-ợc giải tán khi vấn đề đ-ợc
giảiquyết. Trong một số tr-ờng hợp, các đội chuyên gia có thể hỗ trợ dự
án suốt chu kỳ phát triển. Mục tiêu của đội chuyên gia là tập trung giám
định trong một lĩnh vực riêng của dự án.

Lấy thí dụ, ta hãy xét một hệ thống thủ quĩ ngân hàng tự động có hai
hệ thơng phụ chủ yếu : conputer trung tâm của ngân hàng và thủ quỹ tự

động từ xa. Kế hoạch phát triển cho hai hệ thống phụ đó đã giao việc
phát triển của mỗi hệ phụ cho một đội riêng nh-ng qui mơ của dự án
khơng thể đảm bảo có một đội hợp nhất riêng. Cả hai đội đã sử dụng bộ
mô phỏng thực hiện thử nghiệm và hợp nhất hệ thống phụ ban đầu. Dù
sao khi hai hệ thống phụ đ-ợc hợp nhất với nhau, thông tin giữa hai hệ
thống không có.

Trong những tình huống nh- thế bao giờ cũng có nguy cơ là một trong
hai đội tìm kiếm vấn đề trong công việc của đội kia. Nay dù hai đội hợp
tác với nhau tốt, khác biệt trong thực hiện (hay trong thiết kế) có thể làm
cho vấn đề khó đ-ợc giải quyết. Và vì kịch trình bắt đầu tr-ợt. điều này
trở thành mối quan tâm chủ yếu cho ng-ời quản lý dự án.

</div>
(90)<div class='page_container' data-page=90>

thể giải tán vệ moọt số mặt, các đội thử nghiệm độc lập và đội bảo hiểm
chất l-ợng có thể đ-ợc coi là đội chuyên gia ( coi ch-ơng 7 bàn về các
chuyên đề đó). Các đội thử nghiệm độc lập lúc đầu hoạt động trong các
giai đoạn hợp nhất và thử nghiệm của chu kỳ phát triển. Đội bảo hiểm
chất l-ợng là một thí dụ về đội chuyên gia hoạt động xuyên suốt chu kỳ
phát triển của dự án.

Đội chuyên gia th-ờng có những kỹ s- có kinh nghiệm cao trong
những tr-ờng hợp thế điều chắc chắn nhất là đội đ-ợc hình tìanh
nh-đội dân chủ. Trong thí dụ tr-ớc, nh-đội có thể là nh-đội dân chủ hay có thể do
một chuyên gia thơng tin đàn anh lãnh đạo.

5.3 c¸c Kü tht b¸o cáo cơ bản.

Vi ng-i qun lý d ỏn, iu ch yếu là đ-ợc th-ờng xun thơng báo
về điều kiện (tình hình) thực của dự án. điều này đ-ợc thực hiện khi đảm
bảo đ-ợc luồng thơn tin chính xác đều đặn của các đội phát triển. Nhiều

ph-ơng pháp thu thập thông tin khơng khách quan và dựa vào tính chính
xác của các báo cáo do chính những ng-ời sản xuất dự án cung cấp. Các
báo cáo đó gồm :

- Báo cáo viết định kỳ về tình hình
- Báo cáo miệng.

- Häp về tình hình

- Chứng minh sản phẩm (denoi)

cỏc chng minh sản phẩm đặc biệt chủ quan vì chỉ chứng minh cái gì
mà ng-ời sản xuất mong muốn đ-ợc phơ ra. Ng-ời quản lý dự án cần
thông tin khách quan. thông tin nhủ thế th-ờng có thể đ-ợc thu thập từ
những báo cáo của các nhóm hỗ trợ nh- :

- báo cáo bảo hiểm chất l-ợng.
- Báo cáo thử nghiệm độc lập

Mặc dù báo cáo và họp đúng là những nguồn thơng tin có ích, khơng
có gì có thể thay thế tiếp xúc trực tiếp giữa ng-ời quản lý dự án và nhân
lực phát triển. Nh-ng cuộc nói chuyên th-ờng xuyên khơng chính thức
với những ng-ời sản xuất là những nguồn thông tin tuyệt hảo đặc biệt khi
đ-ợc tiến hành trong bầu khơng khí khơng chính thức (và khơng phải
trong văn phòng của ng-ời quản lý dự án).

Ng-ời quản lý dự án phải duy trì cảnh giác th-ờng xuyên với sia lầm
th-ờng đ-ợc gọi là '' hội chứng 90/50 '' khẳng định là ''phải mất 50%thời
gian để hồn thành 90% cơng việc và 50% thời gian phụ thêm để hoàn
thành số 10% cơng việc cịn lại'' . Điều này có nghĩa là những ng-ời sản

xuất dự án sẽ bắt đầu khoe khoang sớm là họ đã ''hầu nh- xong'' nhiệm
vụ của họ, bất hạnh là có sự khác biệt lớn giữa ''hầu nh- xong'' với
''xong''.

</div>
(91)<div class='page_container' data-page=91>

triển có xu h-ớng (sai lầm) kết hợp công việc với kết quả. Do đấy, những
ng-ời quản lý có thể có đ-ợc nhiều thơng tin hơn ở những ng-ời sản xuất
khi hỏi họ dự tính bao lâu nữa thì xong cơng việc chứ khơng hỏi họ đã
hồn thành đ-ợc bao nhiêu cơng việc.

5.3.1 B¸o cáo tình hình

Mi thnh viờn ca i ng phỏt trin khơng trừ ai đều đ-ợc u cầu
làm báo cáo tình hình, các báo cáo phải đ-ợc đệ trình định kỳ, th-ờng là
hàng tuần hay hai tuần một lần và phải có ít ra ba phần sau ( coi hình
5.8).

1 Hoạt động trong thời kỳ báo cáo.

Mỗi phần phụ trông... phần này, mô tả hoạt động chủ yếu trong thời kỳ
báo cao mô tả mỗi hoạt động phải kéo dài hai đến ba dòng. Hoạt động
phải h-ớng về danh mục nhiệm vụ dự án hay cơ cấu phân tích cơng việc
(wbs) ( coi ch-ơng 9 vệ mô tả wBS).

2. Hoạt động qui hoạch cho thời kỳ báo cáo tới.

Mỗi phần phụ, trong phần này, mô tả hoạt động chủ yếu dự kiến cho
thời kỳ báo cáo tới. Mô tả mỗi hoạt động phải một đến hai dòng.

3. Vấn đề.

Mỗi phần phụ, trong phần này, mô tả vấn đề chủ yếu hoặc xảy ra
trong thời kỳ báo cáo hoặc đã đ-ợc báo cáo , tr-ớc đây và vẫn ch-a đ-ợc
giải quyết. Điều này có nghĩa là vấn đề sẽ đ-ợc tiếp tục báo cáo cho đến
khi đ-ợc giải quyết. Nói tiêng, phần này phải giải thích tại sao phần 1
này của báo cáo không t-ơng ứng với phần 2 của báo cáo tr-ớc.

Mọi báo cáo đề cũng phải có :
1. Ngày báo cáo

2. Thời kỳ báo cáo (thí dụ 3-7 đến 10-7-1992)

3. Tên báo cáo ( thí dụ báo cáo tình hình đội thơng tin).
4. Tên ng-ời đệ trình báo cáo.

Việc chuẩn bị báo cáo tình hình định kỳ phải mất khoảng 20 phút
nh-ng không đ-ợc quá 30 phút. Những ng-ời sản xuất phải đệ trình báo
cáo trình hình của mình cho lãnh đạo đội mình, sau đó lánh đạo đội phối
hợp các báo cáo của đội thành một báo cáo tình hình duy nhất trong khi
vẫn giữ cũng cơ cấu báo cáo đó. Hoạt động này chiếm khoảng 30 phút
của ng-ời lãnh đạo đội nh-ng không đ-ợc quá 45 phút (điều này làm
đ-ợc dễ dàng khi báo cáo đ-ợc chuẩn bị và đệ trình bằng th- điện tử)

Mỗi lãnh đạo đội đệ trình báo cáo tình hình của đội cho ng-ời quản lý
dự án.Các báo lẻ về tình hình khơng cần đệ trình những báo cáo đó đ-ợc
d-a vồ hồ sơ và chỉ đệ trình cho ng-ời quản lý dự án khi có u cầu.

</div>
(92)<div class='page_container' data-page=92>

Các báo cáo tình hình dự án khơng cần thiết phải đệ trình cùng tấn độ
nh- báo cáo tình hình dự án nội bộ. Các báo cáo dự án có thể đ-ợc đệ
trình hai tuần hay mỗi tháng một lần.18

H×nh 5.8 thÝ dơ vỊ báo cáo tình hình hàng tuần.

ca Fohn Doe lónh o đội
Gửi Fnank Smith, quản lý dự án.
Ngày 15-6-1993

§éi giao diƯn ng-ời dùng : báo cáo tình hình hàng tuần
Thời kỳ 5-12 th¸ng 6-1993

1. Hoạt động trong thời kỳ báo cáo

1.1 Thiết kế màn hình giúp ng-ời dùng (hoạt động 3.12.6) đ-ợc hoàn
thành đúng lịch . Đặc điểm thiết kế đã đ-ợc đệ trình kiểm tra cấu hình.

1.2 Lập mã khẩu ngữ chỉ huy bằng mơ đun (nhóm hoạt động 5.12)
tiếp tục và th-ờng chậm hơn lịch khoảng 1 tuần

2 Hoạt động dự kiến cho tuần tới

2.1 Lập mã khẩu ngữ chỉ huy bằng mơ đun (nhóm hoạt động 5.12) sẽ
đ-ợc hoàn thành và các thử nghiệm đơn vị sẽ bắt đầu.

2.2 Hai thành viên của đội (Rd và Foan) sẽ dự lớp học 2 ngày về giao
diện của ng-ời lập trình cho bộ ch-ơng trình giao diện mới của ng-ời
dùng. Đây là một hoạt động không theo lịch đã đ-ợc phê chuẩn trong
cuộc họp dự án mới đây. Điều này khơng làm chậm lịch trình, do hồn
thành sớm khẩu ngữ chỉ huy bằng mô đun (coi phần 1.2 trên)

3 Vấn đề

3.1 Bộ ch-ơng trình giao diện cho ng-ời dùng chúng tơi đã qui hoạch
lúc đầu, xét thấy khơng thích hợp cho dự án. Hai thành viên sẽ nghiên
cứu bộ ch-ơng trình mới đề nghị (coi phần 2.2 trên) . Nếu bộ ch-ơng
trình mới lại xét khơng thích hợp, điều này sẽ ảnh h-ơỏng nghiêm trọng
lịch trình phát triển của chúng ta.

3.2 Một thành viên của chúng tôi (pack Brown) đã sử dụng điểm cuối
cũ VT100 chứ không phải trạm cộng tác trong 2 tuần qua, do thiếu cấp
thời trạm công tác... Đây là lý do vì sao nhiệm vụ 5.12 của pack Brown
đã khơng hồn thành tuần này theo lịch.

5.3.2 Các cuộc họp tình hình dự án

Cỏc cuc hp tỡnh hình dự án phải đ-ợc tiến hành định kỳ, thơng
th-ờng một tuần một lần. Thời gian tốt cho cuộc họp tình hình hoặc là
vào cuối ngày cuối tuần hay đầu ngày đầu tuần. Các cuộc họp tình hình
cũng đóng góp vào khơng khí trật tự và kiểm tra trong phạm vi dự án và
phải đ-ợc tiến hành đều dặn vào giờ giấc nhất định. Những thành viên

18Ch-ơng 9 bàn thêm các báo cáo tình hình đ-ợc sử dụng thế nào để cập nhật lịch trình phát triển

</div>
(93)<div class='page_container' data-page=93>

khơng thể tham dự cuộc họp tình hình dự án có thể với sự đồng ý của
ng-ời quản lý dự án, uỷ nhiệm thành viên khác của đội mình tham dự.

Ng-ời quản lý dự án chuẩn bị cho cuộc họp tình hình bằng cách duyệt
lại các báo cáo tình hình của các thành viên chủ chốt của dự án đệ trình
(đặc biệt xoáy vào phần vấn đề). Do đấy báo cáo tình hình phải đ-ợc đệ
trình ít ra hai đến ba giờ tr-ớc cuộc họp tình hình.

Các thành viên chủ chốt của dự án tham dự các cuộc họp tình hình dự

án. Cuộc họp bắt đầu bằng báo cáo hoạt động của dự án và những vấn đề
tổng quát do ng-ời quản lý dự án trình bày. Sau đó mỗi thành viên đ-ợc
giành 5 đến 10 phút báo cáo về hoạt đọng của đội mình hay lĩnh vực
trách nhiệm của mình. Việc thảo luận vấn đề không giới hạn ở ng-ời báo
cáo vấn đề và ng-ời quản lý dự án. Mọi vấn đề có thể đ-ợc mọi thành
viên nêu ra với hỗ trợ có thể có giữa các lãnh đạo đội theo thế làm cho
kinh nghiệm của họ có đ-ợc xuyên suốt dự án. Vai trò của ng-ời quản lý
dự án không phải là cung cấp giải pháp cho các vấn đề mà là h-ớng dẫn
các thành viên đội h-ớng về giải pháp.

Giải pháp phải cố giắng có đ-ợc trong cuộc họp tình hình. Bất cứ vấn
đề nào khơng đ-ợc giải quyết trong phạm vi năm phút phải đ-ợc hoãn lại
để các bên liên quan thảo luận sau cuộc họp tình hình. Biên bản của các
cuộc họp tình hình dự án phải đ-ợc l-u hồ sơ những bản cáp nguyên văn
không có yêu cầu mặc dù những vấn đề sau phải cú trong biờn bn;

1 ngày họp
2. tên cuộc họp

3. Có mặt (danh sách ng-ời dự)

4. vắng mặt (danh sách ng-ời đ-ợc mời vắng mặt

5. Cỏc mc hnh ng (tờn , hành động, ngày hoàn thành)
6.quyết định chủ yếu các vấn đề thảo luận.

Biên bản họp tình hình dự án phải đ-ợc đánh máy và phân phát sớm
không chậm quá cuối ngày đó. Điều này là đặc biệt quan trọng khi có
những mục hành động phải hồn thành trong cùng ngày. Khi dự án khá
lớn để cần có th- ký thì biên bản sẽ đ-ợc lập và đánh máy bởi th- ký.

Trong những dự án nhỏ hơn, ng-ời quản lý dự án có thể quay vịng nhiệm
vụ này mỗi tuần giữa cỏc thnh viờn.

5.4 Những Đ-ờng lối chung trong quản lý các kỹ
s- phần mềm.

</div>
(94)<div class='page_container' data-page=94>

Qun lý theo tho thuận tốt hơn quản lý theo chỉ thị. Bao giờ cũng tốt
nhất là có đ-ợc kỹ s- chấp nhận nhiệm vụ đ-ợc giao. Điều này tạo ra cái
vẫn th-ờng đ-ợc coi là sở hữu nhiệm vụ và làm tăng đáng kể động cơ của
ký s-. Nhằm thực hiện điều này, các kỹ s- phải đ-ợc giao nhiệm mà họ
muốn bất kể khi nào có thể đ-ợc. Nếu điều này khơng thể, ng-ời quản lý
dự án phải mô tả trung thực những ph-ơng án có đ-ợc và giải thích cho
kỹ s- vì sao những nhiệm vụ đặc thù lại khơng có.

Trách nhiệm luôn phải đi liền vai kề vai, với thẩm quyền. Mọi thành
viên điều hành dự án bất kể là thanh niên, phải đ-ợc giao thẩm quyền
hành động trong phạm vi trách nhiệm của họ. Các kỹ s- bảo hiểm chất
l-ợng phải có đ-ợc thẩm quyền phê duyệt hay bác bỏ những thành phần
sản phẩm và các kỹ s- phát triển phải có đ-ợc thẩm quyền có những
quyết định trong thiết kế liên quan đến thành phần mà họ đang phát triển.
Dù sao, khơng có thẩm quyền nào là tuyệt đối, và nhân sự cấp cao hơn
trong dự án phải th-ờng xuyên xét duyệt lại các quyết định đó và nhảy
vào khi họ cảm thấy có sai lẩm xảy ra.

Qui tắc chung là chỉ sai lầm rõ ràng phải đ-ợc hiệu chỉnh. Điều này
dẫn đến một trong những qui tắc cơ bản của phát triển dự án ; cách tốt
hơn để làm đ-ợc điều gì khơng phải là cơ sở đủ để thay đổi . Nói cách
khác nếu ng-ới quản lý cảm thấy là anh hay chị đã có thể có quyết định
tốt hơn, nh-ng quyết định hiện nay chấp nhận đ-ợc thì quyết định phải
khơng đ-ợc thay đổi.

Quyền sở hữu khơng chỉ liên quan đến nhiệm vụ mà cịn đến lịch và
nguồn đi đôi với nhiệm vụ. Mọi lịch trình phải đ-ợc sự thoả thuận của
ng-ời thực hiện trên thực tế các dự tốn lịch trình phải đ-ợc chuẩn bị
cùng với những ng-ời thực hiện. Điều này đảm bảo cam kết của ng-ời
thực hiện hay ng-ời sản xuất tham gia vào lịch trình.

Cuối cùng, động cơ là yếu tố duy nhất quan trọng hơn cả trong việc
quản lý thành cơng của đội ngũ phát triển. Động cơ có thể -c khuyn
khớch bng nhiu cỏch.

- L-ơng và th-ởng
- Đề bạt

- Điều kiện và môi tr-ờng làm việc
-Quyền lợi trong công việc đ-ợc giao
- Qúi trọng

- Tôn giá trị

- Thỳc y ý thức hồn thành

</div>
(95)<div class='page_container' data-page=95>

Tơn giá trị cũng là một nguồn động cơ cao. Với ng-ời quản lý dự án
thì việc gọi ng-ời nào đến văn phịng của mình và nói ''cám ơn anh đã
làm một cơng việc vĩ đại'' có thể tạo nên kỳ tích. Những cách khác để tơn
gía trị là gửi th- đánh giá có bản sao gửi quản lý cấp cao hơn và cho ban
nhân sự hoặc cho nhân viên đã có cố gắng đặc biệt đ-ợc đi nghỉ cuối
tuần. Mọi điều đó sẽ tăng thêm động cơ, không chỉ cho cá nhân nhân
viên đ-ợc cám ơn mà còn cho những ng-ời khác xuyên suốt dự án.

5.5 Tãm t¾t.

Quản lý các kỹ s- phần mềm khó hơn quản lý kỹ s- ở hầu hết các lĩnh
vực công nghệ khác. Các kỹ s- phần mềm khá đa dạng về mức độ hiệu
suất. Trong một dự án trung bình, khơng phải khơng phổ biến là tỉ lệ
hiệu suất 1.5. Một trong những mục tiêu của công nghệ phần mềm thời
hiện đại đã là giảm phạm vi hiệu suất đó trong các nhà sản xuất phần
mềm thơng qua những ph-ơng pháp phát triển phần mềm có hệ thống và
có tổ chức hơn.

Có nhiều cách tổ chức dự án phần mềm. Cơ cấu tổ chức dự án thích
hợp nhất tuỳ thuộc ở loại dự án đ-ợc phát triển. Những dự án lớn và phức
tạp đòi hỏi cơ cấu tổ chức lớn. Bất kể qui mô dự án, các dự án phần mềm
phải đ-ợc tổ chức thành những đội phát triển nhỏ. Về mặt lý tuởng, một
đội phần mềm sẽ có bốn đến sáu nhà sản xuất và sẽ do lãnh đạo đội phụ
trách.

Có ba loại đội phần mềm :

- Những đội dân chủ, do lãnh đạo đội lãnh đạo về mặt hành chính
những quyết định kỹ thuật do mọi thành viên đội đề ra

- Các đội ngũ kỹ tr-ởng (hay đội ngũ các lập trình tr-ởng) do kỹ
s-đàn anh có kinh nghiệm lãnh đạo và trách nhiệm là lãnh đạo cả về mặt
hành chính và kỹ thuật.

- Các đội chuyên gia đ-ợc lập để giải quyết các vấn đề đặc biệt trong
phạm vi dự án. Các đội này có thể đ-ợc giải thể khi vấn đề dặc biệt đ-ợc
giải quyết

Với ng-ời quản lý dự án, điều căn bản là đ-ợc thơng báo. Th-ờng
xun về tình trạng thực của dự án. Có nhiều ph-ơng pháp thu l-ợm
thơng tin phần lớn dựa trực tiếp vào việc cung cấp thông tin của ng-ời
sản xuất. Dù sao, những cuộc trao đổi th-ờng xun khơng chính thức
với những ng-ời sản xuất cũng là những nguồn thông tin tuyệt vời, đặc
biệt khi đ-ợc tiến hành trong bầu khơng khí khơng chính thức (và khơng
phải trong văn phịng của ng-ời quản lý dự ỏn).

</div>
(96)<div class='page_container' data-page=96>

Bài tập

1. Bạn là ng-ời quản lý cho một dự án thông tin tập hợp mọi cửa hàng
vào một dây chuyền lớn các cửa hàng. Mỗi cửa hàng thông th-ờng có
máy vi tính riêng mỗi mạng với đang ký kiểm tra. Quản lý dây chuyền
muốn thiết lập một máy vi tính trung tâm ở văn phòng chính và nối mạng
mọi máy vi tính của các cửa hàng vào vi tính trung tâm thông qua mạng
khu vực rộng lớn. Máy vi tính trung tâm sẽ nhận đ-ợc thông tin, thời gian
thực về giao dịch ở các cửa hàngt và muốn cập nhật cơ sở dữ liệu kiểm kê
trung t©m.

Bạn hãy chuẩn bị biểu đồ tổ chức khối tháp cho dự án thơng tin của
cửa hàng. Giải thích cơ cấu mà bạn đã chọn và vì sao cơ cấu đó lại thích
hợp hơn các cơ cấu tổ chức khác có thể có.

2. Lập kế hoạch luồng thơng tin trong phạm vi tổ chức bạn đã đề nghị
ở bài tập1. Cần những báo cáo nào và phải đ-ợc đệ trình th-ờng xun
thế nào? có những cuộc họp tình hình nào là cần và phải đ-ợc triệu tập
th-ờng xuyên thế nào? Ai dự các cuộc họp đó?

Gợi ý tần độ biến động về báo cáo tình hình và các cuộc họp nắm tình
hình, căn cứ theo các giai đoạn phát triển khác nhau.

3. Chuẩn bị biểu đồ tổ chức mà trận cho dự án ở bài tập 1 . So sánh nó
với cơ cấu khối tháp bạn đề nghị ở bài tập 1 : cơ cấu nào là thích hợp hơn
cho dự án ? có những điểm lợi và bất lợi nào của mỗi cơ cấu tổ chức cho
dự án này

4. Bạn hãy đề nghi cơ cấu của các đội phát triển và hỗ trợ cho dự án
mô tả ở bài tập 1. Giải thích cơ cấu mà bạn đã chọn. Bạn có dự kiến nhu
cầu cho các đội chuyên gia trong sự phát triển của dự án ?

5. Dù ¸n của lớp học phân lớp thành 3 hay 4 nhóm sinh viên . giao các
bài tập 1,2 và 4 cho mỗi nhóm cho mỗi nhóm trình bày giải pháp của
mình tr-ớc lớp.

</div>
(97)<div class='page_container' data-page=97>

Ch-ơng sáu

Chia tr cỏc d án lớn thế nào :

phân chia và chiếm lĩnh

Nhu cÇu lớn không có nghĩa là khó

Nhiu i t-ng phc tp có thể đ-ợc xem là một bộ vơ vàn đối t-ợng
dơn giản hơn. Một thí dụ thích hợp là một hố chất hình thành từ nhiều
phân tử khác nhau mỗi phân tử đ-ợc tạo thành khi phối hợp nhiều nguyên
tử khác nhau . Các nguyên tử mặc dẫn bản thân phân chia đ-ợc có thể
đ-ợc coi là phần tử nhỏ nhất của một hoá chất.

Theo cách t-ơng tự dự án phức tạp có thể đ-ợc phân thành những
thành phần đơn giản hơn. Trong khi tồn bộ dự án có thể khó quản lý thì
mỗi thành phần sẽ dễ sử lý hơn những dự án phần mềm có thể đ-ợc phân

thành những thành phần nhỏ hơn nhằm dự tính tốt hơn về khối l-ợng
công việc hoặc nhằmđiều khiển các hoạt động ca cỏc i phỏt trin khỏc
nhau.

Việc phân giải dự án phần mềm là một trong những nhiệm vụ đầu tiên
của ng-ời quản lý dự án phần mềm . Dù sao ph-ơng pháp phân giải có
thể khác nhau, tuỳ theo mục tiêu thực sự của ng-ời quản lý dự án.Việc
phân tích dự án theo chức năng có thể không nh- là phân tích thiết kế.
Phân tích chức năng chia dự án thành những thành phần cơ bản của nó
theo cách nhìn cđa ng-êi dïng trong khi ph©n tÝch thiÕt kÕ chia dự án
thành thành phần hay mô đun lập trình cơ b¶n.

Ch-ơng này bàn đến những ph-ơng pháp quản lý hiệu quả những dự
án phần mềm phức tạp và giới thiệu những ph-ơng pháp phân tích các dự
án thành những thành phần quản lý đ-ợc. Các loại phân giải dự án cũng
đ-ợc bàn đến và mục tiêu của mỗi loại phân giải đ-ợc giải thích.

6.1 tinh chÕ tõng b-íc mét

Theo trực giác có vẻ khơng hợp lý khu tìm cách minh định mọi thành
phần dự án trong một b-ớc duy nhất. Rõ ràng một qui trình lặp có thể dần
dần cung cấp nhiều chi tiết hơn, hẳn là dể sử dụng hơn. Những ph-ơng
pháp lặp thuộc loại này đ-ợc gọi là tinh chế từng b-ớc một vì sự phân
giải đ-ợc tiếp tục tinh chế ở mỗi b-ớc kế tục

Hình 6.1 trình bày ninh hoạ tổng quát về tinh chế từng b-ớc một . Hệ
thống ban đầu đ-ợc phân thành ba thành phần cấp cao và rồi mỗi thành
phần cấp cao lại đ-ợc phân tiếp thành các thành phần cấp thấp hơn, và cứ
thế cho đến khi đạt đ-ợc cấp thành phần thp nht.

</div>
(98)<div class='page_container' data-page=98>

tả toàn bộ hệ thông nh-ng ở mức chi tiết khác trong hình 6.1 các thành
phần 1,2 và 3 tạo nên hệ thống hoàn chỉnh. Để đ-ợc chi tiết hơn, chúng ta
lấy b-ớc phân giải tiếp và thấy các thành phần 1.1,1.2,2.1,2.2,2.3,3.1 và
3.1 biểu thị tòan bộ hệ thống.

Hình 6.1

Phân giải phần mềm bằng tinh lọc tõng b-íc

Sơ đồ tinh chế từng b-ớc một t-ơng tự nh- biểu đồ một hệ thống tôn ti
trật tự. Dù sao điều quan trọng là phải hiểu rằng tinh chế từng b-ớc là cơ
bản khác nhau vì các khối cấu thành của biểu đồ khác nhau. Sơ đồ hệ
thống tôn ti mô tả mối quan hệ tôn ti giữa các thành phần khiến cho mỗi
thành phần trong sơ đồ t-ơng ứng thực sự với một thành phần thực trong
hệ thống. Dù sao sơ đồ tinh lọc từng b-ớc, thành phần cấp cao hơn chỉ là
tên đặt theo qui -ớc cho một nhóm các thành phần thực xuất hiện ở ngay
d-ới nó.

Trong h.6.2(a) phần mềm của hệ thống truy nhập đ-ợc có kiểm tra có
năm thành phần , phần mềm cấp thấp, nhận biết truy nhập phi pháp và
kích hoạt báo động. Mỗi một trong năm mơ đun đó có thể t-ơng ứng với
một mô đun phần mềm thực tại.19 Hai thành phần cấp cao kiểm tra truy

nhập và hệ thống báo động không tồn tại là mô đun phàn mềm thực tại và
chỉ xuất hiện nh- là tên đặt cho hai nhóm thành phần cấp thấp hơn.

Hình 6.2 (b) mơ tả cũng phần mềm của hệ thống truy nhập đ-ợc có
kiểm tra nh- ng lần này đ-ợc biểu thị nh- biểu đồ tôn ti . ở đây
mỗi-thành phần trong biểu đồ biểu thị một mỗi-thành phần phần mềm thực.Thành
phần khung chính điều hành của hệ thống gọi ra ba thành phần khác nhận

biết khách thăm , kiểm tra khoá cửa và kích hoạt báo động thành phần
nhận biết khách.

19 Tất nhiên , đây là sự đơn giản hoá hệ thống thực.Trên thực tế năm thành phần cấp thấp đó cú th

đ-ợc phân giải tiếp thành những- thành phần cấp thấp hơn

Hợp phần 3
Hệ thống

Hợp phần 1 Hợp phần 2

1.1 1.2 2.1 2.2 2.3 3.1 3.2

</div>
(99)<div class='page_container' data-page=99>

Hình 6.2.a

Phân giảI thành phần mức trên ra các thành phần mức d-ới

Hình 6.2.b

S cu trỳc tụn ti trt t

thăm gọi ra hai hành phần : Nhận biết truy nhập nh-ơng pháp và quản lý
hồ sơ truy nhập.

6.1.1 Phân giải chức năng

Vic phõn gii theo chc nng mt d ỏn phn mềm là sự phân chia hệ
thống thành những thành phần theo hoạt động của nó nh- ng-ời dùng
nhận định. Việc phân giải theo chức năng là một bộ phận của pha yêu cầu

của dự án. Mục tiêu của pha này là xác định mọi đặc điểm của hệ thống
theo cách nhìn của ng-ời dùng.

Ta hãy thử xem xét một hệ thống thủ qũi ngân hàng tự động khả năng
thông tin trực tuyến giữa các thủ quỹ tự động xa xôi và máy vi tính trung
tâm của ngân hàng nhằm cung cấp thông tin tài khoản đã đ-ợc cập nhật
là đặc điểm chức năng của hệ thống. điều này thông th-ờng s -c xỏc

Phần mềm hệ thống
truy cập đ-ợc đ/kh.

Kớch hot
bỏo động
Nhận ra truy cập

bất hợp pháp
Hệ thống
báo động

Quản lý tệp truy
cp
Khng ch ng

hồ cửa
Nhận ra

ng-ời thăm

Khống chế
Truy cập

Vòng lặp chính
thừa hành hệ thống.

Bỏo ng

Quản lý tệp truy
cập
Nhận ra việc

truy cập bất hợp pháp

Nhận ra
khách thăm

</div>
(100)<div class='page_container' data-page=100>

nh trong pha yêu cầu của chu kỳ phát triển. Dù sao, ph-ơng pháp
chuyển giao giữa thủ quỹ tự động và máy vi tính trung tâm khơng phải là
đặc điểm chức năng của hệ thống vì đây là bài trong thiết kế và thực hiện
của hệ thống chứ không hiển nhiên cho ng-ời dùng. Ph-ơng pháp
chuyển giáo kể cả nghi thức liên lạc th-ờng sẽ đ-ợc xác định trong giai
đoạn thiết kế của sự phát triển của hệ thống.20

H×nh 6.3

Hệ thống thủ quỹ tự động -- biểu đồ phân giải chức năng

Dù sao, ph-ơng pháp chuyển giao giữa thủ quỹ tự động và máy vi tính
trung tâm khơng phải là đặc điểm chức năng của hệ thống vì đây là bên
trong thiết kế và thực hiện của hệ thống chứ không hiển nhiên cho ng-ời
dùng. Ph-ơng pháp chuyển giao kể cả nghi thức liên lạc th-ờng sẽ đ-ợc

xác định trong giai đoạn thiết kế của sự phát triển của hệ thống.

ở các quyết định thực hiện có thể từng lúc đ-ợc đ-a ra trong giai đoạn
yêu cầu và đ-ợc coi là yêu cầu thực hiện. Điều này có thể bao gồm đặc
điểm nh- là loại máy tính đối t-ợng, ngơn ngữ lập trình đ-ợc sử dụng
hay ph-ơng pháp truyền thông đ-ợc dùng tốt hơn hết là nên hoãn, các
quyết định thực hiện càng chậm càng hay cho đến pha thiết kế .

Hình 6.3 nêu một thí dụ phân tích theo chức năng của một hệ thống
thủ quĩ ngân hàng tự động thành những thành phần chức năng ở mức thấp
hơn.

Trong hình 6.3 chúng ta đã xác định là sẽ có một cơ sở dữ liệu khách
hàng có thể đ-ợc xem là quyết định thiết kế. Điều này là khơng tránh
khỏi. Phân tích chức năng hiếm khi hoàn toàn tránh đ-ợc mọi nhận định
thiết kế. Nh- chúng ta đã biết phân giải chức năng th-ờng khi là khởi
điểm cho thiết kế ban đầu của h thng.

6.1.2

Phân giải thiết kế.

Cỏc quyt nh thc hin có thể đơi khi đ-ợc đ-a ra trong giai đoạn yêu cầu và đ-ợc coi là
yêu cầu thực hiện. Điều này có thể bao gồm những đặc điểm nh- là loại máy vi tính đối
t-ợng, ngơn ngữ lập trình đ-ợc dùng hay ph-ơng pháp thông tin sử dụng. Th-ờng tốt hơn
nên chậm quyết định thực hiện đến giai đoạn thiết kế bất cứ lúc nào có thể đ-ợc.

Hệ thống thủ qu
ngõn hng t ng.

Dịch vụ
ng-ời vận

hành
Bộ sinh

báo cáo

Dịch vụ máy tính
trung tâm

Chức năng giao
diện máy thủ quĩ
Cập nhật và hỏi

máy tính trung
tâm
Dịch vụ

ng-i dựng
Dch v
th qu t ng

</div>
(101)<div class='page_container' data-page=101>

Phân giải thiết kế của một hệ thống phần mềm là phân chia hệ thống
thành những thành phần cấp thấp khớp với thành phần phần mềm thực sự
của hệ thống. Trong phân giải thiết kế hoàn toàn của một hệ thống phần
mềm, các thành phần thấp nhất t-ơng ứng với các mô đun lập trình
(thông th-ờng là các thủ tục, ch-ơng trình con hay chức năng ch-ơng
trình)

ỳng nh- pha yờu cầu đi tr-ớc giai đoạn thiết kế việc phân giải chức
năng của một hệ thống phần mềm thông th-ờng đi tr-ớc việc phân giải
thiết kế. Phân giải chức năng th-ờng cung cấp nhiều thông tin cần thiết
cho việc phân chia tiếp hệ thống đó thành những thành phần thực hiện.
Trên thực tế, phân giải chức năng th-ờng là nơi tốt để khởi sự thiết kế
một hệ thống phần mềm vì thành phần chức năng chủ yếu của một hệ
thống th-ờng t-ơng ứng với phân chia ban đầu hệ thống đó thành những
hệ thống con hay thành phần mức cao.

Hai trong những chức năng chính của một hệ thống chủ quỹ ngân hàng
tự động có thể đ-ợc coi là máy vi tính trung tâm nơi l-u trữ và bảo trì
tồn bộ thông tin tài khoản và các máy thủ quỹ tự động giao diện với
khách hàng. Mạng thông tin nối máy vi tính trung tâm với các địa điểm
thủ quỹ có thể đ-ợc xác định là thành phần bổ sung cấp cao. Rồi thì
mạng này tất nhiên là phân chia đầu tiên của hệ thống từ viễn cảnh thiết
kế: (1) hệ thống phụ thủ quỹ tự động21 (2) hệ thống phụ vi tớnh trung tõm

và (3) thiết bị mạng thông tin.

Hình 6.4

Hệ thống thủ quỹ tự động -- biểu đồ phân gii thit k

21 ở những hệ thông hớn các hệ con th-ờng tiêu biểu cho phân giải mức thứ nhất của hệ

thống. Điều này đ-ợc bàn thêm ở phần 6.3.

H thống thủ quĩ
ngân hàng tự động.

Logic giao
diƯn thđ q
Logic thđ

M¸y tính
trung tâm

Giao diện phần
cứng
Giao diện

truyền thông
máy tính thủ
quĩ
Giao diện truyền

thông thủ quỹ
Giao diện
mạng diện rộng

Quản lý cơ
sở dữ liệu

khỏch
hng
Th qu t ng

Driver

phát tiếng

bíp
Driver

máy in
Driver

màn hình
Driver bàn

</div>
(102)<div class='page_container' data-page=102>

Hỡnh 6.4. nêu một thí dụ phân giải thiết kế hệ thống thủ quỹ ngân hàng
tự động thành những cấp thành phần thiết kế thấp hơn. ởcấp thứ ba thành
phần thủ quỹ tự động phân giải thành các giao diện phần cứng và logic
thủ quỹ. Rồi cấp sau có thể phân giải giao diện phần cứng thành bộ kích
thích bàn phím, bộ kích thích màn hình, bộ kích thích máy in và máy
phát tiếng bíp, ở cấp này, các bộ kích thích đó có thể đại diện mơ đun
phần mềm hiện nay.

Một điểm quan trọng cần nhớ là trong phân giải thiết kế, chỉ có các
thành phần cấp thấp hơn hiện nay đ-ợc thực hiện. Các thành phần cấp cao
hơn đại diện cho một nhóm các thành phần cấp thấp hơn. Điều này đ-ợc
minh họa trong hình 6.2(a) theo các đó thành phần kiểm tra truy nhập và
hệ thống báo động đại diện cho hai nhóm thành phần cấp thấp hơn (nhận
biết khách thăm, kiểm tra khóa cửa v.v...).

Về cơ bản phân giải thiết kế tạo ra hai loại thành phần hệ thống thành
phần cấp cao và mô đun cấp thấp hơn. Các tiêu chuẩn phát triển phần
mềm khác nhau sử dụng thuật ngữ khác nhau để nhận biết các cấp phân
giải khác nhau.

Chẳng hạn, tiêu chuẩn 2167A US DOD (DOD 1988a) sử dụng một
ph-ơng pháp phân giải nhiều cấp đôi chút nặng nề (coi h. 8.4). Tiêu
chuẩn sử dụng từ CSU (đơn vị phần mềm vi tính) để nhận biết thành phần
phân giải cấp thấp nhất. Những thành phần cấp trung độ đ-ợc gọi là CDC
(thành phần phần mềm vi tính) và những thành phần này có thể đại diện
một nhóm CSU và CSC. Các CSC cấp cao đ-ợc nhóm thành CSCZ (khoản
cấu hình phần mềm vi tính) và những CSCZ đ-ợc quản lý trong phạm vi
dự án coi nh- những đơn vi phát triển bán độc lập. CSCZ là những thành
phần có thể đ-ợc thiết kế, chứng minh bằng t- liệu và phê chuẩn
nh-những thực thể riêng biệt trong phạm vi toàn bộ dự án phần mềm. Tiêu
chuẩn DOD 2167a cho phát triển phần mềm đ-ợc bàn thêm ở ch-ng 9.

Hình 6.5.a

Phõn gii phn mm mc nh ban u

Hợp phần 3
Hệ thống

</div>
(103)<div class='page_container' data-page=103>

Hình 6.5.b

Phõn gii phn mm mc trung gian -- thit k mc nh

Hình 6.5.c

Phân giải phÇn mỊm møc chi tiÕt

Một hệ thống phân giải hồn tồn với mọi thành phần cấp thấp của nó,
khơng phải bao giờ cũng dễ nắm bắt, điều này đặc biệt đúng trong sự

trình bày hệ thống lúc duyệt dự án khi hệ thống cần đ-ợc những ng-ời
khơng dính liú vào việc thiết kế nó nhanh chóng hiểu đ-ợc. Trong những
tr-ờng hợp nh- thế, kỹ thuật tinh lọc từng b-ớc là ph-ơng pháp thuận lợi
để trình bày tuần tự chi tiết tăng dần bằng cách lúc đầu choi thấy cấp
phân giải đầu tiên và rồi chầm chậm phát hiện những cấp tiếp theo. Điều
này đ-ợc chứng minh trong hình 6.5. Trong b-ớc phân giải trung độ thích
hợp, chúng ta có thể phân thiết kế làm hai: cấp cao hơn và cấp thấp hơn.
Điều này đặc biệt đ-ợc dùng khi giai đoạn thiết kế đ-ợc thực hiện thành
2 giai đoạn riêng biệt: thiết kế cấp cao và thiết kế chi tiết (coi hỡnh 6.5).

6.2. Cơ cấu phân tích công việc.

Nh- vy, chỳng ta đã bàn đến việc phân hệ thống phần mềm thành
những thành phần hoặc chức năng hoặc thiết kế. Chúng ta cũng sẽ xem
xét việc phân dự án phần mềm thnh nhng thnh phn cụng vic c bn.

Hợp phần 3
Hệ thống

Hợp phần 1 Hợp phần 2

1.1 1.2 2.1 2.2 2.3 3.1 3.2

Hợp phần 3
Hệ thống

Hợp phần 1 Hợp phần 2

1.1 1.2 2.1 2.2 2.3 3.1 3.2

</div>
(104)<div class='page_container' data-page=104>

Tổng số của những thành phần cơng việc đó bao gồm mọi nhiệm vụ cần
thiết đ-ợc thực hiện nhằm hoàn thành thắng li d ỏn.

6.2.1. Phân giải dự án.

Đúng nh- mọi nhiệm vụ phức tạp lớn khác, việc phát triển dự án phần
mềm dễ quản lý hơn nhiều bằng cách tiếp cận chia và trị (phân chia và
chiếm lĩnh) việc tinh lọc từng b-ớc, khi áp dụng cho một dự án phần
mềm, tạo nên mọi nhiệm vụ công việc cấp thấp. Điều này bao gồm nhiệm
vụ phát triển, nhiệm vụ quản lý, nhiệm vụ hỗ trợ và nhiệm vụ hành chính.
Việc phân giải một dự án phần mềm thành những nhiệm vụ đ-ợc coi là
cơ cấu phân tích công việc hay WBS.

Hình 6.6

Cấu trúc liệt kê công việc (a) phác thảo công viƯc

Hình 6.6. cho một ví dụ về biểu đồ cơ cấu phân tích cơng việc và bảng
6.1. danh mục nhiệm vụ cơ cấu phân tích cơng việc đạt đ-ợc. Danh mục
nhiệm vụ WBS có mọi nhiệm vụ cơng việc dự án và có thể đ-ợc dùng
làm cơng cụ kiểm chứng để kiểm tra tình hình các nhiệm vụ cơng việc
đ-ợc giao. Danh mục nhiệm vụ WBS ban đầu th-ờng từ lịch trình dự án
mà ra lịch có danh mục hoạt động của dự án. Danh mục hoạt động của
lịch t-ơng tự nh- WBS mặc dù mục đích của nó có khác nhau và th-ờng
ít chi tiết hơn. Danh mục hoạt động của lịch đ-ợc mô tả ở ch-ơng 9.

Hoạt động báo động

Qu¶n lý file

Hoạt động
báo động

Hoạt
động báo

độ

Hoạt động báo động

Qu¶n lý fil

Hoạt động báo
động
Hoạt động

báo động

Qu¶n lý

Hoạt động báo
động

Quản lý file
Hoạt động báo động

Qu

Hoạt
động báo

động
Hoạt động báo động

Hoạt
động báo
Hoạt

động báo
động
Hoạt

động báo
đ
Hoạt

động báo
độn

Hoạt động
báo động

</div>
(105)<div class='page_container' data-page=105>

H×nh 6.6

CÊu tróc liƯt kê công việc (a) phác thảo công việc
Bảng 6.1. Danh mục nhiệm vụ cơ cấu phân tích công việc.

Nhiệm vụ Mô tả Tình hình Giao cho Nhận xét
1. Quản lý và hành chính

2. Phát triển phần mềm
2.1. Phân tích yêu cÇu phÇn

mỊm

2.2. ThiÕt kÕ phÇn mỊm
2.2.1. LogÝc kiĨm tra
2.2.2. Giao diện chỉ huy
2.2.3. Tiện ích màn hình

2.2.3.1. Bộ khuôn màn hình Trọn vẹn J.Smith
2.2.3.1. Bộ kích thích màn hình Khởi

công F.Brown
2.2.3.2. Máy phát khuôn Khởi

công A.Black
2.2.4 Thông tin

2.3. MÃ hóa phần mềm
2.4. Hòa nhập phần mềm
3. Cung cấp và hỗ trợ phát

triển

Hot ng bỏo ng

Quản lý file

Hot ng

bỏo ng

Hot
ng bỏo

Hot động báo động

Qu¶n lý fil

Hoạt động báo
động
Hoạt động

báo động

Qu¶n lý

Hoạt động báo
động

Quản lý file
Hoạt động báo động

Qu

Hoạt
động báo

động
Hoạt động báo động

Hoạt
động báo
Hoạt

động báo
động
Hoạt

động báo
đ
Hoạt

động báo
độn

Hoạt động
báo động

</div>
(106)<div class='page_container' data-page=106>

Dù ¸n WBS

Đơi khi lại có ích khi gặp các nhóm nhiệm vụ cấp cao hơn trong danh
mục nhiệm vụ WBS (thí dụ nhiệm vụ 1, 2, 3, 2.1, 2.2, v.v... trong bảng
6.1). Điều này giúp truy nguyên có lợi cho mỗi nhiệm vụ cấp thấp nhằm
nhận biết các nhóm nhiẹme vụ từ đó suy ra. Dù sao, việc đ-a các nhóm
nhiệm vụ cấp cao trong danh mục nhiệm vụ WBS cũng có thể gây ra hỗn
độn vì những khoản này không đại diện cho những nhiệm vụ hiện nay
đ-ợc giao và nhữn thuộc tính tình hình và ủy nhiệm cho không áp dụng

đ-ợc cho chúng.

Danh mục WBS các nhiệm vụ dự án đ-ợc suy từ bản thống kê công
việc của dự án (SON) xác đinh quy mô của dự án. SON th-ờng đ-ợc
chuẩn bị tr-ớc khi trong dự án chính thức (coi ch-ơng 3) và th-ờng là bộ
phận của hợp đồng dự án giữa khách hàng và nhà sản xuất. Với những dự
án nội bộ, khi một tổ chức tài trợ cơng việc phát triển của chính mình,
SON trở nên vô danh với việc xác định chi tiết dự án hay một t- liệu
t-ơng tự xác định qui mô công việc cho ng-ời quản lý dự án phần mềm.

6.2.2. WBS là một công cụ quản lý dự án.

C cu phõn tích cơng việc xác định mọi nhiệm vụ phải thực hiện
trong quá trình phát triển của dự án. Điều này sẽ bao gồm cả những
nhiệm vụ từ các phạm trù d ỏn nh-:

- Phát triển phần mềm
- Bảo trì

- Đào tạo

- Dn chng t- liu
- Lp t

- Quản lý
- Cung cấp

Những nhiệm vụ này đ-ợc mô tả chi tiết hơn ë b¶ng 6.2.

ở Mọi lúc, bất cứ cơng việc nào đ-ợc một thành viên của đội dự án

phần mềm thực hiện phải là một bộ phận của nhiệm vụ WBS không một
thành viên nào của đội đ-ợc thực hiện bất cứ nhiệm vụ gì khơng có trong
danh mục WBS các nhiệm vụ.

</div>
(107)<div class='page_container' data-page=107>

WBS cũng là một công cụ ngân sách cung cấp ph-ơng tiện tính giá
mỗi hoạt động phát triển vào mỗi đoạn thích hợp trong ngân sách dự án.
Đây là một trong những ph-ơng pháp cơ bản để lập kế hoạch và giám sát
chi phí dự án.

Có nhiều tiện ích vi tính hóa có đ-ợc để hỗ trợ bảo trì WBS. Những
tiện ích này hoạt động cả trên máy vi tính nhỏ loại PC và những phần
chính lớn. Những tiện ích WBS đơi khi có đ-ợc nh- là bộ phận của tiẹne
ích qui hoạch chung của ng-ời quản lý và cung cấp các đặc điểm lịch
trình và giám sát khác nh- phân tích PERT và hình thành báo cáo.

Có những ph-ơng pháp khác đ-ợc phát triển để quản lý những nhiệm
vụ công việc cấp thấp bao gồm một dự án lớn. Có vơ vàn biến thức và cải
tiến kỹ thuật cơ cấu phân tích cơng việc22, một số sử dụng những cơng cụ

truy tìm tinh vi, số khác sử dụng những ký hiệu và kỹ thuật đặc biệt để
phân tích và giám sát danh mục nhiệm vụ cơng việc.

6.3. Xư lý c¸c dù ¸n lín.

Rõ ràng, những nhiệm vụ nhỏ dễ sử lý hơn những nhiệm vụ lớn.
Nh-chúng ta đã thấy, đây đã là lập luận bảo vệ việc phân các dự án lớn thành
những thành phần nhỏ hơn.

Trong một tranh luận về kiến trúc của hệ thống phần mềm tàu con thoi
vũ trụ, Carlow (1984) đã nhận xét là "... chỉ công cụ và kỹ thuật thơi

khơng thể phịng ngừa hay khắc phục những vấn đề sẽ tồn tại nếu kiến
trúc hệ thống cấu trúc tốt đã không đ-ợc thiết lập trên đầu mặt tiền của
qui trình phát triển." Trong tham luận của ơng, Carlow mô tả lập luận
bảo vẹ cơ cấu và kiến trúc của phần mềm phức tạp cho một trong những
hệ thống mà phân ban hệ thống liên bang IBM đã phát triển cho tàu con
thoi vũ trụ NASA. Điểm phải làm là kiến trúc phần mềm vốn đ-ợc xác
định sớm trong chu kỳ phát triển đóng vai trị chủ đạo trong việc xây
dựng chất l-ợng của sản phẩm phần mềm cuối cùng. Hay, tóm lại, những
sai lầm chủ yếu th-ờng bắt đầu sớm.

Con đ-ờng mà một hệ thống đ-ợc phân giải, đóng góp đáng kể vào
kiến trúc phần mềm. Thơng th-ờng khơng có điều gì tựa nh- kiến trúc
duy nhất đúng hay phân giải duy nhất đúng cả. H.6.7 giới thiệu hai phân
giải cấp cao có thể đ-ợc của một hệ truy nhập đ-ợc kiểm tra. Cả hai có vẻ
là những đoạn hợp lý của một hệ thống nh-ng kiến trúc trong h.6.7.(b) có
thể địi hỏi ít giao diện hơn giữa các thành phần phần mềm chính.

Giê chóng ta sÏ xem xÐt mét sè h-íng dÉn ph¶i theo khi lùa chän một
cơ cấu phân giải riêng.

6.3.1. Các hệ thống phụ.

</div>
(108)<div class='page_container' data-page=108>

Các hệ thống đôi khi gồm những thành phần chủ yếu bán độc lập bản
thân chúng có thể đ-ợc coi là hệ thống. Một hệ thống thủ quỹ ngân hàng
tự động tất nhiên có thể đ-ợc phân làm hai hệ phụ hơn: hệ phụ vi tính
chính và hệ phụ vi tính thủ quỹ tự động. Theo thế một hệ phụ chứa hầu
hết đặc điểm của một hệ, trừ khi hệ phụ khơng có ý định hoạt động trên
chính nó.

H×nh 6.7.a

Phân giải hệ thống mức cao. Cách (a)

Hình 6.7.b

Phân giải hƯ thèng møc cao. C¸ch (b)

Khi các hệ thống phần mềm lớn có thể chia thành những hệ thống phụ
chúng loại bỏ một số tính phức tạp, có ở tính chất rộng lớn, ý t-ởng bảo
vệ cho tiếp cận đó căn cứ ở việc quản lý phát triển mỗi hệ thống phụ coi
nh- hệ riêng biệt trong phạm vi có thể đ-ợc.

Với mỗi hệ thống phụ, ng-ời lãnh đạo đội hay phó quản lý dự án đ-ợc
ủy thác phần lớn trách nhiệm cho phát triển trong khi các trách nhiệm
chúng cho mọi hệ thống phụ đ-ợc quản lý dự án trong tâm sử lý.

Hoạt động báo động
Hoạt động báo động

Qu¶n lý file truy nhËp

Hoạt động
báo động
Hoạt động báo

động

Qu¶n lý file t

Hoạt động báo động

Hoạt động
báo động

Quản lý f
Hoạt động

báo động

Q
Hoạt động báo

động

Qu¶n lý file

Hoạt động báo động

Qu¶n lý file truy

Hoạt
động báo

động
Hoạt động báo động

Qu¶n lý file truy nhËp

Hoạt động
báo động
Hoạt động báo

động

Qu¶n lý file

Hoạt động báo động

Hoạt động
báo động

Quả
Hoạt động

báo động
Hoạt động báo

động

Q

Hoạt động báo động

</div>
(109)<div class='page_container' data-page=109>

ở một dự án qui mô nhỏ, nh- hệ thống thủ quỹ ngân hàng tự động,
thảo luận tr-ớc đây, hai lãnh đạo đội có thể đ-ợc giao trách nhiệm cho
hai thành phố chính của hệ thống. Ng-ời quản lý dự án sẽ giám sát hoạt
động ở mỗi đội và sẽ phối hợp hoạt động giao diện kỹ thuật và hành
chính giữa các đội. Việc ủy nhiệm của lãnh đạo đội phần mềm đ-ợc bàn

thêm ở ch-ơng 5.

ở một số dự án qui mô lớn nh- phát triển phần mềm cho tàu con thoi
vũ trụ NASA, dự án đã quá khổng lồ đến mức độ trên thức tế đ-ợc phát
triển nh- vô vàn dự án riêng biệt. Văn phòng Trung -ơng chịu trách
nhiệm về sự phối hợp và hoà nhập mọi hệ thống phụ (cả phần mềm và
phần cứng). Tham luận của Dadden và Rone (1984) đề cập sâu đến qui
mô lớn lao ca d ỏn phc tp ny.

6.3.2. Đ-ờng lối phân giải chức năng.

Nh- chỳng ta ó thy phõn chia ban u của một hệ thống phần mềm
là phân giải theo chức năng t-ơng ứng với cơ cấu của phần mềm
nh-đ-ợc ng-ời dùng nhận thức. Việc phân chia này giúp chúng ta xác định
những yêu cầu cho hệ thống và cung cấp ph-ơng pháp nhận biết các chức
năng cấp thấp và gán chúng vào những yêu cầu cho hệ thống chủ yếu.

Nhiều văn bản đề nghị là phân giải chức năng phải theo sự phân tích
yêu cầu của hệ thống. Trong nhiều tr-ờng hợp, phác thảo chung các yêu
cầu sẽ tạo nên biểu đồ chức năng cấp cao. Trên tinh thần đó, việc tình lọc
phân giải chức năng khăng khít với việc phân tích hệ thóng trong đó biểu
đồ đ-ợc ln ln xem lại và tinh lọc khi lại có thêm đ-ợc thơng tin.

Phân tích chức năng cấp cao cơ bản của hệ thống phần mềm th-ờng
căn cứ ở những ý t-ởng tiêm nghiệm diễn tiến trong giai đoạn quan
niệm. Rồi những ý t-ởng có thể định ra sự phân chia đặc thù của hệ
thống, từ đó diến tiến sự phân gii chc nng.

Sự phân chia ban đầu này của hệ thống không phải bao giờ cũng là
lôgíc nhất và thích hợp nhất theo viễn cảnh của ng-ời sản xuất. Hệ thống

kiểm kê rộng lớn ban đầu có thể nhận thức là bao gồm:

- Giao diện con ng-ời
- Bộ phát báo cáo
- Cơ sở dữ liệu
- Lôgíc cập nhật.

</div>
(110)<div class='page_container' data-page=110>

Đ-ờng lối chung là không có phân giải chức năng duy nhất nào đ-ợc
lựa chọn chỉ vì đ-ợc quan niệm đầu tiên cả.

Nh- chỳng ta ó thy, phõn gii chc năng tốt là quan trọng và rõ ràng
có thể xác định thiết kế và kiến trúc của hệ thống đ-ợc phát triển, Chiến
l-ợc tin cậy trong việc xác định phân giải chức năng phần mềm đ-ợc tốt
là triệu tập cuộc họp của những ng-ời trọng yếu của dự án để bàn một số
những phân chia khác nhau của hệ thống. Sau đó phân giải chức năng
phải đ-ợc lựa chọn trên cơ sở.

- Lý do (thÝ dơ c¸c m¸y vi tÝnh khác nhau th-ờng hỗ trợ các chức năng
khác nhau).

- D thực hiện (thí dụ phân giải chức năng tốt sẽ th-ờng dẫn đến thiết
kế tốt).

- Dễ hiểu (đã đáp ứng hết các chức năng ch-a ?)

ViƯc dƠ thùc hiƯn tïy thuộc ở tiêu chí thiết kế mà ta sẽ bàn sau.

6.3.3. Đ-ờng lối phân giải thiết kế.

Chỳng ta ó bit là phân giải chức năng của hệ thống phần mềm có thể

cơ bản khác với phân giải thiết kế của hệ thống. Dù sao phân giải chức
năng tốt sẽ chú ý đến thiết kế nh- ở giai đoạn phát triển sau và sẽ th-ờng
là khởi điểm tốt cho việc phân chia hệ thống thành những thành phần
thiết kế cấp cao.

Việc phân giải thiết kế của hệ thống chỉ là một phần của tồn bộ thiết
kế phần mềm (có nhiều ph-ơng pháp thiết kế, chẳng hạn xin coi Fairly
(1985) hay Irossman (1987). Dù sao theo viễn cảnh của ng-ời quản lý dự
án, đây là giai đoạn quyết định vì việc phân giải thiết kế của một hệ
thống xác định cơ cấu của phần mềm nh- nó sẽ đ-ợc hình thành. Sau đây
là tổng quan về nhận định thiết kế cơ bản ảnh h-ởng đến ph-ơng pháp
phân giải hệ thống.

Một trong những quan điểm cơ bản sớm của công nghệ phần mềm đòi
hỏi tiếp cận về cơ cấu với việc thiết kế và lập trình phần cứng. Bản chất
cơ cấu của phần mềm đ-ợc xác định từ những giai đoạn phân giải đầu
tiên. Vào cuối những năm 1960 và đầu 1970. Difkstra đã đi đầu trong
tiếp cận này (1972). Mục tiêu chủ yếu là chuyển sang phát triển phần
mềm (hay đơn giản là lập trình nh- sau này đ-ợc gọi thế) từ khi ch-a
thành thục tới trở thành một ngành công nghệ hịan tồn phát triển. Từ đó
đến nay nhiều kỹ thuật thiết kế cơ cấu khác đã đ-ợc Yourdon (1978),
Jackson (1976) De Marco (1979) Warrier và Orr (1977) phát triển, đấy là
mới chỉ kể một số, nh-ng ch-a có tiêu chuẩn duy nhất nào nói chung
đ-ợc chấp nhận.

</div>
(111)<div class='page_container' data-page=111>

che dấu thông tin trở thành những khối công trình cơ bản cho việc thiết
kế môđun phần mềm đ-ợc tốt.

Núi mt cách đơn giản, phân giải thiết kế tốt tạo nên những môđun
nhỏ, đơn giản, độc lập. Tất nhiên, trong mọi hệ thống, khơng có hai

mơđun thực sự độc lập, nên từ ngữ độc lập ở đây phải hiểu theo nghĩa
càng độc lập càng tốt trong phạm vi các ràng buộc của hệ thống đ-ợc
phát triển.

ở cấp phân giải thấp nhất, mức độ độc lập của các môđun đ-ợc coi là
mức độ ghép nối tồn tại trong thiết kế. Những biện pháp ghép nối các đặc
điểm phụ thuộc lẫn nhau đó nh- dữ liệu nội dung kiểm tra và mơđun (có
nghĩa chồng chéo các biên môđun).

Chắc chắn một trong những nguyên tắc cơ bản nhất trong phân giải
thiết kế phần mềm đ-ợc định tâm chung quanh quan niệm hộp đen.
Nguyên tắc đó, cũng đ-ợc coi là che dấu thơng tin tiến tới tạo ra những
môđun che dấu thiết kế của chúng. Các hộp đen chỉ đ-ợc nhận biết ở đầu
vào và đầu ra, chứ không ở ph-ơng pháp sử dụng để phát sinh đầu ra từ
đầu vào mà có. Việc che dấu thơng tin tạo ra những mơđun che dấu luồng
lơgíc của chúng và các cơ cấu dữ liệu của chúng với nhau. Mặc dù từ hộp
đen đi tr-ớc tiến triển của công nghệ phần mềm là một ngành, quan niện
che dấu thông tin trong thiết kế phần mềm đã đ-ợc Iarnas -a ra u tiờn
(1972).23

6.3.4. Đ-ờng lối phân giải nhiệm vơ c«ng viƯc.

Chúng ta đã thấy cơng việc u cầu để hồn thành dự án có thể đ-ợc
phân thành nhóm nhiệm vụ đơn giản hơn đ-ợc xác định rõ biểu thị bằng
cơ cấu phân tích cơng việc hay WBS. WBS không phải là sự phân giải
phần mềm tạo ra bởi dự án. Đó là sự phân giải bản thân dự án và bao gồm
những hoạt động nh- quản lý, cung cấp, lắp đặt và tất nhiên phát triển
phần mềm.

Cơ cấu thiết kế của hệ thống tạo nên những nhiệm vụ công việc phát

triển cấp thấp. Mỗi môđun cấp thấp đ-ợc ủy thác ba nhiệm vụ công việc
cơ bản: thiết kế môđun, lập mã và thử nghiệm đơn vị. Những nhiệm vụ
phát triển bổ sung nh- lấy nguyên mẫu thử nghiệm và hội nhập là từ các
giai đoạn phát triển khác mà ra.

Bảng 6.2. có một danh mục tiêu biểu các nhiệm vụ WBS cấp cao đ-ợc
đ-a vào danh mục nhiệm vụ WBS chính thức (coi bảng 6.1). Đây khơng
phải là một danh mục tận dụng mọi nhiệm vụ phát triển dự án và khơng
phải mọi dự án sẽ địi hỏi mọi nhiệm vụ mô tả. Dù sao, bảng này sẽ có
ích làm danh mục kiểm tra hỗ trợ xác định vị trí các nhiệm vụ có thể bị
bỏ qua.

Những hoạt động không phát triển nh- nhiệm vụ WBS quản lý cấp cao
là qui chuẩn đến một mức độ rộng và mọi khác nhau đ-ợc xác định hoặc

</div>
(112)<div class='page_container' data-page=112>

do qui mô lớn lao của dự án hoặc đ-a vào một mơ hình quản lý mới. Thí
dụ danh mục các nhiệm vụ quản lý quan trọng nhất đòi hỏi cho hầu hết
dự án phát triển phần mềm. Những nhiệm vụ nào không bắt buộc cho mọi
nhiệm vụ đ-ợc đánh dấu nh- thế trong danh mục.

Nên ghi nhận là phân tích ngân sách và quản lý ngân sách không phải
là nhiệm vụ quản lý bắt buộc đơn giản vì khơng phải tất cả dự án quản lý
ngân sách của chính chúng. Một số tổ chức có quan chức tài chính chịu
trách nhiệm quản lý các ngân sách của dự án. Giao diện khách hàng cũng
phải là nhiệm vụ quản lý bắt buộc vì khơng phải mọi dự án đều có khách
hàng. Trong tr-ờng hợp các dự án nội bộ công ty, quản lý cấp cao, cùng
với những ng-ời sử dụng hệ thống đ-ợc chỉ định, đóng vai trị khách
hàng. Th-ờng là họ nêu rõ những yêu cầu dự án ban đầu và ng-ời quản lý

dự án phải đến họ để đ-ợc phê chuẩn cuối cùng và đ-ợc nghiệm thu hệ
thống lần cuối.

6.4. Tãm t¾t.

Những dự án phần mềm phức tạp có thể phân thành những thành phần
đơn giản hơn và mặc dù tồn bộ dự án có thể khó quản lý, mỗi thành
phần lại sẽ dễ sử lý hơn. Việc phải giải các hệ thống phần mềm thành
những thành phần nhỏ là có ích trong việc giám sát những hoạt động
đ-ợc ủy thác cho các đội phát triển khác nhau. Ph-ơng pháp phân giải có
thể khác nhau, tùy thuộc ở mục tiêu của ng-ời quản lý dự án.

Việc tinh lọc từng b-ớc là một ph-ơng pháp lặp lại để phân giải một dự
án thành những thành phần quản lý đ-ợc. Việc tinh lọc từng b-ớc là cơng
cụ có ích cho việc xác định, các phân giải công việc, thiết kế và chức
năng của một dự án phần mềm. Trong phân giải từng b-ớc một dự án,
mỗi thanhphâfn phân giải thành những thành phần trực tiếp d-ới nó. Mỗi
b-ớc phân giải mơ tả toàn bộ hệ thống nh-ng ở mức độ chi tiết khác
nhau.

Phân giải chức năng của một hệ thống phần mềm là phân chia hệ thống
thành những thành phần vận hành: đó là những đặc điểm nào mà ng-ời
dùng nhìn thấy. Phân giải thiết kế một hệ thống phần mềm là phân chia
hệ thống thành những thành phần cấp thấp hơn trùng với những thành
phần lập trình của hệ thống. Cơ cấu phân tích cơng việc (WBS) là phân
giải dự án phần mềm thành những nhiệm vụ công việc cấp thấp.

</div>
(113)<div class='page_container' data-page=113>

Phân giải chức năng cấp cao cơ bản của một hệ thống phần mềm
th-ờng căn cứ ở những ý t-ởng tiêm nghiệm diễn tiến trong giai đoạn
quan niện. Những ý t-ởng đó có thể định ra sự phân chia đặc thù của hệ

thống từ đó diễn tiến ra phân giải chức năng. Dù sao, phân chia ban đầu
cảu hệ thống khơng phải bao giờ cũng là lơgíc nhất và thích hợp nhất
tr-ớc viễn cảnh của ng-ời sản xuất. Về đ-ờng lối chung, khơng có phân
giải chức năng duy nhất nào lại đ-ợc lựa chọn chỉ vì đ-ợc quan niện đầu
tiên.

Phân giải chức năng của một hệ thống phần mềm có thể căn bản khác
với phân giải thiết kế của hệ thống. Dù sao phân giải chức năng tốt sẽ có
tính đến thiết kế là giai đoạn phát triển sau và sẽ luôn là khởi điểm tốt
cho việc phân chia hệ thống thành những thành phần thiết kế cấp cao. Sau
đó, các thành phần thiết kế cấp cao lại đ-ợc phân giải thành những cấp
thấp hơn liên tiếp cuối cùng tạo nên những mơđun lập trình. Thiết kế
mơđun tốt tạo nên những môđun độc lập, đơn giản, nhỏ.

Cơ cấu phân tích cơng việc khơng phải là phân giải của phần mềm do
dự án tạo nên mà là phân giải của chính dự án và bao gồm những hoạt
động nh- quản lý, cung cấp, lắp đặt và tất nhiên, phát triển phần mềm.
Nhiều nhiệm vụ phát triển WBS là do ph-ơng pháp phát triển đ-ợc sử
dụng và do thiết kế và kiến trúc của hệ thống mà ra.

Bµi tËp.

1. Công ty hệ thống phần mềm (SSI) đang phát triển một vi tính có
mục đích đặc biệt dựa trên bộ vi xử lý chung. SSI có bộ biên dịch chéo
cho bộ vi xử lý hoạt động trên khung chính của công ty. Công ty đã quyết
định phát triển một hệ thống vận hành sở hữu khiêm tốn cho máy vi tính
mới.

Hãy xét một hệ thống đơn giản chỉ một ng-ời dùng. Chuẩn bị một đề
nghị về việc phân giải chức năng của hệ thống vận hành sử dụng tinh lọc

từng b-ớc. Mô tả biểu đồ phân giải chức năng cho ba cp u.

2. Với hệ thống vận hành mô tả ở bài tập 1 và căn cứ ở phân giải chức
năng, chuẩn bị phân giải thiết kế. Mô tả biểu diễn phân giải thiết kế cho
ba cấp đầu. Chọn thành phần cấp cao duy nhất và mô tả toàn bộ phân giải
tới tận cấp môđun phần mềm.

Gii thớch bn ó tính đến những h-ớng dẫn cho các mơđun độc lập thế
nào. Giải thích bạn đã thực hiện h-ớng dẫn che dấu thông tin thế nào.

3. Với hệ thống vận hành ở bài tập 1, chuẩn bị biểu đồ cơ cấu phân tích
cơng việc cho ba cấp đầu và chuẩn bị danh mục nhiệm vụ WBS. Giải
thích vì sao một số nhiệm vụ ở bảng 6.2 không áp dụng đ-ợc cho d ỏn
ny.

4. Xét phần mềm cho 1 dự án vệ tính kể cả việc phóng và theo dõi vệ
tinh và vËn hµnh cđa vƯ tinh trong vµ sau khi phãng.

</div>
(114)<div class='page_container' data-page=114>

Bây giờ xét hệ thống danh sách nhân viên kể cả nhân lực bảo trì hồ
sơ,phát phiếu kiểm tra danh sách v.v... liệu đó có lợi điểm gì trong việc
xác định các hệ phụ cho dự án đó ? Gii thớch.

Bảng 6.2. Nhiệm vụ cơ cấu phân tích công việc cấp cao.

Phát triển phần mềm
Phân tích yêu cầu
Phát triển nguyên mẫu
Đặc điểm nguyên mẫu
Thiết kế nguyên mẫu
Thực hiện nguyên mẫu

Thử nghiệm

Th nghim Alpha
Th nghim bờta
Nghim thu
Lp t

Đào tạo
Cung cấp

Thu thập công cụ phát
triển

Thu thập các thành phần
hệ thống

Thiết kế

Thiết kế cấp cao
Thiết kế chi tiết

Bảo trì

Hiệu chỉnh sai lầm
Tăng c-ờng phần
mềm

Chn la thitbi
Chn la ng-i bỏn

Th tc t hàng
Kiểm tra kiểm kê
Thực hiện

LËp m·

Thử nghiệm đơn vị

Qu¶n lý
Qui hoạch
Tuyển nhân sự

Quản trị và dịch vụ
khác

T- liệu

Bài viết kỹ thuËt

Hoạt động xuất bản dự án
T- liệu phát triển không
giao -c.

Hội nhập

Hội nhập phần mềm
Hội nhập phần cứng/
phần mềm.

Quản trị ngân sách

Quản lý nhân sự
Bảo hiểm chất l-ợng
Quản lý cấu hình

T- liệu phát triển giao
đ-ợc

T- liệu về bảo trì
T- liệu ng-ời dùng

Bảng 6.3. Nhiệm vụ quản lý và hành chính

ủy
nhiệm

Nhiệm vụ quản lý
v
v
v
v
v
v
v
v
v
v

1. Quy hoạch
2. Chuẩn bị dự án

3. Phân tích rủi ro và quản lý rủi ro
4. Lịch trình

5. Tuyển nhân sự

6. Phân tích ngân sách và quản trị ngân sách
7. Quản lý nhân sự

8.ủy thác nhiệm vụ
9. Giao thẩm quyền

10.ủy thác nguồn phát triển

11. Giám sát bảo trì thiết bị phát triển
12. Giám sát và kiểm tra phát triển

</div>
(115)<div class='page_container' data-page=115>

v
v
v
v

15. Bảo hiểm và kiểm tra chất l-ợng
16. Quản lý và kiểm tra cấu hình

17. Giám sát các chủ thầu phụ và ng-ời bán
18. Giao diện và phối hợp quản lý cao
19. Giao diện và phối hợp khách hàng
20. Báo cáo

</div>
(116)<div class='page_container' data-page=116>

Ch-ơng bảy

Các chức năng hỗ trợ dự án

Hỗ trợ quản lý dự án.

Qun lý dự án phần mềm là quá trình qui hoạch, tổ chức, tuyển nhân
sự, giám sát, kiểm tra và lãnh đạo dự án phần mềm24. Hiếm khi mọi nhiệm
vụ đó lại có thể do quản lý dự án thực hiện mà trên thực tế về mặt lý
t-ởng họ không thể. Nhiều hoạt động kiểm tra và giám sát có thể đ-ợc ủy
thác cho các nhóm hỗ trợ dự án. Những nhóm hỗ trợ này không chỉ giám
định nặng cho quản lý dự án và kỹ s- phát triển bằng những nhiệm vụ hỗ
trợ: họ cũng thực hiện những nhiệm vụ đó tốt hơn bằng cách tập trung
mọi cố gắng của họ vào những chức năng hỗ trợ đặc tr-ng.

Cã nhiỊu lo¹i chức năng hỗ trợ dự án. Dịch vụ th- ký, hỗ trợ hành
chính xuất bản và cung cấp tài liệu là những thí dụ về chức năng hỗ trợ
không kỹ thuật; thử nghiệm, kiểm tra cấu hình, công nghệ hệ thống quản
lý hội nhập và bảo hiểm chất l-ợng là những thí dụ về chức năng hỗ trợ
kỹ thuật.

D ỏn càng lớn và càng phức tạp lại sẽ đòi hỏi chức năng hỗ trợ nhiều
hơn. Chẳng hạn, một dự án lớn th-ờng có tổ chức kiểm tra chất l-ợng của
nó trong khi một dự án nhỏ có thể chia xẻ chức năng đó với các dự án
khác. T-ơng tự, nhiều tổ chức duy trì nhóm thử nghiệm độc lập mà vai
trò là thử nghiệm một sản phẩm phần mềm tr-ớc khi đ-a ra. ở những dự
án lớn, nhóm thử nghiệm độc lập là một bộ phận của đội dự án và tham
gia trong thử nghiệm và qui hoạch thử nghiệm xuyờn sut chu trỡnh phỏt
trin.

Ch-ơng này mô tả ba chức năng hỗ trợ dự án kỹ thuật chủ yếu:

- Kiểm tra cấu hình

- Bảo hiểm chất l-ợng phần mềm
- Thử nghiƯm.

Ba chức năng cơ bản đó đ-ợc u cầu trong mỗi dự án phát triển phần
mềm. Kiểm tra cấu hình quản lý thay đổi cho sản phẩm phần mềm đ-ợc
phát triển, bảo hiểm chất l-ợng giám sát và kiểm tra chất l-ợng sản phẩm
còn thử nghiệm thử lại đáp ứng với các yêu cầu của sản phẩm. Trách
nhiệm của ng-ời quản lý dự án là tổ chức các nhóm hỗ trợ dự án và cung
cấp t- liệu các hoạt động đã quy hoạch của các nhóm cho kế hoạch phát
triển dự án (coi ch-ơng 9). Nếu những nhóm đó đã có trong tổ chức, thì
hỗ trợ của các nhóm cần đ-ợc phối hợp và lên lịch cho dự án. Nếu các

</div>
(117)<div class='page_container' data-page=117>

nhóm khơng tồn tại thì chúng phải đ-ợc thiết lập trong đội phát triển dự
án.

Qui m« cđa một nhóm hỗ trợ rõ ràng tùy thuộc ở qui mô dự án, chẳng
hạn, một dự án lớn có thể yêu cầu một nhóm hai hay ba kỹ sự kiểm tra
cấu hình và một dự án nhỏ có thể giao nhiệm vụ một phần thời gian cho
kỹ s- phát triển.

Cỏc quyết định này phải do quản lý dự án đ-a ra trong những giai đoạn
ban đầu của dự án. Các chức năng hỗ trợ dự án đã đ-ợc qui hoạch tốt lúc
khởi đầu dự án sẽ đóng góp vào việc quản lý hiệu quả dự án suốt dự án.

7.1. KiÓm tra cấu hình phần mềm (SCC).

Kim tra cu hỡnh l chức năng hỗ trợ quản lý hỗ trợ nhiều hoạt động
khác nhau liên quan đến thay đổi cho sản phẩm phần mềm. Điều này bao

gồm những thay đổi mã của ch-ơng trình, yêu cầu và thay đổi thiết kế
cùng thay đổi trong việc đ-a ra phiên bản. Kiểm tra cấu hình th-ờng đ-ợc
những nhà sản xuất coi là trở ngại hơn là lợi ích vì nó hạn chế sự tự do
của đội phát triển và đặt ra những giới hạn về cái gì có thể và khơng thể
làm. Kiểm tra cấu hình dù sao cũng tạo ra mơi tr-ờng trong đó phần mềm
có thể đ-ợc phát triển một cách trật tự.

Từ cấu hình đ-ợc sử dụng ở đây để mơ tả sự phối hợp các thành phần
phần mềm tạo thành hệ hợp chất. Khi kết hợp với từ kiểm tra, từ đ-ợc sử
dụng để mô tả một ph-ơng pháp trật tự và hiệu quả theo đó sự phối hợp
đó của các thành phần có thể đ-ợc thực hiện, chẳng hạn, xây dựng các hệ
phần mềm từ những thành phần cấp thấp không phải là nhiệm vụ đơn
giản. Điều này đ-ợc minh họa tốt nhất ở giai đoạn sau.

Một công ty ngân hàng lớn kết hợp làm dịch vụ thông tin tài chính
quốc tế. Dịch vụ này có thể cung cấp cho ngân hàng truy nhập trực tuyến
với cơ sở dữ liệu trung tâm chứa thông tin th-ờng xuyên cập nhật về
những thị tr-ờng tài chính thế giới. Trong thế giới hiện đại thông tin điện
tử nhanh, đây là một dịch vụ chủ yếu cho mọi tổ chức ngân hàng hiện
đại. Dù sao, máy tính của ngân hàng đã khơng có đ-ợc khả năng giao
diện với dịch vụ tài chính.

Ngân hàng ủy thác ng-ời quản lý dự án phát triển phần mềm cần thiết
có nhu cầu cho giao diện. Sau khi giai đoạn hội nhập bắt đầu, một trong
những nhà sản xuất báo cáo là cột mốc chủ yếu đã hoàn thành liên túc với
dịch vụ thông tin đã đ-ợc thiết lập thành công. Ng-ời quản lý dự án báo
cáo điều này cho các cấp trên của anh ta và thông báo với họ là phát triển
đã đ-ợc tiến hành theo lịch.

</div>
(118)<div class='page_container' data-page=118>

ch-a hoạt động. Ngay cả những đặc im tr-c õy cng khụng cũn hot

ng na.

Bắt đầu

Có sửa
không?

Môđun yêu cầu kiểm
tra cấu hình

Sửa môđun

Tiến trình kiểm tra
cấu hình

Th nghim
n v

Môđun phát triển

Kết thúc

Môđun do kiểm tra
cấu hình phát ra

</div>
(119)<div class='page_container' data-page=119>

Hình 7.1

Dòng điều khiển cấu hình môđun phÇn mỊm

Rõ ràng, hẳn nhà sản xuất đã giữ một bản sao của phần mềm liên lạc

khơng có những đặc điểm mới. Trong một dự án tổ chức tốt, nhiệm vụ
phòng vệ, một phiên bản phần mềm tr-ớc đây hẳn đã đ-ợc ng-ời quản lý
cấu hình thực hiện.

Một cách lý thú để xem đến kiểm tra cấu hình là coi nh- một ph-ơng
pháp đảm bảo là dự án tiến triển (hay ít ra khơng thụt lùi). Trong tr-ờng
hợp xét trên hiện nay dự án tr-ợt lùi.

Kiểm tra cấu hình là chủ yếu cho mọi hạng mục phát triển kể cả mã,
t-liệu và hợp nhất thành phần hình 7, mơ tả dịng kiểm tra cấu hình để phát
triển mơđun phần mềm. Một dòng ơng tự hẳn vận dụng đ-ợc cho
t-liệu mà dự án phát sinh kiểm tra cấu hình cũng quan trọng trong giai
đoạn bảo trì để đảm bảo khi việc phát hành mới một hệ thống đ-ợc gọi
lại do những khuyết tật nghiêm trọng có thể bị thay thế trong đợt phát
hành tr-ớc.

7.1.1. Tht ng÷ kiĨm tra cÊu h×nh.

Có nhiều từ đ-ợc dùng liên quan đến kiểm tra cấu hình. Chẳng may,
khơng có một sử dụng nào hay một ý nghĩa nào của chúng đ-ợc chuẩn
hoá: rất nhiều từ khác nhau đã đ-ợc sử dụng để mô tả cùng chức năng;
cùng ý t-ởng. Một trong những cố gắng tốt nhất nhằm tiêu chuẩn hóa có
trong từ vựng IEEE thuật ngữ về công nghệ phần mềm (IEEE 1987b). Dù
sao, ngay từ vựng đó cũng phản ảnh sự thiếu sót trong lý giải và sử dụng
thống nhất các từ đó khi mà nhiều từ kiểm tra cấu hình xuất hiện với vơ
vàn định nghĩa. Sau đây là giải thích hơn là định nghĩa chính xác của một
số những thuật ngữ c bn.

Hạng mục kiểm tra cấu hình phần mềm (SCCI) là hạng mục dự án

phn mm -c coi l mt đơn vị cho những mục đích của kiểm tra cấu
hình. Điều này có thể bao gồm những điều nh- mơ đun phần mềm (1)
phiên bản hệ thống phần mềm hay t- nliệu.

Kiểm tra thay đổilà quá trình kiểm tra các thay đổi. Điều này bao gồm

đề nghị thay đổi, đánh giá thay đổi, chấp nhận hay bác bỏ, lên lịch và
theo dõi thay đổi. Kiểm tra phiên bản nh- vận dụng cho phát triển phần
mềm, là quá trình kiểm tra phát hành các phiên bản phần mềm.25Điều này
bao gồm l-u giữ và phòng ngừa mỗi đợt phát hành và chứng minh bằng
t- liệu các khác biệt giữa các đợt phát hành.

Kiểm tra cấu hình là quá trình đánh giá, chấp nhận hay bác bỏ, và

quản lý thay đổi cho những hạng mục cấu hình. Kiểm tra cấu hình cũng
bao gồm các chức năng kiểm tra phiên bản.

25 NhiỊu gi¶ thÝch từ hạng mục cấu hình không bao giờ hạng mục cấp thấp nh- mô đun phần mềm.

</div>
(120)<div class='page_container' data-page=120>

Qun lý cấu hình là ứng dụng kỹ thuật và hành chính kiểm tra cấu
hình. Điều này cũng bao gồm việc duy trì tổ chức kiểm tra cấu hình, thay
đổi và các tiêu chuẩn kiểm tra phiên bản và các ph-ơng tiện kiểm tra cấu
hình.

Các từ khác là chỉ định nhận biết cấu hình đ-ợc sử dụng để nhận biết
các hạng mục cấu hình, ban kiểm tra cấu hình chấp nhận hay bác bỏ
những thay đổi cơng nghệ và kiểm tốn cấu hình kiểm tra thích ứng với
các tiêu chuẩn kiểm tra cấu hình.

Mục tiêu của quản lý cấu hình đ-ợc xác định tốt nhất khơng phải

nh-những định nghĩa chính thức từ vựng IEEE nh-những thực ra nhờ giải thích
có tính chất mơ tả hơn nh- đã nêu trong lời nói đến tiêu chuẩn IEEE 828
(1987b) cho những kế hoạch quản lý cấu hình phần mềm, khẳng định:

Cung cấp cấu hình phần mềm (SCM) là ngành cơng nghệ chính thức
cung cấp ph-ơng pháp và công cụ cho các nhà sản xuất và sử dụng phần
mềm biết phần mềm đ-ợc phát triển, lập ra những đ-ờng mốc, thay đổi
kiểm tra cho những đ-ờng gốc đó, l-u giữ và theo dõi tình hình và kiểm
tốn sản phẩm.

SCM là ph-ơng tiện thơng qua đó sự hợp nhất và liên tục của sản
phẩm phần mềm đ-ợc l-u giữ, thông tin và kiểm tra.

Một số những nhiệm vụ quản lý cấu hình chồng chéo với nhiệm vụ của
hoạt động hỗ trợ khác, kiểm tra chất l-ợng phần mềm (bàn đến sau).
Trong các dự án phần mềm mà kiểm tra chất l-ợng và kiểm tra cấu hình,
do các nhóm riêng rẽ thực hiện, việc định nghĩa rõ trong phân chia trách
nhiệm là cần thiết.

7.1.2. Nguån lùc kiểm tra cấu hình.

Hình 7.2

Điều khiển cấu hình mạng

Kim tra cấu hình là một trong những lĩnh vực đầu tiên của công nghệ
phần mềm đ-ợc công nhận là dự tuyển tự động hóa, nhiều hoạt động
kiểm tra cấu hình nh- kiểm tra phiên bản và kiểm tra thay đổi đã -c t

Cơ cở dữ liệu

kiểm tra cấu

hình

Các máy tính đầu ci ph¸t triĨn dù ¸n

</div>
(121)<div class='page_container' data-page=121>

động hóa vào đầu những năm 1970 với những cơng cụ nh- đóng mạch và
SCCS (coi Rochkind 1975)26. Một số những công cụ đó dịch chuyển từ
các hệ vận hành UNIX nói chung đ-ợc sử dụng đầu tiên đến các môi
tr-ờng khác nh- MS-DOS và VMS của Digital.

Nhiều hoạt động kiểm tra cấu hình chính là những dự tuyển tự nhiên
cho các cơng cụ tự động hóa CASE (Cơng nghệ phần mềm có hỗ trợ bằng
máy tính) nh- đ-ợc xác định rõ, có đôi chút lặp lại và sẵn sàng hội nhập
vào quá trình phát triển. Những cơng cụ đó có thể đ-ợc dễ dùng giao diện
với các công cụ mã phần mềm (thí dụ các biên tập viên và s-u tập) và các
bộ xử lý từ để sản sinh t- liệu. Kiểm tra cấu hình tự động là tốt nhất khi
đ-ợc sử dụng trong môi tr-ờng phát triển nhiều ng-ời sử dụng nh- LAN
với cách đó mọi nhân tố đ-ợc kiểm tra l-u giữ trong cơ sở dữ liệu trung
tâm và việc truy nhập của mọi nhà sản xuất đ-ợc quản lý từ hệ thống
kiểm tra cấu hình trung tâm (coi Hình.7.2).

Việc kiểm tra cấu hình có hiệu quả địi hỏi ở sự tổ chức hiệu quả và
đ-ợc xác định rõ. Mọi ph-ơng pháp kiểm tra cấu hình phải căn cứ ở bốn
quan niệm sau:

1. Phải thành lập cấp thẩm quyền quản lý cấu hình đ-ợc xác định rõ.
2. Phải sản xuất và phân phối các tiêu chuẩn kiểm tra cấu hình, các thủ
tục và h-ớng dẫn kiểm tra cấu hình các nh sn xut.

3. Kiểm tra cấu hình không thể có hiệu quả nếu không có công cụ và
ph-ơng tiện cần thiÕt.

4. Phải phát triển kế hoạch quản lý cấu hình ngay khởi đầu dự án.
Đây là trách nhiệm của ng-ời quản lý dự án trong việc giao quyền
quản lý cấu hình. Điều này có thể tiến hành từ đội kiểm tra cấu hình
trong các dự án lớn đến kỹ s- kiểm tra cấu hình một phần thời gian trong
các dự án nhỏ. Trong cả hai tr-ờng hợp, cả quyền hạn và trách nhiệm
phải đ-ợc xác định rõ. Kỹ s- kiểm tra cấu hình phải đ-ợc tham gia trong
mọi hoạt động phát triển và phải có quyền hạn đặc thù trong việc chấp
nhận hay bác bỏ hạng mục cấu hình.

Các thành viên đội phát triển phải làm quen với các tiêu chuẩn kiểm tra
cấu hình, các thủ tục và h-ớng dẫn phải dễ hiểu và rõ ràng. Điều này có
thể giảm bớt số phản bác trong kiểm tra cấu hình do khơng thích ứng với
các tiêu chuẩn khơng quen thuộc.

M«i tr-êng quản lý cấu hình bao gồm những cần thiết cho việc thực
hiện kế hoạch kiểm tra cấu hình. Điều này bao gồm:

- Công cụ kiểm tra cấu hình, kể cả:

+ Kiểm tra phiên bản tự động và công cụ kiểm tra thay đổi.
+ Giám sát, kiểm toán và đăng ký các tiện ích hỗ trợ.

26 Sù tiÕn triĨn cđa qu¶n lý cấu hình đ-ợc mô tả trong thảo luận của Ambriola và cộng sự (1990)

</div>
(122)<div class='page_container' data-page=122>

- Ph-ơng tiện l-u giữ: kho chứa an toàn cho mọi hạng mục cấu hình
đ-ợc phê chuẩn, kể cả:

- L-u gi ti ch cho q trình phát triển hàng ngày.
- L-u giữ ngồi phm vi phc hi tai ha.

7.1.3. Kế hoạch quản lý cấu hình phần mềm.

K hoch qun lý cu hỡnh phần mềm (SCMP) là một bộ phận của kế
hoạch phát triển phần mềm cả dự án. SCMP có thể xuất hiện nh- một
t-liệu riêng biệt hay một phần trong phạm vi kế hoạch phát triển dự án.
SCMP cung cấp dự liệu cho các nguồn có nh- cầu, chúng đ-ợc sử dụng
nh- thế nào, và có những tiêu chuẩn thủ tục gì sẽ đ-ợc vận dụng trong dự
án. Theo thế SCMP trở thành đ-ợc ủy nhiệm cho nhóm kiểm tra cấu hình
trong phát triển dự án. Việc đ-a ra kế hoạch đó là trách nhiệm của ng-ời
quản lý dự án, mặc dù trong những dự án lớn nó có thể đ-ợc phó thác cho
ng-ời quản lý kiểm tra cấu hình.

Bảng 7.1. Có một danh mục các đề tài chính nằm trong SCMP. Nếu có
một đề tài nào trong những đề tài đó nằm ở chỗ khác (thí dụ trong kế
hoạch bảo hiểm chất l-ợng phần mềm) thì đề tài đó có thể đ-ợc bỏ qua ở
SCMP và đ-ợc thay bằng con trỏ. Trong t- liệu mà nó đáng phải ở đó.
Mặc dù phần lớn các đề tài trong bảng 7.1. là tự mô tả, sau đây là một số
h-ơng dẫn:

 Báo cáo tình hình cấu hình mơ tả cách thơng tin tình hình diễn triển:
- Từ ng-ời sản xuất đến tổ chức quản lý cấu hình (kiểm tốn và
duyệt).

- Tõ tổ chức quản lý cấu hình tới quản lý dự ¸n (thđ tơc b¸o c¸o
t×nh h×nh).

 Nhận biết cấu hình mô tả ph-ơng pháp chỉ định các hạng mục phát

triển nh- SCCI. Đây là một bộ phận của phân giải hệ thống cấp cao
thành những thành phần páht triển chủ yếu (coi ch-ơng 6). Phần về
các ph-ơng pháp nhận biết mô tả cách mà mỗi thành phần phát sinh,
từ dự án đ-ợc đánh dấu nhận biết duy nhất.

 An toàn, truy nhập hạn chế và phân loại nhằm phát triển an toàn các
sản phẩm nhạy cảm (nh- t- liệu phần mềm, bằng phát minh, thông tin
quân sự xếp hạng v.v...). Th-ờng thuận lợi là ủy thác nhiều những
nhiệm vụ đó cho kiểm tra cấu hình do nh- cầu phải tham gia vào việc
duyệt và phân loại t- liệu và các hoạt động khác liên quan gắn với an
toàn.

</div>
(123)<div class='page_container' data-page=123>

SCMP cũng có thể bao gồm những sơ đồ và biểu đồ để dịng chảy mơ
tả thủ tục đệ trình các yêu cầu thay đổi hay báo cáo vấn đề27.

Hình 7.3. giới thiệu một thí dụ về biểu đồ dịng chảy tổng quát kiểm
tra cấu hình mà tiêu chuẩn US DOD 2167A (DOD) 1988a gợi ý (so sánh
với dòng kiểm tra cấu hình mơ đun phần mềm trong h.7.1).

B¶ng 7.1. Thí dụ về nội dung kế hoạch quản lý cấu hình phần
mềm.

1. Tổ chức và nguồn quản lý cấu hình phần mềm
- Cơ cấu tổ chức

- Kh nng v trỡnh độ kỹ năng nhân sự
- Nguồn

2. Tiªu chn, thđ tơc, chính sách và h-ớng dẫn.
3. Nhận biết cấu hình

- Ph-ng pháp xác định SCCI
- Mô tả SCCI cho dự án này

4. Ph-ơng pháp nhận biết (định danh và đánh dấu t- liệu, cấu kiện
phần mềm, duyệt phát hành v.v...).

5. Đệ trình hạng mục cấu hình thủ tục chấp nhận / bác bỏ.
6. Kiểm tra thay đổi.

- Thủ tục kiểm tra thay đổi (ph-ơng pháp đệ trình duyệt, chấp
nhận và bác bỏ).

- Báo cáo t- liệu (yêu cầu thay đổi, báo cáo vấn đề)
- Thủ tục duyệt thay đổi và ban xột duyt

7. Kiểm tra phiên bản.

- Chuẩn bị phiên bản phần mềm và t- liệu
- Thủ tục chấp nhận phát hành.

8. L-u trữ, xử lý và cung cấp các kênh thông tin dự án
- Yêu cầu l-u trữ.

- Sao chép

9. Kiểm tra cấu hình của các chủ thầu phụ, ng-ời bán và ng-ời cung
cấp

10. Kiểm tra bổ sung

- Thủ tục kiÓm tra linh tinh

- Kiểm tra đặc biệt dự án (an tồn v.v...)
11. Báo cáo tình hình cấu hình

- KiĨm toán và duyệt cấu hình

- Thủ tục báo cáo tình hình cấu hình
12. Cột mốc chủ yếu quản lý cấu hình

13. Công cụ, kỹ thuật và ph-ơng pháp luận

</div>
(124)<div class='page_container' data-page=124>

7.1.4. Một số đ-ờng lối chung

Hình 7.3

Thớ d v l-ợc đồ một dịng điều khiển cấu hình.

Danh mục hoạt động mà kiểm tra cấu hình tiến hành cịn ch-a đạt tiêu
chuẩn là chức năng hỗ trợ quản lý dự án, phạm vi kiểm tra cấu hình bao
gồm nhiều hoạt động tùy chọn hay tuyển chọn. Do đó, với t- cách một
h-ớng dẫn cơ bản, nó hồn tồn có thể chấp nhận đ-ợc để gán cho quản
lý cấu hình trong phạm vi dự án chuyên đề, bất kỳ hoạt động nào liên
quan nh- phân bổ nguồn phát triển hay bố trớ v t chc cỏc trỡnh din

Không
Nâng cấp

phn mm

Thay i phần

mềm Các vấn đề

Phân tích và
-ớc định
ảnh h-ởng

Chuẩn bị đề xut thay i k
thut

Sỏp nhp s
thay i

Ban rà soát thiết kế
phần mềm

Ban điều khiển cấu hình
phần mềm
Có

ỏnh giỏ 
xut thay i

kỹ thuật

Cung cấp liên hệ
ng-ợc cho ng-ời

khởi đầu

Kiểm thử thay

i

Kết thóc
ChÊp thn
hay kh«ng?

L-u trữ thay
đổi

</div>
(125)<div class='page_container' data-page=125>

cho khách hàng. Cả hai thí dụ đó sử dụng thơng tin có đ-ợc cho ng-ời
quản lý cấu hình: cấu kiện sản phẩm no -c sn xut, khi no v do ai.

Đòi hỏi

thay đổi phần mềm

Sè : Trang:

Tên ng-ời khởi đầu: Điện thoại: Ngày:
Dự án: Hệ thống/Sản phẩm: Version:
Lý do thay đổi:

Mô tả thay i:

Ng-ời rà soát: Chữ ký: Ngày:

Ước l-ợng số công: Lịch thời gian: Lập lịch ảnh h-ởng:
Ng-ời chấp thuận dự

toán: Chữ ký: Ngày:

Có chấp thuận không

(có/không):

Tờn ng-i quyt nh: Ch ký: Ngày:

H×nh 7.4

Thí dụ biểu u cầu thay đổi phần mm

</div>
(126)<div class='page_container' data-page=126>

quản lý dự án vẫn là tranh chấp vĩnh cửu về các thỏa thuận miệng lý giải
sai hay hiÓu sai...

Kiểm tra thay đổi yếu là phổ biến trong việc gây nên tranh chấp giữa
khách hàng và ng-ời sản xuất. T-ơng tự nh- vậy việc kiểm tra phiên bản
yếu có thể là tai họa, đặc biệt khi khơng có hồ sơ về dị biệt giữa các
phiên bản.

Hình 7.4. cho 1 thí dụ về mẫu yêu cầu thay đổi. Mẫu này l-u giữ thay
đổi phần mềm từ lần đệ trình ban đầu, qua chấp nhận hay bác bỏ và cuối
cùng đến thực hiện và kiểm nghiệm (khi đ-ợc chấp nhận). Cần ghi nhớ
nhu cầu chữ ký; những mẫu này khơng thể l-u giữ bằng điện tử - bản gốc
có chữ ký phải đ-ợc l-u lại.

Sau đây là một số h-ớng dẫn bổ sung để quản lý cấu hình hiệu quả.
Một số những h-ớng dẫn này đồng thời áp dụng đ-ợc cho các chức năng
hỗ trợ quản lý khác.

- Quản lý cấu hình địi hỏi quyền hạn để có hiệu lực. Quyền hạn này
phải đ-ợc quản lý dự án giao cụ thể cho các kỹ s- có trách nhiệm. Bất cứ
kế hoạch quản lý cấu hình nào sẽ trở nên vô nghĩa nếu kế hoạch không
thể đ-ợc tôn trọng.

Tốt nhất nên tránh, bất cứ khi nào có thể, việc c-ỡng bức tơn trọng bất
cứ kế hoạch, chính sách hay tiêu chuẩn nào. Một trong những đức tính
của ng-ời quản lý tốt là khả năng vận dụng chính sách với c-ỡng bức tối
thiểu. Bất cứ khi nào các chính sách và tiêu chuẩn sẵn sàng đ-ợc ng-ời
sản xuất chấp nhận thì chúng càng đ-ợc tự nguyện tuân thủ và rất ít có
tr-ờng hợp bác bỏ vật liệu đệ trình. Điều này dẫn đến quá trình phát triển
hiệu quả hơn.

- Quản lý cấu hình phải đ-ợc thực hiện từ lúc khởi đầu dự án phần
mềm. Nhiều t- liệu chính thức đề xuất trong giai đoạn quan niệm ban đầu
là trọng yếu cho các giai đoạn yêu cầu và thiết kế và phải đ-ợc đặt trong
sự kiểm tra cấu hình.

Việc vận dụng sớm quản lý cấu hình là đặc biệt quan trọng trong các
mơ đen xốy ốc, lấy ngun mẫu nhanh hay các ph-ơng pháp luận phát
triển lặp lại. Những tiếp cận phát triển này khởi đầu tạo ra vô vàn phiên
bản của mỗi sản phẩm. Nhiều phiên bản khác nhau có thể trở thành ác
mộng cơng nghệ nếu khơng có kiểm tra cấu hình có trật tự.

- Đơi khi một số hoạt động kiểm tra cấu hình phần mềm có thể chồng
chéo với các hoạt động bảo hiểm chất l-ợng phần mềm. Trong những dự
án nhỏ, cả hai chức năng đó có thể giao cho một kỹ s- hỗ trợ duy hất.
Ngay trong những dự án lớn, đơi khi chức năng đó có thể do một nhóm
hỗ trợ duy nhất thực hiện.

</div>
(127)<div class='page_container' data-page=127>

triển tr-ớc đây trong dự án khác và đ-ợc thấy thích hợp để hịa nhập vào
dự án thơng th-ờng. Trong những tr-ờng hợp đó, hiếm khi lại có ý nghĩa
trong việc sửa đổi một sản phẩm hoàn chỉnh và hoạt động nhằm cho nó
đáp ứng với các tiêu chuẩn hành chính dự kiến để làm nó trở thành một
sản phẩm hoàn chỉnh và hoạt động đ-ợc.

7.2. Bảo đảm chất l-ợng phần mềm (SQA).

Chất l-ợng khó xác định đ-ợc đặc biệt khi vận dụng cho một hợp đồng
phát triển sản phẩm. Mặc dù không phải mọi phần mềm đ-ợc phát triển
theo hợp đồng, chất l-ợng vẫn là mối quan tâm đầu tiên của khách hàng
(và mọi dự án cuối cùng đều có khách hàng). Cơ quan tiêu chuẩn Anh
(1986) đã khẳng định "chất l-ợng nằm trong con mắt của ng-ời xem, một
đề tài phán xử của khách hàng".

Nếu đã có khó khăn trong việc tìm kiếm đ-ợc những định nghĩa chấp
nhận rộng rãi về thuật ngữ kiểm tra cấu hình thì về thuật ngữ bảo đảm
chất l-ợng phần mềm lại khó gấp đơi từ vựng tiêu chuẩn IEEE về thuật
ngữ cơng nghệ phần mềm (IEEE 1987b) có khơng ít hơn bốn định nghĩa
riêng biệt về chất l-ợng phần mềm28.

1. Tồn bộ khía cạnh và đặc điểm của một sản phẩm phần mềm có khả
năng đáp ứng nhu cầu đề ra: chẳng hạn thích hợp với các đặc điểm kỹ
thuật.

2. Mức độ mà phần mềm có đ-ợc sự phối hợp mong muốn của các
thuộc tính.

3. Mức độ mà khách hàng hay ng-ời dùng nhận thức là phần mềm đáp

ứng đ-ợc các kỳ vọng hợp thể của họ.

4. Các đặc điểm hợp thể của phần mềm xác định mức độ mà phần mềm
sử dụng sẽ đáp ứng đ-ợc các kỳ vọng của khách hàng. US DOD (1988b)
xác định chất l-ợng phần mềm lại đơn giản là:

5. Khả năng của sản phẩm phần mềm để đáp ứng những yêu cầu đặc
dụng của nó.

Chất l-ợng phải đ-ợc đo theo nghĩa kỳ vọng của khách hàng. Dù sao,
viễn cảnh của khách hàng là chủ quan. Phần này xét đến kiểm tra chất
l-ợng theo viễn cảnh của ng-ời quản lý dự án phải coi việc thực hiện
kiểm tra chất l-ợng là một quá trình khách quan, mang tớnh h thng.

7.2.1. Tạo ra phần mềm chất l-ỵng.

Nh- chúng ta đã thấy, một trong những vấn đề chính trong việc tạo ra
phần mềm chất l-ợng là sự khó khăn trong việc xác định mức độ chất
l-ợng trong phần mềm. Vì khơng có định nghĩa duy nhất nào chấp nhận
đ-ợc rộng rãi về chất l-ợng và vì những ng-ời khác nhau nhận thức chất

28tiêu chuẩn phát triển phần mềm, kể cả kiểm tra chất l-ợng phần mềm đ-ợc bàn đến chi tiết ở

</div>
(128)<div class='page_container' data-page=128>

l-ợng theo những cách khác nhau nên cả ng-ời sản xuất lần khách hàng
phải đạt đ-ợc thỏa thuận có đo đếm về chất l-ợng (điều này đ-ợc bàn đến
chi tiết hơn sau này). Ph-ơng pháp đo l-ờng chất l-ợng có thể khác nhau
đối với những dự án khác nhau.Vấn đề này đ-ợc bàn đến trong tham luận
của Wesselius và Ververs (1990) trong đó các ơng kết luận khơng thể đạt
đ-ợc tính khách quan trọn vẹn trong việc giám định chất l-ợng. Họ nhận
biết đ-ợc ba thành phần khác biệt của chất l-ợng:

- Thành phần giám định đ-ợc 1 cách khách quan
- Thành phần giám định đ-ợc chủ quan

- Thành phần không giám định đ-ợc.

Chất l-ợng một sản phẩm đánh giá đ-ợc khách quan khi các đặc điểm
của sản phẩm, nh- nêu trong các chi tiết yêu cầu, có thể nhận biết đ-ợc.

Chất l-ợng một sản phẩm đánh giá đ-ợc chủ quan khi các đặc điểm
của sản phẩm đáp ứng đ-ợc các kỳ vọng của khách hàng.

Chất l-ợng một sản phẩm không đánh giá đ-ợc khi nó tác động theo
các kỳ vọng của chúng ta trong những tình huống đã khơng dự kiến.

Wesselius và Ververs gợi ý là, để chất l-ợng của một sản phẩm phần
mềm đánh giá đ-ợc, càng nhiều đặc điểm càng tốt đ-ợc chuyển từ các
thành phần chủ quan và không đánh giá đ-ợc thành phần đánh giá đ-ợc.
Cơ bản, điều đó có nghĩa là chi tiết u cầu phải mơ tả càng nhiều đặc
điểm đo đếm đ-ợc của sản phẩm càng tốt.

Thí nghiệm hỗ trợ kết luận của Wesselius và Ververs. Những yêu cầu
xác định tồi bao giờ cùng là nguồn tranh chấp giữa nhà sản xuất và khách
hàng. Những yêu cầu xác định rõ, chi tiết và đo đ-ợc giảm thiểu các
tranh chấp và bất hòa khi phát triển của sản phẩm là trọn vẹn.

Dù sao, nhiều ph-ơng pháp phát triển có khoảng cách kéo dài giữa chi
tiết yêu cầu và giao sản phẩm (coi ch-ơng 4 bàn về chu kỳ phát triển của
phần mềm). Việc xác định chất l-ợng phải khơng đ-ợc trì hỗn đến khi
phát triển trọn vẹn. Việc kiểm tra chất l-ợng phần mềm có hiệu quả địi

hỏi có những đánh giá th-ờng xun suốt chu kỳ phát triển. Theo thế,
kiểm tra chất l-ợng có hiệu quả đi đôi với chi tiết yêu cầu tốt rõ ràng sẽ
tăng chất l-ợng của sản phẩm cuối cùng.

Việc thiết lập kiểm tra chất l-ợng có hiệu quả th-ờng vấp phải nhiều
quan niệm sai lệch và huyền thuyết, phổ biến nhất là cái gì liên quan đến
tính hiệu quả vốn đầu t- trong kiểm tra chất l-ợng. Cobb và Mills (1990)
liệt kê nhiều những huyền thuyết đó và gợi ý những ph-ơng pháp đã phá
chúng. Hai trong số nhiều huyền thuyết nổi trội mà Cobb và Mills đã xác
định đ-ợc mô tả nh- sau.

Huyền thuyết: chất l-ợng xứng với đồng tiền. Đây là một trong

</div>
(129)<div class='page_container' data-page=129>

Chất l-ợng tồi gieo rắc thất bại. Có một t-ơng quan tích cực giữa thất bại
và chi phí ở chỗ lại tốn kém hơn trong việc loại trừ thất bại thi công trong
phần mềm hơn là thiết kế phần mềm để loại trừ tht bi thi cụng.

Huyền thuyết: thất bại phần mềm là không tránh khỏi. Đây là một

trong nhng huyn thuyt ti tệ nhất vì điều khẳng định có phần nào thực
và do đó th-ờng đ-ợc sử dụng biện hộ cho phần mềm chất l-ợng tồi. Yêu
sách “bao giờ cũng có con rệp khác” không bao giờ đ-ợc là thông số
trong thiết kế hay thực hiện phần mềm cả.

Khi những huyền thuyết đó mất chỗ đứng trong những tiếp cận hiện
đại với phát triển phần mềm thì yêu cầu về các tiêu chuẩn và thủ tục thích
hợp về kiểm tra chất l-ợng lại gia tăng. IEEE đã đ-a ra tiêu chuẩn đầu
tiên của họ cho những kế hoạch bảo hiểm chất l-ợng phần mềm năm
1984 (IEEE 1984) tiếp theo là h-ớng dẫn chi tiết hỗ trợ tiêu chuẩn, công
bố năm 1986. Bộ Quốc phòng Hoa Kỳ đã đ-a ra tiêu chuẩn riêng biệt

2168 cho các ch-ơng tình chất l-ợng phần mềm của các hệ thống Quốc
phòng (DOD 1988b) tạo thành đồng hành cho tiêu chuẩn nổi tiếng US
DOD 2167A (DOD 1988a) cho việc phát triển phần mềm của các hệ
thống quốc phòng. Tiêu chuẩn Châu Âu IS0 9000-3 của năm 1990 (IS0
1990) đ-a ra một ý nghĩa rộng hơn cho từ bảo hiểm chất l-ợng và bao
gồm cả kiểm tra cấu hình nữa.

7.2.2. Ngn lùc kiĨm tra chÊt l-ỵng.

Khi ủy thác SQA bao gồm các hoạt động kiểm tra cấu hình, các nguồn
yêu cầu cũng bao gồm cả các nguồn yêu cầu cho kiểm tra cấu hình. Việc
hịa đồng SQA và kiểm tra cấu hình khơng phải khơng phổ biến và có thể
loại trừ một số ủy nhiệm và hoạt động phải nhân lên. Có hai biểu đồ tổ
chức xen kẽ đ-ợc mơ tả ở hình 7.5. Nên nhớ là với những dự án nhỏ, việc
hịa đồng hai nhóm đơn giản có thể có nghĩa là phó thác cả hai nhiệm vụ
cho cùng một ng-ời.

Mặc dù nhiều công cụ là phổ biến cả cho kiểm tra chất l-ợng và kiểm
tra cấu hình, chỉ có ít cơng cụ đ-ợc đặc biệt chỉ định cho kiểm tra chất
l-ợng. Sau đây là một số công cụ hỗ trợ chung có thể có ích trong việc hỗ
trợ các hoạt động của SQA:

- TiÖn Ých t- liÖu

- Công cụ thiết kế phần mềm

- Hỗ trợ tìm sai (Ch-ơng trình gỡ rối)
- Các bộ xử lý tr-ớc đ-ợc cấu thành
- Bộ so sánh hồ sơ

- Những bộ phân tích cơ cấu
- Những bộ kiểm toán tiêu chuẩn
- Những bộ mô phỏng

</div>
(130)<div class='page_container' data-page=130>

- Những bộ giám sát thực hiện
- Những công cụ hợp chất CASE
- Những bộ kích thích thử nghiệm

- Những bộ phát tr-ờng hợp thử nghiƯm.

Những cơng cụ đó hỗ trợ kiểm tra chất l-ợng trong mọi giai đoạn phát
triển phần mềm. Các bộ hỗ trợ t- liệu có thể cung cấp phần nào các bộ
viết t- liệu tự động, các bộ kiểm tra chính tả và các s-u tập chuyên ngành
(Thesaurus) v.v... các bộ xử lý tr-ợc đ-ợc cấu thành (nh- tiện ích UNIX
lint) có ích cả trong việc tiêu chuẩn hóa liệt kê mã lẫn cung cấp cảnh báo
bổ sung thời gian biên dịch mà các bộ biên dịch th-ờng bỏ qua. Những
cảnh báo sớm liên quan đến các vấn đề thời gian thực hiện có thể đ-ợc
các mơ phỏng, các bộ phân tích thời gian thực hiện và các bộ giám sát
thực hiện cung cấp. Thử nghiệm thấu đáo hệ thống phần mềm th-ờng có
thể đ-ợc tự động thực hiện nhờ các bộ phát hệ thử nghiệm và các bộ thực
hiện thử nghim t ng.

Hình 7.5

Kiểm tra cấu hình và kiểm tra chất l-ợng phần mềm

Mi cụng c SQA s dng trong phát triển phần mềm phải đ-ợc nhận
biết nguồn bản đảm chất l-ợng yêu cầu và chi tiết là các nguồn đó đ-ợc
vận dụng nh- thế nào. Theo thế, vào lúc khởi đầu dự án, các nguồn SQA

(a) Giám đốc dự án

Khống chế chất l-ợng phần mềm
Giám đốc và các kỹ s- quản lý

chÊt l-ỵng

Khống chế cấu hình
Giám đốc cấu hình
Các kỹ s- cấu hình

(b) Giám đốc dự án

Bảo đảm chất l-ng phn mm.
Giỏm c

Khống chế cấu hình
Các kỹ s- khống chế cấu

hình

Khống chế chất l-ợng phần
mềm

</div>
(131)<div class='page_container' data-page=131>

có thể đ-ợc tài trợ và cung cấp nh- là một phần của nguồn phát triển dự
án yêu cầu (coi ch-ơng 9).

7.2.3. Kế hoạch bảo đảm chất l-ợng phần mềm.

Kế hoạch bảo hiểm chất l-ợng phần mềm (SQAP), cũng nh- kế hoạch

cấu hình phần mềm, cũng là một bộ phận của kế hoạch phát triển tổng
thể dự án phần mềm. SQAP cung cấp t- liệu mà các nguồn cần, chúng
phải đ-ợc sử dụng thế nào và có những tiêu chuẩn và thủ tục nào sẽ đ-ợc
vận dụng trong dự án. Sau đó SQAP trở thành ủy thác cho nhóm bảo đảm
chất l-ợng trong phát triển dự án. Việc đề xuất kế hoạch này là trách
nhiệm của ng-ời quản lý dự án mặc dù trong những dự án lớn. Việc này
th-ờng đ-ợc giao cho ng-ời quản lý bảo đảm chất l-ợng. SQAP có thể
xuất hiện nh- là t- liệu riêng biệt hay bộ phận trong kế hoạch phát triển
dự án và có thể bao gồm kế hoạch quản lý cấu hình) nếu việc này đã
không đ-ợc cung cấp t- liệu riêng biệt.

Bảng 7.2. nêu danh mục các chủ đề chính có trong SQAP29. Khi một
trong những chủ đề đ-ợc đặt ở đâu khác nh- trong kế hoạch quản lý cấu
hình phần mềm (SCMP) thì nó có thể bỏ qua ở SQAP và đ-ợc thay bằng
con trỏ về t- liệu. Nói nó đ-ợc đặt. Dù sao, SCMP và SQAP đ-ợc quan
tâm ở nhiều khía cạnh khác nhau của hạng mục đ-ợc kiểm tra. SCMP lúc
đầu đ-ợc quan tâm ở kích th-ớc của hạng mục đ-ợc kiểm tra trong khi
SQAP lại tham gia nhiều hơn vào nội dung của các hạng mục đ-ợc kiểm
tra.

SQAP phải bao gồm các chủ thầu phụ, ng-ời bán hàng và ng-ời cung
cấp, bất kể các thực thể bên ngồi đó có hay khơng có tổ chức bảo đảm
chất l-ợng của chính chúng. Trong bất cứ dự án nào, chất l-ợng của các
thành phần bên ngoài rút cục là quan tâm của ng-ời quản lý dự án và tổ
chức SQA của anh ta. Khi một hệ thống thất bại thông th-ờng ít có khác
biệt là thất bại đó do thành phần phát triển bên ngoài hay thành phần phát
triển trong nội bộ. Các kế hoạch giám định các nhóm bên ngồi đó phải
thích nghi với loại thành phần bên ngồi đ-ợc cung cấp (ngoại bảng hay
phát triển mới) và loại tổ chức (liệu chúng có đ-ợc tổ chức bảo hiểm chất
l-ợng của chính chúng).

SQAP, coi nh- bộ phận của kế hoạch phát triển dự án, phải đ-ợc duyệt
lại và cập nhật định kỳ và bất cứ khi nào có những yêu cầu thủ tục phát
triển dự án, ph-ơng pháp luận hay các hoạt động khác liên quan nào đ-ợc
thay đổi. H-ớng dẫn SQAP của IEEE khuyên nên đánh giá định kỳ hai
khía cạnh của kế hoạch (1) nội dung của kế hoạch và (2) thực hiện kế
hoạch.

Nội dung của kế hoạch phải đ-ợc đánh giá có căn cứ ở tiêu chuẩn đặc
tr-ng SQAP sử dụng đảm bảo kế hoạch thích ứng tiếp tục với tiêu chuẩn
ngay dù những đặc điểm của dự án phần mềm có thay đổi.

29bảng 7.2 là h-ớng dẫn chứ khôngphải định nghĩa tiêu chuẩn. Các tiêu chuẩn phát triển phần mềm

</div>
(132)<div class='page_container' data-page=132>

Bảng 7.2 Thí dụ về nội dung của một kế hoạch bảo đảm
chất l-ợng phn mm (BCLPM).

1. Tổ chức và các nguồn lực BĐCLPM.

Cơ cÊu tæ chøc

Học vấn và mức độ thạo nghề của nhân sự

C¸c ngn lùc

2. C¸c chn, thđ tơc, chÝnh s¸ch, đ-ờng lối BĐCLPM.

3. Các yêu cầu t- liệu BĐCLPM.

Danh sỏch các chủ đề t- liệu để khống chế chất l-ợng.

Mô t ph-ng phỏp ỏnh giỏ v chp thun.

4. Các yêu cầu phần mềm BĐCLPM.

Đánh giá và chấp thuận phần mềm.

Mụ t ph-ng phỏp ỏnh giỏ.

Đánh giá tiến trình phát triển phần mềm.

Đánh giá phần mềm tái sử dụng.

Đánh giá phần mềm không phân phát đ-ợc.

5. Đánh giá việc l-u trữ, việc xử lý, và phân phát.

T- liệu dự án.

Phần mềm.

Các file dữ liệu.

6. Rà soát và kiểm toán.

7. Quản lý cấu hình phần mềm (khi không nhắm tới một t- liệu
chuyên biệt nào).

8. Bỏo cỏo cỏc vn khú khn v hnh ng chnh n.

9. Đánh giá các thủ tục thử nghiệm.

10. Công cụ, kỹ thuật và ph-ơng pháp.

11. Khống chế chất l-ợng của các chủ thầu phụ, ng-ời bán hàng và
cung cấp.

12. Khống chế phụ thêm

Các thủ tục không chÕ linh tinh.

Khống chế đặc thù dự án.

13. B¸o c¸o, ghi nhận và t- liệu BĐCLPM.

Thủ tục báo cáo tình trạng.

Bảo trì.

L-u trữ và an ninh.

Chu kỳ sở hữu.

</div>
(133)<div class='page_container' data-page=133>

- Yêu cầu mới hay thay đổi của hợp đồng
- Tiêu chuẩn và chính sách bổ sung

- Tµi liƯu dù ¸n bỉ sung

- Thay đổi trong cơ cấu tổ chức của dự án
- Cơng cụ và tiện ích mới

- Chủ thầu phụ và ng-ời bán bổ sung.

7.2.4. Độ đo chất l-ợng phần mềm.

ó cú nhiu quan tõm n cỏc câu hỏi liên quan đến việc đo l-ờng chất
l-ợng. Làm sao chúng ta có thể xác định mức độ mà sản phẩn phần mềm
có đ-ợc thuộc tính mơ hồ đó gọi là chất l-ợng? Khi nào chất l-ợng của
sản phẩm phần mềm là cao và khi nào là thấp?

Một trong những phát triển mới đây nhất trong việc bảo hiểm chất
l-ợng (không chỉ đối với phần mềm) là việc thấy rằng chất l-ợng khơng
phải là một thuộc tính nhị phân tồn tại hay không tồn tại. Kaposi và
Meyer (1990), trong một tham luận về bảo đảm chất l-ợng trên cơ sở đo
đếm, đã nói lên niềm tin của họ là bảo đảm chất l-ợng sản phẩm và qui
trình cơng nghệ phần mềm phải căn cứ ở đo đếm. Việc đo đếm chất
l-ợng càng sớm bắt đầu, các vấn đề càng sớm xác định. Cohen và cộng sự
(1986) khi nói đến kinh phí khắc phục sai lầm trong các giai đoạn đầu
của phát triển phần mềm đã đề x-ớng sự tồn tại của luật lũy thừa nổi
tiếng30.

Chất l-ợng của hai sản phẩm có thể so sánh đ-ợc và thực hồn tồn
chấp nhận đ-ợc khi nói là chất l-ợng một sản phẩm lớn hơn chất l-ợng
của sản phẩm kia. Cũng chấp nhận đ-ợc trong việc đo đếm và suy ra mức
độ khuyết tật dự kiến căn cứ trên kết quả đo đ-ợc.

Bộ trị số đo đ-ợc liên quan đến chất l-ợng sản phẩm đ-ợc coi là độ đo
chất l-ợng của sản phẩm, độ đo chất l-ợng phần mềm có thể đ-ợc dùng
xác định mức độ mà sản phẩm phần mềm đáp ứng yêu cầu. Việc sử dụng
độ đo chất l-ợng gia tăng tính khách quan trong việc đánh giá chất l-ợng

sản phẩm. Việc đánh giá chất l-ợng của con ng-ời là chủ quan và do đó
là nguồn gốc bất đồng có thể có, đặc biệt giữa khách hàng và ng-ời sản
xuất.

Một số ph-ơng pháp thiết lập độ đo chất l-ợng phần mềm th-ờng đ-ợc
phát triển mặc dù ch-a có tiêu chuẩn nào nói chung chấp nhận đ-ợc,
chẳng hạn, dự thảo ban đầu của IEEE Std 1061 (1990) bao gồm chi tiết
hệ chất l-ợng phần mềm nói chung kể cả ph-ơng pháp luận gợi ý về độ
đo vận dụng và nhiều thí dụ cùng h-ớng dẫn. Một khi đ-ợc xác định, độ
đo chất l-ợng thực vậy gia tăng tính khách quan nh-ng bản thân định
nghĩa lại không cần thiết khách quan và tùy thuộc lớn ở nhu cầu của tổ
chức đ-a ra định nghĩa.

Cách tiếp cận cơ bản để vận dụng độ đo chất l-ợng phần mềm địi hỏi:
30chi phí khắc phục sai lầm tăng theo lũy thừa khi phát phát triển phần mềm diễn tiến dọc chu kỳ

</div>
(134)<div class='page_container' data-page=134>

- Nhận biết mọi thuộc tính chất l-ợng phần mềm yêu cầu. Điều này
th-ờng xuất phát từ đặc điểm yêu cầu phần mềm.

- Xác định các trị số đo đ-ợc gắn với mỗi thuộc tính chất l-ợng
- Mơ tả ph-ơng pháp mà mỗi trị số đo đ-ợc sẽ đ-ợc đo đếm.

- Thñ tục cung cấp t- liệu về kết quả đo chất l-ợng của sản phẩm phần
mềm.

Mt b nhiu tr s cú thể đ-ợc sử dụng để xác định chất l-ợng tổng
thể của sản phẩm phần mềm. Dù sao, có thể tạo ra lần đo duy nhất biểu
thị chất l-ợng tổng thể của sản phẩm phần mềm. Điều này đòi hỏi:

- Ph-ơng pháp có cân nhắc trong việc kết hợp các thuộc tính chất

l-ợng đã đo đ-ợc thành lần đo duy nhất chất l-ợng cho sản phẩm.

Một số thí dụ của độ đo phần mềm là:

§é tin cËy tû lƯ thêi gian hệ thống đ-ợc vận hành có kết quả (thí dụ 23
trên 24 giờ tạo ra 100 x (23/24)%).

phc hi đ-ợc l-ợng thời gian mà hệ cần có để phục hồi sau thất
bại (thí dụ 1 giờ để nạp lại từ dự trữ và 30 phút để tái lập ban u h
thng).

Thân hữu của ng-ời dùng l-ợng thời gian huấn lun cÇn cho ng-êi
dïng míi.

Việc đo chất l-ợng phần mềm không đ-ợc thực hiện chỉ vào cuối dự
án. Mức độ chất l-ợng phải đ-ợc thực hiện chỉ vào cuối dự án. Mức độ
chất l-ợng phải đ-ợc đo với những khoảng cách đều đặn trong phát triển.
Do đó, mọi rút giảm trong việc đo chất l-ợng tổng thể phải đ-ợc coi
nh-cảnh báo cho mọi ng-ời quản lý dự án khiến phải có hành động hiệu
chỉnh. Chất l-ợng cao vào cuối dự án đ-ợc thực hiện khi đảm bảo chất
l-ợng cao xuyên suốt phát triển của dự án.

7.2.4. Mét sè ®-êng lèi chung

Các hoạt động bảo đảm chất l-ợng phần mềm cơ bản bao gồm việc
duyệt và phê chuẩn ph-ơng pháp luận phát triển, phần mềm và t- liệu
cùng giám định và phê chuẩn thử nghiệm.

Các hoạt động SQA khác nh- việc giám định duyệt lại, chọn lựa và phê
chuẩn công cụ phát triển hay quản trị kiểm tra cấu hình tùy thuộc ở cách

mà SQA đ-ợc thích ứng với dự án đặc tr-ng. Qui mô của dự án th-ờng là
yếu tố quyết định. Những h-ớng dẫn sau bàn đến một số thông số cần
xem xét cho các loại dự án khác nhau khi lập kế hoạch SQA.

- Trong những dự án nhỏ, có nhiều hoạt động SQA có thể do ng-ời
quản lý dự án thực hiện. Điều này bao gồm tổ chức và giám định duyệt
lại và kiểm toán, đánh giá và lựa chọn các công cụ phát triển, lựa chọn và
vận dụng các tiêu chuẩn.

</div>
(135)<div class='page_container' data-page=135>

các hoạt động thử nghiệm nào có thể đ-ợc ủy thác cho SQA tùy thuộc ở
nhiều yếu tố, kể cả sự độc lập của đội SQA, qui mô của dự án và tính
phức tạp của dự án (coi ch-ơng 6 bàn về tính phức tạp của các dự án).

Khi việc thử nghiệm đ-ợc đội thử nghiệm độc lập tiến hành thí dụ dính
líu của SQA sẽ là tối thiểu. Trong hầu hết các tr-ờng hợp khác, trách
nhiệm của đội SQA sẽ là lập kế hoạch và giám định thử nghiệm của hệ
thống.

- Về h-ớng dẫn chung, th-ờng không nên để một thành viên của đội
phát triển thực hiện SQA. Dù sao, các dự án nhỏ th-ờng khi khơng thể
xác minh chi phí của một kỹ s- đ-ợc bố trí SQA. Vấn đề này có thể đ-ợc
giải quyết khi có một kỹ s- SQA duy nhất chịu trách nhiệm cho hai hay
ba dự án nhỏ (với mỗi dự án tài trợ phần đóng góp của mình về dịch vụ
SQA).

Mét h-íng dÉn bỉ sung đ-ợc căn cứ trên các kết luận của Wesselius và
Ververs (1990) vỊ viƯc vËn dơng kiĨm tra chÊt l-ỵng cã hiƯu qu¶.

- Khả năng kiểm tra chất l-ợng phần mềm hiệu quả trực tiếp với chất
l-ợng của đặc điểm yêu cầu của phần mềm. Kiểm tra chất l-ợng đòi hỏi

chi tiết không mơ hồ của càng nhiều đặc điểm yêu cầu của chất l-ợng
phần mềm càng tốt.

7.3. Thư nghiƯm phÇn mỊm.

Từ thử nghiệm có nhiều nghĩa nh-ng trong sử dụng thơng th-ờng nhất
của nó từ đ-ợc vận dụng vào việc xem xét và đánh giá cái gì nhằm xác
định sự tồn tại của một số đặc tính. Trong thử nghiệm phần mềm, các đặc
tính đó gắn với các u cầu. Xác định tr-ớc của phần mềm. Thử nghiệm
phần mềm là q trình xác định mức độ theo đó phần mềm thỏa mãn
những yêu cầu đặc thù. Do đó, thử nghiệm phần mềm địi hỏi có chi tiết
u cầu phần mềm đã tr-ợc khi thử nghiệm, có thể đ-ợc tiến hành.

Nói một cách đơn giản, chúng ta không thể thử nghiệm phần mềm với
đầy đủ ý nghĩa nếu chúng ta không biết phần mềm đ-ợc dự kiến làm gì.

Thử nghiệm có thể do ng-ời lập trình, kỹ s- hợp nhất hay một nhóm
thử nghiệm độc lập thực hiện. Trong hầu hết tr-ờng hợp, phần mềm
không bao giờ do ng-ời lập trực tiếp chịu trách nhiệm viết mã đ-ợc thử
nghiệm lại thử nghiệm cả. Ng-ời lập trình hiếm khi lại khách quan đ-ợc
với chính mã của mình và thử nghiệm của anh ta sẽ khơng hiệu lực. Có
nhiều cách để tăng tính khách quan của thử nghiệm. Cách tốt nhất là sử
dụng nhóm thử nghiệm độc lập. Những ng-ời thử nghiệm độc lập là
những kỹ s- mà ủy thác chính của họ là phát triển các kế hoạch thử
nghiệm và các tr-ờng hợp thử nghiệm và thử nghiệm hệ thống một cách
khách quan và nghiêm ngặt đáp ứng đặc điểm yêu cầu.

7.3.1. Các loại thử nghiệm phần mềm.

</div>
(136)<div class='page_container' data-page=136>

án. Phần mềm phải đ-ợc thử nghiệm.ở mỗi giai đoạn của phát triển. Các

thử nghiệm phần mềm bao gồm:

- Th nghim n vị
- Thử nghiệm hợp nhất
- Thử nghiệm hệ thống phụ
- Thử nghiệm hệ thống
- Thử nghiệm suy thoái
- Thử nghiệm alpha
- Thử nghiệm bêta

- Thư nghiƯm nghiƯm thu

Thơng th-ờng tốt nhất là thử nghiệm mô đun phần mềm ngay sau khi
đ-ợc mã hóa. Đây là một trong số ít tr-ờng hợp mà các nhà lập trình thử
nghiệm mã của họ. Những thử nghiệm mô đun ban đầu, gọi là thử
nghiệm đơn vị, đ-ợc ng-ời lập trình tiến hành nhằm xác định xem chúng
có phù hợp với một bộ yêu cầu tối thiểu. Chúng bao gồm những thử
nghiệm nh-:

- NhËp vµ xuất (không có vòng vĩnh cửu) cho một bộ nhỏ cơ bản các
dữ liệu đầu vào.

- Vi u vo ó cho, đầu ra là hợp lý

- Những ch-ơng trình phụ đ-ợc gọi ra theo đúng trình tự. Điều này
đ-ợc thử nghiệm khi sử dụng các ngạch (vỏ hệ thống phụ rỗng).

Sau thử nghiệm đơn vị thành công, các mô đun đ-ợc đệ trình kiểm tra
cấu hình. Sau đó, chúng đ-ợc đ-a vào hợp nhất nơi chúng đ-ợc tập hợp
và thử nghiệm coi nh- bộ phận tuần tự các mô đun vào trong hệ thống.

Mọi tính chức năng bổ sung đ-ợc thử nghiệm, ở giai đoạn này, tính chức
năng thử nghiệm tr-ớc đây lại phải đ-ợc thử nghiệm đảm bảo không có
mơ đun mới nào phá hủy hệ thống. Điều này đ-ợc coi là thử nghiệm suy
thoái.

ở những hệ thống phần mềm lớn, các mơ đun tr-ớc hết có thể đ-ợc tập
hợp và hợp nhất với phần cứng thành những hệ thống phụ. Sau khi các hệ
thống phụ đã đ-ợc thử nghiệm riêng rẽ, chúng đ-ợc phối hợp thành một
hệ thống hoàn chỉnh.

</div>
(137)<div class='page_container' data-page=137>

Các giai đoạn cuối cùng của thử nghiệm hệ thống đ-ợc biểu thị trong
thí dụ sau một hệ thống thủ quỹ ngân hàng tự động đ-ợc phát triển cho
một ngân hàng lớn. Khi hệ thống phụ thủ quỹ đã hồn chỉnh, nó tiến
hành thử nghiệm hệ thống phụ để đảm bảo là các chi tiết thủ quỹ tự động
hoạt động tốt. Sau đó hệ thống phụ máy tính trung tâm đ-ợc thử nghiệm
về dữ liệu thử nghiệm đảm bảo hệ tiến hành dữ liệu đúng. Cuối cùng các
hệ thống phụ thông tin liên lạc đ-ợc thử nghiệm với thủ quỹ mô phỏng ở
một đầu và với máy tính trung tâm mơ phỏng ở đầu kia.

Rồi ba hệ thống phụ đ-ợc hợp nhất và việc thử nghiệm toàn bộ hệ
thống đ-ợc tiến hành đảm bảo thủ quỹ tự động và máy tính trung tâm liên
lạc và hoạt động tốt.

Sau khi thử nghiệm hệ thống, hệ thống thủ quỹ tự động hợp nhất hoàn
toàn đ-ợc thử nghiệm trong môi tr-ờng thử nghiệm alpha. Hệ thống đ-ợc
thử nghiệm với dữ liệu thử nghiệm thực tiễn và hoạt động của mọi chi tiết
đ-ợc xem xét và so sánh với các yêu cầu của hệ thống nhiệm vụ này đ-ợc
giao cho nhóm thử nghiệm độc lập.

Sau khi hệ thống thủ quỹ tự động đã qua thử nghiệm alpha, có vẻ đủ

tin cậy để có thể tiến hành dữ liệu thực. Đây là thử nghiệm bêta. Dù sao,
chỉ một trạm thủ quỹ tự động duy nhất đ-ợc đấu với máy tính của ngân
hàng và vận hành của hệ thống th-ờng xuyên đ-ợc các thành viên của đội
phát triển giám sát. Mọi vấn đề đ-ợc định vị và hiệu chỉnh ngay và thử
nghiệm bêta tiếp tục đến khi hệ thống thủ quỹ hoạt động không sai không
hỏng trong một thời gian xác định tr-ớc (thí dụ một tháng). Việc giám
định của giai đoạn bêta cũng đ-ợc ủy thác cho một nhóm thử nghiệm độc
lập.

Sau khi thực hiện thành công thử nghiệm bêta, hệ thống thủ quỹ b-ớc
vào thử nghiệm nghiệm thu cuối cùng. Các đại diện của bộ máy kỹ thuật
của ngân hàng giám định bộ thử nghiệm đ-ợc xác định tr-ớc và xác định
hay bác bỏ thành công của thử nghiệm nghiệm thu.

Theo thế, hệ thống thủ quỹ ngân hàng tự động đã qua mọi giai đoạn
thử nghiệm chủ yếu. Không phải tất cả những giai đoạn đó vận dụng
đ-ợc cho mọi dự án. Chẳng hạn, thử nghiệm alpha và bêta có thể vận
dụng cho các hệ thống th-ơng mại hay h-ớng về ng-ời dùng nh-ng
không cho sự phát triển phần mềm cho một vệ tinh thông tin liên lạc hay
ứng dụng quân sự. Một thí dụ khác là thử nghiệm hệ thống phụ rõ ràng
chỉ áp dụng đ-ợc khi hệ thống hiện nay đ-ợc phân thành các hệ thống
phụ.

Trong mọi tr-ờng hợp, thử nghiệm độc lập đ-ợc hết sức khuyên dùng
cho các giai đoạn thử nghiệm tiên tiến hơn (từ thử nghiệm hệ thống trở
đi). Thử nghiệm độc lập khách quan sẽ th-ờng định vị. Vấn đề sớm hơn
thử nghiệm độc lập mà các nhà sản xuất tiến hành nhiều. Đây là một lợi
ích chủ yếu cho dự án vì vấn đề đ-ợc định vị càng sớm thì lại ít tốn kém
hơn trong việc hiệu chỉnh.

</div>
(138)<div class='page_container' data-page=138>

Cã nhiÒu tiÕp cận và thủ tục khác nhau cho mỗi giai đoạn thử nghiệm
phần mềm. Điều quan trọng là chọn lựa tiếp cận thích hợp cho mỗi giai
đoạn. Các tiêu chuẩn thử nghiệm phần mềm chính thức31 bao gồm cả
h-ớng dẫn tiêu chuẩn đ-ợc vận dụng cho mỗi giai đoạn thế nào.

Tiờu chuẩn 2167 US (DOD 1988a) liên quan đến các giai đoạn cơ bản
sau:

1. Thử nghiệm đơn vị phần mềm của máy tính (CSU)

2. Thử nghiệm cấu kiện phần mềm của máy tính (CSC). Liên quan đến
việc thử nghiệm của nhóm CSC liên quan (coi hình 8.4).

3. Thư nghiƯm h¹ng mơc cấu hình phần mềm máy tính (CSCI). Đây là
giai đoạn tiên tiến của thử nghiệm hợp nhất ở những hệ thống nhỏ, điều
này t-ơng ứng với thử nghiệm hệ thống, và ở những hệ thống lớn có
nhiều CSCI, điều này t-ơng ứng với thử nghiệm hệ thống phụ.

4. Hợp nhất và thử nghiệm hệ thống. Điều này t-ơng ứng với thư
nghiƯm hƯ thèng tiªn tiÕn.

Mọi giai đoạn thử nghiệm phần mềm DOD có bảng tiêu chí đánh giá
kèm theo, mơ tả những yêu cầu đánh giá thử nghiệm. Điều này bao gồm
các tiêu chí nh- tính nhất quán nội bộ, tính thơng hiểu, tính theo dõi đ-ợc
qua dấu vết và đáp ứng u cầu. Sau đó những tiêu chí này đ-ợc đề ra cho
những hạng mục phải đánh giá nh- mã nguồn (và sau này là mã nguồn
cập nhật), các thủ tục và kết quả thử nghiệm.

Thđ tơc thư nghiƯm hiện nay đ-ợc cung cấp t- liệu nh- sau:

Kế hoạch thử nghiệm cung cấp t- liệu chính sách thử nghiệm tổng
quát cho dự án, ph-ơng pháp luận thử nghiệm đ-ợc sử dụng và các
nguồn yêu cầu.

Tả thử nghiệm bao gåm chi tiÕt vÒ:

- Thủ tục thử nghiệm cá thể, mơ tả cái gì cần thử nghiệm phải đ-ợc
tiến hành nh- thế nào, đầu vào sẽ là gì và đầu ra dự kiến phải là gì. Điều
này cũng mơ tả tiêu chí thơng qua khơng đạt cho mỗi thử nghim.

Các báo cáo thử nghiệm thông tin t- liệu về tiến hành thử nghiệm và
kết quả nhận đ-ợc.

Núi chung, mọi thủ tục thử nghiệm phần mềm chính thức đ-ợc căn cứ
ở 4 thành phần: qui hoạch thử nghiệm, mô tả thử nghiệm, tiến hành thử
nghiệm và báo cáo thử nghiệm. Hầu hết các tiêu chuẩn thử nghiệm hỗ trợ
các yếu tố đó và khác về mức độ chi tiết và thông tin t- liệu yêu cầu.

Tiêu chuẩn IEEE 829 (1987b) về thơng tin t- liệu thử nghiệm phần
mềm có mô tả chi tiết hơn nhiều về tiếp cận nên làm trong thử nghiệm
phần mềm, kể cả vơ vàn thí dụ và h-ớng dẫn sử dụng. Tiếp cận IEEE
31Các tiêu chuẩn phát triển phần mềm đ-ợc bàn đến ở ch-ơng 8 và các ph-ơng pháp luận phát triển

</div>
(139)<div class='page_container' data-page=139>

cũng bao gồm ba cấu kiện cơ bản: kế hoạch thử nghiệm, chi tiết thủ tục
thử nghiệm (t-ơng tự với mơ tả thử nghiệm DOD) và báo cáo tình hình
thử nghiệm (t-ơng tự báo cáo thử nghệm DOD). Coi các hình 8.5 và 8.6
về tổng thể mọi hoạt động thử nghiệm và t- liệu chính thức theo tiêu
chuẩn phát triển phần mềm IEEE. Các thủ tục thử nghiệm khơng hồn
tồn đ-ợc các tiêu chuẩn vận dụng xác định. Ph-ơng pháp và kỹ thuật thử
nghiệm hiện nay phải thích nghi với loại dự án đ-ợc phát triển và môi

tr-ờng dự án cùng cơng cụ có đ-ợc. Cộng thêm với lập kế hoạch và báo
cáo thử nghiệm, trách nhiệm của kỹ s- thử nghiệm (hay nhóm thử
nghiệm) là lựa chọn kỹ thuật thích hợp đ-ợc sử dụng trong thử nghiệm hệ
thống phần mềm. Thử nghiệm đặc tr-ng và kỹ thuật hợp nhất đ-ợc bàn
đến ở ch-ơng 4.

7.3.3. Mét sè ®-êng lèi chung

Trong bất cứ dự án phần mềm nào đều có giới hạn về cái gì có thể và
phải thử nghiệm. Nhiều thủ tục thử nghiệm là phức tạp và tốn kém một
cách không hợp lý. Điều quan trọng là sao phù hợp c-ờng độ thử nghiệm
với chi phí khuyết tật hệ thống không phát hiện. Hệ thống kiểm kê không
cần phải thử nghiệm ở mức độ nh- phần mềm đối với hệ thống hỗ trợ
công tác y tế.

Thử nghiệm quá mức cũng có thể sai lệch. Nhiều thủ tục thử nghiệm
địi hỏi thay đổi hệ thống đ-ợc thử nghiệm (thí dụ các giám sát viên trực
tuyến, những tiện ích dấu vết v.v...) hay sử dụng thiết bị thử nghiệm đặc
biệt. Điều này có thể có nghĩa là hệ thống đ-ợc thử nghiệm khơng phải là
hệ thống đ-ợc bàn giao.

Một cách nhìn thú vị về vấn đề này đ-ợc Laplante trình bày (1990)
trong bài báo liên hệ nguyên lý bất định (th-ờng áp dụng cho vật lý) của
Heisenberg vào việc thử nghiệm phần mềm32. Thuyết của Laplante khẳng
định là hệ thống phần mềm càng đ-ợc xem xét chặt chẽ bao nhiêu thì quá
trình xem xét càng tác động đến hệ thống đ-ợc thử nghiệm. Lý thuyết
này có thể đã gợi ý khơng trung thực nh-ng đã làm sáng tỏ thơng điệp cơ
bản:

Thư nghiệm quá mức có thể có hại cho hệ thống đ-ợc thử ba trong

những yêu cầu cơ bản thử nghiệm tốt là:

- Yêu cầu đ-ơc viết rõ
- Thủ tục thử nghiệm tốt

- Những ng-ời thử nghiệm có hiệu quả

Nhng yờu cầu tốt đ-ợc thảo luận ở các ch-ơng 4 và 8 nh-ng một
trong những điều kiện cơ bản để có đ-ợc yêu cầu tốt là phải thử nghiệm
32 Laplante gợi ý cơng thức sauzs = H trong đós biểu thị sự bất trắc của mã phần mềm.s sự

</div>
(140)<div class='page_container' data-page=140>

đ-ợc. Do đấy những u cầu chính thức ln phải đ-ợc viết với ý nghĩ
thử nghiệm trong trí. Đặc điểm có u cầu khơng thể thử nghiệm cũng
khơng thể tỏ ra tồn tại đ-ợc và do đó phải khơng có chỗ đứng trong chi
tiết yêu cầu chính thức cho dự án.

Những thủ tục chúng phải đ-ợc dựa trên tiếp cận gọi là thử nghiệm
tiêu cực. Điều này có nghĩa mục tiêu của nhóm thử nghiệm là chứng
minh những ng-ời sản xuất đã không làm tốt công việc. Nếu thử nghiệm
đ-ợc tiến hành đúng đắn thì khi những ng-ời thử nghiệm thất bại, dự án
thành công33. Những ng-ời thử nghiệm phải khơng đ-ợc dễ tính (ngun
văn lịch sự) vì cuối cùng những ng-ời dùng cũng có dễ tính đâu.

Nh- chúng ta thấy, thử nghiệm đ-ợc tiến hành tốt nhất khi có một
nhóm thử nghiệm độc lập, khách quan, dù sao chỉ có những dự án lớn có
thể hỗ trợ một nhóm thử nghiệm độc lập. Những dự án lớn có thể hỗ trợ
một nhóm thử nghiệm độc lập. Những dự án nhỏ có thể chia xẻ dịch vụ
của các nhóm thử nghiệm độc lập và thậm chí có thể th các kỹ s- phát
triển nhất là để thử nghiệm. Theo thế, kỹ s- phát triển trong một dự án có
thể là một ng-ời thử nghiệm khách quan kiêm nhiệm trong một dự án

khác.

Cuối cùng, thử nghiệm phải đ-ợc dẫn t- liệu đầy đủ. Một trong những
loại thử nghiệm tồi tệ nhất là thử nghiệm thất bại chẳng thể lặp lại. Nếu
thất bại khơng thể sẵn sàng lặp lại thì nó th-ờng khơng đ-ợc hiệu chỉnh.
Do đó t- liệu thử nghiệm phải đủ để ng-ời sản xuất có thể lặp lại phần
hiện t-ợng dẫn tới thử nghiệm thất bại.

7.4. Tãm t¾t.

Các nhóm hỗ trợ dự án không chỉ giảm nhẹ công việc hỗ trợ cho ng-ời
quản lý dự án và các kỹ s- phát triển, mà cịn thực hiện những cơngviệc
đó tốt hơn khi tập trung cố gắng của h ọ vào chức năng hỗ trợ đặc tr-ng.
Có nhiều loại chức năng hỗ trợ dự án. Dịch vụ th- ký, hỗ trợ hành chính,
xuất bản và cung cấp t- liệu là những thí dụ hỗ trợ khơng kỹ thuật, thử
nghiệm kiểm tra cấu hình, cơng nghệ hệ thống, quản lý hợp nhất và bảo
đảm chất l-ợng là những thí tụ về chức năng hỗ trợ kỹ thuật. Ba trong
những chức năng cơ bản cần có ở bất cứ dự án phát triển phần mềm nào
là:

- Kiểm tra cấu hình: quản lý thay đổi cho sản phẩm phần mềm đ-ợc
phát triển.

- Bảo đảm chất l-ợng: giám sát và kiểm tra chất l-ợng sản phẩm đ-ợc
phát triển.

- Thử nghiệm: thử đáp ứng với chi tiết yêu cầu chính thức của sản
phẩm.

Kế hoạch quản lý cấu hình phần mềm (SCMP) và kế hoạch bảo đảm

chất l-ợng phần mềm (SQAP) cung cấp t- liệu các nguồn cần cho mỗi

33điều này nhấn mạnh điểm quá - đơn giản, rõ ràng, có nhiều yếu tố khác cũng đóng góp vào sự

</div>
(141)<div class='page_container' data-page=141>

nhóm hỗ trợ, sử dụng các nguồn đó thế nào và có những tiêu chuẩn và thủ
tục nào sẽ đ-ợc vận dụng trong dự án. SCMP và SQAP trở thành ủy
nhiệm cho hai nhóm trong phát triển dự án. Thử nghiệm phần mềm là quá
trình xác định mức độ mà phần mềm thỏa mãn đ-ợc những yêu cầu cụ
thể. Những thủ tục thử nghiệm đ-ợc chuẩn bị nhằm chứng minh các yêu
cầu đ-ợc hoàn tất (hay khơng hồn tất). Do đó, chúng cần đ-ợc dựa trên
tiếp cận gọi là thử nghiệm tiêu cực. Điều này có nghĩa mục tiêu của nhóm
thử nghiệm là chứng tỏ rằng những ng-ời sản xuất đã không làm tốt công
việc. Nếu thử nghiệm đ-ợc tiến hành đúng đắn, thì khi những ng-ời thử
nghiệm thất bại, dự án là thành công.

Những nhóm thử nghiệm độc lập là những ng-ời thử nghiệm hệ thống
phần mềm đ-ợc chuộng hơn. Việc thử nghiệm độc lập khách quan sẽ
th-ờng định vị đ-ợc vấn đề sớm hơn các thử nghiệm chủ quan do những
ng-ời sản xuất thực hiện. Đây là lợi ích chủ yếu cho dự án vì vấn đề càng
sớm đ-ợc định vị bao nhiêu thì càng ít tốn kém hơn trong việc hiệu
chỉnh.

Đây là trách nhiệm của ng-ời quản lý dự án trong việc tổ chức các
nhóm hỗ trợ dự án và dẫn t- liệu các hoạt động theo kế hoạch của họ
trong ch-ơng trình phát triển dự án (bao gồm SCMP và SQAP). Các chức
năng hỗ trợ dự án đ-ợc lập kế hoạch tốt lúc khởi đầu dự án sẽ đóng góp
cho việc quản lý dự án có hiệu quả xuyên suốt dự án.

Bµi tËp.

1. Bạn đ-ợc chỉ định làm quản lý dự án phát triển hệ thống kiểm kê
cho một công ty sản xuất lớn. Hệ thống kiểm kê cần phát triển đ-ợc căn
cứ ở ph-ơng pháp đặt hàng sS (khi mức kiểm kê cho mỗi hạng mục tụt
xuống d-ới s thì l-ợng đ-ợc đặt sẽ nâng mức lên S: mỗi hạng mc cú tr
sú sS ca nú.

Gợi ý bốn phiên bản trung gian của hệ thống đ-ợc phát hành nội bộ
cho viƯc thư nghiƯm hƯ thèng. Thư nghiƯm alpha, thư nghiƯm bêta và
phát hành cuối cùng. Hỏi chênh lệch chức năng giữa mỗi phiên bản sẽ là
gì? Mô tả thủ tục kiểm tra phiên bản đ-ợc dùng và gợi ý mẫu mô tả phiên
bản.

2. L ng-i qun lý d ỏn, bn hãy xác định các tổ chức quản lý cấu
hình và bảo đảm chất l-ợng cho hệ thống kiểm kê mô tả ở bài tập 1, có
bao nhiêu ng-ời đ-ợc yêu cầu làm những nhiệm vụ này và trách nhiệm
của mỗi ng-ời ra sao? Giải thích quyết định của bạn.

</div>
(142)<div class='page_container' data-page=142>

4. Lập kế hoạch các giai đoạn thử nghiệm cho việc phát hành hệ thống
kiểm kê mô tả ở bài tập 1. Có những giai đoạn thử nghiệm nào mà bạn
gợi ý sau giai đoạn hợp nhất? Viết các ch-ơng trong kế hoạch thử nghiệm
mô tả mỗi một giai đoạn thử nghiệm đó. Có yêu cầu những nguồn nào và
dữ liệu thử nghiệm nào? ủy thác những ng-ời thử nghiệm cho mỗi giai
đoạn.

5. Hãy xác định năm thuộc tính chất l-ợng chủ yếu của hệ thống kiểm
kê mô tả trong bài tập 1 và xác định độ đo chất l-ợng cho những thuộc
tính đó. Giải thích lý do về độ đo mà bạn xác định.

6. Sử dụng mẫu yêu cầu thay đổi mơ tả trong hình 7.4, điền mọi đề
mục vào mẫu cho các thay đổi sau (1) một đặc điểm giám sát đơn đặt

đ-ợc bổ sung cho hạng mục ở d-ới mức 1 (2) mức sS cho mỗi hạng mục
đ-ợc bổ sung vào báo cáo kiểm kê (3) yêu cầu trả lời 6 giây cho một vấn
đề kiểm kê đã đ-ợc giãn ra tới 20 giây và (4) công suất yêu cầu của cơ sở
dữ liệu đã đ-ợc tăng từ 2000 tới 5000 hạng mục. Giải thích các vấn đề và
nhận định liên quan tới mỗi mẫu.

7. Bài học ở lớp: chia lớp thành 4 nhóm. Giao bài tập 6 cho mỗi nhóm.
Thảo luận chênh lệch giữa cách mỗi nhóm điền mẫu u cầu thay đổi (thí
dụ thảo lun khỏc bit v d toỏn).

</div>
(143)<div class='page_container' data-page=143>

Ch-ơng tám

Các tiêu chuẩn phát triển phần mềm

Cỏc tiờu chun phỏt trin: tai hại cần thiết

Với nhiều kỹ s- phần mềm, có mâu thuẫn giữa phát triển phần mềm và
tiêu chuẩn. Các tiêu chuẩn giới hạn phần lớn tự do của ng-ời sản xuất
phần mềm, vì tất nhiên, những tiêu chuẩn đó đ-ợc làm với mục đích
nh-thế. Các tiêu chuẩn đi kèm theo chu kỳ phát triển từ đầu đến cuối có
những tiêu chuẩn thiết kế, tiêu chuẩn t- liệu, tiêu chuẩn lập mã, tiêu
chuẩn thử nghiệm, và thậm chí tiêu chuẩn đệ trình và đánh giá đề nghị
(coi ch-ơng 3).

Mặc dù các tiêu chuẩn có thể đ-ợc coi là nỗi buồn cần thiết, việc vận
dụng các tiêu chuẩn đạt đ-ợc kết quả xứng đáng; điều đó làm cho việc
phát triển phần mềm dễ quản lý đ-ợc hơn. Điều này không có nghĩa là
chỉ có ng-ời quản lý có lợi trong việc sử dụng tiêu chuẩn. Các tiêu chuẩn
thúc đẩy mức độ ngăn nắp và thích nghi, giúp ng-ời sản xuất hiểu đ-ợc
cơng việc ng-ời khác làm và khuyến khích họ tạo ra công việc mà ng-ời
khác hiểu đ-ợc.

Một trong những thách đố chủ yếu cho ng-ời quản lý dự án là việc lựa
chọn tiêu chuẩn đúng. Trong nhiều tr-ờng hợp các chuẩn phát triển đ-ợc
đặc tả nh- là yêu cầu, nh- vẫn th-ờng xẩy ra với các dự án chính phủ. Dù
sao, ngay khi tiêu chuẩn đặc thù đ-ợc yêu cầu, nó vẫn phải đ-ợc “may
đo” phù hợp với yêu cầu của dự án đ-ợc phát triển. Một số phần của tiêu
chuẩn có thể bị "loại" nếu chúng khơng vận dụng đ-ợc ví nh- phân tích
thời gian theo thiết kế của một hệ thống không nghiêm ngặt về thời gian
hay việc đ-a ra những tiêu chuẩn lập mã cho mã ch-ơng trình đ-ợc tái sử
dụng.

Ch-ơng này cung cấp cho ng-ời quản lý dự án thông tin cơ bản về lựa
chọn một bộ tiêu chuẩn phát triển phần mềm thích hợp. Ch-ơng bàn đến
các loại tiêu chuẩn phần mềm và mô tả uy tín của hai tiêu chuẩn phổ biến
nhất: tiêu chuẩn công nghệ phần mềm IEEE và tiêu chuẩn 2167A ca B
Quc phũng Hoa K.

8.1 Tổng quan về các tiêu chuẩn phát triển phần
mềm.

T tiờu chun ó -c ng dng rộng rãi cho nhiều loại đ-ờng lối. Một
số tiêu chuẩn có thể hoạt động làm h-ớng dẫn, kỹ thuật gợi ý hay góp ý
phát triển hay qui mơ t- liệu. Những tiêu chuẩn khác có thể hoạt động
nh- là một bộ những định luật nghiêm ngặt chỉ đạo mọi khía cạnh hoạt
động phát triển. Hình 8.1 mơ tả các tiêu chuẩn phát triển phần mềm chính
và t-ơng quan giữa các tiêu chuẩn. Một trong những tiêu chuẩn phát triển

</div>
(144)<div class='page_container' data-page=144>

Hình 8. 1

Các chuẩn phát triển phần mềm chủ yÕu.

phần mềm dễ hiểu nhất là tiêu chuẩn US DOD 2167 (DOD 1988a). Việc
đề ra tiêu chuẩn tuyên bố lập ra những yêu cầu thống nhất cho phát triển
phần mềm vận dụng đ-ợc xuyên suốt chu kỳ cuộc đời của hệ thống và
tiêu chuẩn không nhằm nhấn mạnh hay khuyến bác việc sử dụng bất cứ

Địi hỏi đề xuất

§Ị xt

Kế hoch bo m

chất l-ợng Kế hoạch quản lý cấuhình

Đặc tả yêu cầu phần
mềm
Kế hoạch phát triển

dự án

c t thit k mc
nh

Kế hoạch thử nghiệm
Các chuẩn lập mÃ

Các thủ tục thử
nghiệm chấp thuận

Kế hoạch tích hợp

Đặc tả bảo trì

</div>
(145)<div class='page_container' data-page=145>

ph-ơng pháp phát triển phần mềm đặc biệt nào. Dù sao, tiêu chuẩn 2167
nặng nghiêng về ph-ơng pháp luận phát triển theo pha nh- hệ biến hóa
thác n-ớc. Overmyer (1990) trong một phân tích lý thú về tiêu chuẩn, báo
cáo là nhiều nhà nghiên cứu đã phát triển thành công những mơ hình phù
hợp với tiêu chuẩn trong khi đ-a ra những quan niệm mới về yêu cầu và
thiết kế lặp lại, mặc dù ông đã kết luận là 2167 không đ-ợc phát triển với
thiết kế lặp lại trong từ.

Với những ai tìm kiếm tiêu chuẩn ít địi hỏi hơn tiêu chuẩn 2167, các
tiêu chuẩn phát triển phần mềm IEEE đ-a ra tiếp cận t-ơng tự mềm dẻo
hơn nhiều. Nhiều những tiêu chuẩn IEEE tựa nh- những h-ớng dẫn hơn
là tiêu chuẩn cứng nhắc.

Các tiêu chuẩn dễ xác định và vận dụng cho các hoạt động phát triển
cơ bản dẫn t- liệu và lập mã) hơn là cho các qui trình phát triển
(nh-thiết kế, thử nghiệm và hợp nhất). Buckley trong nhập mơn của mình về
một trong những phiên bản sớm sủa34 của các tiêu chuẩn công nghệ phần
mềm IEEE giải thích ý định của IEEE đi từ tiêu chuẩn sản phẩm (thí dụ
một t- liệu) đến tiêu chuẩn quá trình. Trên thực tế, định nghĩa các tiêu
chuẩn cho quá trình thử nghiệm phần mềm đã là một trong những quá
trình, đầu tiên đ-ợc các tiêu chuẩn IEEE đề cập. Điều này phản ánh sự
bành tr-ớng của phạm vi tiêu chuẩn.

Buckley trông đợi những tiêu chuẩn t-ơng lai đáp ứng đ-ợc những lĩnh
vực mới nh- các hệ mét năng suất phần mềm. Nh-ng có một số điều dễ
tiêu chuẩn hóa hơn những điều khác và đề tài hệ mét năng suất là một
trong những đề tài khó hơn. Zimmer (1991) khẳng định vơi định nghĩa

"năng suất" khơng có tiêu chuẩn, thì rất khó mà biết đ-ợc phải đo cái gì,
lại càng ít có khả năng đo đ-ợc nó.

Thử nghiệm phần mềm là một lĩnh vực trong đó có nhiều tiêu chuẩn đã
đ-ợc tạo ra. Điều này cũng đúng của thiết kế phần mềm mặc dù đã có
nhấn mạnh nhiều đến cấu trúc của dẫn t- liệu thiết kế. Việc hợp nhất
phần mềm kết thúc ít thuận lợi hơn tr-ớc hết vì có khó khăn trong việc
tiêu chuẩn hóa nh- hoạt động loại bỏ trực giác.

Thử nghiệm không chỉ là lĩnh vực đã đ-ợc tiêu chuẩn hóa rộng. Thật
ngạc nhiên khi thấy việc tạo lập tiêu chuẩn cho một trong những hoạt
động phát triển phần mềm ít quyết định hơn lại phồn thịnh trong những
năm gần đây, cụ thể cho việc kiểm tra chất l-ợng phần mềm. Khó khăn
trong việc định nghĩa chất l-ợng phần mềmđ-ợc minh họa trong từ vựng
tiêu chuẩn IEEE về thuật ngữ công nghệ phần mềm (IEEE 1987b) có
khơng d-ới 4 định nghĩa riêng biệt:

1. Toàn bộ các nét và đặc điểm của sản phẩm phần mềm có trong khả
năng của nó đáp ứng các yêu cầu đề ra, chẳng hạn phù hợp với các đặc tả.
2. Mức độ mà phần mềm có đ-ợc sự phối hợp mong muốn về các
thuộc tính.

</div>
(146)<div class='page_container' data-page=146>

3. Mức độ mà khách hàng hay ng-ời dùng nhận thức đ-ợc là phần
mềm đáp ứng đ-ợc các kỳ vọng phức hợp.

4. Đặc điểm phức hợp của phần mềm xác định mức độ mà phần mềm
sử dụng đáp ứng những kỳ vọng của khách hàng.

Chất l-ợng phần mềm đ-ợc US DOD35định nghĩa lại đơn giản hơn là:
5. Khả năng của một sản phẩm phần mềm đáp ứng đ-ợc các yêu cầu

đặc thù của nó.

Trong khi các định nghĩa 1 và 2 có vẻ hơi tối nghĩa thì các định nghĩa
3; 4 và 5 là chủ quan và có vẻ gợi ý chất l-ợng, giống nh- cái đẹp, là ở
con mắt của ng-ời quan sát.

Chất l-ợng phần mềm không chỉ là từ có định nghĩa khơng phải là
chung nhất, điều này cũng đúng về những từ cơ bản nh- yêu cầu, thiết kế
và bảo trì. Cách mà những từ này đ-ợc sử dụng trong các tiêu chuẩn khác
nhau lại cũng thay đổi. Điều này th-ờng gây ra lẫn lộn khi cũng những từ
đó có nghĩa các điều khác nhau cho những ng-ời khác nhau.

Có nhiều lý do vì sao tiêu chuẩn lại khơng tiêu chuẩn và tính chủ quan
lại chính là 1 trong những lý do đó. Các dự án phần mềm thay đổi dữ, nhu
cầu của khách hàng thay đổi nhiều và các tổ chức phát triển phần mềm
cũng thay đổi lớn. Do đấy khơng ngạc nhiên là Bộ Quốc phịng Hoa Kỳ
khi công nhận dự án và nhu cầu thay đổi, đã cho phép may đo đáng kể
tiêu chuẩn 2167 phát triển phần mềm của các dự án.

Nhiều tiêu chuẩn phát triển phần mềm đã đ-ợc tạo lập đáp ứng các
hoạt động nh- đánh giá đề nghị (coi ch-ơng 3), rà sốt lại, kỹ thuật và
kiểm tra cấu hình. Giờ đây các tiêu chuẩn tồn tại mọi hoạt động phát triển
dự án chủ yếu.

Nhiều tiêu chuẩn phần mềm -a trội là thỏa mãn nếu đ-ợc vận dụng
đúng. Các tiêu chuẩn địi hỏi kỷ luật vốn khơng phải ln ln dễ dàng
buộc trong cơng nghệ phần mềm.

8. 2 Tiªu chn US DOD 2167.

Tiêu chuẩn 2167 đ-ợc Bộ Quốc phòng Hoa Kỳ tọa lập cho sự phát
triển của mọi hệ thống phần mềm quốc phịng sứ mệnh khẩn tr-ơng. Sau
khi cơng bố nhiều dự thảo và phiên bản ban đầu tiêu chuẩn đ-ợc đề xuất
năm 1985 thay thế tiêu chuẩn. Hải quân 1679A vốn sử dụng rộng rãi và
tiêu chuẩn 1644B MIL. ý định đã là năm 2167 trở thành tiêu chuẩn duy
nhất chính thức cho việc phát triển phần mềm của hệ thống quốc phòng
cho quân sự Hoa Kỳ.

Phiên bản đầu của tiêu chuẩn 2167 đã thu hút nhiều bình luận của các
nhà thầu phần mềm DOD và ngay trong nội bộ Bộ Quốc phịng. Điều này
dẫn đến việc cơng bố tiêu chuẩn DOD 2167A sửa đổi năm 1988 với các

35 Định nghĩa US DOD về chất l-ợng phần mềm xuất hiện trong tiêu chuẩn DOD 2168. Ch-ơng

</div>
(147)<div class='page_container' data-page=147>

tiờu chuẩn mới kèm theo 499 cho việc quản lý công nghệ và 2167 cho
việc bảo đảm chất l-ợng phần mềm.

8. 2. 1. Tỉng quan tiªu chn 2167.

Mục tiêu đ-ợc ấn định của tiêu chuẩn DOD 2167 (DOD 1988a) là thiết
lập những yêu cầu thống nhất cho việc phát triển phần mềm áp dụng đ-ợc
suốt cả chu kỳ đời của dự án. Tiêu chuẩn bao gồm việc vận dụng các tiêu
chuẩn kèm theo sau:

DOD-STD-480 Kiểm tra cấu hình - Thay đổi và từ bỏ cơng nghệ
MIL-STD-490 Thực hành đặc tả

MIL-STD-499 Qu¶n lý công nghệ

MIL-STD-1521 Rà soát lại và kiểm toán kỹ thuật cho các hệ thống,

thiết bị và phần mềm máy tính.

DOD-STD-2168 Ch-ơng trình chất l-ợng phần mềm hệ thống quốc
phòng.

MIL-STD-881 Cấu trúc phân tích công việc cho các hạng mục vật
liệu quốc phòng.

DID Mô tả hạng mục dữ liệu (DID đ-ợc phát âm hiệp vận
với kid)

Tiêu chuẩn 480 kiểm tra cấu hình mở rộng sang chỉ thị vô h-ớng dẫn
quản lý cấu hình nói chung xuất hiện ngay trong thân cđa t- liƯu 2167.

Các tiêu chuẩn 490 và 499 bao gồm các chỉ thị công nghệ chung cho
việc đặc tả và quản lý không đặc tr-ng cho phát triển phần mm.

Tiêu chuẩn 1521 mô tả rà soát lại và kiểm toán chính thức đ-ợc tiến
hành trong chu trình phát triển.

Tiờu chuẩn 881 mô tả yêu cầu DOD cho việc sản xuất và sử dụng kết
cấu phân tích cơng việc (WBS). Trong lần phát 2167A của tiêu chuẩn,
881 khơng cịn đ-ợc c t na.

Tiêu chuẩn 2168 (DOD 1988b) chứa các yêu cầu cho sự phát triển, dẫn
t- liệu và thực hiện ch-ơng trình phần mềm bao gồm việc lập kế hoạch và
tiến hành.

- Đánh giá chất l-ợng phần mềm.

- Dn t- liệu phối hợp và các hoạt động liên quan.

- Hoạt động tiếp theo cần thiết đảm bảo giải quyết vấn đề kịp thời và
có hiệu quả.

Các DID là một bộ t- liệu dễ hiểu bao gồm mọi pha của phát triển, bảo
trì phần mềm và xuất bản các cuốn tham khảo cho ng-ời dùng. Các DID
bao gồm một bộ phận gọi là h-ớng dẫn chuẩn bị tạo nên mức độ tự do
rộng rãi bằng cách cho phép lấy kích th-ớc t- liệu và sử dụng các ph-ơng
án về thể thức trình bày. Bộ DID đầy đủ đ-ợc mơ tả trong bng 8.1.

</div>
(148)<div class='page_container' data-page=148>

T- liệu phát triển

1. Kế hoạch phát triển phần mềm

Dẫn t- liệu hệ thống

2. Đặc tả đoạn/hệ thống

3. T- liệu thiết kế đoạn/hệ thống.

Thiết kế và yêu cầu phần mềm

4. Đặc tả yêu cầu phần mềm
5. T- liệu thiết kế phần mềm.

Thiết kế và yêu cầu giao diện

6. Đặc tả yêu cầu giao diện
7. T- liệu thiết kế giao diện.

Mô tả phiên bản

8. T- liệu mô tả phiê bản.

T- liệu thử nghiệm

9. Kế hoạch thử nghiệm phần mềm
10. Mô tả thử nghiệm phần mềm
11. Báo cáo thử nghiệm

Phát hành các sổ tay

12. Sổ tay ng-ời vận hành hệ thống máy tính
13. Sổ tay ng-ời dùng phần mềm

14. Sổ tay ng-ời lập trình phần mềm

15. Sổ tay hỗ trợ phần sụn (ch-ơng trình cơ sở).

T- liệu bảo trì và mÃ nguồn.

16. T- liệu hỗ trợ hợp nhất nguồn máy tính
17. Đặc tả sản phẩm phần mềm

Tiờu chun 2167 khẳng định khơng có ý định chi tiết hóa hay phản bác
việc sử dụng bất cứ ph-ơng pháp phát triển phần mềm đặc biệt nào (DOD
1988a). Dù sao, nh- nêu tr-ớc đây, tiêu chuẩn nặng nghiêng về các
ph-ơng pháp luận phát triển theo pha, nh- hệ biến hóa thác n-ớc. Tiếp
cận theo pha là cố hữu trong các pha phát triển có u cầu và các rà sốt

lại, địi hỏi việc thiết kế hệ thống đ-ợc tiếp nối nhờ những yêu cầu phần
mềm, thiết kế, thực hiện và thử nghiệm phần mềm. Tiêu chuẩn có mơ tả
tiếp cận đó, đ-ợc minh họa ở hình 8. 2.

Tiêu chuẩn cũng nêu các ph-ơng pháp luận thiêt kế khác có thể đ-ợc
dùng cùng với quan niệm chung 2167, nh- lấy nguyên mẫu nhanh vậy.
Nh-ng, nhiều ph-ơng pháp luận khác nhau về cơ bản nh- mơ hình xốy
ốc36 khơng dễ áp dụng cho tiêu chuẩn. Dù sao, Overmyer (1990) trong
bình luận về 2167, kêt luận là nói việc lấy kích th-ớc đầy đủ, 2167 có thể
đ-ợc vận dụng cho các ph-ơng pháp phát triển lặp lại. Việc lấy kích
th-ớc 2167 đ-ợc bàn đến sau trong phn ny.

36Mô hình xoắn ốc mà Boehm (1988) mô tả là mô thức hội tụ lặp lại rõ ràng khó thích nghi với tiêu

</div>
(149)<div class='page_container' data-page=149>

8. 2. 2. Rà soát lại và kiểm toán

R soỏt li v kiểm tốn là một trong những cơng cụ kiểm tra chủ yếu
xây dựng thành tiêu chuẩn 2167. Rà soát lại thành công th-ờng là tiêu đề
cho việc tiến hành sang pha phát triển sau. Theo thế rà sốt lại chính thức
xác nhận sự phê duyệt của khách hàng về công việc phát triển tr-ớc. Rà
sốt lại chính thức cũng th-ờng xuyên kèm theo cột mốc thanh toán chủ
yếu. Điều này trở thành sự kiện gay cấn cả cho khách và ch thu.

Các rà soát lại dự án phần mềm chính và quan hệ giữa các rà soát lại
đ-ợc nêu ở hình 8. 3.

Biên bản rà soát lại chính thức đ-ợc mô tả ở tiêu chuẩn MIL 1521 bao
gồm:

- T- liu và hạng mục phải duyệt lại

- Chỉ định chủ tọa vic r soỏt li

- Hạng mục phải trình bày và thảo luận
- Thủ tục phê chuẩn / không phê chuẩn
- Thđ tơc tiÕn hµnh hiƯu chØnh

Rà sốt lại dự án có ở nơi nào quyết định phát triển dự án chủ yếu đ-ợc
thông qua lần cuối. Những quyết định tới hạn đó đ-ợc dẫn trong t- liệu
đặc tả phát triển và đ-ợc coi là đ-ờng gốc37. Sau đó đ-ờng gốc trở thành
những nguồn tham khảo sơ khởi cho phát triển sau này của sản phẩm
phần mềm có ba đ-ờng gốc chủ yếu.

- Đ-ờng gốc chức năng đ-ợc đặt lúc rà sốt lại thiết kế hệ thống để
thơng qua lần cuối các yêu cầu chức năng của hệ thống (nghĩa là quan
điểm của ng-ời dùng về hệ thống).

- Đ-ờng gốc phân bổ đ-ợc đặt lúc rà soát lại đặc tả phần mềm để thông
qua lần cuối các yêu cầu phần mềm.

- Đ-ờng gốc sản phẩm, đ-ờng gốc này đ-ợc đặt lúc kết thúc cho kỳ
phát triển và thông qua lần cuối phát triển của sản phẩm phần mềm.

Đ-ờng gốc trung gian phụ có thể đ-ợc đặt lúc rà sốt lại thiết kế tới
hạn (CDR) để thông qua lần cuối thiết kế của sản phẩm phần mềm. Các
đ-ờng gốc trung gian khác có thể đ-ợc bổ sung để xác định kết thúc cỏc
hot ng phỏt trin quan trng.

8. 2. 3 Mô tả hạnh mục dữ liệu (các DID).

Cỏc mụ t hng mc dữ liệu xác định tiêu chuẩn t- liệu chính thức mô

tả hạnh mục dữ liệu yêu cầu phát sinh trong lúc phát triển phần mềm theo

</div>
(150)<div class='page_container' data-page=150>

H×nh 8. 2

</div>
(151)<div class='page_container' data-page=151>

H×nh 8. 2

</div>
(152)<div class='page_container' data-page=152>

H×nh 8. 3.

Thí dụ rà soát lại và kiểm toán DOD (từ DOD Std 2167A).

</div>
(153)<div class='page_container' data-page=153>

153

t- liệu riêng biệt các CSCI th-ờng xuyên đ-ợc duyệt lại và phê chuẩn coi
nhẹ hạng mục phát triển riêng rẽ và mặc dù việc duyệt lại hay kiểm tốn
đơn thuần có thể xem xét hơn một CSCI, mỗi một lại th-ờng đ-ợc đề cập
riêng rẽ trong q trình duyệt lại. Khơng có h-ớng dẫn nào thật sự rõ
ràng trong việc phân chia hệ thống phần mềm thành các CSCI vì sự phân
chia chủ yếu là một trong các thuận lợi nh-ng nói chung các ph-ơng
pháp sử dụng t-ơng tự nh- những kỹ thuật phân tích cấp cao mơ tả ở
ch-ơng 6. Hình 8. 4 giới thiệu thí dụ phân tích hệ thống thành các CSCI
và các CSU cấp thấp, theo tiêu chuẩn 2167A.

B¶ng 8. 2 có danh mục các DID tham chiếu theo tiêu chuẩn 2167A,
chất l-ợng phần mềm DID đ-ợc tham chiếu riêng rẽ trong tiêu chuẩn
2168 ch-ơng trình chất l-ợng phần mềm DOD.

Bảng 8. 2. Tiêu chuẩn mô tả hạng mục dữ liệu DOD

Tên gọi yêu cầu dữ liệu Bí danh

1. T- liệu thiết kế đoạn hệ thống SSDD
2. Kế hoạch phát triển phần mềm SOP

3. Đặc tả yêu cầu phần mềm SRS

4. Đặc tả yêu cầu giao diện IRS

5. T- liệu thiÕt kÕ giao diƯn IDD

6. T- liƯu thiÕt kÕ phÇn mềm SDD

7. Đặc tả sản phẩm phần mềm SPS

8. T- liệu mô tả phiên bản VDD

9. Kế hoạch thử nghiệm phần mềm STP

10. Mô tả thử nghiệm phần mềm STD

11. Báo cáo thử nghiệm phần mềm STR
12. Sổ tay vận hành hệ thống máy tính CSOM

13. Sổ tay ng-ời dùng phần mềm SUM

14. Sổ tay lập trình phần mềm SPM

15. Sổ tay hỗ trợ phần sụn FSM

16. T- liệu hỗ trợ nhất nguồn máy tính CRISD

17. ngh thay i cơng nghệ ECP

18. Ghi chú thay đổi đặc tả SCN

HƯ thống

1 phần 1 phần

</div>
(154)<div class='page_container' data-page=154>

-Hình 8. 4

Một thí dụ về phân giải hệ thống DOD 2167 (từ DOD- Std- 2167A)

Mäi kÝch th-íc t- liƯu DID theo cïng khu«n mẫu t-ơng tự. Rất nhiều
phần cứng chung nhất nh- hầu hết, nếu không phải tất cả t- liệu, ví nh-:

- Kích th-ớc trang bìa
- Bảng mục lục

- Phạm vi (kể c¶ nhËn biÕt tỉng quan tham chiÕu v. v. . . )
- Các t- liệu khác vận dụng đ-ợc

- Ghi chó vµ phơ lơc.

CSCI IRS HWCI

CSCI

HWCI

IRS HWCI HWCI HWCI

CSCI IRS

CSC CSC CSC

CSC CSC CSC CSC CSC CSC CSC

CSU

CSU
CSU

CSC
CSC

CSU
CSU

CSC
CSC

CSU

CSU
CSU

CSC
CSC

CSU CSU
CSU

**

**Cïng CSU do các CSC khác nhau sử dụng

*

*Phần mềm không phát triĨn

</div>
(155)<div class='page_container' data-page=155>

Cũng vậy, kích th-ớc trang, sơ đồ đánh số trang, sơ đồ đánh số phần và
nhiều h-ớng dẫn chuẩn bị khác là chung nhất. Điều này rõ ràng gợi ý
việc sử dụng công cụ tự động hỗ trợ trong việc chuẩn bị t- liệu, một thời
gian rất đ-ợc khuyến khích trong tiêu chuẩn 2167. Nhiều cơng cụ nh- thế
đã đ-ợc phát triển để hỗ trợ 2167 và Polack, trong một tham luận phân
tích việc sử dụng các công cụ CASE cho các dự án DOD (Polack 1990),
kết luận là những công cụ này thực tế tiết kiệm thời gian và dẫn đến hệ
thống phần mềm chất l-ợng cao38.

Mỗi DID mô tả những yêu cầu trong việc chuẩn bị t- liệu đặc thù
nh-ng cần nhấn mạnh chính đến nội dung u cầu chứ khơng phải kích

th-ớc u cầu. Điều này đặc biệt đ-ợc đề cập đến trong việc chuẩn bị các
h-ớng dẫn kèm theo mỗi DID khẳng định là các kiểu trình bày khác, kể
cả biểu đồ, bảng hay ma trận, là chấp nhận đ-ợc (thí dụ Hartley và
Pirbhai 1988 - hay Ward và Mellor - 1986). Cũng có sự mềm mỏng có
thực trong các yêu cầu xét về nội dung t- liệu. Tiêu chuẩn tạo cho việc
lấy kích th-ớc nhiều, thích ứng tiêu chuẩn với loại dự án đ-ợc phát triển.

8. 2. 4. LÊy kÝch th-íc tiªu chn.

Lấy kích th-ớc tiêu chuẩn 2167 khơng chỉ là khuyến khích mà cịn là
u cầu. Lời nói đầu cho 2167 khẳng định tiêu chuẩn phải đ-ợc ng-ời
quản lý ch-ơng trình lấy kích th-ớc thích hợp đảm bảo chỉ những yêu cầu
có hiệu quả về kinh phí đ-ợc nêu trong các yêu cầu và hợp đồng quốc
phòng.

DOD đã xây dựng h-ớng dẫn lấy kích th-ớc có thể đ-ợc dùng làm
nguồn tham khảo thích nghi các tiêu chuẩn với loại dự án đ-ợc phát
triển39Có hai nguyên tắc cơ bản vận dụng cho vic ly kớch th-c:

- Quá tình lấy kích th-ớc là xóa đi những yêu cầu không vận dụng
đ-ợc.

- Ly kớch th-ớc tiêu chuẩn phải do cơng ty có hợp đồng tiến hành.
Nguyên tắc đầu tiên có nghĩa những sửa đổi đó chỉ có thể bao gồm.
Việc xóa bỏ đi các yêu cầu khỏi tiêu chuẩn (và không phải là những thay
đổi yêu cầu trong tiêu chuẩn). Nguyên tắc thứ hai có nghĩa là chủ thầu
(nghĩa là ng-ời sản xuất) khơng thể lấy kích th-ớc tiêu chuẩn mà khơng
đ-ợc phép của cơng ty có hợp đồng (nghĩa là DOD).

Việc lấy kích th-ớc tiêu chuẩn 2167 phải đ-ợc hoàn tất càng sớm càng

tốt. Điều này đ-ợc thực hiện tốt nhất hoặc trong các h-ớng thuyết hợp
đồng hoặc là một trong những sáng kiến ban đầu ngay khi dự án bắt đầu.

38Teamwork - cơng việc đồng đội- của Cadre là một thí dụ về công cụ CASE hỗ trợ tiêu chuẩn 2167
39h-ớng dẫn lấy kích th-ớc có thể tìm thấy ở DOD- HDBK 248. H-ớng dẫn vận dụng và lấy kích

</div>
(156)<div class='page_container' data-page=156>

Sau đây là mô tả thủ tục cơ bản trong việc lấy kích th-ớc tiêu chuẩn
2167.

1. Rà soát lại các yêu cầu tiêu chuẩn 2167 bao gồm:
- Rà soát lại và kiểm toán

- Dẫn t- liệu

- Hot ng th nghim

- Hoạt động bảo đảm chất l-ợng
- Hoạt động kiểm tra cấu hình

- Các hoạt động phát triển khác có u cu.

2. Nhận biết các yêu cầu không vận dụng, xác minh hay lý giải đ-ợc
cho dự án đ-ợc phát triển. Chẳng hạn, sổ tay hỗ trợ phần sụn, sẽ không
đ-ợc yêu cầu nếu không có phần sụn đ-ợc phát triển hay hai rà soát lại
thiết kế (PDR và CDR) có thể là không cần thiết cho một dự án nhỏ.

3. Chuẩn bị danh mục yêu cầu xóa bỏ ở tiêu chuẩn. Điều này có thể
bao gồm:

- Loi tr t- liu

- Loại trừ hoạt động

- Loại trừ các đoạn trong t- liệu
- Loại trừ các phần hoạt động.

4. Chuẩn bị mô tả viết các chỉnh trang cho mỗi hạng mục có yờu cu
ly kớch th-c.

5. Đề xuất yêu cầu lấy kích th-ớc, cùng với chỉnh trang, càng sớm
càng tốt (nên tr-ớc khi dự án bắt đầu).

Nhm cú kh nng phõn hóa giữa các hạng mục bỏ quên và các hạng
mục lấy kích th-ớc, nên các hạng mục lấy kích th-ớc phải đ-ợc có tham
chiếu rõ ràng. Khi trình danh sách t- liệu để rà sốt lại chính thức hay
làm đ-ờng mốc, mọi t- liệu đã lấy kích th-ớc phải đ-ợc lên danh sách
cùng với xác nhận hiệu qủa của nó. Trong phạm vi một t- liệu, khi đoạn
đ-ợc lấy kích th-ớc rồi, xác nhận về hiệu quả đó sẽ trực tiếp xuất hiện
sau số của đoạn. Nếu một đoạn và mọi đoạn phụ của nó đã đ-ợc lấy kích
th-ớc, chỉ có số của đoạn cấp cao nhất cần đ-ợc đ-a vào.

Danh mục các DID cùng với danh mục các phê chuẩn lấy kích th-ớc là
một bộ phận hợp nhất của những thứ giao đ-ợc của dự án. Cho đến khi đã
có đ-ợc tiếp cận lấy kích th-ớc, ng-ời sản xuất buộc phải cung cấp danh
sách đầy đủ các DID cùng với mọi tạp chất của chúng. Đây là lý do vì sao
việc lấy kích th-ớc phải đ-ợc kết thúc càng sm cng tt.

8.2.5. Lợi và bất lợi của tiêu chuẩn 2167.

</div>
(157)<div class='page_container' data-page=157>

t-cho việc sản sinh t- liệu. Sau đó, thời gian phụ lại cần đầu t- để giữ t-cho
các t- liệu th-ờng xuyên đ-ợc cập nhật.

Những lời phê phán tiêu chuẩn (coi Polack 1990) bao gồm khiểu nại là
tiêu chuẩn ngăn việc sử dụng thực hành phát triển phần mềm hiện đại
nh-lấy nguyên mẫu nhanh và tái sử dụng phần mềm. Nh- chúng ta thấy,
những ph-ơng pháp này có thể đ-ợc vận dụng cho 2167 mặc dù chúng có
thể thích hợp một cách tự nhiên vào tiếp cận chung của tiêu chuẩn (coi
Oierwyer 1990).

Tiêu chuẩn không dễ dàng, vận dụng đ-ợc cho các dự án quá nhỏ vì nó
địi hỏi lấy kích th-ớc cơ bản nhằm giảm cơng việc hành chính ở mức độ
thỏa đáng. Mặt khác, những dự án rất lớn lại có thể có lợi rất lớn ở tiêu
chuẩn vì nó làm cho dự án dễ quản lý hơn và các hoạt động phát triển rõ
ràng hơn.

Tiêu chuẩn 2167 cung cấp cho khách hàng tầm nhìn, đáng kể trong
mọi pha phát triển chủ yếu. Điều này có thể tăng thêm xác suất thỏa mãn
của khách hàng về sản phẩm cuối cùng. Dù sao tất cả mọi điều đó có giá
của nó. Việc kiểm tra, dẫn t- liệu và báo cáo địi hỏi phải có những
nguồn chủ yếu và những nguồn này làm tăng kinh phí cố gắng phát triển.

Một trong những lợi ích chính của 2167 là cơng tác tiêu chuẩn hóa
tuyệt hảo. Nó là một trong những bộ tiêu chuẩn dễ hiểu nhất tồn tại cho
việc phát triển phần mềm và cung cấp yêu cầu đặc tr-ng rõ ràng để kiểm
tra đ-ợc hầu hết các hoạt động phát triển phần mềm.

Đây không phải là sự lựa chọn của ng-ời sản xuất, vì có ít ng-ời sản
xuất sẵn sàng chọn 2167 đâu. Đây là sự lựa chọn của khách hàng và nó
hỗ trợ kiểm tra quá trình phát triển theo viễn cảnh của khách hàng. Theo
viễn cảnh của ng-ời sản xuất, 2167 tạo ra một bộ yêu cầu rõ ràng loại bỏ
đ-ợc nhiều điều mơ hồ và tối nghĩa dẫn đến các tranh chấp giữa ng-i

sn xut vi khỏch hng.

8.3. Các tiêu chuẩn công nghệ phÇn mỊm IEEE.

Năm 1984, viện các kỹ s- điện và điện tử (IEEE) công bố bộ tiêu
chuẩn công nghệ phần mềm đầu tiên của mình (IEEE 1988). Bộ này bao
gồm bốn tiêu chuẩn phát triển bao gồm các yêu cầu bảo đảm chất l-ợng,
thử nghiệm và quản lý cấu hình và từ vựng tiêu chuẩn thứ năm bao mong
đợi về các từ cơng nghệ phần mềm.

</div>
(158)<div class='page_container' data-page=158>

8.3.1. Tỉng quan các tiêu chuẩn IEEE.

Năm 1987, IEEE xuất bản một bộ các tiêu chuẩn phát triển phần mềm
bao gồm:

1. ANSI/ IEEE Std 729- 1983

Tõ vùng tiªu chn IEEE vỊ tht ngữ công nghệ phần mềm
2. ANSI / IEEE Std 730- 1984

Tiêu chuẩn IEEE về các kế hoạch bảo đảm chất l-ợng phần mềm
3. ANSI / IEEE Std 828 - 1983

Tiªu chuẩn IEEE về kế hoạch quản lý cấu hình phần mỊm
4. ANSI / IEEE Std 829 - 1983

Tiªu chn IEEE vỊ t- liƯu thư nghiƯm phÇn mỊm
5. ANSI / IEEE Std 830 - 1984

H-ớng dẫn IEEE về các đặc điểm yêu cầu phần mềm

6. ANSI / IEEE Std 983- 1986

H-ớng dẫn IEEE về qui hoạch bảo đảm chất l-ợng phần mềm
7. IEEE Std 990 - 1986

Thùc hµnh IEEE vỊ Ada coi nh- ngôn ngữ thiết kế ch-ơng trình
8. IEEE Std 1002 - 1987

Nhân loại học tiêu chuẩn IEEE về các tiêu chuẩn công nghệ phần mềm
9. ANSI / IEEE Std 1088 - 1987

Tiêu chuẩn IEEE về thử nghiệm đơn vị phần mềm
10. ANSI / IEEE. . . 1912 - 1986

Tiªu chuẩn IEEE về các kế hoạch kiểm tra và hiệu lực phần mềm
11. IEEE Std 1016 - 1987

Thực hành IEEE về mô tả thiết kế phần mềm.

Vo lỳc cụng b 11 tiêu chuẩn đó, IEEE đã có 12 dự án khác tiến triển
bao gồm các tiêu chuẩn về rà soát lại và kiểm toán phần mềm, các kế
hoạch quản lý dự án phần mềm và các kế hoạch bảo trì phần mềm cũng
nh- các h-ớng dẫn công nghệ phần mềm40.

ý đồ rõ rệt của các tiêu chuẩn IEEE là chuyển ph-ơng pháp luận phát
triển cho ng-ời sản xuất. Các tiêu chuẩn dễ khớp với tiếp cận thác n-ớc
từng pha mặc dù cũng có thể đ-ợc thích nghi với các ph-ơng pháp khác
nh- lấy nguyên mẫu nhanh và mô thức xoắn ốc. Tiêu chuẩn 930 của các
yêu cầu phần mềm là một thí dụ tuyệt vời về t- liệu tiến triển tốt v-ợt quá
chức năng cơ bản của tiêu chuẩn. Điều đó nói lên ý đồ h-ớng dẫn ng-ời

dùng về việc phát triển "đặc tr-ng yêu cầu phần mềm tốt". Chẳng hạn
tiêu chuẩn liệt kê các đặc điểm cơ bản của một SSS tốt nh-:

- Không mơ hồ
- Sửa đ-ợc
- Đầy

- Theo dõi đ-ợc

40 Jolm Horch trong mở đầu bản in 1987 về các tiêu chuẩn IEEE (IEEE 1987b) báo cáo là IEEE

</div>
(159)<div class='page_container' data-page=159>

- Thử đ-ợc
- Nhất quán

- Sử dụng đ-ợc trong pha vận hành và bảo d-ỡng.

Sau đó, danh mục này có thể đ-ợc dùng làm danh mục kiểm tra41 để
đánh giá những đặc điểm yêu cầu theo cách sau:

1. Liệu mỗi yêu cầu có rõ ràng và có cùng cách lý giải cho mọi ng-ời
đọc nó ? (khơng mơ hồ).

2. Liệu mọi u cầu có t- liệu đầy đủ, liệu chúng ta đã đảm bảo không
tồn tại mọi việc hiểu "miệng" (thuyết khẩu) ? (đầy đủ)

3. Liệu chúng ta có thể chứng minh một cách hợp lý với chi phí hợp lý
là mỗi yêu cầu đã -c ỏp ng (th -c) ?

4. Liệu có yêu cầu nào mâu thuẫn với yêu cầu khác ? (nhất quán)

5. Liệu đặc điểm yêu cầu đã đ-ợc dẫn t- liệu theo cách làm cho dễ
dàng hiệu chỉnh hay thay đổi sau ny -c khụng ? (sa -c).

6. Liệu những nguyên nhân của mỗi yêu cầu có rõ ràng (theo dõi
ng-ợc lại) và t- liệu thiết kế và thử nghiệm sau này có thể theo dõi ở các
yêu cầu? (theo dõi tiÕp diÔn).

7. Liệu đặc điểm yêu cầu đã đ-ợc viết sao cho khơng chỉ tổ chức viết
ra nó hiểu đ-ợc mà cả tổ chức bảo trì phần mềm nữa (sử dụng đ-ợc).

Các tiêu chuẩn khác của IEEE cũng bao gồm nhiều h-ớng dẫn và thí
dụ. Tiêu chuẩn thiết kế phần mềm đ-ợc mô tả nh- là một bộ các thực
hành nên làm trong việc mô tả thiết kế. Tiêu chuẩn bao gồm một phác đề
mẫu cho t- liệu đặc điểm thiết kế cũng nh- những góp ý về nội dung mỗi
mục.

Việc thử nghiệm đã có đ-ợc sự chú ý đáng kể trong các tiêu chuẩn
IEEE. Tiêu chuẩn 829 bao gồm việc chuẩn bị t- liệu thử nghiệm tiêu
chuẩn 1008 bao gồm việc thử nghiệm đơn vị phần mềm và tiêu chuẩn
1002 bao gồm kiểm tra và hiệu lực suốt chu kỳ phát triển. Tiêu chuẩn
1012 mô tả tuyệt vời bao gồm các hoạt động thử nghiệm phát triển dự án.
Điều này đ-ợc mơ tả trong các hình 8. 5 và 8. 6.

Tiêu chuẩn 990 là b-ớc khởi đầu khơng bình th-ờng từ tính khái qt
và đề cập đến ngơn ngữ lập trình đặc thù, Ada. Với những ai quen thuộc
với Ada, lý do hậu thuẫn cho điều này sẽ rõ ràng vì Ada hơn là một ngơn
ngữ lập trình. Hiện t-ợng ngôn ngữ Ada đ-ợc bàn đến ở phần 8. 4.

Phân loại học các tiêu chuẩn công nghệ phần mềm cũng là một hiện
t-ợng khơng bình th-ờng và lý thú, xứng đ-ợc quan tâm đặc biệt.

41 Một đặc điểm thực ra rõ ràng hơn và thực hiện đ-ợc hàm ý là phải có thể thực hiện đ-ợc mỗi yêu

</div>
(160)<div class='page_container' data-page=160>

8.3.2. Phân loại học IEEE cho các tiêu chuẩn công nghệ

phần mềm.

Tiờu chun 1002, phõn loi hc cỏc tiờu chuẩn công nghệ phần mềm là
một hiện t-ợng lý thú ở chỗ nhằm cung cấp tiêu chuẩn lựa chọn, phần
loại và so sánh các tiêu chuẩn phần mềm khác. Mục đích của nó cũng là
gíup đỡ nhận biết nhu cầu cho các tiêu chuẩn ở đâu khơng có hay ở đâu
khơng có cái thích hợp. Tiêu chuẩn cũng có danh sách các định nghĩa bao
gồm nhiều loại tiêu chuẩn phát triển phần mềm và thuật ngữ đ-ợc sử
dụng để nhận biết chúng42.

Phân loại học là tham khảo tuyệt vời để hiểu rõ đ-ợc các tiêu chuẩn
phát triển phần mềm và quan hệ giữa các tiêu chuẩn. Phân loại học tạo
nên sự phân chia các tiêu chuẩn phần mềm theo loại và sự phân chia công
nghệ phần mềm theo chức năng và chu kỳ đời. Để hoàn chỉnh phân loại
học, khung mơ tả quan hệ giữa hai phân chia.

Các hình 8.7a và 8.7b mô tả sự phân chia các tiêu chuẩn theo loại và sự
phân chia công nghệ phần mềm theo chức năng và chu kỳ đời. Hình 8.8
là thí dụ về lại bảng sử dụng để xác định khuôn khổ phân loại cơ bản.

Tiêu chuẩn 1002 có thể có ích trong những tổ chức xem xét chuyển
sang phát triển phần mềm chính thức hay khi khả năng thích ứng của các
thực hành chính thức hiện có đuợc đánh giá lại. Tiêu chuẩn không phụ
thuộc ở các tiêu chuẩn IEEE khác và có thể đ-ợc áp dụng cho bất cứ tiêu
chuẩn phỏt trin phn mm chớnh thc no khỏc.

8.3.3 Lợi và bất lợi của các tiêu chuẩn IEEE.

Cỏc tiờu chun cụng nghệ phần mềm IEEE là một bộ tiêu chuẩn,
h-ớng dẫn và góp ý mềm dẻo có thể áp dụng cho nhiều ph-ơng pháp
luận khác nhau. Các tiêu chuẩn t-ơng đối dễ sử dụng và có nhiều thí
dụ chứng minh cách mà các tiêu chuẩn đó có ý định đ-ợc sử dụng.

Mặc dù mọi tiêu chuẩn công nghệ phần mềm đều so sánh đ-ợc các
tiêu chuẩn đã đ-ợc phát triển sao mỗi tiêu chuẩn có thể đ-ợc sử dụng
riêng biệt. Điều này có nghiã mỗi tiêu chuẩn IEEE có thể đ-ợc sử
dụng mà không cần phải sử dụng tiêu chuẩn.

42 Tiêu chuẩn IEEE 1002 bao gồm định nghĩa từ phân loại học là "sơ đồ phân chia khung kiến thức

</div>
(161)<div class='page_container' data-page=161>

H×nh 8. 5

</div>
(162)<div class='page_container' data-page=162>

H×nh 8. 6

</div>
(163)<div class='page_container' data-page=163>

a) Phân chia tiêu chuẩn.

Các chuẩn tiến trình
- Ph-ơng pháp
- Kỹ thuật
- Đo l-ờng

b) Phân chia công nghệ phần
mềm

Chức năng nghề nghiệp

Các tiêu chuẩn sản phẩm
- Yêu câù

- Thiết kế
- Thành tố
- Mô tả
- Kế hoạch
- Báo cáo

Chức năng công nghệ sản phẩm
Phân tích yêu cầu

Thit k
Lp mó
Hp nht
Chuyn i
G ri

Hỗ trợ sản phẩm
Bảo trì phần mềm
Các tiêu chuẩn chuyên môn

Chc danh ngh nghip
Mó o c

Bằng cấp
Lý lịch

Kiểm tra và hiệu lực
Rà soát lại và kiểm toán

Phân tích sản phẩm
Thử nghiệm

Các tiêu chuẩn ghi chú
Danh mục

Đại diện
Ngôn ngữ

Chức năng quản lý kỹ thuật
Quản lý quá trình

Qun lý sn phm
Qun lý nguồn
Vòng đời
Pha quan niệm
Pha yêu cầu
Pha thiết kế
Pha thực hiện
Pha thử nghiệm
Pha định tính
Pha sản xuất

Pha lắp đặt và kiểm tra
Pha vận hành và bảo trì

Pha nghØ h-u.

H×nh 8. 7

(a) Phân hoạch các chuẩn theo kiểu

(b) Phân hoạch công trình phần mềm theo chức năng và vòng

i

Theo IEEE Std 1002-1987

</div>
(164)<div class='page_container' data-page=164>

Chuẩn
tiến
trình

Chuẩn
sản
phẩm

Chuẩn
chuyên
nghiệp

Chuẩn
quốc

gia

*

Kiểm

nghiệm
và
Thẩm

nh

Rà soát
và
kiểm toán
Phân tích
sản phẩm
Thử nghiệm
Quản

lý kỹ
thuật

Quản lý
tiến trình

Quản lý
sản phẩm

Quản lý
nguồn lực

**

ýniệm

Yêu cầu
Thiết kế
Thực thi
Thử nghiệm

Chế tạo
Vận hành và bảo trì

Nghỉ việc

(

*

) Chc nng cơng việc
(

**

) Vịng đời phần mềm

H×nh 8. 8

Bảng khung phân loại cơ bản (trích ở IEEE Std. 1002. 1987 IEEE
Standard taxonomy for sopftware Engineering standards của Viện kỹ
s- điện và điện tử với sự đồng ý của IEEE)

Dù sao nhiều lợi điểm của tiêu chuẩn cùng có thể đ-ợc nhận thức
là bất lợi, chúng để cho ng-ời thực hiện đ-ợc tự do rất nhiều khiến
cho, vì lợi ích của tiêu chuẩn hoá, mỗi tổ chức phải xác định cái cách
mà họ phải thực hiện.

</div>
(165)<div class='page_container' data-page=165>

giữa các tiêu chuẩn và kích th-ớc t-ơng đối chung nhất đ-ợc sử dụng
để xỏc nh chỳng.

8. 3. 4. So sánh các tiêu chuẩn IEEE vµ DOD.

Các tiêu chuẩn IEEE và DOD đ-ợc căn cứ ở cách lý giải t-ơng tự về
công nghệ phần mềm ở chỗ thuật ngữ t-ơng tự và tiếp cận chung
t-ơng tự. Tuy nhiên mục tiêu lại không t-ơng tự. Tiêu chuẩn DOD
2107 đã đ-ợc xây dựng để hỗ trợ lợi ích của khách hàng (DOD) trong
khi các tiêu chuẩn IEEE đã đ-ợc xây dựng với lợi ích cả của khách
hàng và ng-ời sản xuất cùng nh- nhau trong tâm trí. Sau đây là tóm

tắt của những khác nhau chính gia hai tiờu chun:

1. Tiêu chuẩn DOD hầu hết là một bộ ph-ơng h-ớng trong khi nhiều
những tiêu chuẩn IEEE trên thực tế là những h-ớng dẫn và góp ý.
2. Tiêu chuẩn DOD cung cấp một bộ tổng quát các ph-ơng h-ớng

trong khi IEEE là một bộ các tiêu chuẩn riªng biƯt.

3. Các tiêu chuẩn IEEE mềm mỏng hơn và tạo ra mức độ tự do rộng
lớn hơn những tiêu chuẩn DOD.

4. Cả tiêu chuẩn IEEE đều có thể lấy kích th-ớc theo yêu cầu của dự
án đặc thù. Nh-ng các tiêu chuẩn IEEE lại đi xa hơn khi việc chấp
nhận tiêu chuẩn riêng biệt khơng địi hỏi chấp nhận tiêu chuẩn nào
khác.

5. Cả tiêu chuẩn IEEE và DOD đều nghiêng về tiếp cận theo pha với
công nghệ phần mềm. Mặc dù cả hai đều có thể hỗ trợ các ph-ơng
pháp phát triển khác. IEEE dễ thích nghi với các tip cn lp li
hn nhiu.

8. 4. các Tiêu chuẩn ADA

Ada là ngơn ngữ lập trình nh-ng đó là ngơn ngữ lập trình duy nhất.
Nó có một trong những nhà tiêu thụ lớn nhất các dịch vụ phát triển
phần mềm lớn nhất trên thế giới. Bộ quốc phòng Hoa kỳ. ADA là tiêu
chuẩn quân sự, ký hiệu là ANSI/MIL- STD- 1815a. Ada cũng đến với
h-ơng vị đặc biệt châu Âu và trên thực tế, nó đ-ợc chấp nhận vào đầu
những năm 80 là ngôn ngữ thực hiện chung của cộng đồng kinh tế
châu Âu cộng đồng châu Âu cũng tham gia tích cực vào việc thiết kế

ngơn ngữ và rà sốt lại Ada và nhiều dự án lớn châu Âu cũng sau đó
đ-ợc xây dựng bằng Ada.

</div>
(166)<div class='page_container' data-page=166>

nguyền rủa Ada ngôn ngữ lúc đầu đ-ợc sử dụng cho những ứng dụng
thời gian khơng thực vì có những vấn đề chuyển nhiệm vụ chậm với
những bộ biên soạn Ada đầu tiên. Những vấn đề này biến đi khi có
đ-ợc những bộ biên soạn Ada tinh xảo hơn và Ada giờ đây đ-ợc dùng
xử lý dữ liệu phát triển hệ thống và ứng dụng thời gian thực.

8. 4. 1. M«i tr-êng Ada

Ada cũng đ-ợc dùng làm công cụ thiết kế lúc khởi đầu Ada đ-ợc
coi là một ngôn ngữ mới nhiều hơn. Cấu trúc của ngơn ngữ làm cho
nó thích hợp để dùng làm ngơn ngữ thiết kế ch-ơng trình (PDL). Đặc
điểm đó của Ada khơng phải là ngẫu nhiên khi DOD đặt ch-ơng trình
của các mơi tr-ờng hỗ trợ Ada là mục tiêu song hành với sự phát triển
của bản thân ngôn ngữ. Các yêu cầu về ngôn ngữ Ada đ-ợc xác định
trong văn bản của Stulm và một văn bản thứ hai, văn bản Steelman43
xác định các yêu cầu cho cỏc mụi tr-ng h tr.

Nhiều bộ biên soạn Ada ngày nay đ-ợc cung cấp nh- một bộ phận
nguyên thể của môi tr-ờng phát triển Ada ba thân bộ biên soạn, điều
này bao gồm các công cụ CASE sản sinh t- liệu, thiết kế phầm mềm,
gỡ rối và hoà nhập và thử nghiệm44.

8. 4. 2. Tiêu chuẩn IEEE cho các Ada PDL.

IEEE đã chọn Ada là công cụ thiết kế phần mềm xứng đ-ợc quan
tâm đặc biệt. IEEE công bố tiêu chuẩn 990 năm 1987 xác định một
bộ qui trình kỹ thuật nêu theo trong việc sử dụng Ada làm PDL (ngơn

ngữ thiết kế ch-ơng trình).

Tiêu chuẩn 990 liên quan đến đặc điểm PDL của Ada chứ không
phải sử dụng Ada làm PDL. Điều này là do cố gắng của tiêu chuẩn
trong việc khái quát hoá bằng cách đề cập bất cứ PDL nào dựa trên cú
pháp và ngữ nghĩa Ada (theo thế tiêu chuẩn sáng tạo ra từ Ada PDL).

Tiêu chuẩn IEEE 990 chính thức hố qui trình kỹ thuật tất nhiên
phát triển với những ng-ời dùng Ada. Tiêu chuẩn mô tả đặc điểm yêu
cầu của Ada PDL hầu hết có thể sẵn sàng áp dụng cho mọi PDL tốt.
Những đặc điểm yêu cầu đó bao gồm việc hỗ trợ nhiều ph-ơng pháp
luận thiết kế và một số qui trình thiết kế tốt nh- khả năng điều biên
nh- ẩn dấu thông tin và liên kết thông tin. Tiêu chuẩn có thể đ-ợc
dùng làm phiếu kiểm tra đánh giá các PDL và đặc biệt hơn nó có thể
có ích trong việc hiểu Ada có thể đ-ợc sử dụng tốt nhất làm PDL
nh-thế nào.

43 DOD công bố t- liệu Stoneman năm 1976 xác định ‘’yêu cầu cho các môi tr-ờng hỗ trợ lập

trình Ada” và t- liệu Steelman năm 1978 xác định ‘’u cầu cho các ngơn ngữ lập trình máy tính
lệnh cao’’ dẫn đến nền móng cho ngơn ngữ Ada (đ-ợc gọi theo tên Augusta Ada Byron đ-ợc coi
là nhà lập trình máy tính đầu tiên và con gái của thi hào Anh, bá t-ớc Byron).

44 Tahvanainen vµ Smolander (1990) là nguồn thông tin có ích về các công cơ thiÕt kÕ, m«

</div>
(167)<div class='page_container' data-page=167>

Tiêu chuẩn IEEE về Ada PDL cũng dẫn t- liệu về một hiện t-ợng
tất nhiên do những ng-ời dùng Ada phát triển. Là ngôn ngữ lập trình.
Ada là PDL dễ đ-ợc vận dụng cho pha thiết kế của phát triển phần
mềm và khi đ-ợc dùng nh- thế, nó tạo ra lợi thế phụ rõ rệt. Sau khi
thiết kế hoàn thành một l-ợng chủ yếu của mã đã đ-ợc viết ra. Điều

này đã dẫn đến việc phát triển một số công cụ Ada CASE tạo ra mó
Ada.

8. 5. Các tiêu chuẩn phát triển phần mềm kh¸c.

Một trong những tiêu chuẩn sớm cho t- liệu phần mềm đ-ợc văn
phịng tồn quốc Hoa kỳ về tiêu chuẩn công bố năm 1976. Tiêu
chuẩn, gọi là h-ớng dẫn t- liệu ch-ơng trình máy tính và các hệ dữ
liệu tự động đ-ợc công bố coi nh- ấn phẩm liên bang các tiêu chuẩn
xử lý thông tin. Việc công bố tiêu chuẩn trùng với khởi điểm khiêm
tốn của tiến triển phần mềm coi nh- bộ mơn cơng nghệ. Văn phịng
tiêu chuẩn công bố tiếp năm tiêu chuẩn phần mềm nữa khoảng 1979
và 1984 bao gồm:

 H-íng dÉn vỊ t- liƯu pha ban đầu.

H-ng dn ỏnh giỏ cụng c phỏt trin phn mm.

H-ớng dẫn kiểm tra hợp thực hoá và thử nghiệm phần mềm.

H-ớng dẫn bảo trì phần mềm.

Coi nh- cố gắng b-ớc đầu trong việc cung cấp tiêu chuẩn toàn
quốc các tiêu chuẩn này đã là một b-ớc tiến lên chủ yếu. Những tiêu
chuẩn sớm sủa khác đ-ợc ANSI và nhiều ngành quân sự Hoa kỳ công
bố trong những năm đầu 70.

ở Châu âu tiêu chuẩn Anh BS 6224 đ-ợc cơng bố vào những năm
đó 1980 và tổ chức quốc tế châu âu về tiêu chuẩn hoá (ISO) đã công
bố các tiêu chuẩn phần mềm vào cuối những năm 80.

Rất nhiều tiêu chuẩn trở thành công cụ hay kỹ thuật đặc hiệu. Tiêu
chuẩn anh 6224 có kỹ thuật thiết kế lý thú đ-ợc coi là sơ đồ cấu trúc
thiết kế (BS 6224 DSD) DSD là biểu diễn bằng đồ thị thiết kế phần
mềm (tựa nh- biểu đồ dòng chảy). Khuyến khích tiếp cận theo cơ cấu
đến q trình thiết kế kỹ thuật DSD cơ bản đ-ợc mô tả tuyệt vời trong
chính văn bản tiêu chuẩn45.

Có nhiều kỹ thuật đã không đ-ợc chấp nhận rộng rãi. Điều này đã
dẫn đến tình trạng phong phú về ph-ơng pháp, tiêu chuẩn kỹ thuật.
Chẳng hạn, việc bảo đảm chất l-ợng phần mềm đã đ-ợc chú ý đến
nhiều cả trong tiêu chuẩn IEEE và DOD. Tiêu chuẩn châu Âu ISO
9000- 3 năm 1990 (ISO1990) giới thiệu tiếp cận cơ bản có đơi chút
khác. Tiêu chuẩn châu Âu đ-a ra nghĩa rộng hơn về bảo đảm chất
l-ợng phần mềm và bao gồm:

</div>
(168)<div class='page_container' data-page=168>

Trách nhiệm quản lý.

Kiểu toán và rà soát lại.

Thử nghiệm.

Kiểm tra cấu hình.

Đào tạo.

Nhiu nhng tiêu chuẩn khác đã đ-ợc tạo lập cả ở châu Âu và Hoa
kỳ. Lựa chọn tiêu chuẩn thích hợp, bản thân nó là một hoạt động dự
án chủ yếu. Sai lầm trong việc sử dụng tiêu chuẩn phát triển không
phải phần mềm hầu hết là lớn trong việc tìm cách vận dụng toàn bộ

DOD Std. 2167A cho một dự án xử lý dữ liệu nhỏ.

Chắc chắn điểm quan trọng hơn cả phải nhớ khi lựa chọn tiêu
chuẩn thích hợp cho dự án phần mềm là ở chỗ tiêu chuẩn phát triển là
ph-ơng tiện chứ không phải cứu cánh tiêu chuẩn phải hỗ trợ thực hiện
mục tiêu: phát triển thành công phần mềm có chất l-ợng. Nếu tiêu
chuẩn can thiệp vào việc hồn thành mục tiêu này thì chắc hẳn là
hoặc tiêu chuẩn sai hoặc đ-ợc vận dụng không đúng.

Các tiêu chuẩn thành cơng nhất khi chảy theo dịng. Bất kể khi nào
có thể đ-ợc tiêu chuẩn tạo ra khung hợp thức cho các qui trình kỹ
thuật tốt đã tồn tại. Khi các qui trình hiện có là vơ hiệu, tiêu chuẩn
phải hỗ trợ thay thế chúng bằng những qui trình có thể dễ dàng đ-ợc
thực hiện. Thật sẽ khó mà đ-a ra đ-ợc một tiêu chuẩn đáp ứng đ-ợc
sự chống trả của ng-ời sản xuất.

8. 6. Tãm t¾t.

Tiêu chuẩn có thể đ-ợc coi là tai hoạ cần thiết và việc ứng dụng đạt
đ-ợc kết quả xứng đáng. Nó làm cho việc phát triển phần mềm dễ
quản lý hơn. Một trong những thách đố chính cho ng-ời quản lý dự
án là việc lựa chọn bộ tiêu chuẩn đúng ch-ơng này cung cấp thông tin
cơ bản cần thiết giúp đỡ ng-ời quản lý dự án tiến hành sự lựa chọn
đó.

Loại và biến thức của các tiêu chuẩn phát triển dự án có nhiều và
khơng có chỉ dẫn nào là tiêu chuẩn trở thành tiêu chuẩn cả. Nhiều tiêu
chuẩn phần mềm có -u thế đ-ợc thoả mãn miễn là chúng đ-ợc vận
dụng đúng. Các tiêu chuẩn đòi hỏi kỷ luật và kỷ luật không dễ đáp
đặt trong công nghệ phần mềm.

Tiêu chuẩn 2167 của Bộ quốc phòng Hoa kỳ giải quyết vấn đề kỷ
luật bằng cách yêu cầu vận dụng tiêu chuẩn nh- là bộ phận của hợp
đồng dự án ý định đã nhằm cho 2167 trở thành tiêu chuẩn duy nhất
chính thức cho sự phát triển phần mềm hệ thống quốc phòng cho giới
quân sự Hoa kỳ.

</div>
(169)<div class='page_container' data-page=169>

dẫn và góp ý mềm mỏng có thể đ-ợc áp dụng cho nhiều loại ph-ơng
pháp luận phát triển phần mềm. Các tiêu chuẩn t-ơng đối dễ sử dụng,
kể cả nhiều thí dụ chứng minh con đ-ờng mà các tiêu chuẩn có ý định
sử dụng.

Cả tiêu chuẩn IEEE và DOD đ-ợc căn cứ ở giải thích t-ơng tự về
cơng nghệ phân mềm ở chỗ thuật ngữ t-ơng tự và tiếp cận chung
t-ơng tự nh- thế nào. Tuy nhiên mục tiêu lại không t-ơng tự, Tiêu
chuẩn DOD 2167 đ-ợc xây dựng để hỗ trợ quyền lợi của khách hàng
(DOD) trong khi các tiêu chuẩn IEEE đ-ợc xây dựng vì quyền lợi cả
của khách hàng và ng-ời sản xuất nh- nhau trong tâm trí.

Các tiêu chuẩn đã đ-ợc xây dựng phong phú ở Châu Âu và ở Hoa
kỳ làm cho việc lựa chọn tiêu chuẩn thích hợp tự thân là một hoạt
động chủ yếu của dự án.

Tiêu chuẩn phát triển phần mềm là ph-ơng tiện chứ không phải cứu
cánh. Tiêu chuẩn phải hỗ trợ thực hiện mục tiêu cơ bản: Phát triển
thành cơng phần mềm có chất l-ợng. Nếu tiêu chuẩn can thiệp vào
việc thực hiện mục tiêu này thì hầu nh- chắc chắn là hoặc tiêu chuẩn
sai hoặc khơng đ-ợc vận dụng đúng.

Bµi tËp

1. DOD us đã hợp đồng với bạn phát triển phần mềm cho tiện ích tối
-u hố kiểm kê. Hệ thống sẽ nhận đ-ợc thông tin về các hạng mục
quân sự đặc tr-ng, số l-ợng yêu cầu cho mỗi hạng mục địa điểm
khả năng tiêu thụ dự kiến của mỗi hạng mục. Sau đó hệ thống sẽ
đ-a ra các mức kiểm kê góp ý cho mỗi hạng mục với địa điểm cho
mỗi kho kim kờ

Hệ thống đ-ợc xây dựng phù hợp với tiêu chuẩn 2167. HÃy chuẩn
bị một danh mục 10 yêu cầu lấy kích th-ớc chủ yếu cho tiêu chuẩn
và giải thích lý do cho mỗi yêu cầu.

2. So sánh các tiêu chuẩn IEEE và DOD liên quan với dự án mô tả
trong bài tập 1. Giải thích xem tiêu chuẩn nào bạn nghĩ là thích
hợp hơn cả,

3. Chun b phỏc đồ về đặc điểm yêu cầu cho dự án mô tả trong bài
tập 1. Dựa trên h-ớng dẫn IEEE cho đặc điểm yêu cầu tốt, hãy cho
thí dụ về mỗi một trong 7 đặc điểm mô tả.

4. Mô tả khung liên quan đến các tiêu chuẩn DOD cho công nghệ
phần mềm. Sử dụng bảng xác định trong tiêu chuẩn 1002 phân loại
công nghệ phân mềm IEEE. Cũng xác định khuôn khổ cho các
tiêu chuẩn IEEE.

</div>
(170)<div class='page_container' data-page=170>

Ch-¬ng chÝn

</div>
(171)<div class='page_container' data-page=171>

Lập lịch: Vấn đề.

Mỗi dự án đều có thể hồn thành nếu có đ-ợc một l-ợng thời gian và

nguồn vốn vô hạn đã cho. Về thực tiễn mà xét l-ợng thời gian có để phát
triển dự án bao giờ cũng có hạn. Trên thực tế trong hầu hết tr-ờng hợp nó
lại ít hơn l-ợng thời gian mà ng-ời quản lý dự án coi là đủ. Có ít dự án
hồn thành tr-ớc thời hạn: nhiều dự án v-ợt quá lịch của chúng.

Những chuyện có thật sau đây nhấn mạnh đến một vài yếu tố chính
trong việc lập lịch.

Vào cuối những năm 70, một chủ thầu quốc phòng lớn trụ sở ở
California đã phát triển một hệ thống phịng khơng phức hợp cho quân sự.
Sau khi giai đoạn hợp nhất bắt đầu và trong thời kỳ sau khoảng sáu tháng,
mọi cố gắng đ-ợc h-ớng về thử nghiệm hệ thống chủ yếu đầu tiên, thử
nghiệm này đ-ợc tiến hành cùng với chủ thầu phụ ở bờ biển phía đơng.

Chủ thầu phụ đ-ợc giao nhiệm vụ đ-a một máy bay lên không trung,
máy bay này có thể liên lạc với hệ thống máy tính của chủ thầu phụ ở bờ
biển phía đơng và rồi hệ thống này lại liên lạc với địa điểm thử nghiệm
chính của chủ thầu ở California. Nhiều chức năng hệ thống cơ bản đã
đ-ợc thử thách trong thử nghiệm hệ thống tốn kém đó. Khi thời gian thử
nghiệm đến gần, mỗi thành viên của đội đã làm việc cực kỳ căng thẳng
nhằm đảm bảo cho thử nghiệm thành công. Vào ngày chỉ định cho thử
nghiệm, tất cả nhân viên của dự án đến nơi làm việc từ sáng sớm để đảm
bảo cho thiết bị hoạt động đúng đắn. Chủ thầu phụ ở bờ biển đông cho
máy bay lên và hệ thống hoạt động

Thử nghiệm đã thất bại. Không chỉ thử nghiệm thất bại mà trên thực tế
nó chẳng bao giờ bắt đầu cả. Lý do là không ai nhớ đến việc ra lệnh cho
các tuyến liên lạc từ công ty điện thoại giữa điểm chủ thầu phụ bờ biển
đông và điểm thử nghiệm California. Mọi cố gắng trong quản lý để công
ty điện thoại lắp đ-ờng dây trong ngày thử nghiệm đã thất bại chỉ vì

khơng đủ thời gian. Thất bại tổng cộng của thử nghiệm hệ thống đã tốn
kém nặng cho chủ thầu và chắc hẳn một số nhà quản lý mất việc của
mình.

Giai thoại này nhấn mạnh đến nhiều vấn đề của việc qui hoạch và lập
lịch dự án. Những sai lầm đó có thể xảy ra vì sức ép thời gian do lập lịch
khơng thực tiễn hay vì bố trí nhân viên kém trong phạm vi tổ chức dự án.

Dự án hầu hết luôn đ-ợc phát triển d-ới sức ép thời gian. Có sức ép
“đạt đ-ợc tốc độ” và sức ép “cho chúng ta xem cái gì đang xẩy ra” và tất
nhiên có sức ép địi thu đ-ợc hệ thống lắp đặt xong và chạy. Chắc hẳn sức
ép phổ biến nhất liên quan đến thời gian l get that darned bug fixed

quickly!. Loại sức ép này có thể gây sự tàn phá kế hoạch phát triển dù

án, làm cho ng-ời quản lý dự án tìm cách xoay sở nhanh và bẩn thỉu hay
cắt giảm thẳng thừng. Và cắt giảm thẳng thừng dẫn đến loại sai lầm tốn
kém đ-ợc mô tả ở trên.

</div>
(172)<div class='page_container' data-page=172>

Tất nhiên chuẩn bị lên lịch thực tiễn không chỉ là mục tiêu, mà quan
trọng là có lịch đ-ợc chấp thuận. Việc có đ-ợc sự chấp thuận lịch thoả
dáng và các vấn đề liên quan cũng đ-ợc bàn đến.

Dù lịch dự án đ-ợc chuẩn bị tốt thế nào chăng nữa, thì lịch cũng là vơ
dụng nếu nó khơng đ-ợc thực hiện. Đây là trách nhiệm của ng-ời quản lý
dự án chống chọi đ-ợc sức ép và đảm bảo là dự án đ-ợc phát triển một
cách trật tự theo đúng lịch. Bất kể khi nào tình huống thay đổi, khi đó
lịch của dự án phải theo đó đ-ợc cập nhật để phản ánh đ-ợc tình hình
mới. Lịch của dự án là một trong những phần quan trọng nhất của kế
hoạch phát triển dự án. Kế hoạch không chỉ bao gồm lên lịch các hoạt

động phát triển mà còn lên lịch các nguồn vốn của dự án, đặc biệt là con
ng-ời. Ch-ơng này bàn đến việc lên lịch trong bối cảnh kế hoạch phát
triển d ỏn.

9.1 Kế hoạch phát triển dự án.

Kế hoạch phát triển dự án là một trong những văn bản hợp thức đầu
tiên do dự án tạo ra. Trong văn bản này, ng-ời quản lý dự án mô tả chi
tiết:

Dự án sẽ đ-ợc phát triển thế nào

Cần có những ngn vèn nµo

 Những nguồn vốn đó đ-ợc sử dụng ra sao

Kế hoạch phát triển dự án đảm bảo rằng việc phát triển của dự án đ-ợc
lên biểu rõ ràng tr-ớc khi các hoạt động phát triển chính bắt đầu. Ngồi
lịch phát triển cơ bản, kế hoạch cịn đề cập đến những vấn đề nh-:

 Cung cấp kịp thời thiết bị và công cụ cho ng-ời sản xuất khi cần
đến.

 Có đ-ợc đội ngũ thực hiện các nhiệm vụ phát triển phù hợp với lịch.

 Cung cấp kế hoạch đột xuất đề phòng tr-ờng hợp rủi ro của dự án
thành hiện thực.

 Chỉ định nhiệm vụ trong đội ngũ phát triển và giao những nhiệm vụ
đó cho các thành viên đội.

Nội dung của kế hoạch phát triển dự án có thể thích nghi với qui mơ
dự án, có thể là văn bản lớn hay đúng chỉ vài trang. Bảng 9.1 giới thiệu
phác đồ về một số chủ đề nằm trong kế hoạch phát triển dự án.

</div>
(173)<div class='page_container' data-page=173>

các hoạt động nh- giao diện với chủ thầu phụ, ng-ời bán v i din ca
khỏch hng.

Bảng 9.1 Các hạng mục kế hoạch phát triển dự án phần mềm.

1) Tổng quan hệ thống

2) Quản lý phát triển phần mềm: Tổ chức dự án và nguồn lực dự án,
Ph-ơng tiện phát triển, Cơ cấu tổ chức dự án, Nhân sự

3) Lch v ct mốc: Hoạt động theo lịch, Đ-ờng mốc và cột mốc, Sơ
đồ mạng hoạt động, Nguồn lực thành tố hệ thống, Quản lý ngân sách:
thanh toán cột mốc, chi phi ngân sách chủ yếu, thủ tục cho phép chi phí.

6) Giao diện với các nguồn bên ngoài
7) Thủ tục rà soát lại hợp thức

8) Quỏ trình tiến hành hiệu chỉnh
9) Báo cáo về các thay đổi/vấn đề.

10) Công nghệ phần mềm: Tiêu chuẩn và thủ tục, Ph-ơng pháp luận
phát triển, Nguồn lực phát triển, Nhân sự - trình độ và chức trách

11) Thđ tơc thư nghiƯm

12) Quản lý cấu hình phần mềm
13) Bảo đảm chất l-ợng phần mềm.

Nhiều tiêu chuẩn đã đ-ợc tạo ra cho kế hoạch phát triển dự án. Cơ cấu
hợp thức của năm bỏi kế hoạch phát triển dự án khác nhau tuỳ thuộc ở
tiêu chuẩn t- liệu hiện sử dụng chẳng hạn tiêu chuẩn 2167 US DOD cung
cấp khả năng tuỳ chọn mô tả các kế hoạch thử nghiệmu quản lý cấu hình
và đảm bảo chất l-ợng trong ba văn bản riêng biệt. Với những dự án lớn,
khả năng tuỳ chọn đó có thể trở thành yêu cầu.

Tiêu chuẩn IEEE 1058.1 mô tả cái đ-ợc coi là kế hoạch quản lý dự án
phần mềm chủ yếu cũng y nh- kế hoạch phát triển dự án. Tiêu chuẩn này
t-ơng hợp nhiều với kế hoạch phát triển dự án 2167 mặc dù rõ ràng ít chi
tiết hơn. Tiêu chuẩn này lại cũng cung cấp khả năng tuỳ chọn gộp các kế
hoạch quản lý cấu hình và bảo đảm chất l-ợng hay mơ tả chúng trong các
văn bản riêng biệt.

Kế hoạch phát triển dự án đ-ợc chuẩn bị là văn bản tự lập theo nghĩa
nó đọc đ-ợc và hiểu đ-ợc khơng cần phải xét tới các văn bản khác. Do
đấy tổng quan chung của dự án thông th-ờng đ-ợc gộp trong phần đầu
của văn bản. Tất nhiên tham chiếu về chi tiết phụ phải ln có, kể cả chỉ
dẫn về những văn bản nh- hợp đồng dự án, văn bản quan niệm hay phân
tích, nghiên cứu thị tr-ờng.

</div>
(174)<div class='page_container' data-page=174>

quản lý xét. Xem các ph-ơng tiện sẽ đ-ợc tổ chức thế nào để hỗ trợ cố
gắng phát triển. Đây là một trong những phần cung cấp nhiều chi tiết cần
để chuẩn bị cốt lõi của kế hoạch phát triển cụ thể lịch phát triển. Lịch

cung cấp câu trả lời cho hai câu hỏi qui hoạch cơ bản “cái gì” và “khi
nào”, trong khi phần lớn những phần còn lại đề cập “nh- thế no.

Việc bàn luận trong các phần nh- thế nào cung cấp thông tin về dự
án sẽ đ-ợc tổ chức thế nào, những rủi ro sẽ đ-ợc xử lí thế nào, những rà

soát lại đ-ợc tiến hành thế nào, những tiêu chuẩn sẽ đ-ợc vận dụng thế

nào, những ph-ơng pháp luận phát triển nào sẽ đ-ợc sử dụng và sản

phẩm nào sẽ đ-ợc thử nghiệm.

Thụng th-ng tt nht l cho việc hoàn thành phần lịch (phần 3
trong bảng 9.1) cuối cùng lịch tuỳ thuộc ở hầu hết các phần khác là phần
nhạy cảm nhất của kế hoạch phát triển. Sau khi bản dự thảo đầu của kế
hoạch phát triển đã sẵn sàng lịch phát triển ban đầu có thể theo đó đ-ợc
chuẩn bị. Nh- chúng ta sẽ thấy lịch theo đó đ-ợc tinh chế thêm khi kế
hoạch phát triển đi qua những lần lặp lại tuần tự

9.2 Hoạt động và cột mốc theo lịch

Lịch phát triển của dự án là danh mục các hoạt động và thời gian tiên
liệu thực hiện có nhiều cách biểu thị lịch: danh mục hoạt động biểu đồ,
đồ thị v.v. Ph-ơng pháp thông th-ờng nhất của biểu diễn lịch là biểu đồ
mạng PERT biểu đồ GANTT và danh mục cột mốc (những ph-ơng pháp
này sẽ đ-ợc mô tả sau). Mọi ph-ơng pháp biểu diễn lịch chủ yếu phải
cung cấp cùng thông tin cơ bản hoạt động và thời gian thực hiện. Do đấy
b-óc đầu trong việc chuẩn bị lịch là xác định các hoạt động dự án.
Nh-chúng ta đã thấy lịch phát triển dự án là một trong những yếu tố quan
trọng nhất của kế hoạch phát triển dự án và kế hoạch này đ-ợc yêu cầu ở

những giai đoạn đầu của dự án. Bất hạnh là danh mục đầy đủ các hoạt
động lại th-ờng khơng có đ-ợc cho đến khi hồn tồn vào giai đoạn thiết
kế. Do đấy phiên bản ban đầu của lịch dự án th-ờng bắt đầu với danh
sách hoạt động mức cao và lịch ban đầu này tiếp tục đ-ợc tinh chế lại khi
có đ-ợc nhiều thơng tin hơn. Ch-ơng 6 có bàn đến đầy đủ các ph-ơng
pháp tinh chế danh mục hoạt động cơng việc.

Lịch ban đầu có thể chỉ có những pha cơ bản của chu kỳ phát triển
phần mềm (đặc tả yêu cầu, thiết kế, thực hiện.v.v.) phiên bản đầu này của
lịch th-ờng đ-ợc tạo ra cùng với dự toán ban đầu của dự án tr-ớc khi dự
án chính thức đ-ợc tung ra. Khi có nhiều chi tiết hơn, dự toán tốt hơn
đ-ợc xây dựng và lịch đ-ợc tinh chế hơn và tin cậy hơn. Dự toán dự án
đ-ợc bàn chi tiết ở ch-ơng 10.

9.2.1 Danh mục hoạt động theo lịch

</div>
(175)<div class='page_container' data-page=175>

án tới mức thấp hơn nữa gọi là các tác nhiệm. WBS cung cấp một ph-ơng
pháp kiểm tra công việc hiện nay đ-ợc đội phát triển thực hiện và đặc
biệt có ích trong việc giao nhiệm vụ công việc mức thấp cho nhân viên dự
án. WBS đ-ợc bàn thêm ở ch-ơng 6.

Bảng 9.2 Danh mc hot ng thớ d

S
hiu
hot
ng
Tờn
hot
ng

Mô tả Ngày

bắt đầu
Ngày
kết thúc
Phụ
thuộc
Giao
trách
nhiệm
5. Tích
hợp

Tích hợp phần
cứng và phần
mềm hệ thống

10/01 31/01 5.3 Sơn
5.1 Thiết bị Mua sắm thiết bị

tớch hp 20/01 20/04 5.1 Bo
5.2 Lp t Cung cp ni lp

1/01 28/01 Bình

5.3 Qui
hoạch

tích hợp

Chuẩn bị qui

hoạch tích hợp 22/02 20/03 5.1 Kiên
5.4 Pha 1 Pha tích hợp S/W

nguyên thuỷ 21/03 22/03 5.4 Kiên
5.5 Demo 1 Cột mốc tích hợp

nguyên thuỷ 15/03 30/4 5.4 Kiên
5.6 Pha 2 Pha tích hợp

S/W-H/W

1/05 /05 5.6,5.
5

Kiên,
Bắc
5.7 Demo 2 Cột mốc tích hợp

S/W-H/W 20/04 31/05 5.6 Kiên,Bắc
5.8 Pha 3 Tích hợp hệ

thống trọn vẹn

1/06 2/06 5.8,5.
7

Kiên
5.9 Demo3 Cột mốc tích hỵp

hƯ thèng trän vĐn
6. Thư

nghiệm thống anpha,bêta,Thử nghiệm hệ
chấp thuận
6.1 i th Thnh lp i th

nghiệm 15/04 30/04 Bình

6.2 Các ca
thử

Chuẩn bị các thủ
tục thử và các ca

thử

1/05 31/05 6.1 Bình,
Kim
6.3 Thiết bị

</div>
(176)<div class='page_container' data-page=176>

6.4 Lp t

anpha Lp t hệ thốngvị trí anpha 1/05 15/05 6.3
6.5 Thử

nghiƯm

anpha

Thư nghiƯm hƯ
thèng chức năng

y tI v trớ
anpha

15/05 30/06 6.2,
6.4

Kim,
Kiờn
6.6 Lp t

bêta

Lp t thit b
anpha ti v trớ

bêta

1/07 5/07 6.5 Bảo

6.7 Thử
nghiệm

bêta

Chạy hệ thống

sống tạI vị trí

bêta

6/07 31/07 6.6 Kim,
Kiên
6.8 TRR Rà soát sự sẵn

sàng thử nghiệm
cho việc thử
nghiệm chấp

thuận

30/07 31/07 6.7 Kiên

6.9 ATP Chp thun th
tc th nghim
hon tt vic

phát triển hệ
thống

1/08 4/08 6.8 Bình,
Kiên

6.10 Báo cáo
thử
nghiệm

Chuẩn bị các báo
cáo thư nghiƯm

ATP

5/08 8/08 6.9 Yªn

Bảng 9.2 có thí dụ về một phần của danh mục hoạt động theo lịch của
dự án. Bảng nêu hai hoạt động chủ yếu hợp nhất và thử nghiệm danh mục
hoạt động theo lịch có chứa thông tin sau:

1. Hoạt động ID. Đây là sự nhận biết thập phân có ý nghĩa t-ơng tự

hoạt động phù hợp với các phân loại bố trí cơng việc (coi Hình 6.6)

2. Tên hoạt động. Điều này t-ơng tự với nhận biết bằng số và đ-ợc sử

dụng tham chiếu hoạt động thích hợp

3. Mơ tả. Đây là mơ tả vắn tắt hoạt động

4. Ngày khởi công. Điều này liên quan đến ngày hoạt động bắt đầu

theo lÞch

5. Ngày hồn thành. Điều này liên quan đến ngày hoạt động phải

hoµn tÊt theo kÞch

6. Các phụ thuộc. Điều này liên quan đến các hoạt động khác mà hoạt

động này tuỳ thuộc. Hoạt động này khơng thể hồn thành cho đến khi các
hoạt ng ph thuc hon tt.

7. Uỷ nhiệm/trách nhiệm. Điều này nhận biết ng-ời đ-ợc giao trách

</div>
(177)<div class='page_container' data-page=177>

Mi hot động dự án theo lịch lên danh sách cùng với thông tin trên ở
giai đoạn này điều quan trọng là đảm bảo các hoạt động khơng chồng
chéo, điều này có nghiã khơng có 2 hoạt động mức cao bao gồm cùng
hoạt đông mức thấp. Cuối cùng danh mục theo lịch đ-ợc phân loại phù
hợp với ngày khởi động các hoạt động. Thủ tục này cung cấp hình thức
cơ bản nhất ca lch d ỏn.

9.2.2. Các cột mốc và đ-ờng mốc chđ u

Rõ ràng khơng phải mọi hoạt động có tầm quan trọng nh- nhau. Một
số hoạt động có ý nghĩa là những sự kiện lớn trong chu kỳ phát triển của
dự án. việc hoàn thành đặc tả yêu cầu là cột mốc chủ yếu khi hoàn thành
đặc tả thiết kế. Các sự kiện chủ yếu khác có thể bao gồm việc hoàn thành
một nguyên mẫu hay thiết lập hệ thống thử nghiệm bêta đầu tiên. Tất
nhiên sự kiện dự án quan trọng nhất là kết thúc dự án, th-ờng thể hiện ở
việc hoàn thành các thử nghiệm nghiệm thu. Những sự kiện quan trọng
đó xứng đáng đ-ợc chú ý đặc biệt và đ-ợc ghi lại trong danh sách riêng
các cột mốc dự án chủ yếu.

Những cột mốc dự án chủ yếu th-ờng có thêm đ-ợc tầm quan trọng do
nó liên quan đến các sự kiện khác, nh- thanh toán ngân sách phát triển.
Các thanh toán dự án giá cố định th-ờng liên quan với khách hàng về
việc hoàn tất thành công một số cột mốc đã thoả thuận. Điều này tạo ra
sức ép đáng kể với ng-ời quản lý dự án trong việc hồn thành cột mốc

đúng hạn (khơng nghi ngờ gì nó chính là ý định của khách hàng). Dù sao,
các lịch giống nh- bất cứ bộ phận nào khác của kế hoạch phát triển, cần
đ-ợc cập nhật định kỳ và th-ờng là vì lợi ích tốt nhất của dự án trong việc
sửa đổi ngày hoàn tất cột mốc. Không phải luôn đ-ợc khách công nhận
một sự thật rằng đôi khi khách hàng phải hành động trái với lợi ích tốt
nhất của chính mình.

Những vấn đề này khơng cần thiết đ-ợc ứng dụng cho các dự án nội bộ
khi khách hàng và đội phát triển là một phần của cùng một tổ chức.
Trong những tr-ờng hợp đó khách hàng có thể là bộ phận tiếp thị hay một
nhóm ng-ời dùng trong công ty. Những thay đổi về ngân sách theo đó
đ-ợc cấp quản lý chung cho phép có thể nhạy bén với nhu cầu của cả
khách hàng nội bộ và đội phát triển dự án. Các cột mốc đ-ợc dùng khơng
chỉ làm điểm thanh tốn nh-ng cũng để đo tiến độ dự án và xác định
đ-ờng mốc.

NÕu cét mèc đ-ợc mô tả nh- là sự kiện dự án chủ yếu thì các đ-ờng
mốc có thể đ-ợc mô tả là cột mốc chủ yếu. Định nghĩa của IEEE về từ

-ng mốc có câu “đặc tả thoả thuận chính thức dùng làm cơ sở cho phát

</div>
(178)<div class='page_container' data-page=178>

đ-ợc hoàn thiện. Chẳng hạn, 2167 dành cố gắng đáng kể cho các thủ tục
chấp thuận đối với các đ-ờng mốc dự án phần mềm.

Th-ờng đ-ờng mốc dự án đầu tiên là văn bản đặc tả yêu cầu của hệ
thống đ-ợc chấp thuận, gọi là đ-ờng mốc chức năng. Văn bản này là cơ
sở cho mọi thiết kế và thi công và đặc biệt đó là cơ sở cho thử nghiệm và
chấp nhận hệ thống. Do đấy nó th-ờng đ-ợc coi là đ-ờng mốc dự án quan
trọng nhất. Các thí dụ về các đ-ờng mốc dự án khác là thiết kế hệ thống
và th-ờng là nguyên mẫu hệ thống nếu d-ợc chấp nhận là cơ sở cho phát

triển dự án sau này (coi phần 8.2.2).

9.3. Các biểu đồ GANTT

Tr-ớc khi có máy tính ra đời rất nhiều, Henry L. Gantt đã lấy tên mình
đặt cho biểu diễn đồ thị đơn giản và rất có ích về lịch phát triển dự án.
Biểu đồ GANTT cho thấy hầu hết thơng tin có trong danh sách hoạt động
của lịch theo một cách dễ hiểu hơn. Thông tin theo lịch dễ nắm bắt và
hiểu và các hoạt động có thể so sánh dễ dàng. Biểu đồ GANTT giúp
chúng ta nhìn thấy vào bất cứ lúc nào có những hoạt động gì hẳn là đang
diễn ra trong dự án đó.

Hình 9.1 là một thí dụ điển hình về biểu đồ GANTT. Các ký hiệu đ-ợc
dùng trong biểu đồ là đ-ợc chấp nhận một cách rộng rãi, mặc dù là chúng
ch-a đ-ợc chuẩn hoá. Chẳng hạn, mỗi tam giác ng-ợc th-ờng đ-ợc dùng
để chỉmột sự kiện đáng kể, ví nh- là các cột mốc.

Biểu đồ GANTT trong hình 9.1 thuyết minh cáI sự dễ dàng nhanh
chóng nhận thức đ-ợc các thơng tin lập lịch quan trọng. Chúng ta có thể
trực tiếp thấy ngay rằng không kể đến pha bảo trì, mọi pha khác đều gối
đầu nhau, và rằng trong khoảng thời gian từ tháng 11 đến giữa tháng 12
năm 1992 thì ba hoạt động mức cao là gối đầu nhau.

Một biểu đồ chi tiết hơn cũng có thể bao gồm các tên của các kỹ
s-gắn với từng hoạt động và bao gồm các thiết bị cần thiết cho từng hoạt
động một. Thơng tin này có thể đ-ợc thêm vào bên cạnh đ-ờng thời gian
hoạt động trong đồ thị đó, hoặc là một bảng tham khảo lồng vào bên
(t-ơng tự nh- danh sách các cột mốc chủ yếu trong hình 9.1). Một vài
biến thể của biểu đồ GANTT thực cũng đã bao gồm kiểu thơng tin đó
trên biểu đồ, nh-ng chúng có thể gây ra sự lộn xộn, mà nh- thế lại mâu

thuẫn với chính mục tiêu của biểu đồ đó: làm cho ng-ời ta có thể dễ dàng
nhanh chúng nm bt cỏc thụng tin lch trỡnh.

Phân tích yêu cầu
Thiết kế mức cao
Thiết kế chi tiết

SRR

PDR

CDR

</div>
(179)<div class='page_container' data-page=179>

Hình 9.1

Biểu đồ GANTT mức cao - lịch phát triển dự án

Một điều quan trọng là cũng phải hiểu biểu đồ GANTT khơng cung
cấp những thứ gì. Trong một biểu đồ GANTT, rất khó cung cấp các thơng
tin về khối l-ợng các nguồn lực cần đến để hoàn thành từng hoạt động.
Một sự nhầm lẫn th-ờng thấy là ng-ời ta kết luận rằng nếu 5 kỹ s- đ-ợc
trao trách nhiệm tích hợp và hoạt động tích hợp đ-ợc bắt đầu khoảng giữa
tháng 9 năm 1992 và kết thúc vào giữa tháng 1 năm 1993 (bốn tháng), thì
việc tích hợp địi hỏi 20 tháng cơng. Sự thật là, việc tích hợp có thể chỉ
bắt đầu với 1 kỹ s-, tháng thứ hai thêm một kỹ s- nữa, còn ba ng-ời còn
lại đ-ợc thêm vào tháng thứ ba. Đội tích hợp sau đó lại có thể giảm cịn

ba kỹ s- trong tháng thứ t-.

Hình 9.1 chỉ có bảy hoạt động khi có đ-ợc thêm chi tiết nhiều hoạt
động mức thấp hơn có thể đ-ợc đ-a vào biểu đồ khi biểu đồ có nhiều
hoạt động hơn mức hợp lý có thể đ-ợc (quyết định chủ quan) thì các biểu
đồ bổ sung có thể đ-ợc thêm vào chẳng hạn hoạt động thiết kế có thể
trình bày trên biểu đồ GANTT riêng biệt (coi Hình 9.2).

Hình 9.2 giới thiệu cả hoạt động mức cao và mức thấp. Chẳng hạn,
‘tích hợp mơ hình pha I’ có ba hoạt động mức thấp: ‘tích hợp phần tiến
hành’, “tích hợp hệ điều hành’ và ‘tích hợp giao diện ng-ời dùng’. Điều
này tạo ra một sự nối kết liên tục giữa biểu đồ GANTT chi tiết (Hình
9.2) và biểu đồ mức cao (Hỡnh 9.1).

Thi công
Tích hợp
Thử nghiệm

Bảo trì

1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6

1992 1993

C¸c cét mèc chđ u
SRR = Rà soát yêu cầu phần mềm

PDR = Rà soát thiết kế sơ khởi
CDR = Rà soát thiết kế tới hạn
TRR = Rà soát thử nghiệm

ATP = Thủ tục thử nghiệm chÊp thuËn

TRR



ATP



</div>
(180)<div class='page_container' data-page=180>

H×nh 9.2

Biểu đồ GANTT chi tiết - lịch tích hợp

Nên nhớ là mỗi thời kỳ một tháng trong Hình 9.2 đã đ-ợc phân thành 4
tuần. Mặc dầu khơng hồn tồn chính xác đây là xấp xỉ thơng th-ờng
cũng sử dụng trong dự tốn (coi ch-ơng 10) và ngồi tính thuận tiện nó
cũng tạo ra một số khe hở cho các điều chỉnh nhỏ theo lịch.

Các biểu đồ GANTT chi tiết t-ơng tự có thể đ-ợc chuẩn bị cho mỗi
một giai đoạn phát triển dự án chủ yếu. Các hoạt động không phát triển
cũng xuất hiện trên biểu đó GANTT nh- cung cấp cơng cụ phát triển hay
nghiên cứu thị tr-ờng. Điều này đặc biệt có ích khi một số hoạt động phát
triển nào đó tuỳ thuộc ở các hoạt động không phát triển khác nh- cung
cấp cơng cụ phát triển (thí dụ bộ biên dịch cần thiết phải đ-ợc hoàn thành
tr-ớc khi các hoạt động thi cơng có thể bắt đầu. Tr-ờng hợp mà những
quan hệ tuỳ thuộc nh- thế có thể bỏ qua, chúng sẽ th-ờng xuất diện ở
việc rà soát lại của biểu đồ GANTT. Loại tuỳ thuộc này giữa các hoạt
động đ-ợc trình diễn tốt nhất trong loại biểu đồ khác, gọi là biểu đồ

mạng quan hệ tr-ớc-sau hay biểu đồ PERT.

9.4. Các biểu đồ PERT và đ-ờng tới hạn.

TRR



TÝch hỵp gi/diƯn ph/cøng
TÝch hợp truyền thông

T/hp h thng y

Tích hợp máy chủ

Thử thủ tục sẵn sàng

15/9 10 11 12 1

1992 1993

Tích hợp mô hình pha II
Tích hợp giao diện ng: s/d

Tích hợp hệ điều
hành

Tích hợp phần tiến
hành

</div>
(181)<div class='page_container' data-page=181>

Giai thoi phũng khơng liên quan ở đầu ch-ơng này cung cấp thí dụ
tuyệt vời về sự lệ thuộc giũa các hoạt đông theo lịch. Sự tuỳ thuộc diễn ra
khi một hoạt động này khơng thể thực hiện nếu khơng có một hoạt động
khác đã đ-ợc thực hiện. Kỹ thuật đồ thị đ-ợc gọi là biểu đồ quan hệ
tr-ớc-sau có thể cung cấp câu trả lời cho hai trong các vấn đề liên quan
trong giai thoại này: nhu cầu nhận ra các tuỳ thuộc và nhu cầu đảm bảo
trách nhiệm này đối với mỗi nhiệm vụ đã đ-ợc giao.

Kỹ thuật rà soát lại và đánh giá ch-ơng trình (PERT)46 sử dụng mạng

quan hệ tr-ớc-sau để lập kế hoạch các hoạt động dự án và khống chế sự
thực hiện chúng một cách hiệu quả. Giống nh- biểu đồ GANTT có nhiều
loại biến thể của biểu đồ PERT. Kỹ thuật PERT qui -ớc cơ bản mô tả
một mạng với các node (mấu) là các sự kiện và các cung nối là các hoạt
động.

Mỗi hoạt động liên kết với hai sự kiện liên quan đầu và cuối. Node kết
thúc của một hoạt động có thể trùng với node đầu hoạt động thứ hai, khi
mà sự thực hiện của hoạt động thứ hai tuỳ thuộc ở sự thực hiện của hoàn
thành của hoạt động thứ nhất. Điều này có nghĩa một hoạt động chỉ có
thể đ-ợc thực hiện khi mọi hoạt động khác kết thúc ở node khởi điểm của
chúng đã đ-ợc hồn thành.

Hình 9.3 cho thấy một thí dụ của biểu đồ mạng PERT biểu thị dòng
hoạt động của dự án từ node khởi điểm tới node kết thúc. Mỗi sự kiện
đ-ợc biểu thị bằng một vịng trịn có đánh số mạng bắt đầu bằng sự kiện
khởi điểm, gọi là node nguồn và kết thúc bằng sự kiện kết thúc gọi là
node chìm. Mỗi đ-ờng liên kết biểu thị một hoạt động dự án. Hoạt động
Ai,j mô tả hoạt động bắt đầu với sự kiện i và kết thúc ở sự kiện j. Thuộc số
Di,j biểu thị l-ợng thời gian trôi theo lịch, giữa khởi đầu và kết thúc của

hoạt động Ai,j.

Một khía cạnh quan trọng của ph-ơng pháp biểu đồ PERT là quan
niệm các hoạt động song hành. Mỗi node sự kiện bắt nhánh vào một số
hoạt động có thể thực hiện song hành. Trong hình 9.3 các hoạt động A1,2,
A1,3và A1,4có thể thực hiện song hành. Dù sao mỗi một hoạt động AS,1và

A10,E không thể thực hiện song song với bất cứ hoạt động nào khác.
Chúng ta cũng có thể thấy ở biểu đồ là hoạt động A3,6có thể thực hiện
song song với hoạt động A5,8hay hoạt động A8,10nh-ng không với cả hai.
T-ơng tự, ở một thời điểm đã cho nào đó hoạt động A3,6có thể thực hiện
song song với chỉ một trong ba hot ng A1,4, A4,7v A7,9.

46Một mô tả chi tiết và chÝnh x¸c cđa kü tht PERT xt hiƯn trong Gillett (1976)

2 AS,1 5

DS,1 AS,1

</div>
(182)<div class='page_container' data-page=182>

H×nh 9.3

Một biểu đồ PERTđiển hình

H×nh 9.4

Một biểu đồPERTcó chỉ ra đ-ờng tới hạn

Hình 9.4 là một thí dụ của biểu đồ PERT bao gồm nhiều thuộc tính
thời hạn bằng số chúng ta có thể thấy ở biểu đồ là hoạt động A5,1đ-ợc lập

lịch để tiếp tục trong 5 dơn vị thời gian (có thể là tuần) khi lịch cần đ-ợc
rút ngắn các giá trị thời hạn đó có thể rất có ích cho ng-ời quản lý dự án

AS,1
DS,1
AS,1
DS,1
AS,1
DS,1
AS,1
DS,1
S
8
4 7
E
9
6
3
1
AS,1

DS,1 A

S,1
DS,1
AS,1
DS,1
AS,1
DS,1

AS,1

DS,1 DS,1AS,1

AS,1

DS,1

AS,1

DS,1

Ai,j= Hoạt động bắt đầu tại node i và kết thúc tại node j.
Di,j= Thời gian của hoạt động Ai,j

AS,1
3
AS,1
5
AS,1
4
AS,1
12
AS,1

6 AS,1

2
AS,1
12

AS,1
8
AS,1
5
AS,1
3
AS,1
10
AS,1
6
AS,1
6
AS,1
11
S
2 5
8
4 7
E
1
0
9
6
3
1

</div>
(183)<div class='page_container' data-page=183>

giá trị thời hạn có thể giúp định vị lĩnh vực mà cố gắng bổ sung đ-ợc tốt
nhất.

9.4.1.Con ®-êng tíi h¹n.

Khủng hoảng của các lịch phát triển dự án là phổ biến mà những nhà
quản lý dự án phải tiên liệu.Những dự án lớn có nhiều phần liên quan
trong việc lên lịch nh- quản lý tập đoàn, khách hàng chủ thầu phụ, ng-ời
bán, ng-ời dùng, bộ phận tiếp thịv.v. Một trong những khủng hoảng
th-ờng gặp nhất là về nhu cầu rút ngắn lịch. Một sai lầm chung về phía
ng-ời quản lý dự án là cho rằng bất cứ một cố gắng phụ cũng sẽ rút ngắn
đ-ợc lịch. Dù sao trong một số tr-ờng hợp những hoạt động rút ngắn sẽ
tuyệt đối khơng tác động gì đến thời hạn tổng thể của lịch.

Nhằm xem xét hiện t-ợng này tr-ớc hết chúng ta phải hiểu là trong
mọi mạng không tầm th-ờng có nhiều đ-ờng chuyển tin node nguồn tới
node chìm. chẳng hạn trong hình 9.4 con đ-ờng khả dĩ chạy từ node S tới
1 tới 3 tới 6 tới 9 tới 10 tới E. Một con đ-ờng khả dĩ khác chạy từ nút S
tới 1 tới 2 tới 5 tới 8 tới 10 tới E. Mỗi con đ-ờng có thể đ-ợc đặc tr-ng
bằng con số biểu thị tổng thời hạn của con đ-ờng,đ-ợc tính bằng cách lấy
tổng số các thời hạn cho mọi hoạt động dọc con đ-ờng.

Bảng 9.3 có danh mục mọi con đ-ờng khả dĩ từ nút S tới nút E trong
biểu đồ PERT ở hình 9.4 cùng với độ dài của mỗi con đ-ờng. Con đ-ờng
2 là dài nhất, 52 tuần. Con đ-ờng dài nhất đ-ợc coi là con đ-ờng tới hạn
xác định thời hạn của dự án.

Khi rút ngắn thời hạn hoạt động của một hoạt động dọc con đ-ờng tới
hạn, th-ờng chúng ta có thể rút ngắn đ-ợc thời hạn của tồn dự án. có ít
tr-ờng hợp thái cực mà điều này sẽ không diễn ra chủ yếu khi có hai con
đ-ờng tới hạn. Dù sao có một điều là chắc chắn rút ngắn hoạt động khơng
có trên con đ-ờng tới hạn sẽ khơng rút ngắn đ-ợc chiều dài của tồn bộ
dự án.

B¶ng 9.3 Mäi con đ-ờng khả dĩ từ S tới E (căn cứ ở Hình 9.4)

Con đ-ờng Độ dài Con đ-ờng tới hạn
1. S.1.2.5.8.10.E 41

2. S. 1.3.5.8.10.E 52
3. S. 2.3.6.9.10.E 30
4. S. 1.4.7.9.10.E 34

9.4.2. Khối ch-ơng trình và nâng cao PERT.

</div>
(184)<div class='page_container' data-page=184>

Một ứng dụng lý thú của PERT đ-ợc gọi là biểu diễn đồ thị dòng chảy
mà Riggs và Jones (1990) xây dựng sử dụng mạng quan hệ tr-ớc-sau
hoàn thiện phân tích chi phí chu kỳ vịng đời của dự án. Kỹ thuật biểu đồ
dịng chảy phân tích chi phí dự án dựa trên quan hệ giữa l-ợng, giá đơn
vị, biến số thời gian, chi phí nhân lực và học tập v.v. tất cả đều đ-ợc biểu
thị trên biểu đồ loại PERT.

Kỹ thuật biểu diễn bằng biểu đồ dòng chảy đặt một l-ợng thông tin
đáng kể vào biểu đồ mạng. Thông tin này đứng nh- thông tin cơ bản
PERT phải đ-ợc th-ờng xuyên cập nhật. Một thay đổi nhỏ cho biểu đồ
PERT rộng lớn có thể địi hỏi vẽ loại tồn bộ biểu đồ và tính tốn lại con
đ-ờng tới hạn. Sự tẻ nhạt xảy ra không thúc đảy thêm hào hứng trong
việc giữ cho biểu đồ cập nhật. Vì lý do đó nhiều tiện ích PERT máy tính
hố đã hình thành.

Khối ch-ơng trình phần mềm PERT đã có tác dụng trong nhiều năm
nay rồi, nh-ng chỉ trong vài năm qua thì khối ch-ơng trình PERT chuyên
nghiệp tốt mới dùng đ-ợc trên máy tính cá nhân và các máy tính nhỏ
khác. Những khối ch-ơng trình đó đã làm cho việc chuẩn bị các biểu đồ

PERT bớt tẻ nhạt nhiều và cũng đáp ứng đ-ợc các đặc điểm phụ nh- các
bộ phân tích kế hoạch trong việc bố trí hoạt động, kịch bản “what if” và
phân bố nguồn lực. Những tiện ích máy tính đã đ-ợc ra đời để hồn thiện
phân tích, biểu diễn bằng biểu đồ dòng chảy tạo ra những chi phí theo
lịch cho các hoạt động dự án chủ yếu47. Các tiện ích này đã tỏ ra vơ giá

cho các nhà quản lý dự án và giải phóng nhà quản lý khỏi công việc bàn
gấy căm cụi, tạo cho họ có nhiều thời gian hơn để quản lý tích cc d ỏn.

9.5. Nhân viên lập lịch

Phn ny dnh cho khía cạnh lập lịch bộ máy và quản lý nhân lực.
Động cơ và quản lý con ng-ời đ-ợc bàn đến ở ch-ơng 5.

Về cơ bản, đội phát triển là nguồn lực đúng y nh- thiết bị phát triển là
nguồn lực. Dù sao lập lịch nhân lực không nh- lập lịch thiết bị, nguồn lực
dự án quan trọng nhất của ng-ời quản lý dự án là đội phát triển và do đó
cần quan tâm đặc biệt tới việc lập lịch các hoạt động của các thành viên
trong đội. Khi số l-ợng các hoạt động của dự án thay đổi thì qui mơ của
đội phát triển cũng thay đổi trong suốt vịng đời phát triển của dự án. Cơ
cấu tổ chức của đội trở nên quan trọng hơn khi qui mô của đội tăng.

9.5.1. Qui mô đội phát triển.

Qui mô đội phát triển chịu ảnh h-ởng không chỉ ở số l-ơng mà còn ở
c-ờng độ hpạt động. Một số hoạt động là khẩn tr-ơng lúc khởi đầu dự án
và suy thoái vào lúc kết thúc và ng-ợc lại. Chẳng hạn việc quy hoạch đỏi

47 Riggs vµ Jones (1990) trong tham ln cđa mình về phân tích chi phí dự án mô tả

</div>
(185)<div class='page_container' data-page=185>

hỏi nguồn nhân lực nhiều hơn ở lúc khởi đầu dự án và ít hơn lúc kết thúc
trong khi đó kiểm tra cấu hình đỏi hỏi ít hơn ở lúc đầu và nhiều hơn ở lúc
cuối.

LËp kÕ ho¹ch

KiĨm tra

Yêu cầu Thiết kế Thực thi Tích hợp Thử nghiệm

Hình 9.5

Chứng minh mối quan hệ giữa quy hoạch và kiểm tra

Hình 9.5 chứng minh mối quan hệ giữa qui hoạch và kiểm tra khi
c-ờng độ quy hoạch giảm sẽ cần ít ng-ời hơn cho hoạt động này. T-ơng
tự khi c-ờng độ kiểm tra tăng sẽ cần nhiều ng-ời hơn cho những hoạt
động nh- thử nghiệm, bảo đảm chất l-ợng và quản lý cấu hình.

Qui mơ đội th-ờng biến thiên ứng theo với phân bố chuẩn hình
chng. Điều này đ-ợc chỉ ra ở hình 9.6 (a) mơ tả đội phát triển nhỏ lúc
khởi đầu dự án, đội phát triển lớn trong những giai đoạn giữa dự án và rồi
lại đội nhỏ vào cuối dự án.

ở hai đầu của chu kỳ phát triển khi qui mô đội là nhỏ, nhiều những
chức năng tổ chức là không cần thiết. Trong nhiều tr-ờng hợp các cơ cấu
đội chỉ trở nên cần thiết vào cuối giai đoạn yêu cầu.Khi dự án gần hoàn
thành các đội có thể đ-ợc giải thể và một hay hai thành viên đội có thể
đảm nhận trách nhiệm cho cơng việc phát triển của tồn đội.

Trong vài tr-ờng hợp hình 9.6 (a) có thể khơng biểu thị lập lịch của đội
phát triển đủ chính xác. Hình 9.6 (b) cho thấy đ-ờng cong lệch không
cân xứng t-ơng tự phân bố th-ờng mô tả tỉ suất nhân sự chậm hơn lúc
khởi đầu dự án và qui mô nhân sự suy giảm nhanh vào lúc cuối. Điều
này thơng th-ờng điển hình của các dự án phức tạp khi các giai đoạn hợp
nhất và thử nghiệm đòi hỏi cố gắng lớn. Trên thực tế, đ-ờng biểu diễn
lệch nói chung tiêu biểu cho lập lịch đội ngũ hơn đ-ờng biểu diễn chuẩn
mặc dù mức độ nghiêng của đ-ờng biểu diễn thay đổi.

</div>
(186)<div class='page_container' data-page=186>

T0 tm te

(a)

Trục tung là qui mô đội phát triển, M là qui mụ ti a, T0l khi u d ỏn,

tmlà điểm nhân sự tối đa, telà kết thúc dự án.

T0 tm te

(b)

H×nh 9.6

Phân bố qui mơ đội phát triển (a) bình th-ng (b) lch

</div>
(187)<div class='page_container' data-page=187>

T0 tm te Bảo trì

Trc tung là qui mô đội phát triển, M là qui mụ ti a, T0l khi u d ỏn,

tmlà điểm nhân sự tối đa, telà kết thúc dự án.

Hình 9.7

Phõn b qui mơ đội, kể cả bảo trì

Cách mà giai đoạn bảo trì đ-ợc xét đến tác động đến đ-ờng cong nhân
sự. đ-ờng cong nhân sự sẽ trông khác đi nếu giai đoạn bảo trì đ-ợc coi
nh- bộ phận của chu kỳ phát triển. Đ-ờng biểu diễn hình thành nh- trong
hình 9.7 có góc hơi đi xuống tiếp tục suốt giai đoạn bảo trì.

Hình 9.8 mơ tả chức năng phân bố qui mô đội ngũ khả dĩ trong một dự
án cỡ vừa với qui mô đội ngũ tối đa là 18. Lúc đầu với qui mô đội là ba,
kiểm tra cấu hình và đảm bảo chất l-ợng sẽ do ng-ời quản lý dự án tiến
hành, Khi đội tăng lên tám, những trách nhiệm đó sẽ đ-ợc giao cho một
thành viên đội cũng có thể hồn thành các nhiệm vụ khác48. Khi đội tăng

lên 12 sẽ cần một kỹ s- khống chế cấu hình và một kỹ s- đảm bảo chất
l-ợng ít ra nửa thời gian khi đội tăng đến qui mô cao điểm hai kỹ sự này
sẽ phải yêu cầu làm trọn thời gian.

Qui mô đội đ-ợc xác định bởi tổng số ng-ời đ-ợc uỷ thác vào dự án.
Dù sao khi lập lịch qui mơ đội. Việc bố trí 2 ng-ời mỗi ng-ời cho nửa
phần uỷ thác trọn ngày không nhất thiết bằng việc uỷ thác một ng-ời trọn
ngày. Trong những tr-ờng hợp đó nh- bảo đảm chất l-ợng hay kiểm tra
cấu hình, chi phí cho dự án về uỷ thác những hoạt động đó có thể đ-ợc
giảm khi chia những chức năng đó với các dự án khác. Điều này đặc biệt
đúng với các dự án nhỏ.Thử nghiệm là một thí dụ khác của nguồn nhân
lực chia xẻ giữa các dự án, Nhiều tổ chức có một đội thử nghiệm độc lập

không trực tiếp là một bộ phận của đội dự án, Đội thử nghiệm độc lập trở
thành tham gia vào dự án chủ yếu vào cuối chu kỳ phát triển (mặc dù một
số hoạt động thử nghiệm tiến hành sớm hơn nhiều). Những đội nh- thế

48Không phải bao giờ cũng có thể giao các hoạt động kiểm tra cấu hình và bảo đảm chất

</div>
(188)<div class='page_container' data-page=188>

có thể chuyển từ dự án này sang dự án khác miễn là các hoạt động thử
nghiệm đã đ-ợc lập lịch thích hợp.

18 Tích hợp

16 Thi công

Thiết kế

12 Thử nghiệm

Yêu cầu

8
6

4 Thiết lập dự án

Kết thúc dự án

Hình 9.8

Thớ d v qui mụ i phỏt trin

9.5.2. Kỹ năng và kinh nghiệm

Vic lp lch nhân lực khơng chính chỉ là tr-ờng hợp bố trí số ng-ời
vào mỗi giai đoạn của dự án. Những kỹ năng đặc tr-ng đ-ợc yêu cầu cho
mỗi hoạt động và những ng-ời chun mơn có kinh nghiệm thích hợp
phải đ-ợc uỷ thác nhiệm vụ cho những hoạt động đó. Bảng 9.4 cho danh
mục một số các hạng nhân lực cần cho mỗi giai đoạn phát triển của dự
án. Không phải mọi dự án yêu cầu mọi hạng nhân lực nh- trong truờng
hợp những dự án nhỏ khi hai hay nhiều c-ơng vị của dự án có thể do một
ng-ời đảm nhn.

Bảng 9.4 phân loại các c-ơng vị dự án phần mềm

Phân loại C-ơng vị dự án

Nhà quản lý Quản lý dự án, Đội tr-ởng, Kỹ s- hệ thống
Quản trị viên Th- ký, Trợ lý hành chính

Khng ch cu hỡnh Nh quản lý cấu hình, Ng-ời khống chế cấu hình
Bảo đảm chất l-ợng Quản lý chất l-ợng, Kỹ s- quản lý chất l-ợng
Phân tích và thiết kế Phân tích hệ thống, K s- thit k

Ng-ời lập mÃ Lập trình viên
Ng-ời viết tài liệu

kỹ thuật Ng-ời viết t- liệu, Ng-ời biên tập

</div>
(189)<div class='page_container' data-page=189>

Mặc dù bảng 9.4 xét đến các c-ơng vị nghề nghiệp khác nhau địi hỏi
chun mơn khác nhau ln có lợi thế khi các trình độ chun mơn của
thành viên đội đ-ợc mềm mỏng. Nh- thế có thể bố trí lại các thành viên
đội trong dự án, do đó tiết kiệm đ-ợc chi phí con đ-ờng biểu diễn học tập
th-ờng cần thiết để lập lịch cho những thành viên đội mới.

Hoạt động của đ-ờng biểu diễn học tập th-ờng bị xao lãng. Việc làm
quen dự án đối với các thành viên mới không chỉ là truờng hợp duy nhất
khi có chi phí của đ-ờng biểu diễn học tập. Đào tạo cũng là yếu tố quan
trọng phải đ-ợc lập lịch. Dù sao không phải mọi nhu cầu đào tạo đề có
thể biết ngay đ-ợc trong những giai đoạn đầu của dự án. Những yêu cầu
đào tạo trở nên rõ rệt khi có các qui định liên quan đến mơi tr-ờng phát
triển (nh- ngơn ngữ lập trình, các máy tính để phát triển v.v.) và khi các
thành viên đội đ-ợc lựa chọn và kỹ năng cùng kinh nghiệm của họ đ-ợc
biết.

Có nhiều vấn đề liên quan đến việc lập lịch nhân lực. Kinh nghiệm và
kỹ năng của thành viên không là những độ đo tin cậy về sự hồn thiện
trơng đợi. Việc lập lịch các kỹ s- căn cứ ở những đức tính giả định đo
đ-ợc đã từ lâu là một đề tài tranh cãi. Sackman và cộng sự vào đầu những
năm 1968 có báo cáo về các tính đa dạng bản chất trong việc hồn thành
cơng việc của ng-ời lập trình phần mềm và đ-ợc trao đổi thêm ở ch-ng
5 v ch-ng 10.

9.5.3. Tháng công

Ngun gc sai lm ph biến khác khi lập lịch nhân lực là sự khác nhau

trong cách mà từ “man month” (hay nh- bây giờ đ-ợc gọi là workmonth)
đ-ợc dùng. Nếu ng-ời quản lý dự án tính tốn rằng một hoạt động đã
đ-ợc lập lịch địi hỏi sáu tháng làm việc để hồn thành, thì phải chăng
điều đó có nghĩa là một kỹ s- thích hợp đ-ợc bố trí làm việc trong 6
tháng thì hoạt động đó có thể hồn thành trong sáu tháng?

Phải! câu trả lời . . . là “có thể”. Trong nhiều tr-ờng hợp, hoạt động đó
khơng thể hồn thành trong 6 tháng vì một ng-ời ít khi có đ-ợc 6 tháng
làm việc trong thời hạn lịch 6 tháng. Con ng-ời phải nghỉ hè, họ tổ chức
nghỉ lễ và đôi khi họ ốm. Nói chung con ng-ời có khoảng 8 và 10 tháng
làm việc trong một thời kỳ 12 tháng. Điều này phải xét đến khi chuẩn bị
lịch trình.

Khi những ng-ời quản lý dự án báo cáo cấp trên là dự án sẽ đòi hỏi
đầu t- trong 6 năm họ phải biết rõ về loại năm nào họ nói. Điều đó là 6
năm lịch có nghĩa dự án chỉ có thể hồn thành 6 năm kể từ ngày khởi
cơng? Hay đó là 6 năm làm việc có nghĩa có 72 tháng làm việc để hồn
thành có thể đ-ợc chia cho số nhân lực? hay đó thực ra là 48 tháng cơng
với phụ thêm nghỉ hè, nghỉ lễ, nghỉ ốm ?

</div>
(190)<div class='page_container' data-page=190>

thời gian bất kể có bao nhiêu ng-ời đ-ợc bố trí. Do đó ý nghĩa của thời
hạn dự án cũng nh- thời hạn của mỗi hoạt động chủ yếu phải đ-ợc hiểu
rõ ràng và trình bày nh- bộ phận của lập lịch. Lập lịch phải tính đến cả
tình trạng vơ trách nhiệm, chi phí hành chính (thảo luận họp hành và cả
nói chuyện khơng đâu) và phải giải thích những hoạt động nào không thể
rút ngắn và hoạt động nào có thể.

Giảm thời hạn của hoạt động có cái giá của nó. Thêm nhiều ng-ời vào
dự án này sinh thêm tổng phí. Nếu năm ng-ời có thể phát triển dự án
trong 2 năm điều đó khơng phải là 10 ng-ời có thể phát triển dự án trong

1 năm. Điều này là do liên lạc phụ giữa các thành viên cần nhiều cuộc
họp hơn, nhiều phối hợp hơn, nhiều quản lý và quản trị hơn. Và tất nhiên,
ng-ời ta không thể tiếp tục giảm thời hạn hoạt động bằng cách bố trí
thêm nhiều nhiều ng-ời vào dự án. Luật phản hồi giảm dần có hiệu học
khi bố trí con ng-ời vào một dự án và ở điểm nào đó con ng-ời bắt đầu đi
theo con đ-ờng của nhau. Đóng góp số khơng và thậm chí cả số âm đúng
ra có thể đạt đến nhanh hơn khi mà một dự án đi vào phát triển tốt và
đ-ờng biểu diễn học tập trở nờn di v tn kộm.

9.6. lập lịch các Nguồn lực

Phn tr-ớc đây đã bàn đến việc lập lịch một nguồn lực tối quan trọng
của dự án đội phát triển. Nh-ng khơng có những cơng cụ cần thiết đội
phát triển khơng thể hi vọng làm đ-ợc việc tốt. Nếu máy tính mục tiêu
của dự án khơng có ngay khi pha tích hợp bắt đầu, thì pha tích hợp rất có
thể khơng bắt đầu tốt đ-ợc. Do đó chúng ta thấy là một dạng của nguyên
tắc đ-ờng tới hạn cũng vận dụng đ-ợc cho tính hiệu lực của các nguồn
lực phát triển. Điều này có nghĩa là nếu tính hiệu lực của một nguồn lực
tới hạn theo lịch bị chậm lại nó sẽ làm chậm việc hồn thành dự án.

Có những cách để xem xét các vấn đề tính hiệu lực cho các nguồn lực
tới hạn, nh- phân tích rủi ro.Mục tiêu là cung cấp những kế hoạch phịng
ngừa tình huống mà những nguồn lực tới hạn khơng có đ-ợc theo nh- lập
lịch. Phân tích rủi ro đ-ợc bàn thêm ở ch-ơng 2

9.6.1. Lập lịch không gian làm việc.

ca ra ca dự án, không gian làm việc đặc biệt không gian văn
phòng, th-ờng là một trong những nguồn lực chủ yếu đầu tiên yêu cầu.
Khu vực dự án phải đ-ợc bố trí tr-ớc và xác định rõ. khi dự án tiến

triển,khu vực làm việc yêu cầu sẽ tăng.

</div>
(191)<div class='page_container' data-page=191>

Kh«ng gian làm việc và văn phòng lập lịch là một trong những b-ớc
đầu tiên trong việc lập lịch nguồn lực. Yêu cầu không gian là hàm số
những yêu cầu nhân lực dự toán, yêu cầu thiết bị và lịch nhân sù cđa dù
¸n.

Bảng 9.5 có danh mục kiểm tra một số hạng mục phải xem xét khi lập
lịch không gian làm việc. Tất nhiên, không phải mọi chuyên đề đều vận
dụng đ-ợc cho mọi dự án. Lẽ dĩ nhiên, yêu cầu không gian hiện nay tuỳ
thuộc ở qui mô và thể loại mỗi dự án. Nhiều dự án quốc phòng và an ninh
đòi hỏi những khu vực tiếp cận hạn chế đặc biệt trong bảng kiểm tra đ-ợc
coi là khu vực an tồn. Hạng mục khác phịng l-u kho và kiểm kê, chỉ
yêu cầu cho các dự án bao gồm khi l-ng ln phn cng v thit b.

Bảng 9.5 Hạng mục không gian làm việc danh mục kiểm

tra

1. Không gian văn phòng quản lý

2. Không gian văn phòng hành chính th- ký
3. Phßng häp

4. Phịng đội phát triển và khơng gian bàn giấy
5. Phịng máy tính

6. Phßng thÝ nghiƯm

7. Khu vực hợp nhất và thử nghiệm
8. Khu vực ăn tr-a và giải trí

9. Phòng kho và kiểm kê
10.Khu vực an toàn.

9.6.2. Thiết bị lập lịch

Vi cụng c thớch hp cụng việc bao giờ cũng đ-ợc tiến hành tốt hơn.
Nh-ng nh- chúng ta đã thấy có đ-ợc cơng cụ thích hợp không đủ công cụ
phải đ-ợc sử dụng đúng lúc. Mục tiêu của việc lập lịch thiết bị là để đảm
bảo cơng cụ phát triển thích hợp có đ-ợc với số l-ợng đủ khi cần đến.

Trong những năm đầu của phát triển phần mềm, công cụ cơ bản bao
gồm ng-ời lập trình, bộ biên soạn và máy tính để lập mã. Công cụ phát
triển hiện đại ngày nay bao gồm nhiều hơn bộ biên soạn và máy tính. Các
tiện ích phần mềm từ các công cụ thiết kế hợp nhất tới công cụ gỡ rối và
thử nghiệm tinh vi giờ đây đã có. Trên thực tế máy tính đã đ-ợc tận dụng
nh- là trợ thủ cho ng-ời sản xuất hỗ trợ trong các hoạt động phát triển
đặc tr-ng, tạo nên từ cơng nghệ phần mềm hỗ trợ bằng máy tính hay
CASE.

</div>
(192)<div class='page_container' data-page=192>

tin, hệ thống quân sự, rôbốt và các hệ thơng cơng nghiệp. Trong những
tr-ờng hợp đó, thiết bị có mục đích đặc biệt đ-ợc u cầu cho các giai
đoạn thử nghiệm và hợp nhất. Văn phòng dự án trung tâm sau đó phải
phối hợp qui hoạch và lập lịch phát triển phần cứng và phần mềm đảm
bảo tính hiệu lực kịp thời của thiết bị phát triển.

Đảm bảo tính hiệu lực của thiết bị phát triển thích hợp là bộ phận quan
trọng của qui hoạch tốt. Nh-ng lập lịch kém có thể dẫn đến những tình
huống theo đó thành viên của đội phát triển bị để ngồi không hay phần
nào ngồi không chờ đợi thiết bị bàn giao. Ngay nếu các thành viên có thể

đ-ợc bố trí lại tạm thời thì hiệu qủa và tính hiệu lực của họ là ng-ời sản
xuất sẽ bị sút giảm đáng kể.

9.6.3. Ng-ời bán hàng và chủ thầu phụ

Khụng phi mi hot động lập lịch đều phụ thuộc trực tiếp ở ng-ời
quản lý dự án và đội phát triển. Thông th-ờng, các bộ phận ngoại cuộc lại
cũng tham gia vào việc phát triển dự án nh- chúng ta đã thấy, việc giao
thết bị kịp thời là cốt tử cho lịch phát triển và điều này th-ờng đòi hỏi sự
cung cấp của các bên ngoại cuộc.

Khơng phải khơng bình th-ờng, đặc biệt trong những dự án lớn hay
phức tạp, ở việc có hợp đồng phụ một số phần của dự án cho các cơng ti
có chun mơn đặc tr-ng ở những lĩnh vực liên quan. Điều này có nghĩa
là việc kiểm tra phát triển tực tiếp có thể giao cho chủ thầu phụ.

Khó có thể lập lịch các nguồn lực và hoạt động mà ng-ời quản lý dự án
khơng hồn tồn kiểm tra đ-ợc. Trong những tình huống đó ng-ời quản
lý dự án có hai ph-ơng án.

1. Giao viƯc lËp lÞch cho chđ thầu phụ hay ng-ời bán hàng
2. Giữ quyền kiểm tra chủ thầu phụ hay ng-ời bán hàng.

Trong tr-ờng hợp đầu khi việc lập lịch đ-ợc giao cho bên ngoại cuộc,
ng-ời quản lý dự án phó mặc cho bên mà ông không kiểm tra đ-ợc. Nếu
bên kia lệch lịch giao hàng điều này có thể gây ra tình trạng tr-ợt lịch
cho toàn dự án. Điều này đ-ợc xử lý tốt nhất b»ng c¸ch:

1. Động viên bên ngoại cuộc giao đúng hạn (thí dụ phạt bên đó về giao
chậm)

2. Nhận biết việc giao chậm là một rủi ro của dự án và chuẩn bị kế
hoạch đột xuất để xử lý tình huống nu xy ra.

</div>
(193)<div class='page_container' data-page=193>

Các thăm viếng với phía chủ thầu phụ và ng-ời bán

R soỏt li và đánh giá cột mốc

 Báo cáo định kỳ của chủ thầu phụ và ng-ời bán

Thêm nữa, điều quan trọng cho giám định viên là có khả năng động
viên bên ngoại cuộc bằng cách gắn thanh toán với các cột mốc hồn
thành thắng lợi và bằng áp đặt hình phạt v giao chm.

9.7 Kiểm tra và cập nhật lịch trình.

Lch trình khơng phải là văn bản tĩnh và chịu sự thay đổi th-ờng
xun. Lịch trình lỗi thời ít có (nếu cịn có) giá trị lịch trình là bộ phận
của kế hoạch phát triển dự án, phải đ-ợc cập nhật định kỹ. Nhằm cho
ng-ời quản lý dự án có khả năng duy trì đ-ợc lịch trình cập nhật thơng tin
l-u hành phải chảy đều đặn từ đội phát triển đến. Điều này thực hiện
đ-ợc qua các báo cáo định kỳ, rà soát lại và các hoạt động kiểm tra khác.

9.7.1. Các báo cáo định kỳ

Báo cáo định kỳ là một trong những ph-ơng pháp hợp thức đảm bảo
dịng chảy thơng tin th-ờng xuyên từ đội phát triển đến ng-ời quản lý dự
án. Thực hành nên làm trong việc chuẩn bị và trình báo cáo đ-ợc mơ tả ở
phần 5.3.1

Các thành viên đội phải trình báo cáo định kỳ của mình cho lãnh đạo
đội để ơng này sau đó tóm tắt các báo cáo và trình tóm tắt cùng bản sao
các báo cáo cá nhân cho ng-ời quản lý dự án. Sau đó ng-ời quản lý dự án
tóm tắt các báo cáo của đội tr-ởng cùng với báo cáo của nhân lực dự án
khác nh- ng-ời phụ trách nhóm thử nghiệm. Văn bản có đ-ợc bao gồm
cả báo cáo của ng-ời quản lý dự án, hình thành báo cáo tiến độ dự án và
là văn bản dự án chính thức đ-ợc đệ trinh quản lý cấp cao. Danh mục
phần bố cho báo cáo tiến độ dự án cũng có thể bao gồm các thành viên cá
nhân của đội phát triển khách hàng và các chủ thầu phụ của dự án.

Các báo cáo định kỳ là những kênh thông tin cơ bản đ-ợc sử dụng để
đánh giá và cập nhật kế hoạch phát triển của dự án và đặc biệt lịch trình
dự án. Dù sao các báo cáo định kỳ phải không báo giờ chỉ là nguồn thông
tin duy nhất cho các hoạt động đó. Đây là trách nhiệm của ng-ời quản lý
dự án phải thử tính hồn hảo và chính xác của thông tin đ-ợc báo cáo.

Tần độ báo cáo là vấn đề mà ng-ời quản lý dự án quyết định th-ờng
một báo cáo nửa tháng một là thích hợp cho nhu cầu dự án nội bộ và báo
cáo hàng tháng là thích hợp cho nhu cầu dự án bên ngồi. Dù sao trong
giai đoạn tới hạn của dự án, lại có thể cịn có nhiều báo cáo th-ờng xun
hơn.

</div>
(194)<div class='page_container' data-page=194>

Một trong những yếu tố của quản lý tốt là thiết lập tiếp xúc cá nhân
giữa quản lý và nhân viên. Những cuộc tiếp xúc cá nhân hỗ trợ nhiều mục
đích quản lý, mà một trong đó là kiểm tra các báo cáo tiến độ.

Những vấn đề chính với báo cáo th-ờng kỳ là vấn đề khách quan, lý
giải và chính xác. Lịch trình dự án khơng phải bao giờ cũng đ-ợc lý giải
hay nhận thức cùng cách thức trong quản lý nh- với các nhà sản xuất.
Hội chứng nổi tiếng 90/50 bàn đến ở ch-ơng 5 là minh hoạ cho trình

huống này. Điều này, chúng ta có thể nhắc lại khẳng định là mất 50%
thời gian để hoàn thành 90% công việc và 50% phụ về thời gian để hồn
thành phần cịn lại 10% của cơng việc.

Điều này có nghĩa là khi các thành viên đội bắt đầu báo cáo là họ đã
hầu nh- hoàn thành một nhiệm vụ, chắc chắn có thể cần một l-ợng thời
gian đáng kể để thực sự hoàn thành nhiệm vụ. Điều này là do th-ờng
t-ơng đối dễ có đ-ợc cái gì xi xẻo nh-ng cơng việc nặng nhọc và đơn
điệu cần có để gói ghém nhiệm vụ địi hỏi l-ợng cơng việc đáng kể. Và
tất nhiên điều này lại thêm vào tính lác quan tự nhiên của ng-ời sản xuất
kỳ vọng là không có gì sẽ sai cả.

Có nhiều ph-ơng pháp để kiểm tra tiến độ liên quan đến tiếp xúc cá
nhân giữa ng-ời quản lý dự án và đội phát triển. Những cuộc họp đội và
dự án hàng tuần là những cơ hội tốt để thảo luận tiến bộ và những rà sốt
lại khơng chính thức các hoạt động đặc tr-ng giúp ng-ời quản lý dự án
có thể nhìn và đánh giá cơng việc hiện nay đã làm đ-ợc.

Khi một lịch trình khơng đ-ợc thực hiện, đơi khi đó là dấu hiệu rằng
thành viên đội bố trí vào một hoạt động đặc tr-ng đã khơng hỗ trợ lịch
trình. Những tình huống đó nhấn mạnh đến tầm quan trọng là có đ-ợc
đội phát triển tham gia vào việc chuẩn bị lịch trình. Điều này th-ớng dễ
hơn khi có ng-ời sản xuất tham gia vo vic chun b nú

9.7.3. Cập nhật lịch trình

Nh- chỳng ta đã thấy, kế hoạch phát triển dự án phải đ-ợc xem lại
định kỳ. Lịch trình phải đ-ợc cập nhật bất kể khi nào việc rà soát lại định
kỳ xác minh hay bất kể khi nào có một sự kiện đáng kể diễn ra. Chẳng
hạn, nếu việc rà soát lại cho thấy nhiều hoạt động chậm hơn (hay nhanh

hơn) lịch hay có vơ vàn hoạt động mới cần bổ sung cho danh mục hoạt
động thì lịch trình mới cần đ-ợc xây dựng. Cũng vậy nếu sự phát triển
của bộ phận dự án đ-ợc thay thế khi mua một thành tố t-ơng đối khởi giá
thì lịch trình phải đ-ợc sửa đổi để phản ánh cố gắng phát triển nhỏ nhoi.

Bảng 9.6 có danh mục kiểm tra các hạng mục theo lịch phải đ-ợc
duyệt lại (và cố gắng cập nhật) định kỳ hay bất cứ khi nào một hiện
t-ợng của dự án đáng kể diễn ra.

</div>
(195)<div class='page_container' data-page=195>

hạng mục đã đ-ợc duyệt lại và nếu cần thiết đ-ợc cập nhật thì mơi tr-ờng
biểu thị lịch trìmh cũng phải cập nhật (biểu đồ GANTT, biểu đồ
PERTv.v.) Nh- trong việc chuẩn bị lịch trình ban đầu ln có một thói
quen tốt là có những thành viên của đội phát triển duyệt lại lịch trình
mới tr-ớc khi cơng bố. Những sai lầm, sơ xuất và tranh chấp về lịch trình
theo đó có thể nhận biết và hiệu chỉnh tr-ớc khi lịch trình đ-ợc phát i.

Bảng 9.6 Danh mục kiểm tra cập nhật lịch trình

1. Danh mục hoạt động
2. Bố trí nhân lực

3. Danh mơc rủi ro và phân tích rủi ro
4. Phân bổ nguồn lùc

5. Qui chế bên thứ ba (chủ thầu phụ, bán hàng, cung ứng)
6. Biểu đồ lịch trình (GANTT)

7. M¹ng -u tiªn (PERT)

8. Yêu cầu đ-ợc chấp thuận và thay đổi thiết kế.

9.8. Mét sè h-íng dÉn chung vỊ lËp lÞch trình và
qui hoạch.

Qui hoch bt u vi vic khi cụng dự án và thậm chí tr-ớc nữa ở
một số tr-ờng hợp. Nh- chúng ta đã thấy ở phần 9.1, mọi hoạt động dự
án phải đ-ợc qui hoạch. Việc thiếu qui hoạch th-ờng là nguyên nhân
chính của thất bại. B-ớc đầu tiên tốt đẹp trong qui hoạch là chuẩn bị phác
thảo kế hoạch phát triển dự án, nh- mô tả ở bảng 9.1 và tuần tự bắt đầu
điền vào các phần.

9.8.1. Tinh chế danh mục hoạt động ban đầu

Nh- chúng ta thấy, danh mục hoạt động ban đầu, cùng với ngày tháng
có dự án hồn thành hoạt động tạo ra lịch trình ban đầu. Việc tinh chế
danh mục hoạt động là một q trình lặp lại có thể tạo ra lịch trình phát
triển chi tiết của dự án.

Khi lịch trình tiến triển và trở nên chi tiết hơn, danh mục hoạt động sẽ
có các hoạt động mức độ thấp đ-ợc giao cho các thành viên. Do đó điều
quan trọng nhất cho ng-ời quản lý dự án là bao gồm các thành viên trong
giai đoạn này. Tốt hơn là nên để kỹ s- đề xuất lịch trình trong lĩnh vực
trách nhiệm của họ chứ khơng nên chỉ định lịch trình cho họ. Nói chung,
các thành viên cảm thấy tham gia nhiều hơn vào lịch trình mà họ đã
chuẩn bị hơn là lịch trình đ-ợc chuẩn bị cho họ.

</div>
(196)<div class='page_container' data-page=196>

lại đến khi có đ-ợc lịch trình chấp nhận đ-ợc và nhất trí. Chỉ khi khơng
thể có đ-ợc nhất trí, ng-ời quản lý dự án mới dùng quyền của anh hay
chị và đ-a các phần của lịch trình cịn bất đồng vào.

B¶ng 9.7 Tóm tắt một số h-ớng dẫn cơ bản trong việc xây dựng và duy
trì lịch phát triển chi tiết.

9.8.2. Giành đ-ợc chấp thuận lịch trình

Chun b mt lch trỡnh thực tiễn không phải là mục tiêu duy nhất của
ng-ời quản lý dự án: Có đ-ợc lịch trình chấp thuận lại mới là quan trọng.
Rất th-ờng khi, lịch trình thực tiễn đ-ợc ng-ời quản lý dự án mất nhiều
công sức chuẩn bị và đ-ợc đệ trìmh quản lý tập đồn chỉ đ-ợc để bác bỏ
vì lý do kinh doanh. Điều này nhấn mạnh tầm quan trọng của những
ng-ời quản lý dự án có ý thức đ-ợc hình ảnh rộng hơn của tập đồn và
khơng chỉ tự hạn chế mình trong viễn cảnh kỹ thuật hạn hẹp.

Khi chuẩn bị một kế hoạch phát triển dự án tổng thể, tất nhiên ng-ời
quản lý dự án phải dự kiến sức ép trong hai lĩnh vực cơ bản (1)ngày hồn
thành và (2)chi phí phát triển. Các sức ép khác cũng có thể chịu đựng
đ-ợc nh-ng hai lĩnh vực cơ bản là phổ biến.

B¶ng 9.7 H-óng dẫn lịch trình

1. Xỳc tin tham gia ca i

2. Lặp lại ở mức cao với lịch trình chi tiết

3. Có ý thức về nhu cầu của khách hàng, quản lý, ng-ời dự và tiếp thị.
4. Không chỉ lên lịch các hoạt động mà cả nguồn lực và nhân lực nữa
5. Chống chọi sức ép htam gia lịch trình khơng tho ỏng

6. Sử dụng công cụ lên lịch máy tính ho¸

7. Lên lịch kế hoạch đột xuất phịng ngừa rủi ro

8. Cập nhật định kỳ lịch trình hay sau những sự kiện chủ yếu của dự
án.

Với ng-ời quản lý dự án, con đ-ờng tốt nhất để đối phó với sức ép
nh-thế là tìm cách nhìn nhận dự án từ viễn cảnh khác phi kỹ thuật.

Nếu sức ép phải chịu là ở khách hàng, ng-ời quản lý dự án phải tìm
cách hiểu đ-ợc mối quan tâm của khách hàng và tìm cách đ-a những
quan tâm đó trong phạm vi lịch trình thực tiễn. Liệu khách hàng có chấp
nhận việc sớm giao một phần hệ thống? liệu có giải pháp sẵn có nào thoả
mãn đ-ợc tạm thời cho đến khi tồn bộ hệ thống hoàn thành?

</div>
(197)<div class='page_container' data-page=197>

-u t- và ảo t-ởng tự thân th-ờng là chính sách tồi tệ nhất. Tốt nhất là
trung thành với một lịch trình thực hiện đ-ợc thoả đáng. Cách tiếp cận tốt
nhất cho ng-ời quản lý dự án là trung thực. Không bao giờ hứa hẹn cái gì
bạn khơng dự liệu có khả năng giao đ-ợc.

Một cách tiếp cận hiệu qủa đã đ-ợc minh chứng bao giờ cũng là trình
bày vấn đề cùng với giải pháp. Điều này có nghĩa là khi lịch trình không
thể hỗ trợ mong đợi của khách hàng hay của quản lý cấp cao thì vấn đề
phải đ-ợc trình bày và giải thích và lịch trình xen kẽ phải đ-ợc gợi ý cùng
với những mục tiêu đã sử đổi. Thí dụ sau đây sẽ chứng minh tiếp cận đó.

ACO, một công ty vững vàng, đã tham gia vào dịch vụ hỗ trợ bán lẻ
trong nhiều năm. Mới đây họ quyết định phát triển một hệ thống mới
máy tính hố đ-ợc hồ mạng có thể giao diện với các hệ thống đăng ký
tiền mặt hiện có nhằm cung cấp một loạt đa dạng dịch vụ cho các cửa
hàng và khách hàng của họ. Có hai điều sáng tỏ ở đầu ra: thứ nhất là, có

nhu cầu xác định cho những dịch vụ đó và thứ hai là, cơng ty khơng
phải là duy nhất nhận ra u cầu đó.

BCO, cơng ty đ-ợc chào hợp đồng phát triển, đã thấy là hệ thống
không phải không quan trọng. Biết đ-ợc là ACO muốn giành thị tr-ờng
này, BCO đã đệ trình lịch trình thực tiễn thời gian ngắn nhất mà họ thấy
có thể tham gia. Tuy nhiên lịch trình đó đã bị ACO bác bỏ.

Sau khi BCO điều tra thêm, rõ ràng là ACO đã chấp nhận thời gian
giao hàng của hệ thống cho một số khách hàng của mình. ACO cũng đã
cảm thấy có cơ hội dễ tiêu ma trong thị tr-ờng và họ có thể mất khách
nếu họ khơng thể giao đúng hạn.

BCO đã đề xuất một hệ thống trung gian có thể khơng đ-ợc hồ mạng
giữa các cửa hàng và hẳn là thu giảm chức năng. Hệ thống trung gian này
có thể hoạt động trên phần cứng nh- thế và mọi chức năng có thể t-ơng
thích với hệ thống chức năng trọn vẹn cuối cùng. Hệ thống trung gian này
có thể đ-ợc giao cho khách hàng của ACO sớm hơn và sau này đ-ợc thay
thế bằng hệ thống trọn vẹn. Điều này là chấp nhận đ-ợc cho ACO.

BCO chống chọi lại ý đồ hứa hẹn ngày giao hàng bất khả nhằm đảm
bảo là họ có đ-ợc hợp đồng. Họ giải thích vấn đề với ACO và gợi ý một
giải pháp cho những vấn đề ACO nhắm tới với khách hàng của họ. Chọn
cách làm nh- vậy, BCO cũng giành đ-ợc tín nhiệm của ACO đã thể hiện
sẵn sàng giúp đỡ suốt cả dự án.

Không một ai, dù là khách hàng hay quản lý, có thể dự liệu có lập luận
điều bất khả. Do đấy, để có đ-ợc chấp thuận cho lích trình phát triển dự
án, tiến trình hành động nên là:

1. Kh«ng tình bày lịch trình trong chân không. Lịch trình phải là bộ
phận của kế hoạch phát triển tổng thể của dù ¸n.

</div>
(198)<div class='page_container' data-page=198>

3. Đảm bảo là lịch trình thoả đáng và đ-ợc chuẩn bị kỹ. Sẵn sàng xác
minh mọi cột mốc.

4. Tìm hiểu hỗ trợ của các chuyên gia khác và các nguồn tham khảo
nghiệp vụ nhằm biện minh mọi vấn đề bạn trình bày.

5. Ln trình bày vấn đề cùng với giải pháp.

6. Tự tin là mình đúng. Nếu bạn nghi ngờ những khẳng định của chính
mình thì bạn đã khơng sẵn sàng trình bày lịch trình đ-ợc lịch trình thực
tiễn đ-ợc quản lý (hay khách hàng) chấp thuận là b-ớc chủ yếu đến hoàn
thành thắng lợi dự án. Khi lịch trình là khơng thực tiễn nó th-ờng bị
nguỵ trang bởi những từ nh- chặt chẽ, hung hăng hay thách đố. Dù sao,
những lịch trình chặt chẽ, hăng hái hay thách đố hiếm khi là hấp dẫn cho
cỏc d ỏn thnh cụng

9.8.3. Quan hệ giữa lịch trình, nguồn lực chất l-ợng và

chức năng.

Nh- chỳng ta ó thy, kế hoạch phát triển của dự án lập biểu đ-ờng đi
từ tình hình hiện tại tới mục tiêu của dự án. Kế hoạch mô tả các nguồn
lực cần thiết để thực hiện mục tiêu trong phạm vi một lịch trình định
nghĩa. Nguồn lực u cầu và lịch trình có thể đ-ợc tính (hay dự tốn) cả
hai căn cứ ở mục tiêu đề ra của dự án.

Các mục tiêu của dự án, (là chức năng mô tả trong đặc tả yêu cầu)
không cần thiết là những yêu cầu duy nhất của dự án. Lịch trình danh

nghĩa cũng có thể đ-ợc u cầu (thí dụ để phát triển dự án trong phạm vi
một năm). Nếu lịch trình yêu cầu qúa ngắn thì yêu cầu phụ có thể là yêu
cầu bất khả thi. Dù sao nếu lịch trình u cầu cũng khơng q ngắn thì
cùng với tính chức năng, nó sẽ xác định các nguồn lực yêu cầu.

Các nguồn lực cũng có thể là yêu cầu (qui mô tối đa của đội phát triển
hay máy tính phát triển đặc dụng). Nếu nguồn lực là khơng thích hợp thì
u cầu phụ này có thể là yêu cầu bất khả thi. Khi nguồn lực yêu cầu là
thích hợp thì cùng với tính chức năng, chúng sẽ xác định lịch trình câu
hỏi tồn tại là cái gì xảy ra nếu cả nguồn lực và lịch trình đ-ợc yêu cầu
th-ờng điều này có nghĩa là mức độ tính chức năng sẽ đ-ợc lịch trình và
nguồn lực xác định. Điều này có nghĩa là trong phạm vi một lịch trình đã
cho và với nguồn lực đã cho, l-ợng tính chức năng là hạn chế. Một cách
khác để nhìn vào tam giác các thuộc tính ăn theo của dự án (tính chức
năng lịch trình và nguồn lực) là đ-a vào thuộc tính thứ t- chất l-ợng.
Điều này có nghĩa là nêú cả ba thuộc tính tr-ớc đây đ-ợc định tr-ớc thì
chất l-ợng của sản phẩm phần mềm cũng đ-ợc xác định. Dù sao ng-ời
quản lý dự án đi vào lãnh địa nguy hiểm khi cả bốn thuộc tính đ-ợc xác
định tr-ớc ( coi Hình 9.9).

</div>
(199)<div class='page_container' data-page=199>

T-ơng tự. ng-ời quản lý dự án có thể đ-ợc hỏi cần nguồn lực nào
nhằm phát triển tính chức năng đã cho trong phạm vi 18 tháng ở mức chất
l-ợng đã cho.

H×nh 9.9

Bốn thuộctính của dự án phát triển (cứ ba xác định thứ t-)

9.9. Tãm t¾t

Lịch trình dự án là một trong những phần quan trọng nhất của kế
hoạch phát triển dự án. Kế hoạch này th-ờng là văn bản chính thức đầu
tiên phát sinh trong phạm vi dự án và bao gồm không chỉ lên lịch các
hoạt động phát triển mà cả lên lịch các nguồn lực dự án, đặc biệt con
ng-ời. Kế hoạch phát triển dự án mô tả chi tiết ng-ời quản lý dự án lập
kế hoạch phát triển dự án ra sao, cần những nguồn lực nào và những
nguồn lực đó đ-ợc sử dụng thế nào.

Lịch trình là danh mục các hoạt động và thời gian thực hiện dự kiến có
nhiều cách để biểu thị lịch trình; danh mục hoạt động, sơ đồ, đồ thị v.v.
ph-ơng pháp phổ thơng nhất biểu thị lịch trình là biểu đồ mạng trình tự
tr-ớc-sau (nh- PERT) các biểu đồ GANTT và danh mục cột mốc.

Một sai lầm phổ biến khi cho rằng bất cứ khi nào có cố gắng phụ thì
lịch trình sẽ đ-ợc rút ngắn. Việc rút ngắn các hoạt động tuyệt đối sẽ
khơng có tác động gì đến thời hạn tổng thể của lịch trình nếu những hoạt
động đó không thuộc về con đ-ờng tới hạn của dự án. Đ-ờng tới hạn là
đ-ờng dài nhất xuyên qua biểu đồ trình tự tr-ớc-sau của mạng từ nút khởi
điểm đến nút tận cùng.

Lập lịch các nguồn lực cũng quan trọng nh- việc lập lịch các hoạt
động. Những nguồn lực phát triển bao gồm ph-ơng tiện, không gian làm
việc, thiết bị và nguồn nhân lực.

Nguồn lực dự án quan trọng nhất của ng-ời quản lý dự án chính là đội
phát triển. Vì số l-ợng các hoạt động dự án thay đổi nên qui mô của đội
phát triển cũng thay đổi xuyên suốt vòng đời phát triển dự án. Cơ cấu tổ
chức của đội càng trở nên quan trọng hơn khi qui mô của đội tăng lên.

Một lịch trình q hạn là ít có giá trị. Một lịch trình, với vai trị là bộ

phận của kế hoạch phát triển tổng thể của dự án, phải đ-ợc cập nhập định
kỳ. Nhằm cho ng-ời quản lý dự án có thể duy trì đ-ợc lịch trình cập nhật,
thông tin hiện thời phải đ-ợc chảy đều đặn t i phỏt trin. iu ny

Các nguồn lực

Chất l-ợng Chức năng

</div>
(200)<div class='page_container' data-page=200>

-c thc hin qua cỏc bỏo cỏo định kỳ, rà soát lại định kỳ và các hoạt
động kiểm tra khác.

Một lịch trình thực tiễn đ-ợc quản lý (hay khách hàng) chấp thuận là
một b-ớc chủ yếu để dự án phát triển thành cơng. Khi một lịch trình là
khơng thực tiễn, nó th-ờng đ-ợc nguỵ trang bằng những từ nh- chặt chẽ,
năng động hay thách thức. Dù sao, các lịch trình chặt chẽ, năng động và
thách thức hiếm khi là hấp dẫn cho các dự án thành cơng

Bµi tËp

1. Bạn đã đ-ợc chỉ định làm quản lý dự án cho một hệ thống chuyển
quĩ và vận chuyển của công ty lớn giáo xe tải. Mỗi xe tải đ-ợc trang bị
thiết bị liên lạc bằng số liên lạc với máy tính trung tâm.

Dự án của bạn sẽ phát triển phần mềm để liên lạc với xe tải và gửi đi
theo thuật tốn hành trình tối -u. Hệ thống cũng duy trì cơ sở dữ liệu chi
tiết bao gồm thơng tin liên quan đến xe tải của công ty, vị trí hiện thời
của chúng, ng-ời lái và lộ trình giao nhận. Hệ thống cũng cung cấp câu
hỏi trực tuyến và khả năng cập nhật cũng nh- các bộ phát báo cáo.

Hãy chuẩn bị một danh nục hoạt động cho dự án đó. Nhận biết những

cột mốc chủ yếu và xác định các đ-ờng gốc của dự án.

2. Hãy chuẩn bị biểu đồ GANTT mức cao cho dự án mô tả ở bài tập 1.
Chuẩn bị biểu đồ GANTT chi tiết cho hai trong những hoạt động mức
cao giải thích mọi chồng chéo giữa các hoạt động tới hạn có thể thay đổi
thế nào.

3. Chuẩn bị biểu đồ PERT mức cao cho dự án mô tả ở bài tập 1.

Hãy bao gồm mọi hoạt động phát triển và không phát triển. Định vị
trí các con đ-ờng qua mạng và nhận biết con đ-ờng tới hạn. Chứng minh
đ-ờng tới hạn có thể thay đổi thế nào khi chỉ một thuộc tính thời hạn
thay đổi. Giải thích sự tuỳ thuộc nh- đ-ợc biểu thị trên biểu đồ.

4. Hãy chuẩn bị lịch trình nhân sự cho dự án mô tả ở bài tập 1. Mô tả
cần bao nhiêu thành viên đội ở mỗi giai đoạn, kỹ năng của họ, sự bố trí
họ trong phạm vi dự án ra sao ?

5. H·y chuÈn bÞ lÞch trình nguồn lực cho dự án mô tả ở bài tập 1. Mô
tả mỗi nguồn lực phát triển và giải thích tại sao và khi nào thì sẽ cần

Tho lun các tác động cho cố gắng phát triển dự án ở chỗ khơng có
khả năng có đ-ợc mỗi nguồn lực.

6. Xem xét những nhân tố nào của dự án trong bài tập 1 có thể tuỳ
thuộc ở các bên ngoại cuộc. thảo luận xem những hoạt động phát triển
nào có thể đ-ợc xem xét để thầu phụ và những thành tố và có khả năng
mua.

7. Xem xét những vấn đề có thể dự kiến trong giai đoạn hợp nhất của

dự án mô tả ở bài tập 1

</div>

Giaotrinhquanlyduanphanmempdf

<b>Mục lục</b>

<b>Đối t-ợng đọc đ-ợc chủ định.</b>

<b>Tri ©n</b>

<b>NhÃn hiệu th-ơng mại</b>

<b>Nhập môn về quản lý dự án phần mềm</b>

<b>Nhập môn</b>

<b>Nhng vn phỏt trin phn mm</b>

<b>Một chút phòng xa</b>

<b>2.1.1. Những vấn đề liên quan đến các yêu cầu của dự án.</b>

<b>2.1.2. Những thay đổi th-ờng xuyên.</b>

<b>2.1.3. Dự toán và các vấn đề liên quan.</b>

<b>2.1.4. Ngn lùc bªn ngoµi.</b>

<b>2.1.5. KÕt thúc một dự án phần mềm.</b>

<b>2.1.6. Tuyển dụng nhân viên và thuyªn chun.</b>

<b>2.1.7. Theo dõi và giám sát.</b>

<b>2.2.1. Dự kiến những vấn đề cần giải quyết.</b>

<b>2.2.2. Pha ph©n tÝch</b>

<b>2.2.3. Thc hin cỏc kế hoạch đối phó bất ngờ.</b>

<b>Bµi tËp</b>

<b>Phát triển phần mềm theo hợp đồng</b>

<b>Mối quan hệ khách hàng - nhà phát triển</b>

<b>3.1.1. Hợp đồng phí cộng thêm</b>

<b>3.1.2. Hợp đồng giá cố định</b>

<b>3.3.1. Một số vấn đề cơ bản.</b>

<b>3.3.2. Chuẩn bị các RFP.</b>

<b>3.3.3. Phỏt yờu cu xut RFP</b>

<b>3.4.1. Đề xuất không do yêu cầu</b>

<b>3.4.2. §Ị xuất khi có yêu cầu</b>

<b>3.4.3. Đội ngũ chuẩn bị đề xuất.</b>

<b>3.4.4. Khuôn dạng đề xuất</b>

<b>3.4.5. Khẳng định công việc (Sow)</b>

<b>3.5.2. Ph-ơng pháp đánh giá đề xuất.</b>

<b>3.6.1. Những vấn đề liên quan đến khách hàng.</b>

<b>3.6.2. Những vấn đề liên quan đến ng-ời đề nghị.</b>

<b>Bµi tËp.</b>

<b>Chu trình phát triển phần mềm</b>

<b>Cỏc bin thỏi v ch thỏc n-ớc</b>

<b>4.1.1 Bầu không khí trong pha quan niệm.</b>

<b>4.1.2 Những vấn đề trong pha quan niệm.</b>

<b>4.2.1 Bầu không khí trong quá trình pha yêu cầu.</b>

<b>4.2.2 Các vấn đề trong pha yêu cầu</b>

<b>4.3.1 BÇu kh«ng khÝ trong pha thiÕt kÕ.</b>

<b>4.3.2 Những vấn đề trong pha thiết kế</b>

<b>4.4.1 Bàu không khí trong pha thùc hiÖn</b>

<b>4.4.2 Nhng vấn đề trong pha thực hiện</b>

<b>4.5.1 Bầu không khí trong pha tích hợp và thử nghiƯm</b>

<b>4.5.2 Nhng vn trong pha tớch hợp và thử nghiệm</b>

<b>4.6.1 Bầu không khí trong pha bảo trì</b>

<b>4.6.2 Những vấn đề trong pha bảo trì</b>

<b>Bµi tËp</b>

<b>Nguyên tắc quản lý các</b>

<b>kỹ s- phần mềm</b>

<b>Liệu họ có thực sự có gì khác ?</b>

<b>5.2.1 Lãnh đạo đội.</b>

<b>5.2.2 Các đội dân chủ.</b>

<b>5.2.3 Các đội kỹ s- tr-ởng.</b>

<b>5.2.4 Các đội chuyên gia.</b>

<b>5.3.1 B¸o cáo tình hình</b>

<b>5.3.2 Các cuộc họp tình hình dự án</b>

<b>Bài tập</b>

<b>Chia tr cỏc d án lớn thế nào :</b>

<b>phân chia và chiếm lĩnh</b>

<b>Nhu cÇu lớn không có nghĩa là khó</b>

<b>Phân giải thiết kế.</b>

<b>6.2.1. Phân giải dự án.</b>

<b>6.3.1. Các hệ thống phụ.</b>

<b>6.3.2. Đ-ờng lối phân giải chức năng.</b>

<b>6.3.3. Đ-ờng lối phân giải thiết kế.</b>

<b>6.3.4. Đ-ờng lối phân giải nhiệm vơ c«ng viƯc.</b>

<b>Bµi tËp.</b>

<b>Các chức năng hỗ trợ dự án</b>

<b>Hỗ trợ quản lý dự án.</b>

<b>7.1.1. Tht ng÷ kiĨm tra cÊu h×nh.</b>

<b>7.1.2. Nguån lùc kiểm tra cấu hình.</b>

<b>7.1.3. Kế hoạch quản lý cấu hình phần mềm.</b>

<b>7.1.4. Một số đ-ờng lối chung</b>

<b>7.2.1. Tạo ra phần mềm chất l-ỵng.</b>

<b>7.2.2. Ngn lùc kiĨm tra chÊt l-ỵng.</b>

<b>7.2.3. Kế hoạch bảo đảm chất l-ợng phần mềm.</b>