- ước lượng thời gian khó hơn xây dựng bảng công việc.
- Nguyên tắc: ước lượng thời gian cho mỗi công việc nhỏ, từ đó có cơ sở để ước lượng toàn bộ thời gian cho dự án (Bottom-up)
- ước lượng thời gian sẽ là cơ sở để đánh giá tiến độ của quá trình thực hiện dự án.
- Trong khi ước lượng thời gian, xác định luôn công việc nào quan trọng hơn công việc nào, công việc nào phải làm trước công việc nào => là cơ sở để xây dựng lịch biểu thực hiện dự án
Các kỹ thuật làm ước lượng thời gian
Ước lượng phi khoa học
- Dựa trên kinh nghiệm chủ quan, cảm tính
- Nhanh và dễ dùng,
- Kết quả thiếu tin cậy.
Chỉ nên dùng trong các trường hợp
- Đội ngũ chuyên môn rất có kinh nghiệm, có kĩ năng cao, đội hình cố định
- Dự án đã quy định, bắt buộc phải theo
Ước lượng PERT
Thích hợp đối với những dự án
- đòi hỏi tính sáng tạo
- coi trọng chất lượng kết quả công việc hơn là thời gian hoàn thành dự án
Công thức PERT
- Cần làm ba ước lượng thời gian cho mỗi công việc
- Kết hợp lại để có con số cuối cùng.
- Ước lượng khả dĩ nhất (ML-Most Likely): thời gian cần để hoàn thành công việc trong điều kiện "bình thường" hay "hợp lí".
- Ước lượng lạc quan nhất (MO-Most Optimistic): thời gian cần để hoàn thành công việc trong điều kiện "tốt nhất" hay "lí tưởng" (không có trở ngại nào)
- Ước lượng bi quan nhất (MP-Most Pessimistic): thời gian cần để hoàn thành công việc một cách "tồi nhất" (đầy trở ngại)
Ước lượng cuối cùng tính theo công thức:
(MO + 4(ML) + MP)/6
- Ví dụ: các công việc liên quan đến lắp mạng nội bộ cho cơ quan
(EST: estimation - ước lượng thời gian để làm dự án)
Đơn vị tính: ngày
| Tên công việc | MO | ML | MP | EST |
| Vẽ sơ đồ và khoan tường | 2 | 3 | 5 | 3.2 |
| Lắp các ống gen | 1 | 2 | 4 | 2.2 |
| Đi dây | 1 | 2 | 4 | 2.2 |
| Lắp các hộp nối | 0.5 | 1 | 2 | 1 |
| Lắp các máy tính, máy chủ, Hub | 2 | 3 | 3 | 2.8 |
| Kết nối các máy tính, máy chủ vào hệ thống dây mạng | 1 | 2 | 4 | 2.2 |
| Thử xem mạng đã thông chưa | 0.5 | 1 | 10 | 2.4 |
| Tổng thời gian | 8 | 14 | 32 | 16 |
Sau đó, tăng thêm "một ít thời gian" cho mỗi công việc (thời gian tiêu phí giữa chừng). Thông thường tăng thêm 7% - 10%
| Tên công việc | EST | % | EST cuối cùng |
| Vẽ sơ đồ và khoan tường | 3.2 | 10% | 3.52 |
| Lắp các ống gen | 2.2 | 10% | 2.42 |
| Đi dây | 2.2 | 10% | 2.42 |
| Lắp các hộp nối | 1 | 10% | 1.1 |
| Lắp các máy tính, máy chủ, Hub | 2.8 | 10% | 3.08 |
| Kết nối các máy tính, máy chủ vào hệ thống dây mạng | 2.2 | 10% | 2.42 |
| Thử xem mạng đã thông chưa | 2.4 | 10% | 2.64 |
| Tổng thời gian | 16 | 10% | 17.6 |
Ưu điểm của PERT
- Buộc phải tính đến rất nhiều yếu tố (nếu muốn có được MO, MP).
- Buộc Người quản lý dự án phải trao đổi với nhiều người (đạt được sự đồng thuận)
- Giá trị nhận được là giá trị cân bằng giữa 2 thái cực => có ý nghĩa và đáng tin cậy
- Làm cho việc lập kế hoạch trở nên chi tiết hơn. Nếu gặp một ước lượng là quá lớn (vượt quá 2 tuần hoặc 80 giờ) => phải phân rã công việc
Nhược điểm của PERT
- Mất thời gian (của 1 người và của cả tập thể), khi dự án có quá nhiều công việc. (Tuy nhiên: Thà mất thời gian ban đầu còn hơn mất thời gian sau này)
- Có thể xảy ra: tranh luận hàng giờ về giá trị bi quan nhất cho công việc => có nguy cơ làm cho mọi người chán nản. (Tuy nhiên: cần phải xem lại những người tỏ ra chán nản: trình độ chuyên môn, tinh thần vượt khó, ...)
- Có thể dẫn đến những tíng toán rất vụn vặt => làm cho Người quản lý dự án chỉ "thấy cây mà không thấy rừng". (Tuy nhiên: có thể dùng EXCEL để trợ giúp)
Năng suất toàn cục
Giả thiết lý tưởng rằng mọi thứ đều hoàn hảo 100%
Xây dựng bảng "khiếm khuyết" đối với công việc. Khiếm khuyết là những điểm có thể ảnh hưởng xấu đến tiến độ công việc. Ví dụ:
| Khiếm khuyết | Phần trăm |
| Tinh thần thấp | 15% |
| Kĩ năng chưa cao | 5% |
| Chưa quen làm trong dự án | 10% |
| Trang thiết bị không tốt | 5% |
| Mô tả công việc mơ hồ | 10% |
| Tổng cộng | 45% |
Năng suất toàn cục
100% + 45% = 145%
Từ đó suy ra thời gian ước tính để thực hiện công việc (quy tắc tam suất). Cụ thể:
Thời gian lý tưởng T giờ 100%
Thời gian ước lượng x giờ 145%
x = T x 145% (giờ)
Nhận xét:
- Rất đơn giản, mang tính chủ quan
- Nhanh. Khi điều chỉnh bảng "khiếm khuyết" => dễ dàng tính lại thời gian.
- Thuận tiện => hay được dùng
- Nghi ngờ về tính chính xác????
Các bước khi làm ước lượng
- Khẳng định Bảng Công Việc (BCV) là tốt
- Liệt kê các công việc trong BCV, viết trong bảng ước lượng, có dạng
| Số hiệu | Mô tả công việc | Giờ | Ngày |
| 1.2.1 | ........ | .... | .... |
- Xác định những người cần trao đổi khi làm ước lượng (đối với từng công việc)
- Họp riêng từng người
- Thực hiện tính toán
- Họp cả nhóm để thống nhất chung, có thể chỉnh sửa lại số liệu. Ghi lại biên bản và lấy chữ ký
7. Phân phát biên bản cuối cùng cho mọi người.
Những điểm cần lưu ý
- Những trở ngại gặp phải khi ước lượng, khiến cho ước lượng là không chính xác
- Thiếu thông tin, thiếu tri thức. Ví dụ: một công việc chuyên môn do những chuyên gia kỹ thuật cao đảm nhiệm, làm thế nào để biết được họ thực hiện trong bao nhiêu ngày?
- Không lường trước được những phức tạp kỹ thuật
- Không lường trước được sự hoà thuận hay bất hòa của những thành viên khi thực hiện dự án
- Sau khi đưa ra một ước lượng thời gian rồi, ước lượng đó có thể bị những ý kiến khác góp ý: cố tình thu ngắn lại hoặc dãn dài ra. => lấy ý kiến tư vấn
- Sức ép của cấp trên: thường muốn thu ngắn thời gian thực hiện công việc.
- Thiếu thời gian để cân nhắc, tính toán. Thiếu thời gian để gặp gỡ, trao đổi với các thành viên dự án, với khách hàng.
- Hạn hẹp về kinh phí => không cho phép dự kiến thời gian dôi dư thoả đáng.
- Những khó khăn trong hợp tác khi xây dựng ước lượng thời gian: những người khác (khách hàng, thành viên dự án) không cung cấp đủ (hoặc che dấu) thông tin.
- Phát biểu không rõ ràng về mục đích, mục tiêu của dự án và kết quả (sản phẩm) dự án. những ước lượng về thời gian đều chỉ là cảm tính mà không dựa trên những căn cứ chính xác.
- Bảng Công Việc được xây dựng không tốt
- Trước khi ước lượng thời gian cho công việc, nên xem lại xem BCV đã viết đủ rõ ràng, đủ chi tiết chưa.
- Với các công việc gần giống nhau => ước lượng thời gian cũng gần giống nhau, không quá chênh lệch.
- Không bao giờ có được ước lượng chính xác hoàn toàn. Cố gắng sao cho có được ước lượng hợp lý.
- Việc ước lượng mang tính chủ quan. Do đó nếu có thể kết hợp được với những ý kiến đánh giá độc lập của người khác để chỉnh lại ước lượng cho mình. Tuy nhiên, những ý kiến của người khác chỉ để tham khảo, không nên chấp nhận một cách vội vã.
- Hãy viết tài liệu khi ước lượng. Tài liệu này là cơ sở để trao đổi với mọi người, đồng thời cũng mang tính chất một bản cam kết (về tâm lý) của những người sau này sẽ tham gia công việc.
- Khi ước lượng thời gian quá cao
- Kiểm chứng lại để khẳng định tính hợp lý của ước lượng (có ước lượng nào bị thổi phồng?)
- So sánh với những dự án tương tự đã làm
- Có thể thu hẹp phạm vi công việc
- Tìm cách tiết kiệm thời gian (dùng lại nhưng kết quả đã có trước đây, ...)
- Giảm chất lượng sản phẩm (!!!)
- Có gắng tuyển chọn những nhân viên kỹ thuật có trình độ cao hơn (chi phí lại cao hơn!!!)
- Đề nghị cung cấp thiết bị tốt, mới (tuy nhiên: nhân tố quyết định vẫn là con người!!!)
- Khi ước lượng quá thấp
- Kiểm chứng lại để khẳng định tính hợp lý của ước lượng (có ước lượng nào bị ép xuống?)
- Tăng lên một chút (nhân thêm 1 tỷ lệ %), bù đắp cho tính "lạc quan" trong khi ước lượng
- Thách thức những người tham gia công việc: bắt ký cam kết !!!
Một số hướng dẫn trợ giúp ước lượng thời gian cho dự án CNTT
- Chi phí thời gian của lập trình viên
- (Điều tra của Bell Labs)
| Viết chương trình | 13% |
| Đọc tài liệu hướng dẫn | 16% |
| Thông báo, trao đổi công việc, viết báo cáo | 32% |
| Việc riêng | 13% |
| Việc linh tinh khác | 15% |
| Huấn luyện | 6% |
| Gửi mail, chat | 5% |
- (điều tra của IBM)
| Làm việc một mình | 30% |
| Trao đổi công việc | 50% |
| Làm những công việc khác, không phục vụ trực tiếp cho công việc | 20% |
- Sơ đồ chung
Giải thích sơ đồ: Ví dụ
+ Mặc dù việc phân tích yêu cầu là chính yếu trong giai đoạn phân tích yêu cầu, nhưng những công việc này vẫn còn tiếp diễn trong các giai đoạn sau, với mức độ ít hơn
+ Khi kết thúc giai đoạn cài đặt, khoảng
46% thành viên tham gia khâu kiểm thử hệ thống
15% chuẩn bị cho kiểm thử nghiệm thu
7% theo dõi và đáp ứng các thay đổi của yêu cầu
12% phải thiết kế các thay đổi
20% viết lệnh mới, sửa lệnh cũ, và tích hợp các sửa đổi vào phần mềm
- Ước tính sự tăng trưởng của mã nguồn
- Sự tập trung nỗ lực của các thành viên
Khó khăn trong việc ước lượng thời gian làm phần mềm:
- Phần mềm chưa làm bao giờ (khác với những dự án kỹ thuật khác)
- Khó dùng lại những kinh nghiệm của các dự án trước đây
- Công nghệ thay đổi
- Khó phân ranh giới rõ ràng giữa các giai đoạn. Ví dụ
Kiểm thử có bao gồm việc "bắt rận" (debug) hay không?
Thiết kế có bao gồm việc vẽ sơ đồ cấu trúc chương trình không?
- Công sức và thời gian còn phụ thuộc vào một vài yếu tố khác
| Loại dự án | Môi trường áp dụng | Hệ số nhân dự phòng |
| Cũ | Cũ | 1 |
| Cũ | Mới | 1.4 |
| Mới | Cũ | 1.4 |
| Mới | Mới | 2 |
+ Loại dự án là cũ nếu đã có hơn 2 năm kinh nghiệm
+ Môi trường áp dụng là cũ nếu đã có hơn 2 năm kinh nghiệm
- Công sức và thời gian còn phụ thuộc vào tay nghề của nhóm phát triển (nhóm lập trình)
| Số năm kinh nghiệm | Hệ số nhân |
| 10 | 0.5 |
| 8 | 0.6 |
| 6 | 0.8 |
| 4 | 1 |
| 2 | 1.4 |
| 1 | 2.6 |
- Một số phương cách ước lượng
+ Hỏi ý kiến chuyên gia
+ So với những dự án tương tự đã làm để có số liệu so sánh. Tuy nhiên điều này không phải bao giờ cũng cho kết quả tốt.
Ví dụ về một cơ quan đã làm nhiều dự án phần mềm
(B.A. Kitchenham and N.R. Taylor, Software Project Development, Journal of Systems and Software, 5/1985)
| Thiết kế (%) | Lập trình (%) | Kiểm thử (%) | Người*tháng | SLOC | |
| Dự án 1 | 23 | 32 | 45 | 17 | 6050 |
| Dự án 2 | 12 | 59 | 26 | 23 | 8300 |
| Dự án 3 | 11 | 83 | 6 | 32 | 13300 |
| Dự án 4 | 21 | 62 | 18 | 4 | 5900 |
| Dự án 5 | 10 | 44 | 45 | 17 | 3300 |
| Dự án 6 | 28 | 44 | 28 | 68 | 38990 |
| Dự án 7 | 21 | 74 | 5 | 10 | 38600 |
| Dự án 8 | 7 | 66 | 27 | 19 | 12760 |
| Dự án 9 | 14 | 38 | 47 | 60 | 26500 |
Từ bảng trên không thể rút ra quy luật gì !!!
