Áp dụng mô hình cocomo II để ước lượng chi phí của dự án phần mềm

Thông qua việc khảo sát tại công ty phần mềm được chọn trước để kiểm tra độ chính xác của mô hình COCOMO II đồng thời xác định một số các yếu tố có tầm ảnh hưởng quan trọng đến ước lượng

KHƯU QUỐC BẢO

Áp dụng mô hình COCOMO II để ước lượng chi phí của dự án phần mềm

Chuyên ngành: Hệ thống thông tin quản lý

Mã số: 603448

LUẬN VĂN THẠC SĨ

TP HỒ CHÍ MINH, Tháng 6 năm 2012

Cán bộ hướng dẫn khoa học: TS Nguyễn Hải Quân

NHIỆM VỤ LUẬN VĂN THẠC SĨ

Họ tên học viên: Khưu Quốc Bảo MSHV: 03130029 Ngày, tháng, năm sinh: 16/06/1985 Nơi sinh : Thành phố Hồ Chí Minh Chuyên ngành: Hệ Thống Thông Tin Quản Lý Mã số : 603448

I TÊN ĐỀ TÀI: Áp dụng mô hình COCOMO II để ước lượng chi phí của dự

án phần mềm

II NHIỆM VỤ VÀ NỘI DUNG: Nghiên cứu về mô hình COCOMO II và các yếu

tố điều chỉnh chi phí để ước lượng chi phí của một dự án phần mềm Thông qua việc khảo sát tại công ty phần mềm được chọn trước để kiểm tra độ chính xác của mô hình COCOMO II đồng thời xác định một số các yếu tố có tầm ảnh hưởng quan trọng đến ước lượng chi phí cho dự án

III NGÀY GIAO NHIỆM VỤ : 06/02/2012

IV NGÀY HOÀN THÀNH NHIỆM VỤ: 30/06/2012

V CÁN BỘ HƯỚNG DẪN: TS Nguyễn Hải Quân

Để có thể hoàn thành chương trình cao học và luận văn này, tôi đã nhận được sự hướng dẫn, giúp đỡ và góp ý nhiệt tình của quý thầy cô khoa Hệ Thống Thông Tin Quản Lý trường Đại học Bách Khoa Thành phố Hồ Chí Minh

Tôi xin chân thành cảm ơn quí thầy cô trường Đại học Bách Khoa Thành phố Hồ Chí Minh, đặc biệt là những thầy cô đã tận tình dạy bảo cho tôi suốt thời gian học tập tại trường

Tôi xin gửi lời biết ơn sâu sắc đến Tiến sĩ Nguyễn Hải Quân đã dành rất nhiều thời gian và tâm huyết hướng dẫn nghiên cứu và giúp tôi hoàn thành luận văn tốt nghiệp

Nhân đây, tôi xin chân thành cảm ơn Ban Giám hiệu trường cùng quí thầy cô trong Khoa Hệ Thống Thông Tin Quản Lý đã tạo rất nhiều điều kiện để tôi học tập và hoàn thành tốt khóa học

Đồng thời, tôi cũng xin cảm ơn quí anh, chị và ban giám đốc công ty phần mềm Edge-works đã tạo điều kiện cho tôi điều tra khảo sát để có dữ liệu để viết luận văn Đặc biệt là giám đốc điều hành, tiến sĩ Jochen Nessel, người đã giúp tôi lựa chọn đề tài này và cho phép sử dụng số liệu về dự án của công ty để khảo sát

Mặc dù tôi đã có nhiều cố gắng hoàn thiện luận văn bằng tất cả sự nhiệt tình và năng lực của mình, tuy nhiên không thể tránh khỏi những thiếu sót, rất mong nhận được những đóng góp quí báu của quí thầy cô và các bạn

Trong những năm gần đây ngành công nghiệp phần mềm Việt Nam đã có những bước nhảy vọt đáng kể Từ 2010 Việt nam đã trở thành một trong ba mươi địa điểm đáng chú ý cho ngành gia công phần mềm trên thế giới Đồng thời, mặc dù ảnh hưởng của suy thoái kinh tế thế giới, tỷ lệ tăng trưởng năm 2010 của ngành công nghiệp phần mềm Việt Nam vẫn đạt trên 20% Theo báo cáo Toàn cảnh thị trường Công Nghệ Thông Tin Truyền Thông năm 2011 do Hội Tin học TP.HCM thực hiện, nhóm doanh nghiệp gia công – xuất khẩu phần mềm đang tăng trưởng mạnh trong năm 2010 và đầu năm 2011 Đó là những thành công đáng vui mừng của ngành phần mềm Việt Nam, tuy nhiên đi kèm theo đó là những thách thức đáng kể như sự thiếu thốn đội ngũ nhân lực chất lượng cao và quan trọng hơn đội ngũ quản

lý giỏi có khả năng quản lý cũng như ước lượng chính xác chi phí, thời gian cũng như số lượng nhân lực cần thiết để bảo đảm hoàn thành dự án Mục tiêu của nghiên cứu là tìm hiểu một mô hình ước lượng chi phí đã được dùng nhiều trên thế giới là

mô hình COCOMO II và sử dụng nó như là một công cụ ước lượng chi phí chính xác Sử dụng những dự án phần mềm tại công ty Edge-works Software Ltd để thực nghiệm sự chính xác của phương pháp Từ nghiên cứu đó, tác giả rút ra được những yếu tố chính có tầm ảnh hưởng quan trọng trong việc ước lượng chi phí

In recent years the software industry of Vietnam has a significant leap Since 2010 Vietnam has become one of thirty places of interest for the outsourcing industry in the world Also, although the impact of the global economic slowdown, the growth rate in 2010 of the software industry in Vietnam has reached 20% According to market reports Overview of Information Communication Technology in 2011 by

Ho Chi Minh City Computer Association (HCA), outsourcing business groups - software exports are growing strongly in 2010 and early 2011 That is the happy success of Vietnam's software industry, but it is accompanied by significant challenges such as lack of human resources quality and more importantly good management team is capable management as well as accurate estimates of cost, time and number of staff necessary to ensure completion of the project The objective of this study is to explore a cost estimation model has been used for many

of the world is COCOMO II model and use it as a tool to estimate the exact cost Using the software project data from company Edge Software Ltd for the accuracy

of the experimental method From that study, the authors draw the key elements are influential in the cost estimate

