Luận văn thạc sĩ Hệ thống thông tin quản lý: Á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

TỔNG QUAN CỞ SỞ LÝ THUYẾT

Phần mềm

Phần mềm hay còn gọi là phần mềm máy tính là một tập hợp những câu lệnh hoặc chỉ thị được viết bằng một hoặc nhiều ngôn ngữ lập trình theo một trật tự xác định, và các dữ liệu hay tài liệu liên quan nhằm tự động thực hiện một số nhiệm vụ hay chức năng hoặc giải quyết một vấn đề cụ thể nào đó.

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

Là lượng tài nguyên phải tiêu tốn để đạt được một mục tiêu cụ thể rõ ràng nào đó

Chi phí thường được quy ra thành tiền

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

Là quy trình yêu cầu đảm bảo dự án được hoàn thành trong giới hạn chi phí đã được dự tính trước

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

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

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í

Kiểm soát và đều chỉnh

Ướ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

2.6 Các phương pháp ước lượng chi phí phổ biến

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

 Việc tạo ra bảng câu hỏi để các chuyên gia điền vào rất khó khăn và tốn nhiều thời gian để thực hiện

Một số chuyên gia trong một số trường hợp có thể có những thành kiến hoặc kinh nghiệm chưa chính xác, phụ thuộc vào kinh nghiệm thực tế của họ trong quá khứ về vấn đề đó.

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 Ưu điểm:

 Thích hợp để ước lượng khi những thông tin về dự án không đầy đủ và không thể dùng các phương pháp khác vốn đòi hỏi nhiều yếu tố đầu vào

 Đây là một phương pháp nhanh và dễ thực hiện do không đòi hỏi phải thu thập nhiều thông tin về dự án trước khi thực hiện ước lượng

 Hầu hết các dự án, đặc biệt là các dự án về lĩnh vực phần mềm thường có đặc điểm chung là thay đổi nhanh về mặt công nghệ và yêu cầu của khách hàng nên phương pháp này không đáp ứng tốt

 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

Phương pháp này chú trọng giải quyết từng phần nhỏ lẻ mà chưa tính đến toàn hệ thống, tức là chưa có sự phối hợp giữa các phần nhỏ để tạo thành một hệ thống hoàn chỉnh khi vận hành.

 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

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

Để 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

Bước Mô tả Người thực hiện Kết quả

Bước 1: Thu thập và phân tích các yêu cầu về phần mềm

Tiếp nhận các yêu cầu từ phía khách hàng, phân tích tính khả thi, thiết 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

Bước 4: Ước lượng công sức cần thiết phải bỏ ra để hoành thành dự án

Sử dụng số lượng dòng mã lệnh để tính nỗ lực cần thiết phải có để hoàn thành dự án đúng thời hạn

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

Bước 5: Lên kế hoạch để thực hiện

Sử dụng ước lượng về nỗ lực cần thiết để hoàn thành dự án từ đó ước tính lượng thời gian và nhân lực để có thể hoàn thành dự án

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

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

Bước 7: Xác định Tìm ra các yếu tố Quản lý dự án, Bản mô tả chi tiế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

Bước 8: Điều chỉnh lại ước lượng dựa trên chi phí và thời gian

Kiểm tra lại tất cả các ước lượng có hợp lý về thời gian cũng như chi phí hay chưa nếu không thì cần phải điều chỉnh lại cho hợp lý

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 9: Chấp thuận ước lượng giữa các bên

Các ước lượng trên chuyển thành các bảng kế hoạch và được sự đồng ý nhất trí cao giữa các bên

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

Bước 10: Tiến hành thực hiện dự án

Việc tiến hành dự án cần luôn đi đôi với quá trình kiểm tra, theo dõi và báo cáo thường xuyên Điều này giúp các bên liên quan đánh giá được tiến độ, kết quả và những vấn đề phát sinh trong quá trình thực hiện Từ đó, có thể kịp thời thực hiện những điều chỉnh cần thiết để đảm bảo dự án được hoàn thành đúng mục tiêu, chất lượng và hiệu quả.

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

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

Xét dòng lệnh sau for (i = 0; i < 100; i += 1) println(i); //Print numbers

Theo phương pháp vật lý: 1 Theo phương pháp luận lý: 2 (1 cho for và 1 cho println)

Số lượng dòng ghi chú: 1 Cùng một ví dụ như trên nhưng nếu ta viết theo cách trình bày khác

Theo phương pháp vật lý: 3 Theo phương pháp luận lý: 2 (1 cho for và 1 cho println) Số lượng dòng ghi chú: 1

Về phương pháp đếm số lượng dòng lệnh theo phương pháp vật lý cũng có nhiều tiêu chuẩn khác nhau Trong phạm vi luận văn sẽ sử dụng phương pháp của Samuel Conte dựa vào bảng checklist

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.

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

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

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

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

1 Xác định loại dự án (phát triển dự án mới, nâng cấp dự án hay chỉ đánh giá một dự án đã có)

2 Xác định phạm vi của dự án

3 Xác định số lượng Function Points chưa điều chỉnh (Unadjusted Function Points)

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

5 Xác định số lượng Function Points cân đố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) dùng để thu thập dữ liệu từ người dùng dưới các hình thức như gõ bàn phím hoặc tự động nhập dữ liệu 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)

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

Do ước lượng số lượng dòng lệnh ở đầu dự án khá khó khăn, tốn thời gian và độ chính xác không cao, phương pháp cầu bắc trong COCOMO II ra đời để giải quyết vấn đề này Bằng cách sử dụng bảng chuyển đổi đơn vụ, người ta có thể chuyển đổi các điểm chức năng thành số lượng dòng lệnh, giúp việc ước lượng trở nên dễ dàng và nhanh chóng hơn.

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

