Giáo trình quản lý dự án phần mềm

Đây là cuốn sách về quản lý dự án phần mềm; nó không phải là một cuốn sách tiếp nữa về công trình phần mềm. Đã có nhiều cuốn sách tham khảo về công trình phần mềm (coi danh mục tham khảo ở cuối cuốn sách này). Mục tiêu của sách này là trình bày công việc phát triển phần mềm theo quan điểm của nhà quản lý chứ không phải theo quan điểm của nhà phát triển. Cuốn sách tập trung, trong một cuốn duy nhất nhiều thực tiễn và kỹ thuật quản lý phần mềm hiện đại đã đợc phát triển và tinh lọc trong suốt thập kỷ qua. Quản lý dự án đợc trình bày nhlà một kỹ năng lĩnh hội đợc và chứ không phải nhlà của trời cho. Chắc chắn, việc quản lý dự án đòi hỏi tài năng quản lý, nhng bản thân tài năng không đợc hữu hiệu. Việc vận dụng thiết thực các thủ tục phát triển phần mềm hiện đại đòi hỏi có các nhà quản lý chuyên nghiệp. Vì đây là cuốn sách thực hành (chứ không phải là một công trình lý thuyết) nên nhiều ph ơng pháp và kỹ thuật đợc mô tả không có cơ sở lý thuyết cho riêng nó. Tuy nhiên những tham khảo sẽ đợc cung cấp suốt cuốn sách dành cho những ai quan tâm đến cơ sở lý thuyết. Danh mục kèm các tham khảo và tài liệu để đọc đợc gợi ý có ở cuối cuốn sách này.Nhất thời, độc giả có thể thấy một số đoạn đợc nhắc lại trong cuốn sách này. Sở dĩ có điều này là để giải quyết cái thờng đợc gọi là tình huống năm ngón tay. Điều này xảy ra khi mỗi năm ngón tay của độc giả cần đợc cài vào cuốn sách để đánh dấu trong khi độc giả lỡng lự giữa các ch ơng nhằm bao quát đợc một chủ đề đặc biệt. Cuốn sách này có giảm nhu cầu phải đánh dấu bằng cách lặp lại cái giải thích vắn tắt bất cứ chủ đề chủ yếu nào đợc tham chiếu ngay dù chủ đề đã đợc thảo luận chi tiết ở đâu đó. Suốt cuốn sách những hạng mục tháng công và năm công đã đợc sử dụng thay cho các hạng mục cũ tháng ngời và năm ngời. Những từ này đợc thảo luận chi tiết ở phần 9.5.3.

Mục lục

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

Nhập môn

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

1.2 Vai trò của việc quản lý trong phát triển phần mềm

1.3 Một thí dụ

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

1.5 Tóm tắt

101011131517Ch-ơng 2 Những vấn đề phát triển phần mềm

Một chút phòng xa

2.1 Những vấn đề cơ bản

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

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

2.1.3 Dự toán và những vấn đề liên quan

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

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

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

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

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

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

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

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

3.2 Các mối quan hệ khác gi-ã khách hàng - nhà phát triển

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

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

3.3.2 Chuẩn bị của RFP

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

3.4 Đề xuất

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

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

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

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

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

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

3.5.1 Ban tuyển chọn đề xuất

3333343637383939424343444445484949

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

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

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

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

3.7 Tóm tắt

Bài tập

505252535455Ch-ơng 4 Chu trình phát triển phần mềm

Các biểu thái về chủ đề thác n-ớc

4.1 Pha quan niệm

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

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

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

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

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

4.3 Pha thiết kế

4.3.1 Bàu không khí trong pha thiết kế

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

4.4 Pha thực hiện

4.4.1 Bàu không khí trong pha thực hiện

4.4.2 Những vấn đề trong pha thực hiện

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

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

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

4.6 Pha bảo trì

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

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

4.7 Tóm tắt

Bài tập

576061626263636566676870707173747576777879Ch-ơng 5 Nguyên tắc quản lý các kỹ s- phần mềm

5.2.4 Các đội chuyên gia

5.3 Các kỹ thuật báo cáo cơ bản

929495Ch-ơng 6 Chia để trị các dự án lớn thế nào: phân chia và

chiếm lĩnh

Nhu cầu lớn không có nghĩa khó

6.3.2 Đ-ờng lối phân giải chức năng

6.3.3 Đ-ờng lối phân giải thiết kế

6.3.4 Đ-ờng lối phân giải nhiệm vụ công việc

6.4 Tóm tắt

Bài tập

96969899102103105106106108109110111112Ch-ơng 7 Các chức năng hỗ trợ dự án

Hỗ trợ quản lý dự án

7.1 Kiểm tra cấu hình phần mềm (SCC)

7.1.1 Thuật ngữ kiểm tra cấu hình

7.1.2 Nguồn lực kiểm tra cấu hình

7.1.3 Kế hoạch quản lý cấu hình phần mềm

7.1.4 Một số đ-ờng lối chung

7.2 Bảo đảm chất l-ợng phần mềm (SQA)

7.2.1 Cung cấp phần mềm có chất l-ợng

7.2.2 Nguồn lực kiểm tra chất l-ợng

7.2.3 Kế hoạch bảo đảm chất l-ợng phầm mềm

Tiêu chuẩn phát triển: tai hại cần thiết

8.1 Tổng quan các tiêu chuẩn phát triển phần mềm

8.2 Tiêu chuẩn US DOD 2167

8.2.1 Tổng quan tiêu chuẩn 2167

8.2.2 Rà soát và kiểm toán

8.2.3 Mô tả hạng mục dữ liệu (DIDS)

8.2.4 Lấy kích th-ớc tiêu chuẩn

8.2.5 Lợi và bất lợi của tiêu chuẩn 2167

8.3 Các tiêu chuẩn công nghệ phần mềm IEEE

8.3.1 Tổng quan tiêu chuẩn IEEE

8.3.2 Phân loại IEEE về các tiêu chuẩn công nghệ phần

142142145146148148154156156157

8.3.3 Lợi và bất lợi của tiêu chuẩn IEEE

8.3.4 So sánh các tiêu chuẩn IEEE và DOD

8.4 Các tiêu chuẩn Ada

8.4.1 Môi tr-ờng Ada

8.4.2 Tiêu chuẩn IEEE cho các Ada PDL

8.5 Các tiêu chuẩn phát triển phần mềm khác

8.6 Tóm tắt

Bài tập

159159164164165165166167168Ch-ơng 9 Lập trình dự án

9.8 Một số đ-ờng lối chung cho việc lập trình và qui hoạch

9.8.1 Tinh lọc danh mục hoạt động ban đầu

197198199Ch-ơng 10 Chuẩn bị dự toán: ph-ơng pháp và kỹ thuật

Dự toán: vấn đề

10.1 Dự toán dự án

10.2 Dự toán từng b-ớc

10.2.1 Những thành phần đ-a khỏi giá

10.2.2 Những thành phần d- thừa kinh nghiệm

10.2.3 Những thành phần có một phần kinh nghiệm

200201202203203205

10.2.4 Phát triển mới

10.2.5 Phân tích chi tiết dự án ở mức rủi ro

10.3 Uớc định phát triển mới

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

10.3.2 Những ph-ơng pháp thống kê

10.4 Mô hình chi phí xây dựng (Cocomo)

10.4.1 Mức nhân sự

10.4.2 Mức độ phức tạp

10.4.3 Yếu tố độ tin cậy

10.4.4 Môi tr-ờng phát triển

Tài liệu đọc thêm

Lời nói đầu

Đây là cuốn sách về quản lý dự án phần mềm; nó không phải là mộtcuốn sách tiếp nữa về công trình phần mềm Đã có nhiều cuốn sách thamkhảo về công trình phần mềm (coi danh mục tham khảo ở cuối cuốn sáchnày) Mục tiêu của sách này là trình bày công việc phát triển phần mềmtheo quan điểm của nhà quản lý chứ không phải theo quan điểm của nhàphát triển.

Cuốn sách tập trung, trong một cuốn duy nhất nhiều thực tiễn và kỹthuật quản lý phần mềm hiện đại đã đ-ợc phát triển và tinh lọc trong suốtthập kỷ qua Quản lý dự án đ-ợc trình bày nh- là một kỹ năng lĩnh hội

đ-ợc và chứ không phải nh- là của trời cho Chắc chắn, việc quản lý dự

án đòi hỏi tài năng quản lý, nh-ng bản thân tài năng không đ-ợc hữuhiệu Việc vận dụng thiết thực các thủ tục phát triển phần mềm hiện đại

đòi hỏi có các nhà quản lý chuyên nghiệp

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

Nhất thời, độc giả có thể thấy một số đoạn đ-ợc nhắc lại trong cuốnsách này Sở dĩ có điều này là để giải quyết cái th-ờng đ-ợc gọi là tìnhhuống năm ngón tay Điều này xảy ra khi mỗi năm ngón tay của độc giảcần đ-ợc cài vào cuốn sách để đánh dấu trong khi độc giả l-ỡng lự giữacác ch-ơng nhằm bao quát đ-ợc một chủ đề đặc biệt Cuốn sách này cógiảm nhu cầu phải đánh dấu bằng cách lặp lại cái giải thích vắn tắt bất cứchủ đề chủ yếu nào đ-ợc tham chiếu ngay dù chủ đề đã đ-ợc thảo luậnchi tiết ở đâu đó

Suốt cuốn sách những hạng mục tháng công và năm công đã đ-ợc sửdụng thay cho các hạng mục cũ tháng ng-ời và năm ng-ời Những từ này

đ-ợc thảo luận chi tiết ở phần 9.5.3

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

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

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

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

án kỹ thuật

Bố trí của cuốn sách

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

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

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

cũng tham luận nhiều khó khăn mà các nhà quản lý dự án gặp trong việcgiành hỗ trợ của bộ phận quản lý cấp trên để trình ra những thủ tục pháttriển mới

Ch-ơng 2 tóm tắt vắn tắt nhiều vấn đề phát triển phần mềm chung