Tôi xin cam đoan rằng toàn bộ những nội dung và số liệu trong luận văn này do tôi

tự nghiên cứu, khảo sát và thực hiện Những dữ liệu được thu thập và xử lí một cách khách quan và trung thực

LỜI CẢM ƠN iv

TÓM TẮT NỘI DUNG LUẬN VĂN v

ABSTRACT vi

LỜI CAM ĐOAN vii

MỤC LỤC viii

DANH MỤC HÌNH VÀ BẢNG 5

THUẬT NGỮ 8

CHƯƠNG 1: MỞ ĐẦU 10

1.1 Hình thành vấn đề 10

1.2 Lý do chọn đề tài 11

1.3 Những câu hỏi nghiên cứu 13

1.4 Phạm vi nghiên cứu 13

1.4.1 Đối tượng nghiên cứu 13

1.4.2 Không gian và thời gian thực hiện 13

1.5 Mục tiêu đề tài 13

1.6 Ý nghĩa đề tài 14

1.7 Tóm tắt chương một 15

Chương 2: TỔNG QUAN CỞ SỞ LÝ THUYẾT 16

2.1 Phần mềm 16

2.2 Chi phí của dự án phần mềm 16

2.2.1 Chi phí 16

2.2.2 Quản lý chi phí dự án 16

2.2.3 Ước lượng chi phí dự án 16

2.3 Quản lý dự án phần mềm 16

2.4 Quy trình quản lý chi phí dự án 17

2.5 Ước lượng chi phí phần mềm 18

2.6.2 Phương pháp ước lượng từ trên xuống 20

2.6.3 Phương pháp ước lượng từ dưới lên 21

2.6.4 Phương pháp giá để thắng 21

2.6.5 Phương pháp Parkinson 22

2.6.6 Phương pháp ước lượng tương đương 22

2.6.7 Phương pháp ước lượng bằng công thức 23

2.6.8 Tổng kết ưu khuyết điểm của các phương pháp 24

2.7 Các bước ước lượng chi phí phần mềm 25

2.8 Số lượng dòng lệnh 28

2.8.1 Các phương pháp đếm số lượng dòng lệnh 28

2.9 Phân tích các điểm chức năng 29

2.9.1 Mục tiêu 30

2.9.2 Lợi ích 30

2.9.3 Quy trình 30

2.9.4 Phân loại 31

2.10 Phương pháp đổi điểm chức năng thành số lượng dòng lệnh 32

2.11 Khái niệm về mô hình COCOMO II 36

2.11.1 Công thức tính số người theo làm việc tháng 39

2.11.2 Các yếu tố quyết định quy mô 40

2.11.3 Các yếu tố điều khiển chi phí 51

2.12 Tóm tắt chương hai 59

CHƯƠNG 3: PHƯƠNG PHÁP NGHIÊN CỨU 61

3.1 Quy trình nghiên cứu 61

3.2 Phương pháp nghiên cứu 61

3.3 Công cụ đếm số dòng lệnh 62

3.4 Phần mềm tính toán cho COCOMO II 63

4.1 Dự án StarSequel 66

4.1.1 Giới thiệu 66

4.1.2 Thông tin dự án 66

4.1.3 Đánh giá kết quả ước lượng 68

4.2 Dự án Equator 68

4.2.1 Giới thiệu 68

4.2.2 Thông tin dự án 69

4.2.3 Đánh giá kết quả ước lượng 71

4.3 Dự án Hawa 71

4.3.1 Giới thiệu 71

4.3.2 Thông tin dự án 71

4.3.3 Đánh giá kết quả ước lượng 73

4.4 Dự án Plevo 73

4.4.1 Giới thiệu 73

4.4.2 Thông tin dự án 74

4.4.3 Đánh giá kết quả ước lượng 76

4.5 Dự án Cartridge World 76

4.5.1 Giới thiệu 76

4.5.2 Thông tin dự án 76

4.5.3 Đánh giá kết quả ước lượng 78

4.6 Dự án GVillage 78

4.6.1 Giới thiệu 78

4.6.2 Thông tin dự án 79

4.6.3 Đánh giá kết quả ước lượng 81

4.7 Dự án Consultant Platform 81

4.7.1 Giới thiệu 81

4.8 Dự án Hr-Solution-Vn 84

4.8.1 Giới thiệu 84

4.8.2 Thông tin dự án 84

4.8.3 Đánh giá kết quả ước lượng 86

4.9 Tóm tắt chương bốn 86

CHƯƠNG 5: KẾT LUẬN VÀ KIẾN NGHỊ 86

5.1 Kết quả khảo sát 87

5.1.1 Tìm độ sai lệch khi ước lượng 87

5.1.2 Khả năng ước lượng sai với một độ sai lệch cho trước 89

5.1.3 Hạn chế 89

5.2 Các yếu tố điều chỉnh chi phí quan trọng 89

5.3 Các điểm hạn chế của mô hình COCOMO II 90

5.3.1 Hạn chế về khách hàng 90

5.3.2 Hạn chế về quy trình 90

5.3.3 Hạn chế về rủi ro 90

5.3.4 Hạn chế về đánh giá trình độ 90

5.4 Cách khắc phục các hạn chế của COCOMO II đề nghị 91

5.4.1 Khắc phục hạn chế về khách hàng 91

5.4.2 Khắc phục hạn chế về quy trình 91

5.4.3 Khắc phục hạn chế về rủi ro 91

5.4.4 Khắc phục hạn chế về đánh giá trình độ 92

5.5 Hạn chế của đề tài và cách khắc phục 92

5.6 Hướng phát triển tiếp theo của đề tài 92

5.7 Tóm tắt chương năm 92

TÀI LIỆU THAM KHẢO 5

PHỤ LỤC 8

DANH MỤC HÌNH VÀ BẢNG

Danh mục hình

Hình 1.1: Tỷ lệ thành công của dự án dùng Waterfall so với Agile 12

Hình 1.2: Tam giác dự án 17

Hình 1.3: Quy trình phát triển phần mềm 17

Hình 1.4: Sự chệnh lệch giữa khối lượng và chi phí giữa ước lượng và thực tế 18

Hình 1.5: Các điểm chức năng 32

Hình 1.6: Các dạng mô hình liên quan đến COCOMO 37

Hình 1.7: Mô hình COCOMO II 39

Hình 3.1: Giao diện chương trình cloc 63

