Dự án phần mềm ab bb cb db Tổ chức 2.4 1.05 2.5 0.38 Nửa gắn 3.0 1.12 2.5 0.35 Nhúng 3.6 1.20 2.5 0.32 Bảng P.7 COCOMO cơ sở
Dự án phần mềm ai bi Tổ chức 2.4 1.05 Nửa gắn 3.0 1.12 Nhúng 3.6 1.20 Bảng P.8 COCOMO trung bình P.2 Mô hình COCOMO
P.2.1 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 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 độ khái 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ệ, và 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. Công sức cần để hoàn thành dự án được tính theo đơn vị người-tháng (man-month) và được ước lượng theo công thức: n E NS i i=1 PM =A x Size x EM (2.1) Trong đó, 5 j j=1 E = B + 0.01 x SF
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 x (PM ) (2.2) Trong đó, 5 j j=1 F = D + 0.2 x 0.01 xSF = D + 0.2 x (E - B)
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 cơ sở dữ liệu 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 EM16 củ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 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 cơ sở dữ liệu cùng với 161 dự án của COCOMO II 2000.
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
Các giá trị A, B, C, D có thể được điều chỉnh theo từng cơ sở dữ liệu 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 (không nên sử dụng dữ liêu mà COCOMO II cung cấp sẵn).
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ố đượ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 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.