nhất (sau này đ-ợc xây dựng trong suốt cuốn sách) Ch-ơng này đ-ợcchia làm 2 phần Phần đầu giành cho độc giả không quen với những vấn

đề cơ bản về quản lý phần mềm Phần hai giành cho những ngành đangquản lý dự án cả mới và cả đã có kinh nghiệm Phần này thảo luậnph-ơng pháp đấu tranh với những vấn đề đã thảo luận tr-ớc đây, gọi làphân tích rủi ro

Các nhà quản lý dự án có kinh nghiệm có thể bỏ qua ch-ơng 1 và phần

đầu của ch-ơng 2

Ch-ơng 3 thảo luận việc phát triển phần mềm theo hợp đồng Ch-ơng

này mô tả các hợp đồng dự án phần mềm đ-ợc tiến hành nh- thể nào, các

đề nghị ra sao Một văn bản đề nghị nên đ-ợc xây dựng thể nào và nênthiết lập thế nào và những mối quan hệ giữa khách hàng và nhà sản xuất.Ch-ơng này cũng mô tả các yêu cầu về văn bản đề nghị (RFP) và quátrình lựa chọn sau khi các đề nghị đã đ-ợc đệ trình

Ch-ơng 4 mô tả chu trình cơ bản phát triển phần mềm, nhấn mạnh đến

việc tiếp cận theo giai đoạn, phát triển phần mềm Những ph-ơng phápluận khác cũng đ-ợc thảo luận (nh- là tạo mẫu nhanh và mô hình xoắn ốc

- Spiral) Những giai đoạn cơ bản đ-ợc mô tả theo quan điểm của ng-ờiquản lý dự án nhấn mạnh đến không khí và những vấn đè của mỗi giai

đoạn

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

con ng-ời Ch-ơng này lựa ra một số những mặt đặc thù liên quan đếnviệc quản lý các kỹ s- phần mềm, chẳng hạn nh- sự khác nhau đáng kể

về năng suất giữa các kỹ s- phần mềm và tính khí phong độ của các nhàlập trình nói chung

Ch-ơng 6 đề cập một trong những vấn đề khó khăn nhất của phát triển

phần mềm: làm sao quản lý đ-ợc những dự án phần mềm lớn Ch-ơngnày giải thích những dự án lớn có thể đ-ợc phần chia thành những bộphận nhỏ dễ quản lý nh- thế nào theo ph-ơng châm chia ra chế ngự

Ch-ơng 7 mô tả ba trong những chức năng hỗ trợ quản lý cơ bản:

kiểm tra cấu hình đảm bảo chất l-ợng và thử nghiệm phần mềm Ch-ơngnày cũng thảo luận mối quan hệ giữa những chức năng đó

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

biệt hai chuẩn đ-ợc thảo luận chi tiết: chuẩn 2167 của Bộ Quốc phòngHoa Kỳ (DOD) và chuẩn IEEE về phát triển phần mềm Những chuẩnkhác, nh- chuẩn phát triển phần mềm của Anh và Châu Âu, cũng đ-ợcnhắc tới và so sánh

Ch-ơng 9 thảo luận việc lập lịch và kế hoạch phát triển dự án (PDP) và

kỹ thuật lập lịch và lập kế hoạch đ-ợc mô tả, kể cả phác đồ Gantt vàPERR cổ điển và cấu trúc phá hủy công việc (WBS)

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

pháp và kỹ thuật chuẩn bị dự toán Ch-ơng này gồm những ph-ơng pháp

dự tính qui mô của dự án và lịch phát triển dự án cũng nh- dự toán kỹthuật, chẳng hạn nh- các yêu cầu về đĩa và về bộ nhớ Ch-ơng này cũnggiải thích kinh nghiệm có thể đ-ợc sử dụng thế nào để cải tiến dự toán vàmô tả các dự toán có thể đ-ợc hoàn thiện thế nào trong quá trình pháttriển dự án tiến triển

Tri ân

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

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

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

Phần nhập môn của J.Horch cho bản in 1987 của IEEE về tiểu chuẩncông nghệ phần mềm

IEEE stel 729 - 1983 IEEE stel 1022 - 1987

IEEE stel 830 - 1984 IEEE stel 990 - 1986

Giữ bản quyền mọi mặt @ Viện tập đoàn kỹ s- điện và điện tử

Tôi xin cảm ơn về sự giúp đỡ to lớn của Amir trong việc duyệt và tậphợp văn bản Tôi cũng biết ơn về nhiều gợi ý có ích của Ông

Tôi cũng xin cảm ơn Sharon và Talya đã không xáo trộn bản thảo vănbản

Cuối cũng và quan trọng nhất, tôi xin hết sức cảm ơn động viên củaIril, nếu không văn bản đã chẳng bao giờ đ-ợc viết ra

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

Ada là nhãn hiệu đã đăng ký của Chính phủ Hoa Kỳ, Ada AJPO

UNIX là th-ơng nhãn của tập đoàn điện thoại và điện báo Mỹ

VMS là th-ơng nhãn của tập đoàn thiết bị số

MS-DOS lµ th-¬ng nh·n cña tËp ®oµn Microsoft

PC-DOS lµ th-¬ng nh·n cña tËp ®oµn m¸y mãc kinh doanh quèc tÕBYB lµ th-¬ng nh·n cña nhãm Gordon

có thật sự là một bộ phận công trình không ?

Việc phát triển phần mềm có thể kiểm tra đ-ợc Có những ph-ơngpháp những kỹ thuật nh-ng chuẩn và những công cụ khi đ-ợc vận dụng

đúng đắn chúng sẽ thúc đẩy sự phát triển thắng lợi của dự án phần mềm

Đó không phải là những viên đạn bằng bạc xuyên qua trái tim của ng-ờihóa sói: chẳng có gì giữ thật ở trong cả Những ph-ơng pháp này cungcấp một cách tiếp cận có hệ thống tới sự phát triển phần mềm bắt đầu lànhững giai đoạn qui hoạch ban đầu và kết thúc là việc cung cấp sản phẩmphần mềm cuối cùng

Cuốn sách này đề cập đến việc vận dụng những ph-ơng pháp hiện đại

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

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

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

 Vận dụng các tiêu chuẩn phát triên thiết thực

 Chuẩn bị và đánh giá các đề nghị

Nhà quản lý dự án phần mềm theo thế đ-ợc cung cấp các ph-ơng pháp

và qui tình cần thiết khiến cho việc phát triển phần mềm có hiệu quả hơnvới ba mục tiêu nổi tiếng trong tâm t-ởng: phát triển phần mềm

1 theo ch-ơng trình

2 trong phạm vi ngân sách

3 theo yêu cầu

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

Thật có ít lĩnh vực công nghệ hiện đại lại không chứa phần mềm Điềunày bao gồm xe hơi, hàng không và vệ tinh cũng nh- thang máy, máyfax, truyền hình và các cơ quan điện tử Phần mềm vận hành hệ thống anninh xã hội, hệ thống chi l-ơng tập đoàn, và trái của nền kinh tế ph-ơng

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

in sách

Việc gia tăng nhu cầu về phần mềm đã trở nên một vấn đề gay cấn Nó

đã gây ra việc gia tăng nhu cầu về kỹ s- phần mềm V-ợt rất xa mức độcác nhà chuyên nghiệp phần mềm tốt nghiệp ở các tr-ờng đại học Do

đấy sự phát triển phần mềm đ-ợc yêu cầu có năng suất cao lợi hơn, tincậy hơn và nói chung thành công hơn

Những yêu cầu mới đó có thể không đ-ợc đáp ứng ở những ph-ơngpháp phát triển thô thiển của những ngày đầu của máy vi tính

Những ph-ơng pháp mới đã đ-ợc đề xuất cải tiến đáng kể con đ-ờng

mà phần mềm đ-ợc phát triển Tính nghiêm trọng của vấn đề đã đ-ợcthừa nhận trong khắp cộng đồng công nghệ phần mềm Một số các liêncông ti và công xoexiom quốc tế đã đ-ợc thành lập ở Hoa Kỳ, Nhật Bản

và Châu Âu với những ngân sách to lớn dành cho việc tìm kiếm nhữngph-ơng pháp giảm nhẹ (nếu không phải là loại trừ) vấn đề (coi Bennatan1987)

Cox (1990), trong một phân tích ph-ơng h-ớng công trình phần mềm

sẽ tiến hành cho thấy rõ một cuộc cách mạng công nghiệp phần mềm lýthú, ông đã tiên đoán ngày mà các nhà lập trình sẽ thôi không mã hóamọi thứ khi xóa và sẽ ghép các ứng dụng trừ những catalô l-u trữ tốt củacác thành phần phần mềm sử dụng lại đ-ợc Quan niệm này và nhữngquan niệm cách mạng khác nh- phát triển phần mềm tự động (coiFrankel 1985) vẫn còn phải mất quãng đ-ờng dài tr-ớc khi trở thànhnhững ph-ơng tiện thiết thực của phát triển phần mềm

Xu h-ớng tiến tới công trình phần mềm có máy tính hỗ trợ (CASE) đãtạo nên nhiều công cụ phát triển tự động nh-ng chẳng may thay nhữngcông cụ đó1 th-ờng mất nhiều thời gian không xứng với chúng, ở nhữnglĩnh vực khác của công nghệ các hệ CAD/CAM2 tự động đã đang đ-ợc sửdụng để thiết kế và xây dựng các thành phần điện tử nh-ng phát triểnphần mềm vẫn còn hoàn toàn là một cố gắng thủ công

Cho đến lúc mà phần mềm sử dụng lại và phát triển phần mềm tái tạo

và tự động bắt đầu thay thế đ-ợc các kỹ s- phần mềm thì phần mềm vẫncòn tiếp tục do con ng-ời phát triển Trong khi chờ đợi việc gia tăng theoyêu cầu về năng suất và thuần thục tay nghề và thắng lợi chung của pháttriển phần mềm phải duy trì trách nhiệm vẫn phải là ở nhà quản lý dự ánphần mềm

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

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

1 Xem Tahvanainen và Smolander ‘An annotated CASE Bibliography (1990)’