Hình 3.2: Giao diện chương trình COCOMO II 64

Danh mục bảng Bảng 2.1: So sánh ưu và khuyết điểm của các phương pháp ước lượng 25

Bảng 2.2: Các bước ước lượng chi phí dự án 27

Bảng 2.3: Bảng chuyển đổi SLOC/UFP 1 33

Bảng 2.4: Bảng chuyển đổi SLOC/UFP 2 36

Bảng 2.5: Các tham số đề nghị theo dạng dự án 40

Bảng 2.6: Yếu tố quen thuộc 41

Bảng 2.7: Khả năng hoạt động linh hoạt 42

Bảng 2.8: Các yếu tố nguy cơ 43

Bảng 2.9: Khả năng hoạt động nhóm 43

Bảng 2.10: Các vùng quy trình quan trọng 50

Bảng 2.11: Độ tin cậy của phần mềm 51

Bảng 2.12: Kích thước của dữ liệu 52

Bảng 2.13: Độ phức tạp của dự án 52

Bảng 2.14: Khả năng tái sử dụng 53

Bảng 2.15: Số lượng tài liệu cho vòng đời sản phẩm phần mềm 53

Bảng 2.16: Thời gian hoạt động bắt buộc 54

Bảng 2.17: Dung lượng lưu trữ bắt buộc 54

Bảng 2.18: Sự biến động về nền tảng 55

Bảng 2.19: Khả năng phân tích yêu cầu 55

Bảng 2.20: Khả năng lập trình 56

Bảng 2.21: Thời gian làm việc cho dự án 56

Bảng 2.22: Kinh nghiệm với dạng phần mềm của dự án 57

Bảng 2.23: Kinh nghiệm với kiến trúc của phần mềm 57

Bảng 2.24: Khả năng lập trình 58

Bảng 2.25: Khả năng sử dụng các công cụ hỗ trợ lập trình 58

Bảng 2.26: Sử dụng các phương tiện thông tin liên lạc 59

Bảng 2.27: Thời gian cần thêm để hoàn thành dự án 59

Bảng 3.1: Các tham số cơ bản của chương trình cloc 63

Bảng 3.2: Các tham số tùy chọn 63

Bảng 4.1: Các yếu tố đều chỉnh quy mô của dự án StarSequel 67

Bảng 4.2: Các yếu tố đều chỉnh chi phí của dự án StarSequel 68

Bảng 4.3: Các yếu tố đều chỉnh quy mô của dự án Equator 69

Bảng 4.4: Các yếu tố đều chỉnh chi phí của dự án Equator 71

Bảng 4.5: Các yếu tố đều chỉnh quy mô của dự án Hawa 72

Bảng 4.6: Các yếu tố đều chỉnh chi phí của dự án Hawa 73

Bảng 4.7: Các yếu tố đều chỉnh quy mô của dự án Plevo 74

Bảng 4.8: Các yếu tố đều chỉnh chi phí của dự án Plevo 76

Bảng 4.9: Các yếu tố đều chỉnh quy mô của dự án Cartrige World 77

Bảng 4.10: Các yếu tố đều chỉnh chi phí của dự án Cartrige World 78

Bảng 4.11: Các yếu tố đều chỉnh quy mô của dự án GVillage 79

Bảng 4.12: Các yếu tố đều chỉnh chi phí của dự án GVillage 81

Bảng 4.13: Các yếu tố đều chỉnh quy mô của dự án Consultant Platform 82

Bảng 4.14: Các yếu tố đều chỉnh chi phí của dự án Consultant Platform 83

Bảng 4.15: Các yếu tố đều chỉnh quy mô của dự án HrSolutionVn 84

Bảng 4.16: Các yếu tố đều chỉnh chi phí của dự án HrSolutionVn 86

Bảng 5.0.1: Tổng kết kết quả khảo sát 87

Bảng 5.0.2: Bản độ lệch chuẩn 88

THUẬT NGỮ

1 Analyst Capability ACAP Khả năng phân tích

2 Application Experience APEX Kinh nghiệm với dạng phần

4 Constructive Cost Model COCOMO Mô hình ước lượng chi phí

5 Product Complexity CPLX Độ phức tạp của dự án

6 Database Size DATA Kích thước cơ sở dữ liệu

7 Document Match to

Life-Cycle Needs

DOCU Số lượng tài liệu trong

vòng đời của phần mềm

8 Development Flexibility FLEX Yếu tố quen thuộc

12 Programmer Capability PCAP Khả năng lập trình

13 Personnel Continuity PCON Thời gian làm việc cho

16 Process Maturity PMAT Tiêu chuẩn của dự án

18 Platform Volatility PVOL Sự biến động về nền tảng

24 Source Line Of Mã lệnh SLOC Số lượng dòng mã lập trình

25 Multisite Development SITE Hỗ trợ bằng các phương

tiện thông tin liên lạc

26 Team Cohesion TEAM Quan hệ làm việc trong

CHƯƠNG 1: MỞ ĐẦU

Sự phát triển của lĩnh vực gia công phần mềm ở Việt Nam nhờ có giá thành thấp dẫn đến ngày càng có nhiều nhà đầu tư nước ngoài mang dự án đến cho các công ty phần mềm trong nước thực hiện Để quyết định có nhận một dự án phần mềm thì việc đầu tiên mà một công ty thực hiện trước hết là ước tính chi phí thực hiện, thời gian và số nhân lực cần phải có để tiến hành thực hiện dự án.Thông qua việc ước tính này công ty sẽ quyết định nhận hoặc từ chối đề nghị của khách hàng Đây là giai đoạn quan trọng có tính quyết định sự thành công hay thất bại và lợi nhuận của doanh nghiệp đồng thời ảnh hưởng trực tiếp đến uy tín của doanh nghiệp trên thương trường

