CHƯƠNG 3. ƯỚC LƯỢNG DỰ ÁN PHẦN MỀM
3.2 Quy trình ƣớc lƣợng dự án dựa trên cấu trúc phân rã công việc 46
3.2.3 Ước lượng mỗi một hệ thống con
Với một thiết kế đã hoàn thành và được kiểm tra lại cho khớp với những yêu cầu, bây giờ chúng ta ở vị thế chuẩn bị cho một hội thảo ước lượng.
Thông thường, hội thảo sẽ có sự tham gia của những người mà đang tham gia vào việc ước lượng. Đối với dự án lớn, bạn có thể muốn chia những việc ước lượng đó trong một vài hội thảo.
Các cuộc hội thảo ước lượng nên chiếm từ một đến hai giờ đối với mỗi hệ thống con.
Việc hội thảo nên có một quy định đơn giản. Mỗi một hệ thống con trong một thời điểm hội thảo:
Chia việc cài đặt các hệ thống con thành các công việc (tasks).
Ước lượng thời gian phù hợp đối với mỗi công việc (task).
Gán mỗi một công việc cho một rủi ro kế hoạch gồm những giá trị như High (cao), Medium (bình thường), hoặc Low (thấp).
Tài liệu lại những kết quả được tạo ra.
Viết tài liệu ghi lại những dự án phụ thuộc bên ngoài.
Viết tài liệu ghi lại bất kỳ những rủi ro nào khác được xác định.
Ước lượng những hoạt động khác trong dự án.
Kiểm tra mỗi một hoạt động bằng cách thực hiện chi tiết hơn:
Chia việc cài đặt các hệ thống con thành các công việc.
Mỗi một công việc là một đơn vị logical cơ bản của công việc mà nó sẽ được hoàn thành bởi mỗi một cá nhân. Phân chia việc cài đặt những hệ thống con sẽ yêu cầu một số thiết kế ngay lập tức. Những công việc nên chiếm từ ba đến bẩy ngày và chúng bao gồm cả việc viết mã (coding) và đơn vị kiểm thử (unit testing).
Chúng ta nên có từ bốn đến mười hai công việc đối với mỗi hệ thống con.
1. Ước lượng thời gian phù hợp đối với mỗi công việc
Những người tham dự hội thảo sẽ đưa ra mất bao lâu để hoàn thành một công việc, dựa trên những kinh nghiệm cài đặt tương tự. Trong trường hợp không có kinh nghiệm, đánh dấu đậm dựa đoán và gán công việc với một rủi ro kế hoạch thuộc loại cao (High)- xem thêm đoạn dưới đây về định nghĩa của rủi ro kế hoạch.
Nếu người phát triển gặp vấn đề đối với khái niệm „phù hợp‟, cố gắng tương tự:‟ Nếu người ta gọi và nói „ Đến công ty ngay lập tức nếu cậu rảnh‟, bạn có thể nói: „Chắc chắn tôi sẽ đến trong vòng mười phút‟. Tất nhiên bạn có thể chỉ mất năm phút nếu bạn nghĩ bạn đang làm việc để kết thúc nhanh chóng công việc hơn bạn nghĩ. Hoặc là bạn có thể mất một giờ nếu bạn bị trật mắt cá chân ở hành lang. Mười phút là thời gian phù hợp, không có gì là quá tốt hoặc quá xấu.
Bạn nên quyết định rằng một công việc là ngắn hơn một ngày và nhiều hơn mười ngày. Và từ đó bạn nên gộp các công việc lại hoặc chia nhỏ chúng ra cho phù hợp với tiêu chí trên.
2. Gán mỗi một công việc cho một rủi ro kế hoạch gồm những giá trị như High (cao), Medium (bình thường), hoặc Low (thấp)
Có nhiều công việc vô cùng đơn giản, và đã được thực hiện nhiều lần trước đó, nên khi ước lượng những công việc này chúng ta cảm thấy rất tự tin thực hiện. Những công việc đó có một rủi ro lịch biểu thấp (Low schedule risk).
Những công việc khác thường không hoàn toàn biết rõ về số lượng hay khối lượng công việc, và những công việc đó có một rủi ro lịch biểu cao (High schedule risk).
Những phương pháp ước lượng này sử dụng ba loại của rủi ro lịch biểu được thể hiện như sau:
Loại Kế hoạch cho phép
Cao (High) 150%
Trung bình (Medium) 50%
Thấp (Low) 10%
Một công việc rủi ro cao có thể được ước lượng nhiều hơn 150%. Nói cách khác, không có người nào ngạc nhiên nếu một công việc rủi ro cao được ước lượng thích hợp khoảng 1 tuần, đến 2.5 tuần.
Tương tự là không quá 3.3 ngày đến 4 ngày cho các công việc rủi ro thấp.
Các công việc có rủi ro trung bình (Medium) không nên mất quá sáu ngày.
3. Viết tài liệu ghi lại những kết quả được tạo ra
Danh sách những kết quả được tạo ra trong những lần đọc hiểu yêu cầu.
Danh sách này nên được xây dựng dựa trên danh sách thiết kế ban đầu trong giai đoạn thiết kế.
Ví dụ, có thể yêu cầu về độ phân giải màn hình mà hệ thống hỗ trợ không được đưa ra rõ ràng nên kết quả sẽ được tạo ra là:‟ Máy trạm làm việc sẽ có độ phân giải màn hình ít nhất là 800x600‟.
4. Tài liệu lại những dự án phụ thuộc bên ngoài
Danh sách những đầu ra từ những dự án khác hoặc những nhóm khác mà dự án phụ thuộc vào.
Ví dụ, nếu cài đặt một lược đồ cơ sở dữ liệu sẽ yêu cầu sự chấp thuận từ những nhóm quản trị cơ sở dữ liệu, để viết xuống. Đó là một nhắc nhở đối với người quản trị dự án rằng họ sẽ cần bảo mật việc hợp tác giữa các nhóm.
Một ví dụ khác của việc phụ thuộc là nơi dự án được ước lượng mà họ sẽ sử dụng một thành phần từ dự án khác mà chưa hoàn thành.
Nó thường có ích đối với hội thảo hội thảo để ước lượng thay đổi mà không phù hợp và cần viết tài liệu sự ảnhhưởng của việc phụ thuộc là không phù hợp. Ví dụ, nếu một dự án khác không đưa ra những thành phần yêu cầu để hoàn thành tốt đẹp, phải làm thêm như thế nào để tránh gây ra thất bại.
5. Tài liệu lại những dự án phụ thuộc bên ngoài
Danh sách bất kỳ những nhân tố nào khác có thể gây ảnh hưởng tới dự án.
Một ví dụ là có thể là những thiết bị kiểm thử mà có thể không đáp ứng đầy đủ.
Thêm nữa nó sẽ giúp hội thảo để ước lượng những thay đổi mà rủi ro thậm chí xảy ra và viết tài liệu những ảnh hưởng đến dự án.
Không tài liệu những rủi ro mà đã được bao gồm trong kế hoạch rủi ro, giống như việc gấp đôi rủi ro lên.
6. Ước lượng những hoạt động khác trong dự án Việc hội thảo cần ước lượng:
Những yêu cầu thời gian thiết kế thêm vào- đốivới hệ thống và đối với những hệ thống con hoặc những thành phần riêng biệt.
Thời gian làm mẫu đầu tiên. Thời gian làm mẫu đầu tiên thường có tác dụng giảm tổng số rủi ro kế hoạch đối với những công việc rủi ro cao được thực hiện trong một thời gian dài.
Kiểm thử tích hợp, kiểm thử hệ thống và kiểm thử nghiệm thu. Thông thường việc kiểm thử chiếm từ 20 đến 30% thời gian ước lượng cài đặt.
Thời gian cài đặt, thông thường nếu thiết bị mới hoặc phần mềm phát triển sẽ sử dụng. Nó bao gồm việc cài đặt và cấu hình cơ bản.
Duy trì môi trường phát triển. Quản lý cấu hình và và xây dựng hệ thống quản trị cùng trong loại này. Thông thường cho phép 10% thời gian ước lượng cài đặt.
Thời gian phát hành/triển khai. Mỗi một phiên bản phát hành tới khách hàng cần có thời gian. Nếu không chắc chắn, ước lượng một tuần với những nhóm khác đó mỗi phát hành bao gồm kiểm thử tích hợp, sửa lỗi và xây dựng.
Đối với các hội thảo để chắc chắn rằng nó tập trung vào công việc thực hiện ước lượng chính xác:
Bắt đầu, một vài người phát triển có thể thận trọng chấp nhận bất kỳ một loại ước lượng nào. Những nhà phát triển khác có thể lạc quan với những ước lượng. Hướng dẫn hội thảo trong những giai đoạn ban đầu. Nhấn mạnh rằng chỉ có ước lượng với những rủi ro, kết quả thu được, và sự phụ thuộc mang đến những tài khoản hoặc những dự án sẽ chạy thông qua những ước lượng thích hợp nhất.
Thảo luận thiết kế chi tiết không được phép trừ khi nó nhanh chóng được giải quyết và đặc biệt ảnh hưởng tới ước lượng cuối cùng. Khi nào một thảo luận thiết kế bắt đầu, những người tham dự tự tin để tạo chú ý.
Chắc chắn rằng những công việc rủi ro cao là cách ly trong nó, ngăn cách từ những công việc rủi ro thấp.
Trong hoàn cảnh một vài lựa chọn thiết kế được trình bày trong hội thảo, chọn lựa chọn với tổng thời gian ít nhất để cài đặt, bao gồm rủi ro cho phép, và tiếp tục như thế.
Nếu có một thảo luận về ý nghĩa của một yêu cầu, tài liệu một kết quả thu được về ý nghĩa và tiếp tục.
Nếu bây giờ và sau đó có sự không thật đồng ý giữa đồng nghiệp về những thứ được thực hiện như thế nào. Trong trường hợp, mỗi phần mâu thuẫn để ước lượng bằng cách này, mang ước lượng với thời gian dài nhất để cài đặt, bao gồm rủi ro, và tiếp tục.
Đối chiếu đầu ra của hội thảo. Tạo một bảng tính mà bao gồm một dòng đối với mỗi công việc: Tên công việc, giống như ước lượng, rủi ro kế hoạch được gán và tính tổng.
Những số liệu, thêm sự cho phép đối với rủi ro và những sự phụ thuộc bên ngoài được xác định. Xác định những rủi ro thu được là có liên quan nhỏ và độc lập với những thứ khác, tính toán sự cho phép bởi nhân phần trăm thay đổi xảy ra bằng giá để sửa nó.
Những rủi ro lớn hơn- mà có thể làm cho dự án dừng lại trong kế hoạch dự án. Rủi ro đấy là sự không lệ thuộc vào những thứ mà thường xảy ra đồng thời nếu chúng xảy ra sẽ cùng tập trung lại trong những lỗi lớn hơn.
Cuối cùng thêm một khoảng thời gian đối với quản lý dự án. Nó sẽ mất khoảng 10% của thời gian phát triển, phụ thuộc vào tất cả rủi ro dự án. Bao gồm sự cho phép đối với thay đổi quản lý và thương thảo hợp đồng. Nếu thời gian ước lượng là quản lý sự dư thừa số thời gian quản lý dự án sẽ có khả năng, xem xét để hỏi đối với những nguồn lực mở rộng giống như trợ lý quản trị dự án hoặc một người quản lý khách hàng toàn thời gian.