Các nhóm đặc tính Các yếu tố Ký hiệu
Kỹ năng của kỹ sư Tri thức của miền ứng dụng. Hiểu biết ngôn ngữ lập trình.
Kinh nghiệm với phần mềm hệ thống (OS, DBMS).
KAD FPL ESS Các đặc tính kỹ
thuật
Kiến trúc của các môđun. Độc lập giữa các môđun.
Tính dễ thay đổi/đọc của ngôn ngữ chương trình. Có thể dùng lại các môđun.
SSS ISM CRP RLS Môi trường Cập nhật tài liệu.
Tuân theo tiêu chuẩn kỹ thuật phần mềm. Dễ dàng kiểm thử.
DOC SES TST Bảng P.2 Bảng các thừa số điều chỉnh giá trị
Các nhóm đặc tính
Trọng số (Wg) T – thử nghiệm (df = 31)
95% khoảng tin cậy của chênh lệch Trung
bình Độ lệch T Dấu hiệu Dưới Trên
Kỹ năng của kỹ sư 36.7 9.6 0.011 0.991 3.4263 3.4638 Đặc tính kỹ thuật 33.1 8.6 0.016 0.987 3.0721 3.1221
Môi trường bảo trì
30.2 9.9 0.025 0.980 3.6048 3.5173
Bảng P.3 Trọng số các nhóm đặc tính (N = 32) Loại chức năng Các tham số Hướng dẫn ILF và EIF Số loại bản ghi
(RET)
Đếm số loại bản ghi (RET). Coi mỗi nhóm dữ liệu là một loại bản ghi. Ví dụ: các đơn mua hàng:
RET #1
Purchase Orders No, Data, Supplier Name, Order Value
RET #2
Item Code, Unit Of Measure, Quality Ordered, Rate,…
RET #3 Số trường dữ
liệu được tham chiếu (DET)
Đếm số trường dữ liệu được tham chiếu (DET) là trường duy nhất con người có thể nhận biết trong ILF, không kể các trường khóa liên kết, các trường lặp lại đối với các nhóm dữ liệu.
EI Các tệp dữ liệu
được tham chiếu (FTR)
Đếm các tệp dữ liệu tham chiếu (FTR). Mỗi ILF được đọc hoặc cập nhật là một FTR.
Mỗi EIF được coi là một FTR. Chú ý: chỉ đếm mỗi ILF hoặc EIF một lần.
Số trường dữ liệu được tham chiếu (DET) là những trường duy nhất có thể nhận biết trong ILF, được EI cập nhật.
Đếm DET. Các trường dữ liệu được nhập vào mang một ý nghĩa nào đó về nghiệp vụ được coi là một DET.
Không đếm các thông báo lỗi hoặc các thông báo nhắc trên màn hình.
Nếu các dữ liệu này được lưu trữ vật lý tại nhiều nơi thì cũng chỉ coi như một DET.
EO Các tệp dữ liệu
được tham chiếu (DET)
ILF hay EIF được đọc để hoàn thành EO.
Số trường dữ liệu được tham
chiếu EQ Các tệp dữ liệu được tham chiếu (EIF). Các ILF hoặc EIF được đọc. Đếm FTR.
Đếm các FTR vào và độc lập với nhau.
Số trường dữ liệu được tham chiếu (DET)
Đếm các trường duy nhất xuất hiện trong EQ.
Bảng P.4 Hướng dẫn xác định các tham số cần thiết Nhập dữ liệu (EI) Nhập dữ liệu (EI) Số kiểu tệp tham chiếu (FTR) Số phần tử dữ liệu 1 – 4 5 – 15 > 15 < 2 Thấp (3) Thấp (3) Trung bình (4) 2 Thấp (3) Trung bình (4) Cao (6)
> 2 Trung bình (4) Cao (6) Cao (6) Xuất dữ liệu (EO)
Số kiểu tệp tham
chiếu (FTR) Số phần tử dữ liệu
1 – 5 6 – 19 > 19
< 2 Thấp (4) Thấp (4) Trung bình (5)
2 – 3 Thấp (4) Trung bình (5) Cao (7) > 3 Trung bình (4) Cao (7) Cao (7) Truy vấn ngoài (EQ)
Số kiểu tệp tham
chiếu (FTR) Số phần tử dữ liệu
1 – 5 6 – 19 > 19
< 2 Thấp (3) Thấp (3) Trung bình (4)
2 – 3 Thấp (3) Trung bình (4) Cao (6) > 3 Trung bình (4) Cao (6) Cao (6)
Các tệp logic trong (ILF) Số kiểu tệp tham
chiếu (FTR) Số phần tử dữ liệu
1 – 19 20 – 50 >= 51
1 RET Thấp (7) Thấp (7) Trung bình (10)
2 – 5 RET Thấp (7) Trung bình (10) Cao (15) >= 6 RET Trung bình (10) Cao (15) Cao (15) Các tệp giao tiếp ngoài (EIF)
Số kiểu tệp tham
chiếu (FTR) Số phần tử dữ liệu
1 – 19 20 – 50 >= 51
1 RET Thấp (5) Thấp (5) Trung bình (7)
2 – 5 RET Thấp (5) Trung bình (7) Cao (10) >= 6 RET Trung bình (7) Cao (10) Cao (10)
Bảng P.5 Tham chiếu cho các chức năng Chức năng Trọng số theo tính phức tạp chức năng (W) Chức năng Trọng số theo tính phức tạp chức năng (W)
Thấp Trung bình Cao EI 3 4 6 EQ 4 5 7 EQ 5 4 6 ILF 7 10 15 EIF 5 7 10
Bảng P.6 Bảng tính toán điểm chức năng không được điều chỉnh Dự án phần 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