Quản lý dự án IT - Chương 4: Ước lượng cho dự án

• Chương 4: Ước lượng cho dự án 4. Ước lượng cho dự án • Các ước lượng cần thiết cho dự án: – Nguồn tài nguyên – Thời gian – Chi phí/ngân sách • Gia ́ trị ước lượng phụ thuộc: – Bản chất công việc – Nguồn tài nguyên phân bổ cho công việc – Sự hỗ trợ: Các công cụ thực hiện, sự động viên, sự phối hợp, đào tạo, môi trường làm việc Nguồn tài nguyên Thời gian Chi phí/ngân sách 4. Ước lượng cho dự án • Thực hiện ước lượng theo 2 phương pháp khác nhau và lấy trị trung bình của 2 phương pháp • Ước lượng là một khoa học va ̀ cũng là một sự dự đoán 4. Ước lượng cho dự án • Công cụ & kỹ thuật ước tính: – Ước lượng tương tự (Analogous estimate – Top down estimate) • Dựa trên gia ́ trị thực của các dự án khác tương tự • Dự án càng phức tạp, cấu trúc không ro ̃ càng cần nhiều thời gian, nguồn tài nguyên, chi phí thực hiện • Độ tin cậy thấp – Ước lượng theo phương pháp Delphi – Khống chê ́ khung thời gian (time boxing) • Khống chê ́ khung thời gian cho mỗi hoạt động àTạo áp lực công việc lên đội dự án àChất lượng/đô ̣ hoàn thiện của dự án có thê ̉ bị ảnh hưởng àChỉ nên dùng trong một sô ́ ít trường hợp đặc biệt 4. Ước lượng cho dự án • Công cụ & kỹ thuật ước tính: – Ước lượng từ trên xuống (top down estimate) • Khống chê ́ thời gian hoàn thành toàn dự án (dựa theo các dự án tương tự đã thực hiện) • Phân chia khung thời gian cho các giai đoạn dự án • Phân chia thời gian cho các hoạt động – Ước lượng từ dưới lên (Bottom up estimate) • Ước lượng cho các công việc cụ thể và cộng lại để tạo ước lượng chung cho dự án • Cấu trúc phân việc WBS thường được sử dụng • Người được phân công chịu trách nhiệm từng công việc sẽ thực hiện sự ước lượng này 4. Ước lượng cho dự án • Công cụ & kỹ thuật ước tính: – Mô hình thông số: • Sử dụng các đặc trưng của dự án để xây dựng một mô hình toán • Dựa vào các dữ liệu của các dự án trong quá khứ để thiết lập các ước lượng cho các đặc trưng của mô hình • Các đặc trưng của dự án: – Quy mô (số người sử dụng, dung lượng thông tin) – Ngôn ngữ lập trình – Cấu trúc mạng – Số trạm làm việc – 4. Ước lượng cho dự án Ví du ̣ vê ̀ ước lượng cho phân bô ̉ nguồn tài nguyên & chi phí Mã số nguồn tài nguyên Tên nguồn tài nguyên Thời lượng sẳn sàng (giờ) Số giờ Chi phí Số giờ Chi phí Số giờ Chi phí Thời gian Chi phí SA1 Kỹ sư phân tích hệ thống 1 800 19.5 $819,000 37.5 $1,575,000 60 $2,520,000 117 $4,914,000 SA2 Kỹ sư phân tích hệ thống 2 300 13 $728,000 60 $3,360,000 45 $2,520,000 118 $6,608,000 SD Kỹ sư thiết kế hệ thống 240 31.2 $1,747,200 75 $4,200,000 105 $5,880,000 211 $11,827,200 . . . Cộng $3,294,200 $9,135,000 $10,920,000 446 $23,349,200 Mã số công việc Tên công việc SA1 SA2 SD SA1 SA2 SD 1.1.1 Phân tích yêu cầu 15 10 24 19.5 13 31.2 1.1.2 Phân tích chức năng 25 40 50 37.5 60 75 1.1.3 Tích hợp hệ thống 40 30 70 60 45 105 Chi phí đơn vị cho các nguồn lực Tên nguồn lực Đơn giá tham khảo (Đồng/giờ) Đơn giá ước tính (Đồng/giờ) Kỹ sư phân tích hệ thống 1 30000 42000 Kỹ sư phân tích hệ thống 2 40000 56000 Kỹ sư thiết kế hệ thống 40000 56000 Phân bổ tài nguyên (tham khảo) (giờ) Ước tính phân bổ tài nguyên (giờ) Phân bổ nguồn tài nguyên và chi phí Cộng 1.1.1 1.1.2 1.1.3 4. Ước lượng cho dự án • Phương pháp mô hình thông số • Ước lượng theo phương pháp trung bình có trọng số • Ước lượng theo phương pháp hồi quy tuyến tính 4. Ước lượng cho dự án • Phương pháp phân tích điểm chức năng (Function Point Analysis) • Mục tiêu: – Đo lường điểm chức năng mà người dùng yêu cầu hay nhận được được – Đo lường sự phát triển và bảo trì phần mềm một cách độc lập với công nghệ sử dụng để làm phần mềm – Đo lường phần mềm bằng cách định lượng các chức năng mà phần mềm cung cấp cho người dùng được dựa chủ yếu trên thiết kế logic 4. Ước lượng cho dự án • Điểm chức năng – Là một số đo đại diện cho kích thước (size) chức năng của một phần mềm áp dụng. – Là một số đo chuẩn hóa để mô tả một đơn vị sản phẩm (unit of work product) thích hợp đê ̉ lượng hóa phần mềm dựa trên những điều mà người dùng yêu cầu hay nhận được • Phân tích điểm chức năng (Functional Point Analysis – FPA): – Là một phương pháp chuẩn hóa đê ̉ đo lường sự phát triển và bảo trì phần mềm dựa trên góc nhìn của khách hàng • Đếm điểm chức năng (Functional Point Count – FPC) – Đo lường điểm chức năng của một ứng dụng hay dự án cụ thể 4. Ước lượng cho dự án Không áp dụng FPA Áp dụng FPA Đúng tiến đô ̣ Trê ̉ tiến đô ̣ Bị hủy bo ̉ 4. Ước lượng cho dự án • Lợi ích của phân tích điểm chức năng – Tạo một phương pháp luận nhất quán, có thể ghi thành tài liệu, có thể lặp lại phép đo – Liên hê ̣ trực tiếp đến các chức năng va ̀ yêu cầu của hê ̣ thống nên người dùng có thể hiểu được • Tạo truyền thông giữa người dùng va ̀ người phát triển phần mềm • Hô ̃ trợ việc phân tích các yêu cầu • Áp dụng ngay từ giai đoạn phân tích yêu cầu xuyên suốt đến hết chu kỳ dự án – Không phu ̣ thuộc công nghê ̣, platforms và ngôn ngữ – Ưu thế nhiều hơn so với phương pháp đếm sô ́ dòng lệnh – Cung cấp số đo định lượng cho việc quản lý gia ́ trị nhận được (Earned value management) 4. Ước lượng cho dự án • 5 chức năng cơ bản: – Data functions – Internal Logical Files (ILFs) – Data functions – External Logical Files (ELFs) – Transaction functions – External Inputs (EIs) – Transaction functions – External Outputs (EOs) – Transaction functions – External Inquires (EQs) 4. Ước lượng cho dự án • Trọng số cho các chức năng CaoTrung bình Thấp 15107ILF 1075ELF 653EQ 754EO 643EI Mức độ phức tạpCác chức năng 4. Ước lượng cho dự án • Ví dụ: Một công ty bán hàng qua điện thoại – Xây dựng hệ thống quản lý hoạt động kinh doanh này. – Mức độ phức tạp của hệ thống? – Thời gian phát triển hê ̣ thống? 4. Ước lượng cho dự án • Các chức năng chính: – External Inputs (EIs): Khách hàng, đơn hàng, tồn kho, chi tiết thanh toán – External Outputs (EOs): Khách hàng, đơn hàng, chi tiết tồn kho, mức tín dụng – External Inquiries (EQs): Ai là khách hàng? Đơn hàng? Chi tiết tồn kho? – External Logical Files (ELFs): không có – Internal Logical Files (ILFs): Hồ sơ (file) Khách hàng và hàng hóa, khách hàng và giao dịch 4. Ước lượng cho dự án 65Cộng 2874ILF 933EQ 1644EO 1234EI Điểm chức năng Trọng sốSố lượngChức năng 4. Ước lượng cho dự án • Từ các dự án trước: – Mỗi một điểm chức năng cần 5 giờ để được phát triển – Chi phí để phát triển một điểm chức năng là $4.000 – Thời gian để phát triển phần mềm là: • 5 giờ/điểm x 65điểm = 325 giờ – Chi phí để phát triển phần mềm là: • $4000/điểm x 65điểm = $260.000 4. Ước lượng cho dự án • Ước lượng ngân sách: – Ước lượng quy mô tài chánh của dự án: • Được làm từ đầu để lựa chọn dự án • Khoảng 2-3 năm trước hoàn tất dự án • Sai số -50% đến +100% – Ước lượng ngân sách: • Dùng để định vị nguồn tiền trong ngân sách doanh nghiệp • Khoảng 2 năm về hướng tương lai • Sai số - 10% đến +25% – Ước lượng định nghĩa (Definitive estimates) • Dùng để ước tính chi phí dự án trong việc mua sắm • Thường khoảng 1 năm trước khi hoàn tất dự án • Sai số -5% đến +10% 4. Ước lượng cho dự án • Kế hoạch quản lý chi phí: – Là một tài liệu mô tả phương cách dự án sẽ xử lý các biến thiên về mặt chi phí thực hiện dự án 4. Ước lượng cho dự án • Một số chi phí dùng ước tính ngân sách dự án • Chi phí lao động: – Tính cho từng loại chuyên viên và lấy tổng – Đơn giá lao động x thời gian • Chi phí phần cứng – Các máy trạm – Server – Truyền thông trong nội bộ mạng • Chi phí phần mềm – Chi phí cho quyền sử dụng phần mềm – Chi phí cho việc phát triển phần mềm • Chi phí thử nghiệm • Chi phí đào tạo và hỗ trợ • Chi phí dự phòng (khoảng 20% tổng ngân sách dự án) 4. Ước lượng cho dự án Ví dụ về ước lượng ngân sách cho một dự án IT 4. Ước lượng cho dự án • Dòng ngân lưu cho dự án được thiết lập dựa trên: – Kế hoạch triển khai dự án – Ngân sách của dự án • Được chi tiết hóa thành từng tháng 4. Ước lượng cho dự án Dòng ngân lưu cho dự án 4. Ước lượng cho dự án • Một số yếu tố ảnh hưởng đến việc ước lượng – Thời gian dành cho việc ước lượng – Kinh nghiệm ước lượng – Sự chủ quan của người lập ước lượngà Bỏ qua một số chi phíà Cần phải thảo luận nội bộ về các ước lượng – Việc quản lý đặt ra các giá trị cho các ước lượng 4. Ước lượng cho dự án • Một số yếu tố ảnh hưởng đến việc ước lượng – Các phương pháp/kỹ thuật ước lượng chưa phát triển – Có sự nhầm lẫn giữa nỗ lực và tiến độà lầm lẫn giữa man – month – Nhà quản lý dự án ít dành thời gian cho việc ước lượng – Tiến độ triển khai không được quan trắc chặt chẽ – Sự trễ tiến độ thường được giải quyết bởi việc tăng nhân lựcàVấn đề càng trở nên rối rắm và trễ nhiều hơn Fredrick P. Brooks – Manager of OS/360 Operating System at IBM