NS
PM = 2.94 x 100 = 586.61 (người-tháng) và thời gian cần thiết để thực hiện dự án là:
(0.28 + 0.2 x (1.15 - 0.91)) 0.328 NS
TDEV = 3.67 x 586.61 = 3.67 x 586.61 = 29.7 (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.61/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 [13].
P.2.2 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 thướ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 nhau (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 thướ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ả 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.
P.2.3 Đế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ịch sử. Nó được 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 đầu chi một dự án, sang số dòng lệnh ước lượng. Nếu thiếu dữ liệu lịch 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 kiể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 loogic được chọn làm dòng mã lệnh chuẩn.
P.2.4 Đếm các điểm chức năng chưa điều chỉnh (UFP)
Phương 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 yếu 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 đầu 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ả
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 tệp lôgic trong (ILF)
Gồm các tệp logic được quản lý bởi ứng dụng. Ví dụ: như bảng của cơ sở dữ liệu. Khái niệm “tệp ” ở đâ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 tệp giao tiếp
ngoài (EIF)
Gồm các tệp 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,… các chức năng này chỉ cung cấp thông tin chứ không làm thay đổi các tệp .
Bảng P.9 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 14 đặc tính này, ví dụ như chức năng phân tán, 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 nhiefu 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ệ cho việc xác định kích cỡ phần mềm tái sử dụng,… có ảnh hưởng đến công sức phát triển dự án.
Ưới đây là thủ tục được COCOMO II dùng để xác định các UFP, áp dụng cho cả mô hình ED và PA:
Đếm số lượng chức năng theo loại: Việc tính các chức năng chưa điều chỉnh 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 mỗi 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 tệp mà chức năng tham chiếu tới.
Xác định trọng số phức tạp thích hợp: Đánh trọng số của mỗi kiểu chức năng ở mỗi mức độ phức tạp đã được ấn định trong bước 2, xem bảng sau. Các trọng số này phản ánh công sức cần có để hoàn thiện chức năng này.
Tính toán UFP: Cộng tất cả các trọng số của mỗi kiểu hàm đã tính trong bước 3 lại, đó chính là giá trị của UFP.
Kiểu chức năng Độ phức tạp – Trọng số Thấp Trung bình Cao ILF 7 10 15 EIF 5 7 10 EI 3 4 6 EO 4 5 7 EQ 3 3 6
Bảng P.10 Xác định trọng số theo độ phức tạp của các chức năng
P.2.5 Mối liên hệ giữa UFP và SLOC
Việc chuyển từ UFP sang SLOC phụ thuộc vào việc các chức năng này được xây dựng trên ngôn ngữ nào. COCOMO II đã được xây dựng một bảng hệ số chuyển từ UFP sang SLOC cho cả hai mô hình PA và ED. Phiên bản năm 2000 của bảng được cho trong hình dưới:
Ngôn ngữ SLOC/UF P Ngôn ngữ SLOC/UF P Access 38 Jovial 107 Ada 83 71 Lisp 64
Ada 95 49 Machine Code 640
Al Shell 49 Modula 2 80
APL 32 Pascal 91
Assembly – Basic 320 Perl 27
Assembly – Macro 213 PowerBuilder 16
Basic – ANSI 64 Prolog 64
Basic – Compiled 91 Query – Default 46
Basic Visual 32 Report Generator 80
C 128 Second Generation
Language
107
C++ 55 Simulation – Default 46
Cobol (ANSI 85) 91 Speadsheet 6
Database – Default 40 Third Generation Language 80 Fifth Generation Language 4 Unix Shell Scripts 107
First Generation Language 320 USR_1 1
Forth 64 USR_2 1 Fortran 77 107 USR_3 1 Fortran 95 71 USR_4 1 Fourth Generation Language 20 USR_5 1
High Level Language 64 Visual Basic 5.0 29
HTML 3.0 15 Visual C++ 34
Java 53
Bảng P.11 Bảng chuyển đổi SLOC/UFP
P.2.6 Tổng hợp các mã mới, mã thích ứng và mã tái sử dụng
Kích cỡ của một sản phẩm được thảo luận từ trước đến giờ đều là cho phát triển mới. Mã lệnh được tạo ra từ nhiều nguồn khác nhau và được dùng cho sản phẩm đang phát triển có ảnh hưởng lên kích cỡ của sản phẩm. Mã có sẵn và được đóng gói xem như một hộp đen (blackbox) và được tích hợp vào sản phẩm gọi là mã tái sử dụng. Mã nguồn có sẵn xem là một hộp trắng (whitebox), có thể
chỉnh sửa làm thích ứng với sản phẩm gọi là mã thích ứng (adapted code). Kích cỡ hiệu dụng của mã tái sử dụng và mã thích ứng được điều chỉnh về đơn vị mã mới. Đại lượng mã đã điều chỉnh này được gọi là số dòng lệnh tương đương – ESLOC (Equivalent Source Lines Of Code). Mô hình định cỡ xem xét việc tái sử dụng cho hai đơn vị FP và SLOC là như nhau trong cả hai mô hình ED và PA.
P.2.7 Mô hình tái sử dụng
Biểu thức (2.3) là phương trình không tuyến tính để ước lượng kích cỡ của phần tái sử dụng trong phần mềm của mô hình COCOMO II. Nó bao gồm lượng phần mềm được thích ứng và ba hệ số phản ánh mức độ chỉnh sửa: phần trăm thiết kế được chỉnh sửa (DM), phần trăm mã được chỉnh sửa (CM) và một hệ số phần trăm phản ánh công sức cần có để tích hợp thành phần tái sử dụng hoặc thành phần thích ứng vào dự án phần mềm (IM). Ba hệ số mã COCOMO 81 xem như là các hệ số tuyến tính, nhưng COCOMO II đã bổ sung vào mối quan hệ không tuyến tính giữa số KSLOC thích ứng (Adapted KSLOC) so với KSLOC nhằm phản ánh khuynh hướng không tuyến tính của mô hình.
AAF = (0.4 x DM) + (0.3 x CM) + (0.3 x IM) AA + AAF x (1 + 0.02 x SU x UNFM) , AAF 50 100 AAM =
AA + AAF + (SU x UNFM)
, AAF > 50 100 (2.3) AT = x (1 - ) x AAM 100 EquivalentKSLOC AdaptedKSLOC
Hệ số SU (Software Understanding) là hệ số phản ánh tính có thể hiểu được của phần mềm, mang giá trị phần trăm. Giá trị của nó được tính bằng cách lấy trung bình một cách chủ quan theo ba tiêu chí: tính cấu trúc, tính rõ ràng của ứng dụng và tính “tự mô tả” (Self Descriptiveness).
Hệ số AA (Assessment and Assimilation) là hệ số xác định mức độ cần thiết xem một thành phần tái sử dụng có thích ứng với ứng dụng hay không và mức độ đồng bộ hóa cần thiết để tích hợp nó vào sản phẩm hoàn chỉnh.
Lượng công sức cần thiết để chỉnh sửa những thành phần có sẵn là một hàm không những của công sức chỉnh sửa để thích ứng (AAF), mà của cả tính
có thể hiểu được của phần mềm có sẵn (SU), tính không quen thuộc với phần mềm của lập trình viên (UNFM). Hệ số UNFM được nhân với hệ số SU. Nếu các lập trình viên làm việc với phần mềm hàng ngày, UNFM sẽ mang giá trị là 0. Còn nếu là phần mềm mà lần đầu tiên các lập trình viên biết đến thì UNFM có giá trị là 1.
Việc tính ESLOC dựa vào kích cỡ của phần sản phẩm được thích ứng với một hệ số AAM (Adaptation Adjustment Modifier). Đây là hệ số phản ánh lượng công sức bỏ ra để tích hợp phần thích ứng vào sản phẩm. Giá trị (1 – AT/100) liên quan đến mã lệnh dịch tự động. Nếu không có mã lệnh nào thuộc phần dịch tự động, khi đó giá trị của AT = 0.
AAM sử dụng các hệ số SU, UNFM và AA cùng với một hệ số gọi là lượng chỉnh sửa để thích ứng (AAF – Adaptaion Adjustment Factor). AAF chứa các đại lượng DM, CM và IM:
DM là phần trăm trong thiết kế của phần mềm cần chỉnh sửa để thích ứng vào các mục đích mới và môi trường mới.
CM là phần trăm mã nguồn của phần mềm cần chỉnh sửa để thích ứng vào các mục đích mới và môi trường mới.
IM là phần trăm nỗ lực cần để tích hợp phần mềm vào sản phẩm một cách tổng thể và kiểm thử sản phẩm, so với nỗ lực thông thường để tích hợp và kiểm thử phần mềm có kích cỡ tương đương.
Nếu không có DM hay CM (thành phần được sử dụng mà không phải chỉnh sửa) thì không có SU, tức là mã không được chỉnh sửa. Ngược lại, nếu mã được chỉnh sửa thì SU sẽ có giá trị khác không [13].
P.2.8 Hướng dẫn việc định lượng phần mềm thích ứng
Trong COCOMO II, thuật ngữ mã nguồn mới ở đây ám chỉ phần mềm được xây dựng mới từ ban đầu. Mã nguồn thích ứng là những mã có sẵn từ trước nhưng có một số chỉnh sửa trước khi sử dụng. Còn mã nguồn tái sử dụng là những mã không hề có sự thay đổi nào. COTS là những phần mềm đóng gói được sử dụng. không cần thay đổi. Nó chỉ khác mã nguồn tái sử dụng là cần có phần mã viết thêm để gắn kết COTS với dự án phần mềm.
Đối với mã nguồn tái sử dụng và COTS, do không phải chỉnh sửa gì nên DM = 0, CM = 0, còn SU, UNFM không được xét đến. AA và IM có thể có giá trị khác 0. Tái sử dụng không có nghĩa là công sức tích hợp và kiểm thử là hoàn toàn không có. Tuy nhiên, trong hướng tiếp cận tái sử dụng, với các sản phẩm có kiến trúc tốt thì công sức tích hợp và kiểm thử là rất nhỏ.
Đối với phần mềm thích ứng, DM và CM > 0, và tất cả các hệ số tái sử dụng khác thường cũng khác 0. IM luôn được mong đợi có giá trị nhỏ nhất, nhưng đôi khi trong các ứng dụng phức tạp thì IM lại có giá trị đáng kể, thậm chí là lớn hơn 100%. Bảng 21 cho các giá trị của các hệ số tái sử dụng.
Loại mã nguồn Các tham số tái sử dụng
DM CM IM AA SU UNFM Mới: Tất cả các phần mềm được xây dựng từ đầu Không xét Được thích ứng 0-100%, thường là > 0% 0-100%, thường là > DM và phải > 0% 0-100% + IM luôn ở mức vừa phải, có thể > 100% 0-8% 0-5% 0-1 Được tái sử dụng: không thay đổi phần mềm có sẵn 0% 0% 0-100%, hiếm khi 0%, nhưng có thể rất nhỏ 0-8% Khôn g xét Không xét COTS: phần mềm đóng gói sẵn (luôn cần viết thêm mã tích hợp, bao bên ngoài COTS) 0% 0% 0-100% 0-8% Khôn g xét Không xét
Bảng P.12 Các ràng buộc và hướng dẫn xác định tham số phần mềm được thích ứng
COCOMO II sử dụng một hệ số gọi là REVL (Requirements Evolution and Volatility) để điều chỉnh kích cỡ hiệu dụng của sản phẩm do sự mở rộng và thay đổi yêu cầu, do việc thay đổi, cải tiến giao diện, nâng cấp công nghệ, hay do sử dụng các COTS thay thế. Đây là phần trăm mã nguồn bị bỏ do đổi mới yêu cầu.
Lấy ví dụ, một dự án bàn giao 100.000 câu lệnh, nhưng loại bỏ khoảng 20.000 câu lệnh, như vậy có nghĩa là REVL = 20. Khi đó, nếu ước lượng bằng