Giaotrinhquanlyduanphanmempdf

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. C«ng ty phÇn mÒm ®-îc lùa chän ph¸t triÓn thµnh c«ng hÖ thèng.. VËn dông c¸c [r]

Môc lôc

Lêi nói đầu

Ch-ơng Nhập môn quản lý dự án phần mềm Nhập môn

1.1 Nhu cầu gia tăng phần mềm

1.2 Vai trò việc quản lý phát triển phần mềm 1.3 Mét thÝ dơ

1.4 Giµnh sù chÊp nhËn thủ tục phát triển 1.5 Tóm tắt

10 10 11 13 15 17 Ch-ơng Những vấn đề phát triển phần mềm

Mét chót phßng xa

2.1 Những vấn đề

2.1.1 Những vấn đề liên quan đến yêu cầu dự án 2.1.2 Những thay đổi th-ờng xuyên

2.1.3 Dự toán vấn đề liên quan 2.1.4 Nguồn lực bờn ngoi

2.1.5 Kết thúc dự án phần mềm

2.1.6 Tuyển dụng nhân viên thuyên chuyển 2.1.7 Theo dõi giám sát

2.2 Phân tích rñi ro

2.2.1 Dự kiến vấn đề cần giải 2.2.2 Pha phân tích

2.2.3 Thự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 Phát triển phần mềm theo hợp đồng

Quan hÖ khách hàng - nhà phát triển

3.1 Chi phớ cộng thêm đối lại với giá cố định 3.1.1 Hợp đồng phí cộng thêm

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

3.2 Các mối quan hệ khác gi-ã khách hàng - nhà phát triển 3.3 Yêu cầu đề xuất (RFP)

3.3.1 Một số vấn đề 3.3.2 Chuẩn bị RFP

3.3.3 Phát yêu cầu đề xuất RFP 3.4 Đề xuất

3.4.1 Đề xuất không yêu cầu 3.4.2 Đề xuất 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 trình lựa chọn 3.5.1 Ban tuyển chọn đề xuất

3.5.2 Ph-ơng pháp đánh giá đề xuất 3.6 Một số nhận định bổ sung đề xuất 3.6.1 Những vấn đề liên quan đến khách hàng 3.6.2 Những vấn đề liên quan đến ng-ời đề nghị 3.7 Tóm tắt

Bµi tËp 50 52 52 53 54 55 Ch-ơng Chu trình phát triển phần mềm

Các biểu thái chủ đề thác n-ớc 4.1 Pha quan niệm

4.1.1 Bàu khơng khí pha quan niệm 4.1.2 Những vấn đề pha quan niệm 4.2 Pha u cầu phần mềm

4.2.1 Bàu khơng khí trình pha yêu cầu 4.2.2 Các vấn đề pha yêu cầu

4.3 Pha thiÕt kÕ

4.3.1 Bàu khơng khí pha thiết kế 4.3.2 Những vấn đề pha thiết kế 4.4 Pha thực

4.4.1 Bàu khơng khí pha thực 4.4.2 Những vấn đề pha thực 4.5 Pha tích hợp thử nghiệm

4.5.1 Bàu khơng khí pha tích hợp thử nghiệm 4.5.2 Những vấn đề pha tích hợp thử nghiệm 4.6 Pha bảo trì

4.6.1 Bàu khơng khí pha bảo trì 4.6.2 Những vấn đề 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 Nguyên tắc quản lý kỹ s- phần mềm

H cú thc có khác 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 5.3.1 Báo cáo tình hình

5.3.2 Các họp tình hình dự án

5.4 Những đ-ờng lối chung quản lý kỹ s- phần mềm

5.5 Tóm tắt Bài tập 80 81 85 85 87 87 88 89 90 91 92 94 95 Ch-ơng Chia để trị dự án lớn nào: phân chia v

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 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ý 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 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 Các chức 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 Ngn 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 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 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 kiểm toán

8.2.3 Mô tả hạng mục liệu (DIDS) 8.2.4 Lấy kích th-ớc tiêu chuẩn

8.2.5 Lợi bất lợi 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 tiêu chuẩn công nghệ phần

mềm

8.3.3 Lợi bất lợi tiêu chuẩn IEEE 8.3.4 So sánh tiêu chuẩn IEEE 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 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 Lập trình dự án

Lp trỡnh:

9.1 Kế hoạch phát triển dự án

9.2 Các hoạt động theo lập trình 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 đ-ờng mốc chủ yếu 9.3 Các biểu đồ Gantt

9.4 Các biểu đồ PERT đ-ờng tới hạn 9.4.1 Đ-ờng tới hạn

9.4.2 C¸c khối ch-ơng trình PERT 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ỹ kinh nghiệm 9.5.3 Tháng ng-ời bất nghì 9.6 Lập lịch 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 nhà thầu phơ

9.7 Kiểm chứng cập nhật ch-ơng trình 9.7.1 Báo cáo định kỳ

9.7.2 Các hoạt động kiểm chứng khác 9.7.3 Cập nhật ch-ơng trình

9.8 Một số đ-ờng lối chung cho việc lập trình qui hoạch 9.8.1 Tinh lọc danh mục hoạt động ban u

9.8.2 Giành đ-ợc phê chuẩn ch-ơng trình

9.8.3 Mối quan hệ ch-ơng trình, tài nguyên, chất l-ợng tính chức

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 kỹ thuật

Dự toán: vấn đề 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ó phần kinh nghiệm

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 Uc nh phỏt trin mi

10.3.1 Những ph-ơng pháp kiểu đầu (nguyên mẫu) 10.3.2 Những ph-ơng pháp thống kê

10.4 Mô hình chi phí xây dựng (Cocomo) 10.4.1 Møc nh©n sù

10.4.2 Mức độ phức tạp 10.4.3 Yếu tố độ tin cậy 10.4.4 Môi tr-ờng phát triển 10.4.5 Các thứ hệ

10.4.6 ThuËt to¸n dù toán phí 10.5 Chức phân tích điểm 10.5.1 Những b-ớc FPA 10.5.2 ứng dụng FPA 10.6 Dự toán lĩnh vực

10.7 Dự toán tài nguyên phần cứng 10.7.1.Tải trọng CPU

10.7.2 L-u trữ dự liệu 10.7.3 Tốc độ

10.8 Tæng phÝ không phát triển 10.9 Tóm tắt

Bài tập

206 206 207 207 209 210 210 213 215 216 218 219 221 221 224 225 229 229 233 236 238 239 241

Tham kh¶o 243

Tài liệu c thờm

Đây sách quản lý dự án phần mềm; sách tiếp công trình phần mềm ĐÃ có nhiều sách tham khảo công trình phần mềm (coi danh mục tham khảo cuối sách này) Mục tiêu sách trình bày công việc phát triển phần mềm theo quan điểm nhà quản lý theo quan điểm nhà phát triển

Cun sỏch trung, nhiều thực tiễn kỹ thuật quản lý phần mềm đại đ-ợc phát triển tinh lọc suốt thập kỷ qua Quản lý dự án đ-ợc trình bày nh- kỹ lĩnh hội đ-ợc nh- trời cho Chắc chắn, việc quản lý dự án đòi hỏi tài quản lý, nh-ng thân tài không đ-ợc hữu hiệu Việc vận dụng thiết thực thủ tục phát triển phần mềm đại đòi hỏi có nhà quản lý chun nghiệp

Vì sách thực hành (chứ cơng trình lý thuyết) nên nhiều ph-ơng pháp kỹ thuật đ-ợc mơ tả khơng có sở lý thuyết cho riêng Tuy nhiên tham khảo đ-ợc cung cấp suốt sách dành cho quan tâm đến sở lý thuyết Danh mục kèm tham khảo tài liệu để đọc đ-ợc gợi ý có cuối sách

Nhất thời, độc giả thấy số đoạn đ-ợc nhắc lại sách Sở dĩ có điều để giải th-ờng đ-ợc gọi tình năm ngón tay Điều xảy năm ngón tay độc giả cần đ-ợc cài vào sách để đánh dấu độc giả l-ỡng lự ch-ơng nhằm bao quát đ-ợc chủ đề đặc biệt Cuốn sách có giảm nhu cầu phải đánh dấu cách lặp lại giải thích vắn tắt chủ đề chủ yếu đ-ợc tham chiếu dù chủ đề đ-ợc thảo luận chi tiết

Suốt sách hạng mục tháng công năm công đ-ợc sử dụng thay cho hạng mục cũ tháng ng-ời năm ng-ời Những từ đ-ợc thảo luận chi tiết phần 9.5.3

Đối t-ợng đọc đ-ợc chủ định.

Quản lý án phần mềm: Một tiếp cận cho ng-ời thực hành đ-ợc chủ

nh cho i t-ng đa dạng Tr-ớc hết chủ yếu sách đ-ọc chủ định làm nguồn tham khảo cho nhà quản lý dự án phần mềm thực thi nhiệm vụ quản lý sở đ-ợc xếp cho đề tài chủ yếu bao quát ch-ơng (trừ ch-ơng 1) Điều đ-ợc thảo luận thêm giải thích sau việc bố trí nội dung sỏch

Cuối cùng, sách dùng làm tham khảo cho kỹ s- phần mềm muốn mở rộng kiến thức minh sang lĩnh vực quản lý dù ¸n kü tht

Nói chung, m-ời ch-ơng sách xuất theo trình tự lơgíc cung cấp cho việc đầu vào lĩnh vực quản lý dự án phần mềm Tham khảo nhanh đặt cuối ch-ơng có dạng tóm tắt mở rộng Tóm tắt nhằm đ-ợc sử dụng nh- để ghi nhớ lần hay nh- nguồn thông tin ban đầu

Ng-ời đọc đ-ợc yêu cầu tìm cách làm số tập cuối ch-ơng Các tập giúp ng-ời đọc hiểu đ-ợc nhiều ý t-ởng kỹ thuật trình bày ch-ơng

Ch-ơng 1 đề cập quan niệm quản lý dự án phần mềm Ch-ơng

cũng tham luận nhiều khó khăn mà nhà quản lý dự án gặp việc giành hỗ trợ phận quản lý cấp để trình thủ tục phát triển

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 đ-ợc xây dựng suốt sách) Ch-ơng đ-ợc chia làm phần Phần đầu giành cho độc giả không quen với vấn đề quản lý phần mềm Phần hai giành cho ngành quản lý dự án có kinh nghiệm Phần thảo luận ph-ơng pháp đấu tranh với vấn đề thảo luận tr-ớc đây, gọi phân tích rủi ro

C¸c nhà quản lý dự án có kinh nghiệm bỏ qua ch-ơng phần đầu ch-ơng

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ả hợp đồng dự án phần mềm đ-ợc tiến hành nh- thể nào, đề nghị Một văn đề nghị nên đ-ợc xây dựng thể nên thiết lập mối quan hệ khách hàng nhà sản xuất Ch-ơng mô tả yêu cầu văn đề nghị (RFP) trình lựa chọn sau đề nghị đ-ợc đệ trình

Ch-ơng 4 mơ tả chu trình 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 thảo luận (nh- tạo mẫu nhanh mơ hình xoắn ốc - Spiral) Những giai đoạn đ-ợc mô tả theo quan điểm ng-ời quản lý dự án nhấn mạnh đến khơng khí vấn đè giai on

Ch-ơng 5 trình bày số nguyên tắc việc quản lý

con ng-i Ch-ơng lựa số mặt đặc thù liên quan đến việc quản lý kỹ s- phần mềm, chẳng hạn nh- khác đáng kể suất kỹ s- phần mềm tính khí phong độ nhà lập trình nói chung

Ch-ơng 6đề cập vấn đề khó khăn phát triển

Ch-ơng 7 mô tả ba chức hỗ trợ quản lý bản: kiểm tra cấu hình đảm bảo chất l-ợng thử nghiệm phần mềm Ch-ơng thảo luận mối quan hệ chức

Ch-ơng 8 trình bày tổng quan chuẩn phát triển phần mềm Đặc

biệt hai chuẩn đ-ợc thảo luận chi tiết: chuẩn 2167 Bộ Quốc phòng Hoa Kỳ (DOD) chuẩn IEEE 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 Anh Châu Âu, đ-ợc nhắc tới so s¸nh

Ch-ơng 9 thảo luận việc lập lịch kế hoạch phát triển dự án (PDP) kỹ thuật lập lịch lập kế hoạch đ-ợc mô tả, kể phác đồ Gantt PERR cổ điển cấu trúc phá hủy cơng việc (WBS)

Ch-¬ng 10 chứa mô tả tăng c-ờng chi tiết vài ph-ơng

phỏp v k thut chun b dự tốn Ch-ơng gồm ph-ơng pháp dự tính qui mô dự án lịch phát triển dự án nh- dự toán kỹ thuật, chẳng hạn nh- yêu cầu đĩa nhớ Ch-ơng giải thích kinh nghiệm đ-ợc sử dụng để cải tiến dự tốn mơ tả dự tốn đ-ợc hồn thiện trình phát triển dự án tiến triển

Tri ©n

Các tiêu chuẩn DOD-STD 2167a DOD-STD 2168 mô tả hạng mục dự liệu liên quan Bộ Quốc phòng Hoa Kỳ đ-ợc tham chiếu trích dẫn đ-ợc phép Bộ Quốc phòng Hoa Kỳ, Bộ huy hệ thống chiến tranh không gian biển

Các tiêu chuẩn công nghệ phần mềm IEEE đ-ợc tham chiếu tài liệu sau đ-ợc trích dẫn đ-ợc phép Viện tập đoàn kỹ s- điện điện t (IEEE)

Phần nhập môn F.Buckley cho in 1984 IEEE tiểu chuẩn công nghệ phần mềm IEEE

Phần nhập môn J.Horch cho in 1987 IEEE 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ữ quyền mặt @ Viện tập ®oµn kü s- ®iƯn vµ ®iƯn tư

Tơi xin cảm ơn giúp đỡ to lớn Amir việc duyệt tập hợp văn Tôi biết ơn nhiều gợi ý có ích Ơng

Tôi xin cảm ơn Sharon Talya không xáo trộn thảo văn

Cuối quan trọng nhất, xin cảm ơn động viên Iril, không văn chẳng bao gi -c vit

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

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

Ch-ơng một

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

Nhập m«n

“Phần mềm nơi trồng giấc mơ thu hái ác mộng giới ng-ời hóa sói viên đạn bạc“ Trích dẫn từ Brad cox (cox 1990) nhấn mạnh quan tâm nhà quản lý dự án phần mềm hơm Làm kiểm tra đ-ợc ng-ời hóa sói d-ới chi tiết cơng nghệ phần mềm ? Liệu việc phát triển phần mềm có thật phận cơng trình khơng ?

Việc phát triển phần mềm kiểm tra đ-ợc Có ph-ơng pháp kỹ thuật nh-ng chuẩn công cụ đ-ợc vận dụng đắn chúng thúc đẩy phát triển thắng lợi dự án phần mềm Đó khơng phải viên đạn bạc xuyên qua trái tim ng-ời hóa sói: chẳng có giữ thật Những ph-ơng pháp cung cấp cách tiếp cận có hệ thống tới phát triển phần mềm bắt đầu giai đoạn qui hoạch ban đầu kết thúc việc cung cấp sản phẩm phần mềm cuối

Cuốn sách đề cập đến việc vận dụng ph-ơng pháp quản lý dự án phần mềm Sách trình bày tiếp cận thực hành “làm đây” tiếp cận lý thuyết có tham khảo rộng rãi cho quan tâm đến việc mô tả lý thuyết đằng sau ph-ơng pháp Mục tiêu chủ yếu tập trung, sách, mô tả cơng cụ qui trình dính líu đến hoạt động quản lý phần mềm nh-:

 Dự toán chi tiết dự án

Chuẩn bị lịch trình phát triển

Vận dụng 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 đ-ợc cung cấp ph-ơng pháp qui tình cần thiết khiến cho việc phát triển phần mềm có hiệu với ba mục tiêu tiếng tâm t-ởng: phát triển phần mềm

1 theo ch-ơng trình

2 phạm vi ngân sách theo yêu cầu

1.1 Nhu cầu gia tăng phần mềm

Tây - Hệ thống thẻ tín dụng Phần mềm đ-ợc sử dụng rộng rãi để viết in sách

Việc gia tăng nhu cầu phần mềm trở nên vấn đề gay cấn Nó gây việc gia tăng nhu cầu kỹ s- phần mềm V-ợt xa mức độ nhà chuyên nghiệp phần mềm tốt nghiệp tr-ờng đại học Do phát triển phần mềm đ-ợc yêu cầu có suất cao lợi hơn, tin cậy nói chung thành cơng

Những u cầu khơng đ-ợc đáp ứng ph-ơng pháp phát triển thô thiển ngày đầu máy vi tính

Những ph-ơng pháp đ-ợc đề xuất cải tiến đáng kể đ-ờng mà phần mềm đ-ợc phát triển Tính nghiêm trọng vấn đề đ-ợc thừa nhận khắp cộng đồng công nghệ phần mềm Một số liên công ti công xoexiom quốc tế đ-ợc thành lập Hoa Kỳ, Nhật Bản Châu Âu với ngân sách to lớn dành cho việc tìm kiếm ph-ơng pháp giảm nhẹ (nếu loại trừ) vấn đề (coi Bennatan 1987)

Cox (1990), phân tích ph-ơng h-ớng cơng trình phần mềm tiến hành cho thấy rõ cách mạng công nghiệp phần mềm lý thú, ơng tiên đốn ngày mà nhà lập trình thơi khơng mã hóa thứ xóa ghép ứng dụng trừ catalô l-u trữ tốt thành phần phần mềm sử dụng lại đ-ợc Quan niệm quan niệm cách mạng khác nh- phát triển phần mềm tự động (coi Frankel 1985) phải quãng đ-ờng dài tr-ớc trở thành ph-ơng tiện thiết thực 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 cơng cụ đó1 th-ờng nhiều thời gian không xứng với chúng, những

lĩnh vực khác công nghệ hệ CAD/CAM2 tự động đ-ợc sử

dụng để thiết kế xây dựng thành phần điện tử nh-ng phát triển phần mềm cịn hồn tồn cố gắng thủ cơng

Cho đến lúc mà phần mềm sử dụng lại phát triển phần mềm tái tạo tự động bắt đầu thay đ-ợc kỹ s- phần mềm phần mềm cịn tiếp tục ng-ời phát triển Trong chờ đợi việc gia tăng theo yêu cầu suất thục tay nghề thắng lợi chung phát triển phần mềm phải trì trách nhiệm phải nhà quản lý dự án phần mềm

1.2 Vai trß cđa việc quản lý phát triển phần mềm.

Vic quản lý dự án có hiệu địi hỏi nhiều tài kỹ xảo Tiêu chuẩn IEEE (IEEE 1987a) cho dịch nghĩa sau quản lý dự án phần mềm

Quản lý dự án phần mềm trình qui hoạch, tổ chức, nhân điều khiển, kiểm tra 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 nhà phát triển phần mềm tốt khơng cịn đủ Có kỹ xảo quản lý đặc biệt đ-ợc yêu cẩu- dụng từ giai đoạn đầu dự án, chằng hạn nh- cỏc lnh vc nh-:

- Giám sát kiÓm tra

Điều bao gồm việc quản lý có hiệu thành viên đội ngũ phát triển địi hỏi ý thức th-ờng xun tình trạng thực công việc họ dự án

- Qui ho¹ch

Qui hoạch hoạt động quản lý quan trọng bao gồm việc chuẩn bị dự tốn tốt, trì lịch trình phát triển bố trí nhân hiệu

- Quan hệ khách hàng

Trong mt s d án, việc tiếp xúc với khách hàng hoạt động quản lý chủ yếu Điều bao gồm viết tài liệu yêu cầu khách hàng, khống chế thay đổi khách hàng, sử lý việc tham gia khách hàng vào trình phát triển, cung cấp báo cáo tổ chức xét duyệt 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 phẩm chất ao -ớc việc quản lý phần mềm có hiệu Điều th-ờng đòi hỏi khả cung cấp đạo giải pháp vấn đề kỹ thuật phát sinh trình phát triển dự án Điều khơng cần thiết có nghĩa dự trữ chung thân giải pháp đích thực

Những lĩnh vực quản lý vận dụng đ-ợc cho thể loại dự án Công nghệ cao Dù việc quản lý dự án phần mềm lại khó khăn thể phát triển phần mềm có tính xác định lĩnh vực cơng nghệ khác Điều dự án phần mềm đo l-ờng đ-ợc khó dự tốn phụ thuộc nhiều vào nhân tố chủ quan ng-ời

Lịch sử phát triển phần mềm đầy rẫy tr-ờng hợp mà mức độ nguồn lực đ-ợc yêu cầu đ-ợc qui hoạch dự toán tốt Phát triển phần mềm từ lâu đ-ợc nhận định doanh nghiệp đầy rủi ro Đã có nhiều tr-ờng hợp dự án phần mềm v-ợt ngân sách ban đầu chúng tới hai, ba hay chí bồn trăm phần trăm Một số phải bỏ bễ sau chi hết vốn thấy rõ dự tốn ngân sách ban đầu khơng chỗ sát với chi phí phát triển thực

Trong năm gần đây, có ý đồ tiêu chuẩn hố qui trình phát triển phần mềm tạo mơi tr-ờng phát triển nghiêm ngặt dự án phần mềm dễ dự toán kiểm tra Dù sao, điều dẫn đến vấn đề nhà sản xuất phàn nàn phải nhiều thời gian vào việc thiết lập t- liệu cho xu h-ớng phát triển

t- liệu mức chi cơng sức q đáng vào tổng phí 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ôin công trình ph-ơng pháp luận phát triển cách có hệ thống bắt đầu xuất hiện3 Mục đích ph-ơng pháp luận là

làm cho phát triển phần mềm thành công Nếu thắng lợi đ-ợc theo mức độ ba mục tiêu nói tr-ớc (theo lịch trình, phạm vi ngân sách, theo yêu cầu) thất bại hẳn có nghĩa việc hồn thành chí mục tiêu Dù sao, thành cơng thất bại điều đ-ợc định nghĩa cách dễ dàng

Đã có nhiều nghiên cứu cho thấy thất bại dự án vấn đề nhận thức (cos Linto mantel 1990) Một dự án đ-ợc nhận định thất bại môi tr-ờng mơi tr-ờng khác dự án lại đ-ợc nhận định thắng lợi Nói cách đơn giản, khách hàng hài lịng với đầu dự án ng-ời khách khác lại không Theo thành công hay thất bại dự án không liên quan đến ba mục tiêu phát triển mà đến kỳ vọng khách hàng

Sự không rõ ràng quan niệm thất bại dự án chẵn tránh đ-ợc đặt đích Đây đích mà khách hàng đặt khơng phải đội ngũ phát triển đặt Điều có nghĩa là:

Thành công hay thất bại dự án đ-ợc tối hậu xác định hài lòng bên yêu cầu phát triển (nghĩa khách hàng) Những quan niệm đ-ợc chứng minh thí dụ sau:

1.3 Mét thÝ dơ:

Thí dụ cho thấy vài sai lầm quản lý thơng th-ờng mà cuối dẫn đến thất bại dự án phần mềm Dự án khởi với vài định sai lầm liên quan đến việc khởi hành dự án, đến l-ợt nó, lại dẫn đến nhiều định sai lầm dự án tiến triển

Công ty liên kết công nghệ (TAI) cơng ty chun mơn hóa việc phát triển chế tạo thiết bị truyền thông TAI ban phần mềm lớn chịu trách nhiệm 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 quản lý cơng ty tìm kiếm cơng ty phần mềm bền để phát triển hệ thống bảo d-ỡng thời gian cho TAI

Ban phần mềm TAI chủ động nắm bắt ý kiến, chuẩn bị đề nghị phát triển hệ thống đệ trình quản lý cơng ty Căn đề nghị hai tháng đ-ợc giành tham khảo ý kiến ban nhân sự, ban tài tr-ởng ban để xác định yêu cầu hệ thống Đội ngũ phát triển sau phát triển hệ thống tháng sau (tồn thời gian phát triển

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

kể phải tháng) Ban phần mềm dự tính cần đội ngũ ng-ời để cung cấp yêu cầu phát triển hệ thống

ý kiến sử dụng công ty phần mềm bên đ-ợc gác lại đề nghị 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 năm r-ỡi nhân công hay ng-ời tháng Ban phần mềm tiến hành lập đội ngũ dự án chọn ng-ời quản lý dự án, số ng-ời quản lý dự án truyền thông để lãnh đạo đội ngũ

Khi cuối đợt hai tháng ban đầu gần kề, nhà quản lý dự án thấy rõ phải cần nhiều thời gian để xác định viết t- liệu yêu cầu Ph-ơng án chọn lựa nhà quản lý dự ỏn l:

1 Hoặc yêu cầu nói rộng thời gian bổ sung ngân sách phát triển Hoặc sử dụng phần yêu cầu cã

Ng-ời quản lý ban muốn chứng minh ban có khả phát triển hệ thông tin phần mềm truyền thông đ-ợc lồng vào Do ng-ời quản lý dự án đội ngũ thúc chọn ph-ơng án Điều dựa tiền đề dự án bị chậm v-ợt ngân sách dự án phải bị coi thất bại hệ thống thông tin sau hẳn phải đ-ợc hợp đồng với công ty phần mềm bền

Tất ban khác thấy có nhiều vấn đề chủ yếu hệ thống Nói tóm lại hệ thống thiếu mà cơng ty cần

Ban phần mềm đề nghị sửa chữa sai sót yêu cầu ngân sách cho việc phát triển version cải tiến Dù sao, bất bình đến mức mà quản lý cơng ty định đ-a việc phát triển hệ thống hòan tồn cho 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ần kinh phí lại ngân sách mà ban phần mềm TAI yeue cầu để sửa chữa sai sót hệ thống ban đầu

ThÝ dơ (cã thËt) nµy thuyết minh số sai lầm chủ yếu quản lý dù ¸n

- Kinh nghiệm lĩnh vực phần mềm (các hệ viễn thông đ-ợc lồng vao) khong đủ cho việc phát triển thành công phần mềm 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 dự án đ-ợc xác định đủ Trong phần lớn tr-ờng hợp cam kết cơng ty có yêu cầu đ-ợc kết luận

- Nếu yêu cầu dự án không đ-ợc đáp ứng việc tham gia vào lịch trình ngân sách trở lên vô nghĩa

- Khách hàng hay ng-ời dùng cung cấp đ-ợc yêu cầu (thí dụ chủ yếu giao liên ban) Th-ờng trách nhiệm ng-ời sản xuất phải hỏi câu hỏi thích đáng nhằm thu thập thông tin cần thiết

1.4 Giành chấp nhận thủ tục phát triển míi.

Một trở ngại mà nhà quản lý dự án th-ờng phải khắc phục tình trạng thiếu hỗ trợ quản lý cấp cao ph-ơng pháp phát triển đại Vận dụng ph-ơng pháp luận hiệu không dễ quản lý cấp cao tranh luận nhu cầu họ Điều dẫn đến nhà quản lý dự án đến tình trạng tiến thối l-ỡng nam, chấp nhận đ-ợc mà họ tin tốt giữ đ-ợc c-ơng vị nhà quản lý dự án

Râ rµng lµ nhiỊu ph-ơng pháp kỹ thuật đ-ợc mô tả sách có hiệu lực chúng đ-ợc sử dụng Mục tiêu phần giúp nhà quản lý dự án giành đ-ợc chấp nhận quản lý cấp cao việc ứng dụng ph-ơng ph¸p míi

Quản lý cấp cao (và đơi kỹ s- phần mềm khác) có dùng lập luận sau chống lại việc sử dụng ph-ơng pháp luận phát triển phần mềm đại

1 Những ph-ơng pháp lý thuyết “thế giới thực” việc diễn khác

2 Những nhà quản lý dự án hình thức chủ nghĩa; họ đòi hỏi thứ văn không đồng ý thay đổi nhỏ

3 Chúng ta khơng có cho cơng việc giấy tờ

4 Chúng ta khơng thể cơng sức xa phí qui trình dài dặc Chúng ta ln phát triển đ-ợc phần mềm mà chẳng cần tổng phí

5 Đây kinh doanh khơng phải tr-ờng đại học Chúng ta tiền khách nều bắt đầu với việc lãng phí thời gian vào ph-ơng pháp

6 Ph-ơng pháp tốt, nh-ng bất hạnh lúc thực chúng Chúng ta mong sử dụng chúng ngày nh-ng khơng phải lúc

7 khơng có kỹ s- quen với ph-ơng pháp Nh- nhiều thời gian nhiều kinh phí để bắt đầu đào tạo lại họ

Sau số trả lời gợi ý cho lập luận

1 H s phỏt trin phần mềm giới thực ch-a phải tốt Trên thực tế, ph-ơng pháp cổ th-ờng dẫn đến thảm họa Có thành cơng nh-ng tỷ số thành công so với thất bại lại thấp

Bất ph-ơng pháp thiết thực có đôi chút lý thuyết nh-những ph-ơng pháp phát triển phần mềm nh-những ph-ơng pháp đ-ợc công ty t-ơng tự khác vận dụng thành công giảm mạnh kinh phí phát triển phần mềm tăng đáng kể chất l-ợng phần mềm

giao tiếp miệng đ-ợc hiểu đắn Nếu thay đổi hay h-ớng dẫn khác không ghi thành văn khơng đ-ợc chấp nhận, phát triển tiến hành theo h-ớng sai khơng chắn thay đổi, lớn nhỏ, sau đ-ợc nhớ lại dự án hoàn thành Danh mục thành văn thay đổi đ-ợc chấp nhận giúp khả theo dõi hạch tốn

3 Đây khiếu lại đáng l-u ý; công việc giấy tờ phải đ-ợc trì mức tổi thiểu (có q mức) Dù sao, đáng ngạc nhiên công việc giấy tờ có mức độ thực lại tiết kiệm thời gian khơng gây lãng phí Chẳng hạn định không ghi thành văn th-ờng cần đ-ợc lặp lặp lại đặc tả nói miệng dẫn đến lý giải gây tranh cãi Việc thiếu t- liệu th-ờng nhiều thời gian pha thích hợp thử nghiệm thiết kế hệ thống đ-ợc l-u trí nhớ ng-ời

Cũng vậy, dự án không thành văn ác mộng việc tu Sau hoàn thành dự án, nhà sản xuất phân tán đi, tất cịn lại sản phẩm t- liệu Khơng có t- liệu sản phẩm khơng bí mật

4 Một câu hỏi cần phản ảnh là: liệu liệu phát triển phần mềm thực thành công nào? Lập luận đ-ợc thử thách tốt với hồ sơ t- liệu đ-ợc chuẩn bị cho biết vấn đề mà cơng ty có kinh nghiệm dự án tr-ớc Mục tiêu chứng minh tiếp cận với phát triển phần mềm đâu phải xa xỉ mà cần thiết

5 Những lập luận khó đ-ơng đầu có yếu tố thực chúng, đặc biệt cơng ty có định ý phát triển ph-ơng pháp luận họ Mổc dù nhiều cơng ty có tiến hành nghiên cứu cơng trình phần mềm điều thật khó cần thiết cơng ty có ph-ơng pháp luận tiêu chuẩn h-ớng dẫn đ-ợc ghi thành văn thỏa đáng (coi IEEE 1987b) chúng đ-ợc vận dụng dễ dàng công ty mà không cần thiết phải phát triển chúng lại

Mất khách hàng không lịch trình phát triển kéo dài mà chất l-ợng nhu cầu kỹ thuật không đ-ợc thỏa mÃn Càng cần nghiêm lệnh hẳn phía lịch trình phát triển lâu 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 thời gian bổ sung đòi hỏi để bổ sản phẩm phần mềm cỏi, sau tung lần đầu (coi thí dụ phần 1.3)

tin thu thập từ công ty khác Mục tiêu bày tỏ qui tình phát triển có thứ tự làm tăng chất l-ợng sản phẩm phần mềm công ty giảm chi phí phát triển

7 Tầm quan trọng việc đầu t- đào tạo cần đ-ợc nêu: quan niệm đ-ợc chấp nhận rộng rãi Lập luận khó bác bỏ ph-ơng pháp phát triển đ-ợc đ-a coi nh- thay đổi chủ yếu ph-ơng h-ớng Câu trả lời tốt tùy thuộc tình hình thực tế Nếu ph-ơng pháp thực tiêu biểu cho thay đổi chủ yếu ph-ơng h-ớng chắn cơng ty có thí nghiệm nhiều vấn đề phát triển phần mềm Nh- câu trả lời cho lập luận thích đáng

Nếu ph-ơng pháp không thực tiêu biểu thay đổi chủ yếu ph-ơng h-ớng điều nêu đ-ợc chứng minh có sử dụng liệu dự án tr-ớc T- t-ởng chứng minh rắng nhiều qui trình phát triển tinh vi, việc cải tiến đáng kể đ-ợc thực thông qua việc giới thiệu số ph-ơng pháp

Mọi lập luận chống lại ph-ơng pháp luận phát triển bác bỏ đ-ợc sau có chuẩn bị đầy đủ Điều th-ờng ngha l:

- S-u tập liệu dự án phát triển phần mềm tr-ớc phạm vi v«ng ty

- S-u tập dự liệu công ty t-ơng tự chấp nhận ph-ơng pháp phát triển

- S-u tập báo cáo có dẫn t- liệu, văn chứng cớ khác thành văn (cần đề phòng lý thuyết)

- Có đ-ợc hỗ trợ chuyên gia phát triển phần mềm khác phạm vi công ty

Mọi liệu cấn đ-ợc nghiên cứu ghi đ-ợc chuẩn bị chứng minh nhu cầu ph-ơng pháp phát triển Dòng cuối phải việc vận dụng qui tình mới, thiết thực phát triển phần mềm lợi Ých cđa c«ng ty

Đã giành đ-ợc phê chuẩn cần thiết quản lý cấp trên, nhà quản lý dự án phần mềm chuyển sang vận dụng ph-ơng pháp mô tả ch-ơng sau B-ớc đầu việc tìm hiểu vấn đề việc phát triển phần mềm đ-ợc thảo luận ch-ơng

1.5 Tãm t¾t.

Việc phát triển phần mềm khống chế đ-ợc Có ph-ơng pháp, kỹ thuật, tiêu chuẩn cơng cụ đ-ợc vận dụng 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 trí óc để phát triển phần mềm

Thắng lợi hay thất bại dự án không liên quan đến ba mục tiêu phát triển nh-ng đến kỳ vọng khách hàng: khách hàng hài lịng với đầu dự án khách hàng khác lại không Do đấy, thành công dự án đ-ợc xác định tối hậu hài lòng khách hàng

Một trở ngại mà nhà quản lý dự án th-ờng phải khắc phục thiếu hỗ trợ quản lý cấp ph-ơng pháp phát triển đại Rõ ràng nhiều ph-ơng pháp kỹ thuật mô tả sách này, có hiệu lực chúng đ-ợc sử dụng

Mọi lập luận chống lại ph-ơng pháp luận phát triển chí bác bỏ sau có chuẩn bị đầy đủ

Ch-¬ng hai

Những vấn đề phát triển phần mềm

Mét chót phßng xa

Tại lớp học đầy quản lý dự án phần mềm, học viên hỏi:

“Chúng tơi có số vấn đề chủ yếu dự án mà tơi quản lý Chúng tơi khơng có đ-ợc t- liệu có hệ thống hay có đ-ợc kế hoạch phát triển dự án đ-ờng v-ợt ngân sách chậm lịch trình Vậy tơi phải vận dụng ph-ơng pháp kỹ thuật học nhằm làm cho dự án trở lại lịch trình ?”

Đây khơng phải tình khơng phổ biến đó, ph-ơng thuốc thấn kỳ tìm cho tình gần gây thảm họa Những dự án quản lý tối đến trì trệ ngân sách v-ợt đến hai chí ba trăm phần trăm vài tr-ờng hợp lại bị bãi bỏ Hầu hết ph-ơng pháp quản lý dự án đại ban đầu quan tâm phịng xa (chứ khơng phải hiệu chính) vấn đề loại

Việc phịng ngừa vấn đề dễ tốn giải 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ấn đề tiềm ẩn

- Giải vấn đề tr-ớc chúng tuột khỏi tầm tay

- Lập kế hoạch tr-ớc (đối phó) với vấn đề tiểm ẩn Những vấn đề trở nên tốn giải dự án tiến triển đến giai đoạn phát triển cao Những vấn đề bị lãng quên lan truyền sang lĩnh vực khác dự án làm cho việc hiệu chúng trở nên khó khăn Do việc thiết lập qui trình để định vị sớm hiệu vấn đề quan trọng

Ch-ơng giải nguyên nhân số thể loại thông th-ờng vấn đề phát triển phần mềm thảo luận tác động chúng đến trình phát triển Ch-ơng thảo luận việc dự kiến vấn đề nhằm giảm thiểu tác động chúng tới dự án Các ch-ơng sau đề ph-ơng pháp phòng ngừa vấn đề mô tả khỏi xảy

2.1 Những vấn đề bản.

Có nhiều vấn đề mà nhà quản lý dự án hình nh- tìm thấy dự án phầm mềm Những vấn đề gây tình sau phịng tr-ớc phát sinh:

- Yêu cầu ban đầu khơng đầy đủ

- Phơ thc ë c¸c ngn bên (các ng-ời bán hàng, chủ thầu phụ v.v )

- Các khó khăn kết thúc dù ¸n

Các vấn đề khác th-ờng nảy sinh sai lầm quản lý thơng th-ờng nh-:

- Dù to¸n tåi

- Theo dõi giám sát không đầy đủ - Thay đổi khơng kiểm sốt đ-ợc

Con đ-ờng tốt để định vị vấn đề sớm tìm Rõ ràng, tìm xem vần đề th-ờng nảy sinh nhiều đâu Chẳng hạn thay đổi th-ờng xuyên không kiểm tra đ-ợc với việc đặc tả yêu cầu th-ờng hiển nhiên nguồn chủ yếu vấn đề thiết kế Những chủ thầu phụ ng-ời bán hàng không giám sát đ-ợc nguồn bất ngờ, thông th-ờng đặc biệt lúc họ báo cáo vấn đề kỹ thuật trì hỗn vào, phút cuối nhà quản lý dự án việc biết phải kiếm quan trọng nh- việc biết phải làm

2.1.1 Những vấn đề liên quan đến yêu cầu dự án.

Đặc tả yêu cầu dự án mô tả sản phẩm phải đ-ợc sản sinh nhóm phát triển (coi ch-ơng 4) Nếu yêu cầu khơng đ-ợc đặc tả đầy đủ may mắn túy đảm bảo đ-ợc sản phẩm đáp ứng yêu cầu khách hàng4 Sau số thí dụ vấn đề

liên quan đến đặc tả yêu cầu nghèo nàn - Quên đặc điểm

Khách hàng tin số đặc điểm bị bỏ quên hẳn phải nằm sản phẩm thảo luận khơng thức (th-ờng với ng-ời khơng đúng) Ghi chép, bình luận nhận xét họp nh-ng không đặc tả u cầu thức

- Có đặc điểm không cần thiết đ-ợc đ-a vào

Đội ngũ phát triển tin khách hàng hẳn vui thích đặ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ụ thêm truy nhập hệ thống ngữ khách hàng lại muốn hệ thống sẵn sàng cho

- Đặ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 đủ mộ đặc điểm cần thiết đội ngũ phát triển hiểu yêu cầu theo cách hiểu Một thí dụ yêu cầu "cập nhật th-ờng xuyên sở liệu" Các nhà phát triển tạo hệ thống cập nhật sở dự liệu lần ngày khách hàng muốn nói lần

- Những đặc điểm cần thiết mà chẳng nghĩ đến

Khách hàng không cần thiết chun gia máy tính không ý thức đ-ợc đặc điểm, đặc biệt phải cần đến Thí dụ nhu cầu bade up đầy đủ; khách hàng cho bade up khơng cần thiết dịch vụ máy tính bị giám đoạn (thí d

4Từ khách hàng đ-ợc sử dụng theo nghĩa rộng bao gồm khách hàng thøc, ban tiÕp

mất điện) việc hay hai giao dịch l-u trữ nhớ chẳng thành vấn đề Thế nh-ng khách hàng khơng xem xét việc điều khiển đĩa đổ vỡ dự liệu họ

Rõ ràng yêu cầu đ-ợc đặc tả lại vấn đề cho nhà phát triển nhiều nh- cho khách hàng Dù sao, nhà sản xuất th-ờng vị tốt để biên soạn yêu cầu khách hàng Thông th-ờng đặc tả yêu cầu tốt kết cố gắng phối hợp nhà phát triển lần khách hàng với văn thực đ-ợc soạn thành văn nhà phát triển đ-ợc chấp nhận khách hàng

2.1.2 Những thay đổi th-ờng xuyên.

Thật tìm đ-ợc dự án phần mềm qui hoạch tốt lạ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 khơng tránh khỏi suốt chu trình phát triển phần mềm Dù sao, phần lớn tr-ờng hợp thay đổi đ-ợc đ-a chậm thực thay đổi lại tốn

Một số thay đổi thỏa đáng phải quản lý đ-ợc Khi dòng thay đổi đổ vào nh- thác lũ chúng trở thành vấn đề Ngay thay đổi thành vấn đề đ-ợc yêu cầu phát triển dự án dẫn đến thay đổi chủ yếu ph-ơng h-ớng Những thay đổi mức tạo nên th-ờng đ-ợc coi hội chứng mục tiêu di động Nhà quản lý dự án thay đổi ph-ơng h-ớng đội ngũ phát triển trở vừa bối rối vừa mục tiêu

Thay đổi phá vỡ dự án chúng không đ-ợc ghi thành văn 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 chế kiểm tra thay đổi cách có hệ thống Ph-ơng pháp phạm vi tổ chức kiểm tra cấu hình, đ-ợc thảo luận ch-ơng

2.1.3 Dự toán vấn đề liên quan.

Dự tốn tốt quan trọng chúng tạo thành móng kế hoạch phát triển dự án tốt Kế hoạch đó, nhà quản lý dự án chuẩn bị đ-ợc lập thành giai đoạn ban đầu dự án bao gồm dự toán liên quan đến

- Ngân sách phát triển dự án - Lịch trình phát triển dự án

- Ti nguyờn phỏt triển cần đến (đội ngũ phát triển thiết bị phát trin v.v )

Những dự toán kỹ thuật đ-ợd hình thành pha thiết kế bao gồm:

- Các đặc tính phần cứng cỡ mục tiêu cần đến (dự toán tốc độ CPU, khả đầu vào, đầu ra; khả điều khiển đĩa v.v )

Dự toán sở cho nhiều định kỹ thuật quản lý dự toán tồi dẫn đến định dở Dự toán tồi hiểu cao thấp định theo tạo lãng phí thiếu tài nguyên phát triển Điều hình thành sai lầm qui hoạch, nh-:

- Lịch trình ngắn cao thái - Ngân sách thấp hay tăng giả tạo

- Quá thiếu hay thừa ng-ời làm sai lÇm thiÕt kÕ kü thuËt, nh-:

- Những máy tính mục tiêu nhiều (và đắt hơn) cần thiết 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 vấn đề nảy sinh từ dự toán cao Hiểu rõ điều này, nhà dự toán th-ờng thêm vào số yếu tố bất trắc (cho đến 30%) dự toán minh, giả định cao thấp Dù dự tốn cao khơng gây thất bại dự án nh-ng ngăn cản dự án chẳng đ-ợc khởi công Đã có nhiều ph-ơng pháp đ-ợc phát triển nhằm tạo loại dự toán khác giai đoạn khác dự án (coi ch-ơng 10) Dù sao, dự toán chuẩn bị tốt dẫn đến vấn đề chúng khơng đ-ợc cập nhật sở định kỳ đặn Rõ ràng thông tin tốt đầy đủ tạo dự toán tốt Do dự án tiến triển có nhiều thơng tin hơn, dự toán cần đ-ợc xem xét lại hiệu chỉnh Điều dẫn đến việc giám định lại định phát triển, tạo cho vấn đề tiềm ẩn đ-ợc đề cập sớm tr-ớc chúng trở thành gay cấn (coi phần 2.2 phân tích rủi ro)

2.1.4 Nguồn lực bên ngoài.

Cỏc đề phát triển dự án th-ờng dễ quản lý nhân tố phát triển đ-ợc điều khiển quản lý dự án Dù sao, điều có đ-ợc Nhiều dự án phụ thuộc nhiều nguồn bên ngồi nh-:

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

- Những dự ¸n ph¸t triĨn song hµnh

- Những ng-ời cung cấp dịch vụ (bảo trì, huấn luyện, lắp đặt v.v ) - Các chức hỗ trợ (thông tin điện thoại mạng, cung cấp dự liệu Dự phụ thuộc vào nguồn bên hẳn phải đ-ợc phản ánh trng)

Kế hoạch phát triển dự án Điều có nghĩa phạm vi giao -ớc dự toán nhận đ-ợc từ nguồn khác Theo thế, dự toán kế hoạch tốt dự toán nhËn tõ c¸c nguån kh¸c

- Chậm trễ lịch trình, việc giao chậm thành phần dự án

- Sự cỏi chất l-ợng thiết kế thiết bị phát triển thành phần dự án bên

- Thnh phn bên ngồi khơng t-ơng hợp sai lệch nhà phát triển bên 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 thành phần bên ngồi Do có ý thức đ-ợc vấn đề tiềm ẩn đó, nhà quản lý dự án đảm bảo họ đ-ợc định vị thích hợp hợp đồng hay thỏa thuận với nguồn bên ngồi Những vấn đề đ-ợc ngăn ngừa nều đ-a vào hợp đồng mức phát chậm trễ giao hàng hay khuyết tật sản phẩm (coi ch-ơng ch-ơng 9) Những đề phịng sớm đ-ợc phát th-ờng xun xét duyệt lại công việc đ-ợc phát triển chủ thầu phụ đòi hỏi báo cáo tiến độ th-ng k

2.1.5 Kết thúc dự án phần mÒm.

Nh- nhà quản lý dự án biết, dự án khó mà bắt đầu đ-ợc kinh nghiệm cho thấy chúng th-ờng khơng khó khăn để đến kết thúc Đi tới đoạn kết dự án, luôn bên quan tâm khác phát sinh yêu cầu Nh- phê phán thay đổi hoạt động phút chót khác Điều đặc biệt có thực với 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 đề liên quan đến việc kết thúc dự án là:

- Tranh chấp khách hàng nhà phát triển việc lý giải cung ứng đặc điểm đ-ợc yêu cầu

- ý đồ đ-a vào thay đổi phút chót

- Thất bại hệ thống khuyết tật thiết kế xác định trình cài đặt thử nghiệm hệ thống

- Khó khăn việc giữ cho đội ngũ phát triển hợp lực lại với động Khi tình hình thẳng giảm vào gần cuối dự án có tình trạng sút giảm nhiệt tình t-ơng ứng thành viên lại đội phát triển

Trách nhiệm nhà quản lý dự án đảm bảo cho việc kết thúc dự án có trật tự thắng lợi Điều đ-ợc thực nhờ việc qui hoạch chi tiết lúc ban đầu dự án quản lý dự án có hiệu xuyên suốt dự án Đặc biệt, điều đòi hỏi rằng:

- Kế hoạch thử nghiệm thu phải đ-ợc chuẩn bị lập tài liệu đ-ợc khách hàng phê chuẩn tr-ớc kêt thúc dự án Mức độ nhân 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 qui mơ đội ngũ phát triển vào cuối dự án

-Việc đ-a ấn phẩm thị tr-ờng phải đ-ợc lập kế hoạch tốt, kể đóng gói soạn thảo t- liệu, huấn luyện, cài đặt chuyển tiếp có trật tự sang pha bảo trì hỗ trợ

phát triển nghèo nàn, tất dẫn đến vấn đề chủ yếu lúc kết thúc dự án

2.1.6 Tuyển dụng nhân viên thuyên chuyển.

Khú khn việc tuyển dụng thành viên đội ngũ phát triển vấn đề mà ng-ời quản lý dự án phần mềm gặp phải Tr-ớc dự án đ-ợc tung ra, đội ngũ phát triển ban đầu phải đ-ợc thiết lập vấn đề không kết thúc đội ngũ vị Giữ đ-ợc đội ngũ th-ờng khó nh- thiết lập

Frenkel (1985) báo cáo nhu cầu kỹ s- phần mềm tăng theo hàm số mũ suất tăng theo mức khoảng 5% năm Các tr-ờng đại học Hoa kỳ châu Âu không cung cấp kỹ s- phần mềm đủ để bù đắp lỗ hổng cung cầu Trên thực tế khơng lỗ hổng khơng đ-ợc lấp kín mà lại rộng mức đáng lo ngại

Khối l-ợng thời gian bình quân mà kỹ s- phần mềm lại nghề giảm yêu cầu kỹ s- tăng Điều không gây thuyên chuyển kỹ s- phần mềm công ty mà sở thuyên chuyển phạm vi công ti Vì công ty tìm cách sử dụng hữu hiệu kỹ s- Sự thuyên chuyển phạm vi công ty không tình trạng thiếu kỹ s- phần mềm mà chi phí họ ngăn trở thành việc tuyển bổ sung.5

Thuyờn chuyển nhân thân vấn đề trọng yếu Sự ổn định có đội ngũ vào thắng lợi dự án

Các vấn đề liên quan đến tuyển nhân thuyên chuyển bao gồm:

- Việc đầu t- đáng kể đ-ợc đòi hỏi đ-ờng biểu diễn học tập đào tạo thành viên đội ngũ phát triển

- Thuyên chuyển nhân luôn giảm tinh thần đội ngũ tác động không lợi đến động đội ngũ

- Tuyển chọn th-ờng tốn địi hỏi nhiều vấn phí tuyển dụng

- Thun chuyển nhân ln tạo tình trạng thiếu kiện định phát triển dự án

Trong vấn đề phát triển phần mềm, liên quan đến phát triển đội ngũ th-ờng đ-ợc nhận thức gay cấn Các thành viên đội nguồn phát triển quan trọng cỡ họ đóng góp nhiều cho thành công hay thất bại dự ỏn

5 Kinh tế học có đ-ợc kỹ s- chi phí hä sÏ

2.1.7 Theo dâi vµ gi¸m s¸t.

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

- Luông thông tin khơng xác hay khơng có Đóng góp đáng kể vào định quản lý tồi

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

- Trí tuệ lịch trình bội chi ngân sách, điều gây dự tốn tồi dựa vào thơng tin khơng

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

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

hạn, giá phận thay thiết bị phát triển Trong tr-ờng hợp, vấn đề đ-ợc phân tích giải sớm đơn giản nhiều so với việc giải vấn đề sau phát sinh bất ngờ

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

Giai đoạn phân tích rủi ro địi hỏi duyệt xét kế hoạch quản trị kỹ thuật dự án nhằm minh định vấn đề tiềm ẩn bao gồm:

- 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ụ 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 bị chậm

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

3 Kh«ng cã chuyªn gia

hệ thống điều hành Hệ thống đòi hỏi thay đổi cho hệ thống điềuhành chuẩn J.Adams chuyên gia hệ điều hành công ty ơng bận khơng đ-ợc sử dụng cho hệ thống

4 Thời gian đáp ứng

hệ thống chậm Thời gian đáp ứng hệ thống yêu cầu cho đầuvào giây so với đặc tả yêu cầu

5 Thuyên chuyển nhân

sự nhiều Lịch trình x¸t xao víi thêi gian trèng tèithiĨu NÕu cã sù thay thể nhân mức bình quân phát triển tr-ợt thêm lịch trình

6 Truyền thông

chậm Góc truyền thông chuẩn chậm Thiết kế dựatrên gói truyền thông nhị phân Góc ch-a đ-ợc sử dụng với hệ thống không thích hợp

7 ChËm giao vµ hƯ

thống phụ sở liệu Hệ thống phụ sở 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 khơng giao thời hạn nên làm chậm thích hợp pha thử nghiệm cuối

nh-chủ thầu phụ, ng-ời bán hàng, nhà cung cấp nhà làm dịch vụ Các vấn đề nảy sinh 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 kế hoạch chi tiết việc làm để yêu cầu đ-ợc thực Các định thực đ-ợc địi hỏi chứa vấn đề tiềm Chẳng hạn, vấn đề nảy sinh phần cứng đ-ợc lựa chọn lại hóa khơng thích hợp, chẳng hạn nh-CPU q chậm, mạng cục không đủ tin cây, nhớ không đủ

Sau vấn đề dự liệu đ-ợc tập hợp lên danh sách, vấn đề đ-ợc minh định mô tả tác động tiềm ẩn ảnh h-ởng tới dự án Bảng 2.2 cho thí dụ 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ó tham gia thành viên đội ngũ phát triển dự án Những ng-ời khác đ-ợc mời đóng góp cho danh sách đó, ỉw kinh nghiệm kiến thức kỹ thuật hay quản trị họ; Có thể bao gồm ng-ời từ đội ngũ dự án khác, nhóm hỗ trợ phòng pháp chế hay phòng mua sắm (kinh doanh) công ty

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

2.2.2 Pha ph©n tÝch

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

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

Xác suất tác động đ-ợc dự toán ng-ời Mọi hạng mục danh sách đ-ợc dự toán tốt họp đánh giá vấn đề để đảm bảo tính t-ơng đối mức độ nghiêm trọng, vấn đề không bị lệch lạc Mục tiêu tránh tình việc chậm giao bên cung cấp A đ-ợc ng-ời dự toán 0.8 việc chậm giao bên cung cấp B đ-ợc ng-ời khác dự toán 0.6 nhà dự toán hẳn đồng ý hai xác suất Nếu hai ng-ời phịng lúc lệc lạc t-ơng đối giảm

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

2 Gán số 10 tác động vấn đề với dự án với 10 biểu thị tác động cao 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 thí dụ cách tính mức độ nghiêm trọng có sử dụng vấn đề dự liệu mơ tả bảng 2.1

Bảng 2.2 Thí dụ 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 30

2 Bộ nhớ không đủ

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

5 25

4 Thời gian đáp ứng hệ thống

quá chậm 15

5 Thuyên chuyển nhân cao 40

6 Truyền thông qu¸ chËm 16

7 ChËm giao hƯ thống phụ sở liệu

3 27

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

B¶ng 2.3 Thí dụ bảng ngẫu nhiên

Vn Nghiêm

trọng Kế hoạch đối phó bất ngờ theo dừiNg-i

5 Thuyên chuyển

nhân cao 40 Cho tiền th-ởng hoàn thànhdự án thắng lợi J.Smith ChËm giao m¸y

tính để phát triển 30 u cầu làm ca đêm hệthống phát triển dự án khác

H.Brown ChËm giao hÖ

thèng phụ sở liệu

27 Thit k mt mô hệ thống phụ sở liệu dùng tớch hp

W.Alda Không có chuyên

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

H.Brown Truyền thông

chm 16 Hp 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

H.Troy

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

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

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

(khụng xem xét)

2.2.3 Thực kế hoạch đối phó bất ngờ.

Các kế hoạch đối phó bất ngờ đ-ợc thực tr-ờng hợp sau:

1 Vấn đề liệu diễn hay 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, kế hoạch đối phó bất ngờ đ-ợc nhìn nhận theo nh- kế hoạch, hành động đ-ợc xếp vào ngăn kéo để phòng dùng đến sau Dù sao, vài tr-ờng hợp, kế hoạch đ-ợc thực tr-ớc vấn đề dự liệu xảy nh- phát triển mô tr-ờng hợp việc giao hợp phần định bị chậm trễ Sau đó, họpw phần đ-ợc giao hạn mơ bị bỏ

Lấy thí dụ q trình hồn chỉnh thử xem xét dự án truyền thông cần đến máy tính trung tâm nối 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

- Cơng ty điện thoại đ-ợc chọn khơng có khả 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 đề 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 có thểdiễn giải thể thức truyền thông thiết kế khác

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

Cơng ty điện thoại đ-ợc chọn khơng có khă lắp đặt đ-ờng dây thử nghiệm 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 40

2 Đ-ờng dây thử nghiƯm cã chËm

để tích hợp 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ử nghim cú chm tớch hp

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

Will Doo 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 2.6 bảng phân tích rủi ro cho dự án truyền thơng Nừu khả có đ-ợc đ-ờng dây truyền thơng bị chậm lại, điều gây tác hại cho dự án vấn đề thể thức không t-ơng hợp Việc theo dõi vấn đề đ-ợc giao cho Wieliam Joo.Trách nhiệm ông đảm bảo đ-ờng dâ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 sẵn sàng hẹn đơn đặt hàng từ hai cơng ty khác đ-ợc hủy khả phí hủy bỏ phải trả

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

2.3 Tãm t¾t

Các ph-ơng pháp quản lý dự án đại lúc đầu quan tâm đến việ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 vấn đề dễ tốn giải chúng, biện pháp phòng ngừa có hiệu nêu là:

- Định vị vấn đề vấn đề tiềm ẩn sớm - Giải vấn đề tr-ớc tuột khỏi tầm tay - Lập kế hoạch tr-ớc cho vấn đề tiềm ẩn

Có nhiều vấn đề chung cho hầu hết dự án phầm mềm Phần lớn vấn đề dẫn xuất từ:

- Xác định yêu cầu không đầy đủ - Thay đổi ln

- Dù to¸n tåi

- Tïy thc nguồn bên (ng-ời bán, chủ thầu phụ v.v ) - Khó khăn kết thúc dự án

- Luôn thay nhân phát triển (thuyên chuyển nhân sự) - Theo dõi giám sát không đầy đủ

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

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

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

Bµi tËp

1 Một cơng ty dịch vụ truyền hình cáp chuẩn bị thiết lập dịch vụ thời gian tháng Công ty cung cấp dịch vụ cho 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 cho chiếu phim phim cho khách hàng xem theo yêu cầu qua điện thoại với công ty

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

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

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

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

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

Hãy chuẩn bị bảng đối phó bất ngờ có chứa 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 nhóm hay sinh viên Giao tập 1, 2, cho hóm Yêu cầu nhóm trình bày phân tích rủi ro cho số nhóm lại lớp

Thảo luËn :

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

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 thay đổi nhanh chóng cơng nghệ vài thập niên gần đây, tổ chức công nghệ cao ngày thấy cần thiết phải chuyển hóa lĩnh vực đặc chủng, xác định rõ việc chuyển hóa khơng xác định nhiều nhánh cơng trình học mà cịn xác định lĩnh vực chuyên môn phạm vi mơn cơng trình học Điều đặc biệt với cơng trình phần mềm

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

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

Để tiêu chuẩn hóa thuật ngữ chúng ta, tổ chức mà đề nghị đ-ợc đệ trình đ-ợc coi khách hàng tổ chức đệ trình đề nghị đ-ợc coi 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 cho khách hàng ng-ời yêu cầu hay ng-ời đề xuất yêu cầu Tổ chức đ-a đề nghị đ-ợc thẳng thầu sau lựa chọn, đ-ợc coi nhà phát triển

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

Th-ờng có mâu thuẫn quyền lợi thực hay t-ởng t-ợng khách hàng với ng-ời phát triển Khách hàng muốn chi phí ng-ời phát triển lại muốn thu nhập nhiều Nh- thấy mối quan hệ tốt ng-ời phát triển khách hàng không cần thiết phải dẫn đến tranh chấp quyền lợi nh-

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

2 Giá cố định

Hầu hết quan hệ khác hình thức phối hợp hai loại

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

Phí cộng thêm 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 thêm vào đ-ợc phép h-ởng mức lời thỏa thuận Điều thực 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 ) cho chi phí khác nh- bảo hiểm xăng Theo hợp đồng phí cộng thêm, tổng phí dự án đ-ợc biết sau dự án hoàn thành

Lấy thí dụ, cơng ty Alpha hợp đồng với công ty phần mềm Bêta để phát triển hệ thống Công ty Bêta đ-ợc công ty Alpha trả cho 180 cho kỹ s- minh đầu t- cho dự án khoản 20% bổ sung đ-ợ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 cơng ty Bêta lợi ích dự án sau đ-ợc cơng ty Alpha bồi hồn chi phí bù đắp lĩnh vực nh-:

- Thiết bị phát triển mục đích đặc tr-ng (máy tính, dịch, mạng v.v )

- Chi phÝ ®i lại phát sinh nhân viên công ty Bêta lợi ích dự án

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

- Dịch vụ từ nguồn bên khác công ty Bêta yêu cầu cho dù ¸n

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

Phí cộng thêm đ-ợ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 số tr-ờng hợp, ng-ời sản xuất đ-ợc coi nh- phần mở rộng tổ chức khách hàng hoạt động phát triển khách hàng quản lý

Hợp đồng phí cộng thêm phải bao gồm điều sau: - Danh sách 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 ng-ời

- Mức công việc hàng hay hàng ngày cho 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 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à ng-ời giành cho dự án Nó 100% cho số kỹ s-, 50-60% cho chuyên gia lĩnh vực đặc biệt Tỷ lệ phần trăm giao việc đ-ợc tính hiểu theo tối đa hay tối thiểu, có nghĩa, chẳng hạn, kỹ s- bảo hành chất l-ợng giành không 20 tuần cho dự án khơng 10 tuần cho dự án

Giá suất lập phiếu giá suất cố định cho ng-ời đ-ợc giao việc dự án hay mức cá nhân đ-ợc đặt cho lớp ng-ời Chẳng hạn với làm việc cho dự án, ng-ời sản xuất lập phiếu toán $80, làm việc cho Hay hợp đồng qui định kỹ s- thiết kế đ-ợc lập phiếu toán $120 giờ, ng-ời lập mã $60 giờ, ng-ời viết t- liệu $50 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ó ph-ơng pháp lập phiếu toán cá nhân theo Franh Jones đ-ợc lập phiếu toán $90 John Shith $75 v.v Điều có nghĩa ng-ời đ-ợc thay hay bổ sung cho dự án giá suất theo lại phải th-ơng thảo lại

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

- 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- phần lớn tr-ờng hợp, thuận lợi lại số bật lợi bao gồm:

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

- Cã thĨ cã sù bÊt b×nh nhân - Kiểm tra nhân công việc ph¸t triĨn

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

Hầu hết nhân viên chuộng có đ-ợc xác định rõ ràng 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 phạm vi tôn ti khách hàng nh-ng lại thuộc tôn ti ng-ời phát triển điều gây bất mãn

Nói chung, theo quan điểm ng-ời phát triển, hợp đồng phí cộng thêm 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 khách hàng thuận lợi hợp đồng phí cộng thờm l:

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

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

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

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

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

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

Với khách hàng, khó xác nhận hấp dẫn hợp đồng phí cộng thêm Rõ ràng điều thùy thuộc loại dự án điều kiện để dự án phát triển 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 cam kết ng-ời phát triển cung cấp sản phẩm hay dịch dụ thỏa thuận với phí thỏa thuận phạm vi lịch trình thỏa thuận Điều t-ơng tự với mua tíc kê xe buýt theo cơng xe bt thỏa thuận đ-a khách hàng đến nơi định 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 chọn th xe khơng mua tic kê xe buýt tự lái đến nơi Dù sao, điều trở nên tốn đòi hỏi ng-ời du khách đôi chút kỹ kiến thức tr-ớc nh- kỹ lái xe kiến thức hành trình đến nơi Nừu du khách (hay khách hàng) phải định việc tự tạo dịch vụ việc hợp đồng với để cung cấp dịch vụ

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

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

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

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

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

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

Một tổ chức phần mềm thắng lợi th-ờng chuộng hợp đồng giá cố định Đó th-ờng dự án tạo dựng danh tiếng chuyên môn công ty phát sinh lợi tức đảm bảo tăng tr-ởng Bất hạnh dự án gây lỗ 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 làm cho công ty nhận thầu giá thấp cuối gây lỗ cho ng-ời phát triển

Hầu nh- tránh khỏi dự án ng-ời phát triển đ-ợc đòi hỏi thay đổi yêu cầu trình phát triển Những thay đổi nh- th-ờng liền với chi phí bổ sung địi khánh hàng nguyên nhân bất đồng ng-ời sản xuất khách hàng Điều th-ờng yêu cầu không rõ hay mơ hồ lại dẫn đến bất đồng tiêu việc hoàn thành dự án Về bản, điều làm cho hợp đồng trở lại trạng thái không đ-ợc xác định đầy đủ

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

- Ngân sách cố định cho dự ỏn

- Hầu hết rủi ro phát triển đ-ợc chuyển sang ng-ời phát triển + tham gia tối thiểu 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

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

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

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

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

- Liên doanh

- Thỏa thuận quyền - Cam kết lâu dài

phn 3.1 xem xét thí dụ dự án phối hợp phí cộng thêm giá cố định phần yêu cầu đ-ợc phát triển theo phí cộng thêm phần cịn lại dự án phát triển theo gía cố định

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

Cú cách mà khách hàng chào ng-ời phát triển tham gia vừa phải vào mặt kinh doanh dự án cách thay quyền coi nh- toán phần Điều tạo nên qui mơ bổ sung cho lợi ích ng-ời phát triển thành công dự án Bản quyền thông th-ờng chỗ thất bại dự án tạo nên lợi nhuận cho ng-ời phát triển hợp đồng giá cố định thẳng thừng thắng lợi dự án làm tăng lợi nhuận ng-ời phát triển

Mối quan hệ lâu dài th-ờng quan trọng cho ng-ời phát triển Trong nhiều tr-ờng hợp, cam kết dài hạn nằm lợi ích khách hàng Điều xảy ng-ời phát triển gắn bó hợp đồng ban đầu, giành đ-ợc lợi chủ yếu, qua kiến thức thu l-ợm, ng-ời khác cho công việc phát triển tiếp sau Rõ ràng ng-ời phát triển hoàn thành thắng lợi dự án lớn phức tạp, có đ-ợc lợi đáng kể so với công ty khác tăng c-ờng t-ơng lai dự án Cam kết lâu dài theo có lợi ích t-ơng hỗ cho hai bên khách hàng đảm bảo dịch vụ sau ng-ời phát triển 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 đề xuất (RFP).

RFP cần đ-ợc chuẩn bị nào, tr-ớc hết duyệt lại b-ớc dẫn tới định đ-a yêu cầu đề nghị

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

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

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

Tr-ớc thuê dịch vụ phát triển tổ chức khác, số vấn đề cần đ-ợc xem xét tới:

- Các mục tiêu dự án ?

- Các tổ chức đ-ợc xem xét cho cơng việc ?

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

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

- Ai, 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 đ-ợc giành cho hợp đồng ?

Tất vấn đề phải đ-ợc nêu đầy đủ tr-ớc sang b-ớc sau: việc chun b cỏc RFP

3.3.2 Chuẩn bị RFP.

Yêu cầu tốt với đề nghị yêu cầu lôi đ-ợc đáp ứng tốt (đề nghị) Chuẩn bị RFP tốt th-ờng đòi hỏi cộng tác nhiều ng-ời, ng-ời đ-ợc giao trách nhiệm phần đặc biệt RFP

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

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

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

- Yêu cầu sở dự liệu (nh- khả yêu cầu, quan hệ liệu v.v )

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

- Các chuẩn quân sự, chuẩn quyền hay 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 bc vỊ thêi gian - Ngôn ngữ lập trình

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

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

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

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

Phần có dự phịng kết tổ chức đ-a RFP không bị bắt buộc lựa chọn đề nghị chi phí thấp hay đề nghị khác

4 Yªu cÇu chi phÝ

Mọi vấn đề tài đ-ợc nêu phần Điều bao gồm cấu giá yêu cầu đề nghị nh- thông tin đặc tr-ng đ-ợc nêu đề nghị (nh- giải trình chi phí tổng cộng hay lập giá riêng cho pha) Phần nêu rõ loại hợp đồng phát triển đ-ợ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 bao gồm danh sách mäi t- liƯu nªu RFP nh- tiªu chn, t- liệu hệ thống có, tài liệu 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 tuyến bố công việc (Sow) Chủ yếu danh sách thứ giao đ-ợc dự án nh- t-liệu, phần mềm, đào tạo phần cứng hay thiết bị thích đáng Phần thảo luận việc bảo đảm theo yêu cầu cho hệ thống đ-ợ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 Điều bao gm ni dung yờu cu v:

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

Thí dụ phác họa đề nghị có nêu phần 3.4

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

8 Đệ trình lịch trình lịch định

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

Một mục tiêu RFP làm cho nhiệm vụ so sánh đề nghị đ-ợc dễ dàng Nhiệm vụ trở nên cực kỹ khó đề nghị đ-ợc cấu tạo khác hay đề nghị đ-ợc dựa giả định khác Phần phác thảo nói đến họp với ng-ời đề nghị Cuộc họp tạo hội đảm bảo ng-ời đề nghị có sở chung hiểu biết kết đề nghị họ dễ so sánh Nó thành đạt yêu cầu khuôn dạng đề nghị tiêu chuẩn hóa, nêu phần RFP Bảng 3.1 có nêu phác thảo đại khái RFP

B¶ng 3.1 Phác thảo khái quát cho RFP

1 Tuyên bố vấn đề mục tiêu dự án - Mụ t hin trng

- T- liệu hỗ trợ

c¸c b¸o c¸o

các biểu đồ

các thí dụ - Mơ tả vấn đề

- C¸c mục tiêu Yêu cầu kỹ thuật

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

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

- Tiêu chuẩn quân hay chÝnh qun - Rµng bc thêi gian

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

- Ai đáp ứng cho RFP

- Ngày tháng địa điểm họp theo lịch với ng-ời đề nghị ng-ời đ-ợc chọn- Làm 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 Yêu cầu chi phí

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

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

- Loại hợp đồng phát triển đ-a cho

- So sánh chi phí giải pháp thay T- liệu tham khảo

- Các tiêu chuẩn

- T- liệu 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 chuyển giao - T- liƯu vỊ s¶n phÈm chun giao - Hn lun

- Các công cụ phát triển thử nghiệm 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 tổ chức đề nghị + ủy nhiệm th- kỹ thuật ng-ời đề nghị + Tóm tắt nhõn s ch lc

- Đề nghị lập giá

8 Lịch đệ trình lịch định - Hạn cuối 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 phần phát RFP - Theo danh mục phân phát hạn chế

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

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

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

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

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

3.4 đề xuất

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

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

Kin ngh yêu cầu đáp ứng RFP thức lời mời đặc biệt để trình kiến nghị kiến nghị không yêu cầu thông th-ờng ng-ời đề nghị x-ớng xuất Tất nhiên có nhiều tổ hợp hai biểu ví nh- tình kỳ dị nh-ng th-ờng thấy kiến nghị không yêu cầu làm nảy sinh việc đề xuất RFP thức

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

Nhng kin nghị khơng u cầu thức nhiều so với kiến nghị yêu cầu th-ờng không là b-ớc đầu dẫn đến th-ơng thảo thức Kiến nghị khơng u cầu phải có phần sau:

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

4 Mô tả tổ chức ng-ời kiÕn nghÞ

5 Tổng quan chung kinh phí giải pháp đề nghị

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

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

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

3.4.2 Đề xuất có yêu cầu

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

Một lĩnh vực khiến kiến nghị yêu cầu không yêu cầu khác nhu cầu cạnh tranh Các kiến nghị yêu cầu phải có khả cạnh tranh thắng lợi với kiến nghị khác Điều có nghĩa việc chuẩn bị kiến nghị yêu cầu phải đ-ợc coi thân dự án mini nh- địi hỏi hình thành độ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ị cho tổ chức dự tính đáp ứng thành cơng RFP Ban định ng-ời có nhiệm vụ định vị RFP thích hợp độ trình để thảo luận đ-ờng lỗi đạo ban đề Đ-ờng lối đạo phải nhằm vào RFP mà:

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

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

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

Căn đánh giá ban RFP đek trình, ban kiến nghị định RFP đáp ứng đ-ợc công ty

mäi nhân viên công ty cần sử dụng dịch vụ chuyên gia bên hỗ trợ việc chuẩn bị kiến nghị

Kin ngh yêu cầu 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 lĩnh vực riêng rẽ kin ngh l-u ý

- Quản lý dự án kể dự toán lập kế hoạch

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

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

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

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

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

Theo Silver (1986), kiến nghị công nghệ cao 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ị 1% đến 10% Chi phí hợp đồng cao, phần trăm dành cho chuẩn bị kiến nghị thấp.6

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

Kiến nghị tốt phải trả lời đ-ợc câu hỏi bản: ai, sao, nào, nào, Đáp án cho câu hỏi đơn giản liên quan đến:

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

3 Tại kiến nghị đ-ợc đệ trình ?

4 Lµm công việc kiến nghị đ-ợc thực ? Khi đ-ợc phát triển xong bàn giao ? 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

Câu hỏi quan trọng cho kiến nghị không yêu cầu tạo sở cho việc đệ trình Đáp án cho RFP cần khẳng định  Kiến nghị đ-ợ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 hợp phần kiến nghị Kiến nghị kỹ thuật (cái gì, lµm sao)

2 Kiến nghị quản lý (làm sao, nào) Kiến nghị định giá (bao nhiêu) Tun bố cơng việc (cái gì, nào)

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

- Trình độ chun mơn nhân chủ lực - Các chứng vật văn thích hp

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

1 Tổng quan vấn đề cần giải Tổng quan giải pháp kiến ngh Hp phn cn mua

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

- Cơ sở hạ tầng

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

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

- Các sở liệu

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

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

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

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

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

3 Yờu cầu nhân cấu đội ngũ phát triển Ph-ơng pháp luận phát triển

5 C¸c pha ph¸t triĨn XÐt dut

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 Các chủ thầu phụ Các tiêu chuẩn 10 Thử nghiệm:

- Các giai đoạn thử nghiệm - Thủ tục thử nghiệm thức - Phát 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 mục hoạt động chủ yêu - Các cột mốc

- C¸c phơ thc

- Bè trÝ 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 ) Chi phí phát triển hợp đồng phần dự án

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

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

8 Tổng chi phí dự án

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

Tóm tắt điều hành đặc biệt quan trọng cho kiến nghị lớn phức tạp tất thành viên ban tuyển chọn đọc kiến nghị Tóm tắt phải dài khoảng đến trang nên có tham chiếu tới lĩnh vực đặc tr-ng dự án toàn có đầy đủ chi tiết

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

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

Khẳng định công việc sở hợp đồng ng-ời đề nghị khách hàng th-ờng đ-ợc lồng hợp đồng Sow bao gồm danh mục chi tiết công việc mà ng-ời đề nghị phải thực lợi ích khách hàng Sow bắt đầu danh mục chung thứ bàn giao theo yêu cầu RFP Bản chi tiết sow đ-ợc đệ trình coi nh- phận kiến nghị đ-ợc coi mơ tả b-ớc đầu 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 sow đ-ợc kết thúc trình th-ơng thảo hợp đồng hay sau yêu cầu chi tiết dự án hoàn tất

Bảng 3.5 Giới thiệu thí dụ đại thể Sow cho 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 dự án bao gồm việc bàn giao hợp phần phần cứng dự án đòi hỏi huấn luận hay lập t

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

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

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

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

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

- Tính chức (nh- dẫn đặc tả yê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 thiết bị phần cứng - Tính chức (nh- dẫn đặ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

7 Giám sát chủ thầu phụ 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 Thư nghiƯm

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

- Thử nghiệm nghiệm thu (ATP) 10 Ll t

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

12 Các dịch vụ khác 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 cho việc chuẩn bị Sow hoạt động nào, dịch vụ hay sản phẩm mà khách hàng yêu cầu đ-ợc ng-ời sản xuất thỏa thuận phải có Sow Điều có nghĩa có hạng mục cơng việc khơng bắt buộc đ-ợc hiểu cách khơng thức hay thỏa thuận miệng mà khơng có Sow Sow thức phải bao gồm tồn cơng việc phải hồn thiện cơng việc thơi Điều kiện phòng ngừa hiểu lầm bất đồng sau sau dự án bắt đầu

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

Sau kiến nghị đ-ợc đệ trình, 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 trở thành kỹ thuật túy Có q trình tuyển chọn kiến nghị hoàn toàn khách quan Các ban tuyển chọn bao gồm ng-ời, tất họ có sở thích riêng khuynh h-ớng riêng

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

Ban tuyển chọn kiến nghị nhóm ng-ời đ-ợc định duyệt xét đánh giá dự án khuyên dùng kiến nghị theo tiêu chí xác định tr-ớc Điều h-ớng dẫn chung hay yếu tố thủ tục đánh giá 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 quản lý kỹ thuật đánh giá chi phí Mỗi hợp phần kiến nghị đ-ợc phân cấp theo thủ tục đánh giá đặc biệt phối hợp cấp cá biệt tạo nên cấp cuối cho kiến nghị

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

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

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

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

Cấp Loại Mô tả

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

7-8 Tốt Trình độ chuyên 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 độ chun mơn hay kiến thức thấp

0-2 Bác bỏ Thiếu khả hoàn thiện công việc; liệu đánh giá hay khơng có

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

Hầu hết ph-ơng pháp đánh gía kiến nghị dựa số biến thể kỹ thuật gắn trọng số, số yếu tố tính điểm đ-ợc gán trọng số phối hợp với để tạo nên cấp bậc tổng thể cho kiến nghị Silver (1986) gợi ý kỹ thuật xếp loại cho yếu tố t-ơng tự nh- bảng 3.6 Chú ý việc mô tả loại thấp có tính đến hội 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 hợp phần chủ yếu kiến nghị trọng số trung đ-ợc tính Lấy thí dụ, bốn hợp phần chủ yếu kiến nghị đ-ợ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 trí thức công ty 10%

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

Bảng 3.7 Các hạng mục đề nghị quản lý - mc ỏnh giỏ

1 Lịch trình 23%

Ngµy tèt 12%

Khả 5%

Cột mốc (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ụ tiện ích phát triển 4%

Trọng số trung b×nh 100%

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

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

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

Việc phát triển phần mềm có tính chất xác định lĩnh vực khác cơng nghệ cao Thơng th-ờng dự tính yếu tố dự án phát triển phần cứng hay điện tử dễ yếu tố dự án phần mềm kinh nghiệm cho thấy tình trạng v-ợt trội dự án phần mềm Bản chất th-ờng xuyên tốn lĩnh vực khác cơng nghệ Điều có nghĩa kiến nghị phần mềm địi hỏi có quan tâm đặc biệt 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 tính kinh phí Những lĩnh vực quan trọng lĩnh vực phát triển công nghệ nh-ng lại quan trọng nhiều phát triển phần mềm

Cả khách hàng ng-ời đề nghị phải có ý thức đặc điểm đặc điểm riêng biệt khác phát triển phần mềm Khách hàng phải giành quan tâm đặc biệt đến lĩnh vực đánh giá kiến nghị nh- ng-ời đề nghị phải quan tâm đặc biệt đến chúng 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ị RFP, song đề thông th-ờng khách hàng phải cung cấp chi tiết đến Quá nhiều chi tiết làm ng-ời đề nghị nản lòng đ-a chào giải pháp họ chi tiết phát sinh giải phá khơng thích hợp thiếu thơng tin Khách hàng thơng th-ờng có đơi chút ý t-ởng vấn đề nên đ-ợc giải Nừu ý t-ởng khách hàng kiên ý th-ởng cần đ-ợc chi tiết hóa RFP Dù sao, ng-ời đề nghị đ-ợc tự đề nghị giải pháp họ giải pháp tốt nhiều giải pháp mà khách hàng nhìn thấy rõ

cho dự án khẩn đơ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 tóm tắt vấn đề hẳn nên l-u tâm đến tr-ớc đ-a RFP

1 Mức độ chi tiết

Những vấn đề đặc biệt thông th-ờng đòi hỏi giải pháp đặc hiệu Nếu vấn đề hẹp đ-ợc xác định rõ hay khách hàng có giải pháp đặc hiệu óc phải cung cấp chi tiết đáng kể RFP

2 Đánh giá kiến nghị

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

3 Thay đổi yêu cầu

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

4 TiÕt kiƯm thêi gian

Quá trình đề xuất RFP, đánh giá kiến nghị hồn thành th-ơng thảo Trong số tr-ờng hợp, dự án 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 cách tiết kiệm thời gian khách hàng cho phép công việc phát triển bắt đầu lựa chọn kiến nghị đ-ợc thắng Điều th-ờng làm gửi th- định ý (LOL) cho ng-ời sản xuất đ-ợc chọn Rủi ro khách hàng LOL giảm giới hạn ng-ời sản xuất ngân sách đặc biệt hợp đồng cuối đ-ợc ký

5 Các kiến nghị chung

Mt vấn đề với kiến nghị chung thiều xác định trách nhiệm rõ ràng Các kiến nghị chung phải giao trách nhiệm chung cho bên Các bên tham gia khác kiến nghị, đóng vai trị chủ thầu phụ, 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ắn để viết kiến nghị thắng Những câu hỏi liên quan đến vấn đề kiến trúc kỹ thuật, bao gồm 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ị hồn cảnh đệ trình Sau số h-ớng dẫn chung cho việc chuẩn bị kiến ngh

Vẻ 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ả đ-ợc tuyển chọn kiến nghị, thắng Ng-ời đề nghị quan tâm nhiều đến mỹ học văn bản, đồ họa, nơ buộc, phim đèn chiếu dẫn giải miệng kèm

2 Các yêu cầu tùy chọn

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

Những đặc điểm tùy chọn đ-ợc ý phần bổ sung kiến nghị nên đ-ợc định giá, lp lch trỡnh riờng r

3 Mọi yêu cầu

Một kiến nghị không thiết đáp ứng yêu cầu RFP Dù sao, phải có tham chiếu yêu cầu nhằm chứng minh chúng không bị bỏ qua Những chệch h-ớng với RFP phải đ-ơc biện minh v gii thớch

4 Giải pháp thay

Một kiến nghị có giải pháp đề nghị Dù giải pháp thay phải đ-ợc đệ trình riêng rẽ chúng đ-ợc l-u ý đá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 phần giải pháp đề nghị thứ nhất, chúng tham chiếu phần (thí dụ "tổ chức đội ngũ phát triển cho giải pháp xử lý phân tán nh- với giải phỏp H thng tõm.)

5 Các công cụ chuyªn nghiƯp

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

3.7 Tãm t¾t.

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

Về có hai thể loại hệ hợp đồng khách hàng nhà phát triển

Hầu hết quan hệ khác hình thức phối hợp hai quan hệ

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

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

Có nhiều biến thể quan hệ kể 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 việc khách hàng tuyển chọn nhà phát triển phần mềm Điều thông th-ờng đ-ợc thực phát yêu cầu cho kiến nghị (RFP)

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

Sau đệ trình kiến nghị cho khách hàng, kiến nghị đ-ợc ban tuyển chọn duyệt xét Các kiến nghị cho dự án nhỏ nh- lớn phải đ-ợc đánh giá theo thủ tục có hệ thống t-ơng đối khách quan Th-ờng hai hay ba lời khuyên đ-ợc đệ trình việc lặp lại lần hai đ-ợc bắt đầu với cơng ty đ-ợc tuyển chọn để tìm kiến nghị thắng 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ó đội 500 xe tải với 30 kho chứa xe tải khắp n-ớc Acme đ-a xe tải tuyến giao nhận Mỗi hành trình bắt đầu kho gần đầu tuyến sẵn có xe kết thúc kho gần cuối tuyến Acme muốn phát triển hệ thông đ-a xe vi tính để tối -u hóa việc sử dụng xe họ

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

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

3 Chuẩn bị kiến nghị đêk trình Acme dự án lịch xe tải bao gồm kiến nghị kỹ thuật, tuyên bố công việc tóm tắt điều hành phác thảo cho phần chủ yếu khác (kể bổ sung)

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

5 Bài tập lớp: lựa chọn RFP chuẩn bị tập 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 định ban tuyển xét kiến nghị để duyệt xét kiến nghị tuyển chọn kiến nghị thắng

Ch-¬ng bèn

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

Cỏc bin thái chủ đề thác n-ớc

Phát triển phần mềm nh- hầu hết hoạt động khác có khởi đầu, trung đoạn kết thúc Kết thúc hoạt động phát triển đơi đ-ợc nhìn nhận đ-ợc tiếp nối với khởi đầu hoạt động phát triển tạo 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 cách nhìn phát triển phần mềm đ-ợc coi chu kỳ đời (vịng đời) phát triển phần mềm

Có nhiều biến thức chu kỳ đời phát triển phần mềm Hình 4.1 cho thấy vịng đời đơn giản thông th-ờng vài thập kỷ đầu phát triển phần mềm Vào ngày đầu phát triển phần mềm, nhà lập trình hẳn sáng tạo ch-ơng trình cách lặp lại từ mã đến phạm trù trở lại mã lại phạm trù đến có chút chấp nhận đ-ợc (mong nh- vậy) sản sinh khởi đầu chu trình th-ờng khơng có quan niệm rõ ràng đ-ợc yêu cầu qui trình phát triển hình thức tiếp cận '' để xem làm đ-ợc gì''

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

Hình 4.1

Ph-ơng pháp Code Fix.

Những 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 thiết kế) thử nghiệm Những hệ thống xử lý liệu th-ơng mại, trừ số ngoại lệ, phải tiêu phí khối l-ợng đáng kể thời gian phát triển pha lập trình thử nghiệm đơn vị Các hệ thống thời gian thực th-ờng phức tạp nhiều bao gồm tích hợp bao qt phần cứng/phần mềm Điều thơng th-ờng địi hỏi qui hoạch nhiều tích hợp thử nghiệm nhiều hn

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

Qui hoạch mà thử

nghim n vị thể thửnghiệm Xử lý liệu

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

40% 20% 40%

Hình 4.2

Mơ hình pha 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

Các hệ thống quân đòi hỏi độ tin cậy cao 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 liệu bảng 4.1 biểu thị khái quát hoá; hệ thống xử lý liệu th-ơng mại phức tạp nh- hệ thống thời gian thực ( coi phần 4.4 thảo luận thêm chuyên mục này)

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

Một số lý giải mơ hình thác n-ớc nh- lý giải sau đây, phối hợp pha thiết kế mức đỉnh thiết kế chi tiết thành pha thiết kế pha tích hợp thử nghiệm vào pha Trên thực tế có nhiều biến thể mơ hình thác n-ớc cổ điển nh-ng tất dựa chuyển tiếp có hệ thống từ pha phát triển sang pha sau cho tận n 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 vịng đời phát triển phần mềm

Mơ hình xoắn ốc đ-ợc Boehm mô tả (1988) ph-ơng pháp phát triển khác lặp lại pha yêu cầu thiết kế thực Dù sao, mơ hình xoắn ốc tiếp tục lặp lại đến hệ thống cuối hồn thành Trong 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 ph-ơng pháp chia pha

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

4.1 Pha quan niƯm

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

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

- Xác định yêu cầu phn mm (pha)

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

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

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

nhận thiếu thoả thuận chung pha yêu cầu tạo chu kỳ sống phầnf mềm cho 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 kiểm thử, vận hành bảo trì giai đoạn lý thú gọi 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

liƯu quan niƯm cịng nguồn tham chiến cho việc tạo lập yêu cầu phần mềm pha sau dự án

Pha quan niêm pha phát triển thức uỷ thác Nó th-ờng đ-ợc tiến hành không thức tr-ớc có cam kết cho phát triển sau dự án

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

Bầu khơng khí pha quan niệm biến đổi sở tăng lên, giảm xuống thiếu dự Theo pha đầu dự án th-ờng đ-ợc đặc tr-ng :

- Ao -ớc đội ngũ kỹ thuật muốn nắm đ-ợc vận động dự án - Thiếu cam kết đầy đủ phía quản lý : Chỉ có ngân sách ban đầu th-ờng đ-ợc phân vào giai đoạn

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

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

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

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

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

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

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

- Cung cÊp nh÷ng dự toán ban đầu đầy thuyết phục cho phát triển dự án Không có tổ chức có thĨ cam kÕt cho mét phÝ tỉn kh«ng

9

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

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

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

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

Những vấn đề sau thông th-ờng 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-ời vào đội ngũ dự án 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 việc dễ dàng

- Vấn đề thông th-ờng thiếu thừa lãnh đạo dự án Trong nhiều tr-ờng hợp , pha quan niệm nhiều ng-ời đạo, ng-ời chịu trách nhiệm phân tích thị tr-ờng, ng-ời dự toán lại ng-ời khác soạn thảo t- liệu quan niệm Điều gây tình trạng thiếu phối hợp ng-ời có trách nhiệm hoạt động khác nhau, tạo nên nhiều mâu thuẫn định ban đầu tồi

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

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

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

Giai đoạn yêu cầu phần mềm, gọi pha xác định, giai đoạn thức uỷ thác phát triển phần mềm Giai đoạn cung cấp mô tả chi tiết hệ thống phần mềm đ-ợc phát triển Điều đặc tả yêu cầu 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 Đặc tả yêu cầu trả lời “cái gì” tìm cách tránh câu hỏi “thế nào”

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

- Đ-ờng lối chủ yếu 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

11

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

Pha yêu cầu soạn thảo t- liệu sản phẩm : - T- liệu đặc tả yêu cầu phần mềm

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 u cầu thức kết thúc với việc duyệt xét chủ yếu cho dự án : Duyệt xét yêu cầu phần mềm (SRR) việc duyệt xét kết thúc việc đặc tả yêu cầu thức tuyên bố t- liệu yêu cầu nh- đ-ờng lối dự án đầu tiờn -c phờ duyt

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

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

miễn c-ỡng kết thúc yêu cầu nhận biết làm điều này, thay đổi sau 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 tốt tiến triển chậm chừng sản phẩm cịn ch-a hồn tồn đ-ợc xác định điều tốn Nên bầu khơng khí pha yêu cầu đ-ợc đặc tr-ng nh- hình thức trị kéo co khách hàng ng-ời phát triển

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

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

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

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

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

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

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

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

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

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

- Chấp thuận yêu cầu ký: pha hoàn tất t- liệu yêu cầu đ-ợc phª dut chÝnh thøc

- Tính khả thi u cầu : đơi điều khó xác định tr-ớc giai đoạn thực

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

- Cung cấp thiết bị : Những vấn đề ngân sách sẵn sàng sử dụng đ-ợc làm đứt đoạn kế hoch b trớ thit b

- Những dự án b¾t buéc

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

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

Tính khả thi yêu cầu phải đ-ợc xác định tr-ớc hồn tất yêu cầu Bao tốn phát yêu cầu bất khả thi trình pha sau dự án

Tính khả thi yêu cầu trở nên tốt nhờ - Sử dụng nguyên mẫu để thử nghiệm yờu cu

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

- To yêu cầu mơ hồ tuỳ theo số kết (thí dụ nhớ đủ, hay khả xử lí CPU có sẵn) Bất kỳ chỗ đ-ợc 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 yêu cầu Những vấ đề liên quan với việc bố trí tài nguyên ng-ời kỹ thuật làm dự án trì trệ Tìm đ-ợc thành viên tốt cho đội ngũ bào vấn đề cho ng-ời quản lý dự án Dù sao, họ đ-ợc bố trí uỷ thác, thiết bị phát triển thoả đáng phải sẵn sàng.Do vấn đề liên kết với việc cung cấp thiết bị trở nên nghiêm trọng đội ngũ phát triển lớn lên

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

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

- Sử dụng phần mềm mô thay 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

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

4.3 pha thiÕt kÕ.

Trong pha thiết kế, yêu cầu đ-ợc phân tích ph-ơng pháp thực đ-ợc xác định Pha yêu cầu tr-ớc đặ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 đ-ợc có 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 thiết kế chi tiết Đ-ờng phân chia hai pha đ-ợc đặt có khơng thiết mức độ phân hệ thống thành thành phần (coi ch-ơng 6) hình 6.5 cho thí dụ phân chia thiết kế hệ thống thành thiết kế mức điểm thiết kế chi tiết

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

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

sẽ tối thiểu nh- có may tốt thay đổi cấu hình máy tính tr-ớc giao hàng

Pha thiết kế tạo sở cho :

- §-êng mèc, hƯ thèng chđ u thø hai cđa hƯ thống - Thực 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 văn sau :

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

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

- Đặc tả tr-ờng hợp thử nghiệm, mô tả chi tiết thử nghiệm mức thấp cho cá thÓ

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

Vào cuối pha này, nhiều ch-a biết dự án lại trở nên biết, tạo nên cải tiến đáng kể dự tốn kế hoạch phát triển thơng số phát triển dự án khác nh- tài nguyên lịch tích hợp tr-ờng hợp thử nghiệm thực cho pha thử nghiệm, đ-ợc lập kế hoạch đ-ợc kế hoạch phát triển dự án đ-ợc cập nhật coi giai đoạn kế hoạch đáng tin cậy nhiều

Theo thế, song song với thiết kế hệ thống, hoạt động sau tiến trin :

- Nền tảng, tích hợp phát triển đ-ợc thiết lập bao gồm thiết bị yêu cầu cho phát triển tích hợp hệ thống

- Dự toán đ-ợc cải tiến đáng kể

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

Mi thụng tin trờn đ-ợc đ-a vào việc sửa đổi chủ yếu 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 thông th-ờng xảy việc duyệt xét thiết kế chinh thức, đ-ợc gọi duyệt xét thiết kế có phê phán (CDR) Nếu đặc tả thiết kế mức đỉnh trung gian đ-ợc chuẩn bị, t- liệu đ-ợc dừng việc duyệt xét thiết kế sơ (PDR) ban đầu

4.3.1 Bầu không khí pha thiết kế.

Pha thit kế th-ờng phần t-ơng đối lạc quan tin t-ởng dự án phát triển Giai đoạn đặc tr-ng :

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

- ý kiÕn chËm

- tÝnh bÊt khả thi yêu cầu

- Thông tin bỉ sung

- Sù bèi rèi : §éi ngị phát triển nhanh, tôn ti dự án trách nhiệm cßn ch-a râ

Pha thiết kế, ng-ời quản lý dự án, thời kỳ, tổ chức thời gian cấu đội ngũ dự án đ-ợc hoàn tất việc phân trách nhiệm xong Những nhiệm vụ phải đ-ợc ng-ời quản lý dự án hoàn thanmhf tr-ớc kết thúc giai đoạn thiết kế lẫn lộn có hai pha đầu dự án đ-ợc chuyển sang giai đoạn thực

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

Những vấn đề giai đoạn thiết kế liên quan đến : - Những tranh cãi v thit k k thut

- Khó khăn nhân

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

Nhng thiết kế kỹ thuật liên quan đến yêu cầu bất khả thi nh- gid định thiết kế thực phức tạp Chính pha thiết kế tất vấn đề phải đ-ợc giải việc giải quyêtd chúng trở nên tốn dự án tiến triển

Đôi khi, vấn đề nhân đ-ợc chuyển từ giai đoạn yêu cầu tr-ớc Việc tuyển ng-ời cho số nhiệm vụ khó hay chậm quan trọng cho ng-ời quản lý dự án phải tìm cách bố trí nhân viên vào vị trí dự án cáng sớm tốt chí tr-ớc ng-ời đ-ợc yêu cầu Trên thực tế, thói quen tốt việc bắt đâu bố trí nhân viên vào vị trí tr-ớc ngày mà nhân viên thực 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 dự án vấn đề thwng đ-ợc phối hợp với ng-ời bán hàng bên ng-ời cung cấp thiết bị cơng ty có mà cịn ràng buộc với dự án khác Nh- nêu tr-ớc đây, nhiều vấn đề th-ờng đ-ợc giải cho vay hay thuê thiết bị Dù tác động không lợi giải pháp tạm thời nh- lại tăng lên dự án chuyển sang giai đoạn phát triển tiên tiến Trên thực tế, giải pháp đó, khơng đ-ợc xử lý thận trọng, dẫn đến vấn đề :

- Thuê tốn hao phí số tiền đáng kể ngân sách phát triển

- Những giải pháp thay tạm thời dẫn đến chất l-ợng sút giảm thời gian phát triển kéo dài Rút cục điều 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 cịn xảy pha thiết kế Với yêu cầu đ-ợc chấp thuận Phần lớn căng thẳng giảm nh-ng pha thiết kế kết thúc với việc tổng duyệt thức, khách hàng chia xẻ trách nhiệm thiết kế đó.Điều tăng thêm dính líu khách hàng pha thiết kế dẫn đến bất đồng hệ thống phải đ-ợc thực

Những loại vấn đề đ-ợc giải tốt cách định thành viên đội ngũ (có thể 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 giảm điểm tiếp xúc đội ngũ khách hàng đảm bảo khách hàng có địa cho yêu cầu nhận xét

4.4 Pha thùc hiÖn.

Trong pha thực hiện, mơ đun phần mềm đ-ợc mã hố 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 mơ đun cá thể sau mơ đun đ-ợc mã hố Sau mơ đun đ-ợc phận kiểm tra chất l-ợng phần mềm phê chuẩn đ-ợc đệ trình phận kiểm tra cấu hình (coi ch-ơng thảo luận chức kiểm tra đó) Sau phận kiểm tra cấu hình chuyển mô đun để hợp

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

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

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

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

Tình trạng gối đầu pha thiết kế thực đòi hỏi phải thận trong việc đảm bảo mô đun thiết kế hoàn chỉnh đ-ợc phê chuẩn để thực sớm Có rủi ro thay đổi chậm sau thiết kế mơ đun đòi hỏi phải lập mã lại Theo lãng phí tài ngun Cũng có rủi ro thiết kế thay đổi mã không thay đổi Dù rủi ro th-ờng nắm bắt đ-ợc tốt Với qui hoạch khống chế kiểm tra cấu hình tốt vấn đề đ-ợc khắc phục

T Hình 4.5

Sự gối đầu pha

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

Pha thực bao gồm hoạt động sau : - Phát triển mã phần mềm

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

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

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

- KÕ ho¹ch bảo trì thu thập t- liệu, kể 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

- Các ban đầu t- liƯu cho ng-êi dïng, kĨ c¶ sỉ tay tham kh¶o 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 bao gồm :

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

Nền thử nghiệm (môi tr-ờng 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 củi ro đ-ọc trở thành thực kế hoạch dự phòng bất trắc đ-ợc đ-a vào hot ng

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

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

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

- áp lực đ-ợc tiếp tục đ-a điều th-ờng kết viẹc gia tăng đáng kể mức độ tăng chi phí nh-ng cịn đ-ợc chi phí phát triển

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

- Hoath động đội ngũ phát triển gia tăng cịn gió cịn lại ngày giao sản phẩm tới gàn trở nên thục tiễn

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

- u cầu 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ịn ch-a đ-ợc giải - Hỗ trợ quản lý có th thiu

- Quan hệ khách hàng căng

4.4.2 Nhng pha thc hiện

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

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

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

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

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

- Giao tiếp phối hợp thành viên đội ngũ, vấn đề đặc biệt nghiêm trọng dự ỏn ln

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

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

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

Truyền thơng thức đ-ợc xá định đội nhỏ

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

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

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

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

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

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

- Xác định xem hệ thống có đ-ợc xây dựng theo đặc tả yêu cầu hay không

-Tạo chất l-ợng hệ thống

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

Cã nhiÒu kỹ thuật ph-ơng pháp tích hợp - Từ xuống

- Từ d-ới lên

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

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

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

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

Tích hợp từ (indide out integration) thông th-ờng phát triển hệ sở liệu lớn cấu trúc file nội đ-ợc xây dựng tr-ớc sau logic xử lý liệu cuối giao diện với ng-ời tiếp cận tốt hệ thống mặt logic tấng chức nh-ng điểm yếu giao diện với ng-ời lại th-ờng đ-ợc tích hợp cuối Điều địi hỏi viết mã thử nghiệm tạm thời để đầu đ-ợc duyệt xét lại Do thử nghiệm th-ờng chậm khó so với tiếp cận từ ra.Việc thử nghiệm bắt đầu việc tích hợp tiếp tục tới cuối 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 máy tích hợp hệ thống

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

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

- Thư nghiƯm alpha bêta

cỏc th nghim nytin hnh hệ thống môi tr-ờng thực (không phải thử nghiệm phịng thí nghiệm test) Thử nghiệm alpha thử nghiệm hệ thống khơng có liệ sống Thử nghiệm beta thử nghiệm hệ thống có sử dụng liệu sóng có giám sát th-ờng xuyên để chỉnh lý vấn đề phát sinh

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

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

- T- liệu bảo trì

- T- liệu 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 báo cáo thư nghiƯm

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

- Lập ngân sách cuối dự án, phí tổn cho thay đổi (phát minh) đ-ợc xác định hoạt dộng dự phòng rủi ro đ-ợc đánh giá 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ì sỹ s- tiếp thị

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

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

4.5.1 Bầu không khí pha tích hợp thư nghiƯm

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

- áp lực có đ-ợc làm việc Điều bắt đầu pha thực tr-ớc gia tăng Quản lý nhìn thấy chút thực chất để biện minh cho đầu t- họ Mọi chậm trễ lịch trình điểm nghiêm trọng quan trọng ng-ời quản lý dự án,là phải tạo đ-ợc phiên ban đầu hệ thống sớm tốt

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

- Tranh chấp với khách hàng Cuối khách hàng nhìn thấy phiên ban đầu mà sản phẩm có dáng vẻ Về điều này, có lý giải yêu cầu khác nảy sinh th-ờng cần đ-ợc giải cấp quản lý cao

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

Pha tích hợp thiết kế khó lập kế hoạch Đó lại quan trọng lập kế hoạch có qủ tránh đ-ợc tốt đảm bảo

- Thiết kế tốt

- Kế hoạch lập mà môđun hiệu - Độ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 thử nghiệm tích hợp

4.5.2 Những vấn đề pha tích hợp thử nghiệm

Chính pha tích hợp thử nghiệm hều hết vấn đề phát triển xuất Những cố mô tả tr-ớc dự án nh- rủi ro thành thực 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ấn đề thực nảy sinh Đó loại vấn đề khó khám phá khơng có phiên vận hành hệ thống Dp chúng không đ-ợc phát sớm dự án

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

- Thay đổi phút chót Vấn đề tồn pha nh-ng trở nên nghiêm trọng dự án cáng tiến triển Giờ thay đổi trở nên tốn

- V-ợt ngân sách (thậm chí, bội chi) vấn đề thay đổi sai lầm thiết kế nhu sai lầm qui hoạch dự án

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

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

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

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

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

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

Hệ thống xử lý liệu th-ơng mại nhỏ 10% Hệ thống xử lý liệu th-ơng mại loại vừa 15% Hệ thống xử lý 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, 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 dự án phần mềm

4.6 Pha bảo trì

Pha bo trỡ hon tất chu kỳ phát triển phần mềm 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 Từ bảo trì phần mềm gây tranh cãi bao hàm nhu cầu sửa chữa bị h- Trong hệ thống học hay điện tử, việc bảo trì địi hỏi sửa chữa hay thay thành phần bị h- hại việc bảo trì dự phịng địi hỏi việc dịch vụ với thành phần phòng ngừa h- hỏng Dù phần mềm không h- Bộ máy mang phần

15

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

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

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

Hai hoạt động khác phần bảo d-ỡng - 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ó hoạt động lại làm cho phần mềm trở lại trạng tháo ban đầu

Điều trái lại hoàn toàn : mục tiêu sửa đổi phần mềm sửa đổi phần mềm bao gồm đặc điểm 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 thử nghiệm thức, tất nhiên,những sửa đổi cần đ-ợc tái trợ Do thực hành cơng trình vững để thực giai đoạn bảo trì coi nh- loạt dự án phần mềm nhỏ

Kiểm tra cấu hình đặc biệt quan trọng thời gian bảo trì để quản lý thay đổi với phần mềm kiểm tra đợt phát hành phiên hệ thống Điều đảm bảo đợt phát hành định kỳ có trật tự phần mềm tránh đ-ợc hỗ trợ phiêu l-u cố định chỗ trở thành ác mộng cơng trình

Quản lý dự án đ-ợ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ỏ đội nhỏ nhiều quản lý kiểu khác Trên thực tế, nhóm bảo trì đ-ợ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 tr-ờng bảo trì t- liệu

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

- Các báo cáo vấn đề - Mọi t- liệu phát triển - Mọi t- liệu ng-ời dùng

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

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

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

16Theo nghĩa đó, phần mềm đ-ợc coi thay đổi sai sót rệp hay

Trong nhiều tr-ờng hợp, bảo trì khơng tạo thách đố phát triển điều dẫn đến đội ngũ bảo trì khơng ổn định với số kỹ s-th-ờng xun nhập rời bỏ đội ngũ Dù bảo trì tạo nhiều thách đố chẳng hạn nhận biết vấn đề gay cấn, tạo giải pháp gợi ý cải tiến Nói chung, giai đoạn bảo trì đặc tr-ng

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

- áp lực tạo đị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 nhanh đ-ợc

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

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

Nh- thấy, bảo trì phần mềm bao gồm pha tồn dự án phát triển Do nhiều vấn đề phát triển th-ờng thấy pha phát triển lại thông th-ờng pha bảo trì

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

-Không đủ kỹ s- bảo trì có đủ kiến thức khó khăn 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 phát hành hệ thống

- Chắp vá chằng đụp hệ thống có Sau thời gian, thủ tục bảo trì có trật tự tạo hệ thống phần mềm chắp vá Điều nàyth-ờng nhắc nhở phát triển hệ thống

- Thiếu thiết bị hỗ trợ thử nghiệm Vấn đề lại th-ờng kết ngân sách không đủ cho 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 vấn đề tạo lập bổ nhiêm lý thú thách thức Điều th-ờng thực cách giao trách nhiệm dự án đơn giản hay phận xác định rõ dự án lớn cho kỹ s- phần mềm việc uỷ nhiệm bao gồm việc minh định vấn đề, cung cấp giải pháp gợi ý cải tiến phạm vi trách nhiệm kỹ s-

Cách tiếp cận thúc đảy tận tuỵ kỹ s- với nhiệm vụ đồng anh (hay chị) với thành công cố giắng bảo trì Khơng giống nh- động nhân lực đội ngũ, vấn đề ngân sách 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 th-ờng đ-ợc tài trợ ng-ời dùng hệ thống cần đ-ợc bảo trì Lệ phí hàng tháng hay hàng năm cách thông th-ờng cho việc tạo ngân sách để bảo trì

Nh- thấy, bảo trì mà khơng khống chế cấu hình trở nên 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 pha phát triển

Từ quan niệm ban đầu tới bàn giao cuối hệ thống Có nhiều cách tiếp cận khác tới chu kỳ phát triển phần mềm kể ph-ơng pháp mã cố định, ph-ơng pháp lặp (nh- tạo nguyen mẫu nhanh) 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 triển thành

- Pha quan niệm - pha yêu cầu - Pha thiÕt kÕ - Pha thùc hiÖn

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

Tiếp cận theo pha (cũng gọi mơ hình thác n-ớc) đ-ợc bao gồm hầu hết 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ể mơ hình thác n-ớc cổ điển, nh-ng tất độ có hệ thống tự pha phát triển sang pha sau dự án hoàn thành

Mơ hình thác n-ớc bắt đầu pha quan niệm ban đầu, q trình nhu cầu hệ thống phần mềm đ-ợc xác định quan niệm hệ thống phần mềm tiến triển Tiếp theo pha u cầu 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 dự án Sau xác định yêu cầu pha thiết kế phân tích yêu cầu 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 thiết kế chi tiết Đ-ờng phân chia hai pha đ-ợc đặt đôi phần tuỳ ý, mức phân giải hệ thống Thiết kế hệ thống quy định đ-ờng mốc chủ yếu thứ hai dự án pha sau (pha thực hiện) mơ đun phần mềm đ-ợc mã hố thử nghiệm đơn vị ban đầu đ-ợc tiến hành Sau đó, mơ đun đ-ợc kiểm tra chất l-ợng phần mềm chấp thuận đ-ợ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 mơ đun để tích hợp

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

Bµi tËp

1 Một hãng sản xuất máy bay lớn định cho kỹ s- làm việc nhà Các kỹ s- đ-ợc cung cấp máy đầu cuối mô đun họ liên lạc tự nhà với máy vi tính cơng ty Hãng sản xuất máy bay cần ch-ơng trình phần mềm truyền thông giám sát để quản lý công việc 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ông ty làm khởi động hệ thống báo động có có truy nhập không đ-ợc phép nh- Hệ thống phải giám sát giấc kỹ s- làm việc nhà phải cung cấp nguồn lực chia xẻ hồ sơ liệu chung tiện ích phần mềm Cuối ch-ơng trình phải có chứa trực tuyến mode theo báo cáo đặc điểm để cung cấp thông tin việc dùng hệ thống kỹ s- từ nhà họ

Hãy phân tích ch-ơng trình phần mềm khảo sát ph-ơng pháp thực khác nha Đặc biệt, 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 bất lợi cách tiếp cận dự án

2 Xem xÐt sù chång chÐo c¸c pha vận dụng ph-ơng pháp thác n-ớc với hệ thống mô tả tập Đặ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à mô đun cho pha thực bắt đầu sớm tốt Giải thích mô đun đ-ợc tích hợp an toàn tr-ớc bình luận rđi ro cã thĨ cã

3 Nh- ë bµi tËp h·y xem xÐt rñi ro chång chÐo pha thực với pha hợp

Chuẩn bị kế hoạch tích hợp mô đun phần mềm cho tích hợp bắt đầu sớm tốt HÃy giải thích mô đun đ-ợc tích hợp an toàn tr-ớc 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ừ xuống với kế hoạch từ d-ới lên kế hoạch từ Mô tả tiếp cận bạn khuyên nên dùng cho dự án

4 Hóy tho luận vấn đề mà bạn đợi chờ việc phát triển hệ thống mô tả tập Đặc biệt xem xét vấn đề liên kết với việc xác định yêu cầu Ai khách hàng ?

Cũng xem xét vấn đề tích hợp thử nghiệm dự án thảo luận thay đổi yêu cầu xảy Các vấn đề đ-ợc sử lý tốt ?

5 Hãy xem xét đặc điểm bổ sung cải tiến cho hệ thống mô tả tập Chuẩn bị kế hoạch bảo trì dài hạn bao gồm việc phát hành hệ thống có hiệu chỉnh sai sót kỹ thuật số đặc điểm lần đ-a phát hành

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ã khác ?

Theo nhiu nghiờn cu, qun lý kỹ s- phần mềm khó khăn quản lý kỹ s- hầu hết lĩnh vực công nghệ khác Kỹ s- phần mềm điển hình (nếu có ng-ời nh- thế) th-ờng đ-ợc biểu thị vừa tài tử vừa lôgic nh- vừa phục tùng vừa thất th-ờng Những nét thấy nhóm ng-ời nh-ng trội kỹ s- phần mềm

Các kỹ s- phần mềm lại đa dạng mức độ hiệu suất họ Xa x-a, năm 1968, Sackman cộng có t- liệu chênh lệch to lớn hiệu suất nhà lập trình phần mềm Sackman báo cáo tỉ lệ hiệu suất tới 25:1 lập trìnhvà 28:1 gỡ rối (ch-ơng trình).Tất nhà lập trình tham gia vào thí nghiệm quen thuộc với lĩnh vực ứng dụng ch-ơng trình, khiến Sackman lý giải kết coi nh- phạm vi tinh thơng họ

H×nh 5.1

Bèn cét mèc qu¶n lý

Các kết Sackman có đơi chút cực đoan Dù dự án trung bình khơng phải khơng phổ biến có tỉ lệ hiệu suất 1:5 mục tiêu công nghệ phần mềm thời đại giảm phạm vi hiệu suất kinh khủng nhà phát triển phần mềm Điều làm đ-ợc thơng qua việc phát triển có tổ chức có hệ thống vốn khơng đ-ợc hài lịng ng-ời đứng đầu (cha tinh thần) đầu cao phạm trù hiệu suất Những ph-ơng pháp luận phát triển phần mềm giảm tác động nét nhân khác tới trình phát triển Điều đ-ợc thực qua việc vận dụng t- liệu, báo cáo, tiêu chí phát triển họp qui chế rộng rãi, bao quát Dù thủ tục số ph-ơng tiện quản lý ng-ời Con ng-ời đ-ợc quản lý thông qua cấu tổ chức Cơ cấu tôn ti

3 ThÈm qun Authority Tr¸ch nhiƯm Responsibility Gi¸m s¸t Supervision

trên bốn cột mốc quản lý : uỷ quyền, thẩm quyền, trách nhiệm giám sát (coi hình 5.1) Uỷ quyền trao thẩm quyền, thẩm quyền lại tạo (và đòi hỏi) trách nhiệm Cả thẩm quyền trách nhiệm địi hỏi giám sát giám sát có hiệu lại địi hỏi cấu tổ hức thích ứng

Hầu hết dự án đ-ợc tổ chức thành đội ngũ với đội ngũ đ-ợc giao phó chức đặc thù phạm vi dự án Các loại dự án khác đòi hỏi loại cấu đội ngũ khác nh- chẳng hạn đội ngũ nhà lập trình trung cấp địi hỏi lãnh đạo đội ngũ kỹ thuật đội ngũ chuyên gia địi hỏi lãnh đạo đội ngũ hành Đó trách nhiệm ng-ời quản lý dự án việc chọn lựa cấu thích ứng cho dự án

Ch-ơng đề cập đến vấn đề quản lý ng-ời Xuyên suốt ch-ơng nhấn mạnh chủ yếu vấn đề liên quan đến dự án phần mềm Về thảo luận khái quát ph-ơng pháp quản lý động viên ng-ời, bạn đọc vui lòng tham chiếu lý thú 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ó nhiều cách tổ chức dự án phần mềm Dự án lớn cấu tổ chức trở nên gay cấn Những dự án tổ chức tồi gieo rắc lộn xộn 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ấu dự án bên d-ới ng-ời quản lý dự án có chức tổng quát phát triển hỗ trợ

Cơ cấu dự án phần mềm không phổ biến năm 50 60 Đó cịn cấu dự án có giá trị cho dự án nhỏ (có đến năm nhà sản xuất) có ngày thấy dự án lớn

H.5.3 Mô tả biểu đồ tổ chức chi tiết kể chức hỗ trợ chủ yếu Cơ cấu tổ chức thích ứng với dự án lớn (với nhân 20) Những dự án nhỏ khơng địi hỏi phó quản lý dự án hay nhóm kiểm tra cấu hình bảo hiểm chất l-ợng riêng biệt (coi ch-ơng thảo luận chi tiết chuyên đề này) Những dự án lớn (nhõn s

Ng-ời quản lý dự án

Đội ph¸t triĨn dù ¸n

v-ợt qua 40) th-ờng đ-ợc quản lý dễ dàng phân dự án thành dự án phụ Hình 5.4 cho thấy biểu đồ tổ chức dự án lớn Biểu đồ bao gồm đội ngũ phát triển phần cứng phần mềm nhóm hợp phạm vị 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 xét tổ chức dự án vệ tinh lớn Nguời quản lý dự án thực tế chịu trách nhiệm số dự án Trạm kiểm tra mặt đất, thân trạm vệ tinh trạm hoả tiễn Phần mềm cho dự án phụ đ-ợc quản lý phạm vi văn phòng dự án dự án phụ lại 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 áp dụng cho dự án vệ tinh, biểu đồ kết đ-ợ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 Đội phát triển Đội phát triển n

§éi1 §éi2 §éi3 §éi1 §éi §éi §éi 2 Đội3 Chánh quản lý dự án

Phó quản lý dù ¸n

Kü s-hƯ thèng

Nhóm thử nghiệm c lp

Bảo hiểm chất l-ợng Khống chế cấu h×nh Th- ký

H×nh 5.5

Biểu đồ tổ chức dự án vệ tinh

Rõ ràng cấu tổ chức dự án tuỳ thuộc loại dự án đ-ợc phát triển Một số vấn đề phải xem xét :

- Qui mô dự án : dự án lớn, tổ chức quan trọng Những dự án lớn có tổng phí thơng tin phối hợp đáng kể ng-ời địi hỏi nhiều chức hỗ trợ

- 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 phần mềm không dễ dàng việc lập kế hoạch, hợp thử nghiệm lại phức tạp địi hỏi nhóm hỗ trợ tận tuỵ

Các gi/đốc dự án Các gi/đốc chức

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 Khống chế cấu hình Th- ký

Đội phát triển Đội phát triển Đội phát triển n

Đội1 Đội2 Đội3 Đội1 §éi §éi §éi §é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

- Các hệ thống tin cậy cao Bất hệ thống nhạy cảm với vấn đề độ tin (nh- hệ thống quân hay cứu mạng) đòi hỏi cố gắng chủ yếu bảo hiểm chất l-ợng Chất l-ợng nhận định quan trong nhiều sản phẩm phần mềm đ-a thị truờng (thí dụ ch-ơng trình thơng tin) Những loại dự án địi hỏi 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 nhiều vào cấu tổng thể cơng ty dự án đ-ợc phát triển Nhiều chức hỗ trợ dự án đ-ợc nhóm tập trung hố cơng ty cung cấp Trên thực tế, dịch vụ nh- dịch vụ tài văn phịng pháp lý th-ờng tổ chức bà hay tập đoàn cung cấp

Cơ cấu tập đoàn th-ờng định hai loại tổ chức dự án : ma trận hay khối tháp Hình 5.6 mơ tả cấu tổ chức ma trận (so sánh với cấu khối tháp hình 5.4).Trong tổ chức ma trận tập đoàn, ng-ời quản lý dự án quản lý hoạt động kỹ thuật đội ngũ dự án dính líu anh hay chị tong vấn đề nhấn phi kỹ thuật (thí dụ duyệt l-ơng, đề bạt, đào tạo)

Lợi ích tổ chức ma trận :

- Tinh thơng hơn: Một tổ chức ma trận giữ chuyên gia lĩnh vực đặc thù (thông tin, sở liệu, đồ hoạ.v.v) ng-ời đ-ợc uỷ nhiệm vào dự án khác Dự án đơn độc khơng tự cho có đ-ợc điều xa xỉ việc giữ chuyên gia lĩnh vực

- Cơ động : dễ chuyển ng-ời từ dự án đến dự án khác Điều dẫn đến sử dụng đ-ợc tốt tinh thơng có đ-ợc

- Chú trọng quản lý dự án: Ng-ời quản lý dự án đ-ợc rảnh rang nhiều nhiệm vụ quản lý đội ngũ, giành đ-ợc nhiều thời gian tập trung vào khía cạnh kỹ thuật dự án Dù tổ chức ma trận có bất lợi đáng kể

- biện pháp quản lý Một công cụ việc hình thành động cơ, đề bạt tuột khỏi tay ng-ời quản lý dự án Nguời quản lý có ảnh h-ởng đến l-ơng ng-ời sản xuất vai trị chun mơn tổ chức

- Tính trung thành đội ngũ thấp Mọi nhân viên muốn biết xác cấp họ Trong tổ chức ma trận, nhân viên có cấp Điều tạo phân hoá trung thành mối liên kết yếu nhân viên ng-ời quản lý

Những bất lợi th-ờng lấn át lợi điểm tổ chức ma trận tập đoàn Động yếu tố chủ đạo cho thành công dự án điều xói mịn động có th-ờng ng-ợc lại lợi ích tốt dự án Bất hạnh lợi ích tốt dự án lại khơngln ln trùng hợp với lợi ích tốt công ty

những ng-ời d-ới họ Khi đề bạt qui chế đóng vai trị chủ yếu hình thành động : (và họ th-ờng làm thế) tổ chức khối tháp có hiệu Nhiều yếu tố khác hình thành động ý thức hồn thành khen ngợi quí trọng vài (coi phần 5.4 thảo luận thêm chuyên đề này) Mặc dù đề bạt qui chế luôn ;à động hiệu nhất, ng-ời quản lý dự án từ bỏ công cụ tổ chức khối tháp th-ờng tốt

5.2 Cơ cấu đội ngũ.

Trừ với dự án nhỏ (số ng-ời sản xuất 5) dự án phần mềm đ-ợc tổ chức tốt thành đội ngũ phát triển nhỏ Qui mô lý t-ởng đội ngũ phát triển khoảng bốn sáu ng-ời sản xuất Những đội ngũ lớn hạn chế khả lãnh đạo đội đ-ợc hoạt động ng-ời sản xuất tăng tổng phí quản lý hạn chế dính líu kỹ thuật 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 tốt : Cơ cấu đội ngũ hỗ trợ việc uỷ nhiệm thẩm quyền

- Trao đổi thông tin ý kiến hiệu làm quen đ-ợc rộng đội ngũ với nhiệm vụ thành viên

Đội ngũ giảm khả kỹ s- không thay đ-ợc chia xẻ kiến thức phạm vi đội khơng có ng-ời đơn độc trở thành nguồn thông tin gay cấn

Trong dự án nhỏ, có đồng mạnh với dự án dự án lớn ng-ời sản xuất có xu h-ớng cảm thấy họ số nhiều đóng góp họ cho dự án tiến hành khơng hay Nhỏ hơn, gắn bó hơn, đội ngũ hình thành tận tuỵ

5.2.1 Lãnh đạo đội.

Lãnh đạo đội ngũ đ-ợc coi kênh thơng tin ng-ời quản lý dự án với thành viên đội Điều khơng có nghĩa khơng có thơng tin trực tiếp ng-ời quản lý dự án với thành viên đội Dù thơng tin trực tiếp nh- điều hẳn làm cho mục đích cấu đội bị thất bại: uỷ nhiệm thẩm quyền trách nhiệm đ-ợc hiệu (coi hình 5.1)

Vai trò lãnh đạo đội :

- Đạ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

thuật Cả đội ngũ dân chủ đội ngũ kỹ s- tr-ởng đòi hỏi khả lãnh đạo đội hà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 kiu 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

viên Đội

õy l trỏch nhim ng-ời quản lý dự án việc tuyển chọn đội ngũ uỷ nhiệm vai trò lãnh đạo đội Điều (và th-ờng phải) đ-ợc tiến hành qua tham vấn lãnh đạo đội có kinh nghiệm thành viên dự án thâm niên khác Cơ cấu tổ chức uỷ nhiệm nhiệm vụ chủ chốt phần kế hoạch phát triển dự án phải đ-ợc hoàn thành sớm tốt chu kỳ phát triển dự án (bàn chi tiết 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 có sở khả lãnh đạo họ Nếu khả cố hữu tính tình cá nhấn việc đào tạo đỉ Sai lầm chung đề bạt kỹ s- tốt trở thành lanh đạo đội tồi17.

Lãnh đạo đội ngũ, tr-ớc hết hết chức quản lý nh- đòi hỏi đ-ợc đào tạo Mọi lãnh đạo đội phải đ-ợc đào tạo thức kỹ quản lý cần thiết cho việc quản lý đội cho việc đối diện với quản lý dự án Lãnh đạo đội có khả đ-ợ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, đội dân chủ khơng có lãnh đạo, chức vai trò lành đạo đội điều phối viên nhiều đội dân chủ, lãnh đạo đội giành phần nhỏ thời gian họ cho :

- việc đại diện đội thông tin với quản lý dự án đội khác - Phối hợp hoạt động đội

- Sử lý nhiệm vụ hành chínhkhác nh- báo cáo, lập trình giám sát hoạt động

Mọi định kỹ thuật đội dân chủ đ-ợc đội thực lãnh đạo đội triệu tập họp vấn đề gay cấn cấp thiết đ-ợc đ-a thảo luận Nh-ng thành viên đội tham gia trình định chịu trách nhiệm đầu

Các đội dân chủ th-ờng thích ứng cho nhóm nhà sản xuất thâm niên có kinh nghiệm Theo vai trị lãnh đạo đội giảm tổng phí hành cách giao nhiệm vụ hành đội cho thành viên Cơ cấu đội dân chủ đặc biệt khơng thích hợp cho nhóm hỗn hợp, hay nhóm bao gồm chủ yếu ng-ời sản xuất niên Trong hai tr-ờng hợp đó, vai trị lãnh đạo rõ ràng cần thiết

5.2.3 Các đội kỹ s- tr-ởng.

Đọi kỹ s- tr-ởng (cũng gọi đội tr-ờng lập trình) tiến hành lãnh đạo đội phát triển Vai trò lãnh đạo đội vừa điều phối viên (nh-trong tr-ờng hợp đội dân chủ) vừa h-ớng dẫn (nh-trong dự án phức tạp, lãnh đạo đội đ-ợc yêu cầu giành đến 50% thời gian vào hoạt động kỹ thuật hành

Hoạt động lãnh đạo đội kỹ s- tr-ởng là: - Giao nhiệm vụ trách nhiệm cho thành viên đội -Giám định công việc thành viên đội

- Góp ý h-ớng dẫn thành viên đội

- Hoạt động hành phối hợp (t-ơng tự nh- lãnh đạođội dân chủ) Các đội kỹ s- tr-ờng thích ứng cho đội hỗn hợp đội chủ yếu có ng-ời sản xuất than niên hay khơng có kinh nghiệm chức lãnh đạo đội với t- cách ng-ời quản lý hàng đầu phải đ-ợc đàp tạo thích hợp kỹ thuật quản lý Các đội kỹ s- truởng thành cơng đội ng-ời sản xuất đàn anh có kinh nghiệm nh-ng vai trị th-ờng không cần thiết cấu đ-ợc vận dụng cho đội kỹ s- có kinh nghiệm việc ng-ời lãnh đạo đội có kỹ quản lý lại quan trọng gấp hai không ffụng chạm phát triển thành viên đội 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ó 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 đội ngũ nhỏ đ-ơịc thành lập để giải vấn đề đặc thù dự án Một đội ngũ chuyên gia đ-ợc thành lập q trình phát triển dự án có vấn đề phức tạp nảy sinh sau đội đội đ-ợc giải tán vấn đề đ-ợc giảiquyết Trong số tr-ờng hợp, đội chuyên gia hỗ trợ dự án suốt chu kỳ phát triển Mục tiêu đội chuyên gia tập trung giám định lĩnh vực riêng dự án

Lấy thí dụ, ta xé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 ngân hàng 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 hệ phụ cho đội riêng nh-ng qui mô dự án đảm bảo có đội hợp riêng Cả hai đội sử dụng mô thực thử nghiệm hợp hệ thống phụ ban đầu Dù hai hệ thống phụ đ-ợc hợp với nhau, thông tin hai hệ thống khơng có

Trong tình nh- có nguy hai đội tìm kiếm vấn đề công việc đội Nay dù hai đội hợp tác với tốt, khác biệt thực (hay thiết kế) làm cho vấn đề khó đ-ợc giải Và kịch trình bắt đầu tr-ợt điều trở thành mối quan tâm chủ yếu cho ng-ời quản lý dự án

thể giải tán vệ moọt số mặt, đội thử nghiệm độc lập đội bảo hiểm chất l-ợng đ-ợc coi đội chuyên gia ( coi ch-ơng bàn chuyên đề đó) Các đội thử nghiệm độc lập lúc đầu hoạt động giai đoạn hợp thử nghiệm chu kỳ phát triển Đội bảo hiểm chất l-ợng thí dụ đội chuyên gia hoạt động xuyên suốt chu kỳ phát triển dự án

Đội chuyên gia th-ờng có kỹ s- có kinh nghiệm cao tr-ờng hợp điều chắn đội đ-ợc hình tìanh nh-đội dân chủ Trong thí dụ tr-ớc, nh-đội nh-đội dân chủ hay chuyên gia thông tin đàn anh lãnh đạo

5.3 Kỹ thuật báo cáo bản.

Vi ng-i quản lý dự án, điều chủ yếu đ-ợc th-ờng xun thơng báo điều kiện (tình hình) thực dự án điều đ-ợc thực đảm bảo đ-ợc luồng thơn tin xác đặn đội phát triển Nhiều ph-ơng pháp thu thập thông tin khơng khách quan dựa vào tính xác báo cáo 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ỳ 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 chứng minh sản phẩm đặc biệt chủ quan chứng minh mà ng-ời sản xuất mong muốn đ-ợc phơ Ng-ời quản lý dự án cần thông tin khách quan thơng tin nhủ th-ờng đ-ợc thu thập từ báo cáo 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 họp nguồn thông tin có ích, khơng có thay tiếp xúc trực tiếp ng-ời quản lý dự án nhân lực phát triển Nh-ng nói chuyên th-ờng xuyên khơng thức với ng-ời sản xuất nguồn thông tin tuyệt hảo đặc biệt đ-ợc tiến hành bầu khơng khí khơng thức (và khơng phải văn phòng ng-ời quản lý dự án)

Ng-ời quản lý dự án phải trì cảnh giác th-ờng xuyên với sia lầm th-ờng đ-ợc gọi '' hội chứng 90/50 '' khẳng định ''phải 50%thời gian để hồn thành 90% cơng việc 50% thời gian phụ thêm để hồn thành số 10% cơng việc cịn lại'' Điều có nghĩa ng-ời sản xuất dự án bắt đầu khoe khoang sớm họ ''hầu nh- xong'' nhiệm vụ họ, bất hạnh có khác biệt lớn ''hầu nh- xong'' với ''xong''

triển có xu h-ớng (sai lầm) kết hợp cơng việc với kết Do đấy, ng-ời quản lý có đ-ợc nhiều thơng tin ng-ời sản xuất hỏi họ dự tính xong cơng việc khơng hỏi họ hồn thành -c bao nhiờu cụng vic

5.3.1 Báo cáo tình h×nh

Mỗi thành viên đội ngũ phát triển không trừ đ-ợc yêu cầu làm báo cáo tình hình, báo cáo phải đ-ợc đệ trình định kỳ, th-ờng hàng tuần hay hai tuần lần phải có ba phần sau ( coi hình 5.8)

1 Hoạt động 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 thời kỳ báo cao mô tả hoạt động phải kéo dài hai đến ba dòng Hoạt động phải h-ớng danh mục nhiệm vụ dự án hay cấu phân tích cơng việc (wbs) ( coi ch-ơng 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ụ, 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ả hoạt động phải đến hai dòng

3 Vấn đề

Mỗi phần phụ, phần này, mô tả vấn đề chủ yếu xảy thời kỳ báo cáo đ-ợc báo cáo , tr-ớc ch-a đ-ợc giải Điều có nghĩa vấn đề đ-ợc tiếp tục báo cáo đ-ợc giải Nói tiêng, phần phải giải thích phần báo cáo không t-ơng ứng với phần báo cáo tr-ớc

Mọi báo cáo đề phải có : 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) 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 khoảng 20 phút nh-ng không đ-ợc 30 phút Những ng-ời sản xuất phải đệ trình báo cáo trình hình cho lãnh đạo đội mình, sau lánh đạo đội phối hợp báo cáo đội thành báo cáo tình hình giữ cấu báo cáo Hoạt động chiếm khoảng 30 phút ng-ời lãnh đạo đội nh-ng không đ-ợc 45 phút (điều làm đ-ợc dễ dàng báo cáo đ-ợc chuẩn bị đệ trình th- điện tử)

Mỗi lãnh đạo đội đệ trình báo cáo tình hình đội cho ng-ời quản lý dự án.Các báo lẻ tình hình khơng cần đệ trình báo cáo đ-ợc d-a vồ hồ sơ đệ trình cho ng-ời quản lý dự án có yêu cầu

Các báo cáo tình hình dự án khơng cần thiết phải đệ trình độ nh- báo cáo tình hình dự án nội Các báo cáo dự án đ-ợc đệ trình hai tuần hay tháng 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 Ngy 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 thời kỳ báo cáo

1.1 Thiết kế hình giúp ng-ời dùng (hoạt động 3.12.6) đ-ợc hoàn thành lịch Đặc điểm thiết kế đ-ợc đệ trình kiểm tra cấu hình

1.2 Lập mã ngữ huy mô đun (nhóm hoạt động 5.12) tiếp tục th-ờng chậm lịch khoảng tuần

2 Hoạt động dự kiến cho tuần tới

2.1 Lập mã ngữ huy mơ đun (nhóm hoạt động 5.12) đ-ợc hoàn thành thử nghiệm đơn vị bắt đầu

2.2 Hai thành viên đội (Rd Foan) dự lớp học ngày giao diện ng-ời lập trình cho ch-ơng trình giao diện ng-ời dùng Đây hoạt động không theo lịch đ-ợc phê chuẩn họp dự án Điều khơng làm chậm lịch trình, hồn thành sớm ngữ huy 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 nghiên cứu ch-ơng trình đề nghị (coi phần 2.2 trên) Nếu ch-ơng trình lại xét khơng thích hợp, điều ảnh h-ơỏng nghiêm trọng lịch trình phát triển

3.2 Một thành viên (pack Brown) sử dụng điểm cuối cũ VT100 trạm cộng tác tuần qua, thiếu cấp thời trạm công tác Đây lý nhiệm vụ 5.12 pack Brown khơng hồn thành tuần theo lịch

5.3.2 Các họp tình hình dự án

Các họp tình hình dự án phải đ-ợc tiến hành định kỳ, thông th-ờng tuần lần Thời gian tốt cho họp tình hình vào cuối ngày cuối tuần hay đầu ngày đầu tuần Các họp tình hình đóng góp vào khơng khí trật tự kiểm tra phạm vi dự án phải đ-ợc tiến hành dặn vào giấc định Những thành viên

18Ch-ơng bàn thêm báo cáo tình hình đ-ợc sử dụng để cập nhật lịch trình phát triển

khơng thể tham dự họp tình hình dự án với đồng ý ng-ời quản lý dự án, uỷ nhiệm thành viên khác đội tham dự

Ng-ời quản lý dự án chuẩn bị cho họp tình hình cách duyệt lại báo cáo tình hình thành viên chủ chốt dự án đệ trình (đặc biệt xốy vào phần vấn đề) Do báo cáo tình hình phải đ-ợc đệ trình hai đến ba tr-ớc họp tình hình

Các thành viên chủ chốt dự án tham dự họp tình hình dự án Cuộc họp bắt đầu báo cáo hoạt động dự án vấn đề tổng quát ng-ời quản lý dự án trình bày Sau thành viên đ-ợc giành đến 10 phút báo cáo hoạt đọng đội hay lĩnh vực trách nhiệm Việc thảo luận vấn đề khơng giới hạn ng-ời báo cáo vấn đề ng-ời quản lý dự án Mọi vấn đề đ-ợc thành viên nêu với hỗ trợ có lãnh đạo đội theo làm cho kinh nghiệm họ có đ-ợc xuyên suốt dự án Vai trị ng-ời quản lý dự án khơng phải cung cấp giải pháp cho vấn đề mà h-ớng dẫn thành viên đội h-ớng giải pháp

Giải pháp phải cố giắng có đ-ợc họp tình hình Bất vấn đề khơng đ-ợc giải phạm vi năm phút phải đ-ợc hoãn lại để bên liên quan thảo luận sau họp tình hình Biên họp tình hình dự án phải đ-ợc l-u hồ sơ cáp ngun văn khơng có u cầu vấn đề sau phải có biên bản;

1 ngày họp tên 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 hành động (tên , hành động, ngày hoàn thành) 6.quyết định chủ yếu vấn đề thảo luận

Biên họp tình hình dự án phải đ-ợc đánh máy phân phát sớm khơng chậm q cuối ngày Điều đặc biệt quan trọng có mục hành động phải hoàn thành ngày Khi dự án lớn để cần có th- ký biên đ-ợc lập đánh máy th- ký Trong dự án nhỏ hơn, ng-ời quản lý dự án quay vịng nhiệm vụ tun gia cỏc thnh viờn

5.4 Những Đ-ờng lối chung quản lý kỹ s- phần mềm.

Quản lý theo thoả thuận tốt quản lý theo thị Bao tốt có đ-ợc kỹ s- chấp nhận nhiệm vụ đ-ợc giao Điều tạo th-ờng đ-ợc coi sở hữu nhiệm vụ làm tăng đáng kể động ký s- Nhằm thực điều này, kỹ s- phải đ-ợc giao nhiệm mà họ muốn đ-ợc Nếu điều không thể, ng-ời quản lý dự án phải mô tả trung thực ph-ơng án có đ-ợc giải thích cho kỹ s- nhiệm vụ đặc thù lại khơng có

Trách nhiệm ln phải liền vai kề vai, với thẩm quyền Mọi thành viên điều hành dự án niên, phải đ-ợc giao thẩm quyền hành động phạm vi trách nhiệm 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ỏ thành phần sản phẩm kỹ s- phát triển phải có đ-ợc thẩm quyền có định thiết kế liên quan đến thành phần mà họ phát triển Dù sao, khơng có thẩm quyền tuyệt đối, nhân cấp cao dự án phải th-ờng xuyên xét duyệt lại định nhảy vào họ cảm thấy có sai lẩm xảy

Qui tắc chung sai lầm rõ ràng phải đ-ợc hiệu chỉnh Điều dẫn đến qui tắc phát triển dự án ; cách tốt để làm đ-ợc điều khơng phải sở đủ để thay đổi Nói cách khác ng-ới quản lý cảm thấy anh hay chị có định tốt hơn, nh-ng định chấp nhận đ-ợc định phải khơng đ-ợc thay đổi

Quyền sở hữu không liên quan đến nhiệm vụ mà cịn đến lịch nguồn đơi với nhiệm vụ Mọi lịch trình phải đ-ợc thoả thuận ng-ời thực thực tế dự toán lịch trình phải đ-ợc chuẩn bị với ng-ời thực Điều đảm bảo cam kết ng-ời thực hay ng-ời sản xuất tham gia vào lịch trình

Cuối cùng, động yếu tố quan trọng việc quản lý thành công đội ngũ phát triển Động đ-ợc khuyn khớch bng nhiu cỏch

- L-ơng th-ởng - Đề bạt

- Điều kiện môi tr-ờng làm việc -Quyền lợi công việc đ-ợc giao - Qúi trọng

- Tôn giá trị

- Thỳc đảy ý thức hồn thành

Tơn giá trị nguồn động cao Với ng-ời quản lý dự án việc gọi ng-ời đến văn phịng nói ''cám ơn anh làm cơng việc vĩ đại'' tạo nên kỳ tích Những cách khác để tơn gía trị gửi th- đánh giá có gửi quản lý cấp cao cho ban nhân cho nhân viên có cố gắng đặc biệt đ-ợc nghỉ cuối tuần Mọi điều tăng thêm động cơ, không cho cá nhân nhân viên đ-ợc cám ơn mà cho ng-ời khác xuyên suốt dự án

5.5 Tãm t¾t.

Quản lý kỹ s- phần mềm khó quản lý kỹ s- hầu hết lĩnh vực công nghệ khác Các kỹ s- phần mềm đa dạng mức độ hiệu suất Trong dự án trung bình, khơng phải không phổ biến tỉ lệ hiệu suất 1.5 Một mục tiêu công nghệ phần mềm thời đại giảm phạm vi hiệu suất nhà sản xuất phần mềm thông qua ph-ơng pháp phát triển phần mềm có hệ thống có tổ chức

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 tuỳ thuộc loại dự án đ-ợc phát triển Những dự án lớn phức tạp đòi hỏi cấu tổ chức lớn Bất kể qui mô dự án, dự án phần mềm phải đ-ợc tổ chức thành đội phát triển nhỏ Về mặt lý tuởng, đội phần mềm có bốn đến sáu nhà sản xuất lãnh đạo đội phụ trách

Có ba loại đội phần mềm :

- Những đội dân chủ, lãnh đạo đội lãnh đạo mặt hành định kỹ thuật thành viên đội đề

- Các đội ngũ kỹ tr-ởng (hay đội ngũ lập trình tr-ởng) kỹ s-đàn anh có kinh nghiệm lãnh đạo trách nhiệm lãnh đạo mặt hành kỹ thuật

- Các đội chuyên gia đ-ợc lập để giải vấn đề đặc biệt phạm vi dự án Các đội đ-ợc giải thể vấn đề dặc biệt đ-ợc giải

Với ng-ời quản lý dự án, điều đ-ợc thơng báo Th-ờng xun tình trạng thực 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 ng-ời sản xuất Dù sao, trao đổi th-ờng xun khơng thức với ng-ời sản xuất nguồn thông tin tuyệt vời, đặc biệt đ-ợc tiến hành bầu không khí khơng thức (và khơng phải văn phịng ng-ời quản lý dự án)

Bài tập

1 Bạn ng-ời quản lý cho dự án thông tin tập hợp cửa hàng vào dây chuyền lớn cửa hàng Mỗi cửa hàng thông th-ờng có máy vi tính riêng mạng với ký kiểm tra Quản lý dây chuyền muốn thiết lập máy vi tính trung tâm văn phòng nối mạng máy vi tính 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 nhận đ-ợc thông tin, thời gian thực giao dịch cửa hàngt muốn cập nhật sở liệu kiểm kê trung tâm

Bn hóy chuẩn bị biểu đồ tổ chức khối tháp cho dự án thơng tin cửa hàng Giải thích cấu mà bạn chọn cấu lại thích hợp cấu tổ chức khác có

2 Lập kế hoạch luồng thơng tin phạm vi tổ chức bạn đề nghị tập1 Cần báo cáo phải đ-ợc đệ trình th-ờng xun nào? có họp tình hình cần phải đ-ợc triệu tập th-ờng xuyên nào? Ai dự họp đó?

Gợi ý tần độ biến động báo cáo tình hình họp nắm tình hình, theo giai đoạn phát triển khác

3 Chuẩn bị biểu đồ tổ chức mà trận cho dự án tập So sánh với cấu khối tháp bạn đề nghị tập : cấu thích hợp cho dự án ? có điểm lợi bất lợi cấu tổ chức cho dự án

4 Bạn đề nghi cấu đội phát triển hỗ trợ cho dự án mơ tả tập Giải thích cấu mà bạn chọn Bạn có dự kiến nhu cầu cho đội chuyên gia phát triển dự án ?

5 Dù ¸n cđa lớp học phân lớp thành hay nhóm sinh viên giao tập 1,2 cho nhóm cho nhóm trình bày giải pháp tr-ớc lớp

Ch-ơng sáu

Chia để trị dự án lớn : phõn chia v chim lnh

Nhu cầu lớn không cã nghÜa lµ khã

Nhiều đối t-ợng phức tạp đ-ợc xem vơ vàn đối t-ợng dơn giản Một thí dụ thích hợp hố chất hình thành từ nhiều phân tử khác phân tử đ-ợc tạo thành phối hợp nhiều nguyên tử khác Các nguyên tử mặc dẫn thân phân chia đ-ợc đ-ợc coi phần tử nhỏ hoá chất

Theo cách t-ơng tự dự án phức tạp đ-ợc phân thành thành phần đơn giản Trong tồn dự án khó quản lý thành phần dễ sử lý dự án phần mềm đ-ợc phân thành thành phần nhỏ nhằm dự tính tốt khối l-ợng công việc nhằmđiều khiển hoạt động đội phát triển khác

ViƯc ph©n giải dự án phần mềm nhiệm vụ ng-ời quản lý dự án phần mềm Dù ph-ơng pháp phân giải khác nhau, tuỳ theo mục tiêu thực ng-ời quản lý dự án.Việc phân tích dự án theo chức không nh- phân tích thiết kế Phân tích chức chia dự án thành thành phần theo cách nhìn ng-ời dùng phân tích thiết kế chia dự án thành thành phần hay mô đun lập trình

Ch-ơng bàn đến ph-ơng pháp quản lý hiệu dự án phần mềm phức tạp giới thiệu ph-ơng pháp phân tích dự án thành thành phần quản lý đ-ợc Các loại phân giải dự án đ-ợc bàn đến mục tiêu 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 khơng hợp lý khu tìm cách minh định thành phần dự án b-ớc Rõ ràng qui trình lặp cung cấp nhiều chi tiết hơn, dể sử dụng Những ph-ơng pháp lặp thuộc loại đ-ợc gọi tinh chế b-ớc phân giải đ-ợc tiếp tục tinh chế b-ớc kế tục

Hình 6.1 trình bày ninh hoạ tổng quát tinh chế b-ớc Hệ thống ban đầu đ-ợc phân thành ba thành phần cấp cao thành phần cấp cao lại đ-ợc phân tiếp thành thành phần cấp thấp hơn, đạt đ-ợc cấp thành phần thấp

tả toàn hệ thông nh-ng mức chi tiết khác hình 6.1 thành phần 1,2 tạo nên hệ thống hoàn chỉnh Để đ-ợc chi tiết hơn, lấy b-ớc phân giải tiếp thấy thành phần 1.1,1.2,2.1,2.2,2.3,3.1 3.1 biểu thị tòan hệ thống

Hình 6.1

Phân giải phần mềm tinh lọc b-ớc

S đồ tinh chế b-ớc t-ơng tự nh- biểu đồ hệ thống tôn ti trật tự Dù điều quan trọng phải hiểu tinh chế b-ớc khác khối cấu thành biểu đồ khác Sơ đồ hệ thống tôn ti mô tả mối quan hệ tôn ti thành phần khiến cho thành phần sơ đồ t-ơng ứng thực với thành phần thực hệ thống Dù sơ đồ tinh lọc b-ớc, thành phần cấp cao tên đặt theo qui -ớc cho nhóm thành phần thực xuất d-ới

Trong h.6.2(a) phần mềm 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 kích hoạt báo động Mỗi năm mơ đun t-ơng ứng với 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 hệ thống báo động không tồn mô đun phàn mềm thực xuất nh- tên đặt cho hai nhóm thành phần cấp thấp

Hình 6.2 (b) mơ tả phần mềm hệ thống truy nhập đ-ợc có kiểm tra nh- ng lần đ-ợc biểu thị nh- biểu đồ tôn ti mỗi-thành phần biểu đồ biểu thị mỗi-thành phần phần mềm thực.Thành phần khung điều hành hệ thống gọi ba thành phần khác nhận biết khách thăm , kiểm tra khoá cửa kích hoạt báo động thành phần nhận biết khách

19 Tất nhiên , đơ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ợp phần Hệ thống

Hợp phần Hợp phần

1.1 1.2 2.1 2.2 2.3 3.1 3.2

Hình 6.2.a

Phân giảI thành phần mứ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 hai hành phần : Nhận biết truy nhập nh-ơng pháp 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 dự án phần mềm phân chia hệ thống thành thành phần theo hoạt động nh- ng-ời dùng nhận định Việc phân giải theo chức phận pha yêu cầu dự án Mục tiêu pha xác định đặc điểm hệ thống theo cách nhìn ng-ời dùng

Ta thử xem xét hệ thống thủ qũi ngân hàng tự động khả thông tin trực tuyến thủ quỹ tự động xa xơi máy vi tính trung tâm ngân hàng nhằm cung cấp thông tin tài khoản đ-ợc cập nhật đặc điểm chức hệ thống điều thơng th-ờng đ-ợc xác

PhÇn mỊm hệ thống truy cập đ-ợc đ/kh

Kớch hot bỏo động Nhận truy cập

bất hợp pháp Hệ thống báo động

Quản lý tệp truy cập Khống ch ng

hồ cửa Nhận

ng-ời thăm

Khống chế Truy cập

Vòng lặp thừa hành hệ thống

Bỏo ng

Quản lý tệp truy cËp NhËn viƯc

truy cËp bÊt hỵp pháp

Nhận khách thăm

định pha yêu cầu chu kỳ phát triển Dù sao, ph-ơng pháp chuyển giao thủ quỹ tự động máy vi tính trung tâm khơng phải đặc điểm chức hệ thống thiết kế thực hệ thống không hiển nhiên cho ng-ời dùng Ph-ơng pháp chuyển giáo kể nghi thức liên lạc th-ờng đ-ợc xác định giai đoạn thiết kế phát triển 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 thủ quỹ tự động máy vi tính trung tâm đặc điểm chức hệ thống bên thiết kế thực hệ thống không hiển nhiên cho ng-ời dùng Ph-ơng pháp chuyển giao kể nghi thức liên lạc th-ờng đ-ợc xác định giai đoạn thiết kế phát triển hệ thống

ở định thực lúc đ-ợc đ-a giai đoạn yêu cầu đ-ợc coi yêu cầu thực Điều bao gồm đặc điểm nh- 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ết nên hỗn, định thực chậm hay pha thiết kế

Hình 6.3 nêu thí dụ phân tích theo chức hệ thống thủ quĩ ngân hàng tự động thành thành phần chức mức thấp

Trong hình 6.3 xác định có sở liệu khách hàng đ-ợc xem định thiết kế Điều không tránh khỏi Phân tích chức hồn tồn tránh đ-ợc nhận định thiết kế Nh- biết phân giải chức th-ờng khởi điểm cho thiết kế ban đầu hệ thống

6.1.2 Ph©n gi¶i thiÕt kÕ.

20

Các định thực đơi đ-ợc đ-a giai đoạn yêu cầu đ-ợc coi yêu cầu thực Điều bao gồm đặc điểm nh- 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 nên chậm định thực đến giai đoạn thiết kế lúc đ-ợc

Hệ thống thủ quĩ ngân hàng 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 giao diện máy thủ quĩ Cập nhật hỏi

máy tính trung tâm Dịch vụ

ng-ời dùng Dịch vụ thủ quĩ tự động

Phân giải thiết kế hệ thống phần mềm phân chia hệ thống thành thành phần cấp thấp khớp với thành phần phần mềm thực hệ thống Trong phân giải thiết kế hoàn toàn hệ thống phần mềm, thành phần thấp t-ơng ứng với mô đun lập trình (thông th-ờng thủ tục, ch-ơng trình hay chức ch-ơng trình)

ỳng nh- pha yờu cu tr-ớc giai đoạn thiết kế việc phân giải chức hệ thống phần mềm thông th-ờng tr-ớc việc phân giải thiết kế Phân giải chức 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 thành phần thực Trên thực tế, phân giải chức th-ờng nơi tốt để khởi thiết kế hệ thống phần mềm thành phần chức chủ yếu hệ thống th-ờng t-ơng ứng với phân chia ban đầu hệ thống thành hệ thống hay thành phần mức cao

Hai chức hệ thống chủ quỹ ngân hàng tự động đ-ợc coi máy vi tính trung tâm nơi l-u trữ bảo trì tồn thông tin tài khoản 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 địa điểm thủ quỹ đ-ợc xác định thành phần bổ sung cấp cao Rồi mạng tất nhiên phân chia 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 ở hệ thông hớn hệ th-ờng tiêu biểu cho phân giải mức thứ hệ

thống Điều đ-ợc bàn thêm phần 6.3

H thng th qu ngân hàng tự động

Logic giao diƯn thđ q Logic thủ

quĩ

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đ q Giao diƯn trun

th«ng thđ q Giao diện mạng diện rộng

Quản lý sở d÷ liƯu

khách hàng Thủ quỹ tự động

Driver ph¸t tiÕng

bÝp Driver

m¸y in Driver

màn hình Driver bàn

Hỡnh 6.4 nêu thí dụ phân giải thiết kế hệ thống thủ quỹ ngân hàng tự động thành cấp thành phần thiết kế thấp ởcấp thứ ba thành phần thủ quỹ tự động phân giải thành giao diện phần cứng logic thủ quỹ Rồi cấp sau phân giải giao diện phần cứng thành kích thích bàn phím, kích thích hình, kích thích máy in máy phát tiếng bíp, cấp này, kích thích đại diện mô đun phần mềm

Một điểm quan trọng cần nhớ phân giải thiết kế, có thành phần cấp thấp đ-ợc thực Các thành phần cấp cao đại diện cho nhóm thành phần cấp thấp Điều đ-ợc minh họa hình 6.2(a) theo thành phần kiểm tra truy nhập hệ thống báo động đại diện cho hai nhóm thành phần cấp thấp (nhận biết khách thăm, kiểm tra khóa cửa v.v )

Về phân giải thiết kế tạo hai loại thành phần hệ thống thành phần cấp cao mô đun cấp thấp Các tiêu chuẩn phát triển phần mềm khác sử dụng thuật ngữ khác để nhận biết cấp phân giải khác

Chẳng hạn, tiêu chuẩn 2167A US DOD (DOD 1988a) sử dụng 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ững thành phần cấp trung độ đ-ợc gọi CDC (thành phần phần mềm vi tính) thành phần đại diện nhóm CSU 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) CSCZ đ-ợc quản lý phạm vi dự án coi nh- đơn vi phát triển bán độc lập CSCZ thành phần đ-ợc thiết kế, chứng minh t- liệu phê chuẩn nh-những thực thể riêng biệt phạm vi toàn 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

H×nh 6.5.a

Phân giải phần mm mc nh ban u

Hợp phần Hệ thèng

H×nh 6.5.b

Phân giải phần mềm mức trung gian thiết kế mức 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 hoàn toàn với thành phần cấp thấp nó, khơng phải dễ nắm bắt, điều đặc biệt trình bày hệ thống lúc duyệt dự án hệ thống cần đ-ợc ng-ời khơng dính liú vào việc thiết kế nhanh chóng hiểu đ-ợc Trong tr-ờng hợp nh- thế, kỹ thuật tinh lọc b-ớc ph-ơng pháp thuận lợi để trình bày chi tiết tăng dần cách lúc đầu choi thấy cấp phân giải chầm chậm phát cấp Điều đ-ợc chứng minh hình 6.5 Trong b-ớc phân giải trung độ thích hợp, phân thiết kế làm hai: cấp cao cấp thấp Điều đặc biệt đ-ợc dùng giai đoạn thiết kế đ-ợc thực thành giai đoạn riêng biệt: thiết kế cấp cao 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- vậy, bàn đến việc phân hệ thống phần mềm thành thành phần chức thiết kế Chúng ta xem xét việc phân dự án phần mềm thành thành phần công vic c bn

Hợp phần Hệ thống

Hợp phần Hợp phần

1.1 1.2 2.1 2.2 2.3 3.1 3.2

Hợp phần Hệ thống

Hợp phần Hợp phần

1.1 1.2 2.1 2.2 2.3 3.1 3.2

Tổng số thành phần cơng việc bao gồm nhiệm vụ cần thiết đ-ợc thực nhằm hoàn thnh thng li d ỏn

6.2.1 Phân giải dự án.

Đúng nh- 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ý nhiều cách tiếp cận chia trị (phân chia chiếm lĩnh) việc tinh lọc b-ớc, áp dụng cho dự án phần mềm, tạo nên nhiệm vụ công việc cấp thấp Điều bao gồm nhiệm vụ phát triển, nhiệm vụ quản lý, nhiệm vụ hỗ trợ nhiệm vụ hành Việc phân giải dự án phần mềm thành nhiệm vụ đ-ợc coi 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 ví dụ biểu đồ cấu phân tích cơng việc bảng 6.1 danh mục nhiệm vụ cấu phân tích cơng việc đạt đ-ợc Danh mục nhiệm vụ WBS có nhiệm vụ cơng việc dự án đ-ợc dùng làm cơng cụ kiểm chứng để kiểm tra tình hình 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à lịch có danh mục hoạt động dự án Danh mục hoạt động lịch t-ơng tự nh- WBS mục đích có khác th-ờng chi tiết Danh mục hoạt động lịch đ-ợc mô tả ch-ơng

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

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ấu phân tích công việc.

Nhiệm vụ Mô tả Tình hình Giao cho Nhận xét Quản lý hà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 hình

2.2.3.1 Bộ khuôn hình Trọn vẹn J.Smith 2.2.3.1 Bộ kích thích 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 Cung cấp hỗ trợ phát

triển

Hot 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

Dù ¸n WBS

Đơi lại có ích gặp nhóm nhiệm vụ cấp cao danh mục nhiệm vụ WBS (thí dụ nhiệm vụ 1, 2, 3, 2.1, 2.2, v.v bảng 6.1) Điều giúp truy nguyên có lợi cho nhiệm vụ cấp thấp nhằm nhận biết nhóm nhiẹme vụ từ suy Dù sao, việc đ-a nhóm nhiệm vụ cấp cao danh mục nhiệm vụ WBS gây hỗn độn khoản không đại diện cho nhiệm vụ đ-ợc giao nhữn thuộc tính tình hình ủy nhiệm cho không áp dụng đ-ợc cho chúng

Danh mục WBS nhiệm vụ dự án đ-ợc suy từ thống kê công việc dự án (SON) xác đinh quy mô dự án SON th-ờng đ-ợc chuẩn bị tr-ớc dự án thức (coi ch-ơng 3) th-ờng phận hợp đồng dự án khách hàng nhà sản xuất Với dự án nội bộ, tổ chức tài trợ công việc phát triển mình, SON trở nên vơ danh với việc xác định chi tiết dự án hay 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 công cụ quản lý dự án.

Cơ cấu phân tích cơng việc xác định nhiệm vụ phải thực trình phát triển dự án Điều bao gồm nhiệm vụ từ 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ụ đ-ợc mô tả chi tiết b¶ng 6.2

ở Mọi lúc, cơng việc đ-ợc thành viên đội dự án phần mềm thực phải phận nhiệm vụ WBS không thành viên đội đ-ợc thực nhiệm vụ khơng có danh mục WBS nhiệm vụ

WBS công cụ ngân sách cung cấp ph-ơng tiện tính giá hoạt động phát triển vào đoạn thích hợp ngân sách dự án Đây ph-ơng pháp để lập kế hoạch 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 hoạt động máy vi tính nhỏ loại PC phần lớn Những tiện ích WBS đơi có đ-ợc nh- phận tiẹne ích qui hoạch chung ng-ời quản lý cung cấp đặc điểm lịch trình giám sát khác nh- phân tích PERT hình thành báo cáo

Có ph-ơng pháp khác đ-ợc phát triển để quản lý nhiệm vụ công việc cấp thấp bao gồm dự án lớn Có vơ vàn biến thức cải tiến kỹ thuật cấu phân tích cơng việc22, số sử dụng cơng cụ

truy tìm tinh vi, số khác sử dụng ký hiệu kỹ thuật đặc biệt để phân tích 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, nhiệm vụ nhỏ dễ sử lý nhiệm vụ lớn Nh-chúng ta thấy, lập luận bảo vệ việc phân dự án lớn thành thành phần nhỏ

Trong tranh luận kiến trúc hệ thống phần mềm tàu thoi vũ trụ, Carlow (1984) nhận xét " công cụ kỹ thuật thơi khơng thể phịng ngừa hay khắc phục vấn đề tồn kiến trúc hệ thống cấu trúc tốt không đ-ợc thiết lập đầu mặt tiền qui trình phát triển." Trong tham luận ông, Carlow mô tả lập luận bảo vẹ cấu kiến trúc phần mềm phức tạp cho hệ thống mà phân ban hệ thống liên bang IBM phát triển cho tàu thoi vũ trụ NASA Điểm phải làm kiến trúc phần mềm vốn đ-ợc xác định sớm chu kỳ phát triển đóng vai trị chủ đạo việc xây dựng chất l-ợng sản phẩm phần mềm cuối Hay, tóm lại, sai lầm chủ yếu th-ờng bắt đầu sớm

Con đ-ờng mà 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 tựa nh- kiến trúc hay phân giải H.6.7 giới thiệu hai phân giải cấp cao đ-ợc hệ truy nhập đ-ợc kiểm tra Cả hai đoạn hợp lý hệ thống nh-ng kiến trúc h.6.7.(b) địi hỏi giao diện thành phần phần mềm

Giê chóng ta sÏ xem xÐt mét sè h-íng dÉn ph¶i theo lùa chän mét cấu phân giải riêng

6.3.1 Các hệ thống phô.

22

Các hệ thống gồm thành phần chủ yếu bán độc lập thân chúng đ-ợc coi hệ thống Một hệ thống thủ quỹ ngân hàng tự động tất nhiên đ-ợc phân làm hai hệ phụ hơn: hệ phụ vi tính hệ phụ vi tính thủ quỹ tự động Theo hệ phụ chứa hầu hết đặc điểm hệ, trừ hệ phụ khơng có ý định hoạt động 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 hệ thống phần mềm lớn chia thành hệ thống phụ chúng loại bỏ 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 việc quản lý phát triển hệ thống phụ coi nh- hệ riêng biệt phạm vi đ-ợc

Vớ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 trách nhiệm chúng cho hệ thống phụ đ-ợc quản lý dự án 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

ở 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 giao trách nhiệm cho hai thành phố hệ thống Ng-ời quản lý dự án giám sát hoạt động đội phối hợp hoạt động giao diện kỹ thuật hành đội Việc ủy nhiệm lãnh đạo đội phần mềm đ-ợc bàn thêm ch-ơng

ở số dự án qui mô lớn nh- phát triển phần mềm cho tàu thoi vũ trụ NASA, dự án khổng lồ đến mức độ thức tế đ-ợc phát triển nh- dự án riêng biệt Văn phòng Trung -ơng chịu trách nhiệm phối hợp hoà nhập hệ thống phụ (cả phần mềm phần cứng) Tham luận Dadden Rone (1984) đề cập sâu đến qui mô lớn lao d ỏn phc 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 hệ thống phần mềm phân giải theo chức t-ơng ứng với cấu phần mềm nh-đ-ợc ng-ời dùng nhận thức Việc phân chia giúp xác định yêu cầu cho hệ thống cung cấp ph-ơng pháp nhận biết chức cấp thấp gán chúng vào yêu cầu cho hệ thống chủ yếu

Nhiều văn đề nghị phân giải chức phải theo phân tích yêu cầu hệ thống Trong nhiều tr-ờng hợp, phác thảo chung yêu cầu tạo nên biểu đồ chức cấp cao Trên tinh thần đó, việc tình lọc phân giải chức khăng khít với việc phân tích hệ thóng biểu đồ đ-ợc luôn xem lại tinh lọc lại có thêm đ-ợc thơng tin

Phân tích chức cấp cao hệ thống phần mềm th-ờng ý t-ởng tiêm nghiệm diễn tiến giai đoạn quan niệm Rồi ý t-ởng định phân chia đặc thù hệ thống, từ diến tiến phân giải chức

Sự phân chia ban đầu hệ thống lôgíc thích hợp theo viễn cảnh ng-ời sản xuất Hệ thống kiểm kê rộng lớn ban đầu nhận thøc lµ bao gåm:

- Giao diƯn ng-êi - Bộ phát báo cáo - Cơ sở liệu - Lôgíc cập nhật

Đ-ờng lối chung phân giải chức đ-ợc lựa chọn đ-ợc quan niệm

Nh- chỳng ta ó thy, phõn gii chức tốt quan trọng rõ ràng xác định thiết kế kiến trúc hệ thống đ-ợc phát triển, Chiến l-ợc tin cậy việc xác định phân giải chức phần mềm đ-ợc tốt triệu tập họp ng-ời trọng yếu dự án để bàn số phân chia khác hệ thống Sau phân giải chức phải đ-ợc lựa chọn sở

- Lý (thÝ dơ c¸c m¸y vi tÝnh kh¸c th-ờng hỗ trợ chức khác nhau)

- Dễ thực (thí dụ phân giải chức tốt th-ờng dẫn đến thiết kế tốt)

- Dễ hiểu (đã đáp ứng hết chức ch-a ?)

ViƯc dƠ thùc hiƯn tïy thc ë tiªu chÝ thiết kế mà ta bàn sau

6.3.3 Đ-ờng lối phân giải thiết kế.

Chỳng ta ó bit phân giải chức hệ thống phần mềm khác với phân giải thiết kế hệ thống Dù phân giải chức tốt ý đến thiết kế nh- giai đoạn phát triển sau th-ờng khởi điểm tốt cho việc phân chia hệ thống thành thành phần thiết kế cấp cao

Việc phân giải thiết kế hệ thống phần toàn 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ù theo viễn cảnh ng-ời quản lý dự án, giai đoạn định việc phân giải thiết kế hệ thống xác định cấu phần mềm nh- đ-ợc hình thành Sau tổng quan nhận định thiết kế ảnh h-ởng đến ph-ơng pháp phân giải hệ thống

Một quan điểm sớm cơng nghệ phần mềm địi hỏi tiếp cận cấu với việc thiết kế lập trình phần cứng Bản chất cấu phần mềm đ-ợc xác định từ giai đoạn phân giải Vào cuối năm 1960 đầu 1970 Difkstra đầu tiếp cận (1972) Mục tiêu chủ yếu chuyển sang phát triển phần mềm (hay đơn giản lập trình nh- sau đ-ợc gọi thế) từ ch-a thành thục tới trở thành ngành công nghệ hịan tồn phát triển Từ đến nhiều kỹ thuật thiết kế cấu khác đ-ợc Yourdon (1978), Jackson (1976) De Marco (1979) Warrier Orr (1977) phát triển, kể số, nh-ng ch-a có tiêu chuẩn nói chung đ-ợc chấp nhận

che dÊu th«ng tin trë thành khối công trình 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 môđun nhỏ, đơn giản, độc lập Tất nhiên, hệ thống, khơng có hai mơđun thực độc lập, nên từ ngữ độc lập phải hiểu theo nghĩa độc lập tốt phạm vi ràng buộc hệ thống đ-ợc phát triển

ở cấp phân giải thấp nhất, mức độ độc lập môđun đ-ợc coi mức độ ghép nối tồn thiết kế Những biện pháp ghép nối đặc điểm phụ thuộc lẫn nh- liệu nội dung kiểm tra mơđun (có nghĩa chồng chéo biên môđun)

Chắc chắn nguyên tắc phân giải thiết kế phần mềm đ-ợc định tâm chung quanh quan niệm hộp đen Ngun tắc đó, đ-ợc coi che dấu thơng tin tiến tới tạo môđun che dấu thiết kế chúng Các hộp đen đ-ợc nhận biết đầu vào đầu ra, không ph-ơng pháp sử dụng để phát sinh đầu từ đầu vào mà có Việc che dấu thơng tin tạo mơđun che dấu luồng lơgíc chúng cấu liệu chúng với Mặc dù từ hộp đen tr-ớc tiến triển công nghệ phần mềm ngành, quan niện che dấu thông tin thiết kế phần mềm đ-ợc Iarnas đ-a 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 phân thành nhóm nhiệm vụ đơn giản đ-ợc xác định rõ biểu thị cấu phân tích công việc hay WBS WBS phân giải phần mềm tạo dự án Đó phân giải thân dự án bao gồm hoạt động nh- quản lý, cung cấp, lắp đặt tất nhiên phát triển phần mềm

Cơ cấu thiết kế hệ thống tạo nên 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 bản: thiết kế môđun, lập mã 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 hội nhập từ giai đoạn phát triển khác mà

Bảng 6.2 có danh mục tiêu biểu nhiệm vụ WBS cấp cao đ-ợc đ-a vào danh mục nhiệm vụ WBS thức (coi bảng 6.1) Đây danh mục tận dụng nhiệm vụ phát triển dự án khơng phải dự án địi hỏi nhiệm vụ mơ tả Dù sao, bảng có ích làm danh mục kiểm tra hỗ trợ xác định vị trí nhiệm vụ 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 qui chuẩn đến mức độ rộng khác đ-ợc xác định

23

do qui mô lớn lao dự án đ-a vào mô hình quản lý Thí dụ danh mục nhiệm vụ quản lý quan trọng đòi hỏi cho hầu hết dự án phát triển phần mềm Những nhiệm vụ không bắt buộc cho nhiệm vụ đ-ợc đánh dấu nh- danh mục

Nên ghi nhận phân tích ngân sách quản lý ngân sách nhiệm vụ quản lý bắt buộc đơn giản khơng phải tất dự án quản lý ngân sách chúng Một số tổ chức có quan chức tài chịu trách nhiệm quản lý ngân sách dự án Giao diện khách hàng phải nhiệm vụ quản lý bắt buộc khơng phải dự án có khách hàng Trong tr-ờng hợp dự án nội công ty, quản lý cấp cao, với ng-ời sử dụng hệ thống đ-ợc định, đóng vai trị khách hàng Th-ờng họ nêu rõ yêu cầu dự án ban đầu ng-ời quản lý dự án phải đến họ để đ-ợc phê chuẩn cuối đ-ợ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 phân thành thành phần đơn giản toàn dự án khó quản lý, thành phần lại dễ sử lý Việc phải giải hệ thống phần mềm thành thành phần nhỏ có ích việc giám sát hoạt động đ-ợc ủy thác cho đội phát triển khác Ph-ơng pháp phân giải khác nhau, tùy thuộc mục tiêu ng-ời quản lý dự án

Việc tinh lọc b-ớc ph-ơng pháp lặp lại để phân giải dự án thành thành phần quản lý đ-ợc Việc tinh lọc b-ớc công cụ có ích cho việc xác định, phân giải công việc, thiết kế chức dự án phần mềm Trong phân giải b-ớc dự án, thanhphâfn phân giải thành thành phần trực tiếp d-ới Mỗi b-ớc phân giải mơ tả tồn hệ thống nh-ng mức độ chi tiết khác

Phân giải chức hệ thống phần mềm phân chia hệ thống thành thành phần vận hành: đặc điểm mà ng-ời dùng nhìn thấy Phân giải thiết kế hệ thống phần mềm phân chia hệ thống thành thành phần cấp thấp trùng với thành phần lập trình hệ thống Cơ cấu phân tích cơng việc (WBS) phân giải dự án phần mềm thành nhiệm vụ công việc cấp thấp

Phân giải chức cấp cao hệ thống phần mềm th-ờng ý t-ởng tiêm nghiệm diễn tiến giai đoạn quan niện Những ý t-ởng định phân chia đặc thù hệ thống từ diễn tiến phân giải chức Dù sao, phân chia ban đầu cảu hệ thống lơgíc thích hợp tr-ớc viễn cảnh ng-ời sản xuất Về đ-ờng lối chung, khơng có phân giải chức lại đ-ợc lựa chọn đ-ợc quan niện

Phân giải chức hệ thống phần mềm khác với phân giải thiết kế hệ thống Dù phân giải chức tốt có tính đến thiết kế giai đoạn phát triển sau khởi điểm tốt cho việc phân chia hệ thống thành thành phần thiết kế cấp cao Sau đó, thành phần thiết kế cấp cao lại đ-ợc phân giải thành cấp thấp liên tiếp cuối tạo nên mơđun lập trình Thiết kế môđun tốt tạo nên môđun độc lập, đơn giản, nhỏ

Cơ cấu phân tích cơng việc phân giải phần mềm dự án tạo nên mà phân giải dự án bao gồm hoạt động nh- quản lý, cung cấp, lắp đặt tất nhiên, phát triển phần mềm Nhiều nhiệm vụ phát triển WBS ph-ơng pháp phát triển đ-ợc sử dụng thiết kế kiến trúc hệ thống mà

Bµi tËp.

1 Công ty hệ thống phần mềm (SSI) phát triển vi tính có mục đích đặc biệt dựa vi xử lý chung SSI có biên dịch chéo cho vi xử lý hoạt động khung cơng ty Cơng ty định phát triển hệ thống vận hành sở hữu khiêm tốn cho máy vi tính

Hãy xét hệ thống đơn giản ng-ời dùng Chuẩn bị đề nghị việc phân giải chức hệ thống vận hành sử dụng tinh lọc b-ớc Mô tả biểu đồ phân giải chức cho ba cấp đầu

2 Víi hƯ thèng vËn hành mô tả tập 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 mô tả toàn phân giải tới tận cấp môđun phần mềm

Gii thớch bn ó tớnh n h-ớng dẫn cho môđun độc lập Giải thích bạn thực h-ớng dẫn che dấu thông tin

3 Với hệ thống vận hành tập 1, chuẩn bị biểu đồ cấu phân tích cơng việc cho ba cấp đầu chuẩn bị danh mục nhiệm vụ WBS Giải thích số nhiệm vụ bảng 6.2 không áp dụng đ-ợc cho dự án

4 XÐt phÇn mềm cho dự án vệ tính kể việc phãng vµ theo dâi vƯ tinh vµ vËn hµnh cđa vƯ tinh vµ sau phãng

Bây xét hệ thống danh sách nhân viên kể 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 việc xác định hệ phụ cho dự án ? Giải thích

B¶ng 6.2 NhiƯm vơ 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ử nghiệm 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 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

Chọn lựa thiệtbi Chọn lựa ng-ời bán Thủ tục đặt hàng Kiểm tra kiểm kê Thực

LËp m·

Thử nghiệm đơn vị

Qu¶n lý Qui hoạch Tuyển nhân

Quản trị dịch vụ khác

T- liệu

Bài viết kỹ thuật

Hoạt động xuất 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 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 bảo trì T- liệu ng-ời dùng

Bảng 6.3 Nhiệm vụ quản lý 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 Chuẩn bị dự án

3 Phân tích rủi ro quản lý rủi ro Lịch trình

5 Tuyển nhân

6 Phân tích ngân sách quản trị ngân sách Quản lý nhân

8.ủy thác nhiệm vụ Giao thÈm qun

10.đy th¸c ngn ph¸t triĨn

11 Giám sát bảo trì thiết bị phát triển 12 Giám sát kiểm tra phát triển

v v v v

15 Bảo hiểm kiểm tra chất l-ợng 16 Quản lý kiểm tra cấu hình

17 Giám sát chủ thầu phụ ng-ời bán 18 Giao diện phối hợp quản lý cao 19 Giao diện phối hợp khách hàng 20 Báo cáo

Ch-ơng bảy

Các chức hỗ trợ dự án

Hỗ trợ quản lý dự án.

Qun lý d ỏn phn mềm trình qui hoạch, tổ chức, tuyển nhân sự, giám sát, kiểm tra lãnh đạo dự án phần mềm24 Hiếm nhiệm vụ lại quản lý dự án thực mà thực tế mặt lý t-ởng họ Nhiều hoạt động kiểm tra giám sát đ-ợc ủy thác cho nhóm hỗ trợ dự án Những nhóm hỗ trợ khơng giám định nặng cho quản lý dự án kỹ s- phát triển nhiệm vụ hỗ trợ: họ thực nhiệm vụ tốt cách tập trung cố gắng họ vào chức hỗ trợ c tr-ng

Có nhiều loại chức hỗ trợ dự án Dịch vụ th- ký, hỗ trợ hành xuất cung cấp tài liệu thí dụ chức 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 bảo hiểm chất l-ợng thí dụ chức hỗ trợ kỹ thuật

Dự án lớn phức tạp lại đòi hỏi chức hỗ trợ nhiều Chẳng hạn, dự án lớn th-ờng có tổ chức kiểm tra chất l-ợng dự án nhỏ chia xẻ chức với dự án khác T-ơng tự, nhiều tổ chức trì nhóm thử nghiệm độc lập mà vai trò thử nghiệm sản phẩm phần mềm tr-ớc đ-a dự án lớn, nhóm thử nghiệm độc lập phận đội dự án tham gia thử nghiệm qui hoạch thử nghiệm xuyên suốt chu trỡnh phỏt trin

Ch-ơng mô tả ba chức 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 chc nng đ-ợc yêu cầu 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 kiểm tra chất l-ợng sản phẩm thử nghiệm thử lại đáp ứng với yêu cầu sản phẩm Trách nhiệm ng-ời quản lý dự án tổ chức nhóm hỗ trợ dự án cung cấp t- liệu hoạt động quy hoạch nhóm cho kế hoạch phát triển dự án (coi ch-ơng 9) Nếu nhóm có tổ chức, hỗ trợ nhóm cần đ-ợc phối hợp lên lịch cho dự án Nếu

nhóm khơng tồn chúng phải đ-ợc thiết lập độ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, dự án lớn yêu cầu nhóm hai hay ba kỹ kiểm tra cấu hình dự án nhỏ giao nhiƯm vơ mét phÇn thêi gian cho kü s- ph¸t triĨn

Các định phải quản lý dự án đ-a giai đoạn ban đầu dự án Các chức hỗ trợ dự án đ-ợc qui hoạch tốt lúc khởi đầu dự án đóng góp vào việc quản lý hiệu 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 hỗ trợ quản lý hỗ trợ nhiều hoạt động khác liên quan đến thay đổi cho sản phẩm phần mềm Điều bao gồm thay đổi mã ch-ơng trình, yêu cầu thay đổi thiết kế thay đổi việc đ-a phiên Kiểm tra cấu hình th-ờng đ-ợc nhà sản xuất coi trở ngại lợi ích hạn chế tự đội phát triển đặt giới hạn khơng thể làm Kiểm tra cấu hình dù tạo mơi tr-ờng phần mềm đ-ợc phát triển cách trật tự

Từ cấu hình đ-ợc sử dụng để mơ tả phối hợp 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ả ph-ơng pháp trật tự hiệu theo phối hợp thành phần đ-ợc thực hiện, chẳng hạn, xây dựng hệ phần mềm từ thành phần cấp thấp nhiệm vụ đơn giản Điều đ-ợc minh họa tố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 quốc tế Dịch vụ cung cấp cho ngân hàng truy nhập trực tuyến với sở liệu trung tâm chứa thông tin th-ờng xuyên cập nhật thị tr-ờng tài giới Trong giới đại thông tin điện tử nhanh, dịch vụ chủ yếu cho tổ chức ngân hàng đại Dù sao, máy tính ngân hàng khơng có đ-ợc khả giao diện với dịch vụ tài

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 giai đoạn hội nhập bắt đầu, nhà sản xuất báo cáo 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 cho cấp thông báo với họ phát triển đ-ợc tiến hành theo lịch

ch-a hoạt động Ngay đặc điểm tr-ớc khơng cịn hoạt động

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ử nghiệm đơn vị

Môđun phát triển

Kết thúc

Môđun kiểm tra cấu hình phát ra

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ữ phần mềm liên lạc khơng có đặc điểm Trong dự án tổ chức tốt, nhiệm vụ phòng vệ, phiên phần mềm tr-ớc hẳn đ-ợc ng-ời quản lý cấu hình thực

Một cách lý thú để xem đến kiểm tra cấu hình coi nh- ph-ơng pháp đảm bảo dự án tiến triển (hay không thụt lùi) Trong tr-ờng hợp xét dự án tr-ợt lùi

Kiểm tra cấu hình chủ yếu cho hạng mục phát triển kể mã, t-liệu hợp 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 quan trọng giai đoạn bảo trì để đảm bảo việc phát hành hệ thống đ-ợc gọi lại khuyết tật nghiêm trọng bị thay đợt phát hành tr-ớc

7.1.1 Thuật ngữ kiểm tra cấu hình.

Cú nhiu từ đ-ợc dùng liên quan đến kiểm tra cấu hình Chẳng may, khơng có sử dụng hay ý nghĩa chúng đ-ợc chuẩn hoá: nhiều từ khác đ-ợc sử dụng để mô tả chức năng; ý t-ởng Một cố gắng tốt nhằm tiêu chuẩn hóa có từ vựng IEEE thuật ngữ công nghệ phần mềm (IEEE 1987b) Dù sao, từ vựng phản ảnh thiếu sót lý giải sử dụng thống từ mà nhiều từ kiểm tra cấu hình xuất với vơ vàn định nghĩa Sau giải thích định nghĩa xác số thuật ngữ

H¹ng mục kiểm tra cấu hình phần mềm (SCCI) hạng mơc dù ¸n

phần mềm đ-ợc coi đơn vị cho mục đích kiểm tra cấu hình Điều bao gồm điều nh- mô đun phần mềm (1) phiên hệ thống phần mềm hay t- nliệu

Kiểm tra thay đổilà trình kiểm tra thay đổi Điều bao gồm

đề nghị thay đổi, đánh giá thay đổi, chấp nhận hay bác bỏ, lên lịch theo dõi thay đổi Kiểm tra phiên nh- vận dụng cho phát triển phần mềm, trình kiểm tra phát hành phiên phần mềm.25Điều bao gồm l-u giữ phòng ngừa đợt phát hành chứng minh t- liệu khác biệt đợt phát hành

Kiểm tra cấu hình trình đánh giá, chấp nhận hay bác bỏ,

quản lý thay đổi cho hạng mục cấu hình Kiểm tra cấu hình bao gồm chức kiểm tra phiờn bn

25 Nhiều giả thích từ hạng mục cấu hình không hạng mục cấp thấp nh- mô đun phần mềm.

Qun lý cấu hình ứng dụng kỹ thuật hành kiểm tra cấu hình Điều bao gồm việc trì tổ chức kiểm tra cấu hình, thay đổi tiêu chuẩn kiểm tra phiên ph-ơng tiện kiểm tra cấu hình

Các từ khác chỉ định nhận biết cấu hình đ-ợc sử dụng để nhận biết hạng mục cấu hình, ban kiểm tra cấu hình chấp nhận hay bác bỏ thay đổi cơng nghệ kiểm tốn cấu hình kiểm tra thích ứng với tiêu chuẩn kiểm tra cấu hình

Mục tiêu quản lý cấu hình đ-ợc xác định tốt khơng phải nh-những định nghĩa thức từ vựng IEEE nh-những thực nhờ giải thích có tính chất mơ tả nh- nêu lời nói đến tiêu chuẩn IEEE 828 (1987b) cho 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) ngành cơng nghệ thức cung cấp ph-ơng pháp cơng cụ cho nhà sản xuất sử dụng phần mềm biết phần mềm đ-ợc phát triển, lập đ-ờng mốc, thay đổi kiểm tra cho đ-ờng gốc đó, l-u giữ theo dõi tình hình kiểm tốn sản phẩm.

SCM ph-ơng tiện thơng qua hợp liên tục sản phẩm phần mềm đ-ợc l-u giữ, thông tin kiểm tra.

Một số nhiệm vụ quản lý cấu hình chồng chéo với nhiệm vụ hoạt động hỗ trợ khác, kiểm tra chất l-ợng phần mềm (bàn đến sau) Trong dự án phần mềm mà kiểm tra chất l-ợng kiểm tra cấu hình, nhóm riêng rẽ thực hiện, việc định nghĩa rõ phân chia trách nhiệm 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

Kiểm tra cấu hình lĩnh vực công nghệ phần mềm đ-ợc cơng nhận 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 kiểm tra thay đổi đ-ợc tự

C¬ cở liệu kiểm tra cấu

hình

Các máy tính đầu cuối phát triển dự án

động hóa vào đầu năm 1970 với cơng cụ nh- đóng mạch SCCS (coi Rochkind 1975)26 Một số cơng cụ dịch chuyển từ hệ vận hành UNIX nói chung đ-ợc sử dụng đến môi tr-ờng khác nh- MS-DOS VMS Digital

Nhiều hoạt động kiểm tra cấu hình dự tuyển tự nhiên cho cơng cụ tự động hóa CASE (Cơng nghệ phần mềm có hỗ trợ máy tính) nh- đ-ợc xác định rõ, có đơi chút lặp lại sẵn sàng hội nhập vào q trình phát triển Những cơng cụ đ-ợc dễ dùng giao diện với cơng cụ mã phần mềm (thí dụ biên tập viên s-u tập) xử lý từ để sản sinh t- liệu Kiểm tra cấu hình tự động tốt đ-ợc sử dụng môi tr-ờng phát triển nhiều ng-ời sử dụng nh- LAN với cách nhân tố đ-ợc kiểm tra l-u giữ sở liệu trung tâm việc truy nhập 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 địi hỏi tổ chức hiệu đ-ợc xác định rõ Mọi ph-ơng pháp kiểm tra cấu hình phải 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õ Phải sản xuất phân phối tiêu chuẩn kiểm tra cấu hình, thủ tục h-ớng dẫn kiểm tra cấu hình nhà sản xuất

3 Kiểm tra cấu hình có hiệu công cụ 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 khởi đầu dự án Đây trách nhiệm ng-ời quản lý dự án việc giao quyền quản lý cấu hình Điều tiến hành từ đội kiểm tra cấu hình dự án lớn đến kỹ s- kiểm tra cấu hình phần thời gian dự án nhỏ Trong hai tr-ờng hợp, quyền hạn 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 hoạt động phát triển phải có quyền hạn đặc thù 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 tiêu chuẩn kiểm tra cấu hình, thủ tục h-ớng dẫn phải dễ hiểu rõ ràng Điều giảm bớt số phản bác kiểm tra cấu hình khơng thích ứng với tiêu chuẩn khụng quen thuc

Môi tr-ờng quản lý cấu hình bao gồm cần thiết cho việc thực kế hoạch kiểm tra cấu hình Điều bao gồm:

- Công cụ kiểm tra cấu hình, kể cả:

+ Kiểm tra phiên tự động công cụ kiểm tra thay đổi + Giám sát, kiểm toán đăng ký tiện ích hỗ trợ

26 Sù tiến triển quản lý cấu hình đ-ợc mô tả thảo luận Ambriola cộng (1990)

- Ph-ơng tiện l-u giữ: kho chứa an toàn cho hạng mục cấu hình đ-ợc phê chn, kĨ c¶:

- L-u giữ chỗ cho q trình phát triển hàng ngày - L-u giữ ngồi phạm vi để phục hồi tai họa

7.1.3 KÕ hoạch quản lý cấu hình phần mềm.

K hoch quản lý cấu hình phần mềm (SCMP) phận kế hoạch phát triển phần mềm dự án SCMP xuất nh- t-liệu riêng biệt hay phần phạm vi kế hoạch phát triển dự án SCMP cung cấp dự liệu cho nguồn có nh- cầu, chúng đ-ợc sử dụng nh- nào, có tiêu chuẩn thủ tục đ-ợc vận dụng dự án Theo SCMP trở thành đ-ợc ủy nhiệm cho nhóm kiểm tra cấu hình phát triển dự án Việc đ-a kế hoạch trách nhiệm ng-ời quản lý dự án, dự án lớn đ-ợc phó thác cho ng-ời quản lý kiểm tra cấu hình

Bảng 7.1 Có danh mục đề tài nằm SCMP Nếu có đề tài đề tài nằm chỗ khác (thí dụ kế hoạch bảo hiểm chất l-ợng phần mềm) đề tài đ-ợc bỏ qua SCMP đ-ợc thay trỏ Trong t- liệu mà đáng phải Mặc dù phần lớn đề tài bảng 7.1 tự mô tả, sau 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 duyt)

- 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 định hạng mục phát triển nh- SCCI Đây phận phân giải hệ thống cấp cao thành thành phần páht triển chủ yếu (coi ch-ơng 6) Phần ph-ơng pháp nhận biết mô tả cách mà thành phần phát sinh, từ dự án đ-ợc đánh dấu nhận biết

 An toàn, truy nhập hạn chế phân loại nhằm phát triển an toàn sản phẩm nhạy cảm (nh- t- liệu phần mềm, phát minh, thông tin quân xếp hạng v.v ) Th-ờng thuận lợi ủy thác nhiều nhiệm vụ cho kiểm tra cấu hình nh- cầu phải tham gia vào việc duyệt phân loại t- liệu hoạt động khác liên quan gắn với an toàn

SCMP bao gồm sơ đồ biểu đồ để dịng chảy mơ tả thủ tục đệ trình yêu cầu thay đổi hay báo cáo vấn đề27

Hình 7.3 giới thiệu thí dụ 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 h.7.1)

B¶ng 7.1 ThÝ dơ nội dung kế hoạch quản lý cấu hình phần mềm.

1 Tổ chức nguồn quản lý cấu hình phần mềm - Cơ cấu tổ chức

- Khả trình độ kỹ nhân - Ngun

2 Tiêu chuẩn, thủ tục, sách h-íng dÉn NhËn biÕt cÊu h×nh

- Ph-ơng pháp xác định SCCI - Mô tả SCCI cho dự án

4 Ph-ơng pháp nhận biết (định danh đá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ỏ 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 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 ban xét duyệt

7 KiÓm tra phiên

- Chuẩn bị phiên phần mềm t- liệu - Thủ tục chấp nhận phát hành

8 L-u trữ, xử lý cung cấp 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 chủ thầu phụ, ng-ời bán 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 toàn v.v ) 11 Báo cáo tỡnh hỡnh cu hỡnh

- Kiểm toán 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 ph-ơng pháp luËn

7.1.4 Mét sè ®-êng lèi chung

H×nh 7.3

Thí dụ l-ợc đồ 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 chức 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 h-ớng dẫn bản, hồn tồn chấp nhận đ-ợc để gán cho quản lý cấu hình phạm vi dự án chuyên đề, hoạt động liên quan nh- phân bổ nguồn phát triển hay bố trí tổ chứ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ị đề xuất thay đổi kỹ thuật

Sáp nhập 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ỏ đề xuất 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

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 đ-ợc sản xuất,

Đòi hỏi

thay i phn mm

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ý 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 định: Chữ ký: Ngày:

H×nh 7.4

Thí dụ biểu u cầu thay đổi phần mềm

qu¶n lý dù ¸n vÉn lµ tranh chÊp vÜnh cưu vỊ c¸c tháa thn miƯng lý gi¶i sai hay hiĨu sai

Kiểm tra thay đổi yếu phổ biến việc gây nên tranh chấp khách hàng ng-ời sản xuất T-ơng tự nh- việc kiểm tra phiên yếu tai họa, đặc biệt khơng có hồ sơ dị biệt phiên

Hình 7.4 cho thí dụ mẫu u cầu thay đổi Mẫu 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ỏ cuối đến thực kiểm nghiệm (khi đ-ợc chấp nhận) Cần ghi nhớ nhu cầu chữ ký; mẫu l-u giữ điện tử - gốc có chữ ký phải đ-ợc l-u lại

Sau số h-ớng dẫn bổ sung để quản lý cấu hình hiệu Một số h-ớng dẫn đồng thời áp dụng đ-ợc cho chức 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 phải đ-ợc quản lý dự án giao cụ thể cho kỹ s- có trách nhiệm Bất kế hoạch quản lý cấu hình trở nên vơ nghĩa kế hoạch đ-ợc tôn trọng

Tốt nên tránh, có thể, việc c-ỡng tơn trọng kế hoạch, sách hay tiêu chuẩn Một đức tính ng-ời quản lý tốt khả vận dụng sách với c-ỡng tối thiểu Bất sách tiêu chuẩn sẵn sàng đ-ợc ng-ời sản xuất chấp nhận chúng đ-ợc tự nguyện tuân thủ có tr-ờng hợp bác bỏ vật liệu đệ trình Điều dẫn đến trình phát triển hiệu

- Quản lý cấu hình phải đ-ợc thực từ lúc khởi đầu dự án phần mềm Nhiều t- liệu thức đề xuất giai đoạn quan niệm ban đầu trọng yếu cho giai đoạn yêu cầu thiết kế phải đ-ợc đặt kiểm tra cấu hình

Việc vận dụng sớm quản lý cấu hình đặc biệt quan trọng mơ đen xốy ốc, lấy ngun mẫu nhanh hay ph-ơng pháp luận phát triển lặp lại Những tiếp cận phát triển khởi đầu tạo phiên sản phẩm Nhiều phiên khác trở thành ác mộng cơng nghệ khơng có kiểm tra cấu hình có trật tự

- Đôi số hoạt động kiểm tra cấu hình phần mềm chồng chéo với hoạt động bảo hiểm chất l-ợng phần mềm Trong dự án nhỏ, hai chức giao cho kỹ s- hỗ trợ hất Ngay dự án lớn, đơi chức nhóm hỗ trợ thực

triển tr-ớc dự án khác đ-ợc thấy thích hợp để hịa nhập vào dự án thơng th-ờng Trong tr-ờng hợp đó, lại có ý nghĩa việc sửa đổi sản phẩm hoàn chỉnh hoạt động nhằm cho đáp ứng với tiêu chuẩn hành dự kiến để làm trở thành sản phẩm hồn chỉnh 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 vận dụng cho hợp đồng phát triển sản phẩm Mặc dù phần mềm đ-ợc phát triển theo hợp đồng, chất l-ợng mối quan tâm khách hàng (và dự án cuối có khách hàng) Cơ quan tiêu chuẩn Anh (1986) khẳng định "chất l-ợng nằm mắt ng-ời xem, đề tài phán xử khách hàng"

Nếu có khó khăn việc tìm kiếm đ-ợc định nghĩa chấp nhận rộng rãi thuật ngữ kiểm tra cấu hình 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 thuật ngữ cơng nghệ phần mềm (IEEE 1987b) có khơng bốn định nghĩa riêng biệt chất l-ợng phần mềm28

1 Tồn khía cạnh đặc điểm sản phẩm phần mềm có khả đáp ứng nhu cầu đề ra: chẳng hạn thích hợp với đặc điểm kỹ thuật

2 Mức độ mà phần mềm có đ-ợc phối hợp mong muốn thuộc tính

3 Mức độ mà khách hàng hay ng-ời dùng nhận thức phần mềm đáp ứng đ-ợc kỳ vọng hợp thể họ

4 Các đặc điểm hợp thể phần mềm xác định mức độ mà phần mềm sử dụng đáp ứng đ-ợc kỳ vọng 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ả sản phẩm phần mềm để đáp ứng yêu cầu đặc dụng

Chất l-ợng phải đ-ợc đo theo nghĩa kỳ vọng khách hàng Dù sao, viễn cảnh khách hàng chủ quan Phần xét đến kiểm tra chất l-ợng theo viễn cảnh ng-ời quản lý dự án phải coi việc thực kiểm tra chất l-ợng q trình khách quan, mang tính hệ thống

7.2.1 Tạo phần mềm chất l-ợng.

Nh- chỳng ta thấy, vấn đề việc tạo phần mềm chất l-ợng khó khăn việc xác định mức độ chất l-ợng phần mềm Vì khơng có định nghĩa chấp nhận đ-ợc rộng rãi chất l-ợng ng-ời khác nhận thức chất

28tiêu chuẩn phát triển phần mềm, kể kiểm tra chất l-ợng phần mềm đ-ợc bàn đến chi tiết ở

l-ợng theo cách khác nên ng-ời sản xuất lần khách hàng phải đạt đ-ợc thỏa thuận có đo đếm chất l-ợng (điều đ-ợc bàn đến chi tiết sau này) Ph-ơng pháp đo l-ờng chất l-ợng khác dự án khác nhau.Vấn đề đ-ợc bàn đến tham luận Wesselius Ververs (1990) ông kết luận đạt đ-ợc tính khách quan trọn vẹn việc giám định chất l-ợng Họ nhận biết đ-ợc ba thành phần khác biệt chất l-ợng:

- Thành phần giám định đ-ợc 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 sản phẩm đánh giá đ-ợc khách quan đặc điểm sản phẩm, nh- nêu chi tiết yêu cầu, nhận biết đ-ợc

Chất l-ợng sản phẩm đánh giá đ-ợc chủ quan đặc điểm sản phẩm đáp ứng đ-ợc kỳ vọng khách hàng

Chất l-ợng sản phẩm khơng đánh giá đ-ợc tác động theo kỳ vọng tình không dự kiến

Wesselius Ververs gợi ý là, để chất l-ợng sản phẩm phần mềm đánh giá đ-ợc, nhiều đặc điểm tốt đ-ợc chuyển từ thành phần chủ quan không đánh giá đ-ợc thành phần đánh giá đ-ợc Cơ bản, điều có nghĩa chi tiết u cầu phải mơ tả nhiều đặc điểm đo đếm đ-ợc sản phẩm tốt

Thí nghiệm hỗ trợ kết luận Wesselius Ververs Những yêu cầu xác định tồi nguồn tranh chấp nhà sản xuất khách hàng Những yêu cầu xác định rõ, chi tiết đo đ-ợc giảm thiểu tranh chấp bất hòa phát triển sản phẩm 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 chi tiết yêu cầu giao sản phẩm (coi ch-ơng bàn chu kỳ phát triển phần mềm) Việc xác định chất l-ợng phải khơng đ-ợc trì hỗn đến phát triển trọn vẹn Việc kiểm tra chất l-ợng phần mềm có hiệu địi hỏi có đá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 đơi với chi tiết u cầu tốt rõ ràng tăng chất l-ợng sản phẩm cuối

Việc thiết lập kiểm tra chất l-ợng có hiệu th-ờng vấp phải nhiều quan niệm sai lệch huyền thuyết, phổ biến liên quan đến tính hiệu vốn đầu t- kiểm tra chất l-ợng Cobb Mills (1990) liệt kê nhiều huyền thuyết gợi ý ph-ơng pháp phá chúng Hai số nhiều huyền thuyết trội mà Cobb 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

Chất l-ợng tồi gieo rắc thất bại Có t-ơng quan tích cực thất bại chi phí chỗ lại tốn việc loại trừ thất bại thi công phần mềm thiết kế phần mềm để loại trừ thất bại thi cụng

Huyền thuyết: thất bại phần mềm không tránh khỏi Đây

trong nhng huyn thuyt tồi tệ điều khẳng định có phần thực 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 có rệp khác” khơng đ-ợc thông số thiết kế hay thực phần mềm

Khi huyền thuyết chỗ đứng tiếp cận đại với phát triển phần mềm yêu cầu tiêu chuẩn thủ tục thích hợp kiểm tra chất l-ợng lại gia tăng IEEE đ-a tiêu chuẩn họ cho kế hoạch bảo hiểm chất l-ợng phần mềm năm 1984 (IEEE 1984) 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 tiêu chuẩn riêng biệt 2168 cho ch-ơng tình chất l-ợng phần mềm hệ thống Quốc phòng (DOD 1988b) tạo thành đồng hành cho tiêu chuẩn tiếng US DOD 2167A (DOD 1988a) cho việc phát triển phần mềm hệ thống quốc phòng Tiêu chuẩn Châu Âu IS0 9000-3 năm 1990 (IS0 1990) đ-a ý nghĩa rộng cho từ bảo hiểm chất l-ợng bao gồm kiểm tra cấu hình

7.2.2 Ngn lùc kiĨm tra chÊt l-ỵng.

Khi ủy thác SQA bao gồm hoạt động kiểm tra cấu hình, nguồn yêu cầu bao gồm nguồn u cầu cho kiểm tra cấu hình Việc hịa đồng SQA kiểm tra cấu hình khơng phải khơng phổ biến loại trừ số ủy nhiệm 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ớ với dự án nhỏ, việc hòa đồng hai nhóm đơn giản có nghĩa phó thác hai nhiệm vụ cho ng-ời

Mặc dù nhiều công cụ phổ biến cho kiểm tra chất l-ợng kiểm tra cấu hình, có cơng cụ đ-ợc đặc biệt định cho kiểm tra chất l-ợng Sau số cơng cụ hỗ trợ chung có ích việc hỗ trợ hoạt động SQA:

- TiƯn Ých t- liƯu

- C«ng thiÕt kÕ phần mềm

- Hỗ trợ tìm sai (Ch-ơng trình gỡ rối) - Các xử lý tr-ớc đ-ợc cấu thành - Bộ so sánh hồ sơ

- Những phân tích cấu - Những kiểm toán tiêu chuẩn - Những mô

- Những giám sát thực - Những công cụ hợp chất CASE - Những kích thích thử nghiệm

- Những phát tr-ờng hợp thử nghiƯm

Những cơng cụ hỗ trợ kiểm tra chất l-ợng giai đoạn phát triển phần mềm Các hỗ trợ t- liệu cung cấp phần viết t- liệu tự động, kiểm tra tả s-u tập chuyên ngành (Thesaurus) v.v xử lý tr-ợc đ-ợc cấu thành (nh- tiện ích UNIX lint) có ích 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à biên dịch th-ờng bỏ qua Những cảnh báo sớm liên quan đến vấn đề thời gian thực đ-ợc mơ phỏng, phân tích thời gian thực giám sát thực cung cấp Thử nghiệm thấu đáo hệ thống phần mềm th-ờng đ-ợc tự động thực nhờ phát hệ thử nghiệm thực thử nghiệm tự động

H×nh 7.5

Kiểm tra cấu hình kiểm tra chất l-ợng phần mỊm

Mọi cơng cụ SQA sử dụng phát triển phần mềm phải đ-ợc nhận biết nguồn đảm chất l-ợng yêu cầu chi tiết nguồn đ-ợc vận dụng nh- Theo thế, vào lúc khởi đầu dự án, nguồn SQA

(a) Giám đốc dự án

Khống chế chất l-ợng phần mềm Giám đố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 phần mềm 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

có thể đ-ợc tài trợ cung cấp nh- phần 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), nh- kế hoạch cấu hình phần mềm, phận kế hoạch phát triển tổng thể dự án phần mềm SQAP cung cấp t- liệu mà nguồn cần, chúng phải đ-ợc sử dụng có tiêu chuẩn thủ tục đ-ợc vận dụng dự án Sau SQAP trở thành ủy thác cho nhóm bảo đảm chất l-ợng phát triển dự án Việc đề xuất kế hoạch trách nhiệm ng-ời quản lý dự án dự án lớn Việc th-ờng đ-ợc giao cho ng-ời quản lý bảo đảm chất l-ợng SQAP xuất nh- t- liệu riêng biệt hay phận kế hoạch phát triển dự án bao gồm kế hoạch quản lý cấu hình) việc không đ-ợc cung cấp t- liệu riêng biệt

Bảng 7.2 nêu danh mục chủ đề có SQAP29 Khi chủ đề đ-ợc đặt đâu khác nh- kế hoạch quản lý cấu hình phần mềm (SCMP) bỏ qua SQAP đ-ợc thay trỏ t- liệu Nói đ-ợc đặt Dù sao, SCMP SQAP đ-ợc quan tâm nhiều khía cạnh khác hạng mục đ-ợc kiểm tra SCMP lúc đầu đ-ợc quan tâm kích th-ớc hạng mục đ-ợc kiểm tra SQAP lại tham gia nhiều vào nội dung hạng mục đ-ợc kiểm tra

SQAP phải bao gồm chủ thầu phụ, ng-ời bán hàng ng-ời cung cấp, thực thể bên ngồi có hay khơng có tổ chức bảo đảm chất l-ợng chúng Trong dự án nào, chất l-ợng thành phần bên quan tâm ng-ời quản lý dự án tổ chức SQA Khi hệ thống thất bại thơng th-ờng có khác biệt thất bại thành phần phát triển bên hay thành phần phát triển nội Các kế hoạch giám định 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) loại tổ chức (liệu chúng có đ-ợc tổ chức bảo hiểm chất l-ợng chúng)

SQAP, coi nh- phận kế hoạch phát triển dự án, phải đ-ợc duyệt lại cập nhật định kỳ có yêu cầu thủ tục phát triển dự án, ph-ơng pháp luận hay hoạt động khác liên quan đ-ợc thay đổi H-ớng dẫn SQAP IEEE khuyên nên đánh giá định kỳ hai khía cạnh kế hoạch (1) nội dung kế hoạch (2) thực kế hoạch

Nội dung kế hoạch phải đ-ợc đánh giá 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 dù đặc điểm dự án phần mềm có thay đổi

29bảng 7.2 h-ớng dẫn khôngphải định nghĩa tiêu chuẩn Các tiêu chuẩn phát triển phần mềm

Bảng 7.2 Thí dụ nội dung kế hoạch bảo đảm chất l-ợng phần mềm (BCLPM).

1. Tổ chức nguồn lực BĐCLPM

C¬ cÊu tỉ chøc

Học vấn mức độ thạo nghề nhân

C¸c nguån lùc

2. Các chuẩn, thủ tục, sách, đ-ờng lối BĐCLPM

3. Các yêu cầu t- liệu BĐCLPM

Danh sách chủ đề t- liệu để khống chế chất l-ợng

Mô tả ph-ơng pháp đánh giá chp thun

4. Các yêu cầu phần mềm BĐCLPM

Đánh giá 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ý, phân phát

T- liệu dự án

Phần mềm

Các file liệu

6. Rà soát kiểm toán

7. Quản lý cấu hình phần mềm (khi không nhắm tới t- liệu chuyên biƯt nµo)

8. Báo cáo vấn đề khó khn v hnh ng chnh n

9. Đánh giá thủ tục thử nghiệm

10. Công cụ, kỹ thuật ph-ơng pháp

11. Khống chế chất l-ợng chủ thầu phụ, ng-ời bán hàng 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 t- liệu BĐCLPM

Thủ tục báo cáo tình trạng

Bảo trì

L-u trữ an ninh

Chu kú së h÷u

- Yêu cầu hay thay đổi hợp đồng - Tiêu chuẩn sách bổ sung

- Tµi liƯu dù ¸n bæ sung

- Thay đổi cấu tổ chức dự án - Công cụ tiện ớch mi

- Chủ thầu phụ ng-ời bán bổ sung

7.2.4 Độ đo chất l-ợng phần mềm.

Đã có nhiều quan tâm đến câu hỏi liên quan đến việc đo l-ờng chất l-ợng Làm xác định mức độ mà sản phẩn phần mềm có đ-ợc thuộc tính mơ hồ gọi chất l-ợng? Khi chất l-ợng sản phẩm phần mềm cao thấp?

Một phát triển việc bảo hiểm chất l-ợng (không phần mềm) việc thấy chất l-ợng thuộc tính nhị phân tồn hay khơng tồn Kaposi Meyer (1990), tham luận bảo đảm chất l-ợng sở đo đếm, nói lên niềm tin họ bảo đảm chất l-ợng sản phẩm qui trình cơng nghệ phần mềm phải đo đếm Việc đo đếm chất l-ợng sớm bắt đầu, vấn đề sớm xác định Cohen cộng (1986) nói đến kinh phí khắc phục sai lầm giai đoạn đầu phát triển phần mềm đề x-ớng tồn luật lũy thừa tiếng30

Chất l-ợng hai sản phẩm so sánh đ-ợc thực hồn tồn chấp nhận đ-ợc nói chất l-ợng sản phẩm lớn chất l-ợng sản phẩm Cũng chấp nhận đ-ợc việc đo đếm suy mức độ khuyết tật dự kiến kết đo đ-ợc

Bộ trị số đo đ-ợc liên quan đến chất l-ợng sản phẩm đ-ợc coi độ đo chất l-ợng sản phẩm, độ đo chất l-ợng phần mềm đ-ợ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 việc đánh giá chất l-ợng sản phẩm Việc đánh giá chất l-ợng ng-ời chủ quan nguồn gốc bất đồng có, đặc biệt khách hàng 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 ch-a có tiêu chuẩn nói chung chấp nhận đ-ợc, chẳng hạn, dự thảo ban đầu IEEE Std 1061 (1990) bao gồm chi tiết hệ chất l-ợng phần mềm nói chung kể ph-ơng pháp luận gợi ý độ đo vận dụng nhiều thí dụ h-ớng dẫn Một đ-ợc xác định, độ đo chất l-ợng gia tăng tính khách quan nh-ng thân định nghĩa lại không cần thiết khách quan tùy thuộc lớn nhu cầu tổ chức đ-a định nghĩa

Cách tiếp cậ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 phát phát triển phần mềm diễn tiến dọc chu kỳ

- Nhận biết thuộc tính chất l-ợng phần mềm yêu cầu Điều th-ờng xuất phát từ đặc điểm yêu cầu phần mềm

- Xác định trị số đo đ-ợc gắn với thuộc tính chất l-ợng - Mơ tả ph-ơng pháp mà trị số đo đ-ợc đ-ợc đo đếm

- Thđ tơc cung cÊp t- liƯu kết đo chất l-ợng sản phẩm phần mỊm

Một nhiều trị số đ-ợc sử dụng để xác định chất l-ợng tổng thể sản phẩm phần mềm Dù sao, tạo lần đo biểu thị chất l-ợng tổng thể sản phẩm phần mềm Điều đòi hỏi:

- Ph-ơng pháp có cân nhắc việc kết hợp thuộc tính chất l-ợng đo đ-ợc thành lần đo chất l-ợng cho sản phẩm

Một số thí dụ độ đ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 (thí dụ 23 24 giê t¹o 100 x (23/24)%)

Độ phục hồi đ-ợc l-ợng thời gian mà hệ cần có để phục hồi sau thất bại (thí dụ để nạp lại từ dự trữ 30 phút để tái lập ban u h thng)

Thân hữu ng-ời dùng l-ợng thời gian huấn luyện cần cho ng-ời dùng

Việc đo chất l-ợng phần mềm không đ-ợc thực vào cuối dự án Mức độ chất l-ợng phải đ-ợc thực vào cuối dự án Mức độ chất l-ợng phải đ-ợc đo với khoảng cách đặn phát triển Do đó, rút giảm việc đo chất l-ợng tổng thể phải đ-ợc coi nh-cảnh báo cho 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 đảm bảo chất l-ợng cao xuyên suốt phát triển 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 bao gồm việc duyệt phê chuẩn ph-ơng pháp luận phát triển, phần mềm t- liệu giám định 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 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ô dự án th-ờng yếu tố định Những h-ớng dẫn sau bàn đến số thông số cần xem xét cho loại dự án khác lập kế hoạch SQA

- Trong dự án nhỏ, có nhiều hoạt động SQA ng-ời quản lý dự án thực Điều bao gồm tổ chức giám định duyệt lại kiểm toán, đánh giá lựa chọn công cụ phát triển, lựa chọn vận dụng tiêu chuẩn

các hoạt động thử nghiệm đ-ợc ủy thác cho SQA tùy thuộc nhiều yếu tố, kể độc lập đội SQA, qui mô dự án tính phức tạp dự án (coi ch-ơng bàn tính phức tạp 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 SQA tối thiểu Trong hầu hết tr-ờng hợp khác, trách nhiệm đội SQA lập kế hoạch giám định thử nghiệm hệ thống

- Về h-ớng dẫn chung, th-ờng không nên để thành viên đội phát triển thực SQA Dù sao, dự án nhỏ th-ờng xác minh chi phí kỹ s- đ-ợc bố trí SQA Vấn đề đ-ợc giải có kỹ s- SQA chịu trách nhiệm cho hai hay ba dự án nhỏ (với dự án tài trợ phần đóng góp dịch vụ SQA)

Một h-ớng dẫn bổ sung đ-ợc kết luận Wesselius Ververs (1990) việc vận dụng kiểm tra chất l-ợng có hiệu

- Khả kiểm tra chất l-ợng phần mềm hiệu trực tiếp với chất l-ợng đặc điểm yêu cầu phần mềm Kiểm tra chất l-ợng đòi hỏi chi tiết không mơ hồ nhiều đặc điểm yêu cầu chất l-ợng phần mềm tốt

7.3 Thư nghiƯm phÇn mỊm.

Từ thử nghiệm có nhiều nghĩa nh-ng sử dụng thơng th-ờng từ đ-ợc vận dụng vào việc xem xét đánh giá nhằm xác định tồn số đặc tính Trong thử nghiệm phần mềm, đặc tính gắn với u cầu Xác định tr-ớc phần mềm Thử nghiệm phần mềm q trình xác định mức độ theo phần mềm thỏa mãn 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 thử nghiệm, đ-ợc tiến hành

Nói cách đơn giản, thử nghiệm phần mềm với đầy đủ ý nghĩa phần mềm đ-ợc dự kiến làm

Thử nghiệm ng-ời lập trình, kỹ s- hợp hay nhóm thử nghiệm độc lập thực Trong hầu hết tr-ờng hợp, phần mềm không 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 Ng-ời lập trình lại khách quan đ-ợc với mã thử nghiệm khơng hiệu lực Có nhiều cách để tăng tính khách quan thử nghiệm Cách tốt sử dụng nhóm thử nghiệm độc lập Những ng-ời thử nghiệm độc lập kỹ s- mà ủy thác họ phát triển kế hoạch thử nghiệm tr-ờng hợp thử nghiệm thử nghiệm hệ thống cách khách quan 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.

án Phần mềm phải đ-ợc thử nghiệm.ở giai đoạn phát triển Các thử nghiệm phần mềm bao gồm:

- Thử nghiệm đơn vị - Thử nghiệm hợp - 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 thử nghiệm mô đun phần mềm sau đ-ợc mã hóa Đây số tr-ờng hợp mà nhà lập trình thử nghiệm mã họ Những thử nghiệm mơ đun ban đầu, gọi 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 yêu cầu tối thiểu Chúng bao gồm thử nghiệm nh-:

- NhËp xuất (không có vòng vĩnh cửu) cho nhỏ liệu đầu vào

- Với đầu vào cho, đầu hợp lý

- Những ch-ơng trình phụ đ-ợc gọi theo trình tự Điều đ-ợc thử nghiệm sử dụng ngạch (vỏ hệ thống phụ rỗng)

Sau thử nghiệm đơn vị thành công, mô đun đ-ợc đệ trình kiểm tra cấu hình Sau đó, chúng đ-ợc đ-a vào hợp nơi chúng đ-ợc tập hợp thử nghiệm coi nh- phận mô đun vào hệ thống Mọi tính chức bổ sung đ-ợc thử nghiệm, giai đoạn này, tính chức thử nghiệm tr-ớc lại phải đ-ợc thử nghiệm đảm bảo khơng có mơ đun phá hủy hệ thống Điều đ-ợc coi thử nghiệm suy thoái

ở hệ thống phần mềm lớn, mơ đun tr-ớc hết đ-ợc tập hợp hợp với phần cứng thành hệ thống phụ Sau hệ thống phụ đ-ợc thử nghiệm riêng rẽ, chúng đ-ợc phối hợp thành hệ thống hoàn chỉnh

Các giai đoạn cuối thử nghiệm hệ thống đ-ợc biểu thị thí dụ sau hệ thống thủ quỹ ngân hàng tự động đ-ợc phát triển cho ngân hàng lớn Khi hệ thống phụ thủ quỹ hồn chỉnh, tiến hành thử nghiệm hệ thống phụ để đảm bảo 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 liệu thử nghiệm đảm bảo hệ tiến hành liệu Cuối hệ thống phụ thông tin liên lạc đ-ợc thử nghiệm với thủ quỹ mô đầu với máy tính trung tâm mơ đầu

Rồi ba hệ thống phụ đ-ợc hợp việc thử nghiệm toàn hệ thống đ-ợc tiến hành đảm bảo thủ quỹ tự động máy tính trung tâm liên lạc hoạt động tốt

Sau thử nghiệm hệ thống, hệ thống thủ quỹ tự động hợp hồn tồn đ-ợc thử nghiệm mơi tr-ờng thử nghiệm alpha Hệ thống đ-ợc thử nghiệm với liệu thử nghiệm thực tiễn hoạt động chi tiết đ-ợc xem xét so sánh với yêu cầu hệ thống nhiệm vụ đ-ợc giao cho nhóm thử nghiệm độc lập

Sau hệ thống thủ quỹ tự động qua thử nghiệm alpha, đủ tin cậy để tiến hành liệu thực Đây thử nghiệm bêta Dù sao, trạm thủ quỹ tự động đ-ợc đấu với máy tính ngân hàng vận hành hệ thống th-ờng xuyên đ-ợc thành viên đội phát triển giám sát Mọi vấn đề đ-ợc định vị hiệu chỉnh thử nghiệm bêta tiếp tục đến hệ thống thủ quỹ hoạt động không sai không hỏng thời gian xác định tr-ớc (thí dụ tháng) Việc giám định giai đoạn bêta đ-ợc ủy thác cho nhóm thử nghiệm độc lập

Sau thực 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ác đại diện máy kỹ thuật ngân hàng giám định thử nghiệm đ-ợc xác định tr-ớc xác định hay bác bỏ thành công thử nghiệm nghiệm thu

Theo thế, hệ thống thủ quỹ ngân hàng tự động qua giai đoạn thử nghiệm chủ yếu Không phải tất giai đoạn vận dụng đ-ợc cho dự án Chẳng hạn, thử nghiệm alpha bêta vận dụng cho hệ thống th-ơng mại hay h-ớng ng-ời dùng nh-ng không cho phát triển phần mềm cho vệ tinh thông tin liên lạc hay ứng dụng quân Một thí dụ khác thử nghiệm hệ thống phụ rõ ràng áp dụng đ-ợc hệ thống đ-ợc phân thành hệ thống phụ

Trong tr-ờng hợp, thử nghiệm độc lập đ-ợc khuyên dùng cho giai đoạn thử nghiệm tiên tiến (từ thử nghiệm hệ thống trở đi) Thử nghiệm độc lập khách quan th-ờng định vị Vấn đề sớm thử nghiệm độc lập mà nhà sản xuất tiến hành nhiều Đây lợi ích chủ yếu cho dự án vấn đề đ-ợc định vị sớm lại tốn việc hiệu chỉnh

Cã nhiều tiếp cận thủ tục khác cho giai đoạn thử nghiệm phần mềm Điều quan trọng chọn lựa tiếp cận thích hợp cho giai đoạn Các tiêu chuẩn thử nghiệm phần mềm thức31 bao gồm h-ớng dẫn tiêu chuẩn đ-ợc vận dụng cho giai đoạn

Tiờu chun 2167 US (DOD 1988a) liên quan đến giai đoạn sau:

1 Thử nghiệm đơn vị phần mềm máy tính (CSU)

2 Thử nghiệm cấu kiện phần mềm máy tính (CSC) Liên quan đến việc thử nghiệm 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 giai đoạn tiên tiến thử nghiệm hợp hệ thống nhỏ, điều t-ơng ứng với thử nghiệm hệ thống, hệ thống lớn có nhiều CSCI, điều t-ơng ứng víi thư nghiƯm hƯ thèng phơ

4 Hỵp nhÊt thử nghiệm hệ thống Điều 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ả yêu cầu đánh giá thử nghiệm Điều bao gồm tiêu chí nh- tính qn nội bộ, tính thơng hiểu, tính theo dõi đ-ợc qua dấu vết đáp ứng yêu cầu Sau tiêu chí đ-ợc đề cho hạng mục phải đánh giá nh- mã nguồn (và sau mã nguồn cập nhật), thủ tục kết thử nghiệm

Thđ tơc thư nghiƯm đ-ợ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 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ần thử nghiệm phải đ-ợc tiến hành nh- nào, đầu vào đầu dự kiến phải Điều mơ tả tiêu chí thơng qua khơng đạt cho thử nghim

Các báo cáo thử nghiệm thông tin t- liệu tiến hành thử nghiệm kết nhận đ-ợc

Núi chung, mi th tc th nghim phần mềm thức đ-ợc thành phần: qui hoạch thử nghiệm, mô tả thử nghiệm, tiến hành thử nghiệm báo cáo thử nghiệm Hầu hết tiêu chuẩn thử nghiệm hỗ trợ yếu tố khác mức độ chi tiết thơng tin t- liệu yêu cầu

Tiêu chuẩn IEEE 829 (1987b) thông tin t- liệu thử nghiệm phần mềm có mơ tả chi tiết nhiều tiếp cận nên làm thử nghiệm phần mềm, kể thí dụ 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 ph-ơng pháp luận phát triển

cũng bao gồm ba cấu kiện 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) báo cáo tình hình thử nghiệm (t-ơng tự báo cáo thử nghệm DOD) Coi hình 8.5 8.6 tổng thể hoạt động thử nghiệm t- liệu 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 tiêu chuẩn vận dụng xác định Ph-ơng pháp kỹ thuật thử nghiệm phải thích nghi với loại dự án đ-ợc phát triển môi tr-ờng dự án cơng cụ có đ-ợc Cộng thêm với lập kế hoạch báo cáo thử nghiệm, trách nhiệm kỹ s- thử nghiệm (hay nhóm thử nghiệm) lựa chọn kỹ thuật thích hợp đ-ợc sử dụng thử nghiệm hệ thống phần mềm Thử nghiệm đặc tr-ng kỹ thuật hợp đ-ợc bàn đến ch-ơng

7.3.3 Mét sè ®-êng lèi chung

Trong dự án phần mềm có giới hạn phải thử nghiệm Nhiều thủ tục thử nghiệm phức tạp tốn cách không hợp lý Điều quan trọng phù hợp c-ờng độ thử nghiệm với chi phí khuyết tật hệ thống không phát Hệ thống kiểm kê không cần phải thử nghiệm mức độ nh- phần mềm hệ thống hỗ trợ công tác y tế

Thử nghiệm mức 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ụ giám sát viên trực tuyến, tiện ích dấu vết v.v ) hay sử dụng thiết bị thử nghiệm đặc biệt Điều có nghĩa hệ thống đ-ợc thử nghiệm hệ thống đ-ợc bàn giao

Một cách nhìn thú vị vấn đề đ-ợc Laplante trình bày (1990) báo liên hệ nguyên lý bất định (th-ờng áp dụng cho vật lý) Heisenberg vào việc thử nghiệm phần mềm32 Thuyết Laplante khẳng định hệ thống phần mềm đ-ợc xem xét chặt chẽ trình xem xét tác động đến hệ thống đ-ợc thử nghiệm Lý thuyết gợi ý khơng trung thực nh-ng làm sáng tỏ thông điệp bản:

Thử nghiệm mức có hại cho hệ thống đ-ợc thử ba yêu cầu 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

Nhng yờu cầu tốt đ-ợc thảo luận ch-ơng nh-ng điều kiện để có đ-ợc yêu cầu tốt phải thử nghiệm 32 Laplante gợi ý cơng thức sauzs = H đós biểu thị bất trắc mã phần mềm.s sự

đ-ợc Do yêu cầu thức ln phải đ-ợc viết với ý nghĩ thử nghiệm trí Đặc điểm có u cầu khơng thể thử nghiệm tỏ tồn đ-ợc phải khơng có chỗ đứng chi tiết yêu cầu thức cho dự án

Những thủ tục chúng phải đ-ợc dựa tiếp cận gọi thử nghiệm tiêu cực Điều có nghĩa mục tiêu nhóm thử nghiệm chứng minh 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 đắn 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ự) cuối ng-ời dùng tính đâu

Nh- thấy, thử nghiệm đ-ợc tiến hành tốt có nhóm thử nghiệm độc lập, khách quan, dù có dự án lớn hỗ trợ nhóm thử nghiệm độc lập Những dự án lớn hỗ trợ nhóm thử nghiệm độc lập Những dự án nhỏ chia xẻ dịch vụ nhóm thử nghiệm độc lập chí th kỹ s- phát triển để thử nghiệm Theo thế, kỹ s- phát triển dự án ng-ời thử nghiệm khách quan kiêm nhiệm dự án khác

Cuối cùng, thử nghiệm phải đ-ợc dẫn t- liệu đầy đủ Một loại thử nghiệm tồi tệ thử nghiệm thất bại chẳng thể lặp lại Nếu thất bại sẵn sàng lặp lại th-ờng khơng đ-ợc hiệu chỉnh Do t- liệu thử nghiệm phải đủ để ng-ời sản xuất lặp lại phầ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 giảm nhẹ công việc hỗ trợ cho ng-ời quản lý dự án kỹ s- phát triển, mà thực cơngviệc tốt tập trung cố gắng h ọ vào chức hỗ trợ đặc tr-ng Có nhiều loại chức hỗ trợ dự án Dịch vụ th- ký, hỗ trợ hành chính, xuất cung cấp t- liệu 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 bảo đảm chất l-ợng thí tụ chức hỗ trợ kỹ thuật Ba chức cần có dự án phát triển phần mềm 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 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 thức sản phẩm

Kế hoạch quản lý cấu hình phần mềm (SCMP) kế hoạch bảo đảm chất l-ợng phần mềm (SQAP) cung cấp t- liệu nguồn cần cho

33điều nhấn mạnh điểm - đơn giản, rõ ràng, có nhiều yếu tố khác đóng góp vào sự

nhóm hỗ trợ, sử dụng nguồn có tiêu chuẩn thủ tục đ-ợc vận dụng dự án SCMP SQAP trở thành ủy nhiệm cho hai nhóm phát triển dự án Thử nghiệm phần mềm trình xác định mức độ mà phần mềm thỏa mãn đ-ợc yêu cầu cụ thể Những thủ tục thử nghiệm đ-ợc chuẩn bị nhằm chứng minh yêu cầu đ-ợc hồn tất (hay khơng hồn tất) Do đó, chúng cần đ-ợc dựa tiếp cận gọi thử nghiệm tiêu cực Điều có nghĩa mục tiêu nhóm thử nghiệm chứng tỏ 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 đắn, ng-ời thử nghiệm thất bại, dự án thành cơng

Những nhóm thử nghiệm độc lập ng-ời thử nghiệm hệ thống phần mềm đ-ợc chuộng Việc thử nghiệm độc lập khách quan th-ờng định vị đ-ợc vấn đề sớm thử nghiệm chủ quan ng-ời sản xuất thực Đây lợi ích chủ yếu cho dự án vấn đề sớm đ-ợc định vị tốn việc hiệu chỉnh

Đây trách nhiệm ng-ời quản lý dự án việc tổ chức nhóm hỗ trợ dự án dẫn t- liệu hoạt động theo kế hoạch họ ch-ơng trình phát triển dự án (bao gồm SCMP SQAP) Các chức hỗ trợ dự án đ-ợc lập kế hoạch tốt lúc khởi đầu dự án đóng góp cho việc quản lý dự án có hiệu xuyên suốt dự án

Bµi tËp.

1 Bạn đ-ợc định làm quản lý dự án phát triển hệ thống kiểm kê cho công ty sản xuất lớn Hệ thống kiểm kê cần phát triển đ-ợc ph-ơng pháp đặt hàng sS (khi mức kiểm kê cho hạng mục tụt xuống d-ới s l-ợng đ-ợc đặt nâng mức lên S: hạng mục có trị só sS ca nú

Gợi ý bốn phiên trung gian hệ thống đ-ợc phát hành nội cho viƯc thư nghiƯm hƯ thèng Thư nghiƯm alpha, thư nghiƯm bêta phát hành cuối Hỏi chênh lệch chức phiên gì? Mô tả thủ tục kiểm tra phiên đ-ợc dùng gợi ý mẫu mô tả phiên

2 L ng-i quản lý dự án, bạn xác định tổ chức quản lý cấu hình bảo đảm chất l-ợng cho hệ thống kiểm kê mô tả tập 1, có ng-ời đ-ợc yêu cầu làm nhiệm vụ trách nhiệm ng-ời sao? Giải thích định bạn

4 Lập kế hoạch giai đoạn thử nghiệm cho việc phát hành hệ thống kiểm kê mô tả tập Có giai đoạn thử nghiệm mà bạn gợi ý sau giai đoạn hợp nhất? Viết ch-ơng kế hoạch thử nghiệm mô tả giai đoạn thử nghiệm Có yêu cầu nguồn liệu thử nghiệm nào? ủy thác ng-ời thử nghiệm cho giai đoạn

5 Hãy xác định năm thuộc tính chất l-ợng chủ yếu hệ thống kiểm kê mô tả tập xác định độ đo chất l-ợng cho thuộc tính Giải thích lý độ đo mà bạn xác định

6 Sử dụng mẫu u cầu thay đổi mơ tả hình 7.4, điền đề mục vào mẫu cho thay đổi sau (1) đặc điểm giám sát đơn đặt đ-ợc bổ sung cho hạng mục d-ới mức (2) mức sS cho hạng mục đ-ợc bổ sung vào báo cáo kiểm kê (3) yêu cầu trả lời giây cho vấn đề kiểm kê đ-ợc giãn tới 20 giây (4) công suất yêu cầu sở liệu đ-ợc tăng từ 2000 tới 5000 hạng mục Giải thích vấn đề nhận định liên quan tới mẫu

7 Bài học lớp: chia lớp thành nhóm Giao tập cho nhóm Thảo luận chênh lệch cách nhóm điền mẫu u cầu thay đổi (thí dụ thảo luận khác biệt dự toán)

Ch-ơng tám

Các tiêu chuẩn phát triển phần mÒm

Các tiêu chuẩn phát triển: tai hại cần thiết Với nhiều kỹ s- phần mềm, có mâu thuẫn phát triển phần mềm tiêu chuẩn Các tiêu chuẩn giới hạn phần lớn tự ng-ời sản xuất phần mềm, tất nhiên, tiêu chuẩn đ-ợc làm với mục đích nh-thế Các tiêu chuẩn kèm theo chu kỳ phát triển từ đầu đến cuối có 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, chí tiêu chuẩn đệ trình đánh giá đề nghị (coi ch-ơng 3)

Mặc dù tiêu chuẩn đ-ợc coi nỗi buồn cần thiết, việc vận dụng tiêu chuẩn đạt đ-ợc kết xứng đáng; điều làm cho việc phát triển phần mềm dễ quản lý đ-ợc Điều khơng có nghĩa có ng-ời quản lý có lợi việc sử dụng tiêu chuẩn Các tiêu chuẩn thúc đẩy mức độ ngăn nắp thích nghi, giúp ng-ời sản xuất hiểu đ-ợc cơng việc ng-ời khác làm khuyến khích họ tạo công việc mà ng-ời khác hiểu đ-ợc

Một thách đố chủ yếu cho ng-ời quản lý dự án việc lựa chọn tiêu chuẩn Trong nhiều tr-ờng hợp chuẩn phát triển đ-ợc đặc tả nh- yêu cầu, nh- th-ờng xẩy với dự án phủ Dù sao, tiêu chuẩn đặc thù đ-ợc yêu cầu, phải đ-ợc “may đo” phù hợp với yêu cầu dự án đ-ợc phát triển Một số phần tiêu chuẩn bị "loại" chúng khơng vận dụng đ-ợc ví nh- phân tích thời gian theo thiết kế hệ thống không nghiêm ngặt thời gian hay việc đ-a tiêu chuẩn lập mã cho mã ch-ơng trình đ-ợc tái sử dụng

Ch-ơng cung cấp cho ng-ời quản lý dự án thông tin lựa chọn tiêu chuẩn phát triển phần mềm thích hợp Ch-ơng bàn đến loại tiêu chuẩn phần mềm mơ tả uy tín hai tiêu chuẩn phổ biến nhất: tiêu chuẩn công nghệ phần mềm IEEE tiêu chuẩn 2167A Bộ Quốc phòng Hoa K

8.1 Tổng quan tiêu chuẩn phát triển phần mềm.

T tiờu chun ó -c ứng dụng rộng rãi cho nhiều loại đ-ờng lối Một số tiêu chuẩn 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 hoạt động nh- định luật nghiêm ngặt đạo khía cạnh hoạt động phát triển Hình 8.1 mơ tả tiêu chuẩn phát triển phần mềm t-ơng quan tiêu chuẩn Một tiêu chuẩn phát triển

Hình

Các chuẩn phát triển phần mềm chñ yÕu.

phần mềm dễ hiểu tiêu chuẩn US DOD 2167 (DOD 1988a) Việc đề tiêu chuẩn tuyên bố lập yêu cầu thống cho phát triển phần mềm vận dụng đ-ợc xuyên suốt chu kỳ đời hệ thống tiêu chuẩn không nhằm nhấn mạnh hay khuyến bác việc sử dụng

Đị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 chn 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×

ph-ơng pháp phát triển phần mềm đặc biệt Dù sao, tiêu chuẩn 2167 nặng nghiêng ph-ơng pháp luận phát triển theo pha nh- hệ biến hóa thác n-ớc Overmyer (1990) phân tích lý thú tiêu chuẩn, báo cáo nhiều nhà nghiên cứu phát triển thành công mô hình phù hợp với tiêu chuẩn đ-a quan niệm yêu cầu thiết kế lặp lại, ông kết luận 2167 không đ-ợc phát triển với thiết kế lặp lại từ

Với tìm kiếm tiêu chuẩn đòi hỏi tiêu chuẩn 2167, tiêu chuẩn phát triển phần mềm IEEE đ-a tiếp cận t-ơng tự mềm dẻo nhiều Nhiều tiêu chuẩn IEEE tựa nh- h-ớng dẫn tiêu chuẩn cứng nhắc

Các tiêu chuẩn dễ xác định vận dụng cho hoạt động phát triển dẫn t- liệu lập mã) cho qui trình phát triển (nh-thiết kế, thử nghiệm hợp nhất) Buckley nhập mơn phiên sớm sủa34 tiêu chuẩn công nghệ phần mềm IEEE giải thích ý định IEEE từ tiêu chuẩn sản phẩm (thí dụ t- liệu) đến tiêu chuẩn trình Trên thực tế, định nghĩa tiêu chuẩn cho trình thử nghiệm phần mềm trình, đ-ợc tiêu chuẩn IEEE đề cập Điều phản ánh bành tr-ớng phạm vi tiêu chuẩn

Buckley trông đợi tiêu chuẩn t-ơng lai đáp ứng đ-ợc lĩnh vực nh- hệ mét suất phần mềm Nh-ng có số điều dễ tiêu chuẩn hóa điều khác đề tài hệ mét suất đề tài khó Zimmer (1991) khẳng định vơi định nghĩa "năng suất" khơng có tiêu chuẩn, khó mà biết đ-ợc phải đo gì, lại có khả đo đ-ợc

Thử nghiệm phần mềm lĩnh vực có nhiều tiêu chuẩn đ-ợc tạo Điều thiết kế phần mềm có nhấn mạnh nhiều đến cấu trúc dẫn t- liệu thiết kế Việc hợp phần mềm kết thúc thuận lợi tr-ớc hết có khó khăn việc tiêu chuẩn hóa nh- hoạt động loại bỏ trực giác

Thử nghiệm không lĩnh vực đ-ợc tiêu chuẩn hóa rộng Thật ngạc nhiên thấy việc tạo lập tiêu chuẩn cho hoạt động phát triển phần mềm định lại phồn thịnh năm gần đây, cụ thể cho việc kiểm tra chất l-ợng phần mềm Khó khăn việc định nghĩa chất l-ợng phần mềmđ-ợc minh họa từ vựng tiêu chuẩn IEEE thuật ngữ cơng nghệ phần mềm (IEEE 1987b) có khơng d-ới định nghĩa riêng biệt:

1 Toàn nét đặc điểm sản phẩm phần mềm có khả đáp ứng yêu cầu đề ra, chẳng hạn phù hợp với đặc tả Mức độ mà phần mềm có đ-ợc phối hợp mong muốn thuộc tính

3 Mức độ mà khách hàng hay ng-ời dùng nhận thức đ-ợc phần mềm đáp ứng đ-ợc kỳ vọng phức hợp

4 Đặc điểm phức hợp phần mềm xác định mức độ mà phần mềm sử dụng đáp ứng kỳ vọng khách hàng

Chất l-ợng phần mềm đ-ợc US DOD35định nghĩa lại đơn giản là: Khả sản phẩm phần mềm đáp ứng đ-ợc yêu cầu đặc thù

Trong định nghĩa tối nghĩa định nghĩa 3; chủ quan gợi ý chất l-ợng, giống nh- đẹp, mắt ng-ời quan sát

Chất l-ợng phần mềm khơng từ có định nghĩa khơng phải chung nhất, điều từ nh- yêu cầu, thiết kế bảo trì Cách mà từ đ-ợc sử dụng tiêu chuẩn khác lại thay đổi Điều th-ờng gây lẫn lộn từ có nghĩa điều khác cho ng-ời khác

Có nhiều lý tiêu chuẩn lại khơng tiêu chuẩn tính chủ quan lại lý Các dự án phần mềm thay đổi dữ, nhu cầu khách hàng thay đổi nhiều tổ chức phát triển phần mềm thay đổi lớn Do không ngạc nhiên Bộ Quốc phịng Hoa Kỳ cơng nhận dự án 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 dự án

Nhiều tiêu chuẩn phát triển phần mềm đ-ợc tạo lập đáp ứng hoạt động nh- đánh giá đề nghị (coi ch-ơng 3), rà sốt lại, kỹ thuật kiểm tra cấu hình Giờ tiêu chuẩn tồn 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 thỏa mãn đ-ợc vận dụng Các tiêu chuẩn đòi hỏi kỷ luật vốn luôn dễ dàng buộc công nghệ phần mềm

8 Tiªu chuÈn US DOD 2167.

Tiêu chuẩn 2167 đ-ợc Bộ Quốc phòng Hoa Kỳ tọa lập cho phát triển hệ thống phần mềm quốc phòng sứ mệnh khẩn tr-ơng Sau công bố nhiều dự thảo phiên ban đầu tiêu chuẩn đ-ợc đề xuất năm 1985 thay tiêu chuẩn Hải quân 1679A vốn sử dụng rộng rãi tiêu chuẩn 1644B MIL ý định năm 2167 trở thành tiêu chuẩn thức cho việc phát triển phần mềm hệ thống quốc phòng cho quân Hoa Kỳ

Phiên đầu tiêu chuẩn 2167 thu hút nhiều bình luận nhà thầu phần mềm DOD nội Bộ Quốc phịng Điều dẫn đến việc cơng bố tiêu chuẩn DOD 2167A sửa đổi năm 1988 với

35 Định nghĩa US DOD chất l-ợng phần mềm xuất tiêu chuẩn DOD 2168 Ch-ơng

tiêu chuẩn kèm theo 499 cho việc quản lý công nghệ 2167 cho việc bảo đảm chất l-ợng phần mềm

8 Tæng quan tiªu chuÈn 2167.

Mục tiêu đ-ợc ấn định tiêu chuẩn DOD 2167 (DOD 1988a) thiết lập yêu cầu thống cho việc phát triển phần mềm áp dụng đ-ợc suốt chu kỳ đời dự án Tiêu chuẩn bao gồm việc vận dụng tiêu chuẩn kèm theo sau:

DOD-STD-480 Kiểm tra cấu hình - Thay đổi từ bỏ cơng nghệ MIL-STD-490 Thc hnh c t

MIL-STD-499 Quản lý công nghệ

MIL-STD-1521 Rà soát lại kiểm toán kỹ thuật cho hệ thống, thiết bị 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 hạng mục vật liệu quốc phòng

DID Mô tả hạng mục liệu (DID đ-ợc phát ©m hiƯp vËn víi kid)

Tiªu chn 480 kiĨm tra cấu hình mở rộng sang thị vô h-ớng dẫn quản lý cấu hình nói chung xuất th©n cđa t- liƯu 2167

Các tiêu chuẩn 490 499 bao gồm thị công nghệ chung cho việc đặc tả quản lý không đặc tr-ng cho phát triển phần mềm

Tiªu chuÈn 1521 mô tả rà soát lại kiểm toán thức đ-ợc tiến hành 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 sử dụng kết cấu phân tích cơng việc (WBS) Trong lần phát 2167A tiêu chuẩn, 881 không cịn đ-ợc đặc tả

Tiªu chn 2168 (DOD 1988b) chứa yêu cầu cho phát triển, dẫn t- liệu thực ch-ơng trình phần mềm bao gồm việc lập kế hoạch tiến hành

- Đánh giá chất l-ợng phần mềm

- Dn t- liệu phối hợp hoạt động liên quan

- Hoạt động cần thiết đảm bảo giải vấn đề kịp thời có hiệu

Các DID t- liệu dễ hiểu bao gồm pha phát triển, bảo trì phần mềm xuất tham khảo cho ng-ời dùng Các DID bao gồm phận gọi h-ớng dẫn chuẩn bị tạo nên mức độ tự rộng rãi cách cho phép lấy kích th-ớc t- liệu sử dụng ph-ơng án thể thức trình bày Bộ DID đầy đủ đ-ợc mô tả bảng 8.1

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ế yêu cầu phần mềm

4 Đặc tả yêu cÇu phÇn mỊm T- liƯu thiÕt kÕ phÇn mỊm

Thiết kế yêu cầu giao diện

6 Đặc tả yêu cầu giao diện T- liệu thiết kế giao diện

Mô tả phiên bản

8 T- liệu mô tả phiê

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 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 sở)

T- liệu bảo trì mà nguồn.

16 T- liệu hỗ trợ hợp nguồn máy tính 17 Đặc tả sản phẩm phÇn mỊm

Tiêu chuẩn 2167 khẳng định khơng có ý định chi tiết hóa hay phản bác việc sử dụng ph-ơng pháp phát triển phần mềm đặc biệt (DOD 1988a) Dù sao, nh- nêu tr-ớc đây, tiêu chuẩn nặng nghiêng 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 cố hữu pha phát triển có u cầu rà sốt lại, địi hỏi việc thiết kế hệ thống đ-ợc tiếp nối nhờ yêu cầu phần mềm, thiết kế, thực thử nghiệm phần mềm Tiêu chuẩn có mơ tả tiếp cận đó, đ-ợc minh họa hình

Tiêu chuẩn nêu ph-ơng pháp luận thiêt kế khác đ-ợc dùng với quan niệm chung 2167, nh- lấy nguyên mẫu nhanh Nh-ng, nhiều ph-ơng pháp luận khác nh- mơ hình xốy ốc36 khơng dễ áp dụng cho tiêu chuẩn Dù sao, Overmyer (1990) bình luận 2167, kêt luận nói việc lấy kích th-ớc đầy đủ, 2167 đ-ợc vận dụng cho 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 phn ny

36Mô hình xoắn ốc mà Boehm (1988) mô tả mô thức hội tụ lặp lại rõ ràng khó thích nghi với tiêu

8 2 Rà soát lại kiểm to¸n

Rà sốt lại kiểm tốn công cụ kiểm tra chủ yếu xây dựng thành tiêu chuẩn 2167 Rà sốt lại thành cơng th-ờng tiêu đề cho việc tiến hành sang pha phát triển sau Theo rà sốt lại thức xác nhận phê duyệt khách hàng công việc phát triển tr-ớc Rà sốt lại thức th-ờng xuyên kèm theo cột mốc toán chủ yếu Điều trở thành kiện gay cấn cho khách v ch thu

Các rà soát lại dự án phần mềm quan hệ rà soát lại đ-ợc nêu hình

Biên rà soát lại thức đ-ợc mô tả tiêu chuÈn MIL 1521 bao gåm:

- T- liệu 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 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 định phát triển dự án chủ yếu đ-ợc thông qua lần cuối Những định tới hạn đ-ợc dẫn t- liệu đặc tả phát triển đ-ợc coi đ-ờng gốc37 Sau đ-ờng gốc trở thành nguồn tham khảo sơ khởi cho phát triển sau sản phẩm phần mềm có ba đ-ờng gốc chủ yếu

- Đ-ờng gốc chức đ-ợc đặt lúc rà sốt lại thiết kế hệ thống để thơng qua lần cuối yêu cầu chức hệ thống (nghĩa quan điểm ng-ời dùng hệ thống)

- Đ-ờng gốc phân bổ đ-ợc đặt lúc rà sốt lại đặc tả phần mềm để thơng qua lần cuối yêu cầu phần mềm

- Đ-ờng gốc sản phẩm, đ-ờng gốc đ-ợc đặt lúc kết thúc cho kỳ phát triển thông qua lần cuối phát triển sản phẩm phần mềm

Đ-ờng gốc trung gian phụ đ-ợ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ế sản phẩm phần mềm Các đ-ờng gốc trung gian khác đ-ợc bổ sung để xác định kết thúc hoạt động phát triển quan trng

8 Mô tả hạnh mục liƯu (c¸c DID).

Các mơ tả hạng mục liệu xác định tiêu chuẩn t- liệu thức mơ tả hạnh mục liệu yêu cầu phát sinh lúc phát triển phần mềm theo

H×nh

H×nh

H×nh

ThÝ dơ rà soát lại kiểm toán DOD (từ DOD Std 2167A).

153

t- liệu riêng biệt CSCI th-ờng xuyên đ-ợc duyệt lại phê chuẩn coi nhẹ hạng mục phát triển riêng rẽ việc duyệt lại hay kiểm toán đơn xem xét CSCI, lại th-ờng đ-ợc đề cập riêng rẽ trình duyệt lại Khơng có h-ớng dẫn thật rõ ràng việc phân chia hệ thống phần mềm thành CSCI phân chia chủ yếu thuận lợi nh-ng nói chung ph-ơng pháp sử dụng t-ơng tự nh- kỹ thuật phân tích cấp cao mơ tả ch-ơng Hình giới thiệu thí dụ phân tích hệ thống thành CSCI CSU cấp thấp, theo tiêu chuẩn 2167A

Bảng có danh mụ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ẽ tiêu chuẩn 2168 ch-ơng trình chất l-ợng phần mềm DOD

Bảng Tiêu chuẩn mô tả hạng mục liệu DOD

Tên gọi yêu cầu liệu Bí danh

1 T- liệu thiết kế đoạn hệ thống SSDD 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 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ợ nguån m¸y tÝnh CRISD

17 Đề nghị thay đổi công nghệ ECP

18 Ghi thay đổi đặc tả SCN

HƯ thèng

1 phÇn 1 phÇn

-H×nh

Một thí dụ phân giải hệ thống DOD 2167 (tõ DOD- Std- 2167A)

Mäi kÝch th-íc t- liƯu DID theo khuôn mẫu t-ơng tự Rất nhiều phần cứng chung nh- hầu hết, 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

CSU CSU

CSU CSU

CSC CSC

CSU CSU

CSC CSC

CSU CSU

CSU CSU

CSC CSC

CSU CSU CSU

**

**Cïng CSU c¸c CSC kh¸c sư dơng

*

*Phần mềm không phát triển

Cũng vậy, kích th-ớc trang, sơ đồ đánh số trang, sơ đồ đánh số phần nhiều h-ớng dẫn chuẩn bị khác chung Điều rõ ràng gợi ý việc sử dụng công cụ tự động hỗ trợ việc chuẩn bị t- liệu, thời gian đ-ợc khuyến khích tiêu chuẩn 2167 Nhiều công cụ nh- đ-ợc phát triển để hỗ trợ 2167 Polack, tham luận phân tích việc sử dụng công cụ CASE cho dự án DOD (Polack 1990), kết luận công cụ thực tế tiết kiệm thời gian dẫn đến hệ thống phần mềm chất l-ợng cao38

Mỗi DID mô tả yêu cầu việc chuẩn bị t- liệu đặc thù nh-ng cần nhấn mạnh đến nội dung u cầu khơng phải kích th-ớc u cầu Điều đặc biệt đ-ợc đề cập đến việc chuẩn bị h-ớng dẫn kèm theo DID khẳng định kiểu trình bày khác, kể biểu đồ, bảng hay ma trận, chấp nhận đ-ợc (thí dụ Hartley Pirbhai 1988 - hay Ward Mellor - 1986) Cũng có mềm mỏng có thực yêu cầu xét 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 LÊy kÝch th-íc tiªu chn.

Lấy kích th-ớc tiêu chuẩn 2167 khơng khuyến khích mà cịn 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 u cầu có hiệu kinh phí đ-ợc nêu yêu cầu hợp đồng quốc phòng

DOD xây dựng h-ớng dẫn lấy kích th-ớc đ-ợc dùng làm nguồn tham khảo thích nghi tiêu chuẩn với loại dự án đ-ợc phát triển39Có hai nguyên tắc vận dụng cho việc lấy kích th-c:

- Quá tình lấy kích th-ớc xóa yêu cầu không vận dụng đ-ợc

- Lấy kích th-ớc tiêu chuẩn phải cơng ty có hợp đồng tiến hành Nguyên tắc có nghĩa sửa đổi bao gồm Việc xóa bỏ yêu cầu khỏi tiêu chuẩn (và thay đổi yêu cầu tiêu chuẩn) Nguyên tắc thứ hai có nghĩa chủ thầu (nghĩa 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ơng ty có hợp đồng (nghĩa DOD)

Việc lấy kích th-ớc tiêu chuẩn 2167 phải đ-ợc hoàn tất sớm tốt Điều đ-ợc thực tốt h-ớng thuyết hợp đồng sáng kiến ban đầu dự án bắt đầu

38Teamwork - công việc đồng đội- Cadre thí dụ cơng cụ CASE hỗ trợ tiêu chuẩn 2167 39h-ớng dẫn lấy kích th-ớc tìm thấy DOD- HDBK 248 H-ớng dẫn vận dụng ly kớch

Sau mô tả thủ tục việc lấy kích th-ớc tiêu chuẩn 2167

1 Rà soát lại yêu cầu tiêu chuẩn 2167 bao gồm: - Rà soát lại kiểm toán

- Dẫn t- liệu

- Hoạt động thử nghiệm

- 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ó yêu cầu

2 Nhận biết 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, không đ-ợc yêu cầu phần sụn đ-ợc phát triển hay hai rà soát lại thiết kế (PDR CDR) không cần thiết cho dự án nhỏ

3 Chuẩn bị danh mục yêu cầu xóa bỏ tiêu chuẩn Điều có thÓ bao gåm:

- Loại trừ t- liệu - Loại trừ hoạt động

- Loại trừ đoạn t- liệu - Loại trừ phần hoạt động

4 Chuẩn bị mô tả viết chỉnh trang cho hạng mục có u cầu để lấy kích th-c

5 Đề xuất yêu cầu lấy kích th-ớc, với chỉnh trang, sớm tốt (nên tr-ớc dự án bắt đầu)

Nhm cú kh nng phân hóa hạng mục bỏ quên hạng mục lấy kích th-ớc, nên 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 thức hay làm đ-ờng mốc, t- liệu lấy kích th-ớc phải đ-ợc lên danh sách với xác nhận hiệu qủa Trong phạm vi t- liệu, đoạn đ-ợc lấy kích th-ớc rồi, xác nhận hiệu trực tiếp xuất sau số đoạn Nếu đoạn đoạn phụ đ-ợc lấy kích th-ớc, có số đoạn cấp cao cần đ-ợc đ-a vào

Danh mục DID với danh mục phê chuẩn lấy kích th-ớc phận hợp thứ giao đ-ợc dự án Cho đến 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 đủ DID với tạp chất chúng Đây lý việc lấy kích th-ớc phải đ-ợc kết thúc sớm tốt

8.2.5 Lỵi bất lợi tiêu chuẩn 2167.

t-cho việc sản sinh t- liệu Sau đó, thời gian phụ lại cần đầu t- để giữ t-cho 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 tiêu chuẩn ngăn việc sử dụng thực hành phát triển phần mềm đại nh-lấy nguyên mẫu nhanh tái sử dụng phần mềm Nh- thấy, ph-ơng pháp đ-ợc vận dụng cho 2167 chúng thích hợp cách tự nhiên vào tiếp cận chung tiêu chuẩn (coi Oierwyer 1990)

Tiêu chuẩn không dễ dàng, vận dụng đ-ợc cho dự án q nhỏ địi hỏi lấy kích th-ớc nhằm giảm cơng việc hành mức độ thỏa đáng Mặt khác, dự án lớn lại có lợi lớn tiêu chuẩn làm cho dự án dễ quản lý hoạt động phát triển rõ ràng

Tiêu chuẩn 2167 cung cấp cho khách hàng tầm nhìn, đáng kể pha phát triển chủ yếu Điều tăng thêm xác suất thỏa mãn khách hàng sản phẩm cuối Dù tất điều có giá Việc kiểm tra, dẫn t- liệu báo cáo địi hỏi phải có nguồn chủ yếu nguồn làm tăng kinh phí cố gắng phát triển

Một lợi ích 2167 cơng tác tiêu chuẩn hóa tuyệt hảo Nó tiêu chuẩn dễ hiểu tồn cho việc phát triển phần mềm cung cấp yêu cầu đặc tr-ng rõ ràng để kiểm tra đ-ợc hầu hết hoạt động phát triển phần mềm

Đây lựa chọn ng-ời sản xuất, có ng-ời sản xuất sẵn sàng chọn 2167 đâu Đây lựa chọn khách hàng hỗ trợ kiểm tra q trình phát triển theo viễn cảnh khách hàng Theo viễn cảnh ng-ời sản xuất, 2167 tạo yêu cầu rõ ràng loại bỏ đ-ợc nhiều điều mơ hồ tối nghĩa dẫn đến tranh chấp ng-ời sản 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 kỹ s- điện điện tử (IEEE) công bố tiêu chuẩn cơng nghệ phần mềm (IEEE 1988) Bộ bao gồm bốn tiêu chuẩn phát triển bao gồm yêu cầu bảo đảm chất l-ợng, thử nghiệm quản lý cấu hình từ vựng tiêu chuẩn thứ năm bao mong đợi từ công nghệ phần mềm

8.3.1 Tæng quan tiêu chuẩn IEEE.

Năm 1987, IEEE xuất 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 chuẩn IEEE thuật ngữ công nghệ phần mÒm ANSI / IEEE Std 730- 1984

Tiêu chuẩn IEEE kế hoạch bảo đảm chất l-ợng phần mềm ANSI / IEEE Std 828 - 1983

Tiêu chuẩn IEEE kế hoạch quản lý cấu hình phần mềm ANSI / IEEE Std 829 - 1983

Tiªu chn IEEE vỊ t- liƯu thư nghiƯm phÇn mỊm ANSI / IEEE Std 830 - 1984

H-ớng dẫn IEEE đặc điểm yêu cầu phần mềm ANSI / IEEE Std 983- 1986

H-ớng dẫn IEEE qui hoạch bảo đảm chất l-ợng phần mềm IEEE Std 990 - 1986

Thùc hành IEEE Ada coi nh- ngôn ngữ thiết kế ch-ơng trình IEEE Std 1002 - 1987

Nhân loại học tiêu chuẩn IEEE tiêu chuẩn công nghƯ phÇn mỊm ANSI / IEEE Std 1088 - 1987

Tiêu chuẩn IEEE thử nghiệm đơn vị phần mềm 10 ANSI / IEEE 1912 - 1986

Tiêu chuẩn IEEE kế hoạch kiểm tra hiệu lực phần mềm 11 IEEE Std 1016 - 1987

Thực hành IEEE mô tả thiết kÕ phÇn mỊm

Vào lúc cơng bố 11 tiêu chuẩn đó, IEEE có 12 dự án khác tiến triển bao gồm tiêu chuẩn rà soát lại kiểm toán phần mềm, kế hoạch quản lý dự án phần mềm kế hoạch bảo trì phần mềm nh- h-ớng dẫn công nghệ phần mềm40

ý đồ rõ rệt tiêu chuẩn IEEE 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 pha đ-ợc thích nghi với ph-ơng pháp khác nh- lấy nguyên mẫu nhanh mô thức xoắn ốc Tiêu chuẩn 930 yêu cầu phần mềm thí dụ tuyệt vời t- liệu tiến triển tốt v-ợt chức tiêu chuẩn Điều nói lên ý đồ h-ớng dẫn ng-ời dùng 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 điểm SSS tốt nh-:

- Không mơ hồ - Sa -c - y

- Theo dõi đ-ợc

40 Jolm Horch mở đầu in 1987 tiêu chuẩn IEEE (IEEE 1987b) báo cáo IEEE

- Thử đ-ợc - Nhất quán

- Sử dụng đ-ợc pha vận hành bảo d-ỡng

Sau ú, danh mc ny cú thể đ-ợc dùng làm danh mục kiểm tra41 để đánh giá đặc điểm yêu cầu theo cách sau:

1 Liệu yêu cầu có rõ ràng có cách lý giải cho ng-ời đọc ? (khơng mơ hồ)

2 Liệu u cầu có t- liệu đầy đủ, liệu đảm bảo không tồn việc hiểu "miệng" (thuyết khẩu) ? (đầy đủ)

3 Liệu chứng minh cách hợp lý với chi phí hợp lý yêu cầu đ-ợc đáp ứng (thử đ-ợc) ?

4 Liệu có yêu cầu mâu thuẫn với yêu cầu khác ? (nhất quán)

5 Liu đặ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 đ-ợc khơng ? (sửa đ-ợc)

6 LiƯu nguyên nhân yêu cầu có rõ ràng (theo dõi ng-ợc lại) t- liệu thiết kế thử nghiệm sau theo dõi yêu cầu? (theo dõi tiếp diễn)

7 Liu c điểm yêu cầu đ-ợc viết cho không tổ chức viết hiểu đ-ợc mà tổ chức bảo trì phần mềm (sử dụng đ-ợc)

Các tiêu chuẩn khác IEEE bao gồm nhiều h-ớng dẫn thí dụ Tiêu chuẩn thiết kế phần mềm đ-ợc mô tả nh- thực hành nên làm việc mô tả thiết kế Tiêu chuẩn bao gồm phác đề mẫu cho t- liệu đặc điểm thiết kế nh- góp ý nội dung mục

Việc thử nghiệm có đ-ợc ý đáng kể 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 tiêu chuẩn 1002 bao gồm kiểm tra 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 hoạt động thử nghiệm phát triển dự án Điều đ-ợc mơ tả hình

Tiêu chuẩn 990 b-ớc khởi đầu khơng bình th-ờng từ tính khái qt đề cập đến ngơn ngữ lập trình đặc thù, Ada Với quen thuộc với Ada, lý hậu thuẫn cho điều rõ ràng Ada ngơn ngữ lập trình Hiện t-ợng ngơn ngữ Ada đ-ợc bàn đến phần

Phân loại học tiêu chuẩn công nghệ phần mềm t-ợng khơng bình th-ờng lý thú, xứng đ-ợc quan tâm đặc biệt

41 Một đặc điểm thực rõ ràng thực đ-ợc hàm ý phải thực đ-ợc yêu

8.3.2 Phân loại học IEEE cho tiêu chuẩn công nghệ phần mềm.

Tiờu chun 1002, phân loại học tiêu chuẩn công nghệ phần mềm t-ợng lý thú chỗ nhằm cung cấp tiêu chuẩn lựa chọn, phần loại so sánh tiêu chuẩn phần mềm khác Mục đích gíup đỡ nhận biết nhu cầu cho tiêu chuẩn đâu khơng có hay đâu khơng có thích hợp Tiêu chuẩn có danh sách định nghĩa bao gồm nhiều loại tiêu chuẩn phát triển phần mềm thuật ngữ đ-ợc sử dụng để nhận biết chúng42

Phân loại học tham khảo tuyệt vời để hiểu rõ đ-ợc tiêu chuẩn phát triển phần mềm quan hệ tiêu chuẩn Phân loại học tạo nên phân chia tiêu chuẩn phần mềm theo loại phân chia công nghệ phần mềm theo chức chu kỳ đời Để hồn chỉnh phân loại học, khung mơ tả quan hệ hai phân chia

Các hình 8.7a 8.7b mô tả phân chia tiêu chuẩn theo loại phân chia công nghệ phần mềm theo chức chu kỳ đời Hình 8.8 thí dụ lại bảng sử dụng để xác định khuôn khổ phân loại

Tiêu chuẩn 1002 có ích tổ chức xem xét chuyển sang phát triển phần mềm thức hay khả thích ứng thực hành thức có đuợc đánh giá lại Tiêu chuẩn khơng phụ thuộc tiêu chuẩn IEEE khác đ-ợc áp dụng cho tiêu chuẩn phát triển phần mm chớnh thc no khỏc

8.3.3 Lợi bất lợi tiêu chuẩn IEEE.

Cỏc tiờu chun công nghệ phần mềm IEEE tiêu chuẩn, h-ớng dẫn góp ý mềm dẻo áp dụng cho nhiều ph-ơng pháp luận khác Các tiêu chuẩn t-ơng đối dễ sử dụng có nhiều thí dụ chứng minh cách mà tiêu chuẩn có ý định đ-ợc sử dụng

Mặc dù tiêu chuẩn công nghệ phần mềm so sánh đ-ợc tiêu chuẩn đ-ợc phát triển tiêu chuẩn đ-ợc sử dụng riêng biệt Điều có nghiã tiêu chuẩn IEEE đ-ợ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 "sơ đồ phân chia khung kiến thức

H×nh

Hình

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

Chức danh nghề nghiệp Mã đạo đức

Bằng cấp Lý lịch

Kiểm tra hiệu lực Rà soát lại kiểm toán Phân tích sản phẩm Thử nghiệm

Các tiêu chuẩn ghi Danh mục

Đại diện Ngôn ngữ

Chức quản lý kỹ thuật Quản lý trình

Qun lý sn phẩm Quản lý nguồn Vòng đời Pha quan niệm Pha yêu cầu Pha thiết kế Pha thực Pha thử nghiệm Pha định tính Pha sản xuất

Pha lắp đặt kiểm tra Pha vận hành bảo trì

Pha nghØ h-u

H×nh

(a) Phân hoạch chuẩn theo kiểu

(b) Phân hoạch công trình phần mềm theo chức vòng

đời

Theo IEEE Std 1002-1987

Chuẩn tiến trình

Chuẩn sản phẩm

Chuẩn chuyên nghiƯp

Chn qc

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ý ngn lùc

** ýniƯm

Yêu cầu Thiết kế Thực thi Thử nghiệm

Chế tạo Vận hành bảo trì

Nghỉ việc

(*) Chức cơng việc (**) Vịng đời phần mềm

H×nh 8

Bảng khung phân loại (trích IEEE Std 1002 1987 IEEE Standard taxonomy for sopftware Engineering standards Viện kỹ s- điện điện tử với đồng ý IEEE)

Dù nhiều lợi điểm tiêu chuẩn đ-ợc nhận thức bất lợi, chúng ng-ời thực đ-ợc tự nhiều khiến cho, lợi ích tiêu chuẩn hố, tổ chức phải xác định cách mà họ phải thực

giữa tiêu chuẩn kích th-ớc t-ơng đối chung đ-ợc sử dụng để xác nh chỳng

8 So sánh tiêu chuÈn IEEE vµ DOD.

Các tiêu chuẩn IEEE DOD đ-ợc cách lý giải t-ơng tự công nghệ phần mềm chỗ thuật ngữ t-ơng tự 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 khách hàng (DOD) tiêu chuẩn IEEE đ-ợc xây dựng với lợi ích khách hàng ng-ời sản xuất nh- tâm trí Sau tóm tắt khác hai tiờu chun:

1 Tiêu chuẩn DOD hầu hết ph-ơng h-ớng nhiều tiêu chuẩn IEEE thực tế h-ớng dẫn gãp ý Tiªu chuÈn DOD cung cÊp mét bé tổng quát ph-ơng h-ớng

trong IEEE tiêu chuẩn riêng biệt

3 Cỏc tiêu chuẩn IEEE mềm mỏng tạo mức độ tự rộng lớn tiêu chuẩn DOD

4 Cả tiêu chuẩn IEEE lấy kích th-ớc theo yêu cầu dự án đặc thù Nh-ng tiêu chuẩn IEEE lại xa 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 khác

5 Cả tiêu chuẩn IEEE DOD nghiêng tiếp cận theo pha với công nghệ phần mềm Mặc dù hai hỗ trợ ph-ơng pháp phát triển khác IEEE dễ thích nghi với tiếp cận lặp li hn nhiu

8 Tiêu chuẩn ADA

Ada ngơn ngữ lập trình nh-ng ngơn ngữ lập trình Nó có nhà tiêu thụ lớn dịch vụ phát triển phần mềm lớn giới Bộ quốc phòng Hoa kỳ ADA tiêu chuẩn quân sự, ký hiệu ANSI/MIL- STD- 1815a Ada đến với h-ơng vị đặc biệt châu Âu thực tế, đ-ợc chấp nhận vào đầu năm 80 ngôn ngữ thực chung cộng đồng kinh tế châu Âu cộng đồng châu Âu tham gia tích cực vào việc thiết kế ngơn ngữ rà sốt lại Ada nhiều dự án lớn châu Âu sau đ-ợc xây dựng Ada

nguyền rủa Ada ngôn ngữ lúc đầu đ-ợc sử dụng cho ứng dụng thời gian khơng thực có vấn đề chuyển nhiệm vụ chậm với biên soạn Ada Những vấn đề biến có đ-ợc biên soạn Ada tinh xảo Ada đ-ợc dùng xử lý liệu phát triển hệ thống ứng dụng thời gian thực

8 M«i tr-êng Ada

Ada đ-ợc dùng làm công cụ thiết kế lúc khởi đầu Ada đ-ợc coi ngôn ngữ nhiều Cấu trúc ngơn ngữ làm cho thích hợp để dùng làm ngơn ngữ thiết kế ch-ơng trình (PDL) Đặc điểm Ada khơng phải ngẫu nhiên DOD đặt ch-ơng trình mơi tr-ờng hỗ trợ Ada mục tiêu song hành với phát triển thân ngôn ngữ Các yêu cầu ngôn ngữ Ada đ-ợc xác định văn Stulm văn thứ hai, văn Steelman43 xác định yêu cầu cho môi tr-ng h tr

Nhiều biên soạn Ada ngày đ-ợc cung cấp nh- phận nguyên thể môi tr-ờng phát triển Ada ba thân biên soạn, điều bao gồm công cụ CASE sản sinh t- liệu, thiết kế phầm mềm, gỡ rối hoà nhập thử nghiệm44

8 Tiêu chuÈn IEEE cho c¸c Ada PDL.

IEEE chọn Ada 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 qui trình kỹ thuật nêu theo 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 Ada sử dụng Ada làm PDL Điều cố gắng tiêu chuẩn việc khái quát hoá cách đề cập PDL dựa cú pháp ngữ nghĩa Ada (theo tiêu chuẩn sáng tạo từ Ada PDL)

Tiêu chuẩn IEEE 990 thức hố qui trình kỹ thuật tất nhiên phát triển với ng-ời dùng Ada Tiêu chuẩn mô tả đặc điểm yêu cầu Ada PDL hầu hết sẵn sàng áp dụng cho 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ế số qui trình thiết kế tốt nh- khả điều biên nh- ẩn dấu thông tin liên kết thông tin Tiêu chuẩn đ-ợc dùng làm phiếu kiểm tra đánh giá PDL đặc biệt có ích việc hiểu Ada đ-ợc sử dụng tốt làm PDL nh-thế

43 DOD công bố t- liệu Stoneman năm 1976 xác định ‘’yêu cầu cho mơi tr-ờng hỗ trợ lập

trình Ada” t- liệu Steelman năm 1978 xác định ‘’yêu cầu cho ngơn ngữ lập trình máy tính lệnh cao’’ dẫn đến móng cho ngơn ngữ Ada (đ-ợc gọi theo tên Augusta Ada Byron đ-ợc coi nhà lập trình máy tính gái thi hào Anh, bá t-ớc Byron)

44 Tahvanainen vµ Smolander (1990) nguồn thông tin có ích c«ng thiÕt kÕ, m«

Tiêu chuẩn IEEE Ada PDL dẫn t- liệu t-ợng tất nhiên ng-ời dùng Ada phát triển Là ngơn ngữ lập trình Ada PDL dễ đ-ợc vận dụng cho pha thiết kế phát triển phần mềm đ-ợc dùng nh- thế, tạo lợi phụ rõ rệt Sau thiết kế hoàn thành l-ợng chủ yếu mã đ-ợc viết Điều dẫn đến việc phát triển số công cụ Ada CASE tạo mã Ada

8 Các tiêu chuẩn phát triển phần mỊm kh¸c.

Một 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ỳ tiêu chuẩn công bố năm 1976 Tiêu chuẩn, gọi h-ớng dẫn t- liệu ch-ơng trình máy tính hệ liệu tự động đ-ợc công bố coi nh- ấn phẩm liên bang 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 tiến triển phần mềm coi nh- 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 khoảng 1979 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 triển phần mềm

 H-íng dÉn kiểm tra hợp thực hoá 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 việc cung cấp tiêu chuẩn toàn quốc tiêu chuẩn b-ớc tiến lên chủ yếu Những tiêu chuẩn sớm sủa khác đ-ợc ANSI nhiều ngành quân Hoa kỳ công bố năm đầu 70

ở Châu âu tiêu chuẩn Anh BS 6224 đ-ợc công bố vào năm 1980 tổ chức quốc tế châu âu tiêu chuẩn hố (ISO) cơng bố tiêu chuẩn phần mềm vào cuối 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 sơ đồ cấu trúc thiết kế (BS 6224 DSD) DSD biểu diễn đồ 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ấu đến trình thiết kế kỹ thuật DSD đ-ợc mơ tả tuyệt vời văn tiêu chuẩn45

Có nhiều kỹ thuật khơng đ-ợc chấp nhận rộng rãi Điều dẫn đến tình trạng phong phú 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 ý đến nhiều tiêu chuẩn IEEE DOD Tiêu chuẩn châu Âu ISO 9000- năm 1990 (ISO1990) giới thiệu tiếp cận có đơi chút khác Tiêu chuẩn châu Âu đ-a nghĩa rộng bảo đảm chất l-ợng phần mềm bao gồm:

Trách nhiệm quản lý

Kiểu toán rà soát lại

Thử nghiệm

Kiểm tra cấu hình

Đào t¹o

Nhiều tiêu chuẩn khác đ-ợc tạo lập châu Âu Hoa kỳ Lựa chọn tiêu chuẩn thích hợp, thân hoạt động dự án chủ yếu Sai lầm việc sử dụng tiêu chuẩn phát triển phần mềm hầu hết lớn việc tìm cách vận dụng tồn DOD Std 2167A cho dự án xử lý liệu nhỏ

Chắc chắn điểm quan trọng phải nhớ lựa chọn tiêu chuẩn thích hợp cho dự án phần mềm chỗ tiêu chuẩn phát triển ph-ơng tiện cứu cánh tiêu chuẩn phải hỗ trợ thực 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 hoàn thành mục tiêu tiêu chuẩn sai đ-ợc vận dụng không

Các tiêu chuẩn thành công chảy theo dịng Bất kể đ-ợc tiêu chuẩn tạo khung hợp thức cho qui trình kỹ thuật tốt tồn Khi qui trình có vơ hiệu, tiêu chuẩn phải hỗ trợ thay chúng qui trình dễ dàng đ-ợc thực Thật khó mà đ-a đ-ợc tiêu chuẩn đáp ứng đ-ợc chống trả ng-ời sản xuất

8 Tãm t¾t.

Tiêu chuẩn đ-ợc coi tai hoạ cần thiết việc ứng dụng đạt đ-ợc kết xứng đáng Nó làm cho việc phát triển phần mềm dễ quản lý Một thách đố cho ng-ời quản lý dự án việc lựa chọn tiêu chuẩn ch-ơng cung cấp thông tin cần thiết giúp đỡ ng-ời quản lý dự án tiến hành lựa chọn

Loại biến thức tiêu chuẩn phát triển dự án có nhiều khơng có dẫn tiêu chuẩn trở thành tiêu chuẩn Nhiều tiêu chuẩn phần mềm có -u đ-ợc thoả mãn miễn chúng đ-ợc vận dụng Các tiêu chuẩn đòi hỏi kỷ luật kỷ luật không dễ đáp đặt công nghệ phần mềm

Tiêu chuẩn 2167 Bộ quốc phòng Hoa kỳ giải vấn đề kỷ luật cách yêu cầu vận dụng tiêu chuẩn nh- phận hợp đồng dự án ý định nhằm cho 2167 trở thành tiêu chuẩn thức cho phát triển phần mềm hệ thống quốc phòng cho giới quân Hoa kỳ

dẫn góp ý mềm mỏng đ-ợ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ể nhiều thí dụ chứng minh đ-ờng mà tiêu chuẩn có ý định sử dụng

Cả tiêu chuẩn IEEE DOD đ-ợc giải thích t-ơng tự cơng nghệ phân mềm chỗ thuật ngữ t-ơng tự tiếp cận chung t-ơng tự nh- 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 khách hàng (DOD) tiêu chuẩn IEEE đ-ợc xây dựng quyền lợi khách hàng ng-ời sản xuất nh- tâm trí

Các tiêu chuẩn đ-ợc xây dựng phong phú Châu Âu Hoa kỳ làm cho việc lựa chọn tiêu chuẩn thích hợp tự thân hoạt động chủ yếu dự án

Tiêu chuẩn phát triển phần mềm ph-ơng tiện cứu cánh Tiêu chuẩn phải hỗ trợ thực mục tiêu 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 mục tiêu hầu nh- chắn tiêu chuẩn sai không đ-ợc vận dụ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 nhận đ-ợc thông tin hạng mục quân đặc tr-ng, số l-ợng yêu cầu cho hạng mục địa điểm khả tiêu thụ dự kiến hạng mục Sau hệ thống đ-a mức kiểm kê góp ý cho hạng mục với địa điểm cho kho kiểm kê

HÖ thèng đ-ợc xây dựng phù hợp với tiêu chuẩn 2167 HÃy chuẩn bị danh mục 10 yêu cầu lấy kích th-ớc chủ yếu cho tiêu chuẩn giải thích lý cho yêu cầu

2 So sánh tiêu chuẩn IEEE DOD liên quan với dự án mô tả tập Giải thích xem tiêu chuẩn bạn nghĩ thích hợp cả,

3 Chuẩn bị phác đồ đặc điểm yêu cầu cho dự án mô tả tập Dựa h-ớng dẫn IEEE cho đặc điểm yêu cầu tốt, cho thí dụ đặc điểm mô tả

4 Mô tả khung liên quan đến tiêu chuẩn DOD cho công nghệ phần mềm Sử dụng bảng xác định 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 tiêu chuẩn IEEE

Ch-¬ng chÝn

Lập lịch: Vấn đề.

Mỗi dự án hồn thành có đ-ợc l-ợng thời gian 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 có hạn Trên thực tế hầu hết tr-ờng hợp lại l-ợng thời gian mà ng-ời quản lý dự án coi đủ Có dự án hoàn thành tr-ớc thời hạn: nhiều dự án v-ợt lịch chúng

Những chuyện có thật sau nhấn mạnh đến vài yếu tố việc lập lịch

Vào cuối năm 70, chủ thầu quốc phòng lớn trụ sở California phát triển hệ thống phịng khơng phức hợp cho qn Sau giai đoạn hợp bắt đầu thời kỳ sau khoảng sáu tháng, cố gắng đ-ợc h-ớng thử nghiệm hệ thống chủ yếu đầu tiên, thử nghiệm đ-ợc tiến hành với chủ thầu phụ bờ biển phía đơng

Chủ thầu phụ đ-ợc giao nhiệm vụ đ-a máy bay lên khơng trung, máy bay liên lạc với hệ thống máy tính chủ thầu phụ bờ biển phía đơng hệ thống lại liên lạc với địa điểm thử nghiệm chủ thầu California Nhiều chức hệ thống đ-ợc thử thách thử nghiệm hệ thống tốn Khi thời gian thử nghiệm đến gần, thành viên đội làm việc căng thẳng nhằm đảm bảo cho thử nghiệm thành công Vào ngày định cho thử nghiệm, tất nhân viên dự án đến nơi làm việc từ sáng sớm để đảm bảo cho thiết bị hoạt động đắn Chủ thầu phụ bờ biển đông cho máy bay lên hệ thống hoạt động

Thử nghiệm thất bại Không thử nghiệm thất bại mà thực tế chẳng bắt đầu Lý không nhớ đến việc lệnh cho tuyến liên lạc từ công ty điện thoại điểm chủ thầu phụ bờ biển đông điểm thử nghiệm California Mọi cố gắng quản lý để công ty điện thoại lắp đ-ờng dây ngày thử nghiệm thất bại khơng đủ thời gian Thất bại tổng cộng thử nghiệm hệ thống tốn nặng cho chủ thầu hẳn số nhà quản lý việc

Giai thoại nhấn mạnh đến nhiều vấn đề việc qui hoạch lập lịch dự án Những sai lầm xảy sức ép thời gian lập lịch khơng thực tiễn hay bố trí nhân viên phạm vi tổ chức dự án

Dự án hầu hết đ-ợc phát triển d-ới sức ép thời gian Có sức ép “đạt đ-ợc tốc độ” sức ép “cho xem xẩy ra” tất nhiên có sức ép địi thu đ-ợc hệ thống lắp đặt xong chạy Chắc hẳn sức ép phổ biến liên quan đến thời gian “get that darned bug fixed

quickly!” Lo¹i søc Ðp gây 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 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 đ-ợc mô tả

Tất nhiên chuẩn bị lên lịch thực tiễn không mục tiêu, mà quan trọng có lịch đ-ợc chấp thuận Việc có đ-ợc chấp thuận lịch thoả dáng vấn đề liên quan đ-ợc bàn đến

Dù lịch dự án đ-ợc chuẩn bị tốt nữa, lịch vơ dụng khơng đ-ợc thực Đây trách nhiệm ng-ời quản lý dự án chống chọi đ-ợc sức ép đảm bảo dự án đ-ợc phát triển cách trật tự theo lịch Bất kể tình thay đổi, lịch dự án phải theo đ-ợc cập nhật để phản ánh đ-ợc tình hình Lịch dự án phần quan trọng kế hoạch phát triển dự án Kế hoạch không bao gồm lên lịch hoạt động phát triển mà lên lịch nguồn vốn dự án, đặc biệt ng-ời Ch-ơng bàn đến việc lên lịch 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 văn hợp thức dự án tạo Trong văn này, ng-ời quản lý dự án mô tả chi tiết:

Dự án đ-ợc phát triển

Cần có ngn vèn nµo

 Những nguồn vốn đ-ợc sử dụng

Kế hoạch phát triển dự án đảm bảo việc phát triển dự án đ-ợc lên biểu rõ ràng tr-ớc hoạt động phát triển bắt đầu Ngồi lịch phát triển bản, kế hoạch đề cập đến vấn đề nh-:

 Cung cấp kịp thời thiết bị công cụ cho ng-ời sản xuất cần đến

 Có đ-ợc đội ngũ thự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 dự án thành thực

 Chỉ định nhiệm vụ đội ngũ phát triển giao nhiệm vụ cho thành viên đội

Nội dung kế hoạch phát triển dự án thích nghi với qui mơ dự án, văn lớn hay vài trang Bảng 9.1 giới thiệu phác đồ số chủ đề nằm kế hoạch phát triển dự án

các hoạt động nh- giao diện với chủ thầu phụ, ng-ời bán đại diện khách hàng

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 nguồn lực dự án, Ph-ơng tiện phát triển, Cơ cấu tổ chức dự án, Nhân

3) Lịch cột mốc: Hoạt động theo lịch, Đ-ờng mốc 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: toán cột mốc, chi phi ngân sách chủ yếu, thủ tục cho phép chi phí

4) Ph©n tÝch rđi ro 5) An toàn

6) Giao diện với nguồn bên 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 thay đổi/vấn đề

10) Công nghệ phần mềm: Tiêu chuẩn thủ tục, Ph-ơng pháp luận phát triển, Nguồn lực phát triển, Nhân - trình độ 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 cho kế hoạch phát triển dự án Cơ cấu hợp thức năm bỏi kế hoạch phát triển dự án khác tuỳ thuộc tiêu chuẩn t- liệu sử dụng chẳng hạn tiêu chuẩn 2167 US DOD cung cấp khả tuỳ chọn mô tả kế hoạch thử nghiệmu quản lý cấu hình đảm bảo chất l-ợng ba văn riêng biệt Với dự án lớn, khả tuỳ chọn trở thành yêu cầu

Tiêu chuẩn IEEE 1058.1 mô tả đ-ợc coi kế hoạch quản lý dự án phần mềm chủ yếu y nh- kế hoạch phát triển dự án Tiêu chuẩn t-ơng hợp nhiều với kế hoạch phát triển dự án 2167 rõ ràng chi tiết Tiêu chuẩn lại cung cấp khả tuỳ chọn gộp kế hoạch quản lý cấu hình bảo đảm chất l-ợng hay mô tả chúng văn riêng biệt

Kế hoạch phát triển dự án đ-ợc chuẩn bị văn tự lập theo nghĩa đọc đ-ợc hiểu đ-ợc không cần phải xét tới văn khác Do tổng quan chung dự án thông th-ờng đ-ợc gộp phần đầu văn Tất nhiên tham chiếu chi tiết phụ phải ln có, kể dẫn văn nh- hợp đồng dự án, văn quan niệm hay phân tích, nghiên cứu thị tr-ờng

quản lý xét Xem ph-ơng tiện đ-ợc tổ chức để hỗ trợ cố gắng phát triển Đây phần cung cấp nhiều chi tiết cần để chuẩn bị cốt lõi 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ái gì” “khi nào”, phần lớn phần lại đề cập “nh- nào”

Việc bàn luận phần nh- nào cung cấp thông tin dự án đ-ợc tổ chức nào, rủi ro đ-ợc xử lí nào, rà

soát lại đ-ợc tiến hành nào, những tiêu chuẩn đ-ợc vận dụng thế

nào, những ph-ơng pháp luận phát triển đ-ợc sử dụng sản

phẩm đ-ợc thư nghiƯm.

Thơng th-ờng tốt việc hoàn thành phần lịch (phần bảng 9.1) cuối lịch tuỳ thuộc hầu hết phần khác phần nhạy cảm kế hoạch phát triển Sau dự thảo đầu kế hoạch phát triển sẵn sàng lịch phát triển ban đầu theo đ-ợc chuẩn bị Nh- thấy lịch theo đ-ợc tinh chế thêm kế hoạch phát triển qua lần lặp lại

9.2 Hoạt động cột mốc theo lịch

Lịch phát triển dự án danh mục hoạt động thời gian tiên liệu thực 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 biểu diễn lịch biểu đồ mạng PERT biểu đồ GANTT danh mục cột mốc (những ph-ơng pháp đ-ợc mô tả sau) Mọi ph-ơng pháp biểu diễn lịch chủ yếu phải cung cấp thông tin hoạt động thời gian thực Do b-óc đầu việc chuẩn bị lịch xác định hoạt động dự án Nh-chúng ta thấy lịch phát triển dự án yếu tố quan trọng kế hoạch phát triển dự án kế hoạch đ-ợc yêu cầu giai đoạn đầu dự án Bất hạnh danh mục đầy đủ hoạt động lại th-ờng đ-ợc hồn tồn vào giai đoạn thiết kế Do phiên ban đầu lịch dự án th-ờng bắt đầu với danh sách hoạt động mức cao lịch ban đầu tiếp tục đ-ợc tinh chế lại có đ-ợc nhiều thơng tin Ch-ơng có bàn đến đầy đủ ph-ơng pháp tinh chế danh mục hoạt động công việc

Lịch ban đầu có pha 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 đầu lịch th-ờng đ-ợc tạo với dự toán ban đầu dự án tr-ớc dự án thức đ-ợc tung Khi có nhiều chi tiết hơn, dự toán tốt đ-ợc xây dựng lịch đ-ợc tinh chế tin cậy 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

án tới mức thấp gọi tác nhiệm WBS cung cấp ph-ơng pháp kiểm tra công việc đ-ợc đội phát triển thực đặc biệt có ích 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

Bảng 9.2 Danh mục hoạt động thí dụ

Số hiệu hoạt động Tên hoạt ng

Mô tả Ngày

bắt đầu Ngày kết thúc Phụ thuộc Giao trách nhiệm Tích hợp

Tích hợp phần cứng 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 hợp 20/01 20/04 5.1 Bảo 5.2 Lắp đặt Cung cấp nơi lắp

đặt

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 Pha tích hợp S/W

nguyên thuỷ 21/03 22/03 5.4 Kiên 5.5 Demo Cột mốc tích hợp

nguyªn thủ 15/03 30/4 5.4 Kiªn 5.6 Pha Pha tÝch hỵp

S/W-H/W

1/05 /05 5.6,5

Kiên, Bắc 5.7 Demo 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 Tích hỵp hƯ

thèng trän vĐn

1/06 2/06 5.8,5

Kiên 5.9 Demo3 Cột mốc tích hợp

hƯ thèng trän vĐn Thư

nghiệm thống anpha,bêta,Thử nghiệm hệ chấp thuận 6.1 Đội thử Thành lập đội th

nghiệm 15/04 30/04 Bình

6.2 Các ca thử

Chuẩn bị thủ tục thử ca

thư

1/05 31/05 6.1 B×nh, Kim 6.3 ThiÕt bÞ

6.4 Lắp đặt

anpha Lắp đặ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

y tI v trớ anpha

15/05 30/06 6.2, 6.4

Kim, Kiên 6.6 Lắp đặt

bªta

Lắp đặt thiết bị anpha 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ẵn

sàng thử nghiệm cho viƯc thư nghiƯm chÊp

thn

30/07 31/07 6.7 Kiªn

6.9 ATP Chấp thuận thủ tục thử nghiệm để hồn tất việc

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ị báo cáo thử nghiệm

ATP

5/08 8/08 6.9 Yªn

Bảng 9.2 có thí dụ phần danh mục hoạt động theo lịch dự án Bảng nêu hai hoạt động chủ yếu hợp 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 nhận biết thập phân có ý nghĩa t-ơng tự

hoạt động phù hợp với phân loại bố trí cơng việc (coi Hình 6.6)

2 Tên hoạt động Điều t-ơng tự với nhận biết số đ-ợc sử

dụng tham chiếu hoạt động thích hợp

3 Mơ tả Đây mô tả vắn tắt hoạt động

4 Ngày khởi công Điều liên quan đến ngày hoạt động bắt đầu

theo lÞch

5 Ngày hoàn thành Điều liên quan đến ngày hoạt động phi

hoàn tất theo kịch

6 Cỏc ph thuộc Điều liên quan đến hoạt động khác mà hoạt

động tuỳ thuộc Hoạt động khơng thể hồn thành hoạt động ph thuc hon tt

7 Uỷ nhiệm/trách nhiệm Điều nhận biết ng-ời đ-ợc giao trách

Mọi hoạt động dự án theo lịch lên danh sách với thông tin giai đoạn điều quan trọng đảm bảo hoạt động không chồng chéo, điều có nghiã khơng có hoạt động mức cao bao gồm hoạt đông mức thấp Cuối danh mục theo lịch đ-ợc phân loại phù hợp với ngày khởi động hoạt động Thủ tục cung cấp hình thức lịch d ỏn

9.2.2 Các cột mốc đ-ờng mốc chđ u

Rõ ràng khơng phải hoạt động có tầm quan trọng nh- Một số hoạt động có ý nghĩa kiện lớn chu kỳ phát triển dự án việc hoàn thành đặc tả yêu cầu cột mốc chủ yếu hoàn thành đặc tả thiết kế Các kiện chủ yếu khác bao gồm việc hồn thành ngun mẫu hay thiết lập hệ thống thử nghiệm bêta Tất nhiên kiện dự án quan trọng kết thúc dự án, th-ờng thể việc hoàn nghiệm nghiệm thu Những kiện quan trọng xứng đáng đ-ợc ý đặc biệt đ-ợc ghi lại danh sách riêng 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 liên quan đến kiện khác, nh- toán ngân sách phát triển Các toán dự án giá cố định th-ờng liên quan với khách hàng việc hồn tất thành cơng số cột mốc thoả thuận Điều tạo sức ép đáng kể với ng-ời quản lý dự án việc hoàn thành cột mốc hạn (khơng nghi ngờ ý định khách hàng) Dù sao, lịch giống nh- phận khác kế hoạch phát triển, cần đ-ợc cập nhật định kỳ th-ờng lợi ích tốt dự án việc sửa đổi ngày hoàn tất cột mốc Không phải đ-ợc khách công nhận thật khách hàng phải hành động trái với lợi ích tốt

Những vấn đề không cần thiết đ-ợc ứng dụng cho dự án nội khách hàng đội phát triển phần tổ chức Trong tr-ờng hợp khách hàng phận tiếp thị hay nhóm ng-ời dùng cơng ty Những thay đổi ngân sách theo đ-ợc cấp quản lý chung cho phép nhạy bén với nhu cầu khách hàng nội đội phát triển dự án Các cột mốc đ-ợc dùng khơng làm điểm tốn nh-ng để đo tiến độ dự án xác định đ-ờng mốc

Nếu cột mốc đ-ợc mô tả nh- kiện dự án chủ yếu đ-ờng mốc đ-ợc mô tả 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 thức dùng làm sở cho phát

đ-ợc hoàn thiện Chẳng hạn, 2167 dành cố gắng đáng kể cho thủ tục chấp thuận đ-ờng mốc dự án phần mềm

Th-ờng đ-ờng mốc dự án văn đặc tả yêu cầu hệ thống đ-ợc chấp thuận, gọi đ-ờng mốc chức Văn sở cho thiết kế thi cơng đặc biệt sở cho thử nghiệm chấp nhận hệ thống Do th-ờng đ-ợc coi đ-ờng mốc dự án quan trọng Các thí dụ đ-ờng mốc dự án khác thiết kế hệ thống th-ờng nguyên mẫu hệ thống d-ợc chấp nhận sở cho phát triển dự án sau (coi phần 8.2.2)

9.3 Các biểu đồ GANTT

Tr-ớc có máy tính đời nhiều, Henry L Gantt lấy tên đặt cho biểu diễn đồ thị đơn giản có ích lịch phát triển dự án Biểu đồ GANTT cho thấy hầu hết thơng tin có danh sách hoạt động lịch theo cách dễ hiểu Thông tin theo lịch dễ nắm bắt hiểu hoạt động so sánh dễ dàng Biểu đồ GANTT giúp nhìn thấy vào lúc có hoạt động diễn dự án

Hình 9.1 thí dụ điển hình biểu đồ GANTT Các ký hiệu đ-ợc dùng biểu đồ đ-ợc chấp nhận cách rộng rãi, chúng ch-a đ-ợc chuẩn hoá Chẳng hạn, tam giác ng-ợc th-ờng đ-ợc dùng để chỉmột kiện đáng kể, ví nh- cột mốc

Biểu đồ GANTT hình 9.1 thuyết minh cáI dễ dàng nhanh chóng nhận thức đ-ợc thơng tin lập lịch quan trọng Chúng ta trực tiếp thấy khơng kể đến pha bảo trì, pha khác gối đầu nhau, khoảng thời gian từ tháng 11 đến tháng 12 năm 1992 ba hoạt động mức cao gối đầu

Một biểu đồ chi tiết bao gồm tên kỹ s-gắn với hoạt động bao gồm thiết bị cần thiết cho hoạt động Thơng tin đ-ợc thêm vào bên cạnh đ-ờng thời gian hoạt động đồ thị đó, bảng tham khảo lồng vào bên (t-ơng tự nh- danh sách cột mốc chủ yếu hình 9.1) Một vài biến thể biểu đồ GANTT thực bao gồm kiểu thông tin biểu đồ, nh-ng chúng gây lộn xộn, mà nh- lại mâu thuẫn với mục tiêu biểu đồ đó: làm cho ng-ời ta dễ dàng nhanh chóng nắm bắt 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

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 phải hiểu biểu đồ GANTT không cung cấp thứ Trong biểu đồ GANTT, khó cung cấp thơng tin khối l-ợng nguồn lực cần đến để hoàn thành hoạt động Một nhầm lẫn th-ờng thấy ng-ời ta kết luận kỹ s- đ-ợc trao trách nhiệm tích hợp hoạt động tích hợp đ-ợc bắt đầu khoảng tháng năm 1992 kết thúc vào tháng năm 1993 (bốn tháng), việc tích hợp địi hỏi 20 tháng cơng Sự thật là, việc tích hợp bắt đầu với kỹ s-, tháng thứ hai thêm kỹ s- nữa, ba ng-ời lại đ-ợc thêm vào tháng thứ ba Đội tích hợp sau lại giảm cịn ba kỹ s- tháng thứ t-

Hình 9.1 có bảy hoạt động có đ-ợc thêm chi tiết nhiều hoạt động mức thấp đ-ợc đ-a vào biểu đồ biểu đồ có nhiều hoạt động mức hợp lý đ-ợc (quyết định chủ quan) biểu đồ bổ sung đ-ợc thêm vào chẳng hạn hoạt động thiết kế trình bày biểu đồ GANTT riêng biệt (coi Hình 9.2)

Hình 9.2 giới thiệu hoạt động mức cao 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’ ‘tích hợp giao diện ng-ời dùng’ Điều tạo nối kết liên tục biểu đồ GANTT chi tiết (Hình 9.2) biểu đồ mức cao (Hình 9.1)

Thi công Tích hợp Thử nghiệm

Bảo tr×

1 10 11 12

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 thn

TRR



ATP



H×nh 9.2

Biểu đồ GANTT chi tiết - lịch tích hợp

Nên nhớ thời kỳ tháng Hình 9.2 đ-ợc phân thành tuần Mặc dầu khơng hồn tồn xác xấp xỉ thơng th-ờng sử dụng dự tốn (coi ch-ơng 10) ngồi tính thuận tiện tạo số khe hở cho điều chỉnh nhỏ theo lịch

Các biểu đồ GANTT chi tiết t-ơng tự đ-ợc chuẩn bị cho giai đoạn phát triển dự án chủ yếu Các hoạt động khơng phát triển xuất biểu GANTT nh- cung cấp công cụ phát triển hay nghiên cứu thị tr-ờng Điều đặc biệt có ích số hoạt động phát triển tuỳ thuộ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ụ biên dịch cần thiết phải đ-ợc hoàn thành tr-ớc hoạt động thi cơng bắt đầu Tr-ờng hợp mà quan hệ tuỳ thuộc nh- bỏ qua, chúng th-ờng xuất diện việc rà soát lại biểu đồ GANTT Loại tuỳ thuộc hoạt động đ-ợc trình diễn tốt loại biểu đồ khác, gọi biểu đồ mạng quan hệ tr-ớc-sau hay biểu đồ PERT

9.4 Các biểu đồ PERT đ-ờ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

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

Giai thoại phịng khơng liên quan đầu ch-ơng cung cấp thí dụ tuyệt vời lệ thuộc giũa hoạt đông theo lịch Sự tuỳ thuộc diễn hoạt động thực khơng có hoạt động khác đ-ợc thực Kỹ thuật đồ thị đ-ợc gọi biểu đồ quan hệ tr-ớc-sau cung cấp câu trả lời cho hai vấn đề liên quan giai thoại này: nhu cầu nhận tuỳ thuộc nhu cầu đảm bảo trách nhiệm nhiệm vụ đ-ợc giao

Kỹ thuật rà sốt lại đánh giá ch-ơng trình (PERT)46 sử dụng mạng

quan hệ tr-ớc-sau để lập kế hoạch hoạt động dự án khống chế thực chúng cách hiệu Giống nh- biểu đồ GANTT có nhiều loại biến thể biểu đồ PERT Kỹ thuật PERT qui -ớc mô tả mạng với node (mấu) kiện cung nối hoạt động

Mỗi hoạt động liên kết với hai kiện liên quan đầu cuối Node kết thúc hoạt động trùng với node đầu hoạt động thứ hai, mà thực hoạt động thứ hai tuỳ thuộc thực hoàn thành hoạt động thứ Điều có nghĩa hoạt động đ-ợc thực hoạt động khác kết thúc node khởi điểm chúng đ-ợc hồn thành

Hình 9.3 cho thấy thí dụ biểu đồ mạng PERT biểu thị dịng hoạt động dự án từ node khởi điểm tới node kết thúc Mỗi kiện đ-ợc biểu thị vịng trịn có đánh số mạng bắt đầu kiện khởi điểm, gọi node nguồn kết thúc kiện kết thúc gọi node chìm Mỗi đ-ờng liên kết biểu thị hoạt động dự án Hoạt động Ai,j mô tả hoạt động bắt đầu với kiện i kết thúc kiện j Thuộc số Di,j biểu thị l-ợng thời gian trôi theo lịch, khởi đầu kết thúc

hoạt động Ai,j

Một khía cạnh quan trọng ph-ơng pháp biểu đồ PERT quan niệm hoạt động song hành Mỗi node kiện bắt nhánh vào số hoạt động thực song hành Trong hình 9.3 hoạt động A1,2, A1,3và A1,4có thể thực song hành Dù hoạt động AS,1và

A10,E thực song song với hoạt động khác Chúng ta thấy biểu đồ hoạt động A3,6có thể thực song song với hoạt động A5,8hay hoạt động A8,10nh-ng không với hai T-ơng tự, thời điểm cho hoạt động A3,6có thể thực song song với ba hoạt động A1,4, A4,7v A7,9

46Một mô tả chi tiết chÝnh x¸c cđa kü tht PERT xt hiƯn Gillett (1976)

2 AS,1 5

DS,1 AS,1

H×nh 9.3

Một biểu đồ PERTđiển hình

H×nh 9.4

Một biểu đồPERTcó đ-ờng tới hạn

Hình 9.4 thí dụ biểu đồ PERT bao gồm nhiều thuộc tính thời hạn số thấy biểu đồ hoạt động A5,1đ-ợc lập

lịch để tiếp tục dơn vị thời gian (có thể tuần) lịch cần đ-ợc rút ngắn giá trị thời hạn 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 node i kết thúc node j Di,j= Thời gian hoạt động Ai,j

AS,1 AS,1 AS,1 AS,1 12 AS,1

6 AS,1

2 AS,1 12 AS,1 AS,1 AS,1 AS,1 10 AS,1 AS,1 AS,1 11 S 2 5 8 4 7 E 1 0 9 6 3 1

giá trị thời hạn giúp định vị lĩnh vực mà cố gắng bổ sung -c tt nht

9.4.1.Con đ-ờng tới hạn.

Khng hoảng lịch phát triển dự án phổ biến mà 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 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, phận tiếp thịv.v Một khủng hoảng th-ờng gặp nhu cầu rút ngắn lịch Một sai lầm chung phía ng-ời quản lý dự án cho cố gắng phụ rút ngắn đ-ợc lịch Dù số tr-ờng hợp hoạt động rút ngắn tuyệt đối không tác động đến thời hạn tổng thể lịch

Nhằm xem xét t-ợng tr-ớc hết phải hiểu 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 hình 9.4 đ-ờng chạy từ node S tới tới tới tới tới 10 tới E Một đ-ờng khác chạy từ nút S tới tới tới tới tới 10 tới E Mỗi đ-ờng đ-ợc đặc tr-ng số biểu thị tổng thời hạn đ-ờng,đ-ợc tính cách lấy tổng số thời hạn cho hoạt động dọc đ-ờng

Bảng 9.3 có danh mục đ-ờng từ nút S tới nút E biểu đồ PERT hình 9.4 với độ dài đ-ờng Con đ-ờng dài nhất, 52 tuần Con đ-ờng dài đ-ợc coi đ-ờng tới hạn xác định thời hạn dự án

Khi rút ngắn thời hạn hoạt động hoạt động dọc đ-ờng tới hạn, th-ờng rút ngắn đ-ợc thời hạn tồn dự án có tr-ờng hợp thái cực mà điều không diễn chủ yếu có hai đ-ờng tới hạn Dù có điều chắn rút ngắn hoạt động khơng có đ-ờng tới hạn khơng rút ngắn đ-ợc chiều dài tồn d ỏn

Bảng 9.3 Mọi đ-ờng từ S tới E (căn Hình 9.4)

Con đ-ờng Độ dài Con đ-ờng tới hạn S.1.2.5.8.10.E 41

2 S 1.3.5.8.10.E 52 S 2.3.6.9.10.E 30 S 1.4.7.9.10.E 34

9.4.2 Khối ch-ơng trình n©ng cao PERT.

Một ứng dụng lý thú PERT đ-ợc gọi biểu diễn đồ thị dòng chảy mà Riggs Jones (1990) xây dựng sử dụng mạng quan hệ tr-ớc-sau hồn thiện phân tích chi phí chu kỳ vịng đời dự án Kỹ thuật biểu đồ dịng chảy phân tích chi phí dự án dựa quan hệ l-ợng, giá đơn vị, biến số thời gian, chi phí nhân lực học tập v.v tất đ-ợc biểu thị biểu đồ loại PERT

Kỹ thuật biểu diễn biểu đồ dịng chảy đặt l-ợng thơng tin đáng kể vào biểu đồ mạng Thông tin đứng nh- thông tin 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 địi hỏi vẽ loại tồn biểu đồ tính tốn lại đ-ờng tới hạn Sự tẻ nhạt xảy không thúc đảy thêm hào hứng việc giữ cho biểu đồ cập nhật Vì lý 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 nhiều năm rồi, nh-ng vài năm qua khối ch-ơng trình PERT chuyên nghiệp tốt dùng đ-ợc máy tính cá nhân máy tính nhỏ khác Những khối ch-ơng trình làm cho việc chuẩn bị biểu đồ PERT bớt tẻ nhạt nhiều đáp ứng đ-ợc đặc điểm phụ nh- phân tích kế hoạch việc bố trí hoạt động, kịch “what if” phân bố nguồn lực Những tiện ích máy tính đ-ợc đời để hồn thiện phân tích, biểu diễn biểu đồ dòng chảy tạo chi phí theo lịch cho hoạt động dự án chủ yếu47 Các tiện ích tỏ vơ giá

cho nhà quản lý dự án 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 để qun lý tớch cc d ỏn

9.5 Nhân viên lËp lÞch

Phần dành cho khía cạnh lập lịch máy quản lý nhân lực Động quản lý ng-ời đ-ợc bàn đến ch-ơng

Về bản, đội phát triển nguồn lực y nh- thiết bị phát triển nguồn lực Dù 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 ng-ời quản lý dự án đội phát triển cần quan tâm đặc biệt tới việc lập lịch hoạt động thành viên đội Khi số l-ợng hoạt động dự án thay đổi qui mơ đội phát triển thay đổi suốt vòng đời phát triển dự án Cơ cấu tổ chức đội trở nên quan trọng qui mô độ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 số l-ơng mà c-ờng độ hpạt động Một số hoạt động khẩn tr-ơng lúc khởi đầu dự án suy thoái vào lúc kết thúc ng-ợc lại Chẳng hạn việc quy hoạch đỏi

47 Riggs vµ Jones (1990) tham luận phân tích chi phí dự án mô tả

hi ngun nhân lực nhiều lúc khởi đầu dự án lúc kết thúc kiểm tra cấu hình đỏi hỏi lúc đầu nhiều 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ệ quy hoạch kiểm tra

Hình 9.5 chứng minh mối quan hệ qui hoạch kiểm tra c-ờng độ quy hoạch giảm cần ng-ời cho hoạt động T-ơng tự c-ờng độ kiểm tra tăng cần nhiều ng-ời cho hoạt động nh- thử nghiệm, bảo đảm chất l-ợng 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 đ-ợc 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 giai đoạn dự án lại đội nhỏ vào cuối dự án

ở hai đầu chu kỳ phát triển qui mô đội nhỏ, nhiều chức tổ chức không cần thiết Trong nhiều tr-ờng hợp cấu đội 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 đội đ-ợc giải thể hay hai thành viên đội đảm nhận trách nhiệm cho cơng việc phát triển tồn đội

Trong vài tr-ờng hợp hình 9.6 (a) khơng biểu thị lập lịch đội phát triển đủ 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 chậm lúc khởi đầu dự án qui mô nhân suy giảm nhanh vào lúc cuối Điều thơng th-ờng điển hình dự án phức tạp giai đoạn hợp 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ũ đ-ờng biểu diễn chuẩn mức độ nghiêng đ-ờng biểu diễn thay đổi

T0 tm te

(a)

Trục tung qui mô đội phát triển, M qui mơ tối đa, T0là khởi đầu dự án,

tmlµ điểm nhân tối đa, telà kết thúc dự án.

M

T0 tm te

(b)

H×nh 9.6

Phân bố qui mô đội phát triển (a) bình th-ờng (b) lệch

T0 tm te Bảo trì

Trc tung l qui mụ i phát triển, M qui mô tối đa, T0là khởi u d ỏn,

tmlà điểm nhân tối đa, telà kết thúc dự án.

Hình 9.7

Phõn bố qui mơ đội, kể bảo trì

Cách mà giai đoạn bảo trì đ-ợc xét đến tác động đến đ-ờng cong nhân đ-ờng cong nhân trơng khác giai đoạn bảo trì đ-ợc coi nh- phận chu kỳ phát triển Đ-ờng biểu diễn hình thành nh- hình 9.7 có góc xuống tiếp tục suốt giai đoạn bảo trì

Hình 9.8 mơ tả chức phân bố qui mơ đội ngũ dự án cỡ vừa với qui mô đội ngũ tối đa 18 Lúc đầu với qui mô đội ba, kiểm tra cấu hình đảm bảo chất l-ợng ng-ời quản lý dự án tiến hành, Khi đội tăng lên tám, trách nhiệm đ-ợc giao cho thành viên đội hồn thành nhiệm vụ khác48 Khi đội tăng

lên 12 cần kỹ s- khống chế cấu hình kỹ s- đảm bảo chất l-ợng nửa thời gian đội tăng đến qui mô cao điểm hai kỹ phải yêu cầu làm trọn thời gian

Qui mô đội đ-ợc xác định tổng số ng-ời đ-ợc uỷ thác vào dự án Dù lập lịch qui mơ đội Việc bố trí ng-ời ng-ời cho nửa phần uỷ thác trọn ngày không thiết việc uỷ thác ng-ời trọn ngày Trong 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 uỷ thác hoạt động đ-ợc giảm chia chức với dự án khác Điều đặc biệt với dự án nhỏ.Thử nghiệm thí dụ khác nguồn nhân lực chia xẻ dự án, Nhiều tổ chức có đội thử nghiệm độc lập khơng trực tiếp phận độ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ù số hoạt động thử nghiệm tiến hành sớm nhiều) Những đội nh-

48Không phải giao hoạt động kiểm tra cấu hình bảo đảm chất

có thể chuyển từ dự án sang dự án khác miễn hoạt động thử nghiệm đ-ợc lập lịch thích hợp

18 TÝch hỵp

16 Thi c«ng

14

ThiÕt kÕ

12 Thư nghiƯm

10

Yêu cầu

8

4 ThiÕt lËp dù ¸n

KÕt thóc dù ¸n

2

H×nh 9.8

Thí dụ qui mơ i phỏt trin

9.5.2 Kỹ kinh nghiệm

Việc lập lịch nhân lực khơng tr-ờng hợp bố trí số ng-ời vào giai đoạn dự án Những kỹ đặc tr-ng đ-ợc yêu cầu cho hoạt động ng-ời chuyên môn có kinh nghiệm thích hợp phải đ-ợc uỷ thác nhiệm vụ cho hoạt động Bảng 9.4 cho danh mục số hạng nhân lực cần cho giai đoạn phát triển dự án Không phải dự án yêu cầu hạng nhân lực nh- truờng hợp dự án nhỏ hai hay nhiều c-ơng vị dự án ng-ời m nhn

Bảng 9.4 phân loại 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

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 thiết kế Phân tích hệ thống, Kỹ s- thiết 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

Mặc dù bảng 9.4 xét đến c-ơng vị nghề nghiệp khác địi hỏi chun mơn khác ln có lợi trình độ chun mơn thành viên đội đ-ợc mềm mỏng Nh- bố trí lại thành viên đội dự án, tiết kiệm đ-ợc chi phí đ-ờng biểu diễn học tập th-ờng cần thiết để lập lịch cho thành viên đội

Hoạt động đ-ờng biểu diễn học tập th-ờng bị xao lãng Việc làm quen dự án thành viên khơng truờng hợp có chi phí đ-ờng biểu diễn học tập Đào tạo yếu tố quan trọng phải đ-ợc lập lịch Dù khơng phải nhu cầu đào tạo đề biết đ-ợc giai đoạn đầu dự án Những yêu cầu đào tạo trở nên rõ rệt có qui định liên quan đến mơi tr-ờng phát triển (nh- ngơn ngữ lập trình, máy tính để phát triển v.v.) thành viên đội đ-ợc lựa chọn kỹ kinh nghiệm 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 kỹ thành viên không độ đo tin cậy hồn thiện trơng đợi Việc lập lịch kỹ s- đức tính giả định đo đ-ợc từ lâu đề tài tranh cãi Sackman cộng vào đầu năm 1968 có báo cáo tính đa dạng chất việc hồn thành cơng việc ng-ời lập trình phần mềm đ-ợc trao đổi thêm ch-ng v ch-ng 10

9.5.3 Tháng công

Nguồn gốc sai lầm phổ biến khác lập lịch nhân lực khác cách mà từ “man month” (hay nh- đ-ợc gọi workmonth) đ-ợc dùng Nếu ng-ời quản lý dự án tính tốn hoạt động đ-ợc lập lịch đòi hỏi sáu tháng làm việc để hồn thành, phải điều có nghĩa kỹ s- thích hợp đ-ợc bố trí làm việc tháng hoạt động hồn thành sáu tháng?

Phải! câu trả lời “có thể” Trong nhiều tr-ờng hợp, hoạt động khơng thể hồn thành tháng ng-ời có đ-ợc tháng làm việc thời hạn lịch tháng Con ng-ời phải nghỉ hè, họ tổ chức nghỉ lễ đơi họ ốm Nói chung ng-ời có khoảng 10 tháng làm việc thời kỳ 12 tháng Điều phải xét đến chuẩn bị lịch trình

Khi ng-ời quản lý dự án báo cáo cấp dự án đòi hỏi đầu t- năm họ phải biết rõ loại năm họ nói Điều năm lịch có nghĩa dự án hồn thành năm kể từ ngày khởi cơng? Hay năm làm việc có nghĩa có 72 tháng làm việc để hồn thành đ-ợc chia cho số nhân lực? hay thực 48 tháng công với phụ thêm nghỉ hè, nghỉ lễ, nghỉ ốm ?

thời gian có ng-ời đ-ợc bố trí Do ý nghĩa thời hạn dự án nh- thời hạn hoạt động chủ yếu phải đ-ợc hiểu rõ ràng trình bày nh- phận lập lịch Lập lịch phải tính đến tình trạng vơ trách nhiệm, chi phí hành (thảo luận họp hành nói chuyện khơng đâu) phải giải thích hoạt động rút ngắn hoạt động

Giảm thời hạn hoạt động có giá Thêm nhiều ng-ời vào dự án sinh thêm tổng phí Nếu năm ng-ời phát triển dự án năm điều khơng phải 10 ng-ời phát triển dự án năm Điều liên lạc phụ thành viên cần nhiều họp hơn, nhiều phối hợp hơn, nhiều quản lý quản trị Và tất nhiên, ng-ời ta tiếp tục giảm thời hạn hoạt độ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 bố trí ng-ời vào dự án điểm ng-ời bắt đầu theo đ-ờng Đóng góp số khơng chí số âm đạt đến nhanh mà dự án vào phát triển tốt đ-ờng biểu diễn học tập trở nên dài tốn

9.6 lập lịch Nguồn lực

Phn tr-c õy ó bàn đến việc lập lịch nguồn lực tối quan trọng dự án đội phát triển Nh-ng khơng có công cụ cần thiết đội phát triển hi vọng làm đ-ợc việc tốt Nếu máy tính mục tiêu dự án khơng có pha tích hợp bắt đầu, pha tích hợp khơng bắt đầu tốt đ-ợc Do thấy dạng nguyên tắc đ-ờng tới hạn vận dụng đ-ợc cho tính hiệu lực nguồn lực phát triển Điều có nghĩa tính hiệu lực nguồn lực tới hạn theo lịch bị chậm lại làm chậm việc hồn thành dự án

Có cách để xem xét vấn đề tính hiệu lực cho nguồn lực tới hạn, nh- phân tích rủi ro.Mục tiêu cung cấp kế hoạch phịng ngừa tình mà 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

9.6.1 Lập lịch không gian làm việc.

cửa dự án, không gian làm việc đặc biệt khơng gian văn phịng, th-ờng nguồn lực chủ yếu yêu cầu Khu vực dự án phải đ-ợc bố trí tr-ớc xác định rõ dự án tiến triển,khu vực làm việc yêu cu s tng

Không gian làm việc văn phòng lập lịch b-ớc việc lập lịch nguồn lực Yêu cầu không gian hàm số yêu cầu nhân lực dự toán, yêu cầu thiết bị lịch nhân sù cđa dù ¸n

Bảng 9.5 có danh mục kiểm tra số hạng mục phải xem xét lập lịch không gian làm việc Tất nhiên, chuyên đề vận dụng đ-ợc cho dự án Lẽ dĩ nhiên, yêu cầu không gian tuỳ thuộc qui mô thể loại dự án Nhiều dự án quốc phòng an ninh đòi hỏi khu vực tiếp cận hạn chế đặc biệt bảng kiểm tra đ-ợc coi khu vực an tồn Hạng mục khác phịng l-u kho kiểm kê, yêu cầu cho dự án bao gồm khối l-ợng lớn phần cứng thiết 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 th- ký Phòng häp

4 Phịng đội phát triển khơng gian bàn giấy Phịng máy tính

6 Phßng thÝ nghiệm

7 Khu vực hợp thử nghiệm Khu vực ăn tr-a giải trí

9 Phòng kho kiểm kê 10.Khu vực an toàn

9.6.2 ThiÕt bÞ lËp lÞch

Với cơng cụ thích hợp công việc đ-ợc tiến hành tốt Nh-ng nh- thấy có đ-ợc cơng cụ thích hợp khơng đủ cơng cụ phải đ-ợc sử dụng lúc Mục tiêu việc lập lịch thiết bị để đảm bảo cơng cụ phát triển thích hợp có đ-ợc với số l-ợng đủ cần đến

Trong năm đầu phát triển phần mềm, cơng cụ bao gồm ng-ời lập trình, biên soạn máy tính để lập mã Cơng cụ phát triển đại ngày bao gồm nhiều biên soạn máy tính Các tiện ích phần mềm từ công cụ thiết kế hợp tới công cụ gỡ rối thử nghiệm tinh vi có Trên thực tế máy tính đ-ợc tận dụng nh- trợ thủ cho ng-ời sản xuất hỗ trợ hoạt động phát triển đặc tr-ng, tạo nên từ công nghệ phần mềm hỗ trợ máy tính hay CASE

tin, hệ thống quân sự, rôbốt hệ thông công nghiệp Trong tr-ờng hợp đó, thiết bị có mục đích đặc biệt đ-ợc yêu cầu cho giai đoạn thử nghiệm hợp Văn phòng dự án trung tâm sau phải phối hợp qui hoạch lập lịch phát triển phần cứng phần mềm đảm bảo tính hiệu lực kịp thời thiết bị phát triển

Đảm bảo tính hiệu lực thiết bị phát triển thích hợp phận quan trọng qui hoạch tốt Nh-ng lập lịch dẫn đến tình theo thành viên đội phát triển bị để ngồi không hay phần ngồi không chờ đợi thiết bị bàn giao Ngay thành viên đ-ợc bố trí lại tạm thời hiệu qủa tính hiệu lực họ ng-ời sản xuất bị sút giảm đáng kể

9.6.3 Ng-êi bán hàng chủ thầu phụ

Khụng phi mi hoạt động lập lịch phụ thuộc trực tiếp ng-ời quản lý dự án đội phát triển Thông th-ờng, phận ngoại lại tham gia vào việc phát triển dự án nh- thấy, việc giao thết bị kịp thời cốt tử cho lịch phát triển điều th-ờng đòi hỏi cung cấp bên ngoại

Không phải khơng bình th-ờng, đặc biệt dự án lớn hay phức tạp, việc có hợp đồng phụ số phần dự án cho công ti có chun mơn đặc tr-ng lĩnh vực liên quan Điều có nghĩa việc kiểm tra phát triển tực tiếp giao cho chủ thầu phụ

Khó lập lịch nguồn lực hoạt động mà ng-ời quản lý dự án khơng hồn tồn kiểm tra đ-ợc Trong tình 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 Giữ quyền kiểm tra chủ thầu phụ hay ng-ời bán hàng

Trong tr-ờng hợp đầu 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 lệch lịch giao hàng điều gây tình trạng tr-ợt lịch cho toàn dự án Điều đ-ợc xử lý tèt nhÊt b»ng c¸ch:

1 Động viên bên ngoại giao hạn (thí dụ phạt bên giao chậm)

2 Nhận biết việc giao chậm rủi ro dự án chuẩn bị kế hoạch đột xuất để xử lý tình xảy

Các thăm viếng với phía chủ thầu phụ ng-ời bán

R soát lại đánh giá cột mốc

 Báo cáo định kỳ chủ thầu phụ ng-ời bán

Thêm nữa, điều quan trọng cho giám định viên có khả động viên bên ngoại cách gắn tốn với cột mốc hồn thành thắng lợi áp đặt hình phạt giao chm

9.7 Kiểm tra cập nhật lịch trình.

Lịch trình khơng phải văn tĩnh chịu thay đổi th-ờng xuyên Lịch trình lỗi thời có (nếu cịn có) giá trị lịch trình phận 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ả trì đ-ợc lịch trình cập nhật thông tin l-u hành phải chảy đặn từ đội phát triển đến Điều thực đ-ợc qua báo cáo định kỳ, rà soát lại 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ỳ 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 việc chuẩn bị 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ỳ cho lãnh đạo đội để ông sau tóm tắt báo cáo trình tóm tắt 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 báo cáo đội tr-ởng với báo cáo nhân lực dự án khác nh- ng-ời phụ trách nhóm thử nghiệm Văn có đ-ợc bao gồm báo cáo ng-ời quản lý dự án, hình thành báo cáo tiến độ dự án văn dự án 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 bao gồm thành viên cá nhân đội phát triển khách hàng chủ thầu phụ dự án

Các báo cáo định kỳ kênh thông tin đ-ợc sử dụng để đánh giá cập nhật kế hoạch phát triển dự án đặc biệt lịch trình dự án Dù báo cáo định kỳ phải không báo nguồn thông tin cho hoạt động Đây trách nhiệm ng-ời quản lý dự án phải thử tính hồn hảo xác thông tin đ-ợc báo cáo

Tần độ báo cáo vấn đề mà ng-ời quản lý dự án định th-ờng báo cáo nửa tháng thích hợp cho nhu cầu dự án nội báo cáo hàng tháng thích hợp cho nhu cầu dự án bên Dù giai đoạn tới hạn dự án, lại cịn có nhiều báo cáo th-ờng xuyên

Một yếu tố quản lý tốt thiết lập tiếp xúc cá nhân quản lý nhân viên Những tiếp xúc cá nhân hỗ trợ nhiều mục đích quản lý, mà kiểm tra báo cáo tiến độ

Những vấn đề với báo cáo th-ờng kỳ vấn đề khách quan, lý giải xác Lịch trình dự án khơng phải đ-ợc lý giải hay nhận thức cách thức quản lý nh- với nhà sản xuất Hội chứng tiếng 90/50 bàn đến ch-ơng minh hoạ cho trình Điều này, nhắc lại khẳng định 50% thời gian để hồn thành 90% cơng việc 50% phụ thời gian để hoàn thành phần cịn lại 10% cơng việc

Điều có nghĩa thành viên đội bắt đầu báo cáo họ hầu nh- hoàn thành nhiệm vụ, chắn cần l-ợng thời gian đáng kể để thực hoàn thành nhiệm vụ Điều th-ờng t-ơng đối dễ có đ-ợc xi xẻo nh-ng cơng việc nặng nhọc đơ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 lại thêm vào tính lác quan tự nhiên ng-ời sản xuất kỳ vọng khơng có sai

Có nhiều ph-ơng pháp để kiểm tra tiến độ liên quan đến tiếp xúc cá nhân ng-ời quản lý dự án đội phát triển Những họp đội dự án hàng tuần hội tốt để thảo luận tiến rà sốt lại khơng thức hoạt động đặc tr-ng giúp ng-ời quản lý dự án nhìn đánh giá công việc làm đ-ợc

Khi lịch trình khơng đ-ợc thực hiện, đơi dấu hiệu thành viên đội bố trí vào hoạt động đặc tr-ng không hỗ trợ lịch trình Những tình nhấn mạnh đến tầm quan trọng có đ-ợc đội phát triển tham gia vào việc chuẩn bị lịch trình Điều th-ớng dễ có ng-ời sản xuất tham gia vào việc chun b nú

9.7.3 Cập nhật lịch trình

Nh- 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 việc rà soát lại định kỳ xác minh hay có kiện đáng kể diễn Chẳng hạn, việc rà soát lại cho thấy nhiều hoạt động chậm (hay nhanh hơn) lịch hay có vơ vàn hoạt động cần bổ sung cho danh mục hoạt động lịch trình cần đ-ợc xây dựng Cũng phát triển phận dự án đ-ợc thay mua thành tố t-ơng đối khởi giá 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 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 t-ợng dự án đáng kể diễn

hạng mục đ-ợc duyệt lại cần thiết đ-ợc cập nhật mơi tr-ờng biểu thị lịch trìmh phải cập nhật (biểu đồ GANTT, biểu đồ PERTv.v.) Nh- việc chuẩn bị lịch trình ban đầu ln có thói quen tốt có thành viên đội phát triển duyệt lại lịch trình tr-ớc công bố Những sai lầm, sơ xuất tranh chấp lịch trình theo nhận biết hiệu chỉnh tr-ớc lịch trình đ-ợc phát

B¶ng 9.6 Danh mơc kiĨm tra cËp nhËt lịch trình

1 Danh mc hot ng B trí nhân lực

3 Danh mơc rđi ro vµ ph©n tÝch rđi ro Ph©n bỉ ngn lùc

5 Qui chế bên thứ ba (chủ thầu phụ, bán hàng, cung ứng) Biểu đồ lịch trình (GANTT)

7 Mạng -u tiên (PERT)

8 Yờu cu -c chấp thuận thay đổi thiết kế

9.8 Mét số h-ớng dẫn chung lập lịch trình và qui ho¹ch.

Qui hoạch bắt đầu với việc khởi cơng dự án chí tr-ớc số tr-ờng hợp Nh- thấy phần 9.1, hoạt động dự án phải đ-ợc qui hoạch Việc thiếu qui hoạch th-ờng nguyên nhân thất bại B-ớc tốt đẹp qui hoạch chuẩn bị phác thảo kế hoạch phát triển dự án, nh- mô tả bảng 9.1 bắt đầu điền vào phần

9.8.1 Tinh chế danh mục hoạt động ban đầu

Nh- thấy, danh mục hoạt động ban đầu, với ngày tháng có dự án hồn thành hoạt động tạo lịch trình ban đầu Việc tinh chế danh mục hoạt động q trình lặp lại tạo lịch trình phát triển chi tiết dự án

Khi lịch trình tiến triển trở tiết hơn, danh mục hoạt động có hoạt động mức độ thấp đ-ợc giao cho thành viên Do điều quan trọng cho ng-ời quản lý dự án bao gồm thành viên giai đoạn Tốt nên để kỹ s- đề xuất lịch trình lĩnh vực trách nhiệm họ khơng nên định lịch trình cho họ Nói chung, thành viên cảm thấy tham gia nhiều vào lịch trình mà họ chuẩn bị lịch trình đ-ợc chuẩn bị cho họ

lại đến có đ-ợc lịch trình chấp nhận đ-ợc trí Chỉ khơng thể có đ-ợc trí, ng-ời quản lý dự án dùng quyền anh hay chị đ-a phần lịch trình cũn bt ng vo

Bảng 9.7 Tóm tắt số h-ớng dẫn việc xây dựng 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 mục tiêu ng-ời quản lý dự án: Có đ-ợc lịch trình chấp thuận lại quan trọng Rất th-ờng khi, lịch trình thực tiễn đ-ợc ng-ời quản lý dự án nhiều cơng sức chuẩn bị đ-ợc đệ trìmh quản lý tập đồn đ-ợc để bác bỏ lý kinh doanh Điều nhấn mạnh tầm quan trọng ng-ời quản lý dự án có ý thức đ-ợc hình ảnh rộng tập đồn khơng tự hạn chế viễn cảnh kỹ thuật hạn hẹp

Khi chuẩn bị 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 hai lĩnh vực (1)ngày hồn thành (2)chi phí phát triển Các sức ép khác chịu đựng đ-ợc nh-ng hai lĩnh vực phổ bin

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 nhu cầu khách hàng, quản lý, ng-ời dự tiếp thị Không lên lịch hoạt động mà nguồn lực nhân lực Chống chọi sức ép htam gia lịch trình khơng thoả đáng

6 Sư dơng c«ng lên lịch máy tính hoá

7 Lờn lch 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 kiện chủ yếu dự án

Với ng-ời quản lý dự án, đ-ờng tốt để đối phó với sức ép nh-thế 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 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 khách hàng tìm cách đ-a quan tâm 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 phần hệ thống? liệu có giải pháp sẵn có thoả mãn đ-ợc tạm thời toàn hệ thống hoàn thành?

-u t- ảo t-ởng tự thân th-ờng sách tồi tệ Tốt trung thành với lịch trình thực đ-ợc thoả đáng Cách tiếp cận tốt cho ng-ời quản lý dự án trung thực Không hứa hẹn bạn khơng dự liệu có khả giao đ-ợc

Một cách tiếp cận hiệu qủa đ-ợc minh chứng trình bày vấn đề với giải pháp Điều có nghĩa lịch trình khơng thể hỗ trợ mong đợi khách hàng hay quản lý cấp cao vấn đề phải đ-ợc trình bày giải thích lịch trình xen kẽ phải đ-ợc gợi ý với mục tiêu sử đổi Thí dụ sau chứng minh tiếp cận

ACO, công ty vững vàng, tham gia vào dịch vụ hỗ trợ bán lẻ nhiều năm Mới họ định phát triển hệ thống máy tính hố đ-ợc hồ mạng giao diện với hệ thống đăng ký tiền mặt có nhằm cung cấp loạt đa dạng dịch vụ cho cửa hàng khách hàng họ Có hai điều sáng tỏ đầu ra: thứ là, có nhu cầu xác định cho dịch vụ thứ hai là, công ty nhận u cầu

BCO, cơng ty đ-ợc chào hợp đồng phát triển, thấy hệ thống không quan trọng Biết đ-ợc 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 mà họ thấy tham gia Tuy nhiên lịch trình bị ACO bác bỏ

Sau BCO điều tra thêm, rõ ràng ACO chấp nhận thời gian giao hàng hệ thống cho số khách hàng ACO cảm thấy có hội dễ tiêu ma thị tr-ờng họ khách họ giao hạn

BCO đề xuất hệ thống trung gian khơng đ-ợc hoà mạng cửa hàng thu giảm chức Hệ thống trung gian hoạt động phần cứng nh- chức t-ơng thích với hệ thống chức trọn vẹn cuối Hệ thống trung gian đ-ợc giao cho khách hàng ACO sớm sau đ-ợc thay hệ thống trọn vẹn Điều 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 họ có đ-ợc hợp đồng Họ giải thích vấn đề với ACO gợi ý giải pháp cho vấn đề ACO nhắm tới với khách hàng họ Chọn cách làm nh- vậy, BCO giành đ-ợc tín nhiệm ACO thể sẵn sàng giúp đỡ suốt dự án

Không ai, dù khách hàng hay quản lý, 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 chân không Lịch trình phải phận kế hoạch phát triển tổng thể dự án

3 Đảm bảo lịch trình thoả đáng đ-ợc chuẩn bị kỹ Sẵn sàng xác minh cột mốc

4 Tìm hiểu hỗ trợ chuyên gia khác nguồn tham khảo nghiệp vụ nhằm biện minh vấn đề bạn trình bày

5 Ln trình bày vấn đề với giải pháp

6 Tự tin Nếu bạn nghi ngờ khẳng định 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 b-ớc chủ yếu đến hoàn thành thắng lợi dự án Khi lịch trình khơng thực tiễn th-ờng bị nguỵ trang từ nh- chặt chẽ, hăng hay thách đố Dù sao, lịch trình chặt chẽ, hăng hái hay thách đố hấp dẫn cho dự án thành công

9.8.3 Quan hệ lịch trình, nguồn lực chất l-ợng và chức năng.

Nh- chỳng ta ó thy, k hoch phỏt triển dự án lập biểu đ-ờng từ tình hình tới mục tiêu dự án Kế hoạch mô tả nguồn lực cần thiết để thực mục tiêu phạm vi lịch trình định nghĩa Nguồn lực u cầu lịch trình đ-ợc tính (hay dự tốn) hai mục tiêu đề dự án

Các mục tiêu dự án, (là chức mô tả đặc tả yêu cầu) không cần thiết yêu cầu dự án Lịch trình danh nghĩa đ-ợc u cầu (thí dụ để phát triển dự án phạm vi năm) Nếu lịch trình u cầu qúa ngắn u cầu phụ yêu cầu bất khả thi Dù lịch trình u cầu khơng q ngắn với tính chức năng, xác định nguồn lực yêu cầu

Các nguồn lực yêu cầu (qui mô tối đa đội phát triển hay máy tính phát triển đặc dụng) Nếu nguồn lực khơng thích hợp u cầu phụ yêu cầu bất khả thi Khi nguồn lực u cầu thích hợp với tính chức năng, chúng xác định lịch trình câu hỏi tồn xảy nguồn lực lịch trình đ-ợc yêu cầu th-ờng điều có nghĩa mức độ tính chức đ-ợc lịch trình nguồn lực xác định Điều có nghĩa phạm vi lịch trình cho với nguồn lực cho, l-ợng tính chức hạn chế Một cách khác để nhìn vào tam giác thuộc tính ăn theo dự án (tính chức lịch trình nguồn lực) đ-a vào thuộc tính thứ t- chất l-ợng Điều có nghĩa nêú ba thuộc tính tr-ớc đ-ợc định tr-ớc chất l-ợng sản phẩm phần mềm đ-ợc xác định Dù ng-ời quản lý dự án vào lãnh địa nguy hiểm bốn thuộc tính đ-ợc xác định tr-ớc ( coi Hình 9.9)

T-ơng tự ng-ời quản lý dự án đ-ợc hỏi cần nguồn lực nhằm phát triển tính chức cho phạm vi 18 tháng mức chất l-ợng cho

H×nh 9.9

Bốn thuộctính 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 phần quan trọng kế hoạch phát triển dự án Kế hoạch th-ờng văn thức phát sinh phạm vi dự án bao gồm không lên lịch hoạt động phát triển mà lên lịch nguồn lực dự án, đặc biệt 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 sao, cần nguồn lực nguồn lực đ-ợc sử dụng

Lịch trình danh mục hoạt động thời gian thực 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 biểu thị lịch trình biểu đồ mạng trình tự tr-ớc-sau (nh- PERT) biểu đồ GANTT danh mục cột mốc

Một sai lầm phổ biến cho có cố gắng phụ lịch trình đ-ợc rút ngắn Việc rút ngắn hoạt động tuyệt đối khơng có tác động đến thời hạn tổng thể lịch trình hoạt động khơng thuộc đ-ờng tới hạn dự án Đ-ờng tới hạn đ-ờng dài xuyên qua biểu đồ trình tự tr-ớc-sau mạng từ nút khởi điểm đến nút tận

Lập lịch nguồn lực quan trọng nh- việc lập lịch 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ị nguồn nhân lực

Nguồn lực dự án quan trọng ng-ời quản lý dự án đội phát triển Vì số l-ợng hoạt động dự án thay đổi nên qui mô đội phát triển thay đổi xuyên suốt vòng đời phát triển dự án Cơ cấu tổ chức đội trở nên quan trọng qui mơ đội tăng lên

Một lịch trình q hạn có giá trị Một lịch trình, với vai trò phận kế hoạch phát triển tổng thể dự án, phải đ-ợc cập nhập định kỳ Nhằm cho ng-ời quản lý dự án trì đ-ợc lịch trình cập nhật, thơng tin thời phải đ-ợc chảy đặn từ đội phát trin iu ny

Các nguồn lực

Chất l-ợng Chức năng

-c thc hin qua báo cáo định kỳ, rà soát lại định kỳ 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 b-ớc chủ yếu để dự án phát triển thành cơng Khi lịch trình khơng thực tiễn, th-ờng đ-ợc nguỵ trang từ nh- chặt chẽ, động hay thách thức Dù sao, lịch trình chặt chẽ, động thách thức hấp dẫn cho dự án thành công

Bµi tËp

1 Bạn đ-ợc định làm quản lý dự án cho hệ thống chuyển quĩ vận chuyển 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 số liên lạc với máy tính trung tâm

Dự án bạn phát triển phần mềm để liên lạc với xe tải gửi theo thuật tốn hành trình tối -u Hệ thống trì sở liệu chi tiết bao gồm thơng tin liên quan đến xe tải công ty, vị trí thời chúng, ng-ời lái lộ trình giao nhận Hệ thống cung cấp câu hỏi trực tuyến khả cập nhật nh- phát báo cáo

Hãy chuẩn bị danh nục hoạt động cho dự án Nhận biết cột mốc chủ yếu xác định đ-ờng gốc dự án

2 Hãy chuẩn bị biểu đồ GANTT mức cao cho dự án mô tả tập Chuẩn bị biểu đồ GANTT chi tiết cho hai hoạt động mức cao giải thích chồng chéo hoạt động tới hạn thay đổi

3. Chuẩn bị biểu đồ PERT mức cao cho dự án mô tả tập

Hãy bao gồm hoạt động phát triển khơng phát triển Định vị trí đ-ờng qua mạng nhận biết đ-ờng tới hạn Chứng minh đ-ờng tới hạn thay đổi thuộc tính thời hạn thay đổi Giải thích tuỳ thuộc nh- đ-ợc biểu thị biểu đồ

4 Hãy chuẩn bị lịch trình nhân cho dự án mô tả tập Mô tả cần thành viên đội giai đoạn, kỹ họ, bố trí họ phạm vi dự án ?

5 H·y chuẩn bị lịch trình nguồn lực cho dự án mô tả tập Mô tả nguồn lực phát triển giải thích cần

Tho lun cỏc tỏc ng cho cố gắng phát triển dự án chỗ khơng có khả có đ-ợc nguồn lực

6 Xem xét nhân tố dự án tập tuỳ thuộc bên ngoại thảo luận xem hoạt động phát triển đ-ợc xem xét để thầu phụ thành tố có khả mua

7 Xem xét vấn đề dự kiến giai đoạn hợp dự án mô tả tập