Ước lượng chi phí dự án là một việc làm khó khăn và đầy rủi ro với độ chính xác là không cao Có rất nhiều nguyên nhân dẫn đến điều này như không có đầy đủ thông tin về dự án trong giai đoạn tìm hiểu nghiên cứu về dự án Khi đó quá trình ước lượng chi phí thực hiện không chính xác sẽ dẫn đến nhiều thiệt hại cho công ty Nếu công ty ước lượng chi phí quá cao so với giá thực tế thì sẽ dẫn đến mất các hợp đồng mới và các khách hàng tiềm năng mới Còn nếu công ty ước lượng chi phí thấp hơn so với thực tế thì sẽ kiếm được nhiều hợp đồng hơn tạo ra lợi thế cạnh tranh với các đối thủ trên thương trường Tuy nhiên hệ quả có thể thấy là các nhân viên buộc phải làm nhiều hơn với giá rẻ hơn thực tế điều này có thể làm giảm chất lượng của sản phẩm phần mềm do phát sinh nhiều lỗi không mong muốn và thời gian kéo dài hơn so với thời gian đã cam kết trước với khách hàng Hậu quả là khách hàng sẽ hủy bỏ dự án đã kí với công ty hoặc công ty phải chịu đền bù thiệt hại Điều này làm gây ra tổn thất không đáng có cho cả hai bên

Việc ước tính chi phí có tầm quan trọng như vậy nhưng lại thường được thực hiện dựa trên kinh nghiệm sẵn có của những người trưởng dự án Nếu kinh nghiệm đánh

giá của người trưởng dự án là không tốt thì sẽ dẫn đến những hậu quả như đã nêu ở trên

COCOMO II viết tắt của Constructive Cost Modellà một mô hình ước lượng chi phí của dự án phần mềm được phát triển bởi Tiến sỹ Barry W Boehm Mô hình này sử dụng một công thức hồi quy cơ bản với các thông số có nguồn gốc từ các dữ liệu dự án lịch sử và đặc điểm của dự án hiện tại Sử dụng những tham số đầu vào

cơ bản cùng một số các yếu tố điều chỉnh chi phí được tính dựa vào đặc điểm của công ty, tổ chức và của bản thân dự án để từ đó có thể ước lượng thời gian và số nhân lực cần thiết cho dự án, từ đó ta có thể ước lượng được chi phí của dự án phần mềm một cách chính xác hơn

Một trong những việc khó khăn nhất trong trong việc phát triển một dự án phần mềm là việc ước lượng chi phí cho dự án đó Có rất nhiều lý do dẫn đến việc ước lượng chi phí là không đúng Tại thời điểm công ty quyết định về ngân sách cần để thực hiện dự án thì thường chưa có đầy đủ thông tin để có thể có một quyết định chính xác Để giải quyết thì cách ước lượng bằng kinh nghiệm sẽ được thực hiện dựa vào kinh nghiệm của các quản lý dự án sẽ thực hiện dự án đó Đây có thể là một nguy cơ tiềm ẩn có thể nhìn thấy trước bởi vì nó phụ thuộc chủ quan vào người ước lượng

1.2 Lý do chọn đề tài

Mặc dù có những bước đột phá về công nghệ trong nhiều năm qua như việc ra đời của nhiều ngôn ngữ lập trình mới và các quy trình phát triển phần mềm tiên tiến như Scrum hay Agile nhưng việc phát triển phần mềm vẫn tốn kém nhiều chi phí

và chậm hơn so với ước lượng Tuy nhiên sự ra đời của những quy trình này cũng

đã làm giảm sự thất bại của các dự án, trong báo cáo The CHAOS Menifesto của nhóm Standish Group vào năm 2012[15] đã cho thấy tỷ lệ thành công của dự án có

sử dụng Agile cao gấp ba lần so với dự án dùng Waterfall

Hình 1.1: Tỷ lệ thành công của dự án dùng Waterfall so với Agile

(Nguồn: The CHAOS Menifesto của nhóm Standish Group vào năm 2012[15])

Trong nhiều thập kỷ qua vẫn có quá nhiều dự án kết thúc với tổng số tiền vượt quá mức dự chi ban đầu và bị chậm tiến độ Theo kết quả nghiên cứu của tổ chức Standish Group, tại Mỹ mỗi năm tiêu tốn khoản 250 tỷ USD để phát triển khoản 175.000 dự án Chi phí trung bình cho mỗi dự án ở các công ty lớn là 2.322.000 USD, cho một công ty trung bình là 1.331.000 USD và cho một công ty nhỏ là 434.000 USD Tuy nhiên theo nghiên cứu của tổ chức này, rất nhiều các dự án đều

bị thất bại

Nghiên cứu Standish Group còn cho thấy một kết quả đáng kinh ngạc 31,1% số dự

án sẽ bị hủy bỏ trước khi chúng được hoàn thành Hơn nữa kết quả cho thấy 52,7% các dự án sẽ chi phí đến 189% dự toán ban đầu của họ dẫn đến thất bại

Dựa trên nghiên cứu này, tập đoàn Standish đã ước tính rằng vào năm 1995 các công ty Mỹ và các cơ quan chính phủ chi tiêu 81 tỷ USD cho các dự án phần mềm

bị hủy bỏ Các tổ chức này sẽ phải trả thêm 59 tỷ USD cho các dự án phần mềm sẽ được hoàn thành, nhưng sẽ vượt quá dự toán ban đầu của họ

Về mặt thành công, trung bình chỉ có 16,2% cho các dự án phần mềm được hoàn thành vào thời gian và ngân sách Trong các công ty lớn hơn, thậm chí còn ít hơn hơn: chỉ có 9% các dự án của họ hoàn thành đúng thời gian và ngân sách Dự án hoàn thành của các công ty Mỹ lớn nhất chỉ khoảng 42% các tính năng ban đầu được đề xuất và chức năng.Trong khi đó các công ty nhỏ hơn làm tốt hơn Tổng

cộng có 78,4% các dự án phần mềm của họ sẽ được triển khai với ít nhất 74,2% các tính năng và chức năng ban đầu

Ở trong nước, các công ty phần mềm đa số ước lượng chi phí chủ yếu là dựa vào kinh nghiệm từ các dự án đã thực hiện trước đây hoặc kinh nghiệm cá nhân của các trưởng dự án Nhận thấy sự khó khăn trong việc ước lượng chi phí và dự đoán rủi

ro trong các dự án phần mềm nên tôi đã quyết định chọn đề tài này nhằm bổ sung thêm một phương pháp ước lượng chi phí của các dự án giúp cho việc ước lượng được chính xác hơn

 Kiểm tra độ chính xác của COCOMO II bằng cách so sánh thời gian thực hiện thực của các dự án đã hoàn thành tại công ty Edge-works Software Ltd với thời gian ước lượng bằng COCOMO II ?

 Xác định các yếu tố điều chỉnh chi phí nào là quan trọng hơn các yếu tố khác thông?

 Mô hình COCOMO II có thực sự thích hợp khi áp dụng cho công ty phần mềm Edge-works Software Ltd Những khó khăn nằm ở đâu và có hướng giải quyết hay không ?

