2.2.3 Mô hình ước lượng Putnam
Mô hình ước lượng Putnam là một mô hình đa biến động, giả thiết có một sự phân bố riêng về nỗ lực trên vòng đời của dự án phát triển phần mềm [20]. Mô hình này đã được suy dẫn từ phân bố lao động thường gặp phải trong các dự án lớn (công sức tổng cộng khoảng 30 người-năm hoặc hơn). Tuy nhiên, có thể ngoại suy cho các dự án phần mềm nhỏ hơn.
Phân bố công sức cho các dự án phần mềm lớn có thể được biểu diễn ở hình 2.2:
Hình 2.2 Phân bố công sức – điểm lớn
Đường cong lớn trong hình này có dạng cổ điển lần đầu tiên được Rayleigh mô tả theo cách vẽ phân tích. Dữ liệu kinh nghiệm trên việc phát triển hệ thống do Norden thu thập, đã được dùng để thay thế cho đường cong. Do đó, phân bố công sức được vẽ trên hình còn được gọi là đường cong Rayleigh – Norden.
Đường cong Rayleigh – Norden có thể được dùng để suy dẫn ra “phương trình phần mềm” đặt quan hệ giữa số các dòng mã bàn giao (câu lệnh gốc) với công sức và thời gian phát triển như sau:
1 4 3 3
k d
L = C K t
Với Ck là hằng trạng thái công nghệ và phản ánh “ràng buộc hiệu năng là trở ngại tiến độ của người lập trình”. Các giá trị điển hình có thể là Ck = 2000 cho môi trường phát triển phần mềm nghèo nàn (không có phương pháp luận, ít tư liệu, xử lý theo lô), Ck = 8000 cho môi trường phát triển phần mềm tốt (có phương pháp luận, tài liệu thích hợp, xử lý thực hiện tương tác), Ck = 11000 cho một môi trường “tuyệt vời” (công cụ và kỹ thuật tự động hóa). Hằng Ck có thể được suy diễn cho các điều kiện cục bộ dùng dữ liệu lịch sử thu thập từ công thức phát triển quá khứ. Bố trí lại phương trình phần mềm trên có thể đi tới một biểu thức cho công sức phát triển K*:
3 3 4 k d L K = C t
Với K là công sức (theo người-năm) dành cho toàn bộ vòng đời phát triển và bảo trì phần mềm, còn td là thời gian phát triển theo năm. Phương trình cho công sức phát triển có thể được liên hệ với chi phí phát triển bằng việc bao hàm nhân tố tỷ lệ lao động ($/người-năm).
Mối quan hệ lũy thừa cấp cao cho trong phương trình phần mềm có thể chỉ ra rằng, sự mở rộng tương đối nhỏ trong ngày bàn giao có thể tạo ra sự tiết kiệm khá lớn cho công sức dùng trong dự án. Nói cách khác, mối quan hệ giữa công sức cần dùng và thời hạn bàn giao là phi tuyến cao độ.
Người lập kế hoạch dự án phần mềm phải ước lượng ba điều trước khi một dự án bắt đầu: dự án kéo dài bao lâu, cần bao nhiêu công sức và bao nhiêu người cần tham gia. Bên cạnh đó, người lập kế hoạch phải dự kiến các tài nguyên (phần cứng và phần mềm) sẽ cần tới và rủi ro trong dự án.
2.2.4 Công cụ ước lượng tự động
Kỹ thuật phân rã và các mô hình ước lượng kinh nghiệm được mô tả ở các mục trên có thể được cài đặt trong các phần mềm. Những công cụ ước lượng tự động hóa này cho phép người lập kế hoạch ước lượng chi phí và công sức và thực hiện các phân tích. Mặc dù đã có nhiều công cụ ước lượng tự động hóa nhưng tất cả đều có cùng đặc trưng tổng quát và yêu cầu một hay nhiều phân loại dữ liệu sau:
1. Ước lượng định lượng về cỡ dự án (LOC) hay chức năng (FP).
2. Các đặc trưng định lượng về dự án như độ phức tạp, độ tin cậy cần có hoặc yêu cầu nghiệp vụ.
3. Một mô tả nào đó về đội ngũ phát triển và/hoặc môi trường phát triển.
Mô hình được cài đặt bởi các công cụ ước lượng tự động xây dưng trên cơ sở các mô hình cho ra những ước lượng về công sức cần để hoàn thành dự án, chi phí, đội ngũ nhân viên, và trong một số trường hợp, phát triển cả lịch biểu và rủi ro liên quan.
Một số công cụ ước lượng tự động dựa trên COCOMO như: BYL (Before You Leap – trước khi bạn hành động) được nhóm GORDEN phát triển, WICOMO (Wang Institute Cost Model) do viện nghiên cứu Wang phát triển, DECPlan do công ty DEC phát triển. Mỗi công cụ này đều yêu cầu người dùng phải cung cấp các ước lượng LOC ban đầu. Những ước lượng này được phân loại theo ngôn ngữ lập trình. Người dùng cũng phải xác định giá trị cho các thuôc tính hướng dẫn chi phí đã mô tả trong các mục trên.
Một hệ thống tính chi phí tự động dựa trên đường cong Rayleigh - Norden cho vòng đời phần mềm và mô hình ước lượng Putnam là SLIM. Hệ thống này giúp cho người lập kế hoạch phần mềm thực hiện các chức năng: (1) định cỡ môi trường phát triển phần mềm bằng cách diễn giải dữ liệu lịch sử do người lập kế hoạch cung cấp, (2) tạo ra một mô hình thông tin về phần mềm cần phát triển bằng cách suy luận ra các đặc trưng phần mềm cơ sở, thuộc tính nhân sự và những xem xét về môi trường, (3) tiến hành định cỡ phần mềm. Cách tiếp cận trong SLIM là phức tạp hơn, tự động hóa hơn trong kỹ thuật đánh giá LOC.
ESTIMACS là một mô hình ước lượng vĩ mô dùng phương pháp ước lượng điểm chức năng có nâng cao để kiểm soát sự biến thiên của các nhân tố dự án và con người. Công cụ này giúp cho người lập kế hoạch có khả năng ước lượng được: (1) công sức phát triển hệ thống, (2) nhân viên và chi phí, (3) cấu hình phần cứng, (4) rủi ro, (5) hiệu quả vốn đầu tư phát triển.
SPQR/20 do Software Productivity Research phát triển, cho người dùng một tập đơn giản các câu hỏi nhiều lựa chọn, đề cấp tới: kiểu dự án (chương trình mới, bảo trì), phạm vi dự án (bản mẫu, môđun dùng lại), mục tiêu (thời hạn tối thiểu, chất lượng cao nhất), lớp dự án (chương trình, sản phẩm cá nhân), kiểu ứng dụng (theo lô, hệ chuyên gia), tài liệu người dùng (hình thức, không hình thức), thời gian đáp ứng, kinh nghiệm nhân viên, phần trăm mã gốc dùng lại, ngôn ngữ lập trình, độ phức tạp logic của thuật toán, độ phức tạp mã và dữ liệu… là những đầu vào. SPQR/20 sẽ đưa ra các dữ liệu đã được mô tả cho các công cụ khác, ngoài ra còn ước lượng tổng số trang tư liệu dự án, tổng số khiếm khuyết tiềm năng của dự án, tổng số khiếm khuyết khi bàn giao, số các khiếm khuyết theo KLOC…
Costar là công cụ ước lượng chi phí phần mềm dựa trên COCOMO được mô tả bởi Dr Barry Boehm trong cuốn Software Engineering Economics và cuốn
Software Cost Estimation with COCOMO II. Phần mềm quản lý dự án sử dụng Costar cho kết quả ước lượng thời gian của dự án và chi phí của dự án.
2.2.5 Mô hình lập luận theo kinh nghiệm – CBR
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
3.2 Cơ sở của UCP
Phương pháp “điểm ca sử dụng”- UCP để định cỡ và ước lượng các dự án phần mềm theo hướng đối tượng được Gustav Karner đề xuất năm 1993 [9]. Nó là sự mở rộng của phân tích điểm chức năng (FPA) và Mk II FPA (một biến thể của FPA dùng ở Vương quốc Anh).
Mô hình ca sử dụng là một kỹ thuật phổ biến rộng rãi và được chấp nhận để nắm bắt yêu cầu nghiệp vụ của một dự án phần mềm. Các ca sử dụng thể hiện phạm vi chức năng của dự án, phân tích các nội dung của nó cung cấp một cách nhìn sâu sắc về các nỗ lực và kích thước cần thiết để thiết kế và thực thi một dự án.
Nói chung, với các dự án lớn, các ca sử dụng phức tạp mất nhiều công sức để thiết kế và thực hiện hơn các dự án nhỏ với các ca sử dụng ít phức tạp hơn. Hơn nữa, thời gian để hoàn thành dự án bị ảnh hưởng bởi các yếu tố như:
− Số lượng các bước để hoàn thành ca sử dụng.
− Số lượng và sự phức tạp của các tác nhân.
− Các yêu cầu kỹ thuật của ca sử dụng như tính tương tranh, bảo mật và hiệu năng.
− Các yếu tố môi trường khác như kinh nghiệm và hiểu biết của đội phát triển.
Ước lượng ban đầu dựa trên các ca sử dụng có thể được thực hiện khi có một số hiểu biết về các miền vấn đề, kích thước và kiến trúc hệ thống ở giai đoạn mà tại đó ước lượng được thực hiện. Các thông tin liên quan UML có thể được dùng như là một tài nguyên chính xác để ước lượng. Phương pháp điểm ca sử dụng là phương pháp ước lượng và định cỡ phần mềm dựa trên biểu đồ ca sử dụng [10].
Biểu đồ ca sử dụng chủ yếu bao gồm hai tài liệu, tài liệu hệ thống hoặc hệ thống con và tài liệu ca sử dụng mà bao gồm các mục sau: tên hệ thống, các yếu tố rủi ro, biểu đồ ca sử dụng mức hệ thống, sơ đồ kiến trúc, các mô tả hệ thống con, tên ca sử dụng, mô tả tóm tắt, ngữ cảnh, tiền điều kiện, luồng sự kiện, hậu điều kiện, các biểu đồ ca sử dụng mức dưới, biểu đồ hoạt động, các lớp tham gia, các biểu đồ tuần tự, giao diện người dùng, các quy tắc nghiệp vụ, các yêu cầu đặc biệt và các nhân tố khác.
3.3 Nội dung phƣơng pháp
Dựa trên công trình của Gustav Karner [19], phương pháp UCP phân tích những tác nhân, các kịch bản ca sử dụng, các yếu tố môi trường và kỹ thuật khác nhau và khái quát thành một phương trình.
Phương trình UCP gồm có 3 biến số:
1. Điểm ca sử dụng không được điều chỉnh (Unadjusted Use Case Points – UUCP).
2. Yếu tố phức tạp kỹ thuật (Technical Complexity Factor – TCF) . 3. Yếu tố phức tạp môi trường (Environment Complexity Factor – ECF).
Mỗi biến được xác định nghĩa và tính toán độc lập bằng cách sử dụng giá trị trọng số, các giá trị chủ quan và các hằng số ràng buộc. Các giá trị trọng số và các hằng số ràng buộc ban đầu dựa trên Albrecht, nhưng sau đó được sửa đổi theo các hệ thống mục tiêu (khách quan), LLC, dựa trên kinh nghiệm của họ theo cách nhìn đối lập – một phương pháp được tạo ra bởi Ivar Jacobson cho phát triển các ứng dụng hướng đối tượng. Các giá trị chủ quan được xác định bởi nhóm phát triển dựa trên nhận thức của họ về sự phức tạp kỹ thuật và hiệu quả của dự án.
Ngoài ra, khi năng suất được xem như một hệ số thể hiện thời gian, phương trình có thể được dùng để ước lượng số nhân lực và thời gian cần thiết để hoàn thành một dự án. Dưới đây là phương trình hoàn thiện với nhân tố năng suất (Productivity Factor – PF):
UCP = UUCP * TCF * ECF * PF
1. Xác định và tính UUCPs. 2. Xác định và tính TCFs. 3. Xác định và tính ECFs. 4. Xác định PF.
5. Tính ước lượng về số giờ.
Các biểu đồ ca sử dụng có các hành vi chức năng của hệ thống đích, xác