MỘT số kỹ THUẬT ước LƯỢNG dự án PHẦN mềm mềm

MỤC LỤC CHƯƠNG TỔNG QUAN VỀ ƯỚC LƯỢNG DỰ ÁN PHẦN MỀM 1.1 Cái nhìn ước lượng .6 1.2 Vai trò ước lượng dự án phần mềm 1.3 Ước lượng dự án phần mềm 1.4 Kỹ thuật ước lượng 1.5 Kế hoạch nguồn tài nguyên 11 1.6 Một số vấn đề ước tính dự án công nghệ thông tin .12 1.7 Qui tắc ước lượng theo kinh nghiệm DEC (và công ty lớn khác) 13 1.8 Kết luận ước lượng 14 CHƯƠNG PHƯƠNG PHÁP ƯỚC LƯỢNG ĐIỂM CHỨC NĂNG 16 2.1 Tổng quan phương pháp điểm chức 16 2.1.1 Giới thiệu 16 2.1.2 Tính hay ước tính ? .17 2.2 So sánh chung phương pháp dựa vào điểm chức 18 2.2.1 Xếp loại phương pháp ước tính FP .18 2.2.2 Ước tính từ lên từ xuống .19 2.2.3 Các phương pháp ước tính trực tiếp 20 2.2.4 Các phương pháp ước tính suy diễn 21 2.3 Các bước thực 21 2.3.1 Phân loại 22 2.3.2 Tính tổng UFP 26 2.3.3 Gán mức độ ảnh hưởng cho tất đặc trưng chung hệ thống .27 2.3.4 Tính giá trị yếu tố điều chỉnh 28 2.3.5 Tính tổng FP ứng dụng 29 CHƯƠNG MÔ HÌNH ƯỚC LƯỢNG COCOMO II 31 3.1 Giới thiệu mô hình COCOMO II 31 3.1.1 Mục đích người sử dụng COCOMO II 32 3.1.2 Mục đích mô hình COCOMO II 33 3.2 Các biểu thức ước lượng thời gian 34 3.3 Xác định kích cỡ 37 3.3.1 Đếm số dòng mã lệnh 37 3.3.2 Đếm điểm chức chưa điều chỉnh (UFP) 40 3.3.3 Mối liên hệ UFP SLOC 42 3.3.4 Tổng hợp mã mới, mã thích ứng mã tái sử dụng .44 3.3.5 Các hiệu ứng không tuyến tính việc tái sử dụng 44 3.3.6 Mô hình tái sử dụng 45 3.3.7 Hướng dẫn việc định lượng phần mềm thích ứng 47 3.3.8 Ước lượng việc bảo trì phần mềm .49 3.4 Ước lượng công sức 50 3.4.1 Các hệ số tỉ lệ 52 3.4.2 Các yếu tố 62 3.4.3 Các nhân tố người 64 3.4.4 Các nhân tố dự án 68 3.5 Ước lượng thời gian bảo trì dự án 71 3.5.1 Bảo trì phần mềm 72 3.5.2 Sử dụng COCOMO II để hỗ trợ việc định 73 3.6 Tổng kết mô hình COCOMO II 74 3.7 Ví dụ .76 CHƯƠNG 77 PHƯƠNG PHÁP ƯỚC LƯỢNG USE CASE POINT .77 4.1 Vai trò biểu đồ Use Case ước lượng phần mềm………………77 4.2 Giới thiệu phương pháp UCP .79 4.3 Các bước thực với phương pháp ước lượng UCP 80 4.4 Phân loại tác nhân phân loại UC .85 KẾT LUẬN .88 TÀI LIỆU THAM KHẢO 89 MỞ ĐẦU “Ước lượng dự án phần mềm” mở đầu giai đoạn lập kế hoạch quản lý dự án, công việc sử dụng kỹ thuật ước lượng, công cụ ước lượng kinh nghiệm người làm dự án để đưa kết luận về: o Kích cỡ dự án phần mềm phát triển mới, dự án phát triển bổ sung hay dự án bảo trì sản phẩm phần mềm tồn o Đưa thời gian để hoàn thành toàn dự án phát triển mới, bổ sung hay dự án bảo trì phần mềm o Đưa công sức (VD: Người/Tháng) để hoàn thành dự án phần mềm thực o Đưa chi phí ước tính để hoàn thành dự án phát triển dựa vào công sức để hoàn thành giá nhân công cộng với giá tài nguyên cần cho dự án cuối dựa vào mắt người ước lượng dự án môi trường phát triển Em theo đuổi lĩnh vực quản lý dự án, để chuẩn bị thâm nhập làm việc lĩnh vực quản lý dự án mà hoạt động ước lượng dự án Đó lý em nhận hoàn thành đồ án Tiến trình quản lý dự án phần mềm bắt đầu với lập kế hoạch dự án, hoạt động ước lượng Khi tiến hành ước lượng có điều đương nhiên phải chấp nhận mức độ bất trắc Ước lượng phần nhiều nghệ thuật khoa học ko nên tiến hành cách ngẫu nhiên Đã xuất vài kĩ thuật có ích để ước lượng thời gian công sức cho dự án phần mềm như: COCOMO, Function Points, Use Case Points, Top – Down, Bottom – Up Ước lượng giữ vị trí tảng cho hoạt động lập kế hoạch dự án khác, việc lập kế hoạch dự án đưa lộ trình cho kĩ nghệ phần mềm thành công nên có am hiểu để tiến hành công việc thiếu phần ước lượng Nội dung đề tài “Một số kỹ thuật ước lượng phần mềm”bao gồm chương: Tổng quan ước lượng dự án phần mềm Phương pháp ước lượng điểm chức Mô hình ước lượng COCOMO II Phương pháp ước lượng Use Case Point Đề tài trình bày dạng ngắn gọn, nhiều hạn chế Mọi ý kiến đóng góp xin liên hệ: Nguyễn Giang Nam, lớp K2A, Khoa công nghệ thông tin, Đại học Thái Nguyên E-mail: giangnamitc@yahoo.com Mobile: 0983983894 Em xin chân thành cám ơn Th.s Nguyễn Hồng Tân thầy cô thuộc môn Công nghệ phần mềm trực tiếp hướng dẫn, giúp đỡ em hoàn thành đề tài Thái nguyên, May 2008 Chương TỔNG QUAN VỀ ƯỚC LƯỢNG DỰ ÁN PHẦN MỀM 1.1 Cái nhìn ước lượng Ước lượng trình mang tính chất lặp Ngay giai đoạn xác định, để viết kế hoạch dự án ban đầu, bạn phải tiến hành ước lượng lần thứ Tuy nhiên, kinh nghiệm công ty phần mềm lớn cho thấy ước lượng giai đoạn thường sai số từ 50% đến 100% Sau lập kế hoạch giai đoạn phân tích, bạn phải xem lại ước lượng chỉnh lại kế hoạch dự án ban đầu thành kế hoạch dự án cuối Sang giai đoạn này, ước lượng bạn phải xác lên gấp đôi: sai số từ 25% đến 50% Sau hoàn thành thiết kế mức trung gian, bạn xét lại lần ước lượng Với hiểu biết thu vào lúc đó, sai số bạn phải giảm xuống 10% Mặc dầu không nói rõ, song giai đoạn nào, bạn cần chỉnh lại ước lượng có thêm hiểu biết dự án [14] Việc ước lượng tài nguyên, chi phí, lập lịch cho công sức phát triển phần mềm đòi hỏi phải có kinh nghiệm, thâm nhập vào thông tin lịch sử tốt dũng cảm sử dụng cách đo định lượng có liệu định lượng Ước lượng mang sẵn yếu tố rủi ro nhân tố làm tăng rủi ro Độ phức tạp dự án có ảnh hưởng mạnh tới tính bất trắc cố hữu có việc lập kế hoạch Có số cách đưa để định lượng độ phức tạp phần mềm, cách đo áp dụng mức thiết kế hay mã hóa khó dùng cho giai đoạn lập kế hoạch phần mềm giai đoạn có trước thiết kế mã hóa tồn Kích cỡ dự án nhân tố quan trọng khác ảnh hưởng tới độ xác tính hiệu ước lượng Mức độ cấu trúc dự án có ảnh hưởng lên rủi ro ước lượng [1] Việc có sẵn thông tin lịch sử xác định rủi ro ước lượng, thiết lập việc lập lịch để tránh khó khăn khứ toàn rủi ro thu lại Rủi ro đo mức độ bất trắc theo ước lượng định được thiết lập cho tài nguyên, chi phí lập lịch [1] 1.2 Vai trò ước lượng dự án phần mềm Mục tiêu việc lập dự án phần mềm cung cấp khuôn khổ cho phép nhà quản lí lập ước lượng hợp lí tài nguyên, chi phí lịch biểu Các ước lượng tiến hành bên khuôn khổ thời gian giới hạn lúc ban đầu dự án phần mềm cần cập nhật đặn tiến trình dự án Mục tiêu lập kế hoạch dự án đạt thông qua tiến trình phát thông tin để dẫn đến ước lượng hợp lí Ước lượng giữ vai trò quan trọng toàn trình phát triển dự án phần mềm: o Đưa số ước tính kích cỡ dự án, tài nguyên, công sức, chi phí lịch biểu o Mọi kết luận ứớc lượng yếu tố có ảnh hưởng trực tiếp đến thời gian hoàn thành dự án, kinh phí trì dự án hiệu suất công việc dự án o Dự đoán trước rủi ro, bất trắc trình phát triển giúp dự án vượt qua thời điểm khó khăn 1.3 Ước lượng dự án phần mềm Trong ngày đầu tin học, chi phí phần mềm phần trăm nhỏ toàn chi phí cho hệ thống dựa máy tính Một lỗi lầm lớn ước lượng chi phí phần mềm tương đối ảnh hưởng [1] Ngày nay, phần mềm yếu tố tốn nhiều hệ thống dựa máy tính Lỗi lầm ước lượng chi phí lớn tạo chênh lệch lợi nhuận thất thoát Việc bội chi thảm họa cho người phát triển Ước lượng chi phí công sức phần mềm chẳng khoa học xác Có nhiều tham biến: người, kĩ thuật, môi trường, trị ảnh hưởng tới chi phí chung phần mềm công sức cần để phát triển nó.Tuy nhiên việc ước lượng dự án phần mềm biến đổi từ nghệ thuật thành dãy bước hệ thống để đưa ước lượng với độ rủi ro chấp nhận Để đạt ước lượng chi phí công sức tin cậy, số tùy chọn nảy sinh:  Trì hoãn việc ước lượng tới giai đoạn sau dự án (hiển nhiên, đạt ước lượng xác 100% sau dự án hoàn tất!)  Dùng kĩ thuật phân rã tương đối đơn giản để sinh ước lượng chi phí công sức dự án  Phát triển mô hình kinh nghiệm cho chi phí công sức làm phần mềm  Thu hay nhiều công cụ ước lượng tự động Không may tùy chọn hấp dẫn, lại không thực tế Các ước lượng chi phí phải đưa “ngay từ đầu” Tuy nhiên phải thừa nhận đợi lâu biết nhiều, có khả phạm phải lỗi lầm trầm trọng ước lượng Ba tùy chọn lại có vị trí tương việc ước lượng dự án phần mềm Một cách lí tưởng, kĩ thuật tùy chọn nên áp dụng nối tiếp nhau, tùy chọn dùng phép kiểm tra chéo cho tùy chọn khác Các kĩ thuật phân rã lấy quan điểm “chia để trị” cho việc ước lượng dự án phần mềm Bằng cách phân rã dự án thành chức nhiệm vụ kĩ nghệ phần mềm có liên quan, việc ước lượng chi phí nỗ lực thực theo kiểu bước Các mô hình ước lượng theo kinh nghiệm dùng để bổ sung cho kĩ thuật phân rã đưa cách tiếp cận ước lượng tiềm có giá trị theo nghĩa Một mô hình dựa kinh nghiệm (dữ liệu lịch sử) có dạng: d = f(vi) Với d số giá trị ước lượng (như công sức, chi phí, thời hạn dự án) vi tham biến độc lập chọn lựa (như LOC hay FP ước lượng) Các công cụ tự động hóa cài đặt cho hay nhiều kĩ thuật phân rã hay mô hình kinh nghiệm Khi tổ hợp với giao diện người – máy tương tác, công cụ tự động hóa đưa tùy chọn hấp dẫn cho việc ước lượng Công cụ đưa mô tả đặc trưng tổ chức phát triển (như kinh nghiệm, môi trường) phần mềm cần phát triển Các ước lượng chi phí nỗ lực suy từ liệu Mỗi tùy chọn ước lượng chi phí phần mềm đứng vững tốt liệu lịch sử dùng cho ước lượng Nếu liệu lịch sử chi phí dựa tảng không vững Những nhà chuyên nghiệp công nghệ thông tin biết rằng, ước lượng chi phí ban đầu cho dự án công nghệ thông tin thường thấp ước lượng dựa yêu cầu chưa đầy đủ mơ hồ Do vậy, kết chi phí vượt hẳn so với ước lượng ban đầu Hơn công việc nhiều người thường phó thác cho người kế toán Ngược lại việc ước đoán chi phí có yêu cầu cao, nên nhà quản lý dự án cần đặt nặng vấn đề Dự án công nghệ thông tin thường phát triển công nghệ mới, cải tiến tiến trình kinh doanh Bất công nghệ mới, thường chưa sử dụng nên không kiểm tra trước (thiếu kinh nghiệm) Vấn đề rủi ro tránh Qua nhận định ta cần quan tâm nhiều đến việc quản lí chi phí 1.4 Kỹ thuật ước lượng Có ba kỹ thuật dùng để ước lượng: đánh giá chuyên gia, qui trình lịch sử công thức o Sử dụng đánh giá chuyên gia Giả sử bạn biết người có kinh nghiệm lập trình cho đơn thể sinh báo cáo Bạn gặp người với thiết kế chương trình sinh báo yêu cầu người ước lượng phải để lập trình cho thiết kế Sau khảo cứu thiết kế khoảng năm phút, người lập trình nhắm mắt lại năm phút (không phải ngủ, mà nhẩm tính), trả lời, “Mười lăm ngày" Đó đánh giá chuyên gia Ưu điểm phương pháp nhanh người hỏi thực chuyên gia, ước lượng xác đến ngạc nhiên Nhược điểm chỗ bạn cần tìm chuyên gia có kinh nghiệm lĩnh vực tương ứng, mà chuyên gia lại thường khó tìm Hơn nữa, độ xác phụ thuộc vào thời gian chuyên gia bỏ để đánh giá Ước lượng tin cậy được, chuyên gia lại giao cho người khác thực Ngoài ra, việc dựa vào ý kiến hiểu biết chủ quan số chuyên gia, điều nguy hiểm o Quy trình lịch sử Để khỏi phụ thuộc vào vài người làm cho ước lượng bạn có sở khoa học hơn, bạn nên lưu giữ quy trình lịch sử Bạn viết công việc cần để hoàn thành người chịu trách nhiệm Sau đó, bạn so sánh công việc cần đánh giá với công việc tương tự thực khứ tới ước lượng Như vậy, bạn cần chia dự án thành công việc thường hay lặp lại dễ so sánh Trong lập trình, việc sinh biểu mẫu đưa vào, sinh báo cáo, tính toán công thức phức tạp, v.v Trên thực tế, công ty thường có khuynh hướng xây dựng kiểu dự án tương tự Bạn tìm khối xây dựng sở tài liệu thời xây dựng khối theo kiểu để sau sử dụng lại Bạn ước lượng việc tái sử dụng xác việc viết lại Để so sánh xác hai công việc nhau, bạn cần để ý người thực việc công việc Thống kê công ty IBM DEC tỉ lệ hiệu suất đạt tới nhà chuyên môn giỏi 10  Các biểu thức mô hình Early - Design PM  A  Size E   EM i  PM Auto i 1  Biểu thức thời gian phát triển Phương trình giới thiệu phần 3.4 %   TDEV  C  ( PM NS ) F  SCED% 100 F  D  0.2  (E  B ) PMactual KSLOC EMi E ln(ước Chênh chưa điều lượng lệch chỉnh chưa điều ước lượng ln(PMactual) chỉnh) 1854.6 134.5 1.89 1.20 686.7 7.53 6.53 0.99 258.5 132.0 0.49 1.08 94.3 5.55 4.55 1.01 201.1 44.0 1.06 1.13 77.7 5.30 4.35 0.95 58.9 3.6 5.05 1.09 20.3 4.08 3.01 1.07 9661.0 380.8 3.05 1.18 3338.8 9.18 8.11 1.06 7021.3 980.0 0.92 1.16 2753.5 8.86 7.92 0.94 91.7 11.2 2.45 1.15 38.9 4.52 3.66 0.86 689.7 61.6 2.38 1.17 301.1 6.54 5.71 0.83 X= 0.96 A= 2.62 Bảng 3.28: Ví dụ điều chỉnh cục số A Ví dụ cho thấy rằng, thay sử dụng số A = 2.94 COCOMO II 2000, ta nên sử dụng số A = 2.62 để ước lượng dự án phần mềm môi trường tổ chức 75 3.7 Ví dụ Hãy ước lưọng xem phải cần thời gian công sức để phát triển dự án trung bình, có kích cỡ 100 KSLOC Giải Với dự án trung bình giá trị hệ số nhân công sức cho chừng 1.0 E = B + 0.01 × ∑SFj j=1 = 0.91 + 0.01 × (3.72 + 3.04 + 4.24 + 3.29 + 4.68) = 1.1 Công sức cần thiết để phát triển dự án là: n PM NS  A  Size E   EM i i 1 = 2.94 × (100)1.1 × = 465.96 (PM) Thời gian cần thiết để thực dự án là: TDEVNS = C × (PMNS)(D + 0,2 × (E - B)) = 3.67 × (465.96)(0.28 + 0.2 × (1.1 – 0.91)) = 25.89 (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 = 465.96 / 25.89 = 18 (người) Như dự án trung bình có kích cỡ 100 KSLOC cần khoảng 26 tháng với khoảng 18 nhân công để hoàn thành Chương trình bày phương pháp ước lượng Use Case Point 76 Chương PHƯƠNG PHÁP ƯỚC LƯỢNG USE CASE POINT 4.1 Vai trò biểu đồ Use Case ước lượng phần mềm Hiện nay, cách tiếp cận phát triển phần mềm hướng đối tượng sử dụng phổ biến Ngôn ngữ mô hình hóa thống (Unified Modeling Language – UML) sử dụng để thu thập yêu cầu phần mềm, phân tích, thiết kế phát triển phần mềm Biểu đồ UC công cụ mạnh để thu thập yêu cầu hệ thống Biểu đồ UC mối quan hệ tác nhân ca sử dụng hệ thống Ca sử dụng: ca sử dụng (Use Case – UC) mô tả tập hoạt động hệ thống theo quan điểm tác nhân (Actors) Nó mô tả yêu cầu hệ thống trả lời cho câu hỏi: hệ thống phải làm (What ?) Mục tiêu ca sử dụng trình phát triển phần mềm:  Mô tả yêu cầu chức hệ thống, kết trình khảo sát, nghiên cứu yêu cầu toán thoả thuận khách hàng, NSD hệ thống với người phát triển phần mềm  Làm sở để người phân tích viên hiểu, người thiết kế xây dựng kiến trúc, người lập trình cài đặt chức năng, người kiểm duyệt kiểm tra kết thực hệ thống Các ca sử dụng đóng vai trò quan trọng trình phát triển phần mềm, tất pha phân tích, thiết kế sau dựa vào ca sử dụng Như vậy, trình hướng dẫn ca sử dụng (use case driven process) cách hữu hiệu để mô hình hoá hệ thống với UML Tác nhân: Tác nhân (Actor) thực thể bên có tương tác với hệ thống, bao gồm người, vật, thiết bị hay hệ thống khác có trao đổi thông tin với hệ thống Nói cách khác, tác nhân đại diện cho người hay phận tổ chức mong muốn nhận thông tin (dữ liệu) câu trả lời từ ca sử dụng tương ứng 77 Xác định tác nhân Tác nhân phận bên hệ thống cộng tác chặt chẽ với hệ thống Nó đối tượng mà hệ thống phục vụ cần có để cung cấp liệu Do đó, nhiệm vụ trước tiên người phân tích xác định tác nhân Một kỹ thuật hỗ trợ để xác định tác nhân dựa câu trả lời câu hỏi sau:  Ai sử dụng chức hệ thống?  Ai cần hỗ trợ hệ thống để thực công việc hàng ngày?  Ai quản trị, bảo dưỡng để đảm bảo cho hệ thống hoạt động thường xuyên?  Hệ thống quản lý, sử dụng thiết bị nào?  Hệ thống cần tương tác với phận, hệ thống khác?  Ai hay quan tâm đến kết xử lý hệ thống? Xác định ca sử dụng Bước xác định ca sử dụng dựa tài liệu đặc tả yêu cầu, thông qua tác nhân Tương tự trên, trả lời câu hỏi sau để tìm ca sử dụng:  Nhiệm vụ tác nhân gì?  Tác nhân cần phải đọc, ghi, sửa đổi, cập nhật, hay lưu trữ thông tin hay không?  Những thay đổi bên hệ thống tác nhân có cần phải thông báo cho hệ thống hay không?  Những tác nhân cần thông báo thay đổi hệ thống?  Hệ thống cần có đầu vào / nào? Từ đâu đến đâu? Nói chung, việc xác định đầy đủ UC tác nhân vấn đề khó khăn Biểu đồ UC mô tả chức hệ thống phần mềm cần xây dựng mà làm sở để nhóm quản lý dự án đưa ước lượng quan trọng cho trình lập kế hoạch dự án 78 4.2 Giới thiệu phương pháp UCP Những ước lượng chi phí lịch biểu dự án phần mềm thường dựa vào việc dự báo kích cỡ hệ thống tương lai Thật không may, phần mềm thường mang tiếng thiếu xác việc ước lượng chi phí lịch biểu Những ước lượng công sức thường bao hàm nhiều phần tử tính không xác Những ước lượng giai đoạn sớm đảm bảo tin cậy thường khó đạt nguyên nhân thiếu thông tin chi tiết đầy đủ hệ thống phần mềm cần xây dựng tương lai giai đoạn đầu dự án Tuy nhiên, ước lượng xác đầy đủ giai đoạn đầu dự án có vai trò quan trọng cho việc thiết lập hợp đồng xác định tính khả thi dự án Những mô hình ước lượng chi phí trước xem kích cỡ phần mềm tham số đầu vào quan trọng sau sử dụng tập nhân tố điều chỉnh để tính toán ước lượng tổng công sức phát triển Khi phát triển phần mềm theo phương pháp hướng đối tượng, Use Cases (UCs) mô tả yêu cầu chức hệ thống Mô hình UC sử dụng để dự báo kích cỡ hệ thống phần mềm tương lai pha phát triển hệ thống Những mô hình ước lượng phần mềm SLOC, COCOMO II, phương pháp xác định kích cỡ Function Point Analysis (FPA) sử dụng rộng rãi hiệu kỹ nghệ phần mềm, thực tế tiếp cận hạn chế Việc đếm điểm chức đòi hỏi kiến thức chuyên gia hỗ trợ Bởi khó khăn việc ước lượng theo phương pháp SLOC, FP, COCOMO… hệ thống phần mềm ngày thường phát triển theo phương pháp hướng đối tượng sử dụng ngôn ngữ Unified Modeling Language (UML) Năm 1993, Gustav Karner đưa phương pháp Use Case Points sử dụng để xác định kích cỡ ước lượng dự án phát triển theo phương pháp hướng đối tượng Phương pháp mở rộng từ phương pháp phân tích điểm chức phương pháp MkII FPA Phương pháp ước lượng UCP tính toán công sức phát triển phần mềm theo đơn vị person – hours dựa vào biểu đồ UC nơi mô tả xác quán yêu cầu chức hệ thống Các UC giả định chúng đưa từ tập hỗn độn chức năng, sau chi tiết chuẩn hóa để có 10 – 12 giao dịch Phương pháp UCP trước sử dụng phổ biến số dự án cỡ nhỏ Cho tới gần đây, cách tiếp cận phát triển phần mềm theo phương pháp tăng trưởng tiến hóa trở lên quan trọng Ta thấy 79 phương pháp UCP có ưu điểm đáng kể, để có ước lượng xác ta cần phải xem xet tới nhân tố ảnh hưởng nhân tố kỹ thuật, nhân tố môi trường, phân loại UC tác nhân biểu đồ UC 4.3 Các bước thực với phương pháp ước lượng UCP Một số giả định phương pháp UCP Để khai thác sử dụng hiệu phương pháp UCP, người dùng phải nắm vững quy trình phát triển phần mềm theo phương pháp hướng đối tượng, có kiến thức ngôn ngữ UML cách xây dựng biểu đồ UC Trong chương này, đưa việc sử dụng phương pháp UCP không đưa vào chi tiết làm để xây dựng biểu đồ UC [4] Phương pháp ước lượng UCP thực qua bước sau đây: Bước 1: Xác định trọng số tác nhân chưa điều chỉnh (Unadjusted Actors Weight – UAW) Đây bước phương pháp UCP, bước ta thực việc phân lớp tác nhân Các tác nhân biểu đồ UC hệ thống phân chia thành lớp: tác nhân đơn giản ( Simple Actors), tác nhân lớp trung bình ( Average Actors) tác nhân lớp phức tạp (Complex Actors) Song song với việc phân lớp ta gán trọng số cho tác nhân Việc phân lớp gán trọng số tác nhân thực theo bảng sau đây: 80 Lớp tác nhân Mô tả Trọng số Đây tác nhân có giao tiếp với hệ thống qua API Simple Actors Đây tác nhân xác định qua đặc trưng sau: - Tác nhân tương tác với hệ thống qua số giao thức HTTP, FTP, giao thức định nghĩa người dùng Average Actors - Tác nhân lưu trữ CSDL, file hệ quản trị CSDL Tác nhân tương tác với hệ thống qua GUI Complex Actors Bảng 4.1: Phân loại tác nhân gán trọng số cho tác nhân Tổng trọng số tác nhân chưa điều chỉnh tính cách đếm số tác nhân loại nhân với trọng số tương ứng cộng tổng kết thao công thức 4.1 UAW=  ( # Actors* wf) (4.1) Bước 2: Phân loại xác định trọng số cho UC chưa điều chỉnh ( UUCW) Tại bước ta tiến hành đếm gán trọng số cho UC, UC phân thành lớp Những UC đơn giản (Simple UC) có không kịch giao dịch, UC trung bình (Average UC) có từ đến giao dịch, UC phức tạp ( Complex UC) có từ giao dịch trở lên Chi tiết phần loại gán trọng số cho UC mô tả bảng 4.2 Lớp UC Mô tả Trọng số Simple UC Đây UC có không kịch Average UC Đây UC có từ tới kịch 10 Complex Actors Đây UC có từ kịch trở lên 15 Bảng 4.2: Phân loại gán trọng số cho UC 81 Một cách khác để phân lớp UC dựa vào phân tích lớp UC đơng giản UC nhỏ lớp, UC trung bình có từ đến 10 lớp, UC phức tạp có lớn 10 lớp Giá trị tổng trọng số UC chưa điều chỉnh tính theo công thức 4.2 UUCW=  ( #UCs* wf) (4.2) Bước 3: Xác định số điểm UC chưa điều chỉnh (Unadjusted Use Case Point – UUCP) cách tính tổng UAW với UUCW theo công thức 4.3 UUCP = UAW + UUCW (4.3) Bước 4: Đưa nhân tố kỹ thuật Phương pháp đưa việc tính toán nhân tố điều chỉnh kỹ thuật phương pháp FPA, hệ số nhân nhân tố môi trường để định lượng yêu cầu phi chức hệ thống phần mềm Các nhân tố kỹ thuật môi trường có ảnh hưởng tới hiệu suất sản phẩm ảnh hưởng có giá trị từ đến Giá trị nhân tố gần có nghĩa không ảnh hưởng, giá trị gần có nghĩa ảnh hưởng mức độ trung bình, gần ảnh hưởng mạnh tới hiệu suất sản phẩm Có 13 nhân tố kỹ thuật bảng 4.3 sau đưa trọng số (Weight) mô tả chúng 82 T1 Nhân tố kỹ thuật Hệ thống phân tán T2 Thời gian phản hồi T3 Hiệu người sử dụng Hiệu người dùng nào? T4 T5 Xử lý bên phức tạp Mã dùng lại Tiến trình xử lý bên có phức tạp không? Mã nguồn có cần sử dụng lại không? T6 Dễ cài đặt 0.5 Hệ thống dàng cài đặt không? T7 Tính dễ sử dụng 0.5 T8 Khả tiện lợi Hệ thống có thân thiện với người dùng không? Khách hàng triển khai phần mềm nhiều hệ khác không? T9 Dễ thay đổi Weight Mô tả Hệ thống có kiến trúc phân tán hay tập trung? Máy khách có yêu cầu hời gian phản hồi nhanh không? Thời gian phản hồi có phải yêu cầu quan trọng không? Hệ thống thay đổi, cấp hay không? Khách hàng có yêu cầu nhiều người sử dụng hệ thống thời điểm hay không? T10 Khả thức đồng thời T11 Độ an toàn Hệ thống có yêu cầu đảm bảo độ an toàn không? T12 Truy nhập trực tiếp tới tầng thứ T13 Việc hướng dẫn sử dụng Việc hướng dẫn cho người sử dụng co phức tạp không? Bảng 4.3: Các nhân tố kỹ thuật Bước 5: Tính giá trị Tfactor Ta gán mức độ ảnh hưởng nhân tố kỹ thuật tương ứng với giá trị từ đến 5, sau nhân với trọng số tương ứng nhân tố kỹ thuật tính tổng kết ta giá trị Tfactor theo công thức 4.4 13 Tfactor = Ti * vi (4.4) i 1 Trong vi giá trị, Ti trọng số nhân tố kỹ thuật tương ứng 83 Bước 6: Tính nhân tố độ phức tạp kỹ thuật (Technical Complex Factor – TCF) TCF=0.6 + (0.1*Tfactor) (4.5) Bước 7: Đưa nhân tố môi trường ( Environmental Factor – EF) Ta đưa nhân tố môi trường, nhân tố có trọng số (Weight) mức độ ảnh hưởng tương ứng giá trị từ đến mô tả bảng 4.4 Nhân tố môi trường Weight Mô tả E1 Việc hiểu rõ ràng dự án 1.5 Tất thành viên dự án có hiểu rõ dự án thực hay không? E2 Kinh nghiệm ứng dụng 0.5 Kinh nghiệm làm ứng dụng nào? E3 Kinh nghiệm lập trình hướng đối tượng Những người tham gia dự án có kinh nghiệm phát triển dự án theo phương pháp hướng đối tượng? E4 Khả nhóm phân tích 0.5 Những người nhóm phân tích nào, có đủ lực hiểu biết lĩnh vực vấn đề hay chưa? E5 Động thúc đẩy Động phát triển dự án nào? E6 Sự ổn định yêu cầu phần mềm Khách hàng có hay thay đổi yêu cầu không? E7 Người làm Part – time -1 Có người làm Part – time hay không? E8 Độ khó ngôn ngữ lập trình -1 Sử dụng ngôn ngữ lập trình phức tạp không? Bảng 4.4: Các nhân tố môi trường 84 Bước 8: Tính giá trị Efactor Ta gán mức độ ảnh hưởng nhân tố môi trường tương ứng với giá trị từ đến 5, sau nhân với trọng số tương ứng nhân tố môi trường tương ứng tính tổng kết ta giá trị Efactor theo công thức 4.6 Efactor =  Ei * vi (4.6) i 1 Trong vi giá trị, Ei trọng số nhân tố môi trường tương ứng Bước 9: Tính nhân tố môi trường (Environmental Factor – EF) theo công thức 4.7 sau EF=1.4 + ( -0.3*Efactor) (4.7) Bước 10: Tính tổng điểm UC điều chỉnh ( AUCP – Adjusted Use Case Points) theo công thức 4.8 AUCP= UUCP*TCF*EF (4.8) Bước 11: Ta tính công sức để phát triển sản phẩm theo đơn vị đo person – hours Theo Karner, điểm UC tương ứng công sức phát triển 20 person hours, ta việc nhân giá trị AUCP với 20 ta tổng công sức cần thiết để phát triển Sharks theo kinh nghiệm số điểm UC từ 15 đến 30 Schneider Winters đưa nhận xét số để thưc điểm UC phụ thuộc vào nhân tố môi trường ổn định dự án 4.4 Phân loại tác nhân phân loại UC Để hiểu rõ áp dụng hiệu phương pháp UCP, ta xây dựng công cụ ước lượng tự động theo phương pháp Trước tiên để xây dựng ứng dụng theo phương pháp UCP, ta phải tiến hành tìm hiểu biểu đồ UC để phân lớp tác nhân UC thành mức đơn giản, trung bình phức tạp Việc phân lớp thảo luận kỹ sau Sau phân lớp tác nhân UC, ta tiến hành đưa thông số kỹ thuật môi trường để gán giá trị cho nhân tố Giá trị nhân tố mức độ ảnh hưởng chúng tới phần mềm cần xây dựng Sau ta mô tả bàn luận kỹ tới việc phân lớp tác nhân UC 85 Phân loại tác nhân Đây nhiệm vụ áp dụng phương pháp ước lượng UCP Như đề cập phần 4.3, trọng số tác nhân phụ thuộc vào giao diện tác nhân với hệ thống Nhưng thực tế biểu đồ UC mô tả tên tác nhân Vì vậy, ta sử dụng bước sau để tiến hành phân loại tác nhân: Bước 1: Phân lớp tác nhân dựa vào tên chúng Thông thường tác nhân người hệ thống khác có ảnh hưởng tới hệ thống phần mềm ta xây dựng Khi tác nhân người chúng chúng mức độ đơn trung bình phức tạp Khi tác nhân hệ thống chúng mức độ đơn giản trung bình Do vậy, dựa vào tên tác nhân ta phải xác định chúng người hệ thống Sau danh sách từ khóa, chẳng hạn: từ khóa “system” hay “server” thể tác nhân hệ thống Ngoài ra, số từ khóa khác “application”, “tool” hệ thống Bước 2: Phân lớp dựa vào từ khóa mô tả UC Ta tập trung vào việc mô tả UC theo kịch hay luồng kiện, ta đưa loại từ khóa để phân biệt dạng tác nhân Chẳng hạn, danh sách từ khóa cho tác nhân phức tạp như: “GUI”, “buttom”…Theo kỹ sư Hitachi Systems & Services có loại từ khóa sau [5]: - Từ khóa cho tác nhân mức đơn giản: request, send, inform - Từ khóa cho tác nhân mức trung bình (system): message, mail, send - Từ khóa cho tác nhân mức độ trung bình (person): command, text, input, GUI - Từ khóa cho tác nhân mức độ phức tạp: enter, button, press, push, select, show, GUI, window Bước 3: Phân lớp tác nhân dựa vào liệu kinh nghiệm Tại bước mà ta chưa phân loại tác nhân, ta dựa vào mô hình UC dựa vào kinh nghiệm dự án ước lượng khứ Phân loại UC Độ phức tạp UC phụ thuộc vào số kịch số giao dịch chúng Vì ta tập trung vào luồng kiện UC Một thực tế chuẩn để mô tả UC Một cách đơn giản ta đếm số kịch UC Theo 86 Jacobson UC bao hàm tập hành động, hành động giao dịch UC Có loại tương tác: (1) tác nhân gửi yêu cầu liệu tới hệ thống, (2) Hệ thống kiểm tra yêu cầu liệu, (3) Hệ thống chuyển trạng thái (4) Hệ thống đáp ứng yêu cầu tác nhân [5] Nếu luồng kiện, việc phân loại UC phải dựa vào kinh nghiệm thành viên tham gia ước lượng dự án 87 KẾT LUẬN Kiến thức thu Cuốn đồ án “Một số kỹ thuật ước lượng phần mềm” đề cập, giới thiệu tổng quan vài kỹ thuật sử dụng để ước lượng dự án phần mềm Hoàn thành đồ án này, em nghiên cứu lĩnh vực quản lý dự án phần mềm mà ước lượng phần mềm tiến trình Kỹ o Nghiên cứu đề tài này, giúp em rèn luyện, nâng cao kỹ phân tích, thu thập, thống kê yêu cầu dự án phần mềm o Phân tích dự án thực tế cách phối hợp phương pháp Function Point mô hình COCOMO II, khai thác công cụ ước lượng tự động Costar Demo 7.0 để đưa báo cáo nghiệp vụ Hạn chế Do bị giới hạn thời gian, hiểu biết, mức độ khó tiếp cận đề tài tình hình quản lý dự án công nghệ thông tin Việt Nam nhiều hạn chế dẫn đến nguồn tài liệu “ước lượng dự án phần mềm” chưa nhiều, mà đề tài “Một số kỹ thuật ước lượng dự án phần mềm”có thể nhiều hạn chế chưa hoàn toàn đầy đủ Trong thời gian em tiếp tục phát triển đề tài xây dựng công cụ tích hợp kỹ thuật ước lượng nghiên cứu phát triển thêm kỹ thuật Em xin chân thành cảm ơn Th.s Nguyễn Hồng Tân thầy cô thuộc môn công nghệ phần mềm hướng dẫn, giúp đỡ em hoàn thành đề tài Thái Nguyên, 13 May 2008 Sinh viên Nguyễn Giang Nam 88 TÀI LIỆU THAM KHẢO [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] Roger S Pressman, Người dịch: Ngô Trung Việt, Kĩ nghệ phần mềm, NXB Giáo dục, 2001 COCOMO II Model Definition Manual Lê Đức Trung, Công nghệ phần mềm, NXB Khoa học kỹ thuật, 2002 Phương pháp quản lý dự án công nghệ thông tin Bài giảng nhập môn công nghệ phần mềm, ĐH BKHN 2001 Abbas HeydarNoori , Function Point Analysis Function Points Analysis, Training Course Instructor: David Longstreet,David@SoftwareMetrics.Com www.SoftwareMetrics.Com Longstreet Consulting Inc – October 2004 Function Point Analysis for Software Enhancement © Copyright 2001, NESMA All rights reserved The Netherlands Software Metrics Users Association (NESMA), formerly NEFPUG Barry Boehm Software engineering economics Englewood Cliffs, NJ:Prentice-Hall, 1981 ISBN 0-13-822122-7 Barry Boehm, et al Software cost estimation with Cocomo II (with CD-ROM) Englewood Cliffs, NJ:Prentice-Hall, 2000 ISBN 0-13026692-2 Stan Malevanny Case Study: Software Project Cost Estimates Using COCOMO II Model, 2005 Shinji Kusumoto, Fumikazu Matukawa, Katsuro Inoue, Shigeo Hanabusa, Yuusuke Maegawa, Estimating Effort by Use Case Points: Method, Tool and Case Study, Toyonaka, Osaka, 560-8531 Japan Bente Anda, Hans Christian Benestad and Siw Elisabeth Hove, A Multiple-Case Study of Software Effort Estimation based on Use Case Points, Simula Research Laboratory, P.O Box 134, NO–1325 Lysaker, Norway Parastoo Mohagheghi, Bente Anda, Reidar Conradi, Effort Estimation of Use Cases for Incremental Large-Scale Software Development, Norway Tài liệu quản lý dự án, (sưu tầm) Ngôn ngữ mô hình thống UML (sưu tầm) www.SoftstarSystem.com 89 [...]... việc ước lượng là chia nhỏ Kinh nghiệm, thống kê cũng rất có ích Nếu công việc được chia thành những phần nhỏ hơn và bạn tính toán ước lượng cho từng phần việc nhỏ, một số phần sẽ có thể được ước lượng thừa, một số phần khác bị ước lượng thiếu Cuối cùng bạn phải lấy trung bình - và đó cũng là điểm duy nhất có vấn đề Trong các chương tới chúng ta sẽ nghiên cứu về các kỹ thuật ước lượng một dự án phần mềm. .. 1.6 Một số vấn đề trong ước tính dự án công nghệ thông tin Mặc dù có nhiều công cụ, kĩ thuật hỗ trợ cho việc ước lượng chi phí dự án, nhiều dự án CNTT vẫn chưa ước lượng được chi phí chính xác, đặc biệt khi có công nghệ mới hay phát triển phần mềm Tom De Marco, một tác giả nổi tiếng về phát triển phần mềm đề nghị bốn nguyên nhân dẫn đến không chính xác khi ước lượng và những cách để khắc phục nó o Ước. .. phục nó o Ước lượng dự án phần mềm lớn là công việc phức tạp đòi hỏi phải có nhiều nỗ lực, quyết tâm Nhiều điều phải ước lượng trước khi hiểu rõ đầy đủ những yêu cầu của hệ thống Khi dự án có yêu cầu phát triển một số phần mềm phức tạp, phải có được những ước lượng chi phí theo thứ tự và ngân sách, dĩ nhiên là ít chính xác, có thể lần ước lượng sau ít hơn lần trước Điều quan trọng là ước luợng ở những... nhau, người quản lí dự án phải giải thích được những nhân tố cho ước lượng đó o Những người phát triển những phần mềm khi ước giá thường thiếu kinh nghiệm để ước lượng những dự án lớn, do đó gây ra thiếu chính xác Do vậy, nếu công ty lưu trữ và khai thác được những dữ liệu của những dự án đã thực hiện, thì sẽ hỗ trợ nhiều cho việc cải tiến ước lượng chi phí dự án o Con người có những đánh giá cao thấp... kích thước của ứng dụng mới tương tự 2.2.4 Các phương pháp ước tính suy diễn Các phương pháp này, cũng được biết đến như các phương pháp mô hình thuật toán Cung cấp một hoặc nhiều thuật toán biến đổi để tạo ra sự ước tính kích thước phần mềm như hàm của nhiều biến số liên quan với một số thuộc tính của phần mềm Các phương pháp này có mối tương quan với quá trình phân tách  Bằng cách phân tách một ứng... trong quá trình xây dựng một sản 14 phẩm Sự kiện mốc cho phép ta dừng lại, tính toán xem cần bao lâu để đạt tới đó và ước lượng lại ngày tháng cho các sự kiện mốc tiếp theo dựa trên kinh nghiệm đã có Đừng để bất kỳ ai ràng buộc bạn vào một thời hạn không thể chấp nhận được (hãy chỉ rõ cho cấp quản lý định nghĩa về từ ước lượng .) o Ước lượng vẫn còn là một nghệ thuật Không tồn tại phần mềm hay công cụ... đoạn sớm của dự án 34 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ì... 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à: PM NS  2.94  (100)1.15  586.81 (người-tháng) Tiếp tục với ví dụ trên,... triển phần mềm, cần phải ước lượng cả chi phí phát triển phần mềm lẫn mô tả sơ lược về các chi tiêu trong vòng đời của 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: Ví dụ, cần bao nhiêu người tham gia vào các giai đoạn sớm, giữa và cuối của một dự án phần mềm? Bao nhiêu công sức, chi phí và thời gian cần bỏ ra để đạt được các cột mốc quan trọng của dự án? ... đị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: Có rất nhiều nhân tố không thể tránh khỏi, ảnh hướng tới thời gian và chi phí của dự án Một ví dụ về các nhân tố đó là khối lượng phần mềm mà dự sẽ phát triển và tái sử dụng Các mô hình lượng giá sẽ giúp