Ngôn ngữ lập trình SLOC/UFP

Assemply (Macro) 213 ANSI/Quick/Turbo Basic 64 Basic – Complied 91

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

(Nguồn: COCOMO II Model Definition Manual v1.4 – Barry Boehm)

Bảng chuyển đổi thứ hai được đề nghị tại trang www.qsm.com QSM là một tổ chức lớn và uy tính chuyện về ước lượng dự án Bảng số liệu chuyển đổi do họ đưa ra được tổng kết từ cơ sở dữ liệu gồm 2786dự án đã hoàn thành dùng điểm chức năng để làm phương pháp ước lượng

Ngôn ngữ lập trình QSM SLOC/FP Data

Trung bình - Avg Trung bình - Median Thấp Cao

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

(Nguồn tham khảo: http://www.qsm.com/resources/function-point-languages-table)

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

COCOMO lần đầu tiên được công bố trong Boehm 1981 cuốn sách Software Engineering Economics như là một mô hình để ước tính, chi phí và tiến độ cho các dự án phần mềm Được xây dựng trên một nghiên cứu về 63 dự án tại TRW Aerospace mà Boehm là giám đốc nghiên cứu phần mềm và công nghệ Nghiên cứu đã xem xét các dự án khác nhau, kích thước từ 2.000 đến 100.000 dòng mã, và các ngôn ngữ lập trình khác nhau, từ Assembly đến PL/I Các dự án này phát triển theo mô hình thác nước (Waterfall) là quy trình phát triển phần mềm phổ biến nhất vào năm 1981

COCOMO còn được gọi là COCOMO 81 Năm 1995 COCOMO II đã được phát triển và cuối cùng được công bố vào năm 2000 COCOMO II là sự kế thừa các đặc tính của COCOMO 81 và phù hợp hơn với ước tính các dự án phát triển phần mềm

Nó cung cấp nhiều sự hỗ trợ cho quá trình phát triển phần mềm hiện đại

Ngoài COCOMO II và COCOMO còn có rất nhiều các phiên bản khác nhau phục vụ cho các mục đích ước lượng khác nhau

Hình 1.6: Các dạng mô hình liên quan đến COCOMO (Nguồn tham khảo: COCOMO Suite Methodology and Evolution[22])

Ba mô hình COCOMO II, COINCOMO và DBA COCOMO có những điểm tương đồng như nhau nhưng phục vụ những mục đích khác nhau

Những dạng thông dụng khác bao gồm:

 COQUALMO được sử dụng để ước lượng các lỗi còn lại trong sản phẩm phần mềm

 iDave dùng để ước tính và theo dõi lợi nhuận có được dựa trên mức đầu tư

 COPLIMO hỗ trợ ước lượng dự đoán chi phí và lợi nhuận dựa trên việc phân tích đầu tư

 COPSEMO hỗ trợ việc ước tính phân phối theo từng giai đoạn và thường được sử dụng với CORADMO

 COPROMO dự báo việc phân bổ chi phí sao cho hiệu quả nhất các nguồn lực đầu tư vào các công nghệ mới nhằm nâng cao năng suất

COCOMO II được đánh giá là một trong những phương pháp hiệu quả nhất để ước lượng chi phí dự án Nó cung cấp thêm 17 yếu tố điều chỉnh chi phí (Cost Drivers) giúp cho việc ước lượng chi phí hiệu quả và chính xác hơn

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

(Nguồn: A Winsor Brown, COCOMO + COCOTS Tutorial 2010)

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

= × ( ) (Nguồn: COCOMO II Model Definition Manual [15])

PM là số lập trình viên làm việc trong một thời gian tính theo tháng

Size là số lượng dòng lệnh được tính theo đơn vị hàng ngàn (KSLOC) Nó có thể được tính bằng cách chuyển từ các điểm chức năng qua số lượng dòng lệnh và chia cho 1000

B là con số đại diện cho các yếu tố điều chỉnh có ảnh hưởng đến dự án

A là con số đại diện cho nỗ lực để hoàn thành một ngàn dòng lệnh Con số này sẽ thay đổi theo các dạng dự án khác nhau

Công thức trên của COCOMO II được sử dụng trong dạng hai dự án:

 Mới bắt đầu (Early Design Model): ở dạng này chỉ mới khởi động dự án, mọi yêu cầu của khách hàng cũng như cách thực hiện chưa rõ ràng

 Đang thực hiện (Post Architecture): ở dạng này mọi yêu cầu của khách hàng cũng như cách thực hiện đã rõ ràng

William Roetzheim thuộc tổ chức Cost Xpert Group [25]đã nghiên cứu 20000 dự án phần mềm trong 18 năm và đã đưa ra số liệu cho một số dạng dự án khác ngoài con số chuẩn của mô hình COCOMO II giúp cho việc ước lượng dễ dàng và chính xác hơn Số liệu được liệt kê trong bảng sau:

Phần mềm thương mại điện tử 3.08 1.030 Ứng dụng web 2.51 1.030

Phần mềm dành cho quân đội 3.97 1.072

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

(Nguồn: Project Cost Adjustments, Cost Xpert Group[25])

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

Các yếu tố xác định quy mô (Scaling Factors) đại diện bởi B trong công thức ước lượng chính của mô hình COCOMO II Mỗi loại yếu tố sẽ có sáu cấp độ khác nhau từ rất thấp cho đến rất cao Mỗi ấp độ có một trọng số W khác nhau và một giá trị tương ứng với trọng số đó gọi là Tổng tất cả các giá trị sẽ có B theo công thức

= 1.01 + 0.01 × ∑ (Nguồn: COCOMO II Model Definition Manual [15])

2.11.2.1 Yếu tố quen thuộc và khả năng hoạt động linh hoạt

Yếu tố quen thuộc (Precedentedness (PREC)) được sử dụng để ước lượng một dự án giống với nhiều dự án đã được phát triển trước đây Nếu dự án mới có nhiều đặc điểm giống dự án cũ thì yếu tố quen thuộc sẽ có giá trị cao Đặc điểm Rất thấp Bình thường/Cao Rất cao

Mức độ hiểu biết về tính năng sản phẩm phần mềm

Bình thường Đáng kể Hoàn toàn

Kinh nghiệm làm việc với những phần mềm tương tự

Vừa phải Đáng kể Lớn

Sự phát triển của các phần cứng và hệ điều hành

Sự cần thiết cải tiến quá trình xử lý dữ liệu và thuật toán Đáng kể Ít Rất nhỏ

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

Khả năng hoạt động một cách linh hoạt (Development Flexibility (FLEX)) là khả năng đáp ứng đầy đủ các yêu cầu của người dùng về chức năng và về giao diện chương trình cũng như khả năng hoàn thành đúng thời hạn Đặc điểm Rất thấp Bình thường/Cao Rất cao

Yêu cầu phần mềm phải đúng với những yêu cầu đã được quy định trước

Hoàn toàn Đáng kể Cơ bản

Yêu cầu phần mềm phải đúng với những đặc tả về giao diện

Hoàn toàn Đáng kể Cơ bản

Sự kết hợp hai yếu tố trên và hoàn thành dự án đúng thời hạn

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

2.11.2.2 Các yếu tố nguy cơ

Các yếu tố nguy cơ (Architecture / Risk Resolution (RESL)) là các yếu tố có thể xảy ra và làm ước lượng không chính xác Bao gồm hai loại là PDR (Product Design Review) và LCA (Life Cycle Architecture) Đặc điểm Rất thấp

Xác định rõ tất cả các nguy cơ bất lợi và ước lượng thời gian giải quyết

Không xác định Ít Một số Trung bình

Lập kế hoạch, xác định chi phí và những bản phát hành nội bộ

Không xác định Ít Một số Trung bình

Phần trăm khối lượng công việc dùng cho việc tạo ra kiến trúc hệ thống

Phần trăm khối lượng công việc dùng cho việc tìm kiếm những phần mềm thích hợp cho dự án

Những công cụ sử dụng cho việc phát triển phần mềm và giải quyết các rủi ro

Không xác định Ít Đơn giản

Tốt Rất tốt Xuất sắc

Mức độ không nắm chắc về: mục tiêu,

Hơi thấp Thấp Ít Rất ít giao diện, phần cứng, phần mềm và tốc độ xử lý

Số lượng của các yếu tố nguy cơ

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

2.11.2.3 Khả năng hoạt động nhóm

Khả năng làm việc nhóm Team Cohesion (TEAM) đo lường sự bất đồng của những người có liên quan đến dự án như: người sử dụng, người phát triển, người bảo trì, khách hàng v.v… Những bất đồng này chủ yếu là do mức độ hiểu biết khác nhau về phần mềm hay quy trình làm việc, đôi khi cũng do những khác biệt về cách làm việc Đặc điểm Rất thấp Thấp Bình thường

Cao Rất cao Tuyệt đối

Sự ổn định về mục tiêu và cách làm việc của những người có liên quan đến dự án

Thấp Ít Trung bình Đáng kể Cao Tốt

Khả năng và sự hài lòng của những người liên quan đến dự án

Thấp Ít Trung bình Đáng kể Cao Tốt

Không có Thấp Ít Trung bình Đáng kể Tốt

Sự chia sẻ viễn cảnh, mục tiêu

Không có Thấp Ít Trung bình Đáng kể Tốt

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

2.11.2.4 Phát triển theo quy trình

Phát triển theo quy trình Process Maturity (PMAT) đo lường về tiêu chuẩn, sự cẩn thận trong phát triển phần mềm.Tiêu chuẩn để đánh giá dựa trên tiêu chuẩn CMM (Software Engineering Institute’s Capability Maturity Model) Đánh giá này cần được thực hiện ngay từ khi dự án bắt đầu thực hiện

Mô hình trưởng thành năng lực (Institute’s Capability Maturity Model - CMM) được thay thế bằng Mô hình trưởng thành năng lực tích hợp (Institute’s Capability Maturity Model Integration- CMMI) và là khuôn khổ cho cải tiến qui trình phần mềm Nó dựa trên khái niệm về các thực hành tốt nhất về kĩ nghệ phần mềm và giải thích kỉ luật mà các công ty có thể dùng để cải tiến các qui trình của họ

CMM có 5 mức đánh giá chuẩn Bao gồm:

CMM bao gồm 18 vùng quy trình quan trọng (Key Procress Areas - KPAs) 18 vùng quy trình quan trọng này thuộc vào các mức khác nhau

 Mức 1: không có vùng quy trình quan trọng

 Mức 2: có 6 vùng quy trình quan trọng

Vùng quy trình quan trọng

Luôn luôn Thường xuyên Khoảng một Đôi khi Hiếm khi Không sử dụng Không biết

1 Lấy và quản lý yêu cầu của khách hàng

A1 Yêu cầu hệ thống được xác định rõ rang

A2 Kế hoạch, sản phẩm và những hoạt động phát triển được đảm bảo phù hợp với yêu cầu hệ thống

2 Lập kế hoạch cho dự án

B1 Những uớc lượng được ghi lại bằng văn bản và sử dụng khi lên kế hoạch và theo dõi tiến độ dự án

B2 Những hoạt động phát triển phần mềm được lên kế hoạch và ghi lại bằng văn bản

B3 Các nhóm và cá nhân có liên quan đến dự án thực hiện đúng như kế hoạch

3 Theo dõi kiểm tra tiến độ dự án

C1 Kết quả thực tế và chất lượng được ghi nhận và so sánh với bản kế hoạch

C2 Thực hiện việc sửa chữa khi kết quả kiểm tra không đạt như trong kế hoạch

C3 Những thay đổi liên quan đến phần mềm cần được sự thống nhất của các nhóm và các cá nhân có liên quan

4 Quản trị hợp đồng phụ phần mềm

D1 Nhà sản xuất lựa chọn những nhà thầu phụ có chất lượng tốt

D2 Nhà sản xuất và những nhà thầu phụ tuân thủ các cam kết của họ với nhau

D3 Nhà sản xuất và những nhà thầu phụ duy trì liên lạc một cách thường xuyên

D4 Nhà sản xuất thường xuyên kiểm tra chất lượng công việc của các nhà thầu phụ

5 Đảm bảo chất lượng sản phẩm

E1 Những kế hoạch quản lý chất lượng phần mềm được lên kế hoạch một cách đầy đủ

E2 Tuân thủ đầy đủ các tiêu chuẩn sản xuất phần mềm và các yêu cầu được kiểm tra một cách khách quan

E3 Các nhóm phát triển và các cá nhân được thông báo đầy đủ về hoạt động và kết quả kiểm tra chất lượng phần mềm

E4 Những vi phạm không tuân thủ các nguyên tắc đảm bảo chất lượng được giải quyết bởi những nhà quản lý có đủ thẩm quyền và trách nhiệm

6 Quản trị cấu hình sản phẩm

F1 Kế hoạch quản trị cấu hình sản phẩm được lên kế hoạch đầy đủ

F2 Sản phẩm phần mềm được xác định, có thể điều khiển được và sẵn sàng hoạt động

F3 Những thay đổi có liên quan đến sản phẩm phải được kiểm soát một cách chặt chẽ

F4 Những nhóm và cá nhân được thông báo về tình trạng và nội dung về giới hạn của phần mềm

7 Tập trung tiến trình tổ chức

G1 Quy trình phát triển và cải tiến phần mềm được hợp tác xuyên suốt tổ chức

G2 Các điểm mạnh và yếu của quy trình phát triển phần mềm được so sánh với các quy trình chuẩn

G3 Có kế hoạch nhằm cải tổ và nâng cấp quy trình phát triển

8 Định nghĩa quy trình tổ chức

H1 Tổ chức có một quy trình làm việc được phát triển và bảo trì

H2 Những tài liệu có liên quan đến quy trình làm việc của tổ chức được thu thập, xem xét và luôn sẵn sàng được sử dụng

I1 Những kế hoạch huấn luyện đã được lên kế hoạch

I2 Cung cấp những khóa huấn luyện về phát triển kĩ năng và kiến thức để quản lý dự án và công nghệ

I3 Các cá nhân và những nhóm phát triển phần mềm được huấn luyện một cách đầy đủ để có thể thực hiện công việc

10 Quản trị phần mềm tích hợp

J1 Quy trình phát triển phần mềm phải thích hợp với quy trình tiêu chuẩn của dự án

J2 Dự án được lên kế hoạch và phát triển theo tiêu chuẩn theo quy trình phát triển phần mềm

11 Sản xuất sản phẩm phần mềm

K1 Những công việc được định nghĩa, có quan hệ với nhau và thống nhất với nhau trong một phần mềm

K2 Những sản phẩm phần mềm cần phải được giữ cho đồng nhất với nhau

12 Phối hợp nhóm làm việc

L1 Những yêu cầu của khách hàng cần phải được tất cả các nhóm phát triển hiểu rõ và thống nhất ý kiến thực hiện

L2 Tất cả các cam kết giữa nhóm lập trình được thỏa thuận và được sự đồng thuận của những người có liên quan

L3 Nhóm phát triển phần mềm cần theo dõi, phát hiện và sửa chữa các lỗi phát sinh

M1 Tất cả các hoạt động đều được lên kế hoạch

M2 Những lỗi trong sản phẩm phần mềm cần phải được phát hiện và sửa chữa

14 Quản lý quá trình định lượng

N1 Những hoạt động của quy trình định lượng được lên kế hoạch

N2 Các hoạt động phát triển phần mềm được kiểm soát về mặt số lượng

N3 Tiêu chuẩn khả năng xử lý quá trình phát triển phần mềm của tổ chức được định lượng

15 Quản lý chất lượng phần mềm

O1 Kế hoạch kiểm tra chất lượng của phần mềm được lên kế hoạch trước

O2 Những tiêu chuẩn về chất lượng và độ ưu tiên được xác định

O3 Quá trình kiểm tra chất lượng phần mềm được kiểm soát và đánh giá

P1 Kế hoạch phòng ngừa lỗi được lên kế hoạch

P2 Nguyên nhân của các lỗi phổ biến được xác định

P3 Nguyên nhân của các lỗi phổ biến được ưu tiên phát hiện và loại bỏ một các có hệ thống

17 Quản lý thay đổi công nghệ

Q1 Kế hoạch sử dụng và thay đổi các ông nghệ có liên quan đến dự án được lân kế hoạch trước

Q2 Những công nghệ mới được đánh giá hiệu quả và tác động lên chất lượng và khối lượng công việc

Q3 Những công nghệ mới được sử dụng trong tổ chức một các bình thường

18 Quản lý thay đổi quy trình

R1 Việc cải tiến các quy trình được lên kế hoạch liên tục

R2 Các hoạt động cải tiến quy trình được thực hiện trên diện rộng

R3 Các quá trình phát triển phần mềm cần được nâng cấp một cách liên tục

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

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

Có 17 loại yếu tố điều chỉnh chi phí (Cost Drivers) được sử dụng trong COCOMO II trong mô hình Post Architecture để điều chỉnh công thức tính nỗ lực của người làm theo tháng Personal Months, những yếu tố này phản ánh những ảnh hưởng khác có thể làm ảnh hưởng đến việc tính chi phí phát triển sản phẩm phần mềm

Các yếu tố này được chia ra làm bốn loại:

 Các yếu tố liên quan đến sản phẩm

 Các yếu tố liên quan đến nền tảng

 Các yếu tố liên quan đến con người

 Các yếu tố liên quan đến dự án

2.11.3.1 Các yếu tố liên quan đến sản phẩm

2.11.3.1.1 Độ tin cậy của phần mềm (RELY – Required Software Reliability)

Yếu tố này nhằm đo lường sự ổn định của sản phẩm phần mềm trong một thời gian

Mức độ Rất thấp Thấp Trung bình

Cao Rất cao Tuyệt đối Đánh giá Ổn định, đáp ứng yêu cầu sử dụng Độ ổn định ít hơn , có thể khôi phục lại Độ ổn định trung bình, có thể khôi phục lại

Có thể gây ra thiệt hại

Làm ảnh hưởng đến cuộc sống con người

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

2.11.3.1.2 Kích thước của dữ liệu (Data – Data Base Size)

Yếu tố này đo lường độ lớn của dữ liệu ảnh hưởng đến quá trình phát triển phần mềm.Kích thước dữ liệu sẽ ảnh hưởng đến phát triển phần mềm do cần phải tốn thời gian và công sức để tạo ra những dữ liệu giả để phát triển và kiểm thử chương trình

Sử dụng tỷ lệ D/P để xác định

D là kích thước của data tính bằng byte P là kích thước của chương trình tính bằng SLOC

Rất thấp Thấp Trung bình

Cao Rất cao Tuyệt đối Đánh giá Không xác định

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

2.11.3.1.3 Độ phức tạp của dự án (CPLX – Product Complexity)

Tóm tắt chương hai

Chương này giới thiệu về các phương pháp ước lượng cũng như nêu ra ưu khuyết điểm của từng phương pháp Nêu ra các bước ước lượng chi phí cho một phần mềm từ ban đầu cho đến khi kết thúc

Nêu ra hai phương pháp dùng để tính khối lượng của phần mềm là sử dụng số dòng mã lệnh và điểm chức năng, cách chuyển đổi từ điểm chức năng ra số lượng dòng mã lệnh để có thể sử dụng COCOMO II

Giải thích chi tiết về mô hình COCOMO II cùng các yếu tố quy mô và các yếu tố điều chỉnh chi phí sử dụng trong chương trình nhằm làm tăng hiệu quả ước lượng.

PHƯƠNG PHÁP NGHIÊN CỨU

Quy trình nghiên cứu

Nghiên cứu mô hình COCOMO II và các yếu tố điều chỉnh của mô hình từ đó áp dụng để ước lượng chi phí cho các dự án của công ty phần mềm Xác định một số yếu tố có ảnh hưởng nhiều hơn so với các yếu tố khác

Tìm ra các điểm mạnh và điểm yếu của mô hình COCOMO II để từ đó đề ra một số phương pháp cải tiến

Nghiên cứu quá trình ước lượng chi phí của dự án thông qua việc chuyển đổi các chức năng của hệ thống sử dụng Unadjusted Function Points (UFPs) và sau đó là thành dòng mã lệnh (SLOC) để làm tham số đầu vào cho COCOMO II Quá trình này không những giúp đơn giản quá trình ước lượng mà còn làm tăng độ chính xác của việc ước lượng

Sử dụng một số dự án phần mềm để kiểm định độ chính xác của mô hình COCOMO II

Cuối cùng là kết luận và kiến nghị những giải pháp từ kết quả nghiên cứu, đồng thời nêu lên những hạn chế của nghiên cứu cùng với hướng nghiên cứu trong tương lai.

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

Từ chi phí dự đoán của COCOMO II so sánh với chi phí thực tế phát sinh của một phần mềm được phát triển ở công ty để so sánh độ chính xác của mô hình khi áp dụng trong điều kiện của công ty Edge-Works Software Ltd Đề tài sẽ khảo sát trên những yếu tố cốt lõi ảnh hưởng đến việc ước lượng chi phí cho dự án như: a Độ phức tạp của dự án b Số lượng các chức năng cần phải có c Khả năng của các thành viên trong dự án d Kinh nghiệm của các thành viên đối với các công nghệ được sử dụng trong dự án e Sự thay đổi yêu cầu của người sử dụng f Ngôn ngữ lập trình và hệ cơ sở dữ liệu được sử dụng g Số lượng các thành viên trong nhóm h Mức độ đầy đủ của các tài liệu mô tả của dự án i Mức độ thành thạo của các thành viên đối với phần cứng và phần mềm được sử dụng.

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

Công cụ được sử dụng để đếm số lượng dòng lệnh có tên là cloc phiên bản 1.5.5 được cung cấp miễn phí tại trang web http://cloc.sourceforge.net/ của Al Danial. Đây là một công cụ nguồn mở miễn phí (Giấy phép GNU General Public License v2) Công cụ này có khả năng đếm số lượng dòng mã thuộc nhiều ngôn ngữ khác nhau, ngoài ra nó còn có khả năng đếm số lượng các dòng trống và các dòng chú thích Công cụ này được phát triển bằng ngôn ngữ lập trình Perl

Lý do chọn công cụ cloc là vì:

 Có kích thước nhỏ gọn, dễ dàng sử dụng

 Là một phần mềm dạng không cần cài đặt sử dụng trong môi trường dòng lệnh (Window Command Line – Linux Terminal)

 Có thể đếm mã dòng lệnh trong rất nhiều loại file khác nhau như: SQL, XML …

 Hỗ trợ những loại file nén nhu zip, tar

 Có nhiều tùy chọn để cho kết quả chính xác hơn Để sử dụng chương trình, từ cửa sổ dòng lệnh ta gõ dòng lệnh cloc-1.55.exe [options] | |

Các tham số Giải thích

[options] Là những tùy chọn điều chỉnh sự hoạt động của chương trình theo ý muốn

| Chỉ định các thư mục và các tập tin cần đếm số lượng dòng lệnh chứa bên trong

Chỉ định nơi kết xuất kết quả

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

Tham số tùy chọn (options)

extract-with= Dùng tham số này để chương trình tự động giải nén những tập tin có dạng nén (zip, tar)

list-file= Chỉ dịnh một số tập tin nằm ngoài thư mục được chỉ định unicode Kiểm tra các tập tin chứa các kí tự Unicode

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

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

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

Công cụ dùng để áp dụng mô hình COCOMO II cho công ty phần mềm Edge-Work là một công cụ trên nền web Công cụ này rất dễ sử dụng, cho kết quả tính toán nhanh và đơn giản Chỉ cần nhập vào số lượng dòng mã lệnh và các yếu tố điều chỉnh chi phí Công cụ được cung cấp tại trang web http://diana.nps.edu/~madachy/tools/COCOMOII.php

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

Chương này giới thiệu về quy trình cũng như phương pháp nghiên cứu của luận văn cũng như nêu ra hai công cụ đếm số lượng dòng mã lệnh cloc phiên bản 1.5.5 và một công cụ trên web nhằm hỗ trợ việc ước lượng bằng COCOMO II nhanh chóng và tiện lợi hơn

CHƯƠNG 4: THU THẬP VÀ PHÂN TÍCH DỮ

Edge-works Software Ltd là một công ty phần mềm có vốn đầu tư 100% của Đức

Công ty chuyên gia công các sản phẩm phầm mềm cho thị trường châu Âu và Mỹ

Công ty được thành lập vào năm 2007 tại công viên phần mềm Quang Trung quận 12 TP.HCM Công ty chuyên về sản xuất và gia công các sản phẩm phần mềm dựa trên các công nghệ mã nguồn mở nhằm giảm giá thành sản phẩm tăng tính cạnh tranh và hưởng ứng chủ trương sử dụng mã nguồn mở rộng rãi của chính phủ

Việc khảo sát các yếu tố có ảnh hưởng nhiều đến việc ước lượng hơn các yếu tố khác dựa trên việc khảo sát các dự án tại công ty Edge-works Software Ltd Công ty có nhiều dự án vừa và nhỏ thích hợp cho việc nghiên cứu

Khảo sát dựa trên dữ liệu sẵn có của 8 dự án đã hoàn thành sau:

1 StartSequel 2 Equator 3 Hawa 4 Plevo 5 Cartridge Card 6 GVillage 7 Consulting Platform 8 Hr-Solution-Vn Dữ liệu về những dự án trên được thu thập bằng cách khảo sát và phỏng vấn những người quản lý dự án và lập trình viên trong dự án đó Những người được chọn phỏng vấn là những người có hiểu biết về công nghệ thông tin cũng như hiểu rõ về dự án Với mỗi dự án, người phỏng vấn sử dụng bảng câu hỏi để thu thập các thông tin từ những người được phỏng vấn trên đồng thời sử dụng thêm những câu hỏi trợ giúp tại chỗ để giúp họ trả lời các câu hỏi khảo sát một cách dễ dàng hơn Có một số câu hỏi không được trả lời do các yếu tố bảo mật về dự án và những người được khảo sát không nhớ hoặc không chắc chắn do thời gian hoàn thành đã lâu Từ kết quả của khảo sát có thể rút ra được các yếu tố điều chỉnh chi phí của dự án Sau đó sử dụng công cụ cloc 1.5.5 để đếm số lượng dòng lệnh của dự án

Kết hợp các dữ liệu về các yếu tố điều chỉnh chi phí và số lượng dòng lệnh, ta sử dụng một phần mềm tính toán theo mô hình COCOMO II được cung cấp tại trang http://diana.nps.edu/~madachy/tools/COCOMOII.php

Dự án StarSequel

StarSequel là dự án quản lý đội tàu dùng để chuyên chở hàng hóa trên biển cho khách hàng Chương trình lập lịch và theo dõi hoạt động của từng con tàu để biết tình trạng nhằm đảm bảo hàng hóa được chuyên chở đến chỗ khách hàng một cách nhanh nhất mà vẫn đảm bảo chất lượng của hàng hóa

Chương trình còn đảm bảo quản lý chất lượng của các con tàu nhằm hạn chế những rủi ro có thể xảy ra trong quá trình hoạt động tránh tổn thất

Nhân sự tham gia Ba lập trình viên

Số lượng dòng mã lệnh 49.507

Ngôn ngữ sử dụng PHP

Cơ sở dữ liệu MySQL

Thời gian hoàn thành thực tế 20 tháng Kết quả ước lượng bằng COCOMO II 65.2 Person-months

Yếu tố điều chỉnh quy mô Kết quả khảo sát Chi tiết

PREC Bình thường Đây là dự án đầu tiên làm về lĩnh vực này

FLEX Bình thường Đã từng làm qua các dự án có một số chức năng tương tự

RESL Ít Dự án đơn giản và hầu như không có nguy cơ, khách hàng không yêu cầu về thời gian và chi phí

TEAM Rất cao Các thành viên làm việc rất tốt trong nhóm

PMAT Không biết Không áp dụng

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

Yếu tố điều chỉnh chi phí Kết quả khảo sát Chi tiết

RELY Bình thường Phần mềm được yêu cầu họat động ổn định để đảm bảo hiệu quả kinh doanh nhưng có khả năng khôi phục khi có sự cố xảy ra

RUSE Cao Do viết theo thành phần nên tái sử dụng được

DOCU Rất thấp Không viết các tài liệu cho dự án

TIME Rất cao Hỗ trợ hoạt động 24/24

STOR Thấp Chỉ chiếm dụng một lượng bộ nhớ và đĩa cứng lưu trữ không đáng kể

ACAP Rất cao Có khả năng hiểu và phân thích yêu cầu từ khách hàng dễ dàng

PCAP Rất cao Có thể hiểu và phân tích hơn 90% yêu cầu từ khách hàng

PCON Rất cao Thời gian làm việc ngắn do các thành viên thay đổi để chuyển sang các dự án khác trong công ty

APEX Rất cao Kinh nghiệm với dạng phần mềm được khoảng một năm

PLEX Rất cao Kinh nghiệm với nền tảng được một năm

LTEX Trung bình Kinh nghiệm với công cụ được một năm

TOOL Rất thấp Chỉ sử dụng với những mục đích cơ bản như bẩy lỗi hoặc sửa lỗi

SITE Trung bình Chỉ sử dụng email, điện thoại, máy fax

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

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

Dự án này trong thực tế cần ba người làm việc liên tục trong vòng 20 tháng Kết quả ước lượng cho thấy cần 65.2 PM tương đương ba người làm trong vòng 21.73 tháng Trong trường hợp này kết quả ước lượng cao hơn thực tế gần 2 tháng.

Dự án Equator

Equator là dự án quản lý hàng tồn kho ở bến cảng tàu biển Hệ thống quản lý việc xuất nhập các loại hàng hóa khác nhau

Nhân sự tham gia Hai lập trình viên

Ngôn ngữ sử dụng PHP

TEAM Rất cao Các thành viên trong nhóm làm việc rất tốt

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

Phần mềm doanh nghiệp cần đảm bảo tính ổn định để duy trì hoạt động kinh doanh hiệu quả, đồng thời phải có khả năng phục hồi nhanh chóng khi xảy ra sự cố Điều này giúp giảm thiểu gián đoạn kinh doanh, bảo vệ dữ liệu quan trọng và duy trì sự tin tưởng của khách hàng.

PCON Rất cao Các thành viên luân chuyển giữa các dự án

TOOL Thấp Chỉ sử dụng với những mục đích cơ bản như bẩy lỗi hoặc sửa lỗi, có thể thiết kế giao diện

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

Dự án này trong thực tế cần hai người làm việc liên tục trong vòng 30 tháng Kết quả ước lượng cho thấy cần 62.2 PM tương đương hai người làm trong vòng 31.1 tháng Trong trường hợp này kết quả ước lượng tương cao hơn thực tế 1 tháng.

Dự án Hawa

Hawa là dự án quản lý danh mục sản phẩm các hàng hóa làm bằng gỗ

Nhân sự tham gia Ba lập trình viên

Số lượng dòng mã lệnh 50344

Ngôn ngữ sử dụng PHP, Perl, C

Thời gian hoàn thành thực tế 20 tháng Kết quả ước lượng bằng COCOMO II 66.4 Person Months

TEAM Rất cao Khản năng làm việc nhóm tốt, các thông tin luôn được chia sẻ trong nhóm một cách đầy dủ và chính xác nhất

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

DOCU Trung bình Có tài liệu tuy không đầy đủ

PCON Rất thấp Hơn 48% của một năm

PLEX Trung bình Kinh nghiệm với nền tảng được một năm

TOOL Thấp Chỉ sử dụng với những mục đích cơ bản như bẫy lỗi hoặc sửa lỗi, có thể thiết kế giao diện người dùng

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

Dự án này trong thực tế cần ba người làm việc liên tục trong vòng 20 tháng Kết quả ước lượng cho thấy cần 66.4 PM tương đương ba người làm trong vòng 22 tháng Trong trường hợp này kết quả ước lượng cao hơn thực tế 2 tháng.

Dự án Plevo

Plevo là một hệ thống ERP dùng để quản lý một nhà máy sản xuất lớn theo tiêu chuần ISO – 14000 Hệ thống được triển khai cho các tập đoàn công nghiệp lớn tại Đức

Nhân sự tham gia Năm lập trình viên

Ngôn ngữ sử dụng PHP, ASP, Perl

TEAM Rất cao Khản năng làm việc nhóm tốt, các thông tin luôn được chia sẻ trong nhóm một cách đầy dủ và chính xác nhất

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

DOCU Trung bình Có tài liệu tuy không đầy đủ

PCON Rất thấp Hơn 48% của một năm

PLEX Rất cao Kinh nghiệm với nền tảng rất tốt do đã thực hiện nhiều dự án tương tự

TOOL Thấp Chỉ sử dụng với những mục đích cơ bản như bẩy lỗi hoặc sửa lỗi, có thể thiết kế giao diện

SITE Trung bình Email, điện thoại, trao đổi có hình ảnh (Microsoft Skype, Yahoo).

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

Dự án này trong thực tế cần năm người làm việc liên tục trong vòng 36 tháng Kết quả ước lượng cho thấy cần 199.5 PM tương đương 5 người làm trong vòng 40 tháng Trong trường hợp này kết quả ước lượng lệch cao hơn thực tế khoảng 4 tháng.

Dự án Cartridge World

4.5.1 Giới thiệu Đây là một phần mềm chạy trên nền web thực hiện theo đơn đặt hàng của một công ty Phầm mềm này dùng để quản lý xuất nhập và tồn kho Đồng thời quản lý quy trình sản xuất các loại vật tư để sản xuất thành phẩm Xuất ra các báo cáo doanh thu, dự báo tồn kho

Nhân sự tham gia Một lập trình viên

Ngôn ngữ sử dụng PHP, HTML, JavàScript

TEAM Không biết Do chỉ có một người

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

RELY Rất thấp Phần mềm được yêu cầu họat động ổn định

RUSE Rất cao Do viết theo thành phần nên tái sử dụng được

PVOL Rất cao Có sự thay đổi nhanh chóng trong thời gian rất ngắn.

ACAP Bình thường Có khả năng hiểu và phân thích yêu cầu từ khách hàng dễ dàng

PCON Thấp Thời gian thực hiện từ 3 đến 6 tháng

APEX Trung bình Kinh nghiệm với dạng phần mềm được khoảng một năm

PLEX Trung bình Kinh nghiệm với nền tảng được một năm

SITE Rất cao Email, điện thoại, skype, trao đổi có hình ảnh có tính tương tác cao (Team Viewer)

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

Dự án này trong thực tế cần một người làm việc liên tục trong vòng 9 tháng Kết quả ước lượng cho thấy cần 9.3 PM tương đương một người làm trong vòng 9 tháng và khoảng một tuần Trong trường hợp này kết quả ước lượng tương đối chính xác Độ lệch hầu như không đáng kể.

Dự án GVillage

GVillage là một mạng xã hội thu nhỏ cho phép người dùng đăng các câu chuyện hoặc hình ảnh để những người khác tham gia tương tác Những tương tác này có thể bao gồm bình luận, chia sẻ và đóng góp tài chính, thường được gọi là "tiền boa" Khi một người dùng nhận được tiền boa, họ sẽ nhận được điểm thưởng có giá trị trên nền tảng Nhờ cơ chế này, GVillage khuyến khích sự tương tác và hỗ trợ cộng đồng, cho phép người dùng ghi nhận và tôn vinh những đóng góp có giá trị của nhau.

Ngôn ngữ sử dụng Javà, HTML, JavàScript

Thời gian hoàn thành thực tế 6 tháng Kết quả ước lượng bằng COCOMO II 10.2 Person - Months

RESL Ít Dự án đơn giản, khách hàng không yêu cầu về thời gian và chi phí

TEAM Rất cao Làm việc nhóm, hỗ trợ nhau tốt trong công việc

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

RELY Rất thấp Phần mềm được yêu cầu họat động ổn định và chính xác do có thực hiện giao dịch chuyển tiền trực tuyến

PVOL Rất thấp Nền tảng công nghệ sử dụng rất ít khi thay đổi do được chính khách hàng chỉ định

PCON Rất cao Thời gian thực hiện từ 3 đến 6 tháng

LTEX Cao Kinh nghiệm với công cụ được một năm

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

Dự án này trong thực tế cần hai người làm việc liên tục trong vòng 6 tháng Kết quả ước lượng cho thấy cần 10.2 PM tương đương hai người làm trong vòng hơn 5 tháng Độ lệch trong trường hợp này ước lượng thấp hơn thực tế 1 tháng.

Dự án Consultant Platform

Consultant Service là một trang web nơi người có nhu cầu tư vấn sẽ tìm đến các chuyên gia khi gặp các vần đề trong cuộc sống hoặc trong công việc Các chuyên gia sẽ liên lạc với họ và cho họ giải pháp Nếu họ đồng ý với giải pháp của chuyên gia đưa ra thì họ sẽ tiến hành thanh toán để trả tiền cho giải pháp đó

Thời gian hoàn thành thực tế 7 tháng Kết quả ước lượng bằng COCOMO II 14.2 Person Months

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

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

Dự án này trong thực tế cần hai người làm việc liên tục trong vòng 7 tháng Kết quả ước lượng cho thấy cần 14.2 PM tương đương hai người làm trong vòng hơn 7 tháng và một tuần Độ lệch trong trường hợp này là ước lượng nhiều hơn khoản một tuần so với thực tế.

Dự án Hr-Solution-Vn

Hr-Solution-Vn là dự án về một trang web quản trị hồ sơ nhân sự để phục vụ cho một công ty môi giới việc làm

Thời gian hoàn thành thực tế 7 tháng Kết quả ước lượng bằng COCOMO II 14.9 Personal Months

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

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

Dự án này trong thực tế cần hai người làm việc liên tục trong vòng 7 tháng Kết quả ước lượng cho thấy cần 14.9 PM tương đương hai người làm trong vòng khoảng 8 tháng Độ lệch trong trường hợp này là ước lượng nhiều một tháng so với thực tế.

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

Chương này tập trung vào việc tổng hợp các dữ liệu thu được từ 8 dự án của công ty Edge-works Software Ltd bằng cách sử dụng bảng câu hỏi và phỏng vấn trực tiếp đối với những người quản lý hoặc những người tham gia trong dự án Những người này cần phải có hiểu biết chắc chắn về lĩnh vực phần mềm nói chung và dự án nói riêng Các dữ liệu thu được sau đó được chuyển thành các tham số đầu vào cho việc ước lượng bằng mô hình COCOMO II thông qua công cụ hỗ trợ

Bằng cách so sánh kết quả ước lượng bằng COCOMO II và kết quả thực tế ta có thể thấy được độ chính xác của phương pháp này.

Tiêu đề	Áp dụng mô hình COCOMO II để ước lượng chi phí của dự án phần mềm
Tác giả	Khưu Quốc Bảo
Người hướng dẫn	TS Nguyễn Hải Quân
Trường học	Đại học Quốc gia TP. HCM
Chuyên ngành	Hệ thống thông tin quản lý
Thể loại	Luận văn thạc sĩ
Năm xuất bản	2012
Thành phố	TP. Hồ Chí Minh

Định dạng
Số trang	116
Dung lượng	2,13 MB