1.4.1 Đối tượng nghiên cứu

Nghiên cứu được thực hiện cho các công ty gia công phần mềm, cụ thể hơn là cho các quản lý dự án những người cần ước lượng chi phí trước khi bắt đầu dự án Trong phạm vi đề tài, công ty Edge-works Software Ltd được chọn để lấy các số liệu thực tế của các dự án đã hoàn thành để kiểm tra với số liệu được ước lượng

1.4.2 Không gian và thời gian thực hiện

 Không gian: đề tài được thực hiện trong phạm vi nước Việt Nam

 Thời gian: đề tài sẽ thực hiện trong 6 tháng

1.5 Mục tiêu đề tài

Tìm hiểu mô hình lý thuyết của COCOMO II và hỗ trợ của nó cho ba dạng dự án

 Dự án chỉ gồm nhóm phát triển nhỏ, có kinh nghiệm tốt (Organic projects)

 Dự án bao gồm nhóm phát triển có quy mô trung bình, có hoặc không có kinh nghiệm (Semi-detached projects)

 Là dạng kết hợp của hai dạng trên, có yêu cầu về phần cứng, phần mềm cao (Embedded projects)

Nghiên cứu mô hình COCOMO II và các yếu tố điều chỉnh chi phí Đưa ra một số cải tiến để phù hợp với sự phát triển nhanh chóng của lĩnh vực phần mềm hiện nay Điều này là cần thiết bởi sự phát triển vượt bậc của các công cụ hỗ trợ lập trình, những công cụ này không những có khả năng giúp cho việc viết mã chương trình nhanh hơn mà còn có khả năng sinh ra những đoạn mã đơn giản nhằm tiết kiệm thời gian của lập trình viên

Sử dụng phần mềm COCOMO II để giúp cho việc ước lượng dựa vào mô hình COCOMO II hiệu quả hơn và nhanh chóng hơn

Đưa ra một công cụ tham khảo trong việc ước lượng chi phí và thời gian bên cạnh việc sử dụng kinh nghiệm của trưởng dự án Giúp cho việc so sánh, lựa chọn dự án

để triển khai và phân bổ nguồn nhân lực tốt hơn

1.6 Ý nghĩa đề tài

Trình bày chi tiết và đầy đủ về mô hình ước lượng chi phí dự án COCOMO II cũng như các yếu tố điều chỉnh chi phí để giúp cho các trưởng dự án có thể hiểu và áp dụng một cách dễ dàng Theo kinh nghiệm cá nhân của người viết, các trưởng dự

án thường ước lượng dựa trên kinh nghiệm cá nhân là chủ yếu nên độ chính xác là không cao COCOMO II như là một phương pháp bổ sung để kiểm tra lại việc ước lượng chi phí dựa trên kinh nghiệm của người trưởng dự án

Xác định một số các yếu tố điều chỉnh chi phí có tầm ảnh hưởng cao hơn các yếu tố khác phù hợp với hoàn cảnh của các công ty phần mềm tại Việt Nam với điển hình

là công ty phần mềm Edge-works Software Ltd

Chương 2: TỔNG QUAN CỞ SỞ LÝ THUYẾT

2.2.3 Ước lượng chi phí dự án

Là quy trình ước đoán tổng chi phí thực hiện của dự án trước khi dự án bắt đầu được thực hiện

Quản lý dự án phần mềm là tập hợp các công việc được thực hiện bởi một tập thể (có thể có chuyên môn khác nhau, thực hiện công việc khác nhau, thời gian tham gia dự án khác nhau) nhằm đạt được một kết quả như dự kiến, trong thời gian dự kiến, với một kinh phí dự kiến Trong thuật ngữ của chuyên ngành Công nghệ phần mềm, Quản lý dự án phần mềm là các hoạt động trong lập kế hoạch, giám sát và điều khiển tài nguyên dự án (ví dụ như kinh phí, con người), thời gian thực hiện, các rủi ro và quy trình thực hiện dự án nhằm đảm bảo thành công cho dự án Quản

lý dự án phần mềm cần đảm bảo cân bằng giữa ba yếu tố: thời gian, tài nguyên và chi phí, ba yếu tố này thường được gọi là tam giác dự án

Hình 1.2: Tam giác dự án

2.4 Quy trình quản lý chi phí dự án

Quản lý chi phí dự án bao gồm những quy trình bảo đảm cho dự án được hoàn tất trong sự cho phép của ngân sách Bao gồm:

 Lập kế hoạch: xác định nguồn tài nguyên cần thiết và số lượng cần thiết để

thực hiện dự án

 Ước lượng các chi phí: từ số lượng nguồn tài nguyên cần thiết trên nhân

với giá thành trên một đơn vị ta có thể ước tính chi phí cần thiết

 Dự toán chi phí: phân bổ chi phí ước từng danh mục

 Kiểm soát và điều chỉnh chi phí: điều chỉnh thay đổi chi phí của dự án khi

có biến cố bất ngờ xảy ra

 Kết thúc dự án: tổng kết lại toàn bộ chi phí của dự án

Hình 1.3: Quy trình phát triển phần mềm

Lập kế

hoặch

Ước lượng các chi phí

Dự toán chi phí

Kiểm soát

và đều chỉnh

Kế thúc

dự án

2.5 Ước lượng chi phí phần mềm

Dự toán chi phí phần mềm là quá trình dự đoán nỗ lực cần thiết để phát triển một

hệ thống phần mềm Đây là một trong những việc mà bất cứ công ty nào cũng phải thực hiện khi muốn nhận một dự án từ khách hàng

Hình 1.4: Sự chệnh lệch giữa khối lượng và chi phí giữa ước lượng và thực tế

(Nguồn: COCOMO II Model Definition Manual (Barry Boehm - năm 2000))

Sơ đồ của Barry Boehm ở trên cho thấy sự sai lệch giữa kết quả của việc ước lượng

và thực tế.Ở giai đoạn bắt đầu thì những yêu cầu thực sự của phần mềm từ khách hàng chưa rõ ràng dẫn đến kết quả ước lượng và thực tế có thể khác nhau rất xa Càng về các giai đoạn sau thì sự ước lượng ngày càng chính xác hơn do các yêu cầu của khách hàng đã trở nên rõ ràng hơn nhiều

