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

Quản lý dự án phần mềm 1 Quản lý dự án phần mềm 2 Mục lục Lời nói đầu 6 Ch•ơng 1. Nhập môn về quản lý dự án phần mềm Nhập môn 1.1. Nhu cầu đang gia tăng về phần mềm 1.2. Vai trò của việc quản lý trong phát triển phần mềm 1.3. Một thí dụ 1.4. Giành sự chấp nhận các thủ tục phát triển mới 1.5. Tóm tắt 10 10 11 13 15 17 Ch•ơng 2. Những vấn đề phát triển phần mềm Một chút phòng xa 2.1. Những vấn đề cơ bản 2.1.1. Những vấn đề liên quan đến các yêu cầu của dự án 2.1.2. Những thay đổi th•ờng xuyên 2.1.3. Dự toán và những vấn đề liên quan 2.1.4. Nguồn lực bên ngoài 2.1.5. Kết thúc một dự án phần mềm 2.1.6. Tuyển dụng nhân viên và thuyên chuyển 2.1.7. Theo dõi và giám sát 2.2. Phân tích rủi ro 2.2.1. Dự kiến những vấn đề cần giải quyết 2.2.2. Pha phân tích 2.2.3. Thực hiện các kế hoạch đối phó bất ngờ 2.3. Tóm tắt Bài tập 19 19 20 21 21 22 23 24 25 25 26 27 29 31 32 Ch•ơng 3. Phát triển phần mềm theo hợp đồng Quan hệ khách hàng - nhà phát triển 3.1. Chi phí cộng thêm đối lại với giá cố định 3.1.1. Hợp đồng phí cộng thêm 3.1.2. Hợp đồng giá cố định 3.2. Các mối quan hệ khác gi•ã khách hàng - nhà phát triển 3.3. Yêu cầu đối với một đề xuất (RFP) 3.3.1. Một số vấn đề cơ bản 3.3.2. Chuẩn bị của RFP 3.3.3. Phát yêu cầu đề xuất RFP 3.4. Đề xuất 3.4.1. Đề xuất không do yêu cầu 3.4.2. Đề xuất khi có yêu cầu 3.4.3. Đội ngũ chuẩn bị đề xuất 3.4.4. Khuân dạng đề xuất 3.4.5. Khẳng định công việc (SOW) 3.5. Duyệt xét đề xuất và quá trình lựa chọn 3.5.1. Ban tuyển chọn đề xuất 33 33 34 36 37 38 39 39 42 43 43 44 44 45 48 49 49 Quản lý dự án phần mềm 3 3.5.2. Ph•ơng pháp đánh giá đề xuất 3.6. Một số nhận định bổ sung về đề xuất 3.6.1. Những vấn đề liên quan đến khách hàng 3.6.2. Những vấn đề liên quan đến ng•ời đề nghị 3.7. Tóm tắt Bài tập 50 52 52 53 54 55 Ch•ơng 4. Chu trình phát triển phần mềm Các biểu thái về chủ đề thác n•ớc 4.1. Pha quan niệm 4.1.1. Bàu không khí trong pha quan niệm 4.1.2. Những vấn đề trong pha quan niệm 4.2. Pha yêu cầu phần mềm 4.2.1. Bàu không khí trong quá trình pha yêu cầu 4.2.2. Các vấn đề trong pha yêu cầu 4.3. Pha thiết kế 4.3.1. Bàu không khí trong pha thiết kế 4.3.2. Những vấn đề trong pha thiết kế 4.4. Pha thực hiện 4.4.1. Bàu không khí trong pha thực hiện 4.4.2. Những vấn đề trong pha thực hiện 4.5. Pha tích hợp và thử nghiệm 4.5.1. Bàu không khí trong pha tích hợp và thử nghiệm 4.5.2. Những vấn đề trong pha tích hợp và thử nghiệm 4.6. Pha bảo trì 4.6.1. Bàu không khí trong pha bảo trì 4.6.2. Những vấn đề trong pha bảo trì 4.7. Tóm tắt Bài tập 57 60 61 62 62 63 63 65 66 67 68 70 70 71 73 74 75 76 77 78 79 Ch•ơng 5. Nguyên tắc quản lý các kỹ s• phần mềm Họ có thực có gì khác nhau không ? 5.1. Cơ cấu tổ chức dự án phần mềm 5.2. Cơ cấu đội ngũ 5.2.1. Lãnh đạo đội 5.2.2. Các đội dân chủ 5.2.3. Các đội kỹ s• tr•ởng 5.2.4. Các đội chuyên gia 5.3. Các kỹ thuật báo cáo cơ bản 5.3.1. Báo cáo tình hình 5.3.2. Các cuộc họp về tình hình dự án 5.4. Những đ•ờng lối chung trong quản lý các kỹ s• phần mềm 5.5. Tóm tắt Bài tập 80 81 85 85 87 87 88 89 90 91 92 94 95 Ch•ơng 6. Chia để trị các dự án lớn thế nào: phân chia và chiếm lĩnh. Quản lý dự án phần mềm 4 Nhu cầu lớn không có nghĩa khó 6.1. Tinh chế từng b•ớc một 6.1.1. Phân giải chức năng 6.1.2. Phân giải thiết kế 6.2. Cơ cấu phân tích công việc 6.2.1. Phân giải dự án 6.2.2. WBS làm công cụ quản lý dự án 6.3. Xử lý những dự án lớn 6.3.1. Các hệ thống phụ 6.3.2. Đ•ờng lối phân giải chức năng 6.3.3. Đ•ờng lối phân giải thiết kế 6.3.4. Đ•ờng lối phân giải nhiệm vụ công việc 6.4. Tóm tắt Bài tập 96 96 98 99 102 103 105 106 106 108 109 110 111 112 Ch•ơng 7. Các chức năng hỗ trợ dự án Hỗ trợ quản lý dự án 7.1. Kiểm tra cấu hình phần mềm (SCC) 7.1.1. Thuật ngữ kiểm tra cấu hình 7.1.2. Nguồn lực kiểm tra cấu hình 7.1.3. Kế hoạch quản lý cấu hình phần mềm 7.1.4. Một số đ•ờng lối chung 7.2. Bảo đảm chất l•ợng phần mềm (SQA) 7.2.1. Cung cấp phần mềm có chất l•ợng 7.2.2. Nguồn lực kiểm tra chất l•ợng 7.2.3. Kế hoạch bảo đảm chất l•ợng phầm mềm 7.2.4. Độ đo chất l•ợng phần mềm 7.2.5. Một số đ•ờng lối chung 7.3. Thử nghiệm phần mềm 7.3.1. Các loại thử nghiệm phần mềm 7.3.2. Các thủ tục thử nghiệm chính thức 7.3.3. Một số đ•ờng lối chung 7.4. Tóm tắt Bài tập 115 116 118 119 121 123 126 126 128 130 132 133 134 135 137 138 139 140 Ch•ơng 8. Tiêu chuẩn phát triển phần mềm Tiêu chuẩn phát triển: tai hại cần thiết 8.1. Tổng quan các tiêu chuẩn phát triển phần mềm 8.2. Tiêu chuẩn US DOD 2167 8.2.1. Tổng quan tiêu chuẩn 2167 8.2.2. Rà soát và kiểm toán 8.2.3. Mô tả hạng mục dữ liệu (DIDS) 8.2.4. Lấy kích th•ớc tiêu chuẩn 8.2.5. Lợi và bất lợi của tiêu chuẩn 2167 8.3. Các tiêu chuẩn công nghệ phần mềm IEEE 8.3.1. Tổng quan tiêu chuẩn IEEE 8.3.2. Phân loại IEEE về các tiêu chuẩn công nghệ phần 142 142 145 146 148 148 154 156 156 157 Quản lý dự án phần mềm 5 mềm 8.3.3. Lợi và bất lợi của tiêu chuẩn IEEE 8.3.4. So sánh các tiêu chuẩn IEEE và DOD 8.4. Các tiêu chuẩn Ada 8.4.1. Môi tr•ờng Ada 8.4.2. Tiêu chuẩn IEEE cho các Ada PDL 8.5. Các tiêu chuẩn phát triển phần mềm khác 8.6. Tóm tắt Bài tập 159 159 164 164 165 165 166 167 168 Ch•ơng 9. Lập trình dự án Lập trình: vấn đề 9.1. Kế hoạch phát triển dự án 9.2. Các hoạt động theo lập trình và mốc 9.2.1. Danh mục hoạt động theo lập trình 9.2.2. Các cột mốc và đ•ờng mốc chủ yếu 9.3. Các biểu đồ Gantt 9.4. Các biểu đồ PERT và con đ•ờng tới hạn 9.4.1. Đ•ờng tới hạn 9.4.2. Các khối ch•ơng trình PERT và việc tăng c•ờng 9.5. Nhân sự lập trình 9.5.1. Qui mô đội ngũ phát triển 9.5.2. Kỹ năng và kinh nghiệm 9.5.3. Tháng của con ng•ời bất nghì 9.6. Lập lịch các nguồn lực 9.6.1. Lập lịch không gian làm việc 9.6.2. Thiết bị lập trình 9.6.3. Chủ bán các nhà thầu phụ 9.7. Kiểm chứng và cập nhật ch•ơng trình 9.7.1. Báo cáo định kỳ 9.7.2. Các hoạt động kiểm chứng khác 9.7.3. Cập nhật ch•ơng trình 9.8. Một số đ•ờng lối chung cho việc lập trình và qui hoạch 9.8.1. Tinh lọc danh mục hoạt động ban đầu 9.8.2. Giành đ•ợc phê chuẩn ch•ơng trình 9.8.3. Mối quan hệ giữa ch•ơng trình, tài nguyên, chất l•ợng và tính chức năng 9.9. Tóm tắt Bài tập 170 171 173 174 176 177 180 182 182 183 184 187 188 189 189 190 191 192 192 193 193 194 194 195 197 198 199 Ch•ơng 10. Chuẩn bị dự toán: ph•ơng pháp và kỹ thuật Dự toán: vấn đề 10.1. Dự toán dự án 10.2. Dự toán từng b•ớc 10.2.1. Những thành phần đ•a khỏi giá 10.2.2. Những thành phần d• thừa kinh nghiệm 10.2.3. Những thành phần có một phần kinh nghiệm 200 201 202 203 203 205 Quản lý dự án phần mềm 6 10.2.4. Phát triển mới 10.2.5. Phân tích chi tiết dự án ở mức rủi ro 10.3. Uớc định phát triển mới 10.3.1. Những ph•ơng pháp kiểu đầu (nguyên mẫu) 10.3.2. Những ph•ơng pháp thống kê 10.4. Mô hình chi phí xây dựng (Cocomo) 10.4.1. Mức nhân sự 10.4.2. Mức độ phức tạp 10.4.3. Yếu tố độ tin cậy 10.4.4. Môi tr•ờng phát triển 10.4.5. Các thứ hệ 10.4.6. Thuật toán dự toán phí 10.5. Chức năng phân tích điểm 10.5.1. Những b•ớc FPA cơ bản 10.5.2. ứng dụng của FPA 10.6. Dự toán là một lĩnh vực 10.7. Dự toán tài nguyên phần cứng 10.7.1.Tải trọng CPU 10.7.2. L•u trữ dự liệu 10.7.3. Tốc độ 10.8. Tổng phí không phát triển 10.9. Tóm tắt Bài tập 206 206 207 207 209 210 210 213 215 216 218 219 221 221 224 225 229 229 233 236 238 239 241 Tham khảo 243 Tài liệu đọc thêm Lời nói đầu Quản lý dự án phần mềm 7 Đây là cuốn sách về quản lý dự án phần mềm; nó không phải là một cuốn sách tiếp nữa về công trình phần mềm. Đã có nhiều cuốn sách tham khảo về công trình phần mềm (coi danh mục tham khảo ở cuối cuốn sách này). Mục tiêu của sách này là trình bày công việc phát triển phần mềm theo quan điểm của nhà quản lý chứ không phải theo quan điểm của nhà phát triển. Cuốn sách tập trung, trong một cuốn duy nhất nhiều thực tiễn và kỹ thuật quản lý phần mềm hiện đại đã đ•ợc phát triển và tinh lọc trong suốt thập kỷ qua. Quản lý dự án đ•ợc trình bày nh• là một kỹ năng lĩnh hội đ•ợc và chứ không phải nh• là của trời cho. Chắc chắn, việc quản lý dự án đòi hỏi tài năng quản lý, nh•ng bản thân tài năng không đ•ợc hữu hiệu. Việc vận dụng thiết thực các thủ tục phát triển phần mềm hiện đại đòi hỏi có các nhà quản lý chuyên nghiệp. Vì đây là cuốn sách thực hành (chứ không phải là một công trình lý thuyết) nên nhiều ph•ơng pháp và kỹ thuật đ•ợc mô tả không có cơ sở lý thuyết cho riêng nó. Tuy nhiên những tham khảo sẽ đ•ợc cung cấp suốt cuốn sách dành cho những ai quan tâm đến cơ sở lý thuyết. Danh mục kèm các tham khảo và tài liệu để đọc đ•ợc gợi ý có ở cuối cuốn sách này. Nhất thời, độc giả có thể thấy một số đoạn đ•ợc nhắc lại trong cuốn sách này. Sở dĩ có điều này là để giải quyết cái th•ờng đ•ợc gọi là tình huống năm ngón tay. Điều này xảy ra khi mỗi năm ngón tay của độc giả cần đ•ợc cài vào cuốn sách để đánh dấu trong khi độc giả l•ỡng lự giữa các ch•ơng nhằm bao quát đ•ợc một chủ đề đặc biệt. Cuốn sách này có giảm nhu cầu phải đánh dấu bằng cách lặp lại cái giải thích vắn tắt bất cứ chủ đề chủ yếu nào đ•ợc tham chiếu ngay dù chủ đề đã đ•ợc thảo luận chi tiết ở đâu đó. Suốt cuốn sách những hạng mục tháng công và năm công đã đ•ợc sử dụng thay cho các hạng mục cũ tháng ng•ời và năm ng•ời. Những từ này đ•ợc thảo luận chi tiết ở phần 9.5.3. Đối t•ợng đọc đ•ợc chủ định. Quản lý dữ án phần mềm: Một tiếp cận cho ng•ời thực hành đ•ợc chủ định cho đối t•ợng đa dạng. Tr•ớc hết và chủ yếu sách đ•ọc chủ định làm nguồn tham khảo cho các nhà quản lý dự án phần mềm đang thực thi nhiệm vụ quản lý và trên cơ sở đó nó đ•ợc sắp xếp sao cho đề tài chủ yếu bao quát ở mỗi ch•ơng (trừ ch•ơng 1). Điều này đ•ợc thảo luận thêm trong giải thích sau về việc bố trí nội dung sách. Cuối cùng, cuốn sách có thể dùng làm tham khảo cho các kỹ s• phần mềm muốn mở rộng kiến thức của minh sang những lĩnh vực quản lý dự án kỹ thuật. Bố trí của cuốn sách Quản lý dự án phần mềm 8 Nói chung, m•ời ch•ơng của cuốn sách xuất hiện theo trình tự lôgíc và cung cấp cho việc đi đầu vào lĩnh vực quản lý dự án phần mềm. Tham khảo nhanh đặt ở cuối mỗi ch•ơng có dạng tóm tắt mở rộng. Tóm tắt này nhằm đ•ợc sử dụng nh• là để ghi nhớ lần nữa hay nh• là một nguồn thông tin ban đầu. Ng•ời đọc đ•ợc yêu cầu tìm cách làm một số bài tập ở cuối mỗi ch•ơng. Các bài tập này sẽ giúp ng•ời đọc hiểu đ•ợc nhiều ý t•ởng và kỹ thuật trình bày trong ch•ơng đó. Ch•ơng 1 đề cập quan niệm quản lý dự án phần mềm. Ch•ơng này cũng tham luận nhiều khó khăn mà các nhà quản lý dự án gặp trong việc giành hỗ trợ của bộ phận quản lý cấp trên để trình ra những thủ tục phát triển mới. Ch•ơng 2 tóm tắt vắn tắt nhiều vấn đề phát triển phần mềm chung nhất (sau này đ•ợc xây dựng trong suốt cuốn sách). Ch•ơng này đ•ợc chia làm 2 phần. Phần đầu giành cho độc giả không quen với những vấn đề cơ bản về quản lý phần mềm. Phần hai giành cho những ngành đang quản lý dự án cả mới và cả đã có kinh nghiệm. Phần này thảo luận ph•ơng pháp đấu tranh với những vấn đề đã thảo luận tr•ớc đây, gọi là phân tích rủi ro. Các nhà quản lý dự án có kinh nghiệm có thể bỏ qua ch•ơng 1 và phần đầu của ch•ơng 2. Ch•ơng 3 thảo luận việc phát triển phần mềm theo hợp đồng. Ch•ơng này mô tả các hợp đồng dự án phần mềm đ•ợc tiến hành nh• thể nào, các đề nghị ra sao. Một văn bản đề nghị nên đ•ợc xây dựng thể nào và nên thiết lập thế nào và những mối quan hệ giữa khách hàng và nhà sản xuất. Ch•ơng này cũng mô tả các yêu cầu về văn bản đề nghị (RFP) và quá trình lựa chọn sau khi các đề nghị đã đ•ợc đệ trình. Ch•ơng 4 mô tả chu trình cơ bản phát triển phần mềm, nhấn mạnh đến việc tiếp cận theo giai đoạn, phát triển phần mềm. Những ph•ơng pháp luận khác cũng đ•ợc thảo luận (nh• là tạo mẫu nhanh và mô hình xoắn ốc - Spiral). Những giai đoạn cơ bản đ•ợc mô tả theo quan điểm của ng•ời quản lý dự án nhấn mạnh đến không khí và những vấn đè của mỗi giai đoạn. Ch•ơng 5 trình bày một số những nguyên tắc cơ bản của việc quản lý con ng•ời. Ch•ơng này lựa ra một số những mặt đặc thù liên quan đến việc quản lý các kỹ s• phần mềm, chẳng hạn nh• sự khác nhau đáng kể về năng suất giữa các kỹ s• phần mềm và tính khí phong độ của các nhà lập trình nói chung. Ch•ơng 6 đề cập một trong những vấn đề khó khăn nhất của phát triển phần mềm: làm sao quản lý đ•ợc những dự án phần mềm lớn. Ch•ơng này giải thích những dự án lớn có thể đ•ợc phần chia thành những bộ phận nhỏ dễ quản lý nh• thế nào theo ph•ơng châm chia ra chế ngự. Quản lý dự án phần mềm 9 Ch•ơng 7 mô tả ba trong những chức năng hỗ trợ quản lý cơ bản: kiểm tra cấu hình đảm bảo chất l•ợng và thử nghiệm phần mềm. Ch•ơng này cũng thảo luận mối quan hệ giữa những chức năng đó. Ch•ơng 8 trình bày tổng quan về các chuẩn phát triển phần mềm. Đặc biệt hai chuẩn đ•ợc thảo luận chi tiết: chuẩn 2167 của Bộ Quốc phòng Hoa Kỳ (DOD) và chuẩn IEEE về phát triển phần mềm. Những chuẩn khác, nh• chuẩn phát triển phần mềm của Anh và Châu Âu, cũng đ•ợc nhắc tới và so sánh. Ch•ơng 9 thảo luận việc lập lịch và kế hoạch phát triển dự án (PDP) và kỹ thuật lập lịch và lập kế hoạch đ•ợc mô tả, kể cả phác đồ Gantt và PERR cổ điển và cấu trúc phá hủy công việc (WBS). Ch•ơng 10 chứa một mô tả tăng c•ờng và chi tiết của một vài ph•ơng pháp và kỹ thuật chuẩn bị dự toán. Ch•ơng này gồm những ph•ơng pháp dự tính qui mô của dự án và lịch phát triển dự án cũng nh• dự toán kỹ thuật, chẳng hạn nh• các yêu cầu về đĩa và về bộ nhớ. Ch•ơng này cũng giải thích kinh nghiệm có thể đ•ợc sử dụng thế nào để cải tiến dự toán và mô tả các dự toán có thể đ•ợc hoàn thiện thế nào trong quá trình phát triển dự án tiến triển. Tri ân Các tiêu chuẩn DOD-STD 2167a và DOD-STD 2168 và các mô tả hạng mục dự liệu liên quan của Bộ Quốc phòng Hoa Kỳ đã đ•ợc tham chiếu và trích dẫn đ•ợc phép của Bộ Quốc phòng Hoa Kỳ, Bộ chỉ huy các hệ thống chiến tranh không gian và trên biển. Các tiêu chuẩn công nghệ phần mềm IEEE đã đ•ợc tham chiếu và những tài liệu sau đây đã đ•ợc trích dẫn đ•ợc phép của Viện tập đoàn kỹ s• điện và điện tử (IEEE). Phần nhập môn của F.Buckley cho bản in 1984 của IEEE về tiểu chuẩn công nghệ phần mềm IEEE. Phần nhập môn của J.Horch cho bản in 1987 của IEEE về tiểu chuẩn công nghệ phần mềm. IEEE stel 729 - 1983 IEEE stel 1022 - 1987 IEEE stel 830 - 1984 IEEE stel 990 - 1986 Giữ bản quyền mọi mặt @ Viện tập đoàn kỹ s• điện và điện tử. Tôi xin cảm ơn về sự giúp đỡ to lớn của Amir trong việc duyệt và tập hợp văn bản. Tôi cũng biết ơn về nhiều gợi ý có ích của Ông. Tôi cũng xin cảm ơn Sharon và Talya đã không xáo trộn bản thảo văn bản. Cuối cũng và quan trọng nhất, tôi xin hết sức cảm ơn động viên của Iril, nếu không văn bản đã chẳng bao giờ đ•ợc viết ra. Nhãn hiệu th•ơng mại Ada là nhãn hiệu đã đăng ký của Chính phủ Hoa Kỳ, Ada AJPO UNIX là th•ơng nhãn của tập đoàn điện thoại và điện báo Mỹ VMS là th•ơng nhãn của tập đoàn thiết bị số Quản lý dự án phần mềm 10 MS-DOS là th•ơng nhãn của tập đoàn Microsoft PC-DOS là th•ơng nhãn của tập đoàn máy móc kinh doanh quốc tế BYB là th•ơng nhãn của nhóm Gordon. Quản lý dự án phần mềm 11 Ch•ơng một Nhập môn về quản lý dự án phần mềm Nhập môn “Phần mềm là nơi trồng các giấc mơ và thu hái ác mộng ... một thế giới những ng•ời hóa sói và những viên đạn bằng bạc“ Trích dẫn này từ Brad cox (cox 1990) nhấn mạnh những quan tâm của các nhà quản lý dự án phần mềm hôm nay. Làm sao có thể kiểm tra đ•ợc con ng•ời hóa sói này d•ới chi tiết công nghệ phần mềm đây ? Liệu việc phát triển phần mềm có thật sự là một bộ phận công trình không ? Việc phát triển phần mềm có thể kiểm tra đ•ợc. Có những ph•ơng pháp những kỹ thuật nh•ng chuẩn và những công cụ khi đ•ợc vận dụng đúng đắn chúng sẽ thúc đẩy sự phát triển thắng lợi của dự án phần mềm. Đó không phải là những viên đạn bằng bạc xuyên qua trái tim của ng•ời hóa sói: chẳng có gì giữ thật ở trong cả. Những ph•ơng pháp này cung cấp một cách tiếp cận có hệ thống tới sự phát triển phần mềm bắt đầu là những giai đoạn qui hoạch ban đầu và kết thúc là việc cung cấp sản phẩm phần mềm cuối cùng. Cuốn sách này đề cập đến việc vận dụng những ph•ơng pháp hiện đại để quản lý các dự án phần mềm. Sách trình bày tiếp cận thực hành “làm thế nào đây” hơn là tiếp cận lý thuyết mặc dù có những tham khảo rộng rãi cho những ai quan tâm đến việc mô tả lý thuyết đằng sau các ph•ơng pháp. Mục tiêu chủ yếu là tập trung, trong chỉ một cuốn sách, mô tả biết bao công cụ và qui trình dính líu đến những hoạt động quản lý phần mềm nh•:  Dự toán chi tiết dự án  Chuẩn bị các lịch trình phát triển  Vận dụng các tiêu chuẩn phát triên thiết thực  Chuẩn bị và đánh giá các đề nghị Nhà quản lý dự án phần mềm theo thế đ•ợc cung cấp các ph•ơng pháp và qui tình cần thiết khiến cho việc phát triển phần mềm có hiệu quả hơn với ba mục tiêu nổi tiếng trong tâm t•ởng: phát triển phần mềm 1. theo ch•ơng trình 2. trong phạm vi ngân sách 3. theo yêu cầu 1.1. Nhu cầu đang gia tăng về phần mềm Thật có ít lĩnh vực công nghệ hiện đại lại không chứa phần mềm. Điều này bao gồm xe hơi, hàng không và vệ tinh cũng nh• thang máy, máy fax, truyền hình và các cơ quan điện tử. Phần mềm vận hành hệ thống an ninh xã hội, hệ thống chi l•ơng tập đoàn, và trái của nền kinh tế ph•ơng Quản lý dự án phần mềm 12 Tây - Hệ thống thẻ tín dụng. Phần mềm đ•ợc sử dụng rộng rãi để viết và in sách. Việc gia tăng nhu cầu về phần mềm đã trở nên một vấn đề gay cấn. Nó đã gây ra việc gia tăng nhu cầu về kỹ s• phần mềm. V•ợt rất xa mức độ các nhà chuyên nghiệp phần mềm tốt nghiệp ở các tr•ờng đại học. Do đấy sự phát triển phần mềm đ•ợc yêu cầu có năng suất cao lợi hơn, tin cậy hơn và nói chung thành công hơn. Những yêu cầu mới đó có thể không đ•ợc đáp ứng ở những ph•ơng pháp phát triển thô thiển của những ngày đầu của máy vi tính. Những ph•ơng pháp mới đã đ•ợc đề xuất cải tiến đáng kể con đ•ờng mà phần mềm đ•ợc phát triển. Tính nghiêm trọng của vấn đề đã đ•ợc thừa nhận trong khắp cộng đồng công nghệ phần mềm. Một số các liên công ti và công xoexiom quốc tế đã đ•ợc thành lập ở Hoa Kỳ, Nhật Bản và Châu Âu với những ngân sách to lớn dành cho việc tìm kiếm những ph•ơng pháp giảm nhẹ (nếu không phải là loại trừ) vấn đề (coi Bennatan 1987). Cox (1990), trong một phân tích ph•ơng h•ớng công trình phần mềm sẽ tiến hành cho thấy rõ một cuộc cách mạng công nghiệp phần mềm lý thú, ông đã tiên đoán ngày mà các nhà lập trình sẽ thôi không mã hóa mọi thứ khi xóa và sẽ ghép các ứng dụng trừ những catalô l•u trữ tốt của các thành phần phần mềm sử dụng lại đ•ợc. Quan niệm này và những quan niệm cách mạng khác nh• phát triển phần mềm tự động (coi Frankel 1985) vẫn còn phải mất quãng đ•ờng dài tr•ớc khi trở thành những ph•ơng tiện thiết thực của phát triển phần mềm. Xu h•ớng tiến tới công trình phần mềm có máy tính hỗ trợ (CASE) đã tạo nên nhiều công cụ phát triển tự động nh•ng chẳng may thay những công cụ đó1 th•ờng mất nhiều thời gian không xứng với chúng, ở những lĩnh vực khác của công nghệ các hệ CAD/CAM2 tự động đã đang đ•ợc sử dụng để thiết kế và xây dựng các thành phần điện tử nh•ng phát triển phần mềm vẫn còn hoàn toàn là một cố gắng thủ công. Cho đến lúc mà phần mềm sử dụng lại và phát triển phần mềm tái tạo và tự động bắt đầu thay thế đ•ợc các kỹ s• phần mềm thì phần mềm vẫn còn tiếp tục do con ng•ời phát triển. Trong khi chờ đợi việc gia tăng theo yêu cầu về năng suất và thuần thục tay nghề và thắng lợi chung của phát triển phần mềm phải duy trì trách nhiệm vẫn phải là ở nhà quản lý dự án phần mềm. 1.2. Vai trò của việc quản lý trong phát triển phần mềm. Việc quản lý dự án có hiệu quả đòi hỏi nhiều tài năng và kỹ xảo. Tiêu chuẩn IEEE (IEEE 1987a) cho dịch nghĩa sau về quản lý dự án phần mềm. 1 Xem Tahvanainen và Smolander ‘An annotated CASE Bibliography (1990)’ 2 CAD và CAM là thiết kế có máy tính trợ giúp và chế tạo có máy tính trợ giúp. Quản lý dự án phần mềm 13 Quản lý dự án phần mềm là quá trình qui hoạch, tổ chức, nhân sự điều khiển, kiểm tra và lãnh đạo dự án phần mềm. Rõ ràng để trở thành nhà quản lý dự án phần mềm tốt thì là nhà phát triển phần mềm tốt không còn đủ nữa. Có những kỹ xảo quản lý đặc biệt đ•ợc yêu cẩu• dụng ngay từ những giai đoạn đầu của dự án, chằng hạn nh• ở các lĩnh vực nh•: - Giám sát và kiểm tra Điều này bao gồm việc quản lý có hiệu quả các thành viên đội ngũ phát triển và đòi hỏi ý thức th•ờng xuyên về tình trạng thực của công việc của họ về dự án. - Qui hoạch Qui hoạch là một trong những hoạt động quản lý quan trọng nhất và bao gồm việc chuẩn bị dự toán tốt, duy trì lịch trình phát triển và bố trí nhân sự hiệu quả. - Quan hệ khách hàng Trong một số dự án, việc tiếp xúc với khách hàng là hoạt động quản lý chủ yếu. Điều này bao gồm viết tài liệu về yêu cầu của khách hàng, khống chế những thay đổi do khách hàng, sử lý việc tham gia của khách hàng vào quá trình phát triển, cung cấp báo cáo và tổ chức xét duyệt cùng trình diễn sản phẩm. - Vai trò lãnh đạo kỹ thuật Lãnh đạo kỹ thuật tốt th•ờng là một phẩm chất ao •ớc trong việc quản lý phần mềm có hiệu quả. Điều này th•ờng đòi hỏi khả năng cung cấp chỉ đạo trong giải pháp của các vấn đề kỹ thuật phát sinh trong quá trình phát triển dự án. Điều này không cần thiết có nghĩa là dự trữ chung bản thân một giải pháp đích thực. Những lĩnh vực quản lý này là vận dụng đ•ợc cho mọi thể loại dự án Công nghệ cao. Dù sao việc quản lý dự án phần mềm lại khó khăn hơn do sự thể là phát triển phần mềm ít có tính xác định hơn các lĩnh vực công nghệ khác. Điều này là do những dự án phần mềm ít đo l•ờng đ•ợc khó dự toán hơn và phụ thuộc nhiều hơn vào những nhân tố chủ quan của con ng•ời. Lịch sử phát triển phần mềm đầy rẫy những tr•ờng hợp mà mức độ nguồn lực đ•ợc yêu cầu đã đ•ợc qui hoạch và dự toán tốt. Phát triển phần mềm đã từ lâu đ•ợc nhận định là doanh nghiệp đầy rủi ro. Đã có nhiều tr•ờng hợp các dự án phần mềm v•ợt quá ngân sách ban đầu của chúng tới hai, ba hay thậm chí bồn trăm phần trăm. Một số đã phải bỏ bễ sau khi đã chi hết vốn cơ bản khi thấy rõ là dự toán ngân sách ban đầu không chỗ nào sát với chi phí phát triển thực sự. Trong những năm gần đây, đã có ý đồ tiêu chuẩn hoá qui trình phát triển phần mềm và tạo ra môi tr•ờng phát triển nghiêm ngặt trong đó các dự án phần mềm dễ dự toán và kiểm tra hơn. Dù sao, điều này đã dẫn đến một vấn đề mới các nhà sản xuất đã phàn nàn phải mất quá nhiều thời gian vào việc thiết lập t• liệu và quá ít cho xu h•ớng phát triển hiện nay. Rõ ràng là cần tìm đ•ợc địa bàn trung độ giữa hai thái cực trong dự án không có thể lập trình và dự toán và dự án tiêu chaủan quá mức, thu thập Quản lý dự án phần mềm 14 t• liệu quá mức trong đó chi công sức quá đáng vào tổng phí và công việc giấy tờ. Khi phát triển phần mềm bắt đầu dĩnh dáng đến một bộ môin công trình thì những ph•ơng pháp luận phát triển một cách có hệ thống mới cũng bắt đầu xuất hiện3. Mục đích của những ph•ơng pháp luận mới đó là làm cho sự phát triển phần mềm thành công hơn. Nếu thắng lợi đ•ợc do theo mức độ của ba mục tiêu nói tr•ớc đây (theo lịch trình, trong phạm vi ngân sách, theo yêu cầu) thì sự thất bại hẳn có nghĩa là trong việc hoàn thành thậm chí một trong những mục tiêu đó. Dù sao, thành công và thất bại không phải là cái điều đ•ợc định nghĩa một cách dễ dàng. Đã có nhiều nghiên cứu cho thấy là thất bại của dự án cũng là một vấn đề của nhận thức (cos Linto và mantel 1990). Một dự án có thể đ•ợc nhận định là thất bại ở một môi tr•ờng trong khi ở môi tr•ờng khác dự án lại có thể đ•ợc nhận định là thắng lợi. Nói một cách đơn giản, một khách hàng có thể hài lòng với đầu ra của một dự án trong khi ng•ời khách khác lại không. Theo thế thành công hay thất bại của một dự án không chỉ liên quan đến ba mục tiêu phát triển cơ bản mà cả đến kỳ vọng của khách hàng. Sự không rõ ràng của quan niệm thất bại của dự án chắc chẵn có thể tránh đ•ợc nếu chỉ đặt ra một đích duy nhất. Đây là đích mà khách hàng đặt ra chứ không phải đội ngũ phát triển đặt ra. Điều đó có nghĩa là: Thành công hay thất bại của một dự án đ•ợc tối hậu xác định ở sự hài lòng của bên yêu cầu phát triển (nghĩa là khách hàng) Những quan niệm đó đ•ợc chứng minh trong thí dụ sau: 1.3. Một thí dụ: Thí dụ này cho thấy vài sai lầm quản lý thông th•ờng mà nó có thể cuối cùng dẫn đến thất bại của một dự án phần mềm. Dự án khởi sự với vài quyết định sai lầm cơ bản liên quan đến việc khởi hành dự án, đến l•ợt nó, nó lại dẫn đến nhiều quyết định sai lầm hơn khi dự án tiến triển. Công ty liên kết công nghệ (TAI) là một công ty chuyên môn hóa trong việc phát triển và chế tạo thiết bị truyền thông. TAI là một ban phần mềm lớn chịu trách nhiệm về sự phát triển phần mềm cho thiết bị truyền thông. Ng•ời quản lý ban phần mềm đã đ•ợc biết là quản lý công ty đang tìm kiếm một công ty phần mềm bền ngoài để phát triển một hệ thống bảo d•ỡng và thời gian cho TAI. Ban phần mềm của TAI đã chủ động nắm bắt ý kiến, chuẩn bị một đề nghị phát triển hệ thống và đệ trình quản lý công ty. Căn cứ ở đề nghị này hai tháng đ•ợc giành tham khảo ý kiến của ban nhân sự, ban tài chính và tr•ởng ban để xác định các yêu cầu của hệ thống. Đội ngũ phát triển sau đó phát triển hệ thống trong 6 tháng sau đó (toàn bộ thời gian phát triển 3 Xem Shaw (1990) về một thảo luận đầy đủ trên vấn đề tiến hoá của phần mềm trong bộ môn công trình học. Quản lý dự án phần mềm 15 kể ra phải là 8 tháng). Ban phần mềm dự tính cần đội ngũ 4 ng•ời để cung cấp các yêu cầu và phát triển hệ thống. ý kiến sử dụng một công ty phần mềm bên ngoài đ•ợc gác lại và đề nghị của ban phần mềm đ•ợc quản lý công ty chấp nhận. Ngân sách phát triển đ•ợc thông qua để đáp ứng 2 năm r•ỡi nhân công hay 4 ng•ời trong 8 tháng. Ban phần mềm tiến hành lập đội ngũ dự án và chọn một ng•ời quản lý dự án, trong số các ng•ời quản lý dự án truyền thông để lãnh đạo đội ngũ này. Khi cuối đợt hai tháng ban đầu gần kề, nhà quản lý dự án thấy rõ là phải cần nhiều thời gian hơn để xác định và viết t• liệu về các yêu cầu. Ph•ơng án chọn lựa của nhà quản lý dự án là: 1. Hoặc là yêu cầu nói rộng thời gian và bổ sung ngân sách phát triển 2. Hoặc là sử dụng một phần những yêu cầu hiện có. Ng•ời quản lý ban muốn chứng minh là ban của mình có khả năng phát triển cả các hệ thông tin và phần mềm truyền thông đ•ợc lồng vào. Do đó ng•ời quản lý dự án và đội ngũ đã thúc chọn ph•ơng án 2. Điều này dựa trên tiền đề là nếu dự án bị chậm và v•ợt quá ngân sách thì dự án phải bị coi là thất bại và các hệ thống thông tin sau này hẳn sẽ phải đ•ợc hợp đồng với một công ty phần mềm bền ngoài. Tất cả các ban khác thấy có nhiều vấn đề chủ yếu của hệ thống. Nói tóm lại hệ thống thiếu cái mà công ty cần. Ban phần mềm đề nghị sửa chữa các sai sót và yêu cầu ngân sách cho việc phát triển một version cải tiến mới. Dù sao, sự bất bình đã đến mức mà quản lý công ty quyết định đ•a việc phát triển một hệ thống hòan toàn mới cho một công ty phần mềm bền ngoài. Công ty phần mềm đ•ợc lựa chọn phát triển thành công hệ thống. Ngạc nhiên là lần này kinh phí lại ít hơn là ngân sách mà ban phần mềm TAI yeue cầu để sửa chữa các sai sót trong hệ thống ban đầu. Thí dụ (có thật) này thuyết minh một số sai lầm chủ yếu trong quản lý dự án. - Kinh nghiệm trong một lĩnh vực phần mềm (các hệ viễn thông đ•ợc lồng vao) khong đủ cho việc phát triển thành công phần mềm ở một lĩnh vực hoàn toàn khác (hệ thông tin). - Nhà quản lý dự án nêu trách nhiệm cam kết vào lịch trình phát triển hay ngân sách tr•ớc khi dự án đ•ợc xác định đủ. Trong phần lớn tr•ờng hợp cam kết của công ty chỉ có thể có khi các yêu cầu đã đ•ợc kết luận. - Nếu yêu cầu của một dự án không đ•ợc đáp ứng thì việc tham gia vào lịch trình và ngân sách trở lên vô nghĩa. - Khách hàng hay ng•ời dùng sẽ không phải bao giờ cũng cung cấp đ•ợc những yêu cầu đúng (thí dụ chủ yếu giao liên ban). Th•ờng là trách nhiệm của ng•ời sản xuất phải hỏi những câu hỏi thích đáng nhằm thu thập thông tin cần thiết. - Đôi khi tốt nhất là nên phát triển một hệ thống mới bằng việc xóa bỏ còn hơn là tìm cách cứu vãn một hệ thống đã đ•ợc phát triển tồi. Quản lý dự án phần mềm 16 1.4. Giành sự chấp nhận các thủ tục phát triển mới. Một trong những trở ngại mà các nhà quản lý dự án th•ờng phải khắc phục là tình trạng thiếu hỗ trợ ở quản lý cấp cao hơn đối với những ph•ơng pháp phát triển hiện đại. Vận dụng các ph•ơng pháp luận hiệu quả không dễ khi quản lý cấp cao hơn còn tranh luận về nhu cầu của họ. Điều này dẫn đến các nhà quản lý dự án đến một tình trạng tiến thoái l•ỡng nam, làm sao chấp nhận đ•ợc cái mà họ tin là tốt nhất trong khi vẫn giữ đ•ợc c•ơng vị nhà quản lý dự án. Rõ ràng là nhiều ph•ơng pháp và kỹ thuật đ•ợc mô tả trong cuốn sách này chỉ có hiệu lực khi chúng đ•ợc sử dụng. Mục tiêu của phần này là giúp nhà quản lý dự án giành đ•ợc sự chấp nhận ở quản lý cấp cao hơn trong việc ứng dụng những ph•ơng pháp mới. Quản lý cấp cao hơn (và đôi khi là các kỹ s• phần mềm khác) có khi dùng những lập luận sau chống lại việc sử dụng các ph•ơng pháp luận phát triển phần mềm hiện đại. 1. Những ph•ơng pháp mới này đều là lý thuyết trong “thế giới thực” sự việc diễn ra khác. 2. Những nhà quản lý dự án quá hình thức chủ nghĩa; họ đòi hỏi mọi thứ bằng văn bản và không đồng ý về mọi thay đổi nhỏ. 3. Chúng ta không có thì giờ cho mọi công việc giấy tờ đó. 4. Chúng ta không thể mất công sức về sự xa phí trong mọi qui trình dài dặc đó. Chúng ta vẫn luôn phát triển đ•ợc phần mềm mà chẳng cần những tổng phí đó. 5. Đây là kinh doanh chứ không phải tr•ờng đại học. Chúng ta mất tiền và mất khách nều chúng ta bắt đầu với việc lãng phí thời gian vào mọi ph•ơng pháp đó. 6. Ph•ơng pháp là tốt, nh•ng bất hạnh là bây giờ không phải lúc thực hiện chúng. Chúng ta mong rằng có thể sử dụng chúng một ngày nào đó nh•ng không phải đúng lúc này. 7. không có kỹ s• nào của chúng ta quen với những ph•ơng pháp mới này. Nh• thế sẽ mất nhiều thời gian và mất nhiều kinh phí để bắt đầu đào tạo lại họ. Sau đây là một số trả lời gợi ý cho những lập luận trên. 1. Hồ sơ phát triển phần mềm trong thế giới thực ch•a phải là quá tốt. Trên thực tế, các ph•ơng pháp cổ th•ờng chỉ dẫn đến thảm họa. Có thành công đấy nh•ng tỷ số thành công so với thất bại lại quá thấp. Bất cứ ph•ơng pháp thiết thực nào đều có đôi chút lý thuyết đúng nh• những ph•ơng pháp phát triển phần mềm đó những ph•ơng pháp đó đã đ•ợc các công ty t•ơng tự khác vận dụng thành công và đã giảm mạnh kinh phí phát triển phần mềm và tăng đáng kể chất l•ợng phần mềm. 2.Việc duy trì nề nếp hồ sơ viết là có lợi cho mọi ng•ời cho đội ngũ phát triển cho khách hàng và cho quản lý cấp cao. Nó đảm bảo là những Quản lý dự án phần mềm 17 giao tiếp miệng đ•ợc hiểu đúng đắn. Nếu những thay đổi hay các h•ớng dẫn khác không ghi thành văn bản và không đ•ợc chấp nhận, thì sự phát triển có thể tiến hành theo h•ớng sai không ai có thể chắc chắn là mọi thay đổi, cả lớn và nhỏ, sau này sẽ đ•ợc nhớ lại khi dự án hoàn thành. Danh mục thành văn bản các thay đổi đ•ợc chấp nhận giúp khả năng theo dõi và hạch toán. 3. Đây có thể là khiếu lại đáng l•u ý; công việc giấy tờ phải đ•ợc duy trì ở mức tổi thiểu (có khi nó quá mức). Dù sao, đáng ngạc nhiên là công việc giấy tờ có mức độ hiện nay thực sự lại tiết kiệm thời gian và không gây lãng phí. Chẳng hạn những quyết định không ghi thành văn bản th•ờng khi cần đ•ợc lặp đi lặp lại và những đặc tả nói miệng dẫn đến những lý giải gây tranh cãi. Việc thiếu t• liệu th•ờng mất nhiều thời gian nhất trong các pha thích hợp và thử nghiệm khi bản thiết kế hệ thống chỉ đ•ợc l•u trong trí nhớ của ng•ời. Cũng vậy, một dự án không thành văn bản là một ác mộng trong việc duy tu. Sau khi hoàn thành dự án, khi các nhà sản xuất đã phân tán đi, tất cả những gì còn lại là sản phẩm và t• liệu. Không có t• liệu sản phẩm không gì hơn là một bí mật. 4. Một câu hỏi cần phản ảnh là: liệu và đúng vậy liệu phát triển phần mềm của chúng ta đã thực sự thành công thế nào? Lập luận này đ•ợc thử thách tốt nhất với bộ hồ sơ t• liệu đ•ợc chuẩn bị cho biết những vấn đề mà công ty đã có kinh nghiệm ở những dự án tr•ớc. Mục tiêu là chứng minh tiếp cận mới với phát triển phần mềm đâu phải là xa xỉ mà là cần thiết. 5. Những lập luận khó đ•ơng đầu nhất khi có yếu tố sự thực trong chúng, đặc biệt khi công ty có định ý phát triển ph•ơng pháp luận mới của chính họ. Mổc dù nhiều công ty có tiến hành nghiên cứu trong công trình phần mềm điều này thật khó là cần thiết ở mọi công ty đã có những ph•ơng pháp luận những tiêu chuẩn và những h•ớng dẫn đ•ợc ghi thành văn bản thỏa đáng (coi IEEE 1987b) để cho chúng có thể đ•ợc vận dụng dễ dàng ở mọi công ty mà không cần thiết phải phát triển chúng lại. Mất khách hàng không chỉ do lịch trình phát triển kéo dài mà còn do chất l•ợng kém và nhu cầu kỹ thuật không đ•ợc thỏa mãn. Càng cần nghiêm lệnh hẳn về phía lịch trình phát triển lâu hơn chứ không phải về phía sản phẩm phần mềm tốt hơn. Nh• vậy, lịch trình phát triển ngắn th•ờng dễ bị lạc lối do thời gian bổ sung đòi hỏi để bổ chính sản phẩm phần mềm kém cỏi, sau khi đã tung nó ra lần đầu (coi thí dụ ở phần 1.3). 6. Tại sao lại ch•a làm ngay? Liệu có cơ sở thực sự nào cho việc kêu ca là thời gian thích hợp hơn sẽ xuất hiện sau này? Trái lại càng thêm thời gian và công sức đầu t• vào những ph•ơng pháp phát triển nghèo nàn thì lại càng khó mà thay đổi đ•ợc. Cái cách tốt nhất trả lời cho lập luận này là cung cấp những lý do kinh doanh để giải thích vì sao những ph•ơng pháp phát triển mới lại nêu đ•ợc chấp nhận càng nhanh càng tốt. Bộ hồ sơ đã chuẩn bị, nêu trong trả lời cho lập luận 4, sẽ có ích cùng với thông Quản lý dự án phần mềm 18 tin thu thập từ các công ty khác. Mục tiêu là bày tỏ rằng những qui tình phát triển có thứ tự sẽ làm tăng chất l•ợng sản phẩm phần mềm của công ty trong khi giảm chi phí phát triển. 7. Tầm quan trọng của việc đầu t• trong đào tạo ít khi cần đ•ợc nêu: đây là một quan niệm đ•ợc chấp nhận rộng rãi. Lập luận này khó có thể bác bỏ khi các ph•ơng pháp phát triển mới đ•ợc đ•a ra coi nh• một thay đổi chủ yếu về ph•ơng h•ớng. Câu trả lời tốt nhất tùy thuộc ở tình hình thực tế. Nếu những ph•ơng pháp mới thực sự tiêu biểu cho thay đổi chủ yếu là ph•ơng h•ớng thì chắc chắn là công ty đã có thí nghiệm nhiều vấn đề phát triển phần mềm. Nh• thế câu trả lời cho các lập luận 4 và 5 là thích đáng. Nếu những ph•ơng pháp mới không thực sự tiêu biểu thay đổi chủ yếu về ph•ơng h•ớng thì điều này nêu đ•ợc chứng minh có sử dụng dữ liệu của các dự án tr•ớc đây. T• t•ởng cơ bản là chứng minh rắng mặc dù nhiều qui trình phát triển hiện nay là tinh vi, việc cải tiến đáng kể có thể đ•ợc thực hiện thông qua việc giới thiệu một số ph•ơng pháp mới. Mọi lập luận chống lại các ph•ơng pháp luận phát triển mới chỉ có thể bác bỏ đ•ợc sau khi có chuẩn bị đầy đủ. Điều này th•ờng nghĩa là: - S•u tập dữ liệu về các dự án phát triển phần mềm tr•ớc đây trong phạm vi vông ty. - S•u tập dự liệu về các công ty t•ơng tự đã chấp nhận ph•ơng pháp phát triển mới. - S•u tập các báo cáo có dẫn t• liệu, văn bản và các chứng cớ khác thành văn (cần đề phòng quá lý thuyết). - Có đ•ợc hỗ trợ của các chuyên gia phát triển phần mềm khác hoặc ở trong phạm vi công ty hoặc ở ngoài. Mọi dữ liệu cấn đ•ợc nghiên cứu và các ghi chú đ•ợc chuẩn bị chứng minh nhu cầu của các ph•ơng pháp phát triển mới. Dòng cuối phải là việc vận dụng những qui tình mới, thiết thực phát triển phần mềm là vì lợi ích của công ty. Đã giành đ•ợc sự phê chuẩn cần thiết của quản lý cấp trên, những nhà quản lý dự án phần mềm có thể chuyển sang vận dụng các ph•ơng pháp mô tả trong các ch•ơng sau. B•ớc đầu trong việc tìm hiểu những vấn đề cơ bản trong việc phát triển phần mềm đ•ợc thảo luận ở ch•ơng 2. 1.5. Tóm tắt. Việc phát triển phần mềm có thể khống chế đ•ợc. Có những ph•ơng pháp, những kỹ thuật, những tiêu chuẩn và các công cụ khi đ•ợc vận dụng đúng thì chúng thúc đẩy việc phát triển thắng lợi dự án phần mềm với ba mục tiêu trứ danh trong trí óc để phát triển phần mềm. 1. Theo đúng lịch trình. 2. Trong phạm vi ngân sách. 3. Theo yêu cầu. Quản lý dự án phần mềm 19 Thắng lợi hay thất bại của dự án không chỉ liên quan đến ba mục tiêu phát triển cơ bản đó nh•ng cũng cả đến kỳ vọng của khách hàng: một khách hàng có thể hài lòng với đầu ra của một dự án trong khi khách hàng khác lại có thể không. Do đấy, thành công của dự án đ•ợc xác định tối hậu ở sự hài lòng của khách hàng. Một trong những trở ngại mà các nhà quản lý dự án th•ờng phải khắc phục là thiếu hỗ trợ của quản lý cấp trên đối với những ph•ơng pháp phát triển hiện đại. Rõ ràng là nhiều ph•ơng pháp và kỹ thuật mô tả trong cuốn sách này, có hiệu lực chỉ khi chúng đ•ợc sử dụng. Mọi lập luận chống lại các ph•ơng pháp luận phát triển mới chí có thể bác bỏ sau khi có sự chuẩn bị đầy đủ. Thông tin về thành công và thất bại của phát triển phần mềm trong quá khứ trong phạm vi một công ty cần đ•ợc thu thập cùng với các minh chứng hỗ trợ khác bằng văn bản. Mọi dự liệu cần đ•ợc nghiên cứu và các chi chú cần đ•ợc chuẩn bị để chứng minh cho nhu cầu về ph•ơng pháp phát triển mới. Dòng cuối nên là việc ứng dụng các chu trình phát triển phần mềm hữu hiệu mới là vì lợi ích của công ty. Quản lý dự án phần mềm 20 Ch•ơng hai Những vấn đề phát triển phần mềm Một chút phòng xa Tại một lớp học mới đầy về quản lý dự án phần mềm, một trong các học viên đã hỏi: “Chúng tôi có một số vấn đề chủ yếu trong một dự án mà tôi đang quản lý. Chúng tôi không có đ•ợc t• liệu có hệ thống hay có đ•ợc một kế hoạch phát triển nào và dự án đang trên đ•ờng v•ợt ngân sách và chậm hơn lịch trình. Vậy tôi phải vận dụng mọi ph•ơng pháp và kỹ thuật học ở đây ra sao nhằm làm cho dự án trở lại đúng lịch trình ?” Đây không phải là một tình huống không phổ biến ở đó, một ph•ơng thuốc thấn kỳ đã tìm cho một tình huống gần gây thảm họa. Những dự án quản lý tối có thể đi đến trì trệ và ngân sách v•ợt đến hai thậm chí ba trăm phần trăm và trong vài tr•ờng hợp lại có thể bị bãi bỏ. Hầu hết những ph•ơng pháp quản lý dự án hiện đại ban đầu bao giờ cũng quan tâm phòng xa (chứ không phải là hiệu chính) những vấn đề loại đó. Việc phòng ngừa những vấn đề thì dễ hơn và ít tốn kém hơn là giải quyết chúng. Những biện pháp phòng ngừa thiết thực hẳn là: - Định vị sớm vấn đề và những vấn đề tiềm ẩn. - Giải quyết vấn đề tr•ớc khi chúng tuột khỏi tầm tay. - Lập kế hoạch tr•ớc (đối phó) với những vấn đề tiểm ẩn. Những vấn đề sẽ trở nên tốn kém hơn giải quyết khi dự án tiến triển đến những giai đoạn phát triển cao hơn. Những vấn đề bị lãng quên cũng có thể lan truyền sang các lĩnh vực khác của dự án làm cho việc hiệu chính chúng trở nên khó khăn hơn. Do đấy việc thiết lập những qui trình để định vị sớm và hiệu chính các vấn đề là quan trọng. Ch•ơng này giải quyết nguyên nhân của một số thể loại rất thông th•ờng của vấn đề phát triển phần mềm và thảo luận tác động của chúng đến quá trình phát triển. Ch•ơng này cũng thảo luận việc dự kiến những vấn đề nhằm giảm thiểu tác động của chúng tới dự án. Các ch•ơng sau đề ra những ph•ơng pháp phòng ngừa các vấn đề mô tả ở đây khỏi xảy ra. 2.1. Những vấn đề cơ bản. Có rất nhiều vấn đề cơ bản mà nhà quản lý dự án hình nh• tìm thấy trong bất cứ dự án phầm mềm nào. Những vấn đề cơ bản đó gây ra bởi những tình huống sau đây bao giờ cũng có thể phòng tr•ớc sẽ phát sinh: - Yêu cầu ban đầu không đầy đủ. - Phụ thuộc ở các nguồn bên ngoài (các ng•ời bán hàng, các chủ thầu phụ v.v...) - Các khó khăn trong kết thúc dự án. - Thay thế th•ờng xuyên nhân sự thực hành phát triển (xáo trộn đội ngũ). Quản lý dự án phần mềm 21 Các vấn đề cơ bản khác th•ờng nảy sinh do sai lầm quản lý thông th•ờng nh•: - Dự toán tồi. - Theo dõi và giám sát không đầy đủ. - Thay đổi không kiểm soát đ•ợc. Con đ•ờng tốt nhất để định vị một vấn đề sớm là đi tìm nó. Rõ ràng, đầu tiên là tìm xem vần đề th•ờng nảy sinh nhiều nhất ở đâu. Chẳng hạn thay đổi th•ờng xuyên và không kiểm tra đ•ợc với việc đặc tả các yêu cầu th•ờng hiển nhiên là nguồn chủ yếu của những vấn đề thiết kế. Những chủ thầu phụ và ng•ời bán hàng không giám sát đ•ợc là một trong những nguồn bất ngờ, thông th•ờng nhất đặc biệt là lúc họ báo cáo các vấn đề kỹ thuật và trì hoãn vào, chính những phút cuối cùng đối với các nhà quản lý dự án thì việc biết phải kiếm ở đâu do đó quan trọng nh• việc biết phải làm gì. 2.1.1. Những vấn đề liên quan đến các yêu cầu của dự án. Đặc tả các yêu cầu của dự án sẽ mô tả sản phẩm phải đ•ợc sản sinh ra bởi nhóm phát triển (coi ch•ơng 4). Nếu những yêu cầu không đ•ợc đặc tả đầy đủ thì chỉ các may mắn thuần túy mới đảm bảo đ•ợc là sản phẩm đáp ứng yêu cầu của khách hàng4. Sau đây là một số thí dụ các vấn đề liên quan đến đặc tả yêu cầu nghèo nàn. - Quên các đặc điểm. Khách hàng tin chắc là một số đặc điểm bị bỏ quên hẳn phải nằm trong sản phẩm căn cứ ở những thảo luận không chính thức (th•ờng với ng•ời không đúng). Ghi chép, bình luận và nhận xét ở các cuộc họp nh•ng không căn cứ ở đặc tả yêu cầu chính thức. - Có những đặc điểm không cần thiết đ•ợc đ•a vào. Đội ngũ phát triển đã tin chắc là khách hàng hẳn hết sức vui thích về những đặc điểm ngoại hạng đ•ợc thêm vào sản phẩm (th•ờng không hỏi ý kiến khách hàng). Một thí dụ hẳn là thêm sự truy nhập hệ thống bằng khẩu ngữ khi khách hàng lại muốn hệ thống sẵn sàng cho bất cứ ai. - Đặc điểm mà chúng hoạt động khác với điều mong đợi. Khách hàng giải thích không đầy đủ về mộ đặc điểm cần thiết và thế là đội ngũ phát triển hiểu cái yêu cầu đó theo cách hiểu của mình. Một thí dụ có thể là yêu cầu "cập nhật th•ờng xuyên cơ sở dữ liệu". Các nhà phát triển đã tạo ra một hệ thống cập nhật cơ sở dự liệu mỗi lần một ngày trong khi khách hàng muốn nói là một giờ mỗi lần. - Những đặc điểm cần thiết mà chẳng ai nghĩ đến. Khách hàng không cần thiết là một chuyên gia máy tính và do đó có thể không ý thức đ•ợc là một đặc điểm, đặc biệt nào đó phải cần đến. Thí dụ có thể là nhu cầu về bade up đầy đủ; khách hàng có thể cho là bade up là không cần thiết vì rằng nếu dịch vụ máy tính bị giám đoạn (thí dụ do 4 Từ khách hàng ở đây đ•ợc sử dụng theo nghĩa rất rộng bao gồm khách hàng chính thức, ban tiếp thị, nhóm ng•ời dùng, quản lý v.v... Quản lý dự án phần mềm 22 mất điện) thì việc mất một hay hai giao dịch l•u trữ trong bộ nhớ sẽ chẳng thành vấn đề. Thế nh•ng khách hàng có thể đã không xem xét sự việc là những điều khiển đĩa cũng có thể đổ vỡ và mất đi mọi dự liệu của họ. Rõ ràng là những yêu cầu đ•ợc đặc tả kém lại là vấn đề cho nhà phát triển nhiều cũng nh• cho khách hàng. Dù sao, nhà sản xuất th•ờng ở vị thế tốt hơn để biên soạn những yêu cầu hơn là khách hàng. Thông th•ờng đặc tả yêu cầu tốt nhất là kết quả của sự cố gắng phối hợp của cả nhà phát triển lần của khách hàng với văn bản thực đ•ợc soạn thành văn của nhà phát triển và đ•ợc chấp nhận bởi khách hàng. 2.1.2. Những thay đổi th•ờng xuyên. Thật cực kỳ hiếm khi tìm đ•ợc một dự án phần mềm qui hoạch tốt lại đi đến kết cục thắng lợi với đặc tả yêu cầu đ•ợc dán nhãn. Ph•ơng án 1.0. Thay đổi là không tránh khỏi suốt chu trình phát triển phần mềm. Dù sao, trong phần lớn tr•ờng hợp một thay đổi đ•ợc đ•a ra chậm thì thực hiện thay đổi lại càng tốn kém. Một số thay đổi thỏa đáng hẳn là phải quản lý đ•ợc. Khi dòng các thay đổi đổ vào nh• thác lũ thì chúng trở thành vấn đề. Ngay chỉ một thay đổi có thể thành vấn đề nếu nó đ•ợc yêu cầu ngay trong phát triển của dự án và nếu nó dẫn đến thay đổi chủ yếu về ph•ơng h•ớng. Những thay đổi quá mức tạo nên cái vẫn th•ờng đ•ợc coi là hội chứng mục tiêu di động. Nhà quản lý dự án không những thay đổi ph•ơng h•ớng và đội ngũ phát triển trở thanh vừa bối rối vừa mất mục tiêu. Thay đổi có thể phá vỡ dự án nếu chúng không đ•ợc ghi thành văn bản và giám sát đầy đủ. Những thay đổi với số l•ợng thỏa đáng, phải đ•ợc quản lý, vận dụng cơ chế kiểm tra sự thay đổi một cách có hệ thống. Ph•ơng pháp đó trong phạm vi tổ chức kiểm tra cấu hình, đ•ợc thảo luận ở ch•ơng 7. 2.1.3. Dự toán và các vấn đề liên quan. Dự toán tốt là quan trọng vì chúng tạo thành nền móng của kế hoạch phát triển dự án tốt. Kế hoạch đó, do nhà quản lý dự án chuẩn bị đ•ợc lập thành trong các giai đoạn ban đầu của dự án và bao gồm dự toán liên quan đến. - Ngân sách phát triển dự án - Lịch trình phát triển dự án - Tài nguyên phát triển cần đến (đội ngũ phát triển thiết bị phát triển v.v...) Những dự toán kỹ thuật cũng đ•ợd hình thành trong pha thiết kế và bao gồm: - Các đặc tính của phần mềm (dự toán về cỡ bộ nhớ, cơ sở dữ liệu v.v...). Quản lý dự án phần mềm 23 - Các đặc tính của phần cứng về cỡ mục tiêu cần đến (dự toán tốc độ CPU, khả năng đầu vào, đầu ra; khả năng điều khiển đĩa v.v...). Dự toán là cơ sở cho nhiều quyết định kỹ thuật và quản lý dự toán tồi dẫn đến quyết định dở. Dự toán tồi có thể hiểu là quá cao hoặc là quá thấp và quyết định theo đó hoặc là tạo ra lãng phí hoặc thiếu tài nguyên phát triển. Điều này hình thành sai lầm trong qui hoạch, nh•: - Lịch trình quá ngắn hoặc cao thái quá. - Ngân sách quá thấp hay quá tăng giả tạo. - Quá thiếu hay quá thừa ng•ời làm và những sai lầm trong thiết kế kỹ thuật, nh•: - Những máy tính trong mục tiêu quá nhiều (và đắt hơn) hơn cần thiết hoặc không thể hỗ trợ ứng dụng đ•ợc phát triển. Những vấn đề nảy sinh từ dự toán thấp th•ờng gay cấn hơn là những vấn đề nảy sinh từ dự toán cao. Hiểu rõ điều này, các nhà dự toán th•ờng thêm vào một số yếu tố bất trắc (cho rằng đến 30%) trong dự toán của minh, giả định rằng quá cao còn hơn quá thấp. Dù sao dự toán cao có thể không gây ra thất bại của dự án nh•ng có thể ngăn cản dự án chẳng bao giờ đ•ợc khởi công. Đã có nhiều ph•ơng pháp đ•ợc phát triển nhằm tạo ra các loại dự toán khác nhau ở các giai đoạn khác nhau của dự án (coi các ch•ơng 9 và 10). Dù sao, ngay những dự toán chuẩn bị tốt có thể dẫn đến những vấn đề nếu chúng không đ•ợc cập nhật trên một cơ sở định kỳ và đều đặn. Rõ ràng là thông tin tốt hơn và đầy đủ hơn tạo nền dự toán tốt hơn. Do đó khi dự án tiến triển và có nhiều thông tin hơn, dự toán cần đ•ợc xem xét lại và hiệu chỉnh. Điều này dẫn đến việc giám định lại các quyết định phát triển, tạo cho các vấn đề tiềm ẩn đ•ợc đề cập sớm tr•ớc khi chúng trở thành gay cấn (coi phần 2.2 về phân tích rủi ro). 2.1.4. Nguồn lực bên ngoài. Các vấn đề phát triển dự án th•ờng dễ quản lý nhất khi mọi nhân tố phát triển đ•ợc điều khiển bởi quản lý dự án. Dù sao, điều này không phải bao giờ cũng có đ•ợc. Nhiều dự án phụ thuộc ở nhiều nguồn bên ngoài nh•: - Chủ thầu phụ - Ng•ời bán thiết bị - Những dự án phát triển song hành - Những ng•ời cung cấp dịch vụ (bảo trì, huấn luyện, lắp đặt v.v...) - Các chức năng hỗ trợ (thông tin điện thoại mạng, những cung cấp dự liệu. Dự phụ thuộc vào các nguồn bên ngoài hẳn phải đ•ợc phản ánh trống). Kế hoạch phát triển dự án. Điều này có nghĩa trong phạm vi các giao •ớc và dự toán nhận đ•ợc từ các nguồn khác. Theo thế, dự toán trong kế hoạch không thể tốt hơn dự toán nhận từ các nguồn khác. Việc trông cậy vào các nguồn bền ngoài có thể gây ra những vấn đề sau: Quản lý dự án phần mềm 24 - Chậm trễ lịch trình, do việc giao chậm các thành phần dự án. - Sự kém cỏi quá chất l•ợng và thiết kế thiết bị phát triển và các thành phần dự án bên ngoài. - Thành phần bên ngoài không t•ơng hợp do vì sự sai lệch của nhà phát triển bên ngoài hay bán hàng với đặc điểm đã thỏa thuận hay đã công bố. - Hỗ trợ sản phẩm nghèo nàn đối với các thành phần bên ngoài. Do có ý thức đ•ợc những vấn đề tiềm ẩn đó, nhà quản lý dự án có thể đảm bảo rằng họ đ•ợc định vị thích hợp trong hợp đồng hay thỏa thuận với nguồn bên ngoài. Những vấn đề đó có thể đ•ợc ngăn ngừa nều đ•a vào trong hợp đồng những mức phát về chậm trễ trong giao hàng hay khuyết tật trong sản phẩm (coi các ch•ơng 3 và ch•ơng 9). Những đề phòng sớm có thể đ•ợc phát hiện khi th•ờng xuyên xét duyệt lại công việc đ•ợc phát triển bởi chủ thầu phụ và đòi hỏi sẽ báo cáo tiến độ th•ờng kỳ. 2.1.5. Kết thúc một dự án phần mềm. Nh• mọi nhà quản lý dự án đều biết, các dự án khó mà bắt đầu đ•ợc kinh nghiệm cho thấy là chúng th•ờng không ít khó khăn để đi đến kết thúc. Đi tới đoạn kết của dự án, luôn luôn các bên quan tâm khác nhau phát sinh những yêu cầu. Nh• phê phán những thay đổi mới và những hoạt động phút chót khác nữa. Điều này là đặc biệt có thực với những dự án giá cố định phát triển cho khách hàng theo hợp đồng (coi ch•ơng 3). Những vấn đề chính liên quan đến việc kết thúc dự án là: - Tranh chấp giữa khách hàng và nhà phát triển về việc lý giải và cung ứng mọi đặc điểm đ•ợc yêu cầu - ý đồ đ•a vào những thay đổi ở phút chót. - Thất bại của hệ thống và khuyết tật thiết kế xác định trong quá trình cài đặt và thử nghiệm hệ thống. - Khó khăn trong việc giữ cho đội ngũ phát triển hợp lực lại với nhau và năng động. Khi tình hình căn thẳng giảm đi vào gần cuối dự án có tình trạng sút giảm nhiệt tình t•ơng ứng trong những thành viên còn lại của đội phát triển. Trách nhiệm của nhà quản lý dự án là đảm bảo cho việc kết thúc dự án có trật tự và thắng lợi. Điều này đ•ợc thực hiện nhờ việc qui hoạch chi tiết lúc ban đầu dự án và quản lý dự án có hiệu quả xuyên suốt dự án. Đặc biệt, điều này đòi hỏi rằng: - Kế hoạch thử nghiệm thu phải đ•ợc chuẩn bị lập tài liệu và đ•ợc khách hàng phê chuẩn tr•ớc khi kêt thúc dự án. Mức độ nhân sự và sự phân công công việc phải đ•ợc lập lịch trình, có tính đến việc giảm dần trong qui mô đội ngũ phát triển vào cuối dự án. -Việc đ•a ấn phẩm ra thị tr•ờng phải đ•ợc lập kế hoạch tốt, kể cả đóng gói soạn thảo t• liệu, huấn luyện, cài đặt và chuyển tiếp có trật tự sang pha bảo trì và hỗ trợ. Sự kết thúc thắng lợi của dự án là bắt đầu của chu trình phát triển khác: Những đặc tả yêu cầu, những kế hoạch thử nghiệm hay những kế hoạch Quản lý dự án phần mềm 25 phát triển nghèo nàn, tất cả đều dẫn đến những vấn đề chủ yếu lúc kết thúc dự án. 2.1.6. Tuyển dụng nhân viên và thuyên chuyển. Khó khăn trong việc tuyển dụng các thành viên đội ngũ phát triển là một trong những vấn đề đầu tiên mà ng•ời quản lý dự án phần mềm gặp phải. Tr•ớc khi bất cứ dự án nào đ•ợc tung ra, đội ngũ phát triển ban đầu phải đ•ợc thiết lập và các vấn đề này sẽ không kết thúc một khi đội ngũ tại vị. Giữ đ•ợc đội ngũ th•ờng khó nh• thiết lập nó. Frenkel (1985) báo cáo là nhu cầu kỹ s• phần mềm tăng theo hàm số mũ trong khi năng suất tăng theo mức khoảng 5% mỗi năm. Các tr•ờng đại học Hoa kỳ và châu Âu đang không cung cấp kỹ s• phần mềm đủ để bù đắp lỗ hổng giữa cung và cầu. Trên thực tế không những lỗ hổng không đ•ợc lấp kín mà lại đang rộng ra ở mức đáng lo ngại. Khối l•ợng thời gian bình quân mà một kỹ s• phần mềm ở lại nghề giảm khi yêu cầu kỹ s• tăng. Điều này không chỉ gây ra bởi sự thuyên chuyển của kỹ s• phần mềm giữa các công ty mà cơ sở sự thuyên chuyển trong phạm vi các công ti. Vì các công ty này đang tìm cách sử dụng hữu hiệu hơn các kỹ s• của mình. Sự thuyên chuyển trong phạm vi các công ty không chỉ do tình trạng thiếu kỹ s• phần mềm mà còn do chi phí về họ có thể vẫn ngăn trở thành việc tuyển bổ sung.5 Thuyên chuyển nhân sự bản thân nó là một vấn đề trọng yếu. Sự ổn định có của đội ngũ và do đó vào thắng lợi của dự án. Các vấn đề liên quan đến tuyển nhân sự và thuyên chuyển luôn bao gồm: - Việc đầu t• đáng kể đ•ợc đòi hỏi trong đ•ờng biểu diễn học tập và đào tạo thành viên đội ngũ phát triển mới. - Thuyên chuyển nhân sự luôn luôn sẽ giảm đi tinh thần đội ngũ và tác động không lợi đến động cơ đội ngũ. - Tuyển chọn th•ờng tốn kém và mất thì giờ nó đòi hỏi nhiều cuộc phỏng vấn và cả phí tuyển dụng. - Thuyên chuyển nhân sự luôn tạo ra tình trạng thiếu kiện định trong phát triển dự án. Trong các vấn đề phát triển phần mềm, những gì liên quan đến phát triển đội ngũ th•ờng đ•ợc nhận thức là gay cấn nhất. Các thành viên đội là nguồn phát triển quan trọng nhất cỡ chính họ đóng góp nhiều nhất cho sự thành công hay thất bại của dự án. 5 Kinh tế học cơ bản chỉ ra rằng khi có đ•ợc kỹ s• thì chi phí về họ sẽ giảm (căn cứ ở cung và cầu trong phạm vi thị tr•ờng nghề nghiệp. Dù sao, trong những năm gần đây, việc cung các kỹ s• phần mềm không bao giờ đủ lớn để tạo ra tác động đó ngoại trừ ở những khoảng thời gian ngắn ngủi tại các địa điểm cô lập). Quản lý dự án phần mềm 26 2.1.7. Theo dõi và giám sát. Theo dõi và giám sát là những nhiệm vụ quản lý. Khi các vấn đề phát sinh ở những lĩnh vực này và liên quan, chúng th•ờng là hậu quả của các qui trình quản lý dự án không thích hợp và không hiệu lực. Một trong những kết quả thông th•ờng nhất là nhà quản lý dự án không có ý thức về sự tồn tại của những vấn đề chủ yếu ở giai đoạn mà chúng có thể đ•ợc kiềm chế và hiệu chỉnh tốt nhất. Việc theo dõi và giám sát có hiệu quả đòi hỏi sự tiếp xúc trực tiếp giữa quản lý dự án và đội ngũ phát triển (coi ch•ơng 7). Một trong những nguyên nhân chủ yếu của các vấn đề theo dõi và giám sát là hội chứng tháp ngà nơi tồn tại kẽ nứt th•ờng trực giữa quản lý dự án và phần còn lại của đội ngũ phát triển. Điều này dẫn đến: - 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ả khi một đội ngũ phát triển đang triển khai hai dự án khác nhau. Điều này xảy ra khi các thành viên đội ngũ phát triển không phối hợp và không đ•ợc giám sát lại đã tiến hành theo những h•ớng khác nhau. - Trí tuệ lịch trình và bội chi ngân sách, điều này gây ra do dự toán tồi dựa vào các thông tin không đúng. Thông tin là thành phần cơ bản của bất cứ thể loại quản lý nào. Do đấy, giám sát tồi đi đối với luông thông tin không thích hợp là cốt lõi của quản lý dự án tồi. Cả ba vấn đề trên mô tả hậu quả chung của quản lý tồi. Danh mục các vấn đề kéo theo hẳn đúng là bao trùm hầu hết các kiểu vấn đề phát triển dự án. Các ph•ơng pháp tạo lập những kênh thông tin có hiệu lực và những qui trình báo cáo đ•ợc tổ chức tốt sẽ đ•ợc mô tả ở ch•ơng 5. 2.2. Phân tích rủi ro. Nhìn xa là phẩm chất quản lý tuyệt hảo th•ờng có thể đ•ợc phát triển theo 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 đ•ợc gọi là sự phân tích rủi ro và là một ph•ơng tiện hiệu quả để đấu tranh chố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•ởng cơ bản là nếu một vấn đề có nảy sinh thì một giải pháp đã có sẵn. Giống nh• 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ải phá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 để theo dõi vấn đề. Trong các tr•ờng hợp khác, chi phí có thể là lớn lao, chẳng Quản lý dự án phần mềm 27 hạn, giá của một bộ phận thay thế của thiết bị phát triển. Trong mọi tr•ờng hợp, một vấn đề đã đ•ợc phân tích và giải quyết sớm hơn thì đơn giản hơn rất nhiều so với việc giải quyết vấn đề sau khi phát sinh bất ngờ. 2.2.1. Dự kiến những vấn đề cần giải quyết. Giai đoạn đầu tiên của phân tích rủi ro đòi hỏi duyệt xét mọi kế hoạch quản trị và kỹ thuật của dự án nhằm minh định các vấn đề tiềm ẩn nó bao gồm: - Kế hoạch phát triển dự án. - Đặc tả yêu cầu. - Đặc tả thiết kế. Bảng 2.1. Thí dụ về danh sách vấn đề dự liệu Vấn đề Mô tả 1. Chậm giao máy tính để phát triển Nếu máy tính để phát triển không đ•ợc giao vào 1/6 nh• kế hoạch, giai đoạn thích hợp sẽ bị chậm. 2. Bộ nhớ không đủ Cỡ của phân l•u trữ bộ nhớ của hệ thống có thể v•ợt 8 mêga baitơ (cỡ bộ nhớ tối đa đ•ợc vi tính 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ều hà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 đầu và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ối thiểu. Nếu có sự thay thể nhân sự quá mức bình quân trong phát triển chúng ta sẽ tr•ợt thêm lịch trình. 6. Truyền thông quá chậm Góc truyền thông chuẩn quá chậm. Thiết kế dựa trê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 đúng thờ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 xem xét và đánh giá. Các thí dụ có thể là sự lệ thuộc ở nguồn bên ngoài nh• Quản lý dự án phần mềm 28 chủ thầu phụ, ng•ời bán hàng, nhà cung cấp và các nhà làm dịch vụ. Các vấn đề sẽ nảy sinh nếu các hợp phần hay dịch vụ bên ngoài không đ•ợc cung cấp kịp thời hay không hoạt động nh• trông đợi. Đặc tả thiết kế dự án là một kế hoạch chi tiết về việc làm thế nào để các yêu cầu đ•ợc thực hiện. Các quyết định về sự thực hiện đ•ợc đòi hỏi có thể chứa các vấn đề tiềm năng. Chẳng hạn, các vấn đề sẽ nảy sinh ra nếu phần cứng đ•ợc lựa chọn lại hóa ra không thích hợp, chẳng hạn nh• CPU 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ảng 2.2. cho một thí dụ về danh sách vấn đề dự liệu. Danh sách vấn đề dự liệu nên đ•ợc tập hợp nhờ có sự tham gia của các thành viên chính của đội ngũ phát triển dự án. Những ng•ời khác có thể cũng đ•ợc mời đóng góp cho danh sách đó, căn cứ ỉw kinh nghiệm cùng kiến thức kỹ thuật hay quản trị của họ; Có thể bao gồm cả những ng•ời từ các đội ngũ dự án khác, các nhóm hỗ trợ phòng pháp chế hay phòng mua sắm (kinh doanh) của công ty. Trong khi mục tiêu không phải là liệt kế mọi vấn đề nhận thức đ•ợc mà mỗi dự án có thể kinh qua, cần thiết là minh định những vấn đề hẳn đ•ợc xem một cách hợp lý là có liên quan đến dự án. Trong mọi tình huống, giai đoạn phân tích sau đây đ•ợc nhằm để cách ly chỉ những vấn đề nào có thể tác động lớn lao đến dự án và có thể một cách hợp lý đ•ọc xem là hẳn sẽ xảy ra 2.2.2. Pha phân tích Việc phân tích danh sách những vấn đề dự liệu đòi hỏi đánh giá mỗi vấn đề nhằm: 1. Dự toán xác suất vấn đề sẽ xảy ra. 2. Dự toán sáo động của vấn đề tới dự án 3. Quy cho mức độ nghiêm trọng của vấn đề. Xác suất đó và tác động đó nếu đ•ợc dự toán bởi quá một ng•ời. Mọi hạng mục trong danh sách đ•ợc dự toán tốt nhất trong một cuộc họp duy nhất đánh giá vấn đề để đảm bảo tính t•ơng đối của mức độ nghiêm trọng, giữa các vấn đề không bị lệch lạc. Mục tiêu là tránh những tình huống khi việc chậm giao của bên cung cấp A đ•ợc một ng•ời dự toán là 0.8 và việc chậm giao của bên cung cấp B đ•ợc một ng•ời khác dự toán là 0.6 trong khi cả 2 nhà dự toán hẳn đồng ý là hai xác suất này là bằng nhau. Nếu hai ng•ời ở trong cùng 1 phòng trong cùng 1 lúc thì sự lệc lạc t•ơng đối đó giảm đi. Một cách đơn giản và hiệu quả để tính mức độ nghiêm trọng của mỗi vấn đề đ•ợc dự liệu là: 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ất với 10). Quản lý dự án phần mềm 29 2. Gán một số giữa 1 và 10 căn cứ ở tác động của vấn đề với dự án với 10 biểu thị tác động cao và 1 tác động thấp. 3. Nhân trị giá có đ•ợc ở b•ớc (1) với tự giá có đ•ợc ở b•ớc (2) để tính mức độ nghiêm trọng cho vấn đề. Bảng 2.2. giới thiệu một thí dụ về cách tính mức độ nghiêm trọng có sử dụng các vấn đề dự liệu mô tả ở bảng 2.1. Bảng 2.2. Thí dụ về cách tính mức độ nghiêm trọng. ST T Vấn đề Kỳ vọng Tác động Nghiêm trọng 1 Chậm giao máy tính để phát triển 6 5 30 2 Bộ nhớ không đủ 4 2 8 3 Không có chuyên gia hệ điều hành 5 5 25 4 Thời gian đáp ứng của hệ thống quá chậm 5 3 15 5 Thuyên chuyển nhân sự cao 5 8 40 6 Truyền thông quá chậm 2 8 16 7 Chậm giao hệ thống phụ cơ sở dữ liệu 3 9 27 Sau khi mức độ nghiêm trọng đã đ•ợc tính cho mỗi vấn đề dữ liệu, danh sách đ•ợc phân loại theo dự nghiêm trọng của vấn đề trong đó vấn đề nghiêm trọng nhất đứng đầu danh sách. Sau đó có thể quyết định xem vấn đề nào có mức độ nghiêm trọng ít hơn một trị giá nào đó (thí dụ 10) sẽ không đ•ợc xem xét. Sau đây những vấn đề còn lại đ•ợc đánh giá và tiến trình hành động chi tiết, gọi là kế hoạch đối phó bất ngờ đ•ợc lựa chọn cho mỗi vấn đề. Rồi thông tin đ•a vào bảng đối phó bất ngờ. Với mỗi lần đ•a vào bảng, một thành viên của đội ngũ phát triển đ•ợc bố trí là ng•ời theo dõi để theo dõi vấn đề và báo động quản lý dự án khi kế hoạch đối phó bất ngờ cần đ•a vào hoạt động giai đoạn này đ•ợc trình diễn ở bảng 2.3. 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ến triể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ầu phụ thông báo chậm trễ lịch trình hay một quyết định thiết kế chủ yếu thấy cần phải hiệu chỉnh). Quản lý dự án phần mềm 30 Bảng 2.3. Thí dụ về bảng ngẫu nhiên Vấn đề Nghiêm trọng Kế hoạch đối phó bất ngờ Ng•ời theo dõi 5 Thuyên chuyển nhân sự cao 40 Cho tiền th•ởng hoàn thành dự án thắng lợi. J.Smith 1 Chậm giao máy tính để phát triển 30 Yêu cầu làm ca đêm về hệ thống phát triển của dự án khác. H.Brown 7 Chậm giao hệ thống phụ cơ sở dữ liệu 27 Thiết kế một mô phỏng hệ thống phụ cơ sở dữ liệu dùng để tích hợp. W.Alda 3 Không có chuyên gia hệ điều hành 25 Bố trí chuyên gia hệ điều hành ngoài công ty và thuê làm t• vấn H.Brown 6 Truyền thông quá 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ói vói dự án này. H.Troy 4 Thời gian đáp ứng của hệ thống quá chậm 15 Cho vào điều khỏan thỏa thuận nâng cấp CPU trong hợp đồng mua máy tính. Y.Krot 2 Bộ nhớ không đầy đủ 8 (không xem xét) 2.2.3. 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ững tr•ờng hợp sau: 1. Vấn đề dữ liệu diễn ra hay sắp xảy đến đến nơi. 2. Kế hoạch đối phó bất ngờ đòi hỏi đ•ợc chuẩn bị tr•ớc. Nói chung, các kế hoạch đối phó bất ngờ có thể đ•ợc nhìn nhận theo nh• cái kế hoạch, hành động đ•ợc xếp vào ngăn kéo để phòng khi dùng đến sau này. Dù sao, trong vài tr•ờng hợp, kế hoạch đ•ợc thực hiện tr•ớc khi vấn đề dự liệu xảy ra nh• phát triển một bộ mô phỏng tr•ờng hợp việc giao một hợp phần quyết định bị chậm trễ. Sau đó, nếu họpw phần đ•ợc giao đúng hạn thì bộ mô phỏng đó có thể bị bỏ đi. Lấy thí dụ về quá trình hoàn chỉnh chúng ta thử xem xét một dự án truyền thông cần đến một máy tính trung tâm nối bằng mạng diện rộng với vài vị trí máy tính nhỏ, có hai vấn đề tiềm ẩn đ•ợc minh định. - Hai máy tính có kiến trúc khác nhau có thể diễn giải thể thức truyền thông đã thiết kế đ•ợ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). Quản lý dự án phần mềm 31 - Công ty điện thoại đ•ợc chọn có thể không có khả năng lắp đặt đ•ờng dây thử nghiệm đún ghẹn cho pha tích hợp. Bảng 2.4. Danh mục vấn đề dữ liệu Vấn đề Mô tả 1. thể thức truyền thông không t•ơng hợp. Hai máy tính có kiến trúc khác nhau có thể diễn giải thể thức truyền thông đã thiết kế là khác nhau. 2. Đ•ờng dây thử nghiệm có chậm để tích hợp. Công ty điện thoại đ•ợc chọn có thể không có khă năng lắp đặt đ•ờng dây thử nghiệm đúng hạn để tích hợp. Bảng 2.5. Đo mức độ nghiêm trọng Vấn đề Kỳ vọng Tác động Độ nghiêm trọng 1. Thể thức truyền thông không t•ơng hợp 5 8 40 2. Đ•ờng dây thử nghiệm có chậm để tích hợp. 8 6 48 Bảng 2.6. Bảng đối phó bất ngờ Vấn đề Độ nghiêm trọng Kế hoạch đối phó bất ngờ Ng•ời theo dõi 1. Đ•ờng dây thử nghiệm có chậm để tích hợp. 48 Đặt hàng đ•ờng dây từ 2 công ty điện thoại phụ Will Doo 2. Thể thức truyền thông không t•ơng hợp. 40 Sử dụng gói thông tin ASCII I.Hope Các bảng 2.4; 2.5 và 2.6 là các bảng phân tích rủi ro cho dự án truyền thông đó. Nừu khả năng có đ•ợc đ•ờng dây truyền thông bị chậm lại, điều này sẽ gây ít tác hại cho dự án hơn là vấn đề thể thức không t•ơng hợp. Việc theo dõi vấn đề này đã đ•ợc giao cho Wieliam Joo.Trách nhiệm của ông là đảm bảo những đ•ờng dây này đ•ợc đặt hàng từ hai công ty điện thoại khác (chỉ cho pha tích hợp thôi). Nếu công ty điện thoại có •u tiên thế sẵn sàng đúng hẹn thì những đơn đặt hàng từ hai công ty khác đ•ợc hủy và khả năng phí hủy bỏ phải trả. 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 Quản lý dự án phần mềm 32 A.SCII đơn đ•ợc đặt cho cả hai máy tính phí về gói áCII sẽ là lãng phí nếu thể thức nhị phân đ•ợc chọn sẽ hoạt đồng. Giải phóng áCII thay thế hầu nh• chắc chắn chậm hơn nhiều, nh•ng nó sẽ cung cấp giải pháp tạm thời cho đến khi vấn đề không t•ơng hợp đ•ợc giải quyết. 2.3. Tóm tắt Các ph•ơng pháp quản lý dự án hiện đại lúc đầu quan tâm đến việc các vấn đề phát triển dự án (việc phòng ngừa không hiệu chỉnh). Phòng ngừa các vấn đề thì dễ hơn và ít tốn kém hơn là giải quyết chúng, những biện pháp phòng ngừa có hiệu quả nêu là: - Định vị các vấn đề và các vấn đề tiềm ẩn sớm. - Giải quyết vấn đề tr•ớc khi tuột khỏi tầm tay. - Lập kế hoạch tr•ớc cho những vấn đề tiềm ẩn Có rất nhiều vấn đề cơ bản chung cho hầu hết các dự án phầm mềm. Phần lớn những vấn đề đó dẫn xuất từ: - Xác định yêu cầu không đầy đủ. - Thay đổi luôn - Dự toán tồi - Tùy thuộc ở nguồn bên ngoài (ng•ời bán, chủ thầu phụ v.v...) - Khó khăn trong kết thúc dự án. - 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ững thay đổi đặc tả yêu cầu luôn luôn và không kiểm tra là không thuận lợi đ•ợc coi nh• nguồn gốc chủ yếu của những vấn đề thiết kế. Những chủ thầu phụ và ng•ời bán không giám sát đ•ợc là một trong hầu hết những nguồn gốc bất ngờ, những vấn đề kỹ thuật l•u lại và chậm chễ vào phút chót. Với nhà quản lý dự án thì biết đ•ợc ở đây phải tìm là quan trọng nh• biết đ•ợc phải làm gì. Biết phải làm gì bao gồm cả việc chuẩn bị tr•ớc sự xuất hiện của vấn đề. Trong nhiều tr•ờng hợp, các vấn đề có thể đ•ợc dự liệu. Nhà quản lý dự án có thể lập kế hoạch về khả năng vấn đề sẽ xảy ra bằng cách dự tính xác suất của nó, •ớc l•ợng tác động của nó và chuẩn bị giải pháp thay thế. Cái đó đ•ợc gọi là phân tích rủi ro và là biện pháp có hiệu quả trong việc đấu tranh với những vấn đề phát triển tiềm ẩn. 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ình thứ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ải phá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 Quản lý dự án phần mềm 33 mọi tr•ờng hợp vấn đề đã đ•ợc phân tích giải quyết tr•ớc lại đơn giản hơn là giải quyết vấn đề đã xảy ra bất ngờ. Bài tập 1. Một công ty dịch vụ truyền hình cáp đang chuẩn bị thiết lập dịch vụ trong thời gian 8 tháng. Công ty cung cấp dịch vụ cho các khách hàng với phí cố định hàng tháng tùy thuộc ở qui mô dịch vụ mà họ yêu cầu. Công ty cũng cho chiếu những phim mới mỗi phim có thể cho một khách hàng xem theo yêu cầu qua điện thoại với công ty. Giờ công ty đang trong 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ới thiết bị để nhận thông tin về các buổi chiếu phim mói trên màn ảnh và sẽ giao diện với cơ sở dữ liệu của khách hàng để thông tin đều đặn về hóa đơn hàng tháng. Bạn hãy chuẩn bị một danh mục m•ời vấn đề gay cấn nhất mà bạn chi liệu trong phát triển dự án làm hóa đơn. Hãy thỏa thuận lý do của việc chọn lựa vấn đề của bạn. 2. Bạn hãu tính mức độ nghiêm trọng cho mỗi một vấn đề tiềm ẩn mà bạn đã định ở bài tập 1. Hãy giải thích việc phân định của bạn về tác động của dự án và các trị giá xác suất. Hãy gợi ý một ph•ơng pháp thay thế phân định mức độ nghiêm trọng cho những vấn đề dự liệu mà nó cũng tính cả chi phí chuẩn bị các kế hoạch đối phó bất ngờ. 3. Bạn hãy gợi ý những kế hoạch đối phó bất ngờ cho những vấn đề dự liệu mà bạn đã định ở bài tập 1. Hãy xét hai kế hoạch thay thế khác nhau cho mỗi một vấn đề. Xét chi phí của mỗi kế hoạch thay thế và sau đó chọn kế hoạch tốt nhất dựa trên ph•ơng pháp thay thể để phân định mức độ nghiêm trọng mà bạn gợi ý ở bài tập 2. Hãy chuẩn bị một bảng đối phó bất ngờ có chứa các kế hoạch đối phó bất ngờ mà bạn đã chọn. 4. Bài tập ở lớp: Chia lớp thành các nhóm 3 hay 4 sinh viên. Giao các bài tập 1, 2, 3 cho mỗi hóm. Yêu cầu mỗi nhóm trình bày phân tích rủi ro của mình cho số nhóm còn lại trong lớp. Thảo 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ự ?) Quản lý dự án phần mềm 34 Ch•ơng ba Phát triển phần mềm theo hợp đồng Mối quan hệ khách hàng - nhà phát triển Do những thay đổi nhanh chóng trong công nghệ trong vài thập niên gần đây, các tổ chức công nghệ cao ngày càng thấy cần thiết phải chuyển hóa trong các lĩnh vực đặc chủng, xác định rõ việc chuyển hóa không chỉ xác định nhiều nhánh mới của công trình học mà còn xác định những lĩnh vực chuyên môn trong phạm vi các bộ môn công trình học. Điều này đặc biệt đúng với công trình phần mềm. Thông th•ờng, các tổ chức không chuyên hóa trong phát triển phần mềm lại thuê các tổ chức khác phát triển phần mềm cho họ. Ngay cả những tổ chức có phát triển phần mềm của chính mình có thể quyết định thuê các chuyên gia bên ngoài ở những lĩnh vực đặc chủng. IBM đã thuê Mirosoft phát triển hệ điều hành PC DOS, vì Microft đã có kinh nghiệm trong phát triển các hệ thống vi tính còn IBM thì không. Ch•ơng này đề cập đến mối quan hệ giữa khách hàng và nhà phát triển phần mềm và cung cấp một số h•ớng dẫn làm sao tránh những cái bẫy cổ điển do những lợi ích mẫu thuẫn nhau. Mổc dù nhiều những vấn đề đó là chung cho mọi quan hệ khách hàng, nhà phát triển một số vấn đề tranh cãi là đặc biệt cho phát triển phần mềm. Việc phát triển phần mềm là rất ít xác định hơn và nhiều rủi ro hơn các lĩnh vực khác của công nghệ. Điều này th•ờng dẫn đến những hiểu lầm và bất đồng đáng ra đã có thể tránh đ•ợc nếu đ•ợc dự liệu và kiềm chế đủ sớm. Để tiêu chuẩn hóa thuật ngữ của chúng ta, tổ chức mà đề nghị đ•ợc đệ trình sẽ đ•ợc coi là khách hàng và tổ chức đệ trình đề nghị sẽ đ•ợc coi là ng•ời đề nghị. Các từ khác th•ờng đ•ợc sử dụng ở nơi khác cho ng•ời đề nghị bao gồm ng•ời đấu thầu, ng•ời bán hàng hay chủ thầu và cho khách hàng là ng•ời yêu cầu hay ng•ời đề xuất yêu cầu. Tổ chức đ•a ra đề nghị đ•ợc thẳng thầu sau khi lựa chọn, sẽ đ•ợc coi là nhà phát triển. 3.1. Chi phí cộng thêm đối lại với giá cố định. Th•ờng vẫn có mâu thuẫn về quyền lợi thực sự hay t•ởng t•ợng giữa khách hàng với ng•ời phát triển. Khách hàng thì muốn chi phí ít hơn và ng•ời phát triển lại muốn thu nhập nhiều hơn. Nh• chúng ta sẽ thấy mối quan hệ tốt giữa ng•ời phát triển và khách hàng không cần thiết phải dẫn đến tranh chấp về quyền lợi nh• thế. Cơ bản có 2 loại quan hệ theo hợp đồng giữa khách hàng và ng•ời sản xuất. 1. Chi phí cộng thêm (cũng gọi là chi phí theo thời gian và vật liệu) Quản lý dự án phần mềm 35 2. Giá cố định Hầu hết các quan hệ khác là một hình thức phối hợp nào đó giữa hai loại đó. 3.1.1. Hợp đồng phí cộng thêm Phí cộng thêm là mối quan hệ theo hợp đồng theo đó ng•ời phát triển đ•ợc trả cho chi phí dịch vụ đã làm và thêm vào đấy đ•ợc phép h•ởng mức lời thỏa thuận. Điều này thực ra giống nh• cho thuê ô tô: khách hàng trả cho số thời gian xe đ•ợc sử dụng (theo giờ, ngày, tuần v.v...) và cho mọi chi phí khác nh• bảo hiểm và xăng. Theo thế trong một hợp đồng phí cộng thêm, tổng phí của một dự án chỉ đ•ợc biết sau khi dự án đã hoàn thành. Lấy thí dụ, công ty Alpha có thể hợp đồng với công ty phần mềm Bêta để phát triển một hệ thống. Công ty Bêta sẽ đ•ợc công ty Alpha trả cho 180 cho mỗi giờ các kỹ s• của minh đầu t• cho dự án một khoản 20% bổ sung có thể đ•ợc thêm vào để bù đắp dịch vụ quản lý th• ký hay văn phòng khác. Các chi phí phụ phát sinh bởi công ty Bêta vì lợi ích của dự án sau đó đ•ợc công ty Alpha bồi hoàn các chi phí đó có thể bù đắp các lĩnh vực nh•: - Thiết bị phát triển của mục đích đặc tr•ng (máy tính, các bộ dịch, các mạng v.v...) - Chi phí đi lại phát sinh bởi nhân viên công ty Bêta vì lợi ích của dự án. - Thiết bị mục tiêu do công ty Bêta cung cáp cho công ty Alpha sử dụng. - Dịch vụ từ các nguồn bên ngoài khác do công ty Bêta yêu cầu cho dự án. Khách hàng (Công ty Alpha) có thể yêu cầu ng•ời phát triển (Công ty Bêta) phải đ•ợc phép tr•ớc về mọi chi phí đơn lẻ phát sinh v•ợt quá $250 và mọi chi phí v•ợt quá $600 tổng số hàng tháng. Mọi việc cho phép nh• thế luôn phải bằng văn bản. Điều này xác định quan hệ hợp đồng cơ bản về phí cộng thêm giữa hai công ty. Trong nhiều tr•ờng hợp, hợp đồng phí cộng thêm là tốt nhất có việc phát triển. Tuy nhiên, cũng có vô khối các vấn đề tiềm tàng. Một mâu thuẫn về quyền lợi có thể xảy ra do ng•ời phát triển động cơ hoàn thành dự án nhanh, hoặc do khách hàng miễn c•ỡng cho phép các chi phí phụ thêm. Phí cộng thêm th•ờng thích hợp cho những dự án nhỏ không xác định khi có khó khăn trong việc nhận biết tr•ớc các yêu cầu của dự án. Trên thực tể trong nhiều tr•ờng hợp pha yêu cầu dự án đ•ợc chào hàng nh• hợp đồng phí cộng thêm và các pha còn lại đ•ợc hợp đồng theo kiểu giá cố định, giai đoạn yêu cầu đ•ợc sử dụng để đ•a các phần còn lại của dự án đến trạng thái đủ xác định tốt mà nhờ nó có thể đ•ợc hợp đồng theo kiểu gia cố định đôi khi một công ty Quản lý dự án phần mềm 36 đ•ợc ban cho hợp đồng phí cộng thêm cho giai đoạn yêu cầu về công ty khác đ•ợc ban cho các hợp đồng giá cố định với giai đoạn còn lại. Phí cộng thêm có thể đ•ợc chuộng ở khác hàng muốn nắm quyền kiểm soát quá trình phát triển. Trong một số tr•ờng hợp, ng•ời sản xuất đ•ợc coi nh• phần mở rộng của tổ chức của khách hàng và các hoạt động phát triển do khách hàng quản lý. Hợp đồng phí cộng thêm phải bao gồm các điều sau: - Danh sách những ng•ời đ•ợc giao làm dự án - Xác định công việc - Tỷ lệ phần trăm giao việc cho mỗi ng•ời - Mức công việc hàng giờ hay hàng ngày cho mỗi ng•ời - Tổng phí hành chính - Chi phí đ•ợc phép để đ•ợc bồi hoàn - Thủ tục làm hóa đơn - Thủ tục thanh toán - Thủ tục kết thúc Phần trăm giao việc liên quan đến số thời gian mà mỗi ng•ời sẽ giành cho dự án. Nó có thể là 100% cho một số kỹ s•, và 50-60% cho các chuyên gia trong các lĩnh vực đặc biệt. Tỷ lệ phần trăm giao việc cũng có thể đ•ợc tính hiểu theo tối đa hay tối thiểu, có nghĩa, chẳng hạn, một kỹ s• bảo hành chất l•ợng sẽ giành không quá 20 giờ mỗi tuần cho dự án và không ít hơn 10 giờ mỗi tuần cho dự án. Giá suất lập phiếu có thể là giá suất cố định cho mọi ng•ời đ•ợc giao việc của dự án hay mức cá nhân có thể đ•ợc đặt cho từng lớp ng•ời. Chẳng hạn với mỗi giờ làm việc cho dự án, ng•ời sản xuất sẽ lập phiếu thanh toán $80, bất kể ai làm việc cho giờ đó. Hay hợp đồng có thể qui định là kỹ s• thiết kế đ•ợc lập phiếu thanh toán $120 một giờ, ng•ời lập mã $60 một giờ, ng•ời viết t• liệu $50 một giờ và cứ tiếp tục. Ph•ơng pháp giá suất lập phiếu hợp đồng phí cộng thêm hầu nh• khó nhất là ph•ơng pháp lập phiếu thanh toán cá nhân theo Franh Jones đ•ợc lập phiếu thanh toán $90 một giờ John Shith $75 v.v... Điều này có nghĩa mỗi khi một ng•ời đ•ợc thay thế hay bổ sung cho dự án thì giá suất theo giờ lại phải th•ơng thảo lại. Đối với một tổ chức phát triển phần mềm, có thể có những thuận lợi thiết thực trong các hợp đồng phí cộng thêm bao 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 đối với một số bật lợi bao gồm: - Lợi tức kihnh doanh thập - Có thể có sự bất bình trong nhân sự - Kiểm tra nhân sự và công việc phát triển - 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 Quản lý dự án phần mềm 37 Hầu hết nhân viên chuộng có đ•ợc xác định rõ ràng về tôn ti mà họ tùy thuộc. Trong hợp đồng phí cộng thêm, nhân viên làm việc trong phạm vi tôn ti của khách hàng nh•ng lại thuộc về tôn ti của ng•ời phát triển và điều này có thể gây ra bất mãn. Nói chung, theo quan điểm của ng•ời phát triển, hợp đồng phí cộng thêm là mối quan hệ kinh doanh vững chãi, lợi tức thấp, không rủi ro. Theo quan điểm của khách hàng thuận lợi của hợp đồng phí cộng thêm là: - 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 đồng bất cứ lúc nào) Bất lợi có thể có của khách hàng là: - Chi phí phát triển gia tăng - Khách 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ộng thêm. Rõ ràng điều này thùy thuộc ở loại dự án và điều kiện để dự án phát triển cũng nh• ở nhận định kinh doanh không kỹ thuật khác. 3.1.2. Hợp đồng giá cố định Hợp đồng giá cố định là một cam kết của ng•ời phát triển sẽ cung cấp sản phẩm hay dịch dụ thỏa thuận với phí thỏa thuận trong phạm vi lịch trình thỏa thuận. Điều này t•ơng tự với mua tíc kê xe 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 vi thời gian biểu đã công bố với phí thỏa thuận. Tờt nhiên, du khách có thể chọn thuê xe chứ không mua tic kê xe buýt và rồi tự mình lái đến nơi của mình. Dù sao, điều này có thể trở nên tốn kém hơn và đòi hỏi ở ng•ời du khách đôi chút kỹ năng và kiến thức tr•ớc nh• kỹ năng lái xe và kiến thức về hành trình đến nơi. Nừu du khách (hay khách hàng) phải quyết định giữa việc tự mình tạo ra dịch vụ và việc hợp đồng với ai đó để cung cấp dịch vụ. Hợp đồng giá cố định chỉ có thể đ•ợc vận dụng cho một dự án xác định rõ. Cả khách hàng và ng•ời sản xuất phải có khả năng xác định sản phẩm hay dịch vụ cuối cùng mong muốn. Một khi điều này để thực hiện đ•ợc, một trong những yếu kém chính của hợp đồng cố định sẽ đ•ợc khắc phục. Lợi ích của hợp đồng giá cố định cho ng•ời phát triển là: - Khống chế đầy đủ quá trình phát triển - Lợi ích kinh doanh có thể cao hơn - Cam kết cho dự án trọn vẹn Quản lý dự án phần mềm 38 - Cam kết cho dự án trọn vẹn là •u việt đáng kể so với hợp đồng phí cộng thêm ở đó nó có thể kết thúc bất cứ lúc nào tùy sự xét đoán của khách hàng. Tất nhiên, hợp đồng giá cố định cũng có một số bất lợi cho ng•ời phát triển, bao gồm: - Đảm nhận rủi ro kinh doanh và phát triển - Bất đồng tiềm ẩn với khách hàng do: + thay đổi yêu 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ủa công ty và phát sinh lợi tức đảm bảo tăng tr•ởng. Bất hạnh là những dự án này cũng gây ra lỗ và th•ờng tác hại nghiêm trọng cho công ty cạnh tranh gay gắt để có hợp đồng quan trọng đôi khi làm cho công ty nhận thầu giá thấp cuối cùng gây ra lỗ cho ng•ời phát triển. Hầu nh• không thể tránh khỏi trong bất kỳ dự án nào ng•ời phát triển đ•ợc đòi hỏi thay đổi yêu cầu trong quá trình phát triển. Những thay đổi nh• thế th•ờng đi liền với chi phí bổ sung đòi khánh hàng và bao giờ cũng là nguyên nhân bất đồng giữa ng•ời sản xuất và khách hàng. Điều này th•ờng là do yêu cầu không rõ hay mơ hồ và nó lại dẫn đến bất đồng về chỉ tiêu trong việc hoàn thành dự án. Về cơ bản, điều này làm cho hợp đồng trở lại trạng thái không đ•ợc xác định đầy đủ. Theo quan điểm của khách hàng, •u việt của hợp đồng giá cố định bao gồm: - Ngân sách cố định cho dự án - Hầu hết các rủi ro phát triển đ•ợc chuyển sang ng•ời phát triển + tham gia tối thiểu trong quá trình phát triển Bất lợi cho khách hàng là: - Rủi ro chậm giao sản phẩm - 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ển lẫ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. Quản lý dự án phần mềm 39 Phí cộng thêm và giá cố định là hai trong số mối quan hệ theo hợp đồng cổ truyền giữa ng•ời phát triển và khách hàng. Có nhiều biến thức của hai mối quan hệ cơ bản đó kể cả các ghép nối phù hợp với các dự án đặc tr•ng. Một số trong những quan hệ đó liên kết với vai trò của khách hàng và ng•ời phát triển nhằm tạo nhiều yếu tố kích thích hơn cho ng•ời phát triển hỗ trợ mục tiêu của khách hàng ngoài những tránh nhiệm theo hợp đồng. Những loại khác của quan hệ khách hàng - ng•ời phát triển bao gồm: - Phối hợp giá cố định và phí cộng thêm - Liên doanh - Thỏa 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ộng thêm và giá cố định trong đó phần các yêu cầu đ•ợc phát triển theo phí cộng thêm và các phần còn lại của dự án phát triển theo gía cố định. Liên doanh là những tr•ờng hợp mà ranh giới giữa khách hàng và ng•ời phát triển có thể trở nên mờ ảo và phiền những thuận lợi và bất lợi thảo luận tr•ớc đây có thể không vận dụng đ•ợc. Có nhiều tr•ờng hợp mà một số hình thức liên doanh có thể là mong muốn cho hai bên nh• khi ng•ời phát triển muốn duy trì quyền về sản phẩm, hay khi ng•ời phát triển chung sức với khách hàng tài trợ một phần của cố gắng phát triển. Có một cách mà khách hàng có thể chào ng•ời phát triển tham gia vừa phải vào mặt kinh doanh của dự án là bằng cách thay thế bản quyền coi nh• thanh toán một phần. Điều này tạo nên qui mô bổ sung cho lợi ích của ng•ời phát triển trong thành công của dự án. Bản quyền thông th•ờng là ở chỗ thất bại của dự án có thể tạo nên ít lợi nhuận cho ng•ời phát triển hơn là một hợp đồng giá cố định thẳng thừng và thắng lợi của dự án sẽ làm tăng lợi nhuận của ng•ời phát triển. Mối quan hệ lâu dài th•ờng là quan trọng cho ng•ời phát triển. Trong nhiều tr•ờng hợp, những cam kết dài hạn cũng nằm trong lợi ích của khách hàng. Điều này xảy ra khi ng•ời phát triển do gắn bó ở hợp đồng ban đầu, giành đ•ợc lợi thế chủ yếu, qua kiến thức thu l•ợm, đối với những ng•ời khác cho công việc phát triển tiếp sau. Rõ ràng khi ng•ời phát triển hoàn thành thắng lợi một dự án lớn và phức tạp, anh ta có đ•ợc một lợi thế đáng kể so với các công ty khác về các tăng c•ờng trong t•ơng lai của dự án đó. Cam kết lâu dài theo đó có thể có lợi ích t•ơng hỗ cho cả hai bên trong đó khách hàng đảm bảo các dịch vụ sau này của ng•ời phát triển và ng•ời sản xuất đảm bảo cam kết thu nhập lâu dài. 3.3. Yêu cầu đối với một đề xuất (RFP). Phát triển phần mềm theo hợp đồng bắt đầu từ việc khách hàng lựa chọn ng•ời phát triển phần mềm. Yêu cầu về đề nghị hay RFT (ở Anh cũng gọi là mời thầu) là b•ớc đầu của quá trình lựa chọn. Để hiểu xem Quản lý dự án phần mềm 40 RFP cần đ•ợc chuẩn bị thế nào, tr•ớc hết chúng ta hãy duyệt lại các b•ớc dẫn tới một quyết định đ•a ra yêu cầu về đề nghị. Trong ph•ơng pháp tiếp cận theo pha để phát triển phần mềm, thì pha tiềm dự án th•ờng đ•ợc xem là pha thai nghén. Đây là giai đoạn mà ý t•ởng đằng sau dự án kết tinh và hình thành dự án. Đây cũng là giai đoạn mà tổ chức quyết định xem dự án có thể đ•ợc phát triển nội bộ hay sẽ phải hợp đồng với một công ty khác. Các RFP không chỉ đ•ợc phát ra cho các dự án 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 cho riêng một pha đơn lẻ của dự án. Mọi RFP chuẩn bị kỹ phải có cũng thông tin cơ bản; các RFP không hoàn chỉnh cho kết quả là các đề nghị không hoà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 gian phải sẵn sàng ? - Ai, trong tổ chức, đ•ợc ủy thác trách nhiệm lựa chọn ng•ời phát triển ? - Mức ngân sách nào đ•ợc giành cho hợp đồng ? Tất cả những vấn đề trên phải đ•ợc nêu ra đầy đủ tr•ớc khi sang b•ớc sau: việc chuẩn bị các RFP. 3.3.2. Chuẩn bị các RFP. Yêu cầu tốt với đề nghị là yêu cầu sẽ lôi cuốn đ•ợc những đáp ứng tốt nhất (đề nghị). Chuẩn bị RFP tốt th•ờng đòi hỏi sự cộng tác của nhiều ng•ời, mỗi một ng•ời đ•ợc giao trách nhiệm về những phần đặc biệt của RFP. Một RFP phải bao gồm những phần sau: 1. Phát triển vấn đề và các mục tiêu dự án. Phần này cung cấp thông tin nền tảng chung, kể cả mô tả vấn đề cần đ•ợc giải quyết. Phần này phải cung cấp mọi chi tiết thích đáng cần thiết để hiểu vấn đề, kể cả biểu đồ, báo cáo và thí dụ. 2. Các yêu cầu kỹ thuật. 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ó Quản lý dự án phần mềm 41 - Yêu cầu cơ sở dự liệu (nh• khả năng yêu cầu, các quan hệ dữ liệu v.v...) - Truyền thông và kiến trúc mạng - Các chuẩn quân sự, chuẩn chính quyền hay các chuẩn đ•ợc yêu cầu khác - Ph•ơng pháp luận phát triển yêu cầu - Độ tin cậy của hệ thống - Ràng buộc về thời gian - Ngôn ngữ lập trình - Máy tính chủ (host computer) 3. Thông tin quân sự Phần này cung cấp thông tin liên quan đến việc trình bày về thể chất đề nghị nh•: - Ai có thể trả lời cho RFP - Yêu cầu làm sáng tỏ và các thông tin bổ sung thế nào - Ngày tháng và địa điểm họp theo lịch với các nhà đề nghị - Chỉ tiêu lựa chọn đề nghị Phần này cũng có dự phòng về kết quả là tổ chức đ•a ra RFP sẽ không bị bắt buộc lựa chọn đề nghị chi phí thấp nhất hay bất cứ đề nghị nào khác. 4. Yêu cầu chi phí Mọi vấn đề tài chính đ•ợc nêu ở phần này. Điều này bao gồm cơ cấu giá yêu cầu trong đề nghị cũng nh• mọi thông tin đặc tr•ng đ•ợc nêu trong đề nghị (nh• giải trình chi phí tổng cộng hay lập giá riêng cho mỗi pha). Phần này cũng có thể nêu rõ loại hợp đồng phát triển nào đ•ợc chào (bản quyền, phí cộng thêm, giá cố định v.v...) 5. T• liệu tham khảo Phần này bao gồm danh sách mọi t• liệu nêu trong RFP nh• tiêu chuẩn, t• liệu hệ thống hiện có, tài liệu về sản phẩm khác v.v... 6. Những thứ giao đ•ợc có yêu cầu Phần này bao gồm giải thích ban đầu về tuyến bố công việc (Sow). Chủ yếu đây là danh sách những thứ giao đ•ợc chính của dự án nh• t• liệu, phần mềm, đào tạo và mọi phần cứng hay thiết bị thích đáng. Phần này cũng thảo luận việc bảo đảm theo yêu cầu cho hệ thống sẽ đ•ợc giao. 7. Định dạng đề nghị yêu cầu Định dạng tiêu chuẩn yêu cầu cho đề nghị đ•ợc mô tả ở phần này. Điều này bao gồm nội dung yêu cầu về: - Đề nghị kỹ thuật - Đề nghị quản lý - Đề nghị về giá cả - Tuyên bố về công việc Thí dụ về một phác họa đề nghị có nêu ở phần 3.4 Phần này cũng bao gồm danh sách mọi thông tin có thể phụ lục cho dự án, ngoài đề nghị cơ bản (theo định dạng mô tả trên) nó có thể bao gồm Quản lý dự án phần mềm 42 báo cáo tài chính mới nhất của tổ chức ng•ời đề nghị hay ủy nhiệm th• kỹ thuật của ng•ời đề nghị. 8. Đệ trình lịch trình và lịch quyết định Những thời hạn quyết định liên quan đến RFP đ•ợc mô tả ở phần này. Nó bao gồm thời gian chậm nhất cho việc đệ trình một đề nghị và ngày dự kiến tiến hành lựa chọn. Nó cũng có thể bao gồm lcịh trình mong muốn để hoàn thành công việc phát triển. Một trong những mục tiêu của RFP là làm cho nhiệm vụ so sánh các đề nghị đ•ợc dễ dàng. Nhiệm vụ này có thể trở nên cực kỹ khó nếu mọi đề nghị đ•ợc cấu tạo khác nhau hay nếu các đề nghị đó đ•ợc dựa trên những giả định rất khác nhau. Phần 3 của phác thảo nói đến cuộc họp với mọi ng•ời đề nghị. Cuộc họp này tạo cơ hội đảm bảo là mọi ng•ời đề nghị đều có một cơ sở chung về hiểu biết và kết quả trong các đề nghị của họ dễ so sánh hơn. Nó cũng thành đạt khi yêu cầu khuôn dạng đề nghị tiêu chuẩn hóa, nêu ở phần 7 của RFP. Bảng 3.1. có nêu phác thảo đại khái của một RFP. Bảng 3.1. Phác thảo khái quát cho một RFP 1. Tuyên bố vấn đề và mục tiêu dự án - Mô tả hiện trạng - 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 2. Yêu cầu kỹ thuật - Giao diện với các hệ thống hiện có - Truyền thông và kiến trúc mạng - Độ tin cậy của hệ thống - Ngôn ngữ lập trình - Yêu cầu cơ sở dữ liệu - Tiêu chuẩn quân sự hay chính quyền - Ràng buộc thời gian - Máy tính chủ 3. Thông tin quản trị - Ai có thể đáp ứng cho RFP - Ngày tháng và địa điểm cuộc họp theo lịch với mọi ng•ời đề nghị ng•ời đ•ợc chọn- Làm sao yêu cầu sáng tỏ hay thông tin bổ sung - Tiêu chuẩn lựa chọn đề nghị - Các thông tin quản trị khác 4. Yêu cầu chi phí - Cơ cấu giá Quản lý dự án phần mềm 43 các dịch vụ các sản phẩm cung cấp - Biện minh cho chi phí - Lập giá riêng từng pha - Loại hợp đồng phát triển đ•a chào - So sánh chi phí của các giải pháp thay thế 5. T• liệu tham khảo - Các tiêu chuẩn - T• liệu về hệ thống hiện có - T• liệu về sản phẩm 6. Yêu cầu chuyển giao - T• liệu - Phần mềm - Phần cứng hay thiết bị thích ứng - Bảo hành hệ thống sẽ chuyển giao - T• liệu về sản phẩm chuyển giao - Huấn luyện - Các công cụ phát triển và thử nghiệm 7. Định dạng đề nghị - Đề nghị kỹ thuật - Tuyên bố công việc - Đề nghị quản lý - Bổ sung và phụ lục + báo cáo tài chính của tổ chức đề nghị + ủy nhiệm th• kỹ thuật của ng•ời đề nghị + Tóm tắt nhân sự chủ lực - Đề nghị lập giá 8. Lịch đệ trình và lịch quyết định - Hạn cuối cùng phải đệ trình đề nghị - Hạn dự kiến tiến hành lựa chọn - Lịch mong muốn hoàn thành công việc phát triển 3.3.3. Phát yêu cầu đề xuất RFP Có pha ph•ơng pháp cơ bản trong phần phát một RFP - Theo một danh mục phân phát hạn chế - Theo một danh mục phân phát rộng - Cho mọi ai yêu cầu Danh mục phân phát hạn chế chỉ có những tổ chức nào đã đ•ợc lựa chọn theo bộ chỉ tiêu đặc tr•ng. Nhiều cơ quan chính phủ duy trì một Quản lý dự án phần mềm 44 danh mục các công ty đ•ợc công nhận cho mỗi lớp RFP. Ph•ơng pháp này loại trừ các tổ chức ít có cơ may, đ•ợc lựa chọn. Danh mục phân phát rộng bao gồm bất cứ tổ chức nào có chút ít cơ may đ•ợc lựa chọn. Với một tổ chức đ•ợc bổ sung vào danh mục chỉ yêu cầu điều đó. Các danh mục phân phát rộng có thể thích hợp cho những dự án nhỏ, những dự án không đòi hỏi giám định đặc biệt nào hay những dự án mà ít tổ chức thích hợp đã nhắm vào. Không phải không phổ biến là thông tin RFP ban đầu đ•ợc quảng cáo trong báo chí hay tạp chí chuyên ngành. Những quảng cáo đã mô tả vắn tắt RFP và mời các công ty yêu cầu bản sao toàn bộ RFP. Sự tiếp cận này th•ờng là thích hợp khi phải tìm kiếm những ng•ời đề nghị tiềm ẩn mới. Bất kể ph•ơng pháp phân phát nào đ•ợc chọn lựa, tổ chức đề xuất RFP phải nhớ là thủ tục đề xuất không kết thúc cùng với sự phân phát RFP. Tổ chức phân phát phải sẵn sàng cung cấp mọi thông tin bổ sung và làm sáng tỏ những điều có thể đ•ợc yêu cầu. Có một cách để thực hiện điều này là (nh• đã nêu). Định lịch họp với mọi ng•ời đề nghị tiềm ẩn nhằm làm sáng tỏ và trả lời mọi câu hỏi. Cuộc họp này cũng là một cơ hội cho các ng•ời đề nghị đi xem một l•ợt các thiết bị mục tiêu và biết đ•ợc tận mắt những vấn đề sẽ đ•ợc dự án giải quyết. 3.4. đề xuất Các loại kiến nghị có thể phần thành 2 phạm trù cơ bản: - Kiến nghị do yêu cầu - Kiến nghị không yêu cầu Kiến nghị do yêu cầu đáp ứng hoặc RFP chính thức hoặc lời mời đặc biệt để trình kiến nghị trong khi kiến nghị không do yêu cầu thông th•ờng do ng•ời đề nghị x•ớng xuất. Tất nhiên có nhiều tổ hợp của hai biểu đó ví nh• tình huống kỳ dị nh•ng th•ờng thấy khi một kiến nghị không do yêu cầu làm nảy sinh việc đề xuất RFP chính thức. 3.4.1. Đề xuất không do yêu cầu Những kiến nghị không do yêu cầu ít chính thức hơn nhiều so với kiến nghị do yêu cầu và th•ờng không là gì hơn là một b•ớc đầu dẫn đến những th•ơng thảo chính thức hơn. Kiến nghị không do yêu cầu phải có những phần cơ bản sau: 1. Biện minh việc đệ trình kiến nghị 2. Mô tả vấn đề phải giải quyết 3. Mô tả giải pháp đề nghị 4. Mô tả tổ chức của ng•ời kiến nghị 5. Tổng quan chung về kinh phí của giải pháp đề nghị Phần biện minh là cốt tử vì nó giải thích vì sao khách hàng nên đọc tiếp. Phần này có thể nêu, chẳng hạn là ng•ời kiến nghị đã phát triển một công nghệ mới và thành công có lợi cho khách hàng và có thể thích nghi với nhu cầu của (tổ chức) khách hàng. Mục tiêu chính là cung cấp câu trả Quản lý dự án phần mềm 45 lời cho câu hỏi của khách hàng: “Vì sao công ty lại tiếp cận tôi và vì sao đọc kiến nghị này là lợi ích cho tôi vậy ?” Các phần 2 và 3, mô tả cách mà kiến thức chuyên môn hóa của ng•ời đề nghị đ•ợc vận dụng vào các vấn đề của tổ chức khách hàng. Điều này đòi hỏi ng•ời đề nghị nghiên cứu tổ chức của khách hàng nhằm đảm bảo là kiến nghị cung cấp một giải pháp thực cho một vấn đề thực. Chi phí chính xác của giải pháp không cần nêu ở giai đoạn này. Một kiến nghị không do yêu cầu hiến khi đ•ợc chấp nhận ngày vòng đầu. Mục tiêu chính của nó là tạo dựng một mối quan tâm. Nếu kiến nghị tạo đủ mối quan tâm thì ng•ời đề nghị sẽ đ•ợc mời thảo luận kiến nghị đó và sau đó sẽ đệ trình lại cho khách hàng một bản trình bày kiến nghị chi tiết hơn. 3.4.2. Đề xuất khi có yêu cầu Kiến nghị do yêu cầu mà khách hàng x•ớng xuất coi nh• đáp lại RFP chính thức hay một hình thức mời nào khác đệ trình kiến nghị. Trái với tính chất không chính thức của kiến nghị không do yêu cầu, kiến nghị do yêu cầu là hoàn chỉnh và chi tiết và nội dung th•ờng ràng buộc cho ng•ời đề nghị (kiến nghị coi nh• văn bản ràng buộc đ•ợc thảo luận thêm và minh họa ở lời nói đầu ch•ơng 10). Cùng với yêu cầu đệ trình kiến nghị, khách hàng cũng có thể dẫn chính xác kiến nghị phải đ•ợc chuẩn bị thể bào và đệ trình ra sao. Một thí dụ về dạng kiến nghị chính thức có ở bảng 3.2. Một lĩnh vực cơ bản khiến kiến nghị do yêu cầu và không do yêu cầu khác nhau là ở nhu cầu cạnh tranh. Các kiến nghị do yêu cầu phải có khả năng cạnh tranh thắng lợi với các kiến nghị khác. Điều này có nghĩa là việc chuẩn bị kiến nghị do yêu cầu phải đ•ợc coi bản thân nó là một dự án mini và nh• thế đòi hỏi hình thành một đội ngũ chuẩn bị kiến nghị. 3.4.3. Đội ngũ chuẩn bị đề xuất. Việc hình thành ban kiến nghị là cơ bản cho bất cứ tổ chức nào dự tính đáp ứng thành công một RFP. Ban này chỉ định ng•ời có nhiệm vụ định vị những RFP thích hợp và độ trình để thảo luận căn cứ đ•ờng lỗi chỉ đạo do ban đề ra. Đ•ờng lối chỉ đạo phải nhằm vào các RFP mà: - nằm trong phạm vi đ•ờng lỗi kinh doanh của công ty - nằm trong phạm vị giới hạn kích th•ớc đặc tr•ng (dự án không quá nhỏ và không quá lớn). - không hiển nhiên loại trừ chính công ty (thí dụ yêu cầu giám định đặc biệt hay hoàn thành về an ninh). Căn cứ ở đánh giá của ban về các RFP đek trình, ban kiến nghị quyết định RFP nào là đáp ứng đ•ợc bởi công ty. Sau đó ban kiến nghị lựa chọn đội ngũ chuẩn bị cho mỗi kiến nghị. Đội ngũ này có thể chỉ có một ng•ời hay nhiều thành viên, tùy thuộc ở qui mô của dự án kiến nghị. Đội ngũ rút từ kinh nghiệm và giám định của Quản lý dự án phần mềm 46 mọi nhân viên công ty và nếu cần có thể sử dụng dịch vụ của các chuyên gia bên ngoài hỗ trợ trong việc chuẩn bị kiến nghị. Kiến nghị cơ bản yêu cầu trong phạm vi đội ngũ chuẩn bị kiến nghị bao gồm: - Kiến thức kỹ thuật liên quan đến mỗi lĩnh vực riêng rẽ do kiến nghị l•u ý - Quản lý dự án kể cả dự toán và lập kế hoạch - Kiến thức tài chính, kể cả định ngân sách và lập kế hoạch tài chính cho toàn bộ dự án - Quen thuộc với tổ chức của khách hàng - Kinh nghiệm trong soạn thảo kiến nghị Một thành viên của đội ngũ sẽ đ•ợc ban chỉ định lãnh đạo đội hay điều phối viên. Sau khi đội ngũ đã hình thành, hai việc ủy thác đầu tiên của nó là: 1. Duyệt xét b•ớc đầu RFP 2. Chuẩn bị lịch trình cho việc hoàn thành dự án và giao trách nhiệm. Việc chuẩn bị kiến nghị tốt tốn tiền và phải đ•ợc coi nh• là một đầu t•. Nừu việc này làm tốt, nó có thể tạo ra lợi nhuận, ngân sách kiến nghị không thích hợp sẽ giảm cơ may tạo ra kiến nghị thắng đ•ợc các thành viên của đội ngũ chuẩn bị kiến nghị phải đ•ợc tập trung vào nhiệm vụ và họ phải đ•ợc cung cấp nguồn lực thích hợp. Theo Silver (1986), các kiến nghị trong công nghệ cao và các công nghiệp hành không vũ trụ đ•ợc cấp ngân sách khoảng 2% trị giá hợp đồng, dù sao, phạm vi chi phí. Kiến nghị là 1% đến 10%. Chi phí hợp đồng càng cao, phần trăm dành cho chuẩn bị kiến nghị càng thấp.6 3.4.4. Khuôn dạng đề xuất Kiến nghị tốt phải trả lời đ•ợc 6 câu hỏi cơ bản: ai, cái gì. tại sao, thế nào, khi nào, và bao nhiêu. Đáp án cho các câu hỏi đó đơn giản liên quan đến: 1. Ai là tổ chức đệ trình kiến nghị ? 2. Cái gì đ•ợc đề nghị ? 3. Tại sao kiến nghị đ•ợc đệ trình ? 4. Làm sao công việc kiến nghị đ•ợc thực hiện ? 5. Khi nào nó sẽ đ•ợc phát triển xong và bàn giao ? 6. Bao nhiêu chi phí ? 6 Silver đ•a ra, phạm vi hợp đồng dự án $10K đén $2B với phạm vi chi phí kiến nghị từ 1% đến 20% ở Hoa Kỳ và phạm vi hợp đồng $10K đến $1B với phạm vi chi phí kiến nghị 1% đến 10% ở Châu Âu. Căn cứ ở hầu hết các dự án khoảng $250K và $100, ông dựa ra phạm vi chi phí kiến nghị từ 1,5% đến 8% ở Hoa kỳ và 1% đến 2 1/2% ở châu Âu. Quản lý dự án phần mềm 47 Câu hỏi tại sao là quan trọng cho một kiến nghị không do yêu cầu và tạo cơ sở cho việc đệ trình nó. Đáp án cho một RFP chỉ cần khẳng định  Kiến nghị này đ•ợc đệ trình để phúc đáp yêu cầu đ•ợc kiến nghị cuả công ty Acme Inc số 456 ngày 5/6.... Năm câu hỏi khác đ•ợc nhằm vào 5 hợp phần chính của kiến nghị 1. Kiến nghị kỹ thuật (cái gì, làm sao) 2. Kiến nghị quản lý (làm sao, khi nào) 3. Kiến nghị định giá (bao nhiêu) 4. Tuyên bố công việc (cái gì, khi nào) 5. Tóm tắt điều hành và trong phần bổ sung bao gồm: - Nền tảng và kinh nghiệm của công ty (ai) - Trình độ chuyên môn của nhân sự chủ lực - Các chứng vật và văn bản thích hợp Bảng 3.2. Một khái lựợc cho một kiến nghị kỹ thuật 1. Tổng quan về vấn đề cần giải quyết 2. Tổng quan về giải pháp kiến nghị 3. Hợp phần cần mua 4. Hợp phần cần phát triển 5. Thiết b