Một số kỹ thuật ước lượng dự án và đánh giá phần mềm

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ  TRẦN KHÁNH DUNG MỘT SỐ KỸ THUẬT ƯỚC LƯỢNG DỰ ÁN VÀ ĐÁNH GIÁ PHẦN MỀM LUẬN VĂN THẠC SĨ NGƯỜI HƯỚNG DẪN KHOA HỌC PGS.TS:ĐẶNG VĂN ĐỨC Hà Nội - 2007 MỤC LỤC MỞ ĐẦU CHƢƠNG TỔNG QUAN VỀ ƢỚC LƢỢNG DỰ ÁN PHẦN MỀM VÀ ĐÁNH GIÁ CHẤT LƢỢNG PHẦN MỀM 1.1 Ƣớc lƣợng dự án phần mềm 1.1.1 Ƣớc lƣợng kích cỡ (LOC & FP) 1.1.2 Ƣớc lƣợng công sức 12 1.1.3 Ƣớc lƣợng tài nguyên 14 1.2 Đánh giá chất lƣợng phần mềm 16 1.2.1 Các nhân tố chất lƣợng phần mềm 16 1.2.2 Đánh giá thơng qua tính đắn 19 1.2.3 Đánh giá thơng qua tần suất bảo trì 19 1.2.4 Đánh giá thông qua tính tồn vẹn 20 1.2.5 Đánh giá dựa khả tiếp cận ngƣời dùng 20 CHƢƠNG KỸ THUẬT ƢỚC LƢỢNG DỰ ÁN PHẦN MỀM 21 2.1 Phƣơng pháp Function Points 21 2.1.1 Giới thiệu 21 2.1.2 Tính hay ƣớc tính 23 2.1.3 Mơ hình điểm chức 23 2.1.4 Các bƣớc thực 29 2.1.5 Thí dụ áp dụng phƣơng pháp Function Points 36 2.2 Phƣơng pháp Use Case Points 37 2.2.1 Giới thiệu phƣơng pháp UCP 37 2.2.2 Vai trò biểu đồ Use Case ƣớc lƣợng phần mềm 38 2.2.3 Các bƣớc thực với phƣơng pháp ƣớc lƣợng UCP 40 2.2.4 Thí dụ áp dụng phƣơng pháp UCP 45 2.3 Các mơ hình ƣớc lƣợng dự án phần mềm 47 2.3.1 Tổng quan mô hình ƣớc lƣợng kinh nghiệm 47 2.3.2 Mơ hình ƣớc lƣợng COCOMO (Contructive Cost Model) 48 2.3.3 Mơ hình ƣớc lƣợng Putnam 87 2.4 Công cụ ƣớc lƣợng tự động 89 CHƢƠNG KỸ THUẬT ĐÁNH GIÁ CHẤT LƢỢNG PHẦN MỀM 92 3.1 Độ đo chất lƣợng phần mềm 92 3.2 Khoa học phần mềm HALSTEAD 93 3.3 Đo độ phức tạp Thomas McCabe 95 3.4 Độ tin cậy phần mềm 96 3.5 Cách tiếp cận bảo đảm chất lƣợng phần mềm 97 CHƢƠNG PHÁT TRIỂN CHƢƠNG TRÌNH ỨNG DỤNG 100 4.1 Mục tiêu 100 4.2 Tóm lược sở khoa học 100 4.2.1 Các bước tính Function Points chương trình 100 4.2.2 Các bước tính Use Case Points chương trình 104 4.3 Cài đặt 105 KẾT LUẬN 108 TÀI LIỆU THAM KHẢO 109 PHỤ LỤC 110 DANH MỤC CÁC KÝ HIỆU THUẬT NGỮ VIẾT TẮT COCOMO FP KSLOC LOC PM IFPUG FPA EI EO EQ EF ILF ELF SLOC SQA SPR SMPEEM SMI TCF UUCP UAW UCP UUCPW UFP VAF WBS Contructive Cost Model Function Points Thousand of Source Line Of Code Line Of Code Person-Month Internatinal Function Point Users Group Function Point Analysis External Input External Output External Query Environmental Factor Internal Logical File External Logical File Source Line Of Code Software Quality Assurance Hiệu suất phần mềm Mơ hình đánh giá nỗ lực dự án bảo trì phần mềm Chỉ số chín muồi phần mềm Technical Complex Factor Unadjusted Use Case Point Unadjusted Actors Weight Use Case Points Unadjusted Use Case Point Weight Unadjusted Function Points Value Adjustment Factor Work Breakdown Structure MỞ ĐẦU Mặc dù việc nghiên cứu chủ đề quan tâm nhiều giới, Việt Nam nghiên cứu ứng dụng bước đầu Thực vậy, nhu cầu ước lượng tốt dự án phần mềm để tránh rủi ro vấn đề xúc công ty sản xuất phần mềm, tổ chức thực dự án phần mềm Việc định giá cho phần mềm vậy, cần có đánh giá xác dựa chất lượng thực tế phần mềm Tiến trình quản lý dự án kỹ nghệ phần mềm bắt đầu với tập hoạt động gọi chung lập kế hoạch dự án Hoạt động hoạt động ước lượng Người lập kế hoạch dự án phần mềm phải ước lượng ba điều trước dự án bắt đầu: dự án kéo dài bao lâu, cần nỗ lực người cần tham gia Bên cạnh đó, người lập kế hoạch phải dự kiến tài nguyên (phần cứng phần mềm) cần tới rủi ro dự án Như vậy, dự án phần mềm lập kế hoạch, cần phải đưa ước lượng cơng sức người cần có, thời hạn dự án theo ngày tháng chi phí dự án Những việc tiến hành nào? Trong nhiều trường hợp ước lượng thực cách dùng kinh nghiệm qúa khứ xem hướng dẫn Nếu dự án giống kích cỡ chức với dự án khứ dự án địi hỏi xấp xỉ khối lượng công sức, khoảng thời gian, chi phí dự án cũ Nhưng điều xảy dự án mở “miền đất mới” Khi riêng kinh nghiệm khứ khơng đủ [4] 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 Việc bội chi thảm hoạ cho người phát triển Để giải vấn đề trên, có nhiều kỹ thuật ước lượng nghiên cứu ứng dụng rộng rãi ngành công nghiệp phần mềm Mặt khác, để ước lượng dự án xác, địi hỏi phải dùng hai kỹ thuật để kiểm tra chéo Bằng cách so sánh điều tiết ước lượng suy dùng kỹ thuật khác nhau, người lập kế hoạch suy ước lượng xác Việc ước lượng dự án phần mềm khoa học xác, tổ hợp liệu lịch sử tốt kết hợp với việc sử dụng kỹ thuật ước lượng cải thiện độ xác ước lượng Vấn đề “nóng” thứ hai quan tâm đánh giá phần mềm, sở xác để đưa giá thành phần mềm để phân biệt tổ chức sản xuất phần mềm cạnh tranh sản phẩm loại Khác với việc ước lượng dự án phần mềm (được tiến hành khoảng thời gian giới hạn lúc bắt đầu dự án phần mềm, cập nhật đặn tiến trình dự án) việc đánh giá phần mềm tiến hành phần mềm mã hoá cập nhật sau thời hạn định phần mềm đưa vào sử dụng Để đánh giá phần mềm, tập kỹ thuật phát triển ý nghĩa hơn, từ nghiên cứu chất lượng cách đánh giá nó, quy trình đảm bảo chất lượng cho phần mềm xây dựng Mục đích luận văn khơng nằm ngồi việc nghiên cứu đầy đủ kỹ thuật ước lượng phổ biến, cách đánh giá chất lượng phần mềm có xây dựng công cụ ước lượng tự động áp dụng thực tế Nội dung luận văn chia thành ba phần, phần đầu (chương 1) đưa tổng quan ước lượng dự án phần mềm đánh giá chất lượng phần mềm quản lý dự án phần mềm, sở đó, phần hai (chương 3) sâu vào kỹ thuật ước lượng kỹ thuật đánh giá cụ thể, phần cuối (chương 4) dựa nghiên cứu thu được, phát triển công cụ ước lượng tự động dùng để ước lượng công sức ngày công cho dự án phần mềm./ CHƢƠNG TỔNG QUAN VỀ ƢỚC LƢỢNG DỰ ÁN PHẦN MỀM VÀ ĐÁNH GIÁ CHẤT LƢỢNG PHẦN MỀM 1.1 Ước lượng dự án phần mềm [4] Trong ngày đầu tin học, chi phí phần mềm bao gồm phần trăm nhỏ tồ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 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 phí thảm hoạ cho người phát triển Ước lượng chi phí cơng sức phần mềm chắn khơng khoa học xác Có q nhiều tham biến (con 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 Để đạt ước lượng chi phí công sức tin cậy, số tuỳ chọn nảy sinh:  Trì hỗ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% dự án hoàn tât);  Dùng kỹ thuật phân rã để 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 từ hay nhiều công cụ ƣớc lƣợng tự động Tuỳ chọn „hấp dẫn‟ lại không thực tế Các ước lượng chi phí phải đưa từ đầu Tuy đợi lâu biết nhiều, biết nhiều có khả phạm lỗi lầm ước lượng Ba tuỳ chọn lại cách tiếp cận đứng tương đối ước lượng dự án phần mềm Một cách lý tưởng, kỹ thuật lưu ý cho tuỳ chọn nên áp dụng nối tiếp nhau, tuỳ chọn dùng phép kiểm tra chéo cho tuỳ 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) 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 (LOC FP ước lượng) Có cơng cụ ước lượng tự động 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 tuỳ chọn cho việc ước lượng Trong hệ thống vậy, đặ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 mơ tả Các ước lượng chi phí nỗ lực suy từ liệu [4] Một dự án thực lập kế hoạch cần phải đánh giá độ lớn nó, tài nguyên cần thiết, lịch thực cột mốc quan trọng như: gửi tài liệu, bắt đầu kiểm thử, bàn giao Thơng thường giá thành lịch trình thực dự án thường mang tính rủi ro khơng đánh giá mức Một số lý là:  Giá thành lịch trình thường định trước đối tượng dự án như: khách hàng, chủ đầu tư…;  Cơng việc phân tích thiết kế bao quát hết trường hợp, tình huống, yêu cầu chưa hiểu hết, hiểu đúng;  Thường khách hàng khơng hiểu việc phát triển phần mềm công việc có tính cơng nghệ cao với giá thành cao Quy trình ước lượng chi phí phần mềm mô tả bước cần thiết cho việc bắt đầu đánh giá vịng đời phần mềm sau theo dõi, tinh chỉnh đánh giá xuyên suốt thời gian thực dự án Thiết lập quy trình sớm giúp cho việc đánh giá xác hơn, tin cậy hơn, từ xác định rõ ràng nhân tố liên quan tới giá thành dự án Quy trình đồng thời cung cấp phương pháp cho dự án cách thức quản lý rủi ro liên quan tới chi phí lịch trình dự án Quy trình ước lượng q trình liên tục, thực khơng ngừng thời gian thực dự án Các hoạt động bao gồm: Ước lượng kích cỡ; Ước lượng chi phí nỗ lực; Ước lượng lịch trình; Ước lượng tài nguyên máy tính; Đánh giá rủi ro; Kiểm tra / xác nhận; Theo dõi báo cáo tiến độ; Đánh giá cải tiến quy trình Các hoạt động ước lượng kích cỡ, nỗ lực chi phí cần thực trước xây dựng thứ tự bắt buộc tất mơ hình tính tốn giá thành Tuy nhiên việc xây dựng lịch trình thường bắt đầu thực trước hồn thành tất cơng việc xác định nỗ lực Ngoài ra, việc sớm thiết lập bảng cấu trúc phân việc (Work Breakdown Structure - WBS) giúp việc phân chia nỗ lực phần việc độc lập mà lập lịch xét mức độ ưu tiên xem thực phần việc trước (ít người tham gia xây dựng ) Yêu cầu Ước lượng kích cỡ Ước lượng nỗ lực/chi phí Ước lượng lịch trình Cơ sở liệu dự án ước lượng (dùng kỹ thuật ) (dùng kỹ thuật ) (dùng kỹ thuật ) Ước lượng hệ thống máy tính Quản lý rủi ro (lặp lại định kỳ) Kiểm tra/xác thực Theo dõi, báo cáo dự án Đánh giá cải tiến quy trình Hình Quy trình ước lượng dự án phần mềm 1.1.1 Ƣớc lƣợng kích cỡ (LOC & FP) Kích cỡ phần mềm thường đánh giá đại lượng số lượng dòng mã (Source Lines of Code - SLOC) số nghìn dịng mã (Thousands of Source 10 Lines of Code - KSLOC) Phần mềm thường phát triển theo cách viết hoàn toàn dùng hay nhiều module có sẵn, việc ước lượng đoạn mã có cần quan tâm việc ước lượng đoạn mã cần viết thêm Việc tích hợp module sẵn có đơn giản thực nỗ lực dành cho khơng so với việc phát triển từ đầu Kích cỡ đánh giá qua đơn vị điểm chức (Function Points) Các điểm chức đánh giá dựa chức phần mềm thường áp dụng pha tìm hiểu u cầu Dịng mã (LOC – Line Of Code) điểm chức (FP – Function Point) liệu sở để từ tính độ đo hiệu Dữ liệu LOC FP dùng theo hai cách việc ước lượng dự án phần mềm như: (1) Các biến ước lượng dùng để lấy “kích cỡ” cho phần tử phần mềm (2) Độ đo vạch ranh giới thu thập từ dự án khứ dùng chung với biến ước lượng để xây dựng dự tính chi phí cơng sức Ước lượng LOC FP kỹ thuật ước lượng phân biệt, hai có số đặc trưng chung Người lập dự án bắt đầu với tuyên bố phạm vi phần mềm, từ đó, dự định phân rã phần mềm thành chức nhỏ áp dụng riêng biệt LOC FP ước lượng cho chức Độ đo tính hiệu vạch ranh giới (như LOC/người-tháng hay FP/người-tháng) sau áp dụng cho biến ước lượng thích hợp ước lượng chi phí cơng sức từ suy dẫn Các ước lượng chức tổ hợp lại để tạo thiết kế ước lượng tổng thể cho toàn dự án Các ước lượng kỹ thuật LOC FP khác mức độ chi tiết cần cho việc phân rã Khi LOC dùng biến ước lượng việc phân rã chức thường thực cho mức chi tiết đáng kể Vì liệu cần cho việc ước lượng điểm chức mức vĩ mô hơn, nên mức độ phân rã dùng FP biến ước lượng chi tiết Cũng cần lưu ý LOC ước lượng trực tiếp FP xác định gián tiếp cách ước lượng số vào, ra, tệp liệu, câu hỏi, giao diện kèm theo 14 giá trị điều chỉnh độ phức tạp sau: Fi: Hệ thống có địi hỏi lưu phục hồi khơng? Có địi hỏi trao đổi liệu khơng? Có chức xử lý phân tán khơng? 98 Mặc dù nhiều nhà quản lý người phát triển tranh luận nhiều nhu cầu phát triển phần mềm nhiều người không quan tâm tới việc thiết lập chức SQA hình thức Có nhiều ngun nhân cho mâu thuẫn Người quản lý ngần ngại gánh thêm chi phí phụ tăng thêm Người phát triển cảm thấy họ làm xong thứ cần làm Không biết phải đặt chức đâu tổ chức Mọi người muốn tránh việc SQA công nhận phải đưa vào tiến trình kỹ nghệ phầm mềm Mục thảo luận ngắn mối quan tâm quan trọng cho việc tiến hành hoạt động đảm bảo chất lượng phần mềm Xem xét nhu cầu cho SQA Tất tổ chức phát triển phần mềm có chế để thẩm định chất lượng Trước thủ tục đảm bảo chất lượng thức thiết lập, tổ chức phát triển phần mềm nên chấp nhận thủ tục, phương pháp, công cụ kỹ nghệ phần mềm Phương pháp luận tổ hợp với khuôn cảnh (đã thảo luận Chương II) cải thiện nhiều chất lượng tất phần mền tổ chức tạo Bước cần tiến hành kiểm toán SQA/SCM Trạng thái việc bảo đảm chất lượng phần mềm việc quản lý cấu hình phần mềm thẩm định cách xem xét chủ đề sau: Đường lối, thủ tục chuẩn thời tồn cho giai đoạn phát triển phần mềm? chúng có phải bắt buộc khơng? có đường lối riêng cho SQA khơng? Các đường lối có áp dụng cho tất hoạt động phát triển lẫn bảo trì khơng? Tổ chức kỹ nghệ phần mềm nằm đâu sơ đồ tổ chức tại? Việc bảo đảm chất lượng nằm đâu? Giao diện chức năng: Đâu mối quan hệ thời việc bảo đảm chất lượng thể chế khác SQA tương tác với người thực xét duyệt kỹ thuật quản lý cấu hình kiểm thử? Một vấn đề trả lời điểm mạnh, điểm yếu xác định nhu cầu cho SQA rõ ràng việc thẩm định cẩn thận ý kiến ủng hộ phản đối xem xét Về phía tích cực SQA đưa ích lợi sau: Phần mềm có khiếm khuyết tiềm tàng giúp giảm bớt nỗ lực thời gian dành cho kiểm thử bảo trì 99 Độ tin cậy cao làm nảy sinh thoả mãn lớn cho khách hàng Chi phí bảo trì rút bớt Chi phí vịng đời tồn phầm mềm giảm Về phía tiêu cực : SQA gây vấn đề lý sau: Khó mà thiết lập tổ chức nhỏ nơi tài nguyên sẵn có để thực hoạt động cần thiết không sẵn sàng Nó biểu tượng cho truyền thống việc thay đổi không dễ dàng Nó địi hỏi chi phí tiền khơng có khơng lập ngân sách tường minh cho kỹ nghệ phần mềm hay bảo đảm chất lượng phần mềm Tại mức tảng SQA chi phí hiệu nếu: C3> C1 + C2 C3 Chi phí cho việc lỗi xuất với chương trình khơng có SQA C2 chi phí cho lỗi khơng phát hoạt động SQA C1 Là chi phí thân chương trình SQA Nói chung, SQA phần cam kết quản lý toàn để cải thiện chất lượng - thường gọi quản lý chất lượng toàn [4] 100 CHƢƠNG PHÁT TRIỂN CHƢƠNG TRÌNH ỨNG DỤNG 4.1 Mục tiêu  Ước lượng chi phí nguồn lực cho việc phần mềm cách xác định số lượng chức yêu cầu cung cấp người dùng dựa chủ yếu thiết kế logic  Ước lượng ngày công cho việc phát triển phần mềm, trình bảo dưỡng bảo trì độc lập cơng nghệ sử dụng 4.2 Tóm lược sở khoa học Phần mềm xây dựng dựa hai phương pháp nghiên cứu Function Points Use Case Points [5, 2] 4.2.1 Các bƣớc tính Function Points chƣơng trình Bƣớc Tính tổng số điểm chức (điểm chức thô - UFP) Bƣớc Xác định tác tố ảnh hưởng đến độ phức tạp phần mềm (14 tác tố); tác tố xác định thang điểm 5, dựa việc đáp ứng câu hỏi bảng sau: Tỉ lệ tác tố theo thang điểm từ đến Không ảnh Ngẫu nhiên Đơn giản Trung bình hưởng Có ý nghĩa Bản chất Tổng số điểm tác tố gọi độ ảnh hưởng (Fi với i=1 14) Fi: 1- Hệ thống có u cầu lưu khơi phục khơng? 2- Có u cầu trao đổi liệu khơng? 3- Có chức xử lí phân tán khơng? 4- Có địi hỏi cao vấn đề có làm việc tốt khơng? 5- Hệ thống có chạy mơi trường có nặng vấn đề tiện ích khơng 6- Hệ thống có địi hỏi việc vào liệu trực tuyến khơng 7- Việc vào liệu trực tuyến có địi hỏi phải xây dựng thao tác đưa vào thông qua nhiều hình hay thao tác khơng? 8- Tệp có phải cập nhật trực tuyến không? 9- Cái vào, ra, tệp, truy vấn có phức tạp khơng? 10- Xử lí bên có phức tạp khơng? 11- Mã chương trình có thiêt kế để dùng lại khơng? 101 12- Việc chuyển đổi cài đặt có đưa vào thiết kế khơng? 13- Hệ thống có thiết kế cho nhiều cài đặt tổ chức khác khơng? 14- Liệu ứng dụng có thiết kế để làm thuận tiện cho việc thay đổi dễ dàng cho người dùng khơng? Bƣớc Tính điểm chức năng: FP = UFP * (0,65 + 0,01*SUM(Fi)) Sau tìm điẻm chức ta tính tốn ước lượng theo công thức sau: Hiệu = FP/ngƣời-tháng Phẩm chất = Khiếm khuyết /FP Chi phí = $/FP Tƣ liệu = Số trang tƣ liệu /FP Các loại Funtion Points Data storage External Input (EI) (ví dụ, liệu điền lên form) External Output (EO) (ví dụ, báo cáo) Transactions External Query (EQ) (ví dụ, hộp thoại tìm kiếm) Internal Logical File (ILF) (ví dụ, quan hệ bảng lưu giữ) External Logical File (ELF) (ví dụ, bảng khác ứng dụng liên hệ tới không lưu giữ) 102 Độ phức tạp FP khác nhau:  EI, EO, EQ dựa số lượng kiểu thành phần liệu (ký hiệu DET: Data Element Types) truy cập số lượng kiểu file tham chiếu  ILF EIF có độ phức tạp dựa số lựợng DET số lượng kiểu thành phần ghi Dưới bảng trọng số dành cho loại FP mứ độ phức tạp tương ứng *Các đặc trƣng chung hệ thống (GSC: General Systems Characteristics), có 14 loại nhƣ sau: Data Communications Dữ liệu thông tin điều khiển sử dụng ứng dụng gửi nhận qua điều kiện giao tiếp Distributed Data Processing Xử lý liệu phân tán Performance Tốc độ đáp ứng ứng dụng thời gian Heavily Used Configuration Nặng thao tác cấu hình đặc biệt cân nhắc thiết kế Vấn đề nảy sinh nhu cầu sử dụng người khác nhau, mà việc cấu hình riêng cho người dùng cho chương trình chạy tốt vấn cần thiết 103 Transaction Rate Tỷ lệ giao dịch On-line Data Entry Dầu vào liệu trực tuyến End -User Efficiency: Hiệu sử dụng cuối Mức độ thiết kế hiệu cho người sử dụng cuối Mức độ chi tiết yêu cầu người dùng, yêu cầu người dùng chức đặc thù cho ứng dụng họ yếu tố lớn On-line Update Phần mềm hỗ trợ việc update online cho file hệ thống (ILF: internal logical files) Complex Processing: xửlý phứct tạp Độ phức tạp xử lý bên phần mềm, phép tính tốn, thuật tốn phức tạp… 10 Reusability: khả sử dụng lại Ứng dụng mã nguồn ứng dụng thiết kế, phát triển hỗ trợ để sử dụng lại ứng dụng khác ứng dụng có tính mở rộng phát triển cao 11 Installation Ease: dẽ dàng cài đặt Dễ dàng cài đặt đưa vào sử dụng 12 Operational Ease: thao tác dễ dàng Thao tác dễ dàng đặc điểm ứng Các thủ tục khởi động, lưu, khôi phục hiệu cung cấp, kiểm tra khâu kiểm thử Các chức bên ứng dụng đơn giản, dễ hiểu, dễ xử lý, không cần nhiều thời gian để làm quen sử dụng 13 Multiple Sites: nhiều nơi Ứng dụng thiết kế đặc trưng, phát triển, hỗ trợ để cài đặt nhiều nơi cho nhiều tổ chức 14 Facilitate Change: thay đổi dễ dàng Ứng dụng thiết kế đặc trưng, phát triển, hỗ trợ để dễ dàng thay đổi Mỗi GSC đặt giá trị phù hợp với ảnh hưởng tới ứng ụng.Tổng giá trị 14 GSC gọi TDI (Toptal Degree of Influence) VAF (Value Adjustment Factor) = (TDI*0.01) + 0.65 Adjusted Function Points Count tính sau: AFPC = VAF * UFPC Sau tính tốn AFPC ước lượng giá phần mềm thơng qua cơng sức(efford) trung bình bỏ để xây dựng Function Points, tiếp sau nhân với ngày cơng giá phần mềm 104 4.2.2 Các bước tính Use Case Points chương trình Phương pháp Use case points đếm Actor Use case mơ hình UML Để tính UUCP (Unjust Use case Points) ta nhân thêm trọng số tương ứng bảng với loại Actor Use case ni: số lượng use case Actor wi: trọng số tương ứng Để ước lượng phần mềm tốt thêm hai nhân tố là:  Technical Complexity Factor(TCF) Environmental Factor (EF)  Technical Complexity Factor nói tới (Phần Function Points) Bảng Environmental Factor: 105 Cơng thức tính : với C1 = 1.4, C2 = -0.3 Các số C1, C2 dựa ước lượng sớm F1: Mức độ quen thuộc: Mơ hình hệ thống quen thuộc với nhân viên phát triển phần mềm F2: phụ thuộc vào số lượng mức độ đóng góp nhân viên làm việc Part Time F3: Năng lực phân tích, người phân tích tốt cho hệ thống phát triển tốt, dễ cài đặt, phát triển mở rộng F4: kinh nghiệm ứng dụng: hầu hết công nhân làm việc quen thuộc ứng dụng F5: Kinh nghiệm lập trình hướng đối tượng: kinh nghiệm ảnh hưởng lớn đến mơ hình đối tượng ứng dụng F6: Động thúc đẩy: ứng dụng phát triển có nhu cầu lớn, có tương lai, động thúc đẩy tốt, việc tập trung phát triển tốt hơn, ứng dụng hoàn thiện tốt F7: Mức độ khó khăn ngơn ngữ lập trình: ngơn ngữ lập trình cấp thấp thường khó so với lập trình ngơn ngữ bậc cao F8: Mức độ ổn định yêu cầu: nhân tố điển hình, biết người dùng đơi cịn chưa phát rõ sác u cầu mình, q trình phát triển phần mềm thày đổi đơi phải trả giá đắt Khi Use case points tính: 4.3 Cài đặt Cơng nghệ áp dụng: Chương trình xây dựng ngơn ngữ C#, hoạt động OS MS Windows với môi trường Dot Net Framework 2.0 Yêu cầu hệ thống:  Windows 95, Windows 98, Windows NT 4, Windows 2000, or Windows XP  4MB free ổ cứng  RAM 128MB  Chuột thiết bị trỏ thích hợp 106  Cài Dot Net Framework 2.0 Một số giao diện chƣơng trình Software Estimation Hình Ước lượng phần mềm theo phương pháp Function Points 107 Hình Ước lượng phần mềm phương pháp Use Case Points Hình Bảng thông số 108 KẾT LUẬN Thị trường phần mềm phát triển tương xứng (hoặc gần tương xứng) với kinh tế, đặc điểm chung Do đặc điểm thị trường phần mềm bị ảnh hưởng đặc điểm kinh tế, mà Việt Nam ngoại lệ Chúng ta hiểu có nhiều phát triển năm qua thị trường Việt Nam nhiều bất cập Có thể tạm chia cách hoạt động làm việc loại hình kinh doanh Việt Nam thành hai loại:  Hoạt động khoa học, chuyên nghiệp  Hoạt động cịn mang nặng tính chất "tình cảm" Cả hai loại rơi vào hình thức cơng ty, xí nghiệp nhà nước tư nhân Khơng thể nói hình thức thứ hai làm sai pháp luật, mặt giấy tờ khó tìm lỗi họ chế độ tài hay quản lý nhà nước, nhiên từ mà thị trường nước không đồng Sản phẩm phần mềm từ khơng có mức giá cố định, phần mềm làm cho cơng ty giá đem bán cho cơng ty khác giá nhiều nhơn Từ khơng phí sản xuất định tổ hợp loạt quan hệ nhân theo tỷ lệ phần trăm với giá thành Những khó khăn dẫn tới hệ việc nghiên cứu đề tài này: "Xây dựng phương pháp ước lượng chi phí phần mềm Việt Nam" trở nên rắm rối nguy khơng có cách thức thỏa mãn hai loại Do việc ước lượng chi phí phần mềm nghĩa nghiên cứu cách ước lượng giá trị phần mềm dựa công sức đội ngũ phát triển nó, tức đại lượng để đo lường giá trị tiền mà là:  Người - tháng  Số người cần phát triển dự án  Thời gian thực dự án Khi áp kết vào thực tế, tùy vào thời điểm, doanh nghiệp có giá trị nhân cơng khác Như nói trên, đặc thù không đồng thị trường Việt Nam, việc xác định hệ số cho phương pháp gặp khó khăn, có dự án mà giá trị dự án cao thấp so với đánh giá thông thường Vì việc nghiên cứu kỹ phương pháp điều chỉnh lại chúng quan trọng Đề tài nghiên cứu đầy đủ cách đánh giá chất lượng giá thành phần mềm, đưa dẫn việc ước lượng nguồn lực cho dự án phần mềm Dựa kết nghiên cứu, cài đặt công cụ ước lượng tự động để đưa thơng số cần có cho việc ước lượng chi phí, nhân lực, tài nguyên đánh giá phần mềm./ 109 TÀI LIỆU THAM KHẢO [1.] Barry W Boehm, Software Cost Estimation with COCOMO II , Prentice- Hall, July 2000 [2.] David Garmus & David Herron, Function Point Analysis: Mesurement Practices for Successful Software Projects, Paperback, Dec 2000 [3.] Jonh Porter, Esimation with Use Cases: A simple and Effective Approach to Estimating Software Projects, EII Publication, 2002 [4.] Roger S Pressman, Software Engineering – A Practitioner’s Approach, Third Edition, McGraw-Hill.Inc, 1992 [5.] Suresh Nageswaran, Test Effort Estimation Using Use Case Points, Article, 2001 PHỤ LỤC Các thông số vấn đề cần lưu ý tiến hành ước lượng dự án định giá phần mềm Việt Nam * Lưu ý ước lượng chi phí Tỷ lệ lao động trực tiếp lao động gián tiếp 3,5:1 Tỷ lệ công ty thành lập nước phát triển 4:1 có xu hướng giảm dần công ty sản xuất phần mềm chín muồi, hình thành cơng nghệ lõi Tỷ lệ trưởng dự án kỹ sư 1:6,9 Tần suất thay đổi việc làm sản xuất phần mềm: tần suất thay đổi việc làm cơng ty 15 người lên tới 50-60% giảm xuống cịn 10% quy mơ cơng ty tăng 200 người Hệ số tính dơi tỷ lệ tổng chi phí nhân lực (kể nhân lực gián tiếp) với chi phí nhân lực trực tiếp, hệ số 1,7:1 Điều có nghĩa USD chi cho nhân lực trực tiếp thêm 0.7 USD cho nhân lực gián tiếp Từ lương trung bình cho nhân lực trực tiếp ta suy tỷ lệ chi phí nhân lực nhân lực sản xuất phần mềm Mức độ chi phí nhân lực doanh thu: tỷ lệ chi phí nhân lực cơng ty sản xuất phần mềm khoảng 22.5% với sai phương quãng 5% Lương trung bình kỹ sư lập trình: tạm lấy lương trung bình kỹ sư phần mềm 1200 USD/năm cho kỹ sư năm kinh nghiệm Số liệu tương đối thấp so với thực tế Lương trung bình trưởng dự án 4000USD/năm Với tỷ lệ trưởng dự án/ kỹ sư 1:6.9, tính lương trung bình nhân lực trực tiếp sản xuất phần mềm 1540 USD/năm Như chi phí nhân lực nhân lực trực tiếp 1540 USD X 1,7 =2618USD [Viện chiến lược, 2003] * Lưu ý định giá phần mềm Hiện tại, việc định giá cho hệ thống phần mềm ứng dụng chủ yếu dựa chào giá đơn vị cung ứng phần mềm Cách chào giá thường dựa tính tốn chủ quan khơng phải nhà cung cấp có đầy đủ kinh nghiệm để đưa đơn giá chào hàng nhiều trường hợp họ phải chào giá thành để có đơn hàng vốn vấn đề sống cịn với doanh nghiệp phần mềm Từ xuất vòng luẩn quẩn: nhà cung cấp chào giá cao khơng có đơn hàng, nhà cung cấp chào giá thấp để lấy đơn hàng khơng đủ chi phí sản xuất nên chất lượng không cao, người sử dụng không thoả mãn lại ngại định đầu 111 tư cho hạng mục phần mềm Những nguyên nhân gây ảnh hưởng lớn tới giá phần mềm Việt Nam: Tình trạng sử dụng phần mềm lậu (các sản phẩm cuả Microsoft chẳng hạn) tràn lan Chỉ với vài nghìn người ta mua hàng chục phần mềm lậu Điều tạo nên tâm lý không tốt cách nhận thức giá trị phần mềm Do trình độ CNTT đơn vị sử dụng phần mềm thấp, nên số phần mềm chuyên dụng phức tạp (thường gía cao), đơn vị sử dụng thường hay ngại bỏ chi phí đào tạo cho nhân viên để biết cách sử dụng phần mềm Mặc khác, tình hình nhân viên thường hay dao động Nhiều trường hợp sau bỏ chi phí đào tạo xong nhân viên nghỉ, lại phải đào tạo nhân viên Tâm lý ngại lệ thuộc: tính lệ thuộc phần mềm Một đơn vị sử dụng mua sản phẩm cơng ty phần mềm (đặc biệt phần mềm chuyên dụng) họ phải lệ thuộc phần vào công ty phần mềm Vì phần mềm có cố, u cầu nâng cấp, mở rộng tính người sử dụng tất nhiên phải liên hệ đến nhà sản xuất Yếu tố làm người sử dụng ngại nhà sản xuất không đáp ứng kịp thời gian nhà sản xuất khơng cịn tồn Đơi phần mềm, nhiêu chức Nhưng với công ty sản xuất, nơi giá Có thể chi phí sản xuất cuả cơng ty khác Nhưng có trường hợp sản phẩm công ty bán cho nơi giá Điều tạo nên nghi ngờ giá gây nên hiệu ứng phản cảm cho người sử dụng Người sử dụng chưa thấy hiệu vượt trội sản phẩm phấn mềm mà họ mua: điều phần lao động Việt Nam giá rẻ Ví dụ với phần mềm kế tốn (PMKT): bỏ chi phí vài trăm triệu để mua PMKT xu hướng người tiêu dùng chọn thuê vài ba nhân viên có chun mơn kế tốn để làm việc mà phần mềm làm với mức lương tương đối rẻ Mặc khác, ngồi việc làm kế tốn viên, người nhân viên đảm nhiệm số cơng việc khác Sản phẩm phần mềm xa lạ với người dân Thậm chí đơn vị sản xuất nhỏ Có thể cơng tác tiếp thị DN phần mềm chưa rộng nên Còn nhiều yếu tố khác cạnh tranh, trách nhiệm người sản xuất dẫn đến chất lượng sản phẩm tác động không nhỏ đến thị trường giá Hơn nữa, việc định giá phần mềm phải tính đến yếu tố bảo dưỡng, trì, cập nhật theo yêu cầu khách hàng Đây chỗ khách hàng khó thấy lúc đầu Thank you for evaluating AnyBizSoft PDF Merger! To remove this page, please register your program! Go to Purchase Now>> AnyBizSoft PDF Merger  Merge multiple PDF files into one  Select page range of PDF to merge  Select specific page(s) to merge  Extract page(s) from different PDF files and merge into one ... bắt đầu dự án phần mềm, cập nhật đặn tiến trình dự án) việc đánh giá phần mềm tiến hành phần mềm mã hoá cập nhật sau thời hạn định phần mềm đưa vào sử dụng Để đánh giá phần mềm, tập kỹ thuật phát... công cho dự án phần mềm. / 7 CHƢƠNG TỔNG QUAN VỀ ƢỚC LƢỢNG DỰ ÁN PHẦN MỀM VÀ ĐÁNH GIÁ CHẤT LƢỢNG PHẦN MỀM 1.1 Ước lượng dự án phần mềm [4] Trong ngày đầu tin học, chi phí phần mềm bao gồm phần trăm... trình kỹ nghệ phần mềm Ta nên xác định yêu cầu tài nguyên phần mềm sớm, nhờ đó, việc đánh giá kỹ thuật cho phương án tiến hành thu hạn 1.2 Đánh giá chất lượng phần mềm Đánh giá chất lượng phần mềm