Trải qua nhiều năm phát triển cùng ngành công nghiệp phần mềm, có rất nhiều phương pháp ước lượng chi phí phần mềm được sử dụng cho đến ngày nay Mỗi phương pháp đều có ưu và nhược điểm riêng nên thường được sử dụng chung với nhau để có thể tận dụng ưu điểm và giảm bớt các khuyết điểm

2.6.1 Phương pháp ước lượng chuyên gia

Phương pháp ước lượng chuyên gia (Expert judgment method) là một kĩ thuật sử dụng kinh nghiệm của một chuyên gia hoặc một nhóm chuyên gia để ước lượng chi phí của dự án sử dụng kinh nghiệm có sẵn của họ Phương pháp thường được dùng

là kĩ thuật Delphi để thu thập ý kiến của những chuyên gia trong dự án hoặc những người có kiến thúc chuyên môn tốt

Các bước sử dụng phương pháp Delphi:

1 Một người gọi là điều phối viên sẽ có vai trò trình bày với tất cả các chuyên gia trong nhóm từng người một về một vấn đề cần ước lượng và đưa ra một mẫu điền kết quả ước lượng đã soạn sẵn

2 Người đó sẽ tổ chức một cuộc họp nhóm, trong đó các chuyên gia sẽ thảo luận về vấn đề ước lượng với những người khác

3 Các chuyên gia sẽ điền kết quả ước lượng theo ý mình vào các phiếu kết quả ước luợng đã được phát trước đó

4 Điều phối viên sẽ tổng hợp lại các kết quả ước lượng của các chuyên gia

5 Điều phối viên sau đó sẽ tổ chức một cuộc họp với các chuyên gia để tìm hiểu lý do nếu như có những chuyên gia có ước lượng quá cao hoặc quá thấp

so với những người khác Kết quả cuối cùng là kết quả được nhất trí trong cuộc họp này

Ưu điểm:

 Tận dụng được kinh nghiệm của những người đã tham gia vào nhiều dự án

có chức năng tương tự trong quá khứ

 Các chuyên gia có thể ước đóan được những tác động gây ra do việc ứng dụng những công nghệ hay kĩ thuật mới trong tương lai

 Việc sử dụng bảng câu hỏi và lấy kết quả có thể thực hiện thông qua email

và các công cụ đàm thoại qua Internet giúp lấy được ý kiến của nhiều chuyên gia ở xa

2.6.2 Phương pháp ước lượng từ trên xuống

Phương pháp ước lượng từ trên xuống (Top-down method) còn được gọi là mô hình vĩ mô (Macro Model) Khi sử dụng phương pháp này, chúng ta cần phải có ước lượng một mức chi phí lớn nhất có mà công ty có thể chấp nhận để thực hiện

dự án đó Sau đó, từ chi phí lớn nhất đó có thể phân chia thành những phần chi phí nhỏ ứng với những phần nhỏ hơn trong dự án Phương pháp này thường được sử dụng khi không có nhiều thông tin về dự án, hoặc các thông tin về dự án chưa được chắc chắn Phương pháp này thường sử dụng chi phí thực tế hoặc các dự án tương

tự trước đó để làm nền tảng cơ bản cho ước tính mới

 Do không cần nhiều các yếu tố đầu vào khi tiến hành ước lương, chỉ tập trung vào những phần lớn mà bỏ qua những phần nhỏ nên có thể làm cho ước lượng có độ chính xác không cao

2.6.3 Phương pháp ước lượng từ dưới lên

Phương pháp ước lượng từ dưới lên (Bottom-up method) này có cách thực hiện trái ngược với phương pháp ước lượng từ trên xuống (Top-down method) Phương pháp này ước lượng chi phí của dự án phần mềm bằng cách ước lượng chi phí của từng phần trong dự án rồi sau đó tính tổng của các thành phần đó để ra chi phí ước lượng cho toàn bộ dự án.

Ưu điểm:

 Cho phép ước lượng từng thành phần nhỏ nhất của dự án, do đó làm giảm đi

độ sai lệch do ước lượng một thành phần nhỏ thì chính xác hơn là ước lượng các thành phần lớn

Khuyết điểm:

 Phương pháp này chỉ tập trung vào những phần nhỏ nhưng chưa tính đến mức

hệ thống (high system level) hay nói cách khác là đã bỏ qua việc kết hợp các phần nhỏ lại với nhau khi hệ thống hoàn thiện

 Các thông tin chi tiết có thể chưa được ngay ban đầu nên làm việc ước lượng thiếu chính xác

 Việc ước lượng nhiều thành phần nhỏ làm tốn nhiều thời gian ước lượng

 Nếu có một giới hạn nếu thời gian và ngân sách bị giới hạn trước

2.6.4 Phương pháp giá để thắng

Phương pháp giá để thắng (Price to win method) này giá ước lượng của dự án sẽ được đưa ra dựa trên khả năng thanh toán của khách hàng Khi áp dụng phương pháp này, bên sản xuất phần mềm sẽ chấp nhận bất kì mức giá mà bên mua đưa ra

dù mức giá này là thấp hơn so với chí phí dùng để sản xuất phần mềm đó

2.6.6 Phương pháp ước lượng tương đương

Phương pháp ước lượng tương đương (Estimation by Analogy) sử dụng những dữ liệu cũ của công ty về những dự án tượng tự đã làm trong quá khứ Những dữ liệu này được sử dụng làm cơ sở tính toán cho dự án mới cần được ước lượng

Các bước thực hiện phương pháp này bao gồm:

1 Xác định các thuộc tính đặc trưng của dự án cần ước lượng

2 Chọn ra một dự án có các thuộc tính đặc trưng gần giống với dự án cần ước lượng nhất

3 Xác định chi phí ước lượng bằng cách so sánh hai dự án với nhau Lấy chi phí của dự án cũ để ước lượng chi phí cho những phần giống nhau ở dự án mới

 Khuyết điểm lớn nhất của phương pháp này là việc tìm kiếm một dự án có những đặc tính giống như dự án sắp ước lượng là điều rất khó Bởi thường yêu cầu của các dự án đến từ các khách hàng là khác nhau ngay trong cùng một dạng phần mềm chuyên dụng

2.6.7 Phương pháp ước lượng bằng công thức

