.11 Bảng chuyển đổi SLOC/UFP

Một phần của tài liệu (LUẬN VĂN THẠC SĨ) Ước lượng dự án trên cơ sở các ca sử dụng (Trang 98 - 106)

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 COCOMO II, kích cỡ hiệu dụng của dự án là 120.000 câu lệnh. Tức là:

D REVL Size = 1 + x Size 100       (2.4)

Với SizeD là đương lượng tái sử dụng của phần mềm được bàn giao.

P.2.9 Ước lượng việc bảo trì phần mềm

COCOMO II khác với COCOMO 81 ở chỗ là có sử dụng các hệ số tỷ lệ tác động đến kích cỡ của mã được hiệu chỉnh, còn trong COCOMO 81 sử dụng các chế độ để tác động vào kích cỡ sản phẩm đang được hiệu chỉnh. COCOMO II có tính thêm những ảnh hưởng lên sản phẩm đang chỉnh sửa thông qua các hệ số SU và UNFM.

“Bảo trì phần mềm” là việc phải thêm vào các tính năng mới và sửa chữa hay thích ứng các tính năng cũ. Hoạt động bảo trị phần mềm không làm thay đổi quá 50% phần mềm cũ, không bao gồm hoạt động xây dựng các hệ thống giao tiếp (với kích cỡ vượt quá 20% hệ thống cũ) mà gần như không phải chỉnh sửa hệ thống cũ.

Kích cỡ của quá trình bảo trì có thể nhận thông qua biểu thức 2.5, khi đã biết kích cỡ mã nguồn ban đầu và phần trăm mã nguồn ban đầu bị thay đổi:

 

M

Size = BaseCodeSize + MCF x MAF (2.5)

Trong đó, hệ số thay đổi bảo trì MCF (Maintenance Change Factor) là hệ số thể hiện phần trăm mã ban đầu thay đổi, nó tương tự hệ số lượng thay đổi hàng năm ACT (Annual Change Traffic) trong COCOMO 81, chỉ khác là chu kỳ bảo trì có thể lớn hơn một năm. Nó được tính như sau:

SizeAdded + SizeModified MCF =

Một cách tính khác đơn giản hơn có thể được sử dụng, đó là chỉ tính mã thêm vào và mã sửa đổi mà bỏ qua mã xóa đi, so với mã ban đầu:

 

M

Size = SizeAdded + SizeModified x MAF (2.7)

Kích cỡ có thể tính theo KSLOC, số điểm chức năng hoặc số điểm ứng dụng. Khi sử dụng điểm chức năng hay điểm ứng dụng, tốt hơn hết là nên ước lượng MCF theo toàn bộ ứng dụng được thay đổi chứ không chỉ theo các thao tác nhập dữ liệu, xuất dữ liệu, các màn hình, báo cáo,… bị thay đổi.

Các hệ số MAF (Maintenance Adjustment Factor) được tính như trong biểu thức 2.8. Nó được sử dụng để điều chỉnh kích cỡ bảo trị hiệu dụng khi xét đến các hệ số SU và UNFM từ mô hình tái sử dụng.

SU MAF = 1 + x UNFM 100       (2.8)

SizeM trong biểu thức 2.5 được sử dụng để xác định công sức bảo trì.

P.2.10 Ước lượng công sức

Trong COCOMO II, công sức được ước lượng theo đơn vị PM (Persons – month) - là lượng thời gian một người bỏ ra phát triển phần mềm trong một tháng. COCOMO II lấy số người giờ trên một PM, PH/PM, như một hệ số điều chỉnh với giá trị danh nghĩa là 152 PH/PM. Giá trị này không bao gồm những ngày nghỉ, lễ tết, thời gian nghỉ cuối tuần. PM khác thời gian để hoàn thành dự án, thời gian này được gọi là TDEV. Ví dụ, một dự án được ước lượng cần 50 PM công sức và thời gian là 11 tháng. Nếu ta sử dụng giá trị PH/PM là 160 thay cho 152, COCOMO II sẽ điều chỉnh ước lượng PM tương ứng (trong trường hợp này, PM giảm 5%). Việc giảm PM này sẽ dẫn tới giảm thời gian phát triển được ước lượng.

Mô hình ước lượng công sức COCOMO II được mô tả trong biểu thức 2.9. Dữ liệu đầu vào là Size – kích thước của phần mềm được phát triển, hằng số A, số mũ E, và các giá trị hệ số nhân công sức EM (Effort Multiplier).

n E i i = 1 PM = A x Size x EM (2.9) Với hằng số A = 2.94 (COCOMO II 2000).

Hằng số A, xấp xỉ hằng số năng suất, đơn vị (PM/KSLOC) trong trường hợp E = 1. Năng suất thay đổi khi E tăng do ảnh hưởng không tuyến tính lên kích thước Size. Hằng số A được khởi tạo khi mô hình được điều chỉnh theo cở sở dữ liệu các dự án, phản ánh một giá trị hiệu suất trung bình. Mô hình COCOMO II nên được điều chỉnh theo dữ liệu nội bộ, phản ánh năng suất nội bộ đẻ cải thiện mức độ chính xác của mô hình.

