Từ phần mô tả chi tiết từng ca sử dụng trong phần 4.2.2 Yêu cầu hệ thống, chúng ta có thể phân loại tác nhân và ca sử dụng như sau:
Từ những mô tả trong phần 4.2.2 mục b, chúng ta thấy tất cả các tác nhân này đều tương tác với hệ thống thông qua giao diện người dùng và theo cách xác định để phân loại tác nhân thì các tác nhân này thuộc loại phức tạp với trọng số là 3. Các tác nhân kèm phân loại được thống kê trong bảng sau:
Tác nhân Kiểu tác nhân Trọng số
Customer Phức tạp 3
Member Phức tạp 3
NonMember Phức tạp 3
Assistant Phức tạp 3
Bảng 4.1 Bảng thống kê phân loại tác nhân của dự án iCoot
Từ đó, chúng ta tính được trọng số tác nhân chưa điều chỉnh:
UAW = 4 * 3 = 12 (I)
Dựa vào mô tả chi tiết từng ca sử dụng trong phần 4.2.2, chúng ta xác định được số thao tác có trong từng ca sử dụng, từ đó phân loại các ca sử dụng này theo tiêu chí đã được trình bày ở trên (phần 3.3.2). Có thể phân loại ca sử dụng theo 3 tiêu chí là: dựa vào số thao tác có trong ca sử dụng, dựa vào số lớp phân tích và dựa vào giao diện người dùng cùng số lượng thực thể dữ liệu. Ở đây,
phân loại ca sử dụng theo số thao tác có trong ca sử dụng và được thống kê trong bảng 4.2:
Ca sử dụng Số thao tác Phân loại Trọng số
U1:Browse Index 3 Đơn giản 5
U2:View Results 2 Đơn giản 5
U3:View CarModel Details 4 Trung bình 10
U4:Search 6 Trung bình 10
U5:Log On 7 Trung bình 10
U6:View Member Details 4 Trung bình 10
U7:Make Reservation 7 Trung bình 10
U8:View Rentals 2 Đơn giản 5
U9:Change Password 9 Phức tạp 15
U10: View Reservations 3 Đơn giản 5
U11:Cancel Reservation 6 Trung bình 10
U12:Log Off 4 Trung bình 10
U13:Look for CarModels 1 Đơn giản 5
Bảng 4.2 Bảng thống kê phân loại ca sử dụng của dự án iCoot
Từ bảng 4.2, chúng ta tính được trọng số ca sử dụng chưa điều chỉnh:
UUCW = 5 * 5 + 7 * 10 + 1 * 15 = 25 + 70 + 15 = 110 (II)
Từ (I) và (II), chúng ta tính được Điểm ca sử dụng chưa điều chỉnh:
UUCP = UAW + UUCW = 12 + 110 = 122 (III)
Tiếp đó, chúng ta xét đến yếu tố phức tạp kỹ thuật (TCF) và yếu tố phức tạp môi trường (ECF). Các yếu tố này được gán theo cảm tính của đội phát triển (hoặc người thực hiện ước lượng) nên phụ thuộc nhiều vào đội phát triển cụ thể. Trong trường hợp dự án iCoot, cần chú ý đến yêu cầu phi chức năng được mô tả trong mục (g) phần 4.2.2. Các yếu tố này có thể được đánh giá như 4.3:
Yếu tố Mô tả Trọng số Đánh giá Kết quả
T1 Hệ thống phân tán 2 5 10
lượng hoặc đáp ứng T3 Hiệu quả 1 5 5 T4 Xử lý phức tạp bên trong 1 3 3 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