Mô hình lập luận theo kinh nghiệm (Case-based reasoning - CBR) [18] giải quyết bài toán phù hợp với những miền có tính chất mở như ước lượng chi phí dự án phần mềm [25]. Trong mô hình đề xuất, chi phí cho một dự án mới được ước lượng bằng cách tìm kiếm những dự án tương tự đã có trong quá khứ sau đó hiệu chỉnh chi phí của dự án cũ đó 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 trong ngữ cảnh hẹp của một công ty, tại thời điểm ban đầu của quá trình phát triển, khi thông tin dự án còn chưa được xác định rõ ràng.
Mô hình lập luận theo kinh nghiệm được nhà tâm lý học người Mỹ, Roger Schank [22] đề xuất vào năm 1982. Ý tưởng cơ bản của mô hình này là tìm lời giải bài toán trên cơ sở tìm kiếm và hiệu chỉnh lời giải của các bài toán tương tự đã có trong quá khứ. Aarmodt [18] đã biểu diễn quá trình tìm lời giải theo mô hình lập luận kinh nghiệm bằng chu trình gồm 4 pha (hình 2.2):
1. Tìm kiếm lại (Retrieve) một hoặc nhiều ca lập luận tương tự.
2. Sử dụng lại (Reuse) lời giải của các ca lập luận cũ cho ca lập luận mới. 3. Xem xét lại (Revise) lời giải.
4. Lưu lại (Retain) ca lập luận mới.
Hình 2.3 Chu trình lập luận theo kinh nghiệm
Trước một bài toán mới, hệ suy luận sẽ tìm kiếm lại một hoặc một vài ca lập luận cũ tương tự với ca lập luận xác định bài toán đó (gợi ý lời giải). Nếu lời giải của ca lập luận tìm được phù hợp với bài toán mới sẽ được sử dụng lại
ngay. Ngược lại hệ thống sẽ tìm cách hiệu chỉnh lời giải cũ để đưa ra một lời giải mới. Quá trình xem xét lại lời giải sẽ xác minh xem lời giải được đưa ra có thực sự phù hợp khi áp dụng vào thực tế hay không. Cuối cùng nếu cần thiết, hệ suy luận sẽ lưu lại ca lập luận mới (thành công và thất bại) để phục vụ cho các bài toán trong tương lai. Cả bốn quá trình trên đều cần có sự tham gia hỗ trợ của tri thức nền (các luật) [18, 21, 22].
Do các lập luận trong cơ sở tri thức được lưu trữ một cách riêng rẽ và cụ thể nên chúng có thể được biểu diễn khá linh hoạt mà không cần tuân theo một cấu trúc tổng quát. Mặt khác, nhờ tính chất này của ca lập luận, hệ thống CBR có thể dễ dàng cập nhật thêm các ca lập luận mới, đồng thời liên tục điều chỉnh để phù hợp với sự thay đổi của môi trường. Ví thế, CBR được xem là một mô hình phù hợp cho những miền bài toán khó đặc tả tường minh hoặc những miền bài toán có mối liên hệ phức tạp giữa các yếu tố tri thức.
CHƢƠNG 3: PHƢƠNG PHÁP ƢỚC LƢỢNG DỰ ÁN ĐIỂM CA SỬ DỤNG
3.1 Giới thiệu
Các vấn đề ước lượng trong lĩnh vực phát triển phần mềm là kích thước, nỗ lực đầu tư, thời gian phát triển, công nghệ được sử dụng và chất lượng. Điểm chức năng đo kích thước phần mềm sử dụng các khái niệm chức năng logic mà các chủ doanh nghiệp và người dùng hiểu dễ dàng hơn[17]. Cho đến nay, các phiên bản FPA khác nhau dựa trên phiên bản của Albrech đề xuất (ví dụ phương pháp IFPUG[8], MarkII[21], COSMIC-FFP[14]) đã được chấp nhận như các chuẩn ISO/IEC. Một số mô hình nỗ lực [20, 11, 17] đã được đề xuất và hầu hết đều coi kích thước phần mềm là một tham số quan trọng. Tuy nhiên, các nghiên cứu ước lượng phần mềm trên đây có một số tồn tại: thiếu cơ sở lý thuyết, thiếu các thuộc tính đo mong muốn, không đủ tổng quát, quá phụ thuộc vào công nghệ thực hiện, thước đo là chủ quan dựa trên quyết định chuyên gia và mất quá nhiều công sức để thu thập thông tin [16, 5].
Gần đây, nhiều công ty đã bắt đầu giới thiệu về các công nghệ hướng đối tượng trong quá trình phát triển phần mềm. Ngôn ngữ mô hình hóa thống nhất (Unified Modeling Language - UML ) trở thành một chuẩn thực tế để mô tả các hệ thống phần mềm phát triển theo hướng đối tượng. Nó cung cấp một kiến trúc có cấu trúc tốt và tổng quan về hệ thống thông qua các biểu đồ khác nhau đại diện cho các khung nhìn khác nhau về hệ thống. Do đó, nhiều nhà nghiên cứu đã đề xuất một số thước đo phù hợp để đo kích thước và độ phức tạp của phần mềm hướng đối tượng.
Phương pháp ước lượng hướng đối tượng có thể nắm bắt được ba khía cạnh đặc trưng của phần mềm hướng đối tượng như chức năng (hành vi của đối tượng), số lượng giao tiếp giữa các đối tượng và tỷ lệ tái sử dụng thông qua kế thừa. Trong sản phẩm phần mềm hướng đối tượng, các ca sử dụng mô tả các yêu cầu chức năng. Do đó, mô hình ca sử dụng có thể được dùng để dự đoán kích thước của hệ thống tương lai ở ngay giai đoạn đầu phát triển.
Để ước lượng nỗ lực trong giai đoạn đầu, phương pháp điểm ca sử dụng được đề xuất [9]. Điểm ca sử dụng (Use Case Point - UCP) được tính dựa trên biểu đồ ca sử dụng, định nghĩa phạm vi chức năng của hệ thống phần mềm được phát triển. Nó chịu ảnh hưởng của phương pháp điểm chức năng nhưng dựa trên đối tương tương tự là ca sử dụng