Hình 6. Biểu đồ Use Case
Một ứng dụng của UCPM cho những use Case đã được trình bày bên trên được thể hiện trong bảng dưới. Cột giá trị được tính bằng cách lấy weight * number. Tổng điểm UUCP được tính bằng cách cộng tất cả các giá trị của các cột.
Bảng trên đưa ra một mô hình thể hiện cho mô hình Use Case bên trên và minh họa một ứng dụng của UCPM. Nếu không có nhiều thông tin về việc thực thi Karner cho rằng điểm UUCP có thể được dùng để tạo ra một định giá. Ông ta
phát biểu sâu hơn là sẽ nhận được một định lượng tốt hơn nếu các nhân tố phức tạp và nhân tố môi trường được sử dụng cho việc tính toán.
Việc tính toán của TCF được minh họa trong bảng trên đã được sử dụng như một nhân tố cái mà nó phản xạ kỹ thuật khó trong xây dựng ứng dụng. Nó dựa trực tiếp trên phương thức Function Point, với một vài nhân tố đã được thêm vào và một vài nhân tố khác đã bị bỏ đi để phản chiếu kinh nghiệm tốt hơn của một tổ chức đã làm việc với phương thức Objectory Systems trong Sweden. Để theo dõi cơ sở của trọng lượng, cái mà được gán không rõ ràng, không có cái nào được miêu tả trong một vài phương thức thuật toán khác.
Những nhân tố kỹ thuật phức tạp đã xuất hiện trong UCPM. Mỗi nhân tố được đưa một tỷ số từ người ước lượng định giá từ 1 đến 5.
Một nhân tố có giá trị là 3 thì nó không chủ yếu hoặc không liên quan. Nếu tất cả các nhân tố có giá trị là 3 thì TCF sẽ là 1 vì vậy nó sẽ không có hiệu quả trong việc tính toán. Quá trình tính toán của TCF được tính toán theo công thức cài mà kèm theo FPA. Sự chứng minh là đúng cho những trọng lượng đã không được đưa ra.
TCF = C1 + C2* Tong(Fi * Wi)(I = 1…13) với C1 = 0.6, C2 = 0.01;
Bảng sau tính độ hiệu quả của dự án. Nó dựa trên cùng dạng như TCF. Mỗi tác nhân được đưa ra một tỷ lệ bởi người định lượng nằm trong khoảng 1 đến 5
Các nhân tố đã được nhận biết trong UCPM được liệt kê trong bảng sau:
Một nhân tố có giá trị là 3 thì có nghĩa là nó không liên quan, nếu tất cả các nhân tố là 3 thì EF sẽ là 1 vì vậy nó sẽ không có hiệu quả cho toàn bộ phép tính
Trong đó C1 = 1.4, C2 = - 0.03;
Để đến với kết quả cuối cùng UCP, phép tính được thực hiện như sau UCP = UUCP*TCF*EF
Số đầu tiên trong của UCP được tính theo bằng cách nhân số đó với một số giờ cố định
Tiếp tục với ví dụ này, như nếu không có thông tin có sẵn cho phép tính của TCF và EF, những giá trị này đều bằng 1.
UCP = UUCP =81;
Hours per UCP = 20 (following Karner)
Estimate = 81* 20hrs = 1620;[5]
2.3. Các mô hình ước lượng dự án phần mềm
2.3.1 Tổng quan về các mô hình ƣớc lƣợng kinh nghiệm
Mô hình ước lượng cho phần mềm máy tính dùng các công thức suy ra từ kinh nghiệm để dự đoán dữ liệu vốn là phần cần thiết cho bước lập kế hoạch dự án phần mềm. Dữ liệu kinh nghiệm hỗ trợ cho hầu hết các mô hình được suy dẫn ra từ một
mẫu dự án có giới hạn. Vì vậy không có mô hình ước lượng nào thích hợp cho mọi lớp phần mềm và trong mọi môi trường phát triển.
Môi trường tài nguyên: bao gồm nhiều hay một phương trình suy diễn theo kinh nghiệm dự đoán công sức (người-tháng), thời hạn dự án (tháng), hay các dữ liệu dự án thích hợp khác. Có 4 lớp mô hình tài nguyên:
Mô hình đơn biến tĩnh
Mô hình đa biến tĩnh
Mô hình đa biến động
Mô hình lý thuyết
Mô hình đơn biến tĩnh:
Tài nguyên = c1 *(đặc trưng được ước lượng) c2
với tài nguyên có thể là công sức, thời hạn dự án, đội ngũ nhân viên, hay dòng tư liệu phần mềm. Các hằng c1 và c2 được suy từ dữ liệu thu thập từ các dự án quá khứ. Đặc trưng được ước lượng là số dòng mã gốc, công sức (nếu được ước lượng), hay các đặc trưng phần mềm khác. Các mô hình lấy dạng được mô tả trên có thể được suy diễn cho môi trường cục bộ nếu có sẵn đủ các dữ liệu lịch sử.
*Mô hình chi phí xây dựng (COCOMO)
Mô hình đa biến tĩnh, giống như mô hình đơn biến tĩnh, dùng dữ liệu lịch sử để suy diễn ra mối quan hệ kinh nghiệm. Một mô hình điển hình có dạng:
Tài nguyên = c11e1 + c21e2 +…
Với ei là đặc trưng phần mềm thứ i; ci1, ci2 là các hằng suy dẫn từ kinh nghiệm cho đặc trưng thứ i.
Mô hình đa biến động chiếu các yêu cầu tài nguyên như một hàm của thời gian. Nếu mô hình này được suy dẫn theo kinh nghiệm thì các tài nguyên được xác định theo các chuỗi thời gian với việc cấp cho một số phần trăm công sức (hay các tài nguyên khác) cho từng bước trong tiến trình kỹ nghệ phần mềm. Mỗi bước có thể chia nhỏ hơn nữa thành các nhiệm vụ. Một cách tiếp cận lý thuyết tới các mô hình đa biến động giả thiết về một „đường cong chi phí tài nguyên‟ liên tục và từ đó suy dẫn ra phương trình mô phỏng hành vi của tài nguyên.
*Mô hình ƣớc lƣợng PUTNAM
Mỗi một trong các mô hình được thảo luận ở trên đều để cập tới các vấn đề vĩ mô trong việc phát triển dự án phần mềm. Việc phân loại mô hình tài nguyên cuối cùng xem xét phần mềm theo quan điểm vi mô, tức là đặc trưng của mã gốc (như các số toán tử và toán hạng).
2.3.2 Mô hình ƣớc lƣợng COCOMO (Contructive Cost Model)
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