T5 Khả năng sử dụng lại 1 3 3 T6 Dễ cài đặt 0.5 3 1.5 T7 Dễ sử dụng 0.5 3 1.5 T8 Khả chuyển 2 3 6 T9 Dễ thay đổi 1 3 3 T10 Tính tương tranh 1 5 5
T11 Bao gồm các tính năng bảo mật đặc biệt
1 3 3
T12 Cung cấp xử lý trực tiếp cho bên thứ ba
1 3 3
T13 Các tiện ích đào tạo người dùng đặc biệt
1 3 3
tổng cộng
TFactor 47
Bảng 4.3 Bảng đánh giá các yếu tố phức tạp kỹ thuật dự án iCoot
Và chúng ta tính được yếu tố phức tạp kỹ thuật (bảng 4.4):
TCF = 0.6 + (0.01 * TFactor) = 0.6 + (0.01 * 47) = 1.07 (IV)
Yếu tố Mô tả Trọng số Đánh giá Kết quả
F1 Hiểu biết về RUP 1.5 3 4.5
F2 Kinh nghiệm ứng dụng 0.5 3 1.5
F3 Kinh nghiệm hướng đối tượng 1 4 4
F4 Khả năng phân tích của quản lý 0.5 4 2
F5 Động lực 1 3 3
F6 Các yêu cầu ổn định 2 3 6
F7 Nhân lực bán thời gian -1 0 0
Yếu tố tổng cộng
EFactor 19
Bảng 4.4 Bảng đánh giá các yếu tố phức tạp môi trường dự án iCoot
Tương tự, chúng ta tính được yếu tố phức tạp môi trường:
ECF = 1.4 + (-0.03 * EFactor) = 1.4 + (-0.03 * 19) = 0.83 (V)
Từ (III), (IV) và (V), chúng ta tính được điểm ca sử dụng (được điều chỉnh):
UCP = UUCP * TCF * ECF = 122 * 1.07 * 0.83 ≈ 108.3
Tiếp theo chúng ta sẽ tính ước lượng nỗ lực thông qua đổi số điểm ca sử dụng UCP thành (man-hours), sử dụng chuẩn hoặc tỉ lệ nỗ lực (ER – Effort Rate) và nhân giá trị này với số điểm ca sử dụng.
Theo đề xuất của Karner, ông đưa ra 20 giờ công cho mỗi điểm ca sử dụng. Một cách tiếp cận nữa là đưa ra 36 giờ công cho mỗi điểm ca sử dụng. Lý do cho cách tiếp cận này là các yếu tố môi trường là căn cứ để đánh giá mức độ kinh nghiệm của nhân viên và sự ổn định của dự án. Các số âm có nghĩa là tốn nhiều nỗ lực cho đào tạo nhóm thành viên hoặc các vấn đề do sự bất ổn định.
Một cách tiếp cận khác được Schneider và Winters đề xuất là tính tổng các yếu tố môi trường từ F1 đến F6 mà có giá trị đánh giá lớn hơn 3 và cộng với các yếu tố từ F7 đến F8 mà có giá trị đánh giá nhỏ hơn 3. Nếu tổng thu được là 2 hoặc nhỏ hơn, đề xuất 20 giờ công cho mỗi điểm ca sử dụng, nếu tổng là 3 hoặc 4 thì cần 28 giờ công cho mỗi điểm ca sử dụng. Khi tổng vượt quá 4, được khuyến cáo cần xem xét lại dự án và điều chỉnh các tham số ước lượng.
Ở đây, chúng ta sẽ thực hiện tính ước lượng nỗ lực theo cả 3 hướng này để tham khảo.
Theo cách tiếp cận của Schneider và Winters, chúng ta sẽ xem xét các yếu tố từ F1 đến F6, yếu tố nào có giá trị đánh giá lớn hơn 3 và yếu tố F7 đến F8, yếu tố nào có giá trị đánh giá nhỏ hơn 3. Căn cứ vào bảng 4.4, xét yếu tố từ F1 đến F6 thì có hai yếu tố F3 và F4 có giá trị đánh giá lớn hơn 3, yếu tố F7 đến F8
đều có giá trị đánh giá nhỏ hơn 3. Tổng tính được là 4 + 2 + (-2) = 4, như vậy sẽ cần 28 giờ công cho mỗi điểm ca sử dụng.
Thời gian cần hoàn thành dự án là:
Với 20 giờ công cho mỗi điểm ca sử dụng: 108.3 * 20 = 2166 (man-hours). Với 36 giờ công cho mỗi điểm ca sử dụng: 108.3 * 36 ≈ 3899 (man-hours). Với 28 giờ công cho mỗi điểm ca sử dụng: 108.3 * 28 ≈ 3032 (man-hours). Các đơn vị thông dụng khác là (man-week), (man-month). Chia số giờ (man-hours) cho 40 giờ/tuần sẽ được đơn vị (man-week). Ví dụ:
2166 / 40 ≈ 54 (man-week) 3899 / 40 ≈ 97.5 (man-week) 3032 / 40 ≈ 76 (man-week)
KẾT LUẬN
Như vậy, ước lượng tổng thể nói chung và ước lượng giá nói riêng cho một dự án phần mềm luôn là bài toán khó cho những người phát triển phần mềm. Và để triển khai một dự án phần mềm, thì bài toán đầu tiên là ước lượng giá và thời gian thực hiện dự án. Ước lượng không chính xác dễ gặp rủi ro và dẫn đến thất bại. Đây là một bài toán luôn đặt ra mỗi khi cần phát triển một dự án phần mềm và là một thách thức nói chung cho ngành công nghiệp phát triển phần mềm vì tính đa dạng và phức tạp của nó. Trong điều kiện phương pháp phát triển phần mềm hướng đối tượng phát triển mạnh mẽ chục năm lại đây, việc ước lượng các dự án phần mềm phát triển theo hướng này càng đòi hỏi có một phương pháp ước lượng thích hợp.
Đề tài đã nghiên cứu các phương pháp ước lượng dự án phần mềm, đặc biệt những phương pháp được quan tâm trong thời gian gần đây. Làm rõ cơ sở khoa học và thực tiễn của chúng, những kinh nghiệm áp dụng, so sánh những ưu và nhược điểm của mỗi phương pháp và đề xuất cải tiến cho trường hợp dự án phần mềm hướng đối tượng. Cụ thể, đã tìm hiểu được tổng quan về ước lượng dự án phần mềm cùng một số phương pháp ước lượng truyền thống. Và phần quan trọng nhất là nghiên cứu về phương pháp ước lượng điểm ca sử dụng cho phần mềm phát triển hướng đối tượng, đánh giá được ưu nhược điểm của phương pháp và đề xuất cải tiến phương pháp nhằm thu được những kết quả ước lượng chính xác hơn.
Trên cơ sở lý thuyết đó, tôi đã xây dựng một chương trình thử nghiệm cho phương pháp ước lượng điểm ca sử dụng và áp dụng để đánh giá một dự án đã cho nhằm trợ giúp cho việc triển khai các dự án phần mềm hướng đối tượng, đồng thời làm rõ những ưu điểm và hạn chế của phương pháp. Chương trình cho phép hỗ trợ người dùng đánh giá và tự động phân loại các yếu tố cần thiết để tính toán đưa ra kết quả ước lượng.
Do phương pháp ước lượng điểm ca sử dụng là một phương pháp thực nghiệm, và những đề xuất cải tiến ở đây dựa trên đánh giá chủ quan cá nhân nên cũng cần được kiểm nghiệm thực tế để kiểm chứng cho phương pháp.
Hướng phát triển tiếp theo là tăng tính năng tự động hóa và phân tích của chương trình, phân loại được lớp dự án, tăng thêm yếu tố lựa chọn theo từng lớp dự án,… nhằm thu được kết quả ước lượng chính xác hơn.
TÀI LIỆU THAM KHẢO
[1] SangEun Kim, William Lively and Dick Simmons, An Effort Estimation by UML Points in the Early Stage of Software Development, Article, 2006.
[2] Roy K. Clemmons, Project Estimation With Use Case Points, Diversified Technical Services, Inc, Article, February 2006.
[3] Parastoo Mohagheghi, Bente Anda, and Reidar Conradi, Effort Estimation of Use Cases for Incremental large-Scale Software Development, Proceedings of the International Conference on Software Engineering (ICSE’05), pp. 303-311, May 15-21 2005.
[4] Gennaro Costagliola and Genoveffa Tortora, Class Point: An Approach for the Size Estimation of Object-Oriented Systems, IEEE Transactions on Software Engineering, Vol. 31, No. 1, pp. 52-74, Jan. 2005.
[5] Nasib S. Gill and P.S. Grover, Software Size Prediction Before Coding, ACM SIGSOFT Software Engineering Notes, Vol. 29, No. 5, pp. 1-4, Article, September 2004.
[6] Shinji Kusumoto, Fumikazu Matukawa, Katsuro Inoue, Shigeo Hanabusa,
Yuusuke Maegawa, Estimating Effort by Use Case Points: Method, Tool and Case Study, 2004.
[7] Jonh Porter, Estimation with Use Cases: A simple and Effective Approach to Estimating Software Projects, EII Publication, 2002.
[8] International Function Point Users Group (IFPUG), Function Point Counting Practices Manual, Release 4.1.1, 2002.
[9] Gautam Banerjee, Use Case Points – An Estimation Approach, August 2001.
[10] G. Schneider and J. P. Winters, Applying Use Cases, Second Edition, Addison Wesley, 2001.
[11] Suresh Nageswaran, Test Effort Estimation Using Use Case Points, Article, 2001.
[12] David Garmus & David Herron, Function Point Analysic: Measurement Practices for Successful Software Projects, Paperback, Dec 2000.
[13] Barry W.Boehm, Software Cost Estimation with COCOMO II, Prentice – Hall, July 2000.
[14] Common Software Measurement International Consortium, COSMIC-FFP
Version 2.0, 2000. http://www.cosmicon.com/.
[15]Ian Watson, Applying Case-based Reasoning: Techniques for enterprise systems,
Morgan Kaufmann, 1997.
[16]Shyam R. Chidamber and Chris F. Kemerer, A Metrics Suite for Object Oriented Design, IEEE Transactions on Software Engineering, 20(6), pp. 476-493, June 1994.
[17] A.J. Albrecht, Function Point Analysis, Encyclopedia of Software Engineering, Vol.1, pp. 518-524, 1994.
[18] Agnar Aamodt and Enric Plaza: Case-based reasoning: Foundational issues, methodological variations and system approaches. AI Communication, Vol 7:39-59, 1994.
[19] Karner, Gustav, Resource Estimation for Objectory Projects, Objective Systems SF AB, 1993.
[20] Roger S.Pressman, Software Engineering – A Practitioner’s Approach, Third Edition, Mc Graw – Hill.Inc, 1992.
[21] C. Symons: Software Sizing and Estimating. John Wiley & Sons, 1991.
[22] Chistopher K.Resbeck and Roger C.Schank. Inside Case-based Reasoning,
Lawrence Erlbaum, 1989.
[23] V. R. Basili and K. Freburger, Programming measurement and estimation in the Software Engineering Laboratory, Journal of Systems & Software, 2, pp. 47-57, 1981.
[24] B. W. Boehm: Software Engineering Economics, Prentice Hall, 1981.
[25] Nguyễn Ngọc Bảo, Võ Văn Thành, Lê Việt Hà, Nguyễn Việt Hà, Ứng dụng Ontology trong mô hình ước lượng chi phí phần mềm sử dụng lập luận theo tình huống. Báo cáo hội thảo quốc gia lần thứ IX: Một số vấn đề chọn lọc của công nghệ thông tin và truyền thông, 06-2006.
PHỤ LỤC
P.1 Bảng chi tiết về trọng số và tham số ước lượng
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.1 Bảng tính toán điểm chức năng không được điều chỉnh
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) 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)
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 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