Phương pháp ước lượng bằng công thức (Algorithmic Method) sử dụng các công thức toán học để ước lượng chi phí của dự án phần mềm Những công thức này được xây dựng dựa trên việc nghiên cứu các dữ liệu lịch sử và những yếu tố đầu vào như số lượng dòng mã lệnh, số lượng chức năng của chương trình và những yếu tố điều chỉnh chi phí như ngôn ngữ lập trình, kiến thức về hệ thống, kĩ năng của những người tham gia và những nguy cơ ảnh hưởng trực tiếp đến dự án Có rất nhiều mô hình ước lượng được xây dựng dựa trên phương pháp này như COCOMO, COCOMO II, Putnam …

Ưu điểm:

 Cho một kết quả nhất quán khi thực hiện nhiều lần

 Dễ dàng thay đổi các thông số đầu vào khi cần thiết

 Cho kết quả chính xác do không phụ thuộc vào các yếu tố khách quan

 Cần nhiều thời gian để khảo sát đánh giá các yếu tố điều chỉnh chi phí

 Có một vài thông số đầu vào rất khó đánh giá

2.6.8 Tổng kết ưu khuyết điểm của các phương pháp

Mỗi phương pháp có ưu điểm và khuyết điểm riêng, không phương pháp nào có thể bao trùm phương pháp khác Trong thực tế, người ta thường sử dụng hai hoặc nhiều phương pháp cùng lúc để có được kết quả chính xác hơn

Tốn nhiều thời gian

chính xác

Dễ dàng ước lượng

Dễ cho kết quả ước lượng sai

của các chuyên gia để giải quyết các ngoại lệ

Phụ thuộc chủ quan vào người đánh giá

Ước lượng tương đương Dựa trên những dữ liệu Tốn nhiều thời gian

thực tế

Những dữ liệu cập nhật thường xuyên giúp ước lượng chính xác hơn

Khó tìm ra được dự án có

độ tương đương cao

Ước lượng bằng công

Bảng 2.1: So sánh ưu và khuyết điểm của các phương pháp ước lượng

(Nguồn tham khảo: Software Engineering Economic (Barry Boehm năm 1981))

Để có thể ước lượng chi phí của một sản phẩm phần mềm một cách dễ dàng chính xác ta có thể chia quá trình ước lượng này ra làm mười bước nhỏ hơn Ở mỗi bước cần xác định rõ những gì cần làm, ai có trách nhiệm thực hiện việc đó và kết quả đạt được sẽ là gì Các bước được mô tả lần lượt trong bảng bên dưới

kế kiến trúc hệ thống và những yêu cầu về lập trình

Quản lý dự án, các trưởng nhóm lập trình, những người phân tích yêu cầu

Các yêu cầu bắt buộc phải thực hiện theo hợp đồng

Cách thức và thời gian thực hiện Kiến trúc của hệ thống

Cách thức tiến hành thực hiện

Bước 2: Xác định

và phân chia các

yêu cầu của dự án

thành các phần

công việc nhỏ hơn

Chia các yêu cầu lớn thành các yêu cầu nhỏ hơn để có thể thực hiện đồng thời hoặc theo thứ

tự nhất định

Đánh giá các nguy

Quản lý dự án, các trưởng nhóm lập trình

Sử dụng sơ đồ chia nhỏ công việc Danh sách các nguy cơ có thể xảy

ra của dự án

cơ có thể xảy ra khi thực hiện

Bước 3: Ước

lượng khối lượng

của dự án

Sử dụng phương pháp tính điểm chức năng Function Point

Sử dụng phương pháp đếm số lượng

mã dòng lệnh (SLOC)

Quản lý dự án, những chuyên gia

có kinh nghiệm ước lượng

Sử dụng các phương thức ước lượng ở cấp thấp

Ra được ước lượng

cơ bản dựa trên số lượng dòng lệnh

Quản lý dự án, những chuyên gia

có kinh nghiệm ước lượng

Sử dụng các phương thức chuyển đổi

Chỉ có thể ước lượng ở mức độ chính xác thấp Phải đặt ra nhiều giả thuyết do chưa

có nhiều thông tin

Quản lý dự án, những chuyên gia

có kinh nghiệm ước lượng

Ước lượng phải đảm bảo hoàn thành tất cả các yêu cầu của khách hàng

Đảm bảo các phiên bản được giao cho khách hàng đúng thời hạn để khách hàng có thể kiểm tra

Điều chỉnh lại các ước lượng nếu cần thiết

Bước 6: Ước

lượng tổng chi phí

cần thiết

Ước lượng tổng chi phí cần thiết để hoàn thành dự án

Quản lý dự án, những chuyên gia

có kinh nghiệm ước lượng

Bản chi tiết tổng hợp chi phí cần thiết

các yếu tố nguy cơ

gây ảnh hưởng đế

dự án

nguy cơ có thể làm ảnh hưởng đến dự

án Xác định nguyên nhân và các phòng tránh

những chuyên gia

có kinh nghiệm ước lượng và những người đầu

tư

các yếu tố nguy cơ Phương pháp phòng tránh Điều chỉnh lại ước lượng nếu cần thiết

để làm tăng độ chính xác của ước lượng

Quản lý dự án, những chuyên gia

có kinh nghiệm ước lượng và những người đầu

tư

Giải quyết và điều chỉnh lại các ước lượng sai

Quản lý dự án, những chuyên gia

có kinh nghiệm ước lượng và những người đầu

tư

Kí kết hợp đồng của dự án

để thực hiện điều chỉnh nếu cần thiết

Quản lý dự án, những chuyên gia

có kinh nghiệm ước lượng và những người đầu

tư

Giải quyết và điều chỉnh lại các ước lượng sai

Bước 11: Kết thúc

dự án

Đánh giá kết quả đạt được và kết thúc hợp đồng

Quản lý dự án, khách hàng

Thu thập dữ liệu của dự án để sử dụng cho các ước lượng sau

Bảng 2.2: Các bước ước lượng chi phí dự án

2.8 Số lượng dòng lệnh

Số lượng dòng lệnh (Source Line Of Code) của dự án phần mềm là được sử dụng

để xác định quy mô của của phần mềm bằng cách đếm số lượng dòng lệnh trong

mã nguồn dự án Phương pháp này thường được sử dụng để đo lường khối lượng công việc mà các lập trình viên cần thiết phải thực hiện để phát triển một phần mềm Nó cũng được sử dụng để ước lượng hiệu quả công việc của các lập trình viên hoặc ước lượng khối lượng công việc cần thiết phải bỏ ra để bảo trì phần mềm