2 CAD và CAM là thiết kế có máy tính trợ giúp và chế tạo có máy tính trợ giúp.

Quản lý dự án phần mềm là quá trình qui hoạch, tổ chức, nhân sự điềukhiển, kiểm tra và lãnh đạo dự án phần mềm Rõ ràng để trở thành nhàquản lý dự án phần mềm tốt thì là nhà phát triển phần mềm tốt không còn

đủ nữa Có những kỹ xảo quản lý đặc biệt đ-ợc yêu cẩu- dụng ngay từnhững giai đoạn đầu của dự án, chằng hạn nh- ở các lĩnh vực nh-:

- Giám sát và kiểm tra

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

- Qui hoạch

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

- Quan hệ khách hàng

Trong một số dự án, việc tiếp xúc với khách hàng là hoạt động quản lýchủ yếu Điều này bao gồm viết tài liệu về yêu cầu của khách hàng,khống chế những thay đổi do khách hàng, sử lý việc tham gia của kháchhàng vào quá trình phát triển, cung cấp báo cáo và tổ chức xét duyệt cùngtrình diễn sản phẩm

- Vai trò lãnh đạo kỹ thuật

Lãnh đạo kỹ thuật tốt th-ờng là một phẩm chất ao -ớc trong việc quản

lý phần mềm có hiệu quả Điều này th-ờng đòi hỏi khả năng cung cấp chỉ

đạo trong giải pháp của các vấn đề kỹ thuật phát sinh trong quá trình pháttriển dự án Điều này không cần thiết có nghĩa là dự trữ chung bản thânmột giải pháp đích thực

Những lĩnh vực quản lý này là vận dụng đ-ợc cho mọi thể loại dự ánCông nghệ cao Dù sao việc quản lý dự án phần mềm lại khó khăn hơn do

sự thể là phát triển phần mềm ít có tính xác định hơn các lĩnh vực côngnghệ khác Điều này là do những dự án phần mềm ít đo l-ờng đ-ợc khó

dự toán hơn và phụ thuộc nhiều hơn vào những nhân tố chủ quan của conng-ời

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

đã chi hết vốn cơ bản khi thấy rõ là dự toán ngân sách ban đầu không chỗnào sát với chi phí phát triển thực sự

Trong những năm gần đây, đã có ý đồ tiêu chuẩn hoá qui trình pháttriển phần mềm và tạo ra môi tr-ờng phát triển nghiêm ngặt trong đó các

dự án phần mềm dễ dự toán và kiểm tra hơn Dù sao, điều này đã dẫn đếnmột vấn đề mới các nhà sản xuất đã phàn nàn phải mất quá nhiều thờigian vào việc thiết lập t- liệu và quá ít cho xu h-ớng phát triển hiện nay

Rõ ràng là cần tìm đ-ợc địa bàn trung độ giữa hai thái cực trong dự ánkhông có thể lập trình và dự toán và dự án tiêu chaủan quá mức, thu thập

t- liệu quá mức trong đó chi công sức quá đáng vào tổng phí và công việcgiấy tờ.

Khi phát triển phần mềm bắt đầu dĩnh dáng đến một bộ môin côngtrình thì những ph-ơng pháp luận phát triển một cách có hệ thống mớicũng bắt đầu xuất hiện3 Mục đích của những ph-ơng pháp luận mới đó làlàm cho sự phát triển phần mềm thành công hơn Nếu thắng lợi đ-ợc dotheo mức độ của ba mục tiêu nói tr-ớc đây (theo lịch trình, trong phạm vingân sách, theo yêu cầu) thì sự thất bại hẳn có nghĩa là trong việc hoànthành thậm chí một trong những mục tiêu đó Dù sao, thành công và thấtbại không phải là cái điều đ-ợc định nghĩa một cách dễ dàng

Đã có nhiều nghiên cứu cho thấy là thất bại của dự án cũng là một vấn

đề của nhận thức (cos Linto và mantel 1990) Một dự án có thể đ-ợc nhận

định là thất bại ở một môi tr-ờng trong khi ở môi tr-ờng khác dự án lại

có thể đ-ợc nhận định là thắng lợi Nói một cách đơn giản, một kháchhàng có thể hài lòng với đầu ra của một dự án trong khi ng-ời khách kháclại không Theo thế thành công hay thất bại của một dự án không chỉ liênquan đến ba mục tiêu phát triển cơ bản mà cả đến kỳ vọng của kháchhàng

Sự không rõ ràng của quan niệm thất bại của dự án chắc chẵn có thểtránh đ-ợc nếu chỉ đặt ra một đích duy nhất Đây là đích mà khách hàng

đặt ra chứ không phải đội ngũ phát triển đặt ra Điều đó có nghĩa là:

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

đó đ-ợc chứng minh trong thí dụ sau:

1.3 Một thí dụ:

Thí dụ này cho thấy vài sai lầm quản lý thông th-ờng mà nó có thểcuối cùng dẫn đến thất bại của một dự án phần mềm Dự án khởi sự vớivài quyết định sai lầm cơ bản liên quan đến việc khởi hành dự án, đếnl-ợt nó, nó lại dẫn đến nhiều quyết định sai lầm hơn khi dự án tiến triển.Công ty liên kết công nghệ (TAI) là một công ty chuyên môn hóatrong việc phát triển và chế tạo thiết bị truyền thông TAI là một ban phầnmềm lớn chịu trách nhiệm về sự phát triển phần mềm cho thiết bị truyềnthông Ng-ời quản lý ban phần mềm đã đ-ợc biết là quản lý công ty đangtìm kiếm một công ty phần mềm bền ngoài để phát triển một hệ thốngbảo d-ỡng và thời gian cho TAI

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

