COCOMO, viết tắt của COnstructive COst MOdel, là mô hình ước lượng chi phí phần mềm do tiến sĩ Barry Boehm đưa ra đầu tiên năm 1981, trong cuốn "Software
Engineering Economics" (Kinh tế học kĩ nghệ phần mềm) của ông. Phiên bản đầu tiên này của COCOMO còn được gọi là "COCOMO 81". Từ khi ra đời cho đến nay, mô hình này liên tục được nghiên cứu và cải tiến để phù hợp với sự thay đổi của kĩ nghệ phần mềm. Năm 1987, hai phiên bản của mô hình COCOMO là Ada COCOMO và Incremental COCOMO (COCOMO gia tăng) được giới thiệu. Trong hai năm tiếp theo 1988 và 1989, mô hình Ada COCOMO được tinh chỉnh. Tuy nhiên, điểm nhấn trong sự phát triển của mô hình COCOMO là vào những năm 1990 mô hình COCOMO II đã ra đời. COCOMO II là phiên bản chính thức thứ hai của mô hình ước lượng chi phí phần mềm, đáp ứng được những thay đổi của thực tiễn phát triển phần mềm chuyên nghiệp từ những năm 1970 đến nay.
2.3.2.1 Mục đích của ngƣời sử dụng COCOMO II
Mô hình COCOMO II có thể trợ giúp cho người dùng:
Đưa ra quyết định đầu tư hoặc các chính sách tài chính có đòi hỏi nỗ lực phát triển phần mềm
Thiết lập các ngân sách và lịch biểu, làm cơ sở cho việc lập kế hoạch và điểm soát
Ra quyết định hoặc thương lượng thoả hiệp giữa các yếu tố chi phí lịch biểu, chức năng, tính năng hay chất lượng phần mềm.
Đưa ra các quyết định quản lý rủi ro về chi phí và thời gian phát triển phần mềm
Quyết định sẽ phát triển, tái sử dụng, xuất xưởng hoặc mua những phần nào trong một hệ thống phần mềm
Đưa ra các quyết định kiểm kê đối với những phần mềm kế thừa
Xác định các chiến lược đầu tư kết hợp để tăng cường năng lực phần mềm của tổ chức, thông qua tái sử dụng, các công cụ, sự thuần thục về quy trình, thuê bên ngoài gia công
Đưa ra quyết định về cách thức thực hiện một chiến lược nhằm cải thiện quy trình
Mô hình ước lượng chi phí phần mềm không chỉ là một tiện ích để đưa vào các đánh giá hệ số chi phí và nhận về các ước lượng về ngân sách và lịch biểu.
2.3.2.2 Mục đích của mô hình COCOMO II
Từ những nhu cầu cải tiến và qua những phản hồi của người dùng mô hình COCOMO 81, mô hình COCOMO II được xây dựng với những mục đích sau:
Mang lại những ước lượng chính xác về chi phí và thời gian cho những dự án hiện tại và có thể cả trong tương lai.
Cho phép các tổ chức có thể dễ dàng điều chỉnh lại, xác lập hoặc mở rộng COCOMO II để phù hợp hơn với hoàn cảnh cụ thể của họ.
Cung cấp các định nghĩa chi tiết, dễ hiểu về các đầu vào, các đầu ra và các giả định của mô hình.
Cung cấp một mô hình có tính xây dựng.
Cung cấp một mô hình quy chuẩn.
Cung cấp một mô hình tiến triển. [1]
2.3.2.3 Các biểu thức ƣớc lƣợng thời gian
Trong mô hình COCOMO II, hai mô hình Post-Architecture (PA) và Early- Design (ED) được sử dụng để phát triển các ứng dụng, tích hợp hệ thống hay phát triển các thành phần cơ bản. Mô hình PA là mô hình chi tiết, được sử dụng khi một dự án đã sẵn sàng để phát triển và có thể duy trì. Hệ thống đó cần có một kiến trúc vòng đời để cung cấp các thông tin chi tiết về các tham số đầu vào của hệ thống, từ đó đảm bảo cho sự chính xác khi ước lượng. Còn mô hình ED là một mô hình ở mức cao, được sử dụng để khảo sát các khả năng thay thế về kiến trúc hoặc các chiến lược phát triển gia tăng. Mức độ chi tiết của mô hình này phù hợp với độ tổng quát của các thông tin có được và mức độ chính xác cần thiết ở giai đoạn sớm của dự án.
Cả mô hình PA và ED đều sử dụng cùng một cách tiếp cận để ước lượng kích cỡ sản phẩm (bao gồm cả phần tái sử dụng) lẫn các hệ số tỉ lệ, đều sử dụng cùng một dạng hàm số để ước lượng nỗ lực và thời gian cần thiết cho phát triển dự án. Các công thức thời gian danh nghĩa (Nominal Schedule - NS) không bao gồm tham số độ co giãn về thời gian cần thiết cho phát triển dự án (SCED) (vì theo danh nghĩa ta cho rằng thời gian luôn được hoàn thành đúng hạn định). Các công thức cụ thể sẽ được giới thiệu trong phần sau. Lượng công sức cần để hoàn thành dự án được tính theo đơn vị người-tháng (Person-Month), PMNS, được ước lượng bởi công thức: n 1 i i E NS A Size EM PM (2.1) trong đó 5 1 01 . 0 j j SF B E
Lượng thời gian để phát triển sản phẩm, TDEVNS được ước lượng bởi công thức: ( )F NS NS TDEV C PM (2.2) Trong đó ) B E ( 2 . 0 D SF 01 . 0 2 . 0 D F 5 1 j j
Giá trị của n trong biểu thức 2.1 là 16 đối với mô hình PA (tức là mô hình PA có 16 hệ số nhân công sức EMi) và 6 đối với mô hình ED, các số SFj là các hệ số mũ. Các giá trị A, B, EM1, ..., EM16, SF1,…, SF5 của mô hình PA trong COCOMO II 2000 được điều chỉnh dựa trên giá trị của các tham số và công sức thực tế đã được rút ra từ 161 dự án trong cơ sở dữ liệu hiện thời của COCOMO II.
Giá trị của các hằng số C và D trong biểu thức về thời gian của COCOMO II 2000 có được bằng cách điều chỉnh theo các giá trị thời gian thực tế trong CSDL của COCOMO II với 161 dự án.
Các giá trị A, B, C, D, SF1, ... SF5 của mô hình ED cũng tương tự như của mô hình PA. Các giá trị từ EM1 đến EM6của mô hình ED có được bằng cách kết hợp 16 hệ số của mô hình PA. Sự kết hợp cụ thể sẽ được đề cập đến trong phần sau.
Chỉ số dưới NS áp dụng với PM và TDEV ngụ ý rằng ở đây ta đang ước lượng công sức và thời gian danh nghĩa. Ảnh hưởng của việc co giãn thời gian thực hiện dự án trong thực tế được đặc trưng bởi tham số SCED. Chúng đều được đưa vào trong CSDL cùng với 161 dự án của COCOMO II 2000. Chi tiết sẽ được giới thiệu trong phần sau.
Kích cỡ được tính theo đơn vị nghìn dòng lệnh (KSLOC) hoặc theo đơn vị điểm chức năng (UFP). Chi phí cho nhân công được tính bằng cách nhân công sức PM với giá nhân công trung bình cho một PM. Các giá trị A, B, C, D trong COCOMO II 2000 được xác định bằng:
A = 2.94 B = 0.91
C = 3.67 D = 0.28
Chi tiết về việc ước lượng các hằng số này cùng các công thức cụ thể để tính toán sẽ được giới thiệu trong phần sau. Các giá trị A, B, C, D có thể được điều chỉnh theo từng CSDL các dự án.
Mỗi tổ chức nên tự điều chỉnh ít nhất là 2 hằng số A và C theo môi trường phát triển của mình để đạt được sự chính xác cần thiết trong ước lượng chứ không nên sử dụng các hằng số đã được cung cấp sẵn bới COCOMO II.
Xét một ví dụ: Hãy ước lượng xem phải cần bao nhiêu thời gian và công sức để phát triển một dự án trung bình, có kích cỡ 100 KSLOC. Với một dự án trung bình thì giá trị của các hệ số nhân công sức được cho chừng 1.0, E được gán bằng 1.15 phản ánh một dự án trung bình hoặc lớn. Vì vậy, công sức cần thiết là:
1.15
2.94 (100) 586.61
NS
PM x (người-tháng)
Tiếp tục với ví dụ trên, thời gian cần thiết để thực hiện dự án là:
7 . 29 ) 6 . 586 ( 67 . 3 ) 6 . 586 ( 67 . 3 TDEVNS (0.280.2(1.150.91)) 0.328 (tháng) Số lượng nhân công trung bình cần thiết để phát triển dự án là:
PMNS/TDEVNS = 586.6/29.7 = 19.75 20 (người)
Như vậy một dự án có 100 KSLOC sẽ cần khoảng 30 tháng cùng với khoảng 20 nhân công để hoàn thành. [1]
2.3.2.4 Xác định kích cỡ
Trong một mô hình ước lượng chính xác, ước lượng đúng được kích cỡ của một dự án phần mềm là điều rất quan trọng. Tuy nhiên đây là điều khó khăn và đặt ra nhiều thách thức. Một dự án phần mềm nói chung thường bao gồm mã lệnh được viết mới, mã lệnh tái sử dụng từ các nguồn khác (có hoặc không có sự sửa đổi) và mã lệnh dịch tự động. Mô hình COCOMO II đánh giá kích cỡ của một dự án phần mềm thông qua hai loại mã lệnh cơ bản là mã lệnh được viết mới và mã lệnh được dùng lại nhưng có sửa đổi, bởi chỉ có hai loại này mới ảnh hưởng đến công sức mà những lập trình viên phải bỏ ra.
Đối với mô hình COCOMO II, mã lệnh được viết mới và mã lệnh tái sử dụng được gói chung làm một trong quá trình đánh giá. Trong đó các dòng mã được viết mới là tiêu chí cơ bản để đánh giá cỡ lớn, còn mã lệnh tái sứ dụng qua sao chép rồi chỉnh sửa được điều chỉnh và lấy tương đương bằng một số lượng dòng lệnh mới. Việc điều chỉnh này có tính đến cả lượng thiết kế, mã nguồn và kiếm thử bị thay đổi. Nó còn xét đến tính có thể hiểu được của mã nguồn và tính thân thuộc của lập trình viên với mã nguồn. Còn đối với loại mã lệnh dịch tự động, một tỉ lệ năng suất dịch mã lệnh được sử dụng để tính lượng công sức từ lượng mã đã được dịch.
Phần tiếp theo đây chúng ta sẽ đề cập đến việc xác định kích thước cả mã lệnh viết mới và mã lệnh tái sử dụng.
2.3.2.5 Đếm số dòng mã lệnh
Có một số nguồn để ước lượng số dòng mã lệnh mới, trong đó quan trọng nhất phải kể đến dữ liệu lược sử. Nó được sử dụng để chuyển đổi các điểm chức năng (FP), các thành phần có được từ giai đoạn sớm chia một dự án, sang số dòng lệnh ước lượng. Nếu thiếu dữ liệu lược sử, có thể phán đoán chuyên gia để kế thừa các ước lượng với kích cỡ tương đương, tương đương ít nhất và tương đương nhiều nhất.
Kích thước của mã lệnh được biểu diễn theo đơn vị nghìn dòng lệnh (KSLOC). Một dòng mã nguồn lệnh, nói chung không bao gồm mã lệnh trong các phần mềm hỗ trợ, không được xuất xưởng (như các chương trình test driver). Tuy nhiên, nếu chúng được xây dựng một cách cẩn thận như phần mềm xuất xưởng, với các quá trình thẩm tra, các kế hoạch kiểm thử, tài liệu... chúng sẽ được tính đến. Mục tiêu của việc đếm số dòng mã lệnh là để xác định được lượng chất xám phải bỏ ra trong việc phát triển chương trình.
Để định nghĩa chính xác thế nào là dòng lệnh nói chung là khó, bởi trong các ngôn ngữ lập trình khác nhau thì có sự khác nhau trong khái niệm về câu lệnh có khả năng thực thi và khái niệm về khai báo dữ liệu. Trong COCOMO II, câu lệnh nguồn logic được chọn làm dòng mã lệnh chuẩn. Học viện kỹ thuật phần mềm (SEI) định nghĩa một bản liệt kê (checklist) các câu lệnh nguồn logic được dùng làm đơn vị đo lường cho dòng mã lệnh. SEI đã phát triển checklist trên như là một phần của hệ thống các chuẩn checklist, các biểu mẫu báo cáo, các biểu mẫu bổ sung để hỗ trợ cho việc đo lường.
Hình dưới đây minh hoạ bảng liệt kê định nghĩa SLOC khi áp dụng để hỗ trợ việc phát triển mô hình COCOMO II. Mỗi một dấu được đánh trong bảng kê tại cột "Include" ám chỉ một kiểu câu lệnh, khai báo liên quan hoặc một thuộc tính nào đó được đưa vào định nghĩa, trái ngược với cột "Exclude" các mục khác trong định nghĩa nhằm làm sáng tỏ các thuộc tính của dòng lệnh, phục vụ cho việc sử dụng, phân phối các hàm, chức năng, các bản thử và tình trạng phát triển.
2.3.2.6 Đếm các điểm chức năng chƣa điều chỉnh (UFP)
Phép tiếp cận ước lượng chi phí theo điểm chức năng dựa trên số lượng chức năng trong một dự án phần mềm và một tập các nhân tố đơn lẻ của dự án. Điểm chức năng rất hữu ích cho việc ước lượng bởi chúng dựa trên thông tin có được từ giai đoạn sớm của dự án.
Việc đếm điểm chức năng của một dự án được thực hiện bằng cách tính số lượng các chức năng xử lý thông tin gắn với dữ liệu ngoài quan trọng hoặc các điều khiển xuất, nhập, hoặc các kiểu tập tin. Trong bảng dưới đây liệt kê năm kiểu chức năng.
Điểm chức năng Mô tả
Nhập dữ liệu (EI) Là các chức năng nhập dữ liệu, có ảnh hưởng đến một hay nhiều ILF. Ví dụ: Nhập chứng từ
Xuất dữ liệu (EO) Là các chức năng cung cấp dữ liệu cho người dùng, thông thường là các báo cáo nghiệp vụ
Các file logic trong (ILF)
Gồm các file logic được quản lý bởi ứng dụng, ví dụ như các bảng của CSDL. Khái niệm "file" ở đây cần được hiểu là một nhóm dữ liệu thường được truy cập cùng với nhau.
Các file giao tiếp ngoài (EIF)
Gồm các file của các ứng dụng khác được ứng dụng truy xuất đến. Ví dụ như bảng nhân viên của hệ thống nhân sự bị truy xuất bởi hệ thống kế toán, bảng nhân viên là EIF của hệ thống kế toán
Truy vấn ngoài (EQ) Gồm các chức năng tra cứu, trợ giúp,vv... các chức năng này chỉ cung cấp thông tin chứ không làm thay đổi các file.
Bảng 2.1: Các kiểu chức năng
Mỗi thể hiện của một trong các kiểu chức năng trên được sắp xếp và phân chia thành các mức độ phức tạp. Các độ phức tạp quyết định một tập các trọng số kết hợp với số lượng chức năng đếm được, từ đó quyết định số UFP (Unadjusted Function Points - Điểm chức năng chứa điều chỉnh). Đây là một đơn vị định cỡ kích thước được COCOMO II sử dụng. Một thủ tục FP thông thường (không được thực hiện trong COCOMO II ), bao gồm việc ấn định các mức độ ảnh hưởng (DI) của 14 đặc tính ứng dụng lên dự án phần mềm. Mức độ ảnh hưởng của mỗi đặc tính được
gán các giá trị hệ số từ 0.0 đến 0.05. Mười bốn hệ số ảnh hưởng sau đó được cộng lại với nhau và cộng thêm 0.65 là mức độ ảnh hưởng cơ bản cho việc tạo ra các hệ số đặc tính thích ứng, và do đó giá trị của tổng các hệ số ảnh hưởng nằm trong khoảng 0.65 đến 1.35. Mỗi một trong mười bốn đặc tính này, ví dụ như các chức năng phân tán, tính năng hay tính tái sử dụng được, có mức ảnh hưởng tối đa lên giá trị công sức là 0.05 (5%). Tuy nhiên giá trị tối đa này nhiều khi không thật hợp lí, ví dụ như giới hạn ảnh hưởng của việc tái sử dụng là 5% dường như không phù hợp với kinh nghiệm của những nhà phát triển COCOMO. Do đó COCOMO II sử dụng đơn vị UFP làm đơn vị đo kích thước và áp dụng các hệ số tái sử dụng, các hệ số nhân, các hệ số tỉ lệ của nó cho việc xác định kích cỡ của việc tái sử dụng, phân hồi,...có ảnh hưởng đến công sức phát triển dự án.
Thủ tục COCOMO II dùng để xác định các UFP được định nghĩa dưới đây. Đây là một thủ tục gồm bốn bước, áp dụng cho cả mô hình ED và PA:
Đếm số lƣợng các chức năng theo kiểu: Việc tính các chức năng chưa điều
chỉnh nên được thực hiện bởi một chuyên viên kỹ thuật hàng đâu, dựa trên thông tin về các yêu cầu của phần mềm cũng như các tài liệu thiết kế phần mềm. Cần tính số lượng của mỗi một trong năm kiểu chức năng [ILF, EIF, EI, EO và EQ].
Xác định độ phức tạp: Phân chia và sắp xếp độ phức tạp của mỗi chức năng
thành các mức độ thấp, trung bình, cao, tùy thuộc vào số lượng các kiếu phần tử dữ liệu chứa trong chức năng đó và số lượng các kiểu file mà chức năng đó