Các phương pháp ước lượng công thực hiện phần mềm

12 PHẦN 2: HIỆN TRẠNG Chương 2: Các phương pháp ước lượng công thực hiện phần mềm 2.1. Sơ lược về ước lượng công thực hiện phần mềm 2.1.1. Khái niệm ước lượng công thực hiện phần mềm Uớc lượng là công việc tính toán gần ñúng một ñại lượng nào ñó dựa trên tập dữ liệu liên quan ñến ñại lượng ñó. Tập dữ liệu này thường ñược thu thập trong ñiều kiện thiếu, nhiễu hoặc chỉ có giá trị gần ñúng. Khi tập dữ liệu ở trong ñiều kiện hoàn hảo hay ñầy ñủ thông tin thì ước lượng trở thành tính toán chính xác. Trong bất cứ ngành nghề sản xuất nào làm ra sản phẩm có ñộ phức tạp cao, việc ước lượng những yếu tố liên quan ñến sản phẩm trước khi ñưa vào sản xuất ñều cần thiết. Những yếu tố này cung cấp cho nhà sản xuất một cái nhìn trước về sản phẩm, từ ñó giúp cho việc hoạch ñịnh ngân sách, lên kế hoạch sản xuất, phân bổ nhân lực và giảm thiểu rủi ro. Trong ngành công nghiệp sản xuất phần mềm, yếu tố ước lượng ñược quan tâm nhiều nhất là chi phí phần mềm. Chi phí ở ñây bao gồm hai loại: - Chi phí sản xuất: chi phí gốc ñể phát triển dự án phần mềm, chi phí này ñược tính dựa trên công thực hiện dự án của ñội ngũ phát triển phần mềm. - Chi phí môi trường: những chi phí phát sinh xung quanh quá trình phát triển, bao gồm: chi phí tài nguyên, chi phí ñi lại, chi phí bảo trì, chi phí ngoại giao, … Chi phí môi trường có thể chiếm ñến hơn 2/3 chi phí phần mềm và phụ thuộc vào nhiều yếu tố như: giá cả, lạm phát, xu hướng thị trường, kỹ năng ñàm phán, … Những yếu tố này nằm ngoài lĩnh vực phần mềm và thường xuyên biến ñộng, làm 13 cho việc ước lượng trước chi phí môi trường là ñiều không khả thi. Trong khi ñó, chi phí sản xuất ñược tính toán dựa trên công thực hiện là ñại lượng hoàn toàn có thể ước lượng ñược với ñộ chính xác tương ñối cao. Biết trước công thực hiện sẽ giúp cho việc lập kế hoạch và phân bố nhân lực tham gia vào quá trình phát triển phần mềm ñược tốt hơn. Vì những lý do này, ước lượng công thực hiện phần mềm là một công việc quan trọng ñược thực hiện ở hầu hết các dự án phần mềm nghiêm túc. Việc ước lượng công ñược tiến hành xuyên suốt quá trình thực hiện dự án, trãi qua từng giai ñoạn của quy trình phần mềm. Ở giai ñoạn ñầu, dự án còn ở dạng sơ khai, những thông tin xung quanh dự án còn chưa rõ ràng, công thực hiện ước lượng ñược trong giai ñoạn này có ñộ chính xác không cao và thường ñược dùng làm cơ sở ñể báo giá, ñấu thầu dự án phần mềm. Càng về những giai ñoạn sau, các chi tiết của dự án ñã ñược làm rõ dần, ñộ chính xác của ước lượng càng tăng, công thực hiện ñược dùng ñể ñiều chỉnh ngân sách, chỉnh sửa kế hoạch cho phù hợp với những giai ñoạn tiếp theo. Hình 2.1. Sai số của ước lượng qua từng giai ñoạn của dự án phần mềm [16]. 14 2.1.2. Các thông số ước lượng ðầu vào của quá trình ước lượng công thực hiện dự án phần mềm là các thông số ước lượng (Cost Driver). Mỗi thông số là một yếu tố ảnh hưởng ñến công thực hiện của dự án. Những thông số này chia làm ba loại - Thông số về sản phẩm (Product Factors): những yếu tố của sản phẩm phần mềm ảnh hưởng ñến công thực hiện dự án, như: ñộ lớn, ñộ phức tạp, loại phần mềm, … - Thông số về môi trường phát triển (Environment Factors): những yếu tố của môi trường phát triển phần mềm ít nhiều làm thay ñổi công thực hiện, như: ngôn ngữ lập trình, quy trình phát triển, công nghệ triển khai, công cụ, tài nguyên hỗ trợ quá trình phát triển, … - Thông số về ñội ngũ phát triển (People Factors): những yếu tố của cá nhân tham gia vào quá trình phát triển dự án, như: trình ñộ kỹ thuật, kinh nghiệm, mức ñộ quen thuộc, năng suất làm việc, kỹ năng làm việc nhóm, … Trước khi thực hiện việc ước lượng, giá trị các thông số ước lượng của dự án phần mềm ñược tính bằng cách cho ñiểm dựa vào kinh nghiệm của người thực hiện công tác ước lượng. Công việc này mang tính chủ quan, phụ thuộc rất nhiều vào yếu tố con người. Hiện nay, có những nghiên cứu áp dụng logic mờ (Fuzzy Logic) ñể mờ hóa các giá trị ñiểm số nhằm giảm mức ñộ cảm tính trong việc cho ñiểm [8]. Hình 2.2. Biểu diễn giá trị các thông số ước lượng bằng logic mờ. Một thông số ước lượng rất ñược quan tâm là yếu tố về ñộ lớn của phần mềm. Yếu tố này ñược cho là ảnh hưởng rất lớn ñến công thực hiện phần mềm. Thông thường, 15 ñộ lớn phần mềm ñược ño bằng ñơn vị dòng-mã-nguồn (SLOC - Source Line Of Code). Nhưng trong phần lớn các giai ñoạn của quy trình phát triển, khi phần mềm chưa ñược hoàn thành, thông số ñộ lớn ño bằng ñơn vị dòng-mã-nguồn thường phải phỏng ñoán nên không tránh khỏi những sai sót. ðể khắc phục hạn chế này, ñơn vị ñiểm-chức-năng (FP - Function Point) thường ñược dùng thay thế [7]. ðơn vị này ñược tính toán dựa trên các yêu cầu chức năng và phi chức năng của dự án phần mềm nên mang tính thực tế hơn. Trong vài năm trở lại ñây, một ñơn vị khác cũng ñược sử dụng là ñiểm-ñối-tượng (OP – Object Point) [7]. ðây là ñơn vị ñược tính toán dựa trên các yêu cầu về màn hình và báo biểu của phần mềm. Nó thường ñược dùng ñể ño ñộ lớn phần mềm trong giai ñoạn sơ khởi của dự án, khi những yêu cầu chi tiết dùng ñể tính ñiểm-chức-năng chưa ñược làm rõ. 2.1.3. ðại lượng công thực hiện phần mềm Kết quả của quá trình ước lượng là công thực hiện dự án phần mềm. ðại lượng công thể hiện công sức cần thiết bỏ ra ñể ñội ngũ phát triển ñể hoàn thành dự án phần mềm. Hay nói cách khác, ñây là ñại lượng ñược dùng ñể ño khối lượng công việc cần thực hiện của dự án. ðại lượng công ñược tính bằng ñơn vị người-tháng (Person-Month) hoặc người-giờ (Person-Hour). Công thực hiện là tiền ñề ñể tính toán chi phí sản xuất phần mềm thông qua chi phí trung bình cho một ñơn vị công người-tháng. Một công ty phần mềm có thể dễ dàng tính toán ñược chi phí này thông qua phân tích thống kê số liệu trong quá khứ. Sau khi tính toán, chi phí sản xuất sẽ ñược dùng làm cơ sở ñể hoạch ñịnh ngân sách, báo giá sản phẩm cho khách hàng, ñấu thầu dự án, … Ngoài ra, công thực hiện cũng là tiền ñề ñể lên kế hoạch thời gian và nhân lực cho dự án. Một công thức kinh nghiệm thường ñược dùng ñể tối ưu hóa thời gian và nhân lực dựa vào công thực hiện. 16 ETP ≈≈ Công thức 2.1. Tính thời gian và nhân lực dự án từ ñại lượng công. Trong ñó: - E: công thực hiện dự án phần mềm ước lượng ñược, ñơn vị người-tháng. - P: nhân lực dự kiến thực hiện dự án, ñơn vị người. - T: thời gian dự kiến hoàn thành dự án, ñơn vị tháng. 2.2. Nhóm phương pháp ước lượng dựa vào chuyên gia Là một nhánh trong ngành khoa học về dự báo, ước lượng là một công việc phức tạp và ẩn chứa nhiều rủi ro. Ước lượng công thực hiện phần mềm ñặc biệt phức tạp vì phần mềm là một sản phẩm trí tuệ, khó có thể cân ño ñong ñếm ñước. Vì vậy, những phương pháp ñầu tiên ñược sử dụng ñể ước lượng công thực hiện phần mềm là dựa vào con người, những chuyên gia có nhiều kinh nghiệm và am hiểu về lĩnh vực của dự án phần mềm. Kết quả ước lượng ñược ñưa ra dựa trên cơ sở phân tích, ñánh giá, và nhận ñịnh từ các chuyên gia này. Và ñến nay, mặc dù ñã xuất hiện nhiều phương pháp khác thay thế, việc tham khảo ý kiến chuyên gia ñể ñưa ra kết quả ước lượng vẫn ñược dùng khá phổ biến. Nhận ñịnh của các chuyên gia vẫn luôn ñáng ñược quan tâm xem xét. ðiểm yếu của các phương pháp ước lượng dựa vào chuyên gia là kết quả ước lượng thường là chủ quan và cảm tính, không thể kiểm chứng khi dự án chưa hoàn thành. Ngoài ra, thời gian ra quyết ñịnh thường kéo dài và giá thành thuê chuyên gia tốn kém cũng là một hạn chế không nhỏ của nhóm phương pháp này. Hai trong số những phương pháp thường ñược các chuyên gia sử dụng ñể ước lượng công thực hiện phần mềm là: phương pháp tương ñồng và phương pháp Wide-band Delphi sẽ ñược trình bày ở ñây. 17 2.2.1. Phương pháp tương ñồng [6][7] ðây là phương pháp ước lượng ñơn giản, ñược thực hiện dựa trên nguyên tắt “những dự án phần mềm tương ñồng nhau thường có công thực hiện gần giống nhau”. Theo ñó, công thực hiện dự án phần mềm mới sẽ ñược ước lượng dựa trên những dự án phần mềm cũ tương ñồng ñã ñược thực hiện trước ñó. Quy trình ước lượng của phương pháp tương ñồng bao gồm ba bước: - Bước 1 (Analysis): phân tích, ñánh giá những thông số của dự án phần mềm mới. - Bước 2 (Comparing): so sánh dự án phần mềm mới với những dự án phần mềm trong tập dữ liệu lịch sử ñể tìm ra dự án tương ñồng. - Bước 3 (Scaling): xem xét các thông số giữa hai dự án, từ ñó co giãn công thực hiện của dự án cũ ñể tìm ra công thực hiện dự án mới. ðể tăng tính chính xác của ước lượng, phương pháp tương ñồng phải ñược thực hiện bởi chuyên gia có nhiều kinh nghiệm trong lĩnh vực của dự án phần mềm mới sắp ñược thực hiện. Chuyên gia này cũng cần phải am hiểu về ñội ngũ phát triển và tình hình hoạt ñộng hiện tại của công ty. Hạn chế của phương pháp tương ñồng ñó là việc tìm ra dự án cũ tương ñồng với dự án mới là một công việc không hề dễ dàng. ðiều này ñòi hỏi phải ñề ra ñược những tiêu chí ñánh giá và công thức ñể tính toán mức ñộ tương ñồng giữa hai dự án phần mềm, từ ñó mới có thể xác ñịnh ñược dự án cũ nào trong tập dữ liệu lịch sử là tương ñồng với dự án mới cần ước lượng. Hơn nữa, sau khi ñã tìm ra ñược dự án tương ñồng với dự án mới, việc so sánh các thông số giữa hai dự án, rồi sau ñó co giãn công dự án cũ sao cho hợp lý ñể ñưa ra kết quả cuối cùng là một công việc ñầy cảm tính và dễ gây tranh cãi. ðiều này phụ 18 thuộc rất nhiều vào kinh nghiệm và khả năng phán ñoán của chuyên gia thực hiện công việc ước lượng. 2.2.2. Phương pháp Wide-band Delphi [6][7][18] Dựa vào một cá nhân nào ñó ñể ñưa ra con số ước lượng là một quá trình ñầy cảm tính và rủi ro. Nhằm tăng tính khách quan và ñộ chính xác của kết quả ước lượng, quy trình Wide-band Delphi thường ñược áp dụng. Quy trình này do Barry Boehm và John Farquhar phát triển từ quy trình ra quyết ñịnh Delphi. Thay vì phụ thuộc vào một chuyên gia, kết quả ước lượng giờ ñây ñược ñưa ra dựa trên sự ñồng thuận của một nhóm các chuyên gia, và tuân theo một quy trình bài bản gồm năm bước: - Bước 1 (Preparation): trước hết, một nhóm chuyên gia ñược thành lập, ñiều phối viên có nhiệm vụ gởi ñến mỗi chuyên gia ñầy ñủ thông tin, dữ kiện của dự án phần mềm cần ước lượng. - Bước 2 (Meeting): ñiều phối viên tổ chức một cuộc họp, tại ñây các chuyên gia thảo luận với nhau về những vấn ñề liên quan ñến dự án phần mềm: những thông số dự án, môi trường phát triển, ñội ngũ phát triển, … - Bước 3 (Decision): mỗi chuyên gia ñược phát một phiếu ñể ghi nhận ñịnh và con số ước lượng của mình một cách ñộc lập. - Bước 4 (Summary): ñiều phối viên tổng hợp kết quả ước lượng thu ñược từ các chuyên gia. - Bước 5 (Loop): nếu kết quả ước lượng của các chuyên gia quá khác biệt, bước 2 ñược lặp lại cho ñến khi nào có ñược sự ñồng thuận. Phương pháp Wide-band Delphi tỏ ra khá hiệu quả trong việc ước lượng công thực hiện của những dự án phần mềm lớn, có nhiều ràng buộc phức tạp, và ñòi hỏi ñộ chính xác cao. Tuy nhiên, phương pháp này khá tốn kém và thường mất nhiều thời gian. Các chuyên gia không phải lúc nào cũng có tiếng nói chung. Và ñể tìm ñược 19 sự ñồng thuận giữa họ, quy trình trên có thể phải lặp lại rất nhiều lần. Hơn nữa, việc tập hợp ñược một nhóm các chuyên gia có kinh nghiệm là không dễ dàng chút nào. 2.3. Nhóm phương pháp ước lượng dựa vào công thức Nhóm phương pháp này xem việc ước lượng công thực hiện phần mềm là quá trình tìm kiếm mối liên hệ giữa ñại lượng công và các thông số của dự án phần mềm cần ước lượng. Các phương pháp ước lượng dựa vào công thức biểu diễn mối liên hệ này bằng một phương trình toán học. ða số những phương trình này ở dạng hàm nhiều biến, với một bên là các biến số ñại diện cho các thông số của dự án phần mềm, một bên là ñại lượng công thực hiện dự án. Những hàm nhiều biến này có thể phân làm hai dạng: tuyến tính và phi tuyến. - Tuyến tính: ∑+= ii xaaE 0 . - Phi tuyến: ∏×= i x iaaE 0 . Trong ñó: - E: công thực hiện dự án phần mềm. - xi: thông số thứ i của dự án. - ai: hệ số của từng thông số. Những công thức này ñược xây dựng dựa trên việc khảo sát một tập dữ liệu lịch sử bao gồm các dự án phần mềm ñã ñược thực hiện trước ñó. Phương pháp dùng ñể khảo sát thường là phương pháp phân tích hồi quy (regression analysis). Ưu ñiểm của ước lượng dựa vào công thức là tính khách quan của nó. Các công thức ñược xây dựng bằng phương pháp toán học chặt chẽ. Với cùng một bộ thông số ñầu vào như nhau, các công thức luôn cho ñầu ra kết quả như nhau. Kết quả này không phụ thuộc vào người thực hiện công việc ước lượng và có thể dễ dàng ñược kiểm chứng. 20 Một ưu ñiểm nữa của ước lượng dựa vào công thức là thời gian ñưa ra kết quả ước lượng nhanh chóng và ít tốn kém hơn hẳn so với việc thuê chuyên gia. Tuy nhiên, do ñược xây dựng trên một tập dữ liệu lịch sử cục bộ của một ñội ngũ phát triển nào ñó, các công thức ước lượng thường không phải lúc nào cũng chính xác khi áp dụng vào từng công ty với từng loại dự án cụ thể. Trong trường hợp ñó, các công thức cần phải ñược tinh chỉnh lại cho phù hợp. 2.3.1. Mô hình COCOMO [4][5][6] Mô hình ước lượng công thực hiện phần mềm COCOMO (COst COnstructive MOdel) do Barry Boehm ñề xuất vào ñầu thập niên 1980. Nó ñã nhanh chóng trở thành mô hình ước lượng ñược giới công nghiệp phần mềm sử dụng rộng rãi nhất thời bấy giờ [6]. Nhưng cùng với sự phát triển không ngừng của các quy trình công nghệ phát triển phần mềm, phiên bản ñầu tiên của mô hình là COCOMO 81 ñã dần bị lỗi thời, không còn chính xác khi áp dụng cho những dự án phát triển theo quy trình công nghệ mới. Vì vậy, từ năm 1994 cho ñến năm 2000, Boehm cùng các ñồng sự ở ñại học Nam California ñã tiếp tục nghiên cứu, phát triển và ñưa ra mô hình COCOMO II. Mô hình COCOMO II bao gồm 3 phiên bản (stage) áp dụng vào những thời ñiểm khác nhau trong quy trình phát triển phần mềm. Mỗi phiên bản ñược dùng với tính chất và mục ñích riêng. Ba phiên bản này gồm có: Application Composition, Early Design, và Post-Architecture. Phiên bản Application Composition ñược dùng ñể ước lượng công thực hiện phần mềm ở giai ñoạn khởi ñầu của dự án, khi phần mềm chỉ mới ở dạng prototype, chưa có gì rõ ràng. Kết quả ước lượng thường mang tính tham khảo, dùng trong thương lượng, ñàm phán hợp ñồng dự án. Công thực hiện ñược tính theo công thức 2.2. 21 PROD SIZE E = Công thức 2.2. Tính công thực hiện theo COCOMO 2000 Application Composition [5]. Trong ñó: - E: công thực hiện dự án phần mềm, ñơn vị người-tháng (person-month). - SIZE: kích thước phần mềm tính bằng ñơn vị ñiểm-ñối tượng (object point), ñược ño bằng cách cho ñiểm dựa trên ñộ phức tạp của từng màn hình, báo biểu trong phần mềm rồi cộng lại. - PROD: năng suất thực hiện một ñơn vị ñiểm-ñối tượng của ñội ngũ phát triển. Phiên bản Early Design ñược dùng ñể ước lượng công thực hiện phần mềm trong giai ñoạn ñầu của quá trình thiết kế dự án. Lúc này, các yêu cầu chức năng của dự án ñã rõ ràng nhưng các yếu tố về cài ñặt chưa ñược biết ñến. Kết quả ước lượng ñược dùng ñể ñiều chỉnh ngân sách, nhân lực và lên kế hoạch cài ñặt cho dự án. Công thực hiện ở phiên bản này ñược tính theo công thức 2.3. ∏××= i B EMSIZEAE Công thức 2.3. Tính công thực hiện theo COCOMO 2000 Early Design [5]. Trong ñó: - E: công thực hiện dự án phần mềm, ñơn vị người-tháng (person-month). - A, B: các hệ số ñiều chỉnh của công thức, phụ thuộc vào môi trường phát triển phần mềm ở mỗi công ty. Theo tính toán của Boehm, giá trị mặc ñịnh A = 2.94 và B dao ñộng từ 1.1 ñến 1.24. Tuy nhiên, ñể tăng ñộ chính xác, ông khuyến cáo người dùng công thức nên tinh chỉnh lại A, B theo tập dữ liệu lịch sử của riêng mình cho phù hợp. 22 - SIZE: kích thước phần mềm tính bằng ñơn vị ñiểm-chức năng (function point), ñược ño bằng cách cho ñiểm dựa trên ñộ phức tạp của từng chức năng trong phần mềm rồi cộng lại. - EMi: các hệ số của dự án, trong phiên bản Early Design, có 7 hệ số ñược sử dụng. Bảng 2.1. Các hệ số dự án dùng trong COCOMO 2000 Early Design [1]. STT Hệ số Ý nghĩa 1 RCPX Product Reliability and Complexity 2 RUSE Required Reuse 3 PDIF Platform Difficulty 4 PERS Personnel Capability 5 PREX Personnel Experience 6 FCIL Facilities 7 SCED Required Development Schedule Phiên bản Post-Architecture là sự mở rộng của phiên bản Early Design. Nó ñược sử dụng sau khi giai ñoạn thiết kế của dự án ñã hoàn tất. Lúc này, những thông tin chi tiết về việc cài ñặt dự án ñã ñược biết rõ ràng và cặn kẽ. Kết quả ước lượng của phiên bản này ñược dùng ñể tham khảo cho những ñiều chỉnh cuối cùng về ngân sách và nhân lực của dự án. Công thức của phiên bản Post-Architecture tương tự phiên bản Early Design. Tuy nhiên, có một vài ñiểm khác biệt ở công thức 2.4. ∏××= i B EMSIZEAE Công thức 2.4. Tính công thực hiện theo COCOMO 2000 Post Architecture [5]. 23 Trong ñó: - SIZE: kích thước phần mềm tính bằng ñơn vị dòng mã nguồn (KSLOC), thông thường ñể tính ñược số dòng mã nguồn, người ta dựa vào bản tra số dòng mã nguồn trung bình trên một ñiểm-chức năng. - EMi: trong giai ñoạn này, khi các thông tin về dự án ñã ñược biết ñầy ñủ, có tất cả 17 hệ số ñược sử dụng như mô tả ở bảng 2.2. Bảng 2.2. Các hệ số dự án dùng trong COCOMO 2000 Post Architecture [1]. STT Hệ số Ý nghĩa 1 RELY Required System Reliability 2 CPLX Complexity of System Modules 3 DOCU Extent of Documentation Required 4 DATA Size of Database Used 5 RUSE Required Percentage of Reusable Components 6 TIME Execution Time Constraint 7 PVOL Volatility of Development Platform 8 STOR Memory Constraints 9 ACAP Capability of Project Analysts 10 PCON Personnel Continuity 11 PCAP Programmer Capability 12 PEXP Programmer Experience in Project Domain 13 AEXP Analyst Experience in Project Domain 14 LTEX Language and Tool Experience 15 TOOL Use of Software Tool 16 SCED Development Schedule Compression 17 SITE Extent of Multisite Working and Quality of Intersite Communications 24 2.3.2. Mô hình SLIM [6] Mô hình SLIM ñược Putnam ñề xuất vào thập niên 1980, dựa trên những nghiên cứu của ông về ñường cong Norden/Rayleigh thể hiện sự phân bố nhân lực trong quá trình phát triển phần mềm. Putnam ñưa ra mô hình sau khi phân tích số liệu của rất nhiều dự án phần mềm ñã hoàn tất của Bộ Quốc phòng Mỹ. Công thức toán học chủ ñạo của mô hình SLIM ñược mô tả ở công thức 2.5. 3 4 3 1 tEPRODSIZE ××= Công thức 2.5. Công thức chủ ñạo của mô hình SLIM [6]. Trong ñó: - SIZE: kích thước phần mềm, tính bằng ñơn vị dòng mã nguồn (SLOC). - PROD: năng suất của ñội ngũ phát triển phần mềm. - E: công thực hiện dự án phần mềm, ñơn vị người-năm (person-year). - t: thời gian thực hiện dự án, ñơn vị năm. Ưu ñiểm của mô hình SLIM là có công thức ñơn giản và khả năng tinh chỉnh lại công thức theo tập dữ liệu lịch sử một cách dễ dàng. Những thông số dự án như kích thước (SIZE), công thực hiện (E) và thời gian hoàn thành (t) là những dữ liệu mà ña số các công ty ñều lưu lại sau mỗi dự án. Dựa trên những dữ liệu lịch sử này, tham số PROD có thể ñược tinh chỉnh một cách dễ dàng. Sau ñó, tham số này ñược áp dụng lại vào công thức của mô hình ñể ước lượng cho những dự án tương lai. Tuy nhiên, SLIM không phải là một mô hình ñầy ñủ và công khai. Tập dữ liệu ñược dùng ñể xây dựng nên mô hình này tới nay vẫn còn ñược dấu kín. Những thông tin chi tiết về mô hình cũng không ñược cung cấp miễn phí. Hiện tại mô hình này do công ty QSM (Quality System Management) nắm giữ. Khách hàng của QSM ña số là những công ty thuộc Bộ Quốc phòng Mỹ. 25 2.4. Nhóm phương pháp ước lượng bằng máy học Ước lượng công thực hiện dự án phần mềm là một vấn ñề không ñơn giản. Nó vẫn ñang thu hút rất nhiều nghiên cứu trên thế giới. Hiện nay, các nghiên cứu ñang hướng ñến việc áp dụng những mô hình tính toán mềm (Soft Computing) hay trí tuệ nhân tạo vào trong các mô