đó phát triển hệ thống trong 6 tháng sau đó (toàn bộ thời gian phát triển

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

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

ý kiến sử dụng một công ty phần mềm bên ngoài đ-ợc gác lại và đềnghị của ban phần mềm đ-ợc quản lý công ty chấp nhận Ngân sách pháttriển đ-ợc thông qua để đáp ứng 2 năm r-ỡi nhân công hay 4 ng-ời trong

8 tháng Ban phần mềm tiến hành lập đội ngũ dự án và chọn một ng-ờiquản lý dự án, trong số các ng-ời quản lý dự án truyền thông để lãnh đạo

đội ngũ này

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

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

2 Hoặc là sử dụng một phần những yêu cầu hiện có

Ng-ời quản lý ban muốn chứng minh là ban của mình có khả năngphát triển cả các hệ thông tin và phần mềm truyền thông đ-ợc lồng vào

Do đó ng-ời quản lý dự án và đội ngũ đã thúc chọn ph-ơng án 2 Điềunày dựa trên tiền đề là nếu dự án bị chậm và v-ợt quá ngân sách thì dự ánphải bị coi là thất bại và các hệ thống thông tin sau này hẳn sẽ phải đ-ợchợp đồng với một công ty phần mềm bền ngoài

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

Ban phần mềm đề nghị sửa chữa các sai sót và yêu cầu ngân sách choviệc phát triển một version cải tiến mới Dù sao, sự bất bình đã đến mức

mà quản lý công ty quyết định đ-a việc phát triển một hệ thống hòantoàn mới cho một công ty phần mềm bền ngoài Công ty phần mềm đ-ợclựa chọn phát triển thành công hệ thống Ngạc nhiên là lần này kinh phílại ít hơn là ngân sách mà ban phần mềm TAI yeue cầu để sửa chữa cácsai sót trong hệ thống ban đầu

Thí dụ (có thật) này thuyết minh một số sai lầm chủ yếu trong quản lý

dự án

- Kinh nghiệm trong một lĩnh vực phần mềm (các hệ viễn thông đ-ợclồng vao) khong đủ cho việc phát triển thành công phần mềm ở một lĩnhvực hoàn toàn khác (hệ thông tin)

- Nhà quản lý dự án nêu trách nhiệm cam kết vào lịch trình phát triểnhay ngân sách tr-ớc khi dự án đ-ợc xác định đủ Trong phần lớn tr-ờnghợp cam kết của công ty chỉ có thể có khi các yêu cầu đã đ-ợc kết luận

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

- Khách hàng hay ng-ời dùng sẽ không phải bao giờ cũng cung cấp

đ-ợc những yêu cầu đúng (thí dụ chủ yếu giao liên ban) Th-ờng là tráchnhiệm của ng-ời sản xuất phải hỏi những câu hỏi thích đáng nhằm thuthập thông tin cần thiết

- Đôi khi tốt nhất là nên phát triển một hệ thống mới bằng việc xóa bỏcòn hơn là tìm cách cứu vãn một hệ thống đã đ-ợc phát triển tồi

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

Một trong những trở ngại mà các nhà quản lý dự án th-ờng phải khắcphục là tình trạng thiếu hỗ trợ ở quản lý cấp cao hơn đối với nhữngph-ơng pháp phát triển hiện đại Vận dụng các ph-ơng pháp luận hiệuquả không dễ khi quản lý cấp cao hơn còn tranh luận về nhu cầu của họ

Điều này dẫn đến các nhà quản lý dự án đến một tình trạng tiến thoáil-ỡng nam, làm sao chấp nhận đ-ợc cái mà họ tin là tốt nhất trong khivẫn giữ đ-ợc c-ơng vị nhà quản lý dự án

Rõ ràng là nhiều ph-ơng pháp và kỹ thuật đ-ợc mô tả trong cuốn sáchnày chỉ có hiệu lực khi chúng đ-ợc sử dụng Mục tiêu của phần này làgiúp nhà quản lý dự án giành đ-ợc sự chấp nhận ở quản lý cấp cao hơntrong việc ứng dụng những ph-ơng pháp mới

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

1 Những ph-ơng pháp mới này đều là lý thuyết trong “thế giới thực”

sự việc diễn ra khác

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

3 Chúng ta không có thì giờ cho mọi công việc giấy tờ đó

4 Chúng ta không thể mất công sức về sự xa phí trong mọi qui trìnhdài dặc đó Chúng ta vẫn luôn phát triển đ-ợc phần mềm mà chẳng cầnnhững tổng phí đó

5 Đây là kinh doanh chứ không phải tr-ờng đại học Chúng ta mất tiền

và mất khách nều chúng ta bắt đầu với việc lãng phí thời gian vào mọiph-ơng pháp đó

6 Ph-ơng pháp là tốt, nh-ng bất hạnh là bây giờ không phải lúc thựchiện chúng Chúng ta mong rằng có thể sử dụng chúng một ngày nào đónh-ng không phải đúng lúc này

7 không có kỹ s- nào của chúng ta quen với những ph-ơng pháp mớinày Nh- thế sẽ mất nhiều thời gian và mất nhiều kinh phí để bắt đầu đàotạo lại họ

Sau đây là một số trả lời gợi ý cho những lập luận trên

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

Bất cứ ph-ơng pháp thiết thực nào đều có đôi chút lý thuyết đúng những ph-ơng pháp phát triển phần mềm đó những ph-ơng pháp đó đã

nh-đ-ợc các công ty t-ơng tự khác vận dụng thành công và đã giảm mạnhkinh phí phát triển phần mềm và tăng đáng kể chất l-ợng phần mềm.2.Việc duy trì nề nếp hồ sơ viết là có lợi cho mọi ng-ời cho đội ngũphát triển cho khách hàng và cho quản lý cấp cao Nó đảm bảo là những

giao tiếp miệng đ-ợc hiểu đúng đắn Nếu những thay đổi hay các h-ớngdẫn khác không ghi thành văn bản và không đ-ợc chấp nhận, thì sự pháttriển có thể tiến hành theo h-ớng sai không ai có thể chắc chắn là mọithay đổi, cả lớn và nhỏ, sau này sẽ đ-ợc nhớ lại khi dự án hoàn thành.Danh mục thành văn bản các thay đổi đ-ợc chấp nhận giúp khả năng theodõi và hạch toán.

3 Đây có thể là khiếu lại đáng l-u ý; công việc giấy tờ phải đ-ợc duytrì ở mức tổi thiểu (có khi nó quá mức) Dù sao, đáng ngạc nhiên là côngviệc giấy tờ có mức độ hiện nay thực sự lại tiết kiệm thời gian và khônggây lãng phí Chẳng hạn những quyết định không ghi thành văn bảnth-ờng khi cần đ-ợc lặp đi lặp lại và những đặc tả nói miệng dẫn đếnnhững lý giải gây tranh cãi Việc thiếu t- liệu th-ờng mất nhiều thời giannhất trong các pha thích hợp và thử nghiệm khi bản thiết kế hệ thống chỉ

đ-ợc l-u trong trí nhớ của ng-ời

Cũng vậy, một dự án không thành văn bản là một ác mộng trong việcduy tu Sau khi hoàn thành dự án, khi các nhà sản xuất đã phân tán đi, tấtcả những gì còn lại là sản phẩm và t- liệu Không có t- liệu sản phẩmkhông gì hơn là một bí mật

4 Một câu hỏi cần phản ảnh là: liệu và đúng vậy liệu phát triển phầnmềm của chúng ta đã thực sự thành công thế nào? Lập luận này đ-ợc thửthách tốt nhất với bộ hồ sơ t- liệu đ-ợc chuẩn bị cho biết những vấn đề

mà công ty đã có kinh nghiệm ở những dự án tr-ớc Mục tiêu là chứngminh tiếp cận mới với phát triển phần mềm đâu phải là xa xỉ mà là cầnthiết

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

dễ dàng ở mọi công ty mà không cần thiết phải phát triển chúng lại

Mất khách hàng không chỉ do lịch trình phát triển kéo dài mà còn dochất l-ợng kém và nhu cầu kỹ thuật không đ-ợc thỏa mãn Càng cầnnghiêm lệnh hẳn về phía lịch trình phát triển lâu hơn chứ không phải vềphía sản phẩm phần mềm tốt hơn

Nh- vậy, lịch trình phát triển ngắn th-ờng dễ bị lạc lối do thời gian bổsung đòi hỏi để bổ chính sản phẩm phần mềm kém cỏi, sau khi đã tung

nó ra lần đầu (coi thí dụ ở phần 1.3)

6 Tại sao lại ch-a làm ngay? Liệu có cơ sở thực sự nào cho việc kêu ca

là thời gian thích hợp hơn sẽ xuất hiện sau này? Trái lại càng thêm thờigian và công sức đầu t- vào những ph-ơng pháp phát triển nghèo nàn thìlại càng khó mà thay đổi đ-ợc Cái cách tốt nhất trả lời cho lập luận này

là cung cấp những lý do kinh doanh để giải thích vì sao những ph-ơngpháp phát triển mới lại nêu đ-ợc chấp nhận càng nhanh càng tốt Bộ hồsơ đã chuẩn bị, nêu trong trả lời cho lập luận 4, sẽ có ích cùng với thông

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

ty trong khi giảm chi phí phát triển

7 Tầm quan trọng của việc đầu t- trong đào tạo ít khi cần đ-ợc nêu:

đây là một quan niệm đ-ợc chấp nhận rộng rãi Lập luận này khó có thểbác bỏ khi các ph-ơng pháp phát triển mới đ-ợc đ-a ra coi nh- một thay

đổi chủ yếu về ph-ơng h-ớng Câu trả lời tốt nhất tùy thuộc ở tình hìnhthực tế Nếu những ph-ơng pháp mới thực sự tiêu biểu cho thay đổi chủyếu là ph-ơng h-ớng thì chắc chắn là công ty đã có thí nghiệm nhiều vấn

đề phát triển phần mềm Nh- thế câu trả lời cho các lập luận 4 và 5 làthích đáng

Nếu những ph-ơng pháp mới không thực sự tiêu biểu thay đổi chủ yếu

về ph-ơng h-ớng thì điều này nêu đ-ợc chứng minh có sử dụng dữ liệucủa các dự án tr-ớc đây T- t-ởng cơ bản là chứng minh rắng mặc dùnhiều qui trình phát triển hiện nay là tinh vi, việc cải tiến đáng kể có thể

đ-ợc thực hiện thông qua việc giới thiệu một số ph-ơng pháp mới

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

- S-u tập dữ liệu về các dự án phát triển phần mềm tr-ớc đây trongphạm vi vông ty

- S-u tập dự liệu về các công ty t-ơng tự đã chấp nhận ph-ơng phápphát triển mới

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

- Có đ-ợc hỗ trợ của các chuyên gia phát triển phần mềm khác hoặc ởtrong phạm vi công ty hoặc ở ngoài

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

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

1.5 Tóm tắt.

Việc phát triển phần mềm có thể khống chế đ-ợc Có những ph-ơngpháp, những kỹ thuật, những tiêu chuẩn và các công cụ khi đ-ợc vậndụng đúng thì chúng thúc đẩy việc phát triển thắng lợi dự án phần mềmvới ba mục tiêu trứ danh trong trí óc để phát triển phần mềm

1 Theo đúng lịch trình

2 Trong phạm vi ngân sách

3 Theo yêu cầu

Thắng lợi hay thất bại của dự án không chỉ liên quan đến ba mục tiêuphát triển cơ bản đó nh-ng cũng cả đến kỳ vọng của khách hàng: mộtkhách hàng có thể hài lòng với đầu ra của một dự án trong khi kháchhàng khác lại có thể không Do đấy, thành công của dự án đ-ợc xác địnhtối hậu ở sự hài lòng của khách hàng.

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

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

Thông tin về thành công và thất bại của phát triển phần mềm trong quákhứ trong phạm vi một công ty cần đ-ợc thu thập cùng với các minhchứng hỗ trợ khác bằng văn bản Mọi dự liệu cần đ-ợc nghiên cứu và cácchi chú cần đ-ợc chuẩn bị để chứng minh cho nhu cầu về ph-ơng phápphát triển mới Dòng cuối nên là việc ứng dụng các chu trình phát triểnphần mềm hữu hiệu mới là vì lợi ích của công ty

đây ra sao nhằm làm cho dự án trở lại đúng lịch trình ?”

Đây không phải là một tình huống không phổ biến ở đó, một ph-ơngthuốc thấn kỳ đã tìm cho một tình huống gần gây thảm họa Những dự ánquản lý tối có thể đi đến trì trệ và ngân sách v-ợt đến hai thậm chí batrăm phần trăm và trong vài tr-ờng hợp lại có thể bị bãi bỏ Hầu hếtnhững ph-ơng pháp quản lý dự án hiện đại ban đầu bao giờ cũng quantâm phòng xa (chứ không phải là hiệu chính) những vấn đề loại đó

Việc phòng ngừa những vấn đề thì dễ hơn và ít tốn kém hơn là giảiquyết chúng Những biện pháp phòng ngừa thiết thực hẳn là:

- Định vị sớm vấn đề và những vấn đề tiềm ẩn

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

- Lập kế hoạch tr-ớc (đối phó) với những vấn đề tiểm ẩn Những vấn

đề sẽ trở nên tốn kém hơn giải quyết khi dự án tiến triển đến những giai

đoạn phát triển cao hơn Những vấn đề bị lãng quên cũng có thể lantruyền sang các lĩnh vực khác của dự án làm cho việc hiệu chính chúngtrở nên khó khăn hơn Do đấy việc thiết lập những qui trình để định vịsớm và hiệu chính các vấn đề là quan trọng

Ch-ơng này giải quyết nguyên nhân của một số thể loại rất thôngth-ờng của vấn đề phát triển phần mềm và thảo luận tác động của chúng

đến quá trình phát triển Ch-ơng này cũng thảo luận việc dự kiến nhữngvấn đề nhằm giảm thiểu tác động của chúng tới dự án Các ch-ơng sau đề

ra những ph-ơng pháp phòng ngừa các vấn đề mô tả ở đây khỏi xảy ra

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

Có rất nhiều vấn đề cơ bản mà nhà quản lý dự án hình nh- tìm thấytrong bất cứ dự án phầm mềm nào Những vấn đề cơ bản đó gây ra bởinhững tình huống sau đây bao giờ cũng có thể phòng tr-ớc sẽ phát sinh:

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

- Phụ thuộc ở các nguồn bên ngoài (các ng-ời bán hàng, các chủ thầuphụ v.v )

- Các khó khăn trong kết thúc dự án

- Thay thế th-ờng xuyên nhân sự thực hành phát triển (xáo trộn độingũ)

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

- Dự toán tồi

- Theo dõi và giám sát không đầy đủ

- Thay đổi không kiểm soát đ-ợc

Con đ-ờng tốt nhất để định vị một vấn đề sớm là đi tìm nó Rõ ràng,

đầu tiên là tìm xem vần đề th-ờng nảy sinh nhiều nhất ở đâu Chẳng hạnthay đổi th-ờng xuyên và không kiểm tra đ-ợc với việc đặc tả các yêucầu th-ờng hiển nhiên là nguồn chủ yếu của những vấn đề thiết kế.Những chủ thầu phụ và ng-ời bán hàng không giám sát đ-ợc là một trongnhững nguồn bất ngờ, thông th-ờng nhất đặc biệt là lúc họ báo cáo cácvấn đề kỹ thuật và trì hoãn vào, chính những phút cuối cùng đối với cácnhà quản lý dự án thì việc biết phải kiếm ở đâu do đó quan trọng nh- việcbiết phải làm gì

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

Đặc tả các yêu cầu của dự án sẽ mô tả sản phẩm phải đ-ợc sản sinh rabởi nhóm phát triển (coi ch-ơng 4) Nếu những yêu cầu không đ-ợc đặctả đầy đủ thì chỉ các may mắn thuần túy mới đảm bảo đ-ợc là sản phẩm

đáp ứng yêu cầu của khách hàng4 Sau đây là một số thí dụ các vấn đềliên quan đến đặc tả yêu cầu nghèo nàn

- Quên các đặc điểm

Khách hàng tin chắc là một số đặc điểm bị bỏ quên hẳn phải nằm trongsản phẩm căn cứ ở những thảo luận không chính thức (th-ờng với ng-ờikhông đúng) Ghi chép, bình luận và nhận xét ở các cuộc họp nh-ngkhông căn cứ ở đặc tả yêu cầu chính thức

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

Đội ngũ phát triển đã tin chắc là khách hàng hẳn hết sức vui thích vềnhững đặc điểm ngoại hạng đ-ợc thêm vào sản phẩm (th-ờng không hỏi

ý kiến khách hàng) Một thí dụ hẳn là thêm sự truy nhập hệ thống bằngkhẩu ngữ khi khách hàng lại muốn hệ thống sẵn sàng cho bất cứ ai

- Đặc điểm mà chúng hoạt động khác với điều mong đợi

Khách hàng giải thích không đầy đủ về mộ đặc điểm cần thiết và thế là

đội ngũ phát triển hiểu cái yêu cầu đó theo cách hiểu của mình Một thí

dụ có thể là yêu cầu "cập nhật th-ờng xuyên cơ sở dữ liệu" Các nhà pháttriển đã tạo ra một hệ thống cập nhật cơ sở dự liệu mỗi lần một ngàytrong khi khách hàng muốn nói là một giờ mỗi lần

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

Khách hàng không cần thiết là một chuyên gia máy tính và do đó cóthể không ý thức đ-ợc là một đặc điểm, đặc biệt nào đó phải cần đến Thí

dụ có thể là nhu cầu về bade up đầy đủ; khách hàng có thể cho là bade up

là không cần thiết vì rằng nếu dịch vụ máy tính bị giám đoạn (thí dụ do

4 Từ khách hàng ở đây đ-ợc sử dụng theo nghĩa rất rộng bao gồm khách hàng chính thức, ban tiếp thị, nhóm ng-ời dùng, quản lý v.v

mất điện) thì việc mất một hay hai giao dịch l-u trữ trong bộ nhớ sẽchẳng thành vấn đề Thế nh-ng khách hàng có thể đã không xem xét sựviệc là những điều khiển đĩa cũng có thể đổ vỡ và mất đi mọi dự liệu củahọ.

Rõ ràng là những yêu cầu đ-ợc đặc tả kém lại là vấn đề cho nhà pháttriển nhiều cũng nh- cho khách hàng Dù sao, nhà sản xuất th-ờng ở vịthế tốt hơn để biên soạn những yêu cầu hơn là khách hàng Thông th-ờng

đặc tả yêu cầu tốt nhất là kết quả của sự cố gắng phối hợp của cả nhà pháttriển lần của khách hàng với văn bản thực đ-ợc soạn thành văn của nhàphát triển và đ-ợc chấp nhận bởi khách hàng

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

Thật cực kỳ hiếm khi tìm đ-ợc một dự án phần mềm qui hoạch tốt lại

đi đến kết cục thắng lợi với đặc tả yêu cầu đ-ợc dán nhãn Ph-ơng án 1.0.Thay đổi là không tránh khỏi suốt chu trình phát triển phần mềm Dù sao,trong phần lớn tr-ờng hợp một thay đổi đ-ợc đ-a ra chậm thì thực hiệnthay đổi lại càng tốn kém

Một số thay đổi thỏa đáng hẳn là phải quản lý đ-ợc Khi dòng các thay

đổi đổ vào nh- thác lũ thì chúng trở thành vấn đề Ngay chỉ một thay đổi

có thể thành vấn đề nếu nó đ-ợc yêu cầu ngay trong phát triển của dự án

và nếu nó dẫn đến thay đổi chủ yếu về ph-ơng h-ớng Những thay đổiquá mức tạo nên cái vẫn th-ờng đ-ợc coi là hội chứng mục tiêu di động.Nhà quản lý dự án không những thay đổi ph-ơng h-ớng và đội ngũ pháttriển trở thanh vừa bối rối vừa mất mục tiêu

Thay đổi có thể phá vỡ dự án nếu chúng không đ-ợc ghi thành văn bản

và giám sát đầy đủ Những thay đổi với số l-ợng thỏa đáng, phải đ-ợcquản lý, vận dụng cơ chế kiểm tra sự thay đổi một cách có hệ thống.Ph-ơng pháp đó trong phạm vi tổ chức kiểm tra cấu hình, đ-ợc thảo luận

ở ch-ơng 7

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

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

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

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

- Lịch trình quá ngắn hoặc cao thái quá

- Ngân sách quá thấp hay quá tăng giả tạo

- Quá thiếu hay quá thừa ng-ời làm và những sai lầm trong thiết kế kỹthuật, nh-:

- Những máy tính trong mục tiêu quá nhiều (và đắt hơn) hơn cần thiếthoặc không thể hỗ trợ ứng dụng đ-ợc phát triển Những vấn đề nảy sinh

từ dự toán thấp th-ờng gay cấn hơn là những vấn đề nảy sinh từ dự toáncao Hiểu rõ điều này, các nhà dự toán th-ờng thêm vào một số yếu tố bấttrắc (cho rằng đến 30%) trong dự toán của minh, giả định rằng quá caocòn hơn quá thấp Dù sao dự toán cao có thể không gây ra thất bại của dự

án nh-ng có thể ngăn cản dự án chẳng bao giờ đ-ợc khởi công Đã cónhiều ph-ơng pháp đ-ợc phát triển nhằm tạo ra các loại dự toán khácnhau ở các giai đoạn khác nhau của dự án (coi các ch-ơng 9 và 10) Dùsao, ngay những dự toán chuẩn bị tốt có thể dẫn đến những vấn đề nếuchúng không đ-ợc cập nhật trên một cơ sở định kỳ và đều đặn Rõ ràng làthông tin tốt hơn và đầy đủ hơn tạo nền dự toán tốt hơn Do đó khi dự ántiến triển và có nhiều thông tin hơn, dự toán cần đ-ợc xem xét lại và hiệuchỉnh Điều này dẫn đến việc giám định lại các quyết định phát triển, tạocho các vấn đề tiềm ẩn đ-ợc đề cập sớm tr-ớc khi chúng trở thành gaycấn (coi phần 2.2 về phân tích rủi ro)

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

Các vấn đề phát triển dự án th-ờng dễ quản lý nhất khi mọi nhân tốphát triển đ-ợc điều khiển bởi quản lý dự án Dù sao, điều này khôngphải bao giờ cũng có đ-ợc Nhiều dự án phụ thuộc ở nhiều nguồn bênngoài nh-:

- Chủ thầu phụ

- Ng-ời bán thiết bị

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

- Những ng-ời cung cấp dịch vụ (bảo trì, huấn luyện, lắp đặt v.v )

- Các chức năng hỗ trợ (thông tin điện thoại mạng, những cung cấp dựliệu Dự phụ thuộc vào các nguồn bên ngoài hẳn phải đ-ợc phản ánhtrống)

Kế hoạch phát triển dự án Điều này có nghĩa trong phạm vi các giao-ớc và dự toán nhận đ-ợc từ các nguồn khác Theo thế, dự toán trong kếhoạch không thể tốt hơn dự toán nhận từ các nguồn khác

Việc trông cậy vào các nguồn bền ngoài có thể gây ra những vấn đềsau:

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

- Sự kém cỏi quá chất l-ợng và thiết kế thiết bị phát triển và các thànhphần dự án bên ngoài

- Thành phần bên ngoài không t-ơng hợp do vì sự sai lệch của nhà pháttriển bên ngoài hay bán hàng với đặc điểm đã thỏa thuận hay đã công bố

- Hỗ trợ sản phẩm nghèo nàn đối với các thành phần bên ngoài Do có

ý thức đ-ợc những vấn đề tiềm ẩn đó, nhà quản lý dự án có thể đảm bảorằng họ đ-ợc định vị thích hợp trong hợp đồng hay thỏa thuận với nguồnbên ngoài Những vấn đề đó có thể đ-ợc ngăn ngừa nều đ-a vào tronghợp đồng những mức phát về chậm trễ trong giao hàng hay khuyết tậttrong sản phẩm (coi các ch-ơng 3 và ch-ơng 9) Những đề phòng sớm cóthể đ-ợc phát hiện khi th-ờng xuyên xét duyệt lại công việc đ-ợc pháttriển bởi chủ thầu phụ và đòi hỏi sẽ báo cáo tiến độ th-ờng kỳ

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

Nh- mọi nhà quản lý dự án đều biết, các dự án khó mà bắt đầu đ-ợckinh nghiệm cho thấy là chúng th-ờng không ít khó khăn để đi đến kếtthúc Đi tới đoạn kết của dự án, luôn luôn các bên quan tâm khác nhauphát sinh những yêu cầu Nh- phê phán những thay đổi mới và nhữnghoạt động phút chót khác nữa Điều này là đặc biệt có thực với những dự

án giá cố định phát triển cho khách hàng theo hợp đồng (coi ch-ơng 3).Những vấn đề chính liên quan đến việc kết thúc dự án là:

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

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

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

- Khó khăn trong việc giữ cho đội ngũ phát triển hợp lực lại với nhau

và năng động Khi tình hình căn thẳng giảm đi vào gần cuối dự án có tìnhtrạng sút giảm nhiệt tình t-ơng ứng trong những thành viên còn lại của

đội phát triển

Trách nhiệm của nhà quản lý dự án là đảm bảo cho việc kết thúc dự án

có trật tự và thắng lợi Điều này đ-ợc thực hiện nhờ việc qui hoạch chitiết lúc ban đầu dự án và quản lý dự án có hiệu quả xuyên suốt dự án Đặcbiệt, điều này đòi hỏi rằng:

- Kế hoạch thử nghiệm thu phải đ-ợc chuẩn bị lập tài liệu và đ-ợckhách hàng phê chuẩn tr-ớc khi kêt thúc dự án Mức độ nhân sự và sựphân công công việc phải đ-ợc lập lịch trình, có tính đến việc giảm dầntrong qui mô đội ngũ phát triển vào cuối dự án

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

Sự kết thúc thắng lợi của dự án là bắt đầu của chu trình phát triển khác:Những đặc tả yêu cầu, những kế hoạch thử nghiệm hay những kế hoạch

phát triển nghèo nàn, tất cả đều dẫn đến những vấn đề chủ yếu lúc kếtthúc dự án.

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

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

Frenkel (1985) báo cáo là nhu cầu kỹ s- phần mềm tăng theo hàm số

mũ trong khi năng suất tăng theo mức khoảng 5% mỗi năm Các tr-ờng

đại học Hoa kỳ và châu Âu đang không cung cấp kỹ s- phần mềm đủ để

bù đắp lỗ hổng giữa cung và cầu Trên thực tế không những lỗ hổngkhông đ-ợc lấp kín mà lại đang rộng ra ở mức đáng lo ngại

Khối l-ợng thời gian bình quân mà một kỹ s- phần mềm ở lại nghềgiảm khi yêu cầu kỹ s- tăng Điều này không chỉ gây ra bởi sự thuyênchuyển của kỹ s- phần mềm giữa các công ty mà cơ sở sự thuyên chuyểntrong phạm vi các công ti Vì các công ty này đang tìm cách sử dụng hữuhiệu hơn các kỹ s- của mình Sự thuyên chuyển trong phạm vi các công

ty không chỉ do tình trạng thiếu kỹ s- phần mềm mà còn do chi phí về họ

có thể vẫn ngăn trở thành việc tuyển bổ sung.5

Thuyên chuyển nhân sự bản thân nó là một vấn đề trọng yếu Sự ổn

định có của đội ngũ và do đó vào thắng lợi của dự án

Các vấn đề liên quan đến tuyển nhân sự và thuyên chuyển luôn baogồm:

- Việc đầu t- đáng kể đ-ợc đòi hỏi trong đ-ờng biểu diễn học tập và

đào tạo thành viên đội ngũ phát triển mới

- Thuyên chuyển nhân sự luôn luôn sẽ giảm đi tinh thần đội ngũ và tác

là nguồn phát triển quan trọng nhất cỡ chính họ đóng góp nhiều nhất cho

sự thành công hay thất bại của dự án

5 Kinh tế học cơ bản chỉ ra rằng khi có đ-ợc kỹ s- thì chi phí về họ sẽgiảm (căn cứ ở cung và cầu trong phạm vi thị tr-ờng nghề nghiệp Dùsao, trong những năm gần đây, việc cung các kỹ s- phần mềm không baogiờ đủ lớn để tạo ra tác động đó ngoại trừ ở những khoảng thời gian ngắnngủi tại các địa điểm cô lập)

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

Theo dõi và giám sát là những nhiệm vụ quản lý Khi các vấn đề phátsinh ở những lĩnh vực này và liên quan, chúng th-ờng là hậu quả của cácqui trình quản lý dự án không thích hợp và không hiệu lực Một trongnhững kết quả thông th-ờng nhất là nhà quản lý dự án không có ý thức về

sự tồn tại của những vấn đề chủ yếu ở giai đoạn mà chúng có thể đ-ợckiềm chế và hiệu chỉnh tốt nhất Việc theo dõi và giám sát có hiệu quả

đòi hỏi sự tiếp xúc trực tiếp giữa quản lý dự án và đội ngũ phát triển (coich-ơng 7) Một trong những nguyên nhân chủ yếu của các vấn đề theodõi và giám sát là hội chứng tháp ngà nơi tồn tại kẽ nứt th-ờng trực giữaquản lý dự án và phần còn lại của đội ngũ phát triển Điều này dẫn đến:

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

- Phát triển không phối hợp: tình huống này th-ờng đ-ợc mô tả khimột đội ngũ phát triển đang triển khai hai dự án khác nhau Điều này xảy

ra khi các thành viên đội ngũ phát triển không phối hợp và không đ-ợcgiám sát lại đã tiến hành theo những h-ớng khác nhau

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

Thông tin là thành phần cơ bản của bất cứ thể loại quản lý nào Do đấy,giám sát tồi đi đối với luông thông tin không thích hợp là cốt lõi của quản

lý dự án tồi Cả ba vấn đề trên mô tả hậu quả chung của quản lý tồi Danhmục các vấn đề kéo theo hẳn đúng là bao trùm hầu hết các kiểu vấn đềphát triển dự án Các ph-ơng pháp tạo lập những kênh thông tin có hiệulực và những qui trình báo cáo đ-ợc tổ chức tốt sẽ đ-ợc mô tả ở ch-ơng5

2.2 Phân tích rủi ro.

Nhìn xa là phẩm chất quản lý tuyệt hảo th-ờng có thể đ-ợc phát triểntheo kinh nghiệm Thật vậy, trong nhiều tr-ờng hợp, các vấn đề có thể

đoán tr-ớc Trong những tr-ờng hợp đó, nhà quản lý có thể lập kế hoạch

về khả năng mà vấn đề sẽ xảy ra khi dự tính khả năng của nó, đánh giátác động của nó và chuẩn bị tr-ớc các giải pháp Điều này th-ờng đ-ợcgọi là sự phân tích rủi ro và là một ph-ơng tiện hiệu quả để đấu tranhchống lại những vấn đề phát triển tiềm ẩn Tiến hành phân tích rủi ro cónghĩa là đã đ-ợc dự bị sẵn sàng Đây là một hình thức bảo hiểm, ý t-ởngcơ bản là nếu một vấn đề có nảy sinh thì một giải pháp đã có sẵn Giốngnh- mọi bảo hiểm, phân tích rủi ro th-ờng cũng phải trả giá Chi phí dựphòng cho sự phát sinh một vấn đề tr-ớc hết là chi phí để có đ-ợc giảipháp đối phó sẵn trong tay, trong khi vấn đề có thể xảy ra, có thể không.Trong một số tr-ờng hợp, chi phí có thể là tối thiểu: Chỉ là thời gian cần

để tiến hành phân tích và lập t- liệu cho giải pháp và thời gian để theodõi vấn đề Trong các tr-ờng hợp khác, chi phí có thể là lớn lao, chẳng

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

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

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

2 Bộ nhớ không đủ Cỡ của phân l-u trữ bộ nhớ của hệ thống có thể

v-ợt 8 mêga baitơ (cỡ bộ nhớ tối đa đ-ợc vi tínhcấ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 là chuyên gia hệ điều hành

duy nhất trong công ty và ông có thể bận không

đ-ợc sử dụng cho hệ thống này

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

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

cầu

5 Thuyên chuyển nhân

sự nhiều Lịch trình là xát xao với thời gian trống tốithiểu Nếu có sự thay thể nhân sự quá mức bình

quân trong phát triển chúng ta sẽ tr-ợt thêm lịchtrình

6 Truyền thông quá

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

ch-a bao giờ đ-ợc sử dụng với hệ thống này và

có thể không thích hợp

7 Chậm giao và hệ

thống phụ cơ sở dữ liệu Hệ thống phụ cơ sở dữ liệu đ-ợc hợp đồng phụvới tập đoàn phát triển phần mềm (SOI) cam kết

giao hàng 15-4 SOI có thể không giao đúngthời hạn nên làm chậm sự thích hợp và pha thửnghiệm cuối

Mọi lệ thuộc chủ yếu trong kế hoạch phát triển dự án đều đ-ợc xemxét và đánh giá Các thí dụ có thể là sự lệ thuộc ở nguồn bên ngoài nh-

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

Đặc tả thiết kế dự án là một kế hoạch chi tiết về việc làm thế nào đểcác yêu cầu đ-ợc thực hiện Các quyết định về sự thực hiện đ-ợc đòi hỏi

có thể chứa các vấn đề tiềm năng Chẳng hạn, các vấn đề sẽ nảy sinh ranếu phần cứng đ-ợc lựa chọn lại hóa ra không thích hợp, chẳng hạn nh-CPU quá chậm, mạng cục bộ không đủ tin cây, hoặc bộ nhớ không đủ.Sau đó mọi vấn đề dự liệu đ-ợc tập hợp lên danh sách, mỗi vấn đề

đ-ợc minh định và mô tả về tác động tiềm ẩn ảnh h-ởng tới dự án Bảng2.2 cho một thí dụ về danh sách vấn đề dự liệu

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

Trong khi mục tiêu không phải là liệt kế mọi vấn đề nhận thức đ-ợc

mà mỗi dự án có thể kinh qua, cần thiết là minh định những vấn đề hẳn

đ-ợc xem một cách hợp lý là có liên quan đến dự án Trong mọi tìnhhuống, giai đoạn phân tích sau đây đ-ợc nhằm để cách ly chỉ những vấn

đề nào có thể tác động lớn lao đến dự án và có thể một cách hợp lý đ-ọcxem là hẳn sẽ xảy ra

2.2.2 Pha phân tích

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

1 Dự toán xác suất vấn đề sẽ xảy ra

2 Dự toán sáo động của vấn đề tới dự án

3 Quy cho mức độ nghiêm trọng của vấn đề

Xác suất đó và tác động đó nếu đ-ợc dự toán bởi quá một ng-ời Mọihạng mục trong danh sách đ-ợc dự toán tốt nhất trong một cuộc họp duynhất đánh giá vấn đề để đảm bảo tính t-ơng đối của mức độ nghiêmtrọng, giữa các vấn đề không bị lệch lạc Mục tiêu là tránh những tìnhhuống khi việc chậm giao của bên cung cấp A đ-ợc một ng-ời dự toán là0.8 và việc chậm giao của bên cung cấp B đ-ợc một ng-ời khác dự toán

là 0.6 trong khi cả 2 nhà dự toán hẳn đồng ý là hai xác suất này là bằngnhau Nếu hai ng-ời ở trong cùng 1 phòng trong cùng 1 lúc thì sự lệc lạct-ơng đối đó giảm đi

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

1 Gán một số kỹ vọng giữa 1 và 10 căn cứ ở xác suất là vấn đề sẽ xảy

ra, với 10 biều xác suất cao, và 1 xác suất thấp nhất (thí dụ nhân xác suấtvới 10)

2 Gán một số giữa 1 và 10 căn cứ ở tác động của vấn đề với dự án với

10 biểu thị tác động cao và 1 tác động thấp

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

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

là ng-ời theo dõi để theo dõi vấn đề và báo động quản lý dự án khi kếhoạch đối phó bất ngờ cần đ-a vào hoạt động giai đoạn này đ-ợc trìnhdiễn ở bảng 2.3

Phân tích rủi ro đ-ợc hoàn thiện đầu tiên càng sớm càng tốt trong dự

án, nh-ng không đ-ợc chậm hơn lúc kết thúc pha yêu cầu (coi ch-ơng 4)

Dù sao, phân tích rủi ro không phải là hoạt động một lần khi dự án tiếntriển, những vấn đề bổ sung có thể đ-ợc dữ liệu và những vấn đề khác cóthể cần đ-a ra khỏi danh sách vấn đề Khi có đ-ợc thông tin mới, việc

đánh giá mức độ nghiêm trọng hoặc xác suất hẳn phải đ-ợc cải tiến Do

đấy các bảng phân tích rủi ro nên đ-ợc duyệt xét và cập nhật định kỳ và ởbất cứ khi nào khi có một sự cố quan trọng xảy ra (thí dụ một chủ thầuphụ thông báo chậm trễ lịch trình hay một quyết định thiết kế chủ yếuthấy cần phải hiệu chỉnh)

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

chậm 16 Hợp đồng với công ty đãphát triển gói truyền thông

nhị phân thích nghi cho góivói dự án này

H.Troy

4 Thời gian đáp ứng

của hệ thống quá

chậm

15 Cho vào điều khỏan thỏa

thuận nâng cấp CPU tronghợp đồng mua máy tính

Y.Krot

2 Bộ nhớ không đầy

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

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

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

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

Nói chung, các kế hoạch đối phó bất ngờ có thể đ-ợc nhìn nhận theonh- cái kế hoạch, hành động đ-ợc xếp vào ngăn kéo để phòng khi dùng

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

Lấy thí dụ về quá trình hoàn chỉnh chúng ta thử xem xét một dự ántruyền thông cần đến một máy tính trung tâm nối bằng mạng diện rộngvới vài vị trí máy tính nhỏ, có hai vấn đề tiềm ẩn đ-ợc minh định

- Hai máy tính có kiến trúc khác nhau có thể diễn giải thể thức truyềnthông đã thiết kế đ-ợc một cách (thí dụ trình tự của các từ hai byte có thể

bị đảo ng-ợc - LSB MSB chứ không phải MSB LSB)

- Công ty điện thoại đ-ợc chọn có thể không có khả năng lắp đặt

đ-ờng dây thử nghiệm đún ghẹn cho pha tích hợp

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

ty khác đ-ợc hủy và khả năng phí hủy bỏ phải trả

Một kỹ s- khác Jndira Hepe chịu trách nhiệm về theo dõi vấn đề thểthức truyền thông không t-ơng hợp Chị ta phải đảm bảo gòi truyền thông

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

2.3 Tóm tắt

Các ph-ơng pháp quản lý dự án hiện đại lúc đầu quan tâm đến việccác vấn đề phát triển dự án (việc phòng ngừa không hiệu chỉnh) Phòngngừa các vấn đề thì dễ hơn và ít tốn kém hơn là giải quyết chúng, nhữngbiện pháp phòng ngừa có hiệu quả nêu là:

- Định vị các vấn đề và các vấn đề tiềm ẩn sớm

- Giải quyết vấn đề tr-ớc khi tuột khỏi tầm tay

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

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

- Xác định yêu cầu không đầy đủ

- Thay đổi luôn

- Dự toán tồi

- Tùy thuộc ở nguồn bên ngoài (ng-ời bán, chủ thầu phụ v.v )

- Khó khăn trong kết thúc dự án

- Luôn luôn thay thế nhân sự phát triển (thuyên chuyển nhân sự)

- Theo dõi và giám sát không đầy đủ

Cách tốt nhát để định vị một vấn đề là sớm đi tìm kiếm nó Rõ ràng,tr-ớc hết là tìm xem ở đâu vấn đề hay diễn ra nhất Chẳng hạn nhữngthay đổi đặc tả yêu cầu luôn luôn và không kiểm tra là không thuận lợi

đ-ợc coi nh- nguồn gốc chủ yếu của những vấn đề thiết kế Những chủthầu phụ và ng-ời bán không giám sát đ-ợc là một trong hầu hết nhữngnguồn gốc bất ngờ, những vấn đề kỹ thuật l-u lại và chậm chễ vào phútchót Với nhà quản lý dự án thì biết đ-ợc ở đây phải tìm là quan trọngnh- biết đ-ợc phải làm gì

Biết phải làm gì bao gồm cả việc chuẩn bị tr-ớc sự xuất hiện của vấn

đề Trong nhiều tr-ờng hợp, các vấn đề có thể đ-ợc dự liệu Nhà quản lý

dự án có thể lập kế hoạch về khả năng vấn đề sẽ xảy ra bằng cách dự tínhxác suất của nó, -ớc l-ợng tác động của nó và chuẩn bị giải pháp thaythế Cái đó đ-ợc gọi là phân tích rủi ro và là biện pháp có hiệu quả trongviệc đấu tranh với những vấn đề phát triển tiềm ẩn

Tiến hành phân tích rủi ro có nghĩa là chuẩn bị tr-ớc Đây là một hìnhthức bảo hiểm mà ý t-ởng cơ bản là nếu một vấn đề xảy ra, giải pháp đãsẵn sàng Giống nh- mọi bảo hiểm, phân tích rủi ro th-ờng phải trả giá.Chi phí chuẩn bị cho việc một vấn đề xảy ra tr-ớc hết là chi phí để có giảipháp gồm thay thế có sẵn trong tay Trong một số tr-ờng hợp, chi phí cóthể chỉ là tối thiểu: thời gian cần để phân tích và lập tài liệu cho giải pháp

và thời gian theo dõi vấn đề Trong các tr-ờng hợp khác, chi phí có thểlớn đáng kể: giá của một bộ phận thay thế của thiết bị phát triển Trong

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

Bài tập

1 Một công ty dịch vụ truyền hình cáp đang chuẩn bị thiết lập dịch vụtrong thời gian 8 tháng Công ty cung cấp dịch vụ cho các khách hàng vớiphí cố định hàng tháng tùy thuộc ở qui mô dịch vụ mà họ yêu cầu Công

ty cũng cho chiếu những phim mới mỗi phim có thể cho một khách hàngxem theo yêu cầu qua điện thoại với công ty

Giờ công ty đang trong quá trình đặt mua thiết bị, mua các ph-ơng tiện

và ký với khách hàng Một công ty phần mềm đã hợp đồng phát triển một

hệ thống làm hóa đơn cho các khách hàng Hệ thống này sẽ giao diện vớithiết bị để nhận thông tin về các buổi chiếu phim mói trên màn ảnh và sẽgiao diện với cơ sở dữ liệu của khách hàng để thông tin đều đặn về hóa

đơn hàng tháng

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

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

động của dự án và các trị giá xác suất

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

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

độ nghiêm trọng mà bạn gợi ý ở bài tập 2

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

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

Thảo luận :

a) Các danh mục vấn đề dự liệu khác nhau

b) Các kế hoạch ngẫu nhiên khác nhau

