Tài liệu Ước lượng chi phí phần mềm bằng CBR

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƢỜNG ĐẠI HỌC CÔNG NGHỆ Tô Lan Hƣơng ƢỚC LƢỢNG CHI PHÍ PHẦN MỀM BẰNG CBR LUẬN VĂN THẠC SĨ Hà Nội - 2010 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƢỜNG ĐẠI HỌC CÔNG NGHỆ Tô Lan Hƣơng ƢỚC LƢỢNG CHI PHÍ PHẦN MỀM BẰNG CBR Ngành: Công nghệ thông tin Chuyên ngành: Công nghệ phần mềm Mã số: 60 48 10 LUẬN VĂN THẠC SĨ NGƯỜI HƯỚNG DẪN KHOA HỌC: GS.PTS Nguyễn Việt Hà Hà Nội - 2010 1/71 MỤC LỤC LỜI CẢM ƠN.................................................................. Error! Bookmark not defined. KÝ HIỆU VIẾT TẮT................................................................................................... 3 DANH MỤC BẢNG ..................................................................................................... 4 DANH MỤC HÌNH VẼ ............................................................................................... 5 MỞ ĐẦU....................................................................................................................... 6 1.1 Quản lý dự án phần mềm ............................................................................... 9 1.2 Ước lượng chi phí dự án phần mềm ............................................................... 9 1.3 Các phương pháp ước lượng ........................................................................ 11 1.3.1 Các mô hình ước lượng cơ bản .................................................................... 13 1.3.2 Kỹ thuật ước lượng cải tiến .......................................................................... 24 1.3.3 Ước lượng với hệ chuyên gia ....................................................................... 25 1.4 Bài toán đặt ra.............................................................................................. 27 1.5 Đánh giá và xác định phương pháp tối ưu .................................................... 29 2. CHƢƠNG 2 LẬP LUẬN TRÊN KINH NGHIỆM ............................................ 32 2.1. Định nghĩa ................................................................................................... 33 2.2. Chu trình lập luận trên kinh nghiệm ............................................................. 33 2.3. Các vấn đề khác trong CBR ......................................................................... 38 2.4. Ứng dụng thực tế ......................................................................................... 39 3. CHƢƠNG 3 ÁP DỤNG LẬP LUẬN THEO KINH NGHIỆM VÀO ƢỚC LƢỢNG CHI PHÍ PHẦN MỀM ............................................................................... 40 3.1. Bài toán đặt ra.............................................................................................. 41 3.2. Thiết kế ca sử dụng hệ thống ....................................................................... 42 3.3. Thiết kế chức năng hệ thống ........................................................................ 43 3.3.1. Tìm kiếm ..................................................................................................... 44 3.3.2. Hiệu chỉnh ................................................................................................... 48 3.4. Thiết kế màn hình chức năng ....................................................................... 49 3.5. Thiết kế cơ sở dữ liệu .................................................................................. 50 3.5.1. Biểu diễn dự án ............................................................................................ 50 3.5.2. Tổ chức lưu trữ ............................................................................................ 52 2/71 4. CHƢƠNG 4 THỰC NGHIỆM ............................................................................ 53 4.1. Chương trình thực nghiê ̣m ........................................................................... 54 4.1.1. Ngôn ngữ lập trình và thư viện .................................................................... 54 4.1.2. Cài đặt chương trình .................................................................................... 54 4.2. Thực nghiệm................................................................................................ 54 KẾT LUẬN................................................................................................................. 58 PHỤ LỤC ................................................................................................................... 59 3/71 KÝ HIỆU VIẾT TẮT CBR Case-based Reasoning COCOMO COnstructive COst MOdel AI Aritificial Intelligence SLIM Software LIfe-cycle Model WBS Work Breakdown Structure OLS Ordinary Least Squares EAF Effort Adjustment Factor NOP Number of Object Point LOC Line Of Code CSDL Cơ sở dữ liệu UC Use Case 4/71 DANH MỤC BẢNG Bảng 1 Hệ số các mode trong mô hình COCOMO 18 Bảng 2 Các tham số hiệu chỉnh trong mô hình COCOMO Bảng 3 Tham số hiệu chỉnh trong mô hình tiền thiết kế Bảng 4 Các thừa số hiệu chỉnh của mô hình hậu kiến trúc 19 21 22 Bảng 5 Các hệ số hiệu chỉnh mũ Bảng 6 Bảng so sánh các phương pháp ước lượng chi phí 23 29 Bảng 7 Bảng giá trị thuộc tính đặc trưng dự án Bảng 8 Bảng các giá trị trọng số 50 55 Bảng 9 Kết quả ước lượng các dự án thực nghiệm 1 Bảng 10 Kết quả ước lượng các dự án thực nghiệm 2 Bảng 11 Bảng danh sách dự án trong CSDL ước lượng 55 56 61 Bảng 12 Bảng dự án mới đưa vào ước lượng Bảng 13 Bảng danh sách các dự án đối chứng ước lượng 64 65 Bảng 14 Độ tương quan giữa các giá trị thuộc tính Hiện trạng hệ thống Bảng 15 Độ tương quan giữa các giá trị thuộc tính Ngôn ngữ lập trình 67 67 Bảng 16 Độ tương quan giữa các giá trị thuộc tính Hệ quản trị CSDL Bảng 17 Độ tương quan giữa các giá trị thuộc tính Dạng phần mềm 67 67 Bảng 18 Độ tương quan giữa các giá trị thuộc tính Yêu cầu phi chức năng Bảng 19 Độ tương quan giữa các giá trị thuộc tính Mô hình CSDL Bảng 20 Độ tương quan giữa các giá trị thuộc tính Loại dự án 68 68 68 5/71 DANH MỤC HÌNH VẼ Hình 1 Các kỹ thuật ước lượng theo giai đoạn Hình 2 Phân phối Rayleigh cho nỗ lực phát triển [4] 12 14 Hình 3 Đầu vào và đầu ra của mô hình ước lượng SEER-SEM 16 Hình 4 Các bước thực hiện ước lương theo Delphi 24 Hình 5 Các bước thực hiện của CBR Hình 6 Chu trình lập luận theo kinh nghiệm. Hình 7 Đồ thị biểu diễn ca lập luận [2] Hình 8 Cây quyết định 27 34 36 37 Hình 9 Biều đồ luồng Use case hệ thống 42 Hình 10 Biểu đồ luồng xử lý chức năng Hình 11 Luồng màn hình quản lý dự án Hình 12 Luồng màn hình ước lượng dự án 44 49 49 Hình 13 Màn hình danh mục dự án Hình 14 Màn hình Tìm kiến dự án Hình 15 Màn hình kết quả tìm kiếm 59 59 60 Hình 16 Màn hình Hiệu chỉnh 60 6/71 MỞ ĐẦU Trong kỷ nguyên công nghệ và nền kinh tế đa chiều, phần mềm đã và đang đóng một vai trò vô cùng quan trọng trong việc định hướng phát triển cho mọi doanh nghiệp và góp phần gia tăng giá trị cạnh tranh trong cộng đồng. Tại Việt Nam tổng doanh thu từ ngành công nghệ thông tin năm 2008 là 4,074 tỷ USD [1]. Xây dựng các dự án phần mềm thành công luôn là mối quan tâm hàng đầu đối với mọi tổ chức doanh nghiệp. Đặc biệt quan trọng là quá trình quản lý, kiểm soát tiến độ và chất lượng dự án. Quản trị dự án là một quá trình thực hiện các hoạt động hoạch định, tổ chức, điều khiển và kiểm soát các giai đoạn của một dự án từ khâu hình thành, thẩm định, triển khai và vận hành dự án theo một mục tiêu nhất định, đến đánh giá hiệu quả đạt được của dự án trong từng thời kỳ và trong cả thời hạn đầu tư , đồng thời phối hợp các giai đoạn của dự án với nhau làm cho dự án hoạt động nhịp nhàng và có hiệu quả cao. Các vấn đề thường xảy ra đối với một dự án phần mềm  Thời gian thực hiện dự án vượt mức dự kiến  Chi phí thực hiện dự án vượt mức dự kiến  Kết quả của dự án không như dự kiến  Phát sinh rủi ro Vì vậy quá trình ước lượng cho dự án phần mềm ban đầu là quá trình rất quan trọng và quyết định lớn vào thành công của dự án. Ước lượng sớm và chính xác chi phí dự án phần mềm từ lâu đã là một thách thức lớn đối với các nhà quản trị dự án. Đã có một vài mô hình ước lượng được đề xuất và áp dụng trong thực tế như COCOMO, SLIM (Putnam)... Tuy nhiên, những mô hình này đều cứng nhắc và có độ tin cậy không cao, nhất là khi áp dụng vào những giai đoạn đầu của quá trình phát triển. Luận văn này áp dụng phương pháp lập luận theo kinh nghiệm để giải quyết bài toán trên: xây dựng một mô hình hỗ trợ ước lượng dự án phần mềm. Hướng tiếp cận của mô hình là sử dụng mô hình lập luận theo tình huống (Case-based reasoning- CBR) - một mô hình suy luận thường thấy ở các chuyên gia. Trong mô hình CBR, chi phí cho một dự án được 7/71 ước lượng bằng cách tìm kiếm những dự án tương tự đã trong quá khứ và hiệu chỉnh chi phí của các dự án đó cho phù hợp với ngữ cảnh của dự án mới. Mô hình này có thể áp dụng được ngay tại những pha ban đầu của quá trình phát triển khi dữ liệu phân tích còn chưa đầy đủ. Luận văn nghiên cứu về ước lượng chi phí đặc biệt là phương pháp lập luận theo tình huống CBR áp dụng cho ước lượng chi phí phần mềm và chúng tôi có thực hiện xây dựng chương trình ước lượng vâ ̣n du ̣ng vào ước lươ ̣ng dự án ta ̣i đơn vi ̣đang công tác trong đó có cải tiến một số thông số biểu diễn dự án và đầu ra ước lượng. Các phần còn lại của luận văn có cấu trúc như sau. Chương 1 trình bày khái quát về ước lượng chi phí phần mềm. Chương 2 trình bày về lý thuyết phương pháp lập luận trên kinh nghiệm CBR. Chương 3 đưa ra cách thức chi tiết trong áp dụng phương pháp CBR vào ước lượng chi phí phần mềm. Chương 4 mô tả thực nghiệm với hệ thống các dự án tại đơn vị công tác và có đánh giá kết quả thực nghiệm. Chương 5 tổng kết lại những kết quả đạt được sau quá trình nghiên cứu và hướng nghiên cứu tiếp theo. 8/71 1. CHƢƠNG 1 GIỚI THIỆU Trong chương này giới thiệu tổng quan về quản lý dự án và ước lượng chi phí phần mềm, những khó khăn gặp phải trong quá trình ước lượng chi phí của một dự án phần mềm. Từ đó đưa ra một số phương pháp phổ biến được áp dụng trong quá trình ước lượng dự án phần mềm, đánh giá ưu nhược điểm của các phương pháp làm cơ sở cho quá trình lựa chọn CBR trong ước lượng chi phí dự án phần mềm. ______________________________________________________________  Tổng quan quá trình quản lý dự án  Tổng quan ước lượng chi phí dự án phần mềm  Bài toán đặt ra  Giới thiệu các phương pháp ước lượng.  Đánh giá ưu nhược điểm các phương pháp ước lượng. ______________________________________________________________ 9/71 1.1 Quản lý dự án phần mềm Trong thuật ngữ của chuyên ngành kỹ 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 trong dự án và cả quy trình thực hiện dự án; nhằm đảm bảo thành công cho dự án [1]. 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à chất lượng. Ba yếu tố này được gọi là tam giác dự án. Các vấn đề thường xảy ra đối với một dự án phần mềm  Thời gian thực hiện dự án vượt mức dự kiến  Chi phí thực hiện dự án vượt mức dự kiến  Kết quả của dự án không như dự kiến Trách nhiệm của người quản lý dự án  Quản lý thời gian: Lập lịch, kiểm tra đối chiếu quá trình thực hiện dự án với lịch trình, điều chỉnh lịch trình khi cần thiết  Quản lý tài nguyên: xác định, phân bổ và điều phối tài nguyên  Quản lý sản phẩm: thêm, bớt các chức năng phù hợp với yêu cầu của khách hàng  Quản lý rủi ro: xác định, phân tích rủi ro và đề xuất giải pháp khắc phục  Tổ chức cách làm việc Chính vì vậy việc ước lượng chi phí là khâu quyết định của các doanh nghiệp sản xuất phần mềm trong việc thúc đẩy sản xuất và đưa ra những quyết định đúng đắn về tài chính của doanh nghiệp. 1.2 Ƣớc lƣợng chi phí dự án phần mềm Ước lượng chi phí và thời gian thực hiện dự án quan trọng không chỉ bởi có ảnh hưởng đến chất lượng sản phẩm mà còn có thể ảnh hưởng trực tiếp tới chiến lược phát triển lâu dài của cả công ty. Trước thập kỷ 70, người ta thường tìm cách áp dụng những phương pháp ước lượng truyền thống của công nghiệp chế tạo để ước lượng dự án phần mềm. Tuy nhiên, do phần mềm là một sản phẩm trí tuệ đặc biệt, không có phép đo trực tiếp nên các phương pháp ước 10/71 lượng này tỏ ra không hiệu quả. Sang thập kỷ 80 và 90, một vài mô hình đặc thù đã được đề xuất nhằm nâng cao độ chính xác của các ước lượng (SLIM, PRICES, COCOMO, ESTIMACS . . . )[4]. Vào thời điểm đề xuất, các mô hình này đều khẳng định là sẽ cho kết quả chấp nhận được nhưng sau một thời gian ứng dụng, kết quả thu được vẫn có thể có sai số tới 300 - 400%. Nguyên nhân của sự sai khác trên là do chúng đều được xây dựng dựa trên cơ sở các mô hình thống kê trừu tượng và xem xét các yếu tố ngữ cảnh một cách cứng nhắc. Trong khi đó, phát triển phần mềm lại là lĩnh vực luôn vận động và biến đổi không ngừng và phụ thuộc nhiều vào những yếu tố khách quan bên ngoài. Ngoài ra, hầu hết các mô hình được đề xuất đều đòi hỏi thông tin đầu vào tương đối chi tiết (kích thước dự án, kích thước dữ liệu...). Vì thế, nếu áp dụng vào những giai đoạn đầu của quá trình phát triển (giai đoạn đòi hỏi ước lượng) sẽ cho kết quả không chính xác. Trên thực tế, để đảm bảo độ tin cậy, các chuyên gia vẫn thường phải ước lượng dựa trên kinh nghiệm và phán đoán chủ quan của mình. Trong những năm gần đây, khoa học máy tính nói chung và ngành trí tuệ nhân tạo (AI) nói riêng đã có những bước tiến đáng kể [9]. Nhiều quá trình đòi hỏi óc tư duy sáng tạo đã từng bước được tự động hóa. Nhiều hệ chuyên gia thuộc các lĩnh vực khác nhau như giáo dục, y tế, pháp luật... đã được xây dựng nhằm thỏa mãn nhu cầu con người. Tuy nhiên, số lượng những sản phẩm phục vụ cho quản lý dự án phần mềm lại không nhiều. Phần lớn các công cụ hỗ trợ hiện nay như Microsoft Project, Rational Rose, Source Safe. . . chỉ giải quyết được những vấn đề thuộc về biểu diễn nghiệp vụ và lưu trữ thống kê. Những yêu cầu đòi hỏi khả năng thông minh và năng lực suy luận cao vẫn do con người đảm nhận. Từ những thực tế trên, nhiệm vụ đặt ra đối với đề tài luận văn là nghiên cứu xây dựng một mô hình hệ chuyên gia hỗ trợ ước lượng dự án phần mềm một cách tương đối chính xác, đáp ứng được những đòi hỏi trong thực tế. Trên cơ sở đó, luận văn cũng tiến hành cài đặt thử nghiệm một chương trình, cho phép ước lượng tự động các dự án phần mềm. Hướng tiếp cận được đề xuất trong đề tài là dựa trên mô hình lập luận theo tình huống (Case based reasoning - CBR). Theo hướng tiếp cận này, chi phí cho một dự án được ước lượng bằng cách tìm kiếm các dự án tương tự đã hoàn thành trong quá khứ và hiệu chỉnh kết quả các dự án đó để phù hợp với ngữ cảnh của dự án mới. Mô hình này tương đối gần với phương pháp ước lượng mà chúng ta vẫn thường thấy ở các chuyên gia. Công việc ước lượng nhằm thực hiện các mục tiêu: 11/71  Dự toán ngân sách  Xác định điểm hòa vốn và phân tích rủi ro  Lập kế hoạch và điều phối dự án  Phân tích tình hình đầu tư Đối với người quản trị dự án, có nhiều đại lượng chưa biết cần được ước lượng. Các đại lượng này thường nằm trong các lĩnh vực:  Chi phí phát triển dự án  Lịch trình phát triển dự án  Quy mô đội phát triển  Khối lượng phần mềm cần phát triển  Yêu cầu tài nguyên phần cứng Tuy nhiên, không giống như việc ước lượng các đại lượng hữu hình (sản phẩm công nghiệp, công trình xây dựng. . . ), ước lượng phần mềm là một công việc rất khó khăn. Các dự án chỉ có thể ước lượng một cách tương đối chính xác khi đi về các pha phát triển sau. Điều này hoàn toàn không có ý nghĩa nếu mục đích của ước lượng là làm căn cứ để lập kế hoạch. Thực tế đã chứng minh rằng có tới 15% các dự án đã phải bỏ dở do chi phí phát triển vượt xa ước lượng ban đầu. Nguyên nhân của tình trạng trên là do đặc thù của phần mềm là một sản phẩm trí tuệ vô hình, không thể đo được một cách trực tiếp. Các số liệu thu được thường rất phức tạp và không thể hiện được mọi đặc trưng của phần mềm. Hơn nữa, với sự biến đổi nhanh của công nghệ, việc dự đoán trước để đưa ra một chuẩn chung đánh giá mọi phần mềm là rất khó khăn. Chính vì vậy, chúng ta không thể áp dụng những phương pháp ước lượng công nghiệp truyền thống cho lĩnh vực công nghệ phần mềm. 1.3 Các phƣơng pháp ƣớc lƣợng Trải qua 60 năm phần mềm tồn tại và được phát triển, đã có nhiều mô hình và phương pháp ước lượng được đưa ra nhằm ước lượng chính xác được chi phí cũng như thời gian thực hiện dự án. Mỗi phương pháp đều có ưu và nhược điểm và hầu hết chỉ áp dụng được trong một số trường hợp ngữ cảnh cụ thể. 12/71 Các phương pháp ước lượng được phân loại thành sáu nhóm chính [4] như Hình 1 Hình 1 Các kỹ thuật ước lượng theo giai đoạn  Mô hình cơ bản trong ước lượng chi phí phần mềm : o Putnam‟s Software Life-cycle Model (SLIM) o CHECKPOINT o PRICE-S o ESTIMACS o SEER-SEM o SELECT Estimator o COCOMO  Kỹ thuật ước lượng cải tiến o DELPHI o Work breakdown structure (WBS)  Ước lượng với hệ chuyên gia o Case Based Reasoning (CBR) o Neural Networks  Kỹ thuật ước lượng động  Kỹ thuật ước lượng hồi quy o Ordinary Least Squares (OLS) o Hồi quy Robust  Kỹ thuật kết hợp 13/71 o Bayesian 1.3.1 Các mô hình ƣớc lƣợng cơ bản 1.3.1.1 Putnam’s Software Life-cycle Model (SLIM) Mô hình SLIM [4] được đề xuất dựa trên những phân tích của Putnam, sử dụng phân phối Rayleigh về quan hệ giữa số lượng nhân lực và thời gian phát triển của dự án trong vòng đời phát triển (Hình 2). Công thức ước lượng mức vĩ mô là : S s  Ck K 1 / 3t d4 / 3 (1) Trong đó: o Ss : số lượng dòng mã lệnh nguồn o K : nỗ lực trong vòng đời, tính bằng người-năm (man-years) o td : thời gian phát triển tính bằng năm o Ck : một “hằng số kỹ thuật” Giá trị của C thường nằm trong khoảng từ 57.314 đến 610. Phiên bản SLIM mới cho phép tính Ck dựa trên các dự án trong quá khứ hoặc xem nó dưới dạng một hàm của các nhân tố của dự án như ngôn ngữ lập trình, ràng buộc phần cứng, kinh nghiệm phát triển, quy trình quản lý. . .Đối với hệ thống lớn, nỗ lực phát triển DE 1 được ước lượng theo mô hình SLIM sẽ xấp xỉ bằng 40% nỗ lực phát triển trong cả vòng đời. Đối với những hệ thống nhỏ hơn, tỉ lệ này sẽ thay đổi và là một hàm của kích thước hệ thống. Mô hình SLIM (Hình 2) cũng có thể mở rộng để ước lượng những yếu tố định lượng khác như sự phân bổ nhân lực, chu kỳ vốn, các mốc lịch biểu chính, các mức độ tin cậy, chi phí tính toán và các chi phí cho tài liệu. 1 Development Effort 14/71 Hình 2 Phân phối Rayleigh cho nỗ lực phát triển [4] Điểm thú vị nhất của mô hình SLIM là nó cho thấy mối quan hệ giữa nỗ lực phát triển K và thời gian phát triển td. Đối với một hệ thống có kích thước cho trước, từ phương trình 1 chúng ta có: K const t4 (2) Như vậy là nỗ lực phát triển là đại lượng rất phi tuyến đối với thời gian phát triển. Để giảm thời giản phát triển đi 1/2 thì phải tăng nỗ lực lên gấp 16 lần. Ngoài ra, mô hình SLIM cũng đưa ra một số công cụ ước lượng các yếu tố bên trong của dự án như đường cong phân phối Rayleigh cho các nỗ lực phát triển một lần, ước lượng rủi ro và độ bất định, ước lượng thời gian phát triển tối thiểu cho dự án có nỗ lực phát triển bị ràng buộc trước. 1.3.1.2 Checkpoint Checkpoint là công cụ hỗ trợ ước lượng được phát triển năm 1997. Nó có cơ sở dữ liệu bao gồm 8000 dự án phần mềm và tập trung vào bốn mảng cần thiết để quản lý nâng cao chất lượng và hiệu quả sản xuất. Nó sử dụng các đặc tính chức năng là đầu vào chính để tính kích thước dự án. 15/71 Ước lượng : dự kiến nỗ lực ở 4 mức chính gồm dự án, pha phát triển, hoạt động, và các đầu công việc. Ước lượng bao gồm cả nhân lực, sản phẩm bàn giao, các lỗi dự kiến, chi phí và kế hoạch. Đo lường : kiểm soát đưa ra những số liệu chỉ tiêu của dự án nhắm phân tích, đưa ra những bài học kinh nghiệm và phát triển tri thức để ước lượng nội bộ. Đánh giá : đánh giá quá trình thực hiện để so sánh con số thực tế với số liệu dự kiến. Kiểm soát còn đánh giá được những ưu và nhược điểm của môi trường phát triển phần mềm. Những đề xuất cải tiến quy trinh có thể được ghi nhận lại và quyết định giá cả cũng như lợi nhuận trong quá trình thực thi. 1.3.1.3 PRICE-S Mô hình PRICE-S [4] được bắt đầu được phát triển nhằm sử dụng nội bộ trong dự án phần mềm thuộc chương trình Apollo moon. Phát hành năm 1977 như là mô hình độc quyền và sử dụng trong ước lượng cho US DoD, NASA và những dự án phần mềm của chính phủ. Toàn bộ công thức tính không được công bố tuy nhiên một vài công thức được công bố vào năm 1988. Mô hình ước lượng Price-s bao gồm 3 mảng chính có thể ước lượng được là giá thành, kế hoạch phát triển và kế hoạch hỗ trợ hệ thống máy tính. 1.3.1.4 ESTIMACS Mô hình ESTIMAC2 [4], được Howard Rubin đưa ra vào năm 1983 dựa trên mô hình Quest. Đây là một mô hình “vĩ mô” đề cập khá đầy đủ đến các khía cạnh của dự án (cả phần cứng lẫn phần mềm). Tuy nhiên, mô hình nguyên thủy chỉ chủ yếu tập trung vào pha phát triển mà chưa đề cập đến pha bảo trì. Rubin đề ra 6 chiều ước lượng và một ánh xạ thể hiện quan hệ giữa chúng. Đối với từng chiều ước lượng Rubin định nghĩa những nhân tố, gọi là nhân tố dự án, để đặc tả tổng thể dự án. Dữ liệu cho các nhân tố này được thu thập thông qua một bảng các câu hỏi được soạn sẵn. Mô hình ESTIMACS được chia làm 5 mô hình con: o Ước lượng nỗ lực phát triển o Ước lượng nhân lực và chi phí 2 mô hình này được phát triển dưới sự tài trợ của Management and Computer Services - MACS 16/71 o Ước lượng cấu hình phần cứng o Ước lượng rủi ro o Phân tích tình hình vốn Chi tiết về các phương pháp ước lượng cho từng mô hình không được công bố do ESTIMACS là sản phẩm thương mại. Tuy nhiên, về cơ bản ước lượng này là một hàm của các nhân tố dự án, trong đó đầu ra của mô hình con này có thể là đầu vào của con mô hình kia. 1.3.1.5 SEER-SEM SEER-SEM là sản phẩm được đề xuất bởi Galorath, hội liên hiệp El Segundo, California [4]. Mô hình này dựa trên mô hình Jensen gốc đã được đưa ra thị trường trong khoảng 15 năm. Trong suốt thời gian này nó được phát triển thành công cụ hữu dụng trong phương pháp ước lượng từ trên xuống và từ dưới lên. Phạm vi của mô hình rất rộng. Nó bao gồm tất cả các pha của vòng đời phát triển phần mềm, từ giai đoạn khởi tạo ban đầu tới thiết kế, phát triển, triển khai và bảo trì. Nó bao gồm những biến môi trường và tham số cấu hình ứng dụng. Mô hình này sử dụng ước lượng trên cả phương thức và ngôn ngữ. Những cách thức phát triển bao gồm hướng đối tượng, tái sử dụng, COTS, lặp, thác nước, mẫu thử và phát triển tăng dần. Ngôn ngữ phát triển đời thứ 3 hoặc 4 như C++, FORTRAN, COBOL, Ada…Nó cũng cho phép việc nhập những yêu cầu thiết kế, chuẩn quy trình và rủi ro có thể có như là những ràng buộc của quá trình ước lượng. Hình 3 thể hiện đầu vào và đầu ra của hệ thống ước lượng Hình 3 Đầu vào và đầu ra của mô hình ước lượng SEER-SEM 17/71 Các chức năng của mô hình SEER-SEM  Cho phép ước lượng theo các mức độ, ràng buộc về ép tiến độ và kế hoạch thực hiện được đưa vào như là những biến độc lập.  Hỗ trợ việc mở rộng phạm vi và phân tích để cân đối những tham số đầu vào.  Tổ chức những thành phần dự án theo cấu trúc WBS3  Hiển thị quá trình ước lượng dự án  Cho phép tương tác với các thành phần kế hoạch của dự án trên biểu đồ phân cấp Gantt,  Thực hiện ước lượng trên những dữ liệu của các dự án đã tồn tại. Mô hình có những đặc điểm chính sau : Tham số : kích thức, nhân sự, độ phức tạp, môi trường và ràng buộc – mỗi thuộc tính có nhiều tham số độc lập ; tập danh sách các platform và ứng dụng, những phương thức phát triển, chuẩn tương thích, kinh nghiệp của người sử dụng. Kết quả ước lượng : nỗ lực, kế hoạch, số lượng nhân sự, số lỗi và chi phí ; thông số ước lượng thời gian, nhân sự và nỗ lực là ràng buộc với nhau. Phân tích rủi ro : phân tích có thể là ít nhất hoặc gần giống với giá trị của các tham số đầu ra ; có thể điều chỉnh các thành phần riêng biệt của WBS, cho phép sắp xếp các thành phần ước lượng theo mức độ quan trọng. Phương thức ước lượng độ lớn dự án : theo hướng chức năng, cả Đầu ra và giao diện : có nhiều chỉ tiêu, hàng trăm báo cáo và biểu đồ, phân tích các yêu tố để so sánh điều chỉnh ; có khả năng tích hợp với các hệ thống ứng dụng Windows khác. 1.3.1.6 Mô hình COCOMO Mô hình ước lượng COCOMO4 [5] được Boehm đề xuất vào năm 1981, là một trong những mô hình phổ biến nhất trong thập kỷ 80. Mô hình này ước lượng dựa trên kích thước dự án. Ưu điểm nổi bật của mô hình này là đã hình thức hóa được các nhân tố trong một dự án phần mềm để từ đó làm căn cứ xây dựng một mô hình ước lượng khách quan. 3 4 WBS_ Work breakdown structures COntractive COst MOdel 18/71 Phương trình COCOMO tổng quát có dạng như sau: Effort  C1  EAF  (Size) P1 Time  C 2  ( Effort ) P 2 (3) (4) Trong đó: o Effort: nỗ lực tính bằng staff-months o C1: hằng số tỉ lệ cho nỗ lực o EAF5: hệ số hiệu chính phụ thuộc vào miền bài toán, nhân tố con người, môi trường, công cụ phát triển v.v. o Size: kích thước của sản phẩm cuối tính bằng số dòng mã lệnh (LOC-Line Of Code) o P1: thừa số mũ biểu hiện khả năng tiết kiệm chi phí (tái sử dụng, năng lực quản lý . . . ) o Time: thời gian tính bằng tháng o C2: hệ số tỷ lệ cho lịch biểu o P2: số mũ biểu thị sự khả năng tận dụng thời gian (phát triển song song) Mô hình COCOMO nguyên thủy được xây dựng dựa trên dữ liệu từ 56 dự án, trong đó Boehm đã chia các phần mềm thành 3 mode là:  Mode tổ chức: gồm những dự án trong nội bộ tổ chức, độ phức tạp thấp và có quy trình phát triển linh hoạt. Các yêu cầu chức năng, chất lượng, giá thành và lịch trình có thể thay đổi linh hoạt mà không ảnh hưởng tới lớn chi phí chung.  Mode nhúng: gồm những phần mềm nhúng, không hoạt động độc lập. Các yêu cầu về độ phức tạp, độ tinh cậy, và tính ổn định trong phát triển là rất cao.  Mode nửa gắn: là một mode trung gian giữa hai mode trên. Công thức ước lượng cho cả 3 mode đều có dạng 1.3 và 1.4, chỉ sai khác nhau về các hệ số C1, C2, P1, P2 (xem bảng 1) Bảng 1 Hệ số các mode trong mô hình COCOMO 5 Effort Adjustment Factor