CHƢƠNG 3 ƢỚC LƢỢNG DỰ ÁN PHẦN MỀM
3.1 Quy trình ƣớc lƣợng dự án phần mềm
Sau đây là quy trình ước lượng dự án phần mềm:
Ước lượng cỡ sản phẩm Tập hợp yêu cầu
Ước lượng Effort
Đưa ra Schedule
Phê duyệt ước lượng Ước lượng dự toán
Phát triển sản phẩm
Dữ liệu quá khứ
Nguồn lực có khả năng
Cỡ, effort, schedule thật
Ước lượng được phê duyệt
Phân tích quá trình ước lượng Dự toán hiện tại
Ước lượng Lại nếu cần
Từ quy trình ước lượng dự án trên chúng ta thấy có bốn bước cơ bản trong việc ước lượng dự án phần mềm là :
Ước lượng cỡ của sản phẩm phát triển. Thông thường là bằng tổng số lượng dòng lệnh (Lines of Code-LOC) hoặc là những điểm chức năng
Hình 3.1.1: Quy trình ước lượng dự án phần mềm
43
(Function Points- FP), hoặc có những đơn vi khác được dùng để đo lường như điểm trường hợp sử dụng (Use Case Point-UCP).
Ước lượng thời gian để hoàn thành dự án dùng đơn vị người-tháng (man- months, person-months) hoặc người-giờ (man-hours, person-hours).
Ước lượng kế hoạch công việc theo thời gian. Ước lượng dự toán dự án.
3.1.1 Ƣớc lƣợng cỡ dự án phần mềm
Để bắt đầu quá trình ước lượng, chúng ta thực hiện một ước lượng sơ lược về cỡ dự án phần mềm. Những nguồn thông tin thu thập được về phạm vi của dự án, những mô tả về những yêu cầu- ví dụ, một đặc tả yêu cầu khách hàng, hoặc yêu cầu đối với kế hoạch dự kiến, một đặc tả hệ thống, một đặc tả yêu cầu phần mềm (software requirements specification- SRS). Nếu chúng ta đang ước lượng lại một dự án trong một giai đoạn sau của vòng đời dự án, tài liệu thiết kế có thể được sử dụng để tham khảo. Không nên chỉ nhìn dự án ở mức tài liệu đặc tả và kết thúc việc tìm thêm thông tin để ước lượng dự án. Một mô tả bằng lời hoặc bằng một bảng thông tin bên ngoài đôi khi có thể giúp chúng ta bắt đầu việc ước lượng. Trong bất kỳ trường hợp nào, chúng ta phải chấp nhận rủi ro và không chắc chắn theo cấp độ rằng: tất cả mọi thứ đều được xem xét và chúng ta phải ước lượng lại dự án ngay khi có thêm nhiều thông tin hơn về dự án được đưa ra.
Có hai cách có thể sử dụng để ước lượng cỡ của sản phẩm là :
Bằng cách tương tự. Đã có một số dự án tương tự trong quá khứ và đã biết trước được cỡ của nó, bạn ước mỗi phần của dự án mới giống như % của cỡ tương tự như những phần có trong dự án cũ. Ước lượng tổng của dự án mới bằng cách thêm đến khi ước lượng hết các thành phần trong dự án. Một kinh nghiệm mà người ước lượng có thể đưa ra khả năng ước lượng cỡ tốt nhất bằng cách tương tự nếu giá trị cỡ thực sự là có khả năng đối với những dự án đã có và nếu dự án mới đủ giống dự án trước đó.
Bằng cách đếm những đặc trưng chức năng và sử dụng một cách tiếp cận thuật toán giống như điểm chức năng (FP) để biến đổi việc đếm các chức năng thành một việc ước lượng kích cỡ của dự án. Những đặc trưng chức năng có thể bao gồm số lượng của hệ thống con (subsystems), những lớp/môđun (classess/modules), phương thức/ hàm (methods/functions). Những đặc trưng sản phẩm có thể bao gồm số lượng màn hình, hộp thoại
44
(dialogs), tệp, bảng cở sở dữ liệu (database tables), báo cáo (reports), thông điệp (messages), và một số thứ khác.
3.1.2 Ƣớc lƣợng khối lƣợng công việc
Một khi chúng ta đã có ước lượng về cỡ của sản phẩm, chúng ta có thể đưa ra ước lượng khối lượng công việc. Có một số quy ước để chuyển từ cỡ DAPM tới effort, và có thể áp dụng được nếu chúng ta có một định nghĩa về vòng đời phát triển phần mềm và quy trình phát triển mà trong đó chúng ta tuân theo đặc tả, thiết kế, phát triển, và kiểm thử phần mềm. Một DAPM cần phải làm nhiều thứ hơn là chỉ đơn giản là thực hiện viết mã lệnh phần mềm- trong đó viết mã lệnh thường là phần nhỏ nhất của tổng số khối lượng công việc. Viết và kiểm tra tài liệu, thực hiện giao diện mẫu, thiết kế, và kiểm tra lại và kiểm thử mã lệnh chiếm nhiều công sức hơn trong tổng số công việc của dự án. Việc ước lượng effort yêu cầu bạn xác định và ước lượng từng phần nhỏ, sau đó tổng hợp lại tất cả các hoạt động mà bạn phải thực hiện để xây dựng sản phẩm theo cỡ của dự án.
Có hai cách chính để đưa ra khối lượng công việc từ cỡ của dự án :
Cách tốt nhất là sử dụng những dữ liệu lịch sử trong tổ chức của bạn để quyết định bao nhiêu effort trong dự án trước đó tương ứng với cỡ dự án đưa ra. Giả sử tổ chức của chúng ta đã có tài liệu từ dự án trước, nghĩa là chúng ta có ít nhất một dự án quá khứ có cỡ tương tự; thậm chí sẽ là tốt hơn nếu có một vài dự án tương tự như dự án đó, và chúng ta sẽ tuân theo một số vòng đời phát triển tương tự, sử dụng cùng một phương thức phát triển, sử dụng công cụ tương tự, và sử dụng một nhóm với những kỹ năng và kinh nghiệm tương tự đối với dự án mới. Nếu chúng ta không có những dữ liệu quá khứ trong tổ chức bởi vì
chúng ta đã không tập hợp hoặc bởi vì dự án mới rất khác trong một hoặc nhiều vấn đề, chúng ta có thể sử dụng một phương pháp đã được kiểm chứng và chấp nhận giống như mô hình Barry Boehm‟s COCOMO hoặc phương pháp Putnam để chuyển một ước lượng cỡ DAPM thành ước lượng effort. Những mô hình đó tham khảo một số dự án đã hoàn thành trước đó từ một số tổ chức để hiểu cách họ ánh xạ cỡ dự án đến effort trong dự án. Những mô hình dữ liệu có thể không thực sự giống như dữ liệu lịch sử, nhưng chúng có thể giúp chúng ta đưa ra ước lượng khối lượng công việc.
45
3.1.3 Ƣớc lƣợng thời hạn
Bước thứ ba trong việc ước lượng dự án phát triển phần mềm là quyết định thời hạn dự án từ việc ước lượng khối lượng công việc. Thông thường tham gia ước lượng số lượng người mà sẽ làm việc trong dự án, họ sẽ làm gì trong đó (WBS), khi nào họ sẽ bắt đầu công việc và trong dự án và khi nào họ sẽ kết thúc (đó là staffing profile). Một khi bạn có thông tin này, bạn cần nó để điền vào trong lịch thời hạn. Trở lại, dữ liệu lịch sử từ tổ chức của bạn trong các dự án quá khứ hoặc mô hình dữ liệu có thể sử dụng để dự đoán số lượng người bạn sẽ cần để đối với một dự án có cùng cỡ và làm cách nào để chia những công việc đó ra trong một lịch thời hạn.
Nếu bạn không có gì khác, một luật ước lượng thời hạn của thumb[McConnell 1996] có thể dùng để tính ra tổng số thời gian yêu cầu : Schedule in months=3.0* (effort-months)1/3
. Có một số ý kiến rằng giá trị 2.0 hoặc 2.5 hoặc thậm chí 4.0 nên được dùng để thay thế giá trị 3.0.
3.1.4 Ƣớc lƣợng dự toán
Có rất nhiều nhân tố để xem xét khi ước lượng tổng dự toán của một dự án. Chúng bao gồm phí nghiên cứu, phần cứng, và phần mềm hoặc phí di chuyển để hội họp hoặc với mục đích kiểm thử, phí viễn thông (điện thoại đường dài, hội thảo qua video, quay số,..), phí dành cho đào tạo, phí thuê văn phòng và rất nhiều thứ khác nữa.
Chính xác là bạn ước lượng tổng dự toán dự án như thế nào sẽ phụ thuộc vào dự toán của tổ chức của bạn như thế nào. Một vài dự toán có thể không được chỉ rõ cho một dự án đặc biệt và có thể sử dụng để thêm một giá trị liên quan đến tỷ lệ nghiên cứu (theo giờ). Thông thường, một người quản lý dự án phần memè sẽ chỉ ước lượng dự toán nghiên cứu và xác định bất kỳ dự toán dự án thêm vào sẽ không được xem xét trong tổ chức.
Dự toán nghiên cứu đơn giản nhất có thể lấy bằng cách nhân ước lượng khối lượng công việc dự án (theo giờ) với một tỷ lệ nghiên cứu thông thường (theo giờ). Nhiều giá trị nghiên cứu thực tế sẽ trả về từ việc sử dụng tỷ lệ nghiên cứu xác định đối với mỗi vị trí công việc (ví dụ, Kỹ thuật, Chất lượng, Quản lý dự án,Tài liệu, hỗ trợ,..). Bạn có thể phải quyết định phần trăm của tổng số công viẹc trong dự án sẽ được chỉ rõ với mỗi một vị trí. Ngược lại, những dữ liệu lịch sử hoặc mô hình dữ liệu có thể trợ giúp.
46