c) Các ph-ơng pháp khác nhau để phân định mức độ nghiêm trọng(liệu có 2 nhóm nào đã gợi ý ph-ơng pháp t-ơng tự ?)

Ch-ơng ba

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

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

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

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

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

Ch-ơng này đề cập đến mối quan hệ giữa khách hàng và nhà phát triểnphần mềm và cung cấp một số h-ớng dẫn làm sao tránh những cái bẫy cổ

điển do những lợi ích mẫu thuẫn nhau Mổc dù nhiều những vấn đề đó làchung cho mọi quan hệ khách hàng, nhà phát triển một số vấn đề tranhcãi là đặc biệt cho phát triển phần mềm Việc phát triển phần mềm là rất

ít xác định hơn và nhiều rủi ro hơn các lĩnh vực khác của công nghệ Điềunày th-ờng dẫn đến những hiểu lầm và bất đồng đáng ra đã có thể tránh

đ-ợc nếu đ-ợc dự liệu và kiềm chế đủ sớm

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

đ-ợc thẳng thầu sau khi lựa chọn, sẽ đ-ợc coi là nhà phát triển

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

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

đến tranh chấp về quyền lợi nh- thế

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

1 Chi phí cộng thêm (cũng gọi là chi phí theo thời gian và vật liệu)