2.8.1 Các phương pháp đếm số lượng dòng lệnh

Có hai phương pháp đếm số lượng dòng lệnh: phương pháp vật lý (physical SLOC)

và phương pháp luận lý (logical SLOC)

Phương pháp vật lý đếm số lượng dòng lệnh trong các tập tin của chương trình bao gồm cả những dòng chú thích của chương trình Số lượng dòng trống cũng được nhưng không vượt quá 25% [3] tổng số dòng lệnh

Phương pháp luận lý đếm số lượng dòng lệnh thực tế Điều này là một vấn đề khó

vì các ngôn ngữ lập trình chưa theo một hệ chuẩn thống nhất (ví dụ trong Java một

lệnh kết thúc bằng dấu ; trong khi các lệnh trong Python thì không cần) Do đó

phương pháp luận lý cho ta một kết quả chính xác hơn do không chịu ảnh hưởng của cách viết lệnh mà chỉ căn cứ vào số dòng lệnh thực tế Tuy vậy việc tạo ra một công cụ đếm số lượng dòng lệnh theo phương pháp luận lý thì khó khăn hơn phương pháp vật lý nhiều do số lượng ngôn ngữ lập trình tương đối nhiều và sự thay đổi của chúng qua các phiên bản

Theo quy ước của Samuel Conte thì chỉ những dòng lệnh thực sự tham gia vào làm cho chương trình hoạt động mới được tính, các dòng trống và các dòng ghi chú đều không được tính khi đếm số dòng lệnh của chương trình

Khi bắt tay vào việc thực hiện một dự án, đầu tiên là cần phải xác định được khối lượng công việc, từ đó có thể tính toán được chi phí về tài nguyên (con người, thời gian, tiền bạc…) Để tính được khối lượng công việc cho một dự án phần mềm, ngoài phương pháp tính số dòng lệnh (SLOC) còn có thể sử dụng phương pháp phân tích các điểm chức năng (Function Point Analysis - FPA)

Phân tích các điểm chức năng là một phương pháp được ISO chấp nhận, dùng để xác định kích thước về mặt chức năng của một hệ thống thông tin Functional size phản ánh số lượng chức năng liên quan tới và được chấp nhận bởi người dùng trong doanh nghiệp Nó hoàn toàn độc lập với công nghệ được sử dụng để triển khai hệ thống Đơn vị dùng để đo lường được gọi là điểm chức năng (Function points - FPs) Phương pháp FPA biểu diễn độ lớn của hệ thống bằng số lượng các FPs Khái niệm FP được đưa ra bởi Allan Albrecht[16] vào giữa những năm 1970 nhằm thay thế cho phương pháp đo lường kích thước phần mềm bằng cách đếm số dòng mã

lệnh, sau đó được IBM xuất bản vào năm 1979, và sau đó là IEEE tái bản vào năm

1981

2.9.1 Mục tiêu

1 Tính toán số chức năng dựa trên góc nhìn của người sử dụng về các chức năng của hệ thống

2 Giảm thiểu hóa công sức, chi phí dùng cho việc tính toán, đo đạc

3 Thiết lập nên một phương pháp đo đạc thống nhất giữa các tổ chức

2.9.2 Lợi ích

1 Có thể xác định được kích thước của phần mềm từ sớm trong quy trình phát triển khi chỉ có các yêu cầu của khách hàng

2 Giữ vai trò như một phương pháp đo lường căn bản

3 Độc lập với công cụ và môi trường phát triển vì chỉ căn cứ vào số lượng chức năng của chương trình

4 Cung cấp phương pháp đo lường kích thước thống nhất giữa các nhóm và tổ chức

5 Là công cụ quan trọng để xác định năng suất, ước lượng chi phí, công sức

4 Xác định hệ số cân đối (Value Adjusted Factors)

5 Xác định số lượng Function Points cân đối

2.9.4 Phân loại

Có năm loại điểm chức năng khác nhau thường thấy trong một dự án, năm loại điểm này được chia làm hai nhóm là nhóm liên quan đến nhập xuất dữ liệu và nhóm liên quan đến các thao tác xử lí dữ liệu

 Nhóm liên quan đến nhập xuất dữ liệu

 Các chức năng nhập vào (External Input - EI) được tính từ các chức năng cho phép thu nhận dữ liệu từ người dùng như đánh từ bàn phím hay nhập dữ liệu tự động từ các tập tin được cung cấp sẵn

 Các chức năng xuất ra (External Output - EO) được tính từ các chức năng cho phép ghi lại các dữ liệu đã được thu nhận và xử lý xuống các tập tin hoặc cơ sở dữ liệu hoặc xuất ra cho người dùng có thể nhìn thấy

 Nhóm liên quan đến các thao tác xử lí dữ liệu

 Các thao tác có sử dụng các tập tin chương trình (Internal Logical File - ILF) được tính từ các chức năng bắt buộc phải sử dụng các tập tin của chương trình để co thể hoạt động

 Các thao tác có xuất ra các tập tin cho các chương trình khác (External Logical File - ELF) được tính từ các chức năng có liên quan đến việc xuất

dữ liệu ra giao diện chương trình để người dùng nhìn thấy

 Các thao tác có liên quan đến các tập tin do người dùng tạo ra (External Inquiry - EQ) được tính từ các chức năng có liên quan đến các thao tác do người dùng tự thao tác để nhập và xuất dữ liệu để khai thác thông tin

Hình 1.5: Các điểm chức năng

(Nguồn: http://www.softwarems.com/consulting/whatarefp.shtml)

Do việc ước lượng số lượng dòng lệnh ngay từ khi bắt đầu dự án là một công việc khó khăn, tốn rất nhiều thời gian và kết quả lại có độ chính xác không cao nên người ta thường dùng phương pháp bắc cầu khi muốn ước lượng bằng COCOMO

II Người ta có thể sử dụng một bảng đơn vụ chuyển đổi để chuyển đổi điểm chức năng thành số lượng dòng lệnh

Có rất nhiều bảng chuyển đổi khác nhau được đề nghị như bảng của Jones vào năm

1991 tuy nhiên bảng chuyển đổi này đã cũ và không còn phù hợp với hiện nay do

có rất ít ngôn ngữ còn được sử dụng để phát triển các phần mềm hiện đại