Kich thước trong Size được tính theo đơn vị KSLOC, bắt nguồn từ việc ước lượng kích thước các môđun cấu thành ứng dụng. Nó cũng có thể được ước lượng bằng đơn vị UFP – điểm chức năng, sau đó chuyển đổi sang SLOC rồi chia cho 1000. Các hệ số chi phí thể hiện đặc tính của phát triển phần mềm. Chúng ảnh hưởng tới công sức để hoàn thành dự án. Một hệ số ch phí là một yếu tố mô hình, có tác động mạnh, làm thay đổi công sức được ước lượng. Với một hệ số nhân công sức được xếp loại ở mức độ trung bình, giá trị tương ứng của EM là 1.00. Nếu các hệ số chi phí làm tăng công sức, EM tương ứng có giá trị lớn hơn 1.00 và ngược lại, nếu các hệ số chi phí làm giảm công sức, EM tương ứng có giá trị nhỏ hơn 1.00.

Trong biểu thức 2.9 các hệ số tỷ lệ trong số mũ E chỉ được sử dụng ở mức dự án. Ngoài ra, hệ số chi phí SCED (thời gian phát triển cần thiết), cũng chỉ được sử dụng tại cấp độ dự án. Các hệ số nhân chi phí khác và kích thước Size được áp dụng cho từng thành phần dự án. Có thể ước lượng công sức cho dự án có một thành phần hay nhiều thành phần. Với dự án gồm nhiều thành phần, các hệ số chi phí ở mức dự án được áp dụng cho tất cả các thành phần.

P.2.11 Các hệ số tỷ lệ

Số mũ E trong biểu thức 2.9 là tổng hợp của 5 hệ số tỷ lệ, thể hiện sự giảm bớt hay tăng thêm chi phí sản xuất trong các dự án phần mềm có kích cỡ khác nhau.

Nếu E < 1.0, dự án cho thấy có thể giảm chi phí sản xuất (dự án có tính kinh tế). Nếu kích thước của sản phẩm tăng gấp đôi, công sức thực hiện dự án không tăng gấp đôi mà sẽ tăng với một lượng nhỏ hơn. Năng suất dự án tăng khi kích thước sản phẩm tăng. Có thể giảm chi phí thực hiện dự án nhờ các công cụ chuyên biệt cho dự án (mô phỏng, chạy thử), nhưng nhìn chung rất khó thực hiện. Với những dự án nhỏ, những chi phí cố định ban đầu như chỉnh sửa các

công cụ và thiết lập các báo cáo chuẩn, mang tính quản lý, thường là nguồn để giảm chi phí sản xuất.

Nếu E = 1.0, tính kinh tế và phi kinh tế của dự án là cân bằng. Mô hình tuyến tính này được áp dụng để ước lượng chi phí cho những dự án nhỏ.

Nếu E > 1.0, dự án cho thấy có thể tăng chi phí sản xuất (dự án có tính phi kinh tế). Thông thường có hai nguyên nhân: giao tiếp giữa các thành viên trong dự án phát sinh quá lớn và phát sinh trong việc tích hợp hệ thống lớn. Các dự án càng lớn sẽ càng cần nhiều nhân lực, do đó sẽ tiêu tốn nhiều kênh giao tiếp hơn. Việc tích hợp một sản phẩm nhỏ vào thành một thành phần của một sản phẩm lớn hơn yêu cầu không những công sức để phát triển sản phẩm nhỏ mà còn phải bổ sung thêm công sức để thiết kế, bảo trì, tích hợp và kiểm thử giao diện của nó với phần còn lại.

Biểu thức 2.10 cho cách tính số mũ E. Bảng P.13 cung cấp các cấp độ đánh giá cho các hệ số tỷ lệ của COCOMO II. Mỗi hệ số tỷ lệ có mức độ phân loại từ cực thấp đến cực cao. Mỗi mức phân loại có trọng số riêng. Giá trị cụ thể của trọng số được gọi là hệ số tỷ lệ (SF). Các SF của dự án, với những cấp độ phân loại được lựa chọn, được cộng lại và sử dụng để xác định số mũ E theo biểu thức 2.10. Số hạng trong phương trình là một hằng số có thể điều chỉnh.

5 j j = 1

E = B + 0.01 x SF (2.10)

Với B = 0.91 (COCOMO II 2000)

Ví dụ, các hệ số tỷ lệ trong COCOMO II với cấp độ đánh giá cực cao được gán trọng số là 0. Do đó dự án có kích cỡ 100 KSLOC với tất cả các hệ số tỷ lệ được đánh giá ở mức độ cực cao thì tổng các hệ số tỷ lệ là SFj 0, E = B = 0.91 và công sức tương đương là: 2.94(100)0.91 = 194 PM.

Hai hệ số tỷ lệ: tính tiền lệ và độ linh hoạt (Precedentedness and Flexibility) có sự thay đổi lớn giữa các mô hình, hệ thống, bán hệ thống và nhúng của mô hình COCOMO nguyên thủy. Bảng P.2 và bảng P.3 thể hiện các đặc tính của dự án tương ứng với tính tiền lệ và độ linh hoạt. Các bảng này dùng để giải thích rõ hơn cho các hệ số mũ PREC và FLEX.

Các hệ số Rất thấp Thấp Trung

bình Cao Rất cao Cực cao PREC Hoàn toàn

không có tiền lệ Hầu như không có tiền lệ Có chút ít tiền lệ Thân thuộc ở mức chung chung Rất thân thuộc Hoàn toàn thân thuộc SFj 6.2 4.96 3.72 2.48 1.24 0.0 FLEX Nghiêm

Một phần của tài liệu (LUẬN VĂN THẠC SĨ) Ước lượng dự án trên cơ sở các ca sử dụng (Trang 98 - 106)

Tải bản đầy đủ (PDF)

(124 trang)