2 Giá cố định

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

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

Phí cộng thêm là mối quan hệ theo hợp đồng theo đó ng-ời phát triển

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

Lấy thí dụ, công ty Alpha có thể hợp đồng với công ty phần mềm Bêta

để phát triển một hệ thống Công ty Bêta sẽ đ-ợc công ty Alpha trả cho

180 cho mỗi giờ các kỹ s- của minh đầu t- cho dự án một khoản 20% bổsung có thể đ-ợc thêm vào để bù đắp dịch vụ quản lý th- ký hay vănphòng khác Các chi phí phụ phát sinh bởi công ty Bêta vì lợi ích của dự

án sau đó đ-ợc công ty Alpha bồi hoàn các chi phí đó có thể bù đắp cáclĩnh vực nh-:

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

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

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

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

Hợp đồng phí cộng thêm phải bao gồm các điều sau:

- Danh sách những ng-ời đ-ợc giao làm dự án

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

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

- Mức công việc hàng giờ hay hàng ngày cho mỗi ng-ời

Giá suất lập phiếu có thể là giá suất cố định cho mọi ng-ời đ-ợc giaoviệc của dự án hay mức cá nhân có thể đ-ợc đặt cho từng lớp ng-ời.Chẳng hạn với mỗi giờ làm việc cho dự án, ng-ời sản xuất sẽ lập phiếuthanh toán $80, bất kể ai làm việc cho giờ đó Hay hợp đồng có thể qui

định là kỹ s- thiết kế đ-ợc lập phiếu thanh toán $120 một giờ, ng-ời lậpmã $60 một giờ, ng-ời viết t- liệu $50 một giờ và cứ tiếp tục Ph-ơngpháp giá suất lập phiếu hợp đồng phí cộng thêm hầu nh- khó nhất làph-ơng pháp lập phiếu thanh toán cá nhân theo Franh Jones đ-ợc lậpphiếu thanh toán $90 một giờ John Shith $75 v.v Điều này có nghĩa mỗikhi một ng-ời đ-ợc thay thế hay bổ sung cho dự án thì giá suất theo giờlại phải th-ơng thảo lại

Đối với một tổ chức phát triển phần mềm, có thể có những thuận lợithiết thực trong cá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- trong phần lớn tr-ờng hợp, những thuận lợi đó lại đi đốivới một số bật lợi bao gồm:

- Lợi tức kihnh doanh thập

- Có thể có sự bất bình trong nhân sự

- Kiểm tra nhân sự và công việc phát triển

- Bất đồng tiềm ẩn với khách hàng do thiếu các bị giảm đi, mục đích

đ-ợc xác định rõ và nhân tố thúc đẩy

- Tính kế tục của hợp đồng không bảo đảm

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

điều này có thể gây ra bất mãn

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

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

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

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

Bất lợi có thể có của khách hàng là:

- Chi phí phát triển gia tăng

- Khách hàng phải đảm nhận rủi ro trong phát triển

- Tham gia nhiều hơn trong phát triển

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

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

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

Hợp đồng giá cố định là một cam kết của ng-ời phát triển sẽ cung cấpsản phẩm hay dịch dụ thỏa thuận với phí thỏa thuận trong phạm vi lịchtrình thỏa thuận Điều này t-ơng tự với mua tíc kê xe buýt theo đó công

đi xe buýt thỏa thuận đ-a khách hàng đến nơi nhất định trong phạm vithời gian biểu đã công bố với phí thỏa thuận Tờt nhiên, du khách có thểchọn thuê xe chứ không mua tic kê xe buýt và rồi tự mình lái đến nơi củamình Dù sao, điều này có thể trở nên tốn kém hơn và đòi hỏi ở ng-ời dukhách đôi chút kỹ năng và kiến thức tr-ớc nh- kỹ năng lái xe và kiếnthức về hành trình đến nơi Nừu du khách (hay khách hàng) phải quyết

định giữa việc tự mình tạo ra dịch vụ và việc hợp đồng với ai đó để cungcấp dịch vụ

Hợp đồng giá cố định chỉ có thể đ-ợc vận dụng cho một dự án xác

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

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

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

- Khống chế đầy đủ quá trình phát triển

- Lợi ích kinh doanh có thể cao hơn

- Cam kết cho dự án trọn vẹn

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

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

- Đảm nhận rủi ro kinh doanh và phát triển

- Bất đồng tiềm ẩn với khách hàng do:

+ thay đổi yêu 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 sẽ th-ờng chuộng hợp đồng giá cố

định Đó th-ờng là những dự án tạo dựng danh tiếng chuyên môn củacông ty và phát sinh lợi tức đảm bảo tăng tr-ởng Bất hạnh là những dự

án này cũng gây ra lỗ và th-ờng tác hại nghiêm trọng cho công ty cạnhtranh gay gắt để có hợp đồng quan trọng đôi khi làm cho công ty nhậnthầu giá thấp cuối cùng gây ra lỗ cho ng-ời phát triển

Hầu nh- không thể tránh khỏi trong bất kỳ dự án nào ng-ời phát triển

đ-ợc đòi hỏi thay đổi yêu cầu trong quá trình phát triển Những thay đổinh- thế th-ờng đi liền với chi phí bổ sung đòi khánh hàng và bao giờcũng là nguyên nhân bất đồng giữa ng-ời sản xuất và khách hàng Điềunày th-ờng là do yêu cầu không rõ hay mơ hồ và nó lại dẫn đến bất đồng

về chỉ tiêu trong việc hoàn thành dự án Về cơ bản, điều này làm cho hợp

đồng trở lại trạng thái không đ-ợc xác định đầy đủ

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

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

- Hầu hết các rủi ro phát triển đ-ợc chuyển sang ng-ời phát triển

+ tham gia tối thiểu trong quá trình phát triển

Bất lợi cho khách hàng là:

- Rủi ro chậm giao sản phẩm

- Giảm sự khống chế quá trình phát triển

- Bất đồng tiềm ẩn với ng-ời sản xuất do:

+ chi phí cao về thay đổi yêu cầu

+ chỉ tiêu hoàn thành dự án không rõ ràng

- giải thích yêu cầu

Ngay dù quyền lợi của ng-ời sản xuất và khách hàng có thể khác nhau,với hợp đồng giá cố định vẫn th-ờng đ-ợc cả hai bên -a chuộng Nừu dự

án là chi tiết đủ mức và rõ ràng và nếu quan hệ giữa hai bên đ-ợc xác

định rõ thì các hợp đồng giá cố định có thể có lợi cho cả ng-ời phát triểnlẫn khách hàng

3.2 Các mối quan hệ khác giữa khách hàng - nhà phát triển.

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

đồng cổ truyền giữa ng-ời phát triển và khách hàng Có nhiều biến thứccủa hai mối quan hệ cơ bản đó kể cả các ghép nối phù hợp với các dự án

đặc tr-ng Một số trong những quan hệ đó liên kết với vai trò của kháchhàng và ng-ời phát triển nhằm tạo nhiều yếu tố kích thích hơn cho ng-ờiphát triển hỗ trợ mục tiêu của khách hàng ngoài những tránh nhiệm theohợp đồng

Những loại khác của quan hệ khách hàng - ng-ời phát triển bao gồm:

- Phối hợp giá cố định và phí cộng thêm

- Liên doanh

- Thỏa thuận bản quyền

- Cam kết lâu dài

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

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

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

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

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

Phát triển phần mềm theo hợp đồng bắt đầu từ việc khách hàng lựachọn ng-ời phát triển phần mềm Yêu cầu về đề nghị hay RFT (ở Anhcũng gọi là mời thầu) là b-ớc đầu của quá trình lựa chọn Để hiểu xem

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

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

Đây cũng là giai đoạn mà tổ chức quyết định xem dự án có thể đ-ợcphát triển nội bộ hay sẽ phải hợp đồng với một công ty khác Các RFPkhông chỉ đ-ợc phát ra cho các dự án hoàn chỉnh; chúng cũng có thể

đ-ợc phát ra để bảo d-ỡng phần mềm của một hệ thống hiện có hay choriêng một pha đơn lẻ của dự án Mọi RFP chuẩn bị kỹ phải có cũng thôngtin cơ bản; các RFP không hoàn chỉnh cho kết quả là các đề nghị khônghoàn chỉnh

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

Tr-ớc khi thuê các dịch vụ phát triển của một tổ chức khác, một số vấn

đề cơ bản cần đ-ợc xem xét tới:

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

- Các tổ chức nào là gì đ-ợc xem xét cho công việc đó ?

- Loại hợp đồng nào sẽ đ-ợc chào (giá cố định, phí cộng thêm v.v )

- Phải nhận đ-ợc các đáp ứng nào từ các nhà phát triển sao cho đápứng đó có thể đ-ợc xem xét ?

- Khi nào quá trình lựa chọn ng-ời phát triển phải đ-ợc hòan tất ?

- Khi nào dự án phải hoàn thành và khi nào các hợp đồng trung gianphải sẵn sàng ?

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

?

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

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

3.3.2 Chuẩn bị các RFP.

Yêu cầu tốt với đề nghị là yêu cầu sẽ lôi cuốn đ-ợc những đáp ứng tốtnhất (đề nghị) Chuẩn bị RFP tốt th-ờng đòi hỏi sự cộng tác của nhiềung-ời, mỗi một ng-ời đ-ợc giao trách nhiệm về những phần đặc biệt củaRFP

Một RFP phải bao gồm những phần sau:

1 Phát triển vấn đề và các mục tiêu dự án

Phần này cung cấp thông tin nền tảng chung, kể cả mô tả vấn đề cần

đ-ợc giải quyết Phần này phải cung cấp mọi chi tiết thích đáng cần thiết

để hiểu vấn đề, kể cả biểu đồ, báo cáo và thí dụ

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

Phần này mô tả những yêu cầu kỹ thuật đặc biệt của hệ thống nh-:

- Các giao diện với các hệ thống hiện có