Các đặc trưng cơ bản của các mô hình ứng dụng ước lượng chi phí phần mềm thông dụng nhất và nghiên cứu mô hình COCOMO II

Tuy nhiên, theo khuyếncáo của các nhà giới thiệu các mô hình, để có được một kết quả đánh giá khả quan, có độ chính xác cao, thì mỗi tổ chức phát triển phần mềm đều cần có cách áp dụng v

PHIẾU GIAO NHIỆM VỤ ĐỒ ÁN TỐT NGHIỆP

1 Mục đích nội dung của Đồ Án Tốt Nghiệp

Tìm hiểu về mô hình ước lượng chi phí COCOMO II, từ đó xây dựng ứng dụng để ướclượng chi phí trong xây dựng và quản lý phần mềm

2 Các nhiệm vụ cụ thể của Đồ Án Tốt Nghiệp

 Tìm hiểu chung về ước lượng chi phí phần mềm qua các kỹ thuật phổ biến

 Nghiên cứu phương pháp luận của mô hình COCOMO II

 Cài đặt các giải thuật ước lượng trong mô hình COCOMO II thành một ứng dụng

có thể áp dụng trong thực tế

3 Lời cam đoan của sinh viên:

Tôi – Đoàn Hữu Hậu - cam kết Đồ Án Tốt Nghiệp là công trình nghiên cứu của bản thân tôi dưới sự hướng dẫn của Thạc sỹ Bùi Thị Hòa

Các kết quả nêu trong Đồ Án Tốt Nghiệp là trung thực, không phải là sao chép toànvăn của bất kỳ công trình nào khác

Hà Nội, ngày 20 tháng 5 năm 2008

Tác giả Đồ Án Tốt Nghiệp

Đoàn Hữu Hậu

4 Xác nhận của giáo viên hướng dẫn về mức độ hoàn thành của ĐATN và cho phép bảo vệ:

Hà Nội, ngày tháng năm

Giáo viên hướng dẫn

Thạc Sỹ Bùi Thị Hòa

Xin cảm ơn Công ty Việt Khánh JSC, Công ty Vĩnh Hưng JSC và công ty SunNet JSC

đã giúp đỡ, hỗ trợ tôi tiếp cận với công nghệ, với dữ liệu thực tế để có được những kinhnghiệm quý báu áp dụng vào đề tài

Xin cảm ơn tất cả bạn bè đã nhiệt tình giúp đỡ tôi trong việc sưu tầm tài liệu thamkhảo, tư liệu thực tế, ứng dụng mẫu phục vụ cho đề tài

Cuối cùng, con xin chân thành cảm ơn bố, mẹ và cả gia đình đã nuôi dạy, luôn tạo điềukiện tốt nhất cho con học tập và luôn quan tâm, động viên, hỗ trợ cho con, đặc biệt làtrong thời gian thực hiện đề tài

Hà nội, tháng 5 năm 2008

Người thực hiện

Đoàn Hữu Hậu

MỤC LỤC

PHIẾU GIAO NHIỆM VỤ ĐỒ ÁN TỐT NGHIỆP 1

LỜI CẢM ƠN 2

MỤC LỤC 2

LỜI GIỚI THIỆU 2

DANH MỤC CÁC TỪ VIẾT TẮT VÀ THUẬT NGỮ 2

CHƯƠNG I: TỔNG QUAN VỀ 2

ƯỚC LƯỢNG CHI PHÍ PHẦN MỀM 2

I Đối tượng ước lượng và các phương pháp xác định 2

1 Phương pháp 1: Hướng tiếp cận các độ đo câu hỏi mục tiêu 2

2 Phương pháp 2: Mô hình tạo quyết định 2

3 Phương pháp 3: Các độ đo các hệ số chuẩn 2

4 Phương pháp 4: Mở rộng GQM: Độ đo kỹ xảo 2

5 Đối tượng đo lường là một chức năng của thời gian 2

6 Tổng kết: 2

II Các kỹ thuật ước lượng chi phí phần mềm 2

1 Các kỹ thuật dựa trên mô hình: 2

2 Các kỹ thuật dựa vào chuyên gia 2

3 Các kỹ thuật hướng học 2

4 Các kỹ thuật dựa vào động học 2

5 Các kỹ thuật dựa vào hồi quy 2

6 Các kỹ thuật tổng hợp 2

CHƯƠNG II: MÔ HÌNH COCOMO II 2

1 Tổng quan 2

2 Các biểu thức ước lượng trong mô hình COCOMO II 2

3 Định kích cỡ phần mềm 2

4 Ước lượng công sức 2

5 Các hệ số nhân công sức 2

6 Ước lượng công sức cho các dự án nhiều thành phần 2

7 Bảo trì phần mềm 2

8 Tổng kết: 2

CHƯƠNG III: CHƯƠNG TRÌNH ƯỚC LƯỢNG CHI PHÍ PHẦN MỀM – ÁP DỤNG MÔ HÌNH COCOMO II 2

I Giới thiệu: 2

II Dữ liệu đầu vào: 2

III Hiệu chỉnh các giá trị chuẩn cho các tham số của mô hình 2

IV Ước lượng chi phí dự án phần mềm: 2

V Hiệu chỉnh mô hình ước lượng: 2

CHƯƠNG 4: TỔNG KẾT 2

TÀI LIỆU THAM KHẢO 2

LỜI GIỚI THIỆU

Cùng với sự phát triển mạnh mẽ và đa dạng, Công nghệ thông tin ngày càngđược ứng dụng rộng rãi vào hầu hết mọi ngành nghề và lĩnh vực khác nhau của đờisống, và do đó góp phần nâng cao hiệu quả công việc nhiều lần Do đó đề cập đếnCông nghệ thông tin là đề cập đến một vấn đề rất rộng lớn, bao gồm nhiều mảng ứngdụng khác nhau Tuy nhiên, trên thực tế, ngoài những công nghệ và các lý thuyết hỗ trợcho việc xây dựng, phát triển các phần mềm ứng dụng, vẫn chưa có nhiều nghiên cứu

về các khía cạnh khác không trực tiếp liên quan đến kỹ thuật như: vấn đề quản lý dự

án, đánh giá chất lượng sản phẩm và đặc biệt là vấn đề ước lượng chi phí phần mềm

mà từ đó có thể ước lượng đánh giá hiệu năng trong sản xuất phần mềm, tính kinh tếcủa sản phẩm phần mềm cũng như góp thêm thông tin cho việc định giá phần mềm Đểhoàn thiện thêm những kiến thức bổ trợ cho việc phát triển phần mềm trong tương lai,

em đã chọn đề tài: “Các đ c tr ng c b n c a các mô hình ng d ng ặc trưng cơ bản của các mô hình ứng dụng ước ưng cơ bản của các mô hình ứng dụng ước ơ bản của các mô hình ứng dụng ước ản của các mô hình ứng dụng ước ủa các mô hình ứng dụng ước ứng dụng ước ụng ước ưng cơ bản của các mô hình ứng dụng ướcớc c

l ưng cơ bản của các mô hình ứng dụng ướcợng chi phí phần mềm thông dụng nhất và nghiên cứu mô hình ng chi phí ph n m m thông d ng nh t và nghiên c u mô hình ần mềm thông dụng nhất và nghiên cứu mô hình ềm thông dụng nhất và nghiên cứu mô hình ụng ước ất và nghiên cứu mô hình ứng dụng ước COCOMO II” để nghiên cứu Đề tài nghiên cứu về các đặc trưng cơ bản của các môhình ứng dụng ước lượng chi phí phần mềm phổ dụng nhất Từ những tìm hiểu chi tiết

về các mô hình này, chọn ra một mô hình tiêu biểu với những ưu điểm nổi bật để càiđặt một mô hình ước lượng có tính ứng dụng Mô hình đó là mô hình COCOMO II

Trên thực tế, việc ước lượng chi phí phần mềm không hề đơn giản, đặc biệt làđối với các dự án có quy mô lớn thì quy trình đánh giá càng khó khăn Trước đây, khinhận thức chưa đầy đủ về việc ước lượng chi phí phần mềm, người ta thường tự đánhgiá chi phí phần mềm theo các mô hình riêng _ không có chuẩn mực chung Tuy nhiên,ngày nay, với nhận thức về tầm quan trọng của việc ước lượng chi phí phần mềm, hầuhết các doanh nghiệp lớn đều sử dụng các mô hình tiêu chuẩn để đánh giá Bởi lẽ: các

mô hình tiêu chuẩn đã được các nhà nghiên cứu hàng đầu trên thế giới nghiên cứu trêncác dự án của các công ty hàng đầu về công nghệ thông tin _ đây là kho dữ liệu khổng

lồ về các dự án tiền nhiệm, liên quan đến đủ mọi lình vực _ nên có được các tiêu chuẩnđánh giá có độ chính xác cao, và có thể dễ dàng hiệu chỉnh cho phù hợp với môi trườngphát triển hiện tại Hơn thế sử dụng các mô hình đánh giá tiêu chuẩn có thể dễ dàngđánh giá được hiệu năng của phần mềm, cũng như có được sự so sánh khách quan hơngiữa các phần mềm

Trong việc ước lượng chi phí phần mềm, việc đầu tiên ta cần phải xác địnhcác đối tượng cần ước lượng _ đây là một trong các đặc trưng của phần mềm và dự ánphần mềm như: kích cỡ phần mềm, thời gian phát triển,… để từ đó xác định một hướngtiếp cận phù hợp cho việc đánh giá.Với hướng tiếp cận đó ta sẽ xác định được mô hìnhtiêu chuẩn để thực hiện đánh giá

Trên thực tế, rất nhiều các mô hình ước lượng chi phí phần mềm đều dựa vàophép đo kích cỡ vật lý của phần mềm, với hai phép đo phổ biến nhất là số dòng mãlệnh SLOC (Source line of Code) và phép đo các điểm chức năng FP (Function Points)

Phép đo số dòng mã lệnh SLOC là một phép đo lâu đời nhất để đánh giá kết quả dự án,

và đồng thời cũng là cơ sở của rất nhiều mô hình đánh giá chi phí được phát triển saunày như: mô hình quản lý vòng đời phần mềm SLIM của Putnam hay mô hình chi phíxây dựng COCOMO của Boehm Mặc dù việc đánh giá SLOC sớm và chính xác caotrong vòng đời phát triển phần mềm không phải là đơn giản, và đòi hỏi kinh nghiệm,nhưng phép đo SLOC vẫn được áp dụng khá phổ biến để xác định kích cỡ vật lý phầnmềm cho các mô hình ước lượng chi phi phần mềm Một cải tiến trong phép đo kích cỡvật lý của phần mềm là đo theo các điểm chức năng FP được IBM giới thiệu vào nhữngnăm 1979

Hiện nay, hai phương pháp đo này cùng với các mô hình ước lượng chi phíphần mềm dựa vào chúng được phổ biến và áp dụng rộng rãi Tuy nhiên, theo khuyếncáo của các nhà giới thiệu các mô hình, để có được một kết quả đánh giá khả quan, có

độ chính xác cao, thì mỗi tổ chức phát triển phần mềm đều cần có cách áp dụng và hiệuchỉnh các tham số cho phù hợp với môi trường phát triển của mình, dựa theo kinhnghiệm của các dự án tiền nhiệm (đã hoàn thành) Những nghiên cứu chi tiết các môhình tiêu chuẩn, và cách thức hiệu chỉnh để áp dụng chưa được chú trọng nhiều, đặcbiệt ở Việt Nam, cho nên hầu hết các đánh giá đều dựa theo các giá trị chuẩn của cáctham số, mà chưa có những sự điều chỉnh cần thiết cho phù hợp với thực tế Vì vậy, đềtài này mong muốn góp phần mở ra một sự quan tâm nghiên cứu chi tiết hơn nữa vềvấn đề ước lượng chi phí phần mềm, về các mô hình ước lượng chi phí được áp dụng

và sự ảnh hưởng của các tham số lên ước lượng cũng như vai trò của sự điều chỉnh cáctham số này trong việc nâng cao độ chính xác cho phép ước lượng, góp phần nâng caohiệu quả quản lý cũng như hiệu năng và tính kinh tế trong sản xuất phần mềm

DANH MỤC CÁC TỪ VIẾT TẮT VÀ THUẬT NGỮ

Viết tắt Viết đầy đủ Giải thích

sử dụng COCOMO)

Adjustment Multiplier

Hệ số nhân điều chỉnh để thích ứng), phục vụ choviệc định cỡ, tái sử dụng (mô hình tái sử dụngCOCOMO)

ACAP Analyst Capability Hệ số chi phí “năng lực của người phân tích”

Experience

Hệ số chi phí “Kinh nghiệm phát triển ứng dụng”

Lines of Code

Số dòng lệnh mã nguồn được tích hợp, đượcdùng trong định cỡ tái sử dụng (mô hình tái sửdụng trong COCOMO)

Các thành phần chức năng cơ bản

Phương pháp tiến hành từ các đơn vị nhỏ hoặccác đơn vị chi tiết tới các đơn vị lớn hơn Trongmột cấu trúc phân cấp

phát triển

SoftewareEmgineering Case study

Công nghệ học phần mềm với sự trợ giúp củamáy tính

Nghiên cứu dựa trên đối tượng và hoàn cảnh cụthể

Board

Bảng theo dõi thay đổi trong quá trình phát triển

COCOMO Constructive Cost

Model

Mô hình định giá do Bochrn đưa ra năm 1981

Cost Driver Thuộc tính riêng của phát triển phần mềm, có tácđộng nhân, làm tăng hoặc giảm lượng nỗ lực.

Management System

Hệ quản trị cơ sở dữ liệu

DD Detail Design Pha thiết kế chi tiết trong mô hình thác nướcDET Data Element Type Kiểu trường dữ liệu được tham chiếu: Mỗi DET

là một trường duy nhất, không lặp lại mà ngườidùng có thể nhận biết được

Hệ số chi phí “Tài liệu phù hợp với yêu cầu củavòng đời phát triển phần mềm”

Instrucstions

Số lệnh mã nguồn bàn giao

Factor

Tích của các hệ số nhân công sức

phát hiện ra các khả năng thay thế về kiến trúc vàcác chiến lược phát triển gia tăng

EI External Inputs Nhập dữ liệu là một tiến trình cơ sở, trong đó dữ

liệu đi từ ngoài vào bên trong phạm vi của ứngdụng

EIF External Interface File giao tiếp ngoài – là một nhóm dữ liệu mà

Flie người dùng có thể nhận biết được, có liên hệ với

nhau về mặt lôgíc, chỉ được sử dụng để thamchiếu

EM Effort Multiplier Hệ số nhân công sức – một giá trị gắn với từ hệ

số chi phí

EO External Outputs Xuất dữ liệu là một tiến trình cơ sở, trong đó dữ

liệu nhận được chuyển trừ trong ra ngoài phạm vicủa ứng dụng

EQ External InQuiry Truy vấn ngoài là một tiến trình cơ sở với cả hai

thành phần xuất và nhập dữ liệu, có kết quả là dữlliệu trả về từ một hoặc một vài file logic trong(ILF) và File giao tiếp ngoài (ELF)

Lines of Code

Số dòng mã nguồn tương đương

Flexibility

Hệ số chi phí “Tính linh hoạt của phát triển”

mềm được xác định bằng cách đếm những chứcnăng mà phần mềm cung cấp cho người dùng,chủ yếu dựa trên thiết kế logic Khái niệm “ngườidùng” ở đây là để chỉ người hiểu về hệ thống từgóc độ chức năng

Point

Điểm chức năng đầy đủ, một đo đặc biệt phù hợpvới các hệ thống nhúng và hệ thống thời gianthực

Requirement

Yêu cầu về chức năng của người sử dụng

Charaterisrics

Các đặc trưng chung của hệ thống

GUI Graphical Interface Giao diện đồ họa với người dùng

Computer Aided Software

Engineering

Kỹ nghệ phần mềm được tích hợp với sự hỗ trợcủa máy tính

IFPUG International Một tổ chức phi lợi nhuận, họat động với mục

Function Pont Users Group

đích thúc đẩy việc sử dụng phương pháp phântích điểm chức năng và các đọ đo phần mềmkhác

IN Inception Pha khởi đầu, là pha thứ nhất trong quy trình

RUPIOC Initial Operatinal

Capability

Một cột mốc được sử dụng trong quy trình RUP,xác định thời điểm đưa ra một sản phẩm có khảnăng vận hành

kỹ thuật viên Theo phương pháp này, từng nhómnhỏ tiến hành họp để quyết định về những mụctiêu của hệ thống và các giao dịch nghiệp vụ cầnđược hỗ trợ Họ được điều hành bởi một người cónhiệm vụ dẫn dắt quá trình tư duy của cả nhóm,nhằm đi tới những mục tiêu rõ rang, đúng đắn.Kết quả là đưa ra các mẫu thử của hệ thống/

Adapted Source Lines of Code

Số nghìn dòng mã nguồn được tích hợp (Mô hìnhtái sử dụng trong COCOMO)

Source Instructions

Số đếm hàng nghìn dòng mã lệnh đã bàn giao (ví

dụ mã nguồn có 15000 dòng lệnh, hệ số KDSI là15)

Source Lines of Code

Số nghìn dòng lệnh mã nguồn

Architecture review

Một cột mốc trong quy trình RUP

Objectives review

Một cột mốc trong quy trình RUP

LOC Line of Code Só dòng lệnh của mã nguồn sản phẩm.

(System) Architecting Software Engineering

Kỹ nghệ phần mềm và kiến trúc hóa hệ thống dựatrên mô hình, là một vận dụng nhỏ của mô hìnhxoắn ốc, gồm các pha Khởi đầu (Inception), Phácthảo (Elaboration), Xây dựng (Construction) vàchuyển giao (Transiton) Mô hình này định nghĩamột tập các cột mốc chung, đóng vai trò là cácđiểm chặn, dựa vào đó mà các ước lượng và đánhgiá thực tế của COCOMO được thực hiện

Change Factor

Nhân tố thay đổi trong bảo trì: phần mã cũ đượcchỉnh sửa hoặc thêm mới (mô hình bảo trì trongCOCOMO)

Square

Phương pháp bình phương cực tiểu thông thường

bao nhiêu người-tháng, hoặc ngừơi-giờ để thựchiện một khối lượng công việc đã định trước

PA Post Architecture Mô mô hình chi tiết, được sử dụng trong

COCOMO II khi dự án đã sẵn sàng cho phát triển

Hệ số chi phí “tính liên tục về nhân lực”

PD Product Design Pha thiết kê sản phần trong mô hình thác nướcPDLF Platform Difficulty Độ khó về yếu tố nền – hệ số đa hợp trong mô

PM Person-Months Một người-tháng là lượng thời gian làm việc của

dự án của một ngưồ, trong một tháng; trongCOCOMO thường giả định là 152 giờ làm việc

chi phí SCED (thời gian danh nghĩa)PMAT Process Maturity Hệ số chi phí “Độ thuần thục về quy trình”

Experience

Kinh nghiệm của nhân việ - hệ số đa hợp trong

mô hình Early Design

Review

Một cốt mốc trong mô hình RUP

PVOL Plattorm Volatility Hệ số chi phí “Tính dễ thay đổi của yêu tốt nền”

QA Quality Assurance Một phòng ban hay một chương trình trong một

tổ chức, tham gia vào quá trình kiểm thử sảnphẩm QA bảo đảm rằng tất cả các sản phẩm và

hệ thống đều hoạt động đúng như những gì đã đề

ra ban đầu

Adjustement Factor

Nhân tố điều chỉnh phần trăm kích thước do bổsung hoặc thay đổi yêu cầu

Investment

Tiền lãi từ việc đầu tư

Process

Quy trình hợp nhất của Rational (hang IBM)dùngriêng cho phát triển phần mềm Quy trình gồm 4pha cơ bản: Iception (khởi đầu); Elaboration(Phân tích, phân rã), Construction (Xây dựng) vàTransition( Bàn giao) Quy trình dành cho quản

lý sản xuất phần mềm theo mô hình lặp, khác với

Cột mốc xem xét để chấp nhận phần mềm (quytrình phát triển theo mô hình thác nước)

Development Schedule

Thời gian phát triển cần thiết; hệ số chi phí ở mức

Các độ đo trong phát triển phần mềm

Development Process

Quy trình phát triển phần mềm

Engineering Institute

Viện công nghệ học phần mềm, một trung tâmnghiên cứu và phát triển dưới sự bảo trợ của liênbang, thuộc đại học Carnegie Mellon, Mỹ

SF Scale Factor Một thuộc tính riêng của phát triển phần mềm, có

tác động theo hàm mũ, làm tăng hoặc giảm lượngcông sức phát triển

development

Hệ số tỷ lệ “phát triển đa địa điểm”

Lift-cycle Management

Một mô hình định giá dựa trên việc phân tích sựphân bố công sức thực hiện theo thời gian sảnxuất

Code

Số dòng mã lệnh nguồn

requirement Review

Cột mốc xem xét những yêu cầu của phần mềm

Cột mốc xem xét việc kết thúc quá trình chuyểngiao

TDEV Time to Develop Thời gian để phát triển phần mềm (tính theo

tháng)TEAM Team Cohension Hệ số chi phí “Tính gắn kết đội phát triển”

TIME Execution Time

Constraint

Hệ số “ràng buộc về thời gian thực thi”

Tools

Hệ số “Mức sử dụng các công cụ phần mềm”

Top-down Phương pháp tiến hành từ phần tử lớn, cơ bản đến

phần tử nhỏ và chi tiết hơn trong một hệ thốngphân cấp

Function Points

Các điểm chức năng chưa điều chỉnh

Language

Ngôn ngữ mô hình hóa hợp nhất để thể hiện cacsđặc tả yêu cầu, phân tích, thiết kế sản phẩm phầnmềm

Trường đại học nam California

Completion milestone

Cột mốc kết thúc giai đoạn kiểm thứ đơn vị

Factor

Nhân tố điều chỉnh giá trị - một trong 14 dặcchưng hệ thống GSCs

Water Fall Mô hình thác nước quản lý vòng đời phát triển

số cho mỗi hành vi của lớp đó

CHƯƠNG I: TỔNG QUAN VỀ ƯỚC LƯỢNG CHI PHÍ PHẦN MỀM

I Đối tượng ước lượng và các phương pháp xác định

Mỗi phần mềm đều có rất nhiều thuộc tính đặc trưng mà có thể là đối tượng để đo, đểước lượng như: kích cỡ, độ phức tạp, độ tin cậy, chất lượng, tính khả dụng Do đó đểxây dựng một chương trình đo, ước lượng phần mềm tốt cần xác định rõ các mục tiêucủa dự án cũng như của tổ chức phát triển phần mềm Các câu hỏi cần được trả lời như:

 Đối tượng của các phép đo là gì?

 Mục tiêu kỳ vọng về sản phẩm, quy trình, các nguồn phát triển sau các phép đo?

 Những độ đo nào thể hiện các mục tiêu đó có đạt được hay không

Sau đây ta sẽ nghiên cứu một số phương pháp xác định mục tiêu:

1 Phương pháp 1: Hướng tiếp cận các độ đo câu hỏi mục tiêu

(Goal Question Metrics Approach GQM)

GQM là một hướng tiếp cận đc Basilieta đưa ra và được chấp nhận rộng rãi như mộtcấu trúc có giá trị để giải đáp cho câu hỏi "đo lường cái gì".Nói tóm lược, GQM đưa rađịnh nghĩa về các thông số đo lường chương trình theo một cấu trúc top down như sau:

a Xác định mục tiêu của sản phẩm, tiến trình, và của nguồn _ đây là các mục tiêu màkhách hàng của các độ đo hướng tới

b Làm rõ những câu hỏi về đặc trưng cách đánh giá phương thức gặt hái những thành tựu

c Định nghĩa các độ đo để cung cấp các câu trả lời mang tính số lượng cho từng câuhỏi.Các độ đo có thể là khách quan (nếu chỉ dựa thuần túy vào đối tượng được đo) hoặc

là chủ quan (nếu dựa vào cả quan điểm đo lường và đối tượng đo)

Xét ví dụ: Ta hãy để ý sự chuyển giao một sản phẩm phần mềm: Người quản lý sảnphẩm/dự án, có thể có những mục tiêu sau cho sản phẩm:

* Mục tiêu là chuyển giao một sản phẩm phần mềm đạt các mong đợi về chức năng củakhách hàng => câu hỏi cần đặt ra là phần mềm chuyển giao cho khách hàng kia đã thayđổi bao nhiêu so với yêu cầu của khách hàng Một độ đo cần sử dụng để trả lời cho câuhỏi đó là: Số những khiếm khuyết phần mềm được đếm Thông thường, luôn có nhữngthỏa thuận về việc hình thành các khiếm khuyết, các nhược điểm, thường là dựa trên sựvận hành của phần mềm đã thay đổi trong sự thỏa thuận chặt chẽ của yêu cầu Các yêucầu càng rõ ràng, thì các độ đo càng khách quan Ở đây ta cũng có thể sử dụng một độ

đo khác: Là mức độ thỏa mãn của khách hàng dựa theo một số biểu mẫu khảo sát _

Đây là một độ đo chủ quan, hoàn toàn dựa vào quan điểm của khách hàng.

2 Phương pháp 2: Mô hình tạo quyết định

(Decision Maker Approach)

Một phương thức thứ nữa để tập hợp các độ đo là tập trung vào việc đưa ra các quyếtđịnh của dự án Các bộ tạo quyết định chính là khách hàng của các độ đo, mà các độ đođược tạo ra để làm tiện dụng cho các thông tin tới các bộ quyết định Trong phươngthức này ta cần xác định yêu cầu của bộ tạo quyết định là gì, nhận diện được tác dụngcủa chúng Phương thức này hoàn toàn gắn kết chặt chẽ với GQM với sự chú trọng tới

những quyết định được tạo ra như hình 2.1

Hiểu được các quyết định được tạo ra sẽ giúp cho đặt đúng chỗ việc đo lường dự án hỗtrợ cho việc đưa ra các quyết định Ví dụ: Một quản lý dự án cần đưa ra quyết địnhphân bố nguồn dựa trên tình trạng hiện thời với mối tương quan của tiến trình dự kiến.Anh ta cần tính toán về thời gian và cả nỗ lực/nhân lực trong cả vòng đời phát triển.Một người quản lý kiểm thử cần xác đĩnh xem chất lượng của sản phẩm phần mềm cóđạt được mức có thể chấp nhận được để chuyển giao cho khác hàng không, do đó anh

ta cần đo lường chất lượng hiện tại của sản phẩm và một cái nhìn tổng quan sau thờigian chỉnh sửa

Trong phương thức này, cần xem nhu cầu của việc đưa ra các quyết định để xác địnhcác độ đo cần dùng

3 Phương pháp 3: Các độ đo các hệ số chuẩn

(Standards Driven Metrics)

Có những tập hợp các độ đo tiêu chuẩn chung cho công nghệ phần mềm cũng như chocác ứng dụng chuyên biệt Và một số tổ chức đã sử dụng chúng như chuẩn mực cho các

bộ đo chương trình của họ Một ví dụ là mô hình phần mềm chính xác của Viện côngnghệ phần mềm SEI (Software Engineering Institute) yêu cầu sự đo lường về kích cỡ

hệ thống, thời gian dự án, mức công sức, và những lỗ hổng của phần mềm Họ tích hợp

những đơn vị đo này với những yêu cầu tiến trình để hỗ trợ cho việc Quản lý dự án vàCải thiện liên tục Cùng với năng suất, chúng ta coi tập hợp độ đo của SEI như tập hợpgọn nhất cho tổ chức đó là : Kích cỡ hệ thống, thời gian dự án, nhân lực, lỗ hổng, năngsuất.

Mỗi kỹ nghệ khác nhau cần có nhưng tiêu chuẩn riêng về độ đo, độ tin cậy và an toàn

Ví dụ: Trong công nghệ truyền thông, có tiêu chuẩn TL9000 có định nghĩa dài về độ đo

mà các nhà cung cấp phần mềm phải có và cung cấp cho khách hàng Còn trong côngnghệ hạt nhân EIC60880:1986-09 định nghĩa các tiêu chuẩn và độ đo cho "Phần mềmcho máy tính trong hệ thống an toàn của trung tâm năng lượng hạt nhân"

Tóm lại trong phương thức này, ta cần quan tâm tới cả các tiêu chuẩn chung và các tiêuchuẩn đặc trưng cho từng kỹ nghệ để lựa chọn các độ đo cho phù hợp

4 Phương pháp 4: Mở rộng GQM: Độ đo kỹ xảo

(Extension to GQM: Metric Mechanism)

Một điều quan trọng cần bổ sung vào các hướng tiếp cận trên cần quan tâm Kỹ xảo đểthu thập các dữ liệu về độ đo cần hiểu thấu đáo và thống nhất trước khi đưa vào ứngdụng trong chương trình Trong sự chấp thuận với những tiền đề của Basili, ta thêm kỹxảo vào GQM để có đc GQM2 như sau:

dữ liệu

Thất bại trong việc hiểu và thống nhất trong "Kỹ xảo" có thể dẫn tới rất nhiều thất bạitrong những độ đo chương trình: Dữ liệu không hoàn thiện hoặc không chuẩn xác là dokhông có ai đảm bảo cho nó phải có kịp lúc và đúng kiểu Dữ liệu cũ, và không cònhữu dụng cho những quyết định hiện thời Dữ liệu không có sẵn sàng khi cần tới Ngânsách dự án bị thiếu hụt do chi phí cho cơ sở hạ tầng của độ đo chương trình Kế hoạch

dự án bị phá vớ do không có kế hoạch thời gian dự trù và xác thực

Kỹ xảo cho độ đo khiếm khuyết: Chủ sở hữu=Quản lý dịch vụ khách hàng, tần xuất

thu thập= lỗ hổng xuất hiện, tần xuất báo cáo= hàng tháng, cơ sở vật chất= hệ thốngcông cụ khách hàng hiện có và 0,25 nhân viên văn phòng

Kỹ xảo cho độ đo thỏa dụng khách hàng: Chủ sở hữu = quản lý sản phẩm, tần xuất thu

thập= sau khi chuyển giao từng phần chính của phần mềm, tần xuất báo cáo = quý, cơ sở hạtầng = khảo sát khách hàng đã có trong từng lần chuyển giao và 0.1 quản lý sản phẩm

5 Đối tượng đo lường là một chức năng của thời gian

Một đặc điểm của bất cứ độ đo chương trình nào là chúng đều có chức năng của thờigian trong ba hình thức:

 Đối tượng đo lường biến đổi dựa trên vị trí hiện thời trong sự phát triển phần mềm

và vòng đời sản phẩm phần mềm Ví dụ, các độ đo kiểm tra mã nguồn được thu thập vàkiểm soát trong suốt thời gian phát triển mã lệnh của vòng đời Trong pha kiểm thử,thời gian phát triển để chuyển giao những vá lỗi có thể đồng nhất với nhu cầu bộ đưaquyết định cần biết Độ tin cậy của sản phẩm phần mềm cần được đo trong các bướcsớm trước khi chuyển giao và ứng dụng sản phẩm, trong khi chi phí bảo trì nằm trongkhoảng lợi nhuận khi mà sản phẩm đã nằm ở cuối vòng đời

 Các doanh nghiệp thay đổi từng giờ tùng phút, và các độ đo chương trình cần có sựthay đổi thích ứng theo Ví dụ: Nếu những khảo sát khách hàng chỉ ra rằng họ khôngthỏa mãn với độ tin cậy của sản phẩm, một hệ thống độ đo sẵn sàng cần được tạo ra vàgiám sát Nếu các đối thủ cạnh tranh đang tấn công các sản phẩm của ta trên thị trườngbằng các sản phẩm có chức năng tương tự, chúng ta có thể cần tới đo lường tiến trìnhphát triển, cho phép ta tập trung phần lớn thời gian vào việc triển khai phát triển cảitiến

 Các độ đo, đặc biệt là khi đã được sử dụng như tác nhân trong nhận dạng và đền

bù, có thể sẽ dần mất đi hiệu lực qua thời gian Sự tập trung có thể trở thành gắn kếttrực tiếp đến độ đo và làm cách nào để "quản lý độ đo" Hơn là tối ưu mục tiêu mà dự

án mong đạt tới Khi đó cần lựa chọn một độ đo khác hỗ trợ cho mục tiêu hoặc thay đổicách thức của độ đo hiện có

6 Tổng kết:

Mỗi dự án phần mềm và mỗi tổ chức đều phải đối mặt với câu hỏi "đo lường cái gì?"

Để trả lời được câu hỏi này chúng ta cần hiểu về khách hàng của mình và mục tiêu của

họ, để sử dụng trong việc điều khiển những định nghĩa xấp xỉ trong đo lường chươngtrình Các tiêu chuẩn cung cấp cách thức và định hướng như mô hình tạo quyết địnhhay GQM Không quá chú trọng tới hướng tiếp cận nào được chọn, định nghĩa các độ

đo chương trình có thể là một phần của bước đầu tiến trình lập kế hoạch dự án Đạtđược sự thỏa thuận chung của các thành viên ngay khi bắt đầu giúp cho đảm bảo các độ

đo là cần thiết để đưa ra quyết định và ước lượng mục tiêu đạt được ở bất kỳ lúc nào,nơi nào chúng cần Mọi độ đo chương trình cần thường xuyên sử dụng và đảm bảo liênkết chặt chẽ với mọi sự thay đổi trong công việc và nhu cầu của dự án

II Các kỹ thuật ước lượng chi phí phần mềm

Những nghiên cứu đáng kể đưa ra các kỹ thuật ước lượng chi phí phần mềm bắt đầu từnhững năm 1965, với việc nghiên cứu dựa trên tập hợp các dữ liệu mẫu từ 169 dự ánphần mềm, với 104 thuộc tính của phần mềm được khảo sát Dựa trên những nghiêncứu này, một vài mô hình ước lượng, dù chưa được hòan chỉnh nhưng khá có giá trị đãđược công bố vào cuối những năm 1960 đầu những năm 1970

Cho tới cuối những năm 1970, đã có hàng loạt những mô hình mạnh hơn, có độ chính

xác cao hơn được giới thiệu như: SLIM (Putnam và Myers), Checkpoint (Jones),PRICE-S (Park), SEER (Jensen) và COCOMO (Boehm) Tuy nhiên tất cả các mô hìnhnày đều gặp vấn đề với các dự án có kích cỡ và tầm quan trọng lớn Với những phầnmềm quy mô lớn này, thì có độ phức tạp cao, làm cho việc ước lượng chính xác chi phí

vô cùng khó Đây cũng chính là động lực thúc đẩy các nhà nghiên cứu phát triển thêmcác mô hình cho phù hợp hơn với thực tế

Với bản chất thay đổi nhanh chóng của phần mềm làm cho việc xây dựng các mô hìnhtham số (vốn mang lại độ chính xác cao cho nhiều lĩnh vực trong phát triển phần mềm)trở nên rất khó khăn Với mục tiêu xây dựng các mô hình hữu dụng, dựa theo vòng đờiphát triển phần mềm để dự đoán chính xác chi phí phần mềm, trong khoảng hơn haithập kỷ gần đây, nhiều mô hình ước lượng chi phí phần mềm đã xuất hiện Các kỹthuật thường được sử dụng nhất trong các mô hình này là các phương pháp tiếp cận đahồi quy cổ điển Ta có thể xếp các kỹ thuật thông dụng nhất hiện nay theo sáu hướngtiếp cận sau:

Hình 1: các kỹ thuật ước lượng phần mềm

Sau đây ta sẽ nghiên cứu thêm về từng loại kỹ thuật đó

1 Các kỹ thuật dựa trên mô hình:

Theo nghiên cứu trong thời gian qua không có nhiều các mô hình ước lượng phần mềmđược xây dựng, và hầu hết đều là các mô hình thuộc sở hữu độc quyền do đó khó cóthể so sánh hay đối chiếu về mặt cấu trúc của các mô hình Tính năng của các mô hìnhđược xác định thuần túy trên lý thuyết hay qua các thử nghiệm Sau đây ta sẽ nghiêncứu về một số mô hình phổ biến

1.1 Mô hình SLIM của Putnam

Đây là mô hình được Larry Putnam thuộc công ty Quantitative Software Development,phát triển từ cuối những năm 1970 SLIM là kết quả phân tích của Putnam về vòng đờiphát triển phần mềm, sử dụng đường cong phân bố Rayleigh để ước lượng cống sức,thời gian và tỷ lệ khiếm khuyến của dự án Ông sử dụng một chỉ số xây dựng nhân lực(MBI _ Manpower Buildup Index) và một hệ số năng suất (PF _ Productivity Factor)

để hiệu chỉnh phân bố SLIM sử dụng các dữ liệu từ các dự án đã hoàn thành để ướclượng cho dự án mới Nếu không có các dữ liệu tiền định, thì ta có thể xác định các giátrị MBI và PF qua việc trả lời một tập các câu hỏi SLIM sử dụng khái niệm năng suất

P là tỷ lệ giữa kích cỡ phần mềm S và công sức phát triển E

P = S/E

SLIM có thể thực hiện được với các độ đo kích cỡ phổ biến như số dòng mã lệnh

SLOC, số điểm chức năng Function Points hay kỹ thuật ballpark.

Đường cong Rayleigh được sử dụng để xác định phân bố công sức qua biểu thức viphân:

Dy/dt=2Kate-at2

Đây là một ví dụ về phân bố Rayleigh cho mức sử dụng nhân lực trong thời gian pháttriển td với K=1, a=0.02, td=0.18 Với mỗi giá trị K, a và td khác nhau ta có được đồ thịphân bố khác nhau Tuy nhiên phân bố Rayleigh không phải luôn luôn đúng trong thực

tế, ví dụ khi phát triển gia tăng thì phân bố Rayleigh trở thành nằm ngang, hay khi tăngthời gian thực hiện dự án ta chỉ có thể tiết kiệm nhân lực được một lươngj nhỏ hơn t4.Putnam đã đề xuất một số hiệu chỉnh cho các trường hợp đặc biệt đó

Công ty Quantitative Software Development đã xây dựng một bộ gồm ba công cụ dựatrên mô hình SLIM là SLIM Estimate hỗ trợ lập kế hoạch dự án, SLIM Control để theodõi giám sát dự án và SLIM Metrics để lưu trữ và đánh giá các độ đo phần mềm Ta cóthể tham khảo thêm thông tin về mô hình SLIM và các công cụ này tạihttp://www.qsm.com

1.2 Mô hình Checkpoint - điểm kiểm tra

Đây là công cụ ước lượng dự án phần mềm được Software Productivity Research(SPR) phát triển trên những nghiên cứu của Capers Jones Checkpoint sử dụng cácđiểm chức năng FPs là đầu vào chính về kích cỡ để tiến hành ước lượng với nguồn cơ

sở dữ liệu là hơn 8000 nghìn dự án đã hoàn thiện Dưới đây là mô hình của Checpointvới các khái niệm QA_ Quality Assurance đảm bảo chất lượng, JAD _ JointApplications Development là tham gia phát triển ứng dụng, SDM _ SoftwareDevelopment Metrics là các độ đo phát triển phần mềm

Mô hình này hỗ trợ việc phát triển và củng cố mô hình vòng đời phát triển phần mềmtheo 3 chức năng chính:

 Ước lượng: Dự đoán công sức cần cho dự án théo cả bốn cơ sở: Dự án, các phaphát triển, các hoạt động và các nhiệm vụ Ước lượng gồm 5 thành phần: Tài nguyên,những phần được chuyển giao, các khiếm khuyết, chi phí và thời gian

 Đo lường: Cho phép người dùng chọn các độ đo để đo lường cho dự án, từ đó phântích hiệu năng, xác định kỹ thuật ứng dụng tốt nhất và xây dựng nền tảng tri thức ướclượng nội bộ (là các mẫu _ templates)

 Đánh giá: Dựa trên các tiêu chuẩn công nghiệp để hỗ trợ việc so sánh đánh giá cáctính năng của dự án với nhu cầu thực tế Đánh giá ưư nhược điểm của môi trường pháptriển phần mềm và mô hình hóa các khuyến nghị trong cải thiện quy trình đánh giá

Ngoài ra SPR còn đưa ra thị trường một số công cụ khác như: Knowledge Plan giúpđưa ra một ước lượng ban đầu về dự án phần mềm với công sức giới hạn, và hướng dẫnmột quy trình tinh chỉnh qua các thử nghiệm và đánh giá; FP Workbench là công cụ đểphân tích các điểm chức năng có lưu trữ cập nhật và phân tích từng phép đếm

 Ngoài SPR còn một số tổ chức khác cũng xây dựng mô hình ước lượng dựa trên sốđếm các điểm chức năng Tiêu biểu như COSMIC -Common Software MesurementInternational Consortium Là một dự án với kỳ vọng thừa kế tất cả các ưu điểm của các

mô hình ước lượng qua điểm chức năng khác như IFPUG MkII, NESMA Do cácđiểm chức năng không phù hợp với các hệ thống nhúng và hệ thống thời gian thực, nênCOSMIC FFP v2.2 đã bổ sung để đo kích cỡ theo đơn vị chức năng là các yêu cầu vềchứuc năng của người dùng (FUR-Functional User Requirement) Hiện nay COSMICFFP đã được tiêu chuẩn quốc tế hóa

1.3 PRICE-S

Là mô hình được phát triển đầu tiên ở RCA và được sử dụng nội bộ để ước lượng chocác dự án phần mềm thuộc bộ quốc phòng mỹ, NASA và các dự án chính phủ Mỹkhác Các biểu thức không được công bố mà chỉ một số giải thuật chính được công bốvào năm 1988 Sau này đã được phổ biến rộng rãi và thương mại hóa bởi công tyPRICE System Bao gồm 3 mô hình con:

i Mô hình thu thập: Dự đoán chi phí và thời gian thực hiện của phần mềm, xây dựngứng dụng trên tất cả mọi lĩnh vực: Hệ thống kinh doanh, hệ thống giao tiếp, hệ thốngchỉ huy và điều khiển, hệ thống điện tử hàng không vũ trụ PRICE-S tập trung vào cácvấn đề: Tái kỹ nghệ, sinh mã nguồn, phát triển xoắn ốc, phát triển nhanh, tạo mẫu thửnhanh, phát triển hướng đối tượng và đo lường năng suất phần mềm

ii Mô hình định cỡ: Hỗ trợ việc ước lượng kích cỡ của phần mềm qua các độ đo nhưSLOC, FP hay POP (các điểm đối tượng dự đoán Predictive Object Points) - là độ đohướng đối tượng mới của Chidamber

iii Mô hình chi phí vòng đời: Ước lượng nhanh chi phí các pha bảo trì và hỗ trợ ở giaiđoạn sớm Thường được sử dụng kết hợp với mô hình thu thập

Tham khảo thêm về PRICE-S tại http://www.pricesystems.com

1.4 SEER-SEM

Là một sản phẩm của công ty Galorath dựa trên mô hình của Jensen Đây là bộ công cụphức hợp hỗ trợ cho các phương pháp ước lượng cả "top-down" và "bottom-up" Cácbiểu thức mô hình không công bố, nhưng chúng sử dụng các tham số để ước lượng.Phạm vi của mô hình rộng, bao trùm tất cả các pha trong vòng đời phát triển dự ánphần mềm: Từ đặc tả yêu cầu, thiết kế, phát triển, triển khai và bảo trì Có thể hoạtđộng trên các nền tảng khác nhau: khách - chủ, đơn lẻ, phân tán, đồ họa v.v Áp dụngrộng rãi cho các chế độ phát triển: hướng đối tượng, tái sử dụng, COTS, xoắn ốc, thácnước, mẫu thử và gia tăng Hỗ trợ cho các ngôn ngữ lập trình thế hệ thứ 3, thứ 4 nhưC++, FORTRAN, COBOL, ADA Cũng như các trình tạo ứng dụng khác Các yếu tốđầu vào: năng lực nhân viên, các chuẩn về quy trình, yêu cầu về thiết kế, độ rủi ro chấpnhận được Hình sau mô tả mô hình các nhóm dữ liệu đầu ra đầu vào của hệ thống

Các tính năng chính của mô hình SEER - SEM:

 Cho phép nhập độ xác suất ước lượng, ràng buộc về nhân lực và thời gian độc lập

 Cung cấp các tiện ích giúp phân tích các biến động tổng thể và hiệu chỉnh các tham

số đầu vào

 Tổ chức các thành phần dự án vào cấu trúc phân chia công việc, giúp lập kế hoạch

và kiểm soát thuận tiện hơn

 Hiển thị các hệ số chi phí của dự án

 Cho phép lập kế hoạch có tính tương tác giữa các thành phần dự án trên biểu đồGantt

 Xây dựng ước lượng dựa trên cơ sở tri thức các dự án đã thực hiện, và các tri thứcnày có thể hiệu chỉnh được

Các đặc tả của mô hình bao gồm:

 Các tham số: Bao gồm các nhóm kích cỡ dự án, nhân lực, độ phức tạp, môi trường

và các ràng buộc Trong mỗi nhóm lại có nhiều tham số riêng

 Các dự đoán: Ước lượng công sức, thời gian thực hiện, nhân lực, các khiếm khuyết

và chi phí Các ước lượng này có thể bị chi phối bởi thời gian thực hiện hay nhân lực,

có thể chỉ định các ràng buộc về thời gian thực hiện và nhân lực

 Phân tích rủi ro: Có thể phân tích biến động trên tất cả các giá trị của các tham sốđầu ra (giá trị nhỏ nhất, xác suất gặp cao nhất, giá trị lớn nhất ), định các xác suất chotừng thành phần trong WBS và có thể điểu chỉnh được các giá trị này, cho phép sắpxếp các ước lượng theo độ quan trọng của các thành phần trong WBS

 Các phương pháp định cỡ: Theo điểm chức năng theo cả chuẩn của IFPUG vànhững cách thức khác , số dòng mã lệnh, cả thêm mới và sử dụng sẵn có

 Các đầu ra và giao diện: Nhiều độ đo năng lực với hàng trăm báo cáo và biểu đồ,các phân tích thỏa hiệp cùng với việc so sánh các khả năng thay thế, tích hợp giao diệncác cửa sổ ứng dụng và các giao diện người dùng tùy biến

Tham khảo thêm chi tiết về SEER-SEM tại http://www.gaseer.com

1.5 COCOMO II

Mô hình ước lượng chi phí và thời gian phát triển COCOMO lần đầu được đề cập đếntrong cuốn sách "Kinh tế học công nghệ phần mềm" (Software engineering economics)của Barry Boehm xuất bản năm 1981 và nhanh chóng trở thành một mô hình ước lượngchi phí phổ biến trong những năm 1980 Tuy nhiên cùng với sự phát triển của các công

cụ lập trình thì mô hình COCOMO 81 này và bản bổ sung ADA COCOMO cũngkhông đáp ứng được yêu cầu ước lượng với độ chính xác cao nữa

Thế nên năm 1995 mô hình COCOMO II được giới thiệu với 3 mô hình con

"Applications Composition", "Early Design" Và "Post Architecture" Có thể kết hợplinh hoạt với nhau theo nhiều cách để giải quyết các yêu cầu thực tế

Trong đó mô hình " Application Composition" được sử dụng để ước lượng công sức vàthời gian cho các dự án có sử dụng các công cụ ICASE để phát triển nhanh ứng dụng.Các dự án này khá đa dạng nhưng thường ở mức khá đơn giản Các thành phần thôngthường là các GUI, các trình quản lý đối tượng hay CSDL, phầm mềm trung gian để xử

lý phân tán hay xử lý giao dịch Mô hình này dựa trên các điểm đối tượng, với cácđối tượng ở đây là các màn hình, các báo cáo và các module phát triển bởi các ngônngữ lập trình thế hệ thứ 3 Mỗi đối tượng được đếm với một trọng số ảnh hưởng bởi độphức tạp (gồm ba mức: đơn giản, trung bình, và phức tạp) Phép ước lượng này phùhợp với mức độ thông tin có được trong giai đoạn lập kế hoạch dự án

Mô hình "Early Design" khám phá các khái niệm vận hành và khả năng thay thế vềkiến trúc của hệ thống Thường mô hình này áp dụng vào giai đoạn sớm, khi chưa có

đủ các thông tin để có thể đưa ra một ước lượng chi tiết Mô hình này ước lượng dựatrên số điểm chức năng, hay số dòng mã lệnh SLOC nếu có Được hiệu chỉnh bởi bộ 5

hệ số tỷ lệ và 7 hệ số nhân công sức

Mô hình "Post Architecture" ước lượng cho toàn bộ vòng đời phát triển của dự án, mởrộng chi tiết hơn cho mô hình "Early Design" Thường được áp dụng sau khi đã hoànthiện thiết kế ở mức cao nhất, với đấy đủ các thông tin chi tiết về dự án, kiến trúc phầnmềm Đây là mô hình gần gũi nhất về mặt kiến trúc và biểu thức với COCOMO81 vàADA COCOMO Sử dụng các tham số định kích cỡ như LOC hay FP được điều chỉnhcho phù hợp với trường hợp tái sử dụng và ngắt đoạn Sử dụng 17 hệ số nhân công sức

và 5 hệ số tỷ lệ để hiệu chỉnh ước lượng

Mô hình "Post Architecture" có các hệ số điều chỉnh được rút ra từ 161 dự án Việchiệu chỉnh các hệ số của mô hình "Early Design" là sự tổng hợp các hệ số của mô hình

"Post Architecture" Riêng mô hình "Application Composition" thì thiếu các thông tinchi tiết nên không có sự hiệu chỉnh nào

Điểm nổi bật và cuốn hút nhất ở các mô hình COCOMO là các biểu thức và giá trị cáctham số hoàn toàn công khai Có lẽ đây là lý do mà nhiều công cụ ước lượng đã được

phát triển dựa trên mô hình này Và đây cũng chính là lý do em đã chọn mô hìnhCOCOMO II để nghiên cứu và xây dựng công cụ hỗ trợ tự động ước lượng chi phí.

1.6 Tổng kết về các kỹ thuật ước lượng dựa trên mô hình

Bảng sau tổng kết các tham số và họat động được sử dụng trong các mô hình đã được

đề cập Nhìn chung các kỹ thuật dựa trên mô hình phù hợp cho việc lập ngân sách,phân tích sự cân bằng giữa các yếu tố, lập kế hoạch và kiểm soát cũng như phân tíchviệc đầu tư trong trường hợp đã có thông tin từ các dự án đã kết thúc Trong trườnghợp không có tiền lệ thì khó có thể áp dụng các mô hình trên

Bảng 1: Tổng kết các kỹ thuật dựa trên mô hình

Trong đó “?”: không nắm rõ hoặc không có nhân tố tương ứng trong mô hình đang xét.

2 Các kỹ thuật dựa vào chuyên gia

Các kỹ thuật dựa vào chuyên gia hữu dụng trong trường hợp không có các dữ liệu địnhlượng, có được do quan sát Dựa vào tri thức và kinh nghiệm của những người đã thànhthạo trong một lĩnh vực với các dự án đã tham gia hoặc có hiểu biết để đưa ra nhữngước lượng Một yếu điểm của các kỹ thuật này là dựa quá nhiều vào ý kiến chủ quancủa chuyên gia, và thường là không có một phương thức nào để kiểm tra lại ý kiến đó,cho tới khi phát hiện ra ước lượng đó sai lầm thì cũng quá muộn để có thể sửa chữa.Kinh nghiệm không đồng nghĩa với năng lực, và kể cả những người có năng lực caonhất thì ý kiến chủ quan của họ đôi khi cũng không chính xác trong từng hoàn cảnh cụthể Hai kỹ thuật được phát triển để thu thập ý kiến các chuyên gia nhằm tổng hợp kinhnghiệm của họ và giảm thiểu các yếu tố chủ quan trong ước lượng của họ thường được

áp dụng là kỹ thuật Delphi và Cấu trúc phân chia công việc

2.1 Kỹ thuật Delphi

Đây là kỹ thuật được The Ran Corporation phát triển vào cuối những năm 1940, vớimục đích ban đầu là để dự đoán các sự kiện trong tương lai Sau này được áp dụng đểtổng hợp ý kiến của một tập thể các chuyên gia về một lĩnh vực sở trường nào đó.Những người tham gia được yêu cầu đưa ra ý kiến về một vấn đề nào đó Trong vòng

sơ bộ, đây là ý kiến độc lập của từng người, không có sự tham khảo trao đổi giữa cácchuyên gia Sau khi thu thập các ý kiến, tập hợp thành bảng đưa lại cho những ngườitham gia Dựa trên quan điểm cá nhân và bảng tổng hợp đó, các chuyên gia sẽ đưa ra ýkiến lần 2 Kết quả ở lần này thường có độ dao động nhỏ hơp và có thể dẫn tới một cơ

sở dung hòa hợp lý Kỹ thuật Delphi cổ điển không có sự thảo luận trong từng vòng,còn ở kỹ thuật Delphi mở rộng cho phép thảo luận trong nhóm theo từng vòng

Đây là một kỹ thuật hữu ích để rút ra kết luận về một vấn đề khi không có thông tin cơ

sở nào, ngoài thông tin dựa trên kinh nghiệm của các chuyên gia

2.2 Cấu trúc phân chia công việc (WBS)

Đây là một chuẩn trong thực tiễn phát triển cả phần cứng và phần mềm.WBS là mộtcách tổ chức phân cấp các thành phần của dự án, giúp đơn giản hóa việc ước lượng vàkiểm soát ngân sách Nó giúp xác định chính xác yếu tố nào đang được ước lượng Hơnnữa, nếu các chi phí trong từng phần của cây phân cấp được gán xác suất, có thể xácđịnh một giá trị mong đợi của chi phí phát triển toàn bộ dự án theo cách tổng hợp từdưới lên “bottom - up” Các chuyên gia sử dụng phương pháp này để xác định đặc tảcủa các thành phần sao cho có lợi nhất, với cấu trúc và các xác suất được gán cho mỗithành phần

Thực chất cấu trúc phân chia công việc của một dự án phần mềm bao gồm, hai hệthống phân cấp: một hệ thống để biểu diễn sản phẩm : mô tả các cấu trúc cơ bản củaphần mềm và một hệ thống để biểu diễn các hoạt động cần thiết để xây dựng sản phẩmđó: đây là các hoạt động được gắn với từng thành phần của phần mềm

Với cấu trúc như vậy, WBS rất hữu ích cho việc lập kế hoạch và kiểm soát Do đó, bêncạnh việc trợ giúp ước lượng chi phí phần mềm, WBS còn được sử dụng chủ yếu chotính toán và lập báo cáo chi tiết Mỗi phần tử của WBS có thể được gán cho một giá trịkiểm soát ngân sách và chi phí, cho phép nhân viên lập báo cáo về lượng thời gian họ

đã sử dụng cho từng nhiệm vụ hoặc từng thành phần của dự án Thông tin này sẽ đượctổng kết, phục vụ các mục đích kiểm soát ngân sách dùng cho quản lý

Cuối cùng, nếu một tổ chức sử dụng một cấu trúc phân chia công việc chuẩn WBS mộtcách nhất quán cho tất cả các dự án của mình, thì cùng với thời gian, nó sẽ tích lũyđược một cơ sở dữ liệu rất có giá trị trọng việc đưa ra phân bổ chi phí phần mềm củamình Dữ liệu này có thể được sử dụng để phát triển một mô hình ước lượng chi phíphần mềm được phát triển theo kinh nghiêm của tổ chức

3 Các kỹ thuật hướng học

3.1 Các nghiên cứu dựa trên đối tượng và hoàn cảnh (Case studies)

Dựa vào kiến thức từ các ví dụ cụ thể người ta tổng quát hóa bằng cách ngoại suynhững dữ liệu ước lượng cho một bài toán quy nạp chung Những người ước lượng tìmhiểu chi tiết tất cả các mô tả về điều kiện môi trường và các ràng buộc, các quyết định

về kỹ thuật và quản lý đã được đưa ra trong quá trình phát triển các phần mềm trước

đó, và thành tựu cuối cùng Họ cố gắng tổng hợp từ các trường hợp này với mối liên hệgiữa nguyên nhân (các điều kiện môi trường và phát triển) và kết quả đạt được để cóthể áp dụng vào các hoàn cảnh phát triển khác Trong trường hợp lý tưởng, họ tìm đượccác đặc tả tương tự với dự án cần ước lượng và có thể áp dụng nguyên tắc tương đương

để đưa ra các ước lượng hợp lý về chi phí và thời gian Các trường hợp kinh nghiệm(Case study) này có thể là của bản thân tổ chức đó hoặc cập nhật thêm kinh nghiệm từbên ngoài Các trường hợp trong chính tổ chức đó có ý nghĩa cao hơn bởi nó phù hợpvới điều kiện môi trường phát triển

Shepperd và Shòield đã thực hiện một nghiên cứu so sánh việc sử dụng tính tưong tựvới các mô hình dự đoán dựa trên phân tích hồi quy từng bước cho tập 9 dữ liệu (tổngcộng gồm 275 dự án), nhằm mang lại độ chính xác cao hơn cho ước lượng Họ đã xâydựng một quy trình gồm 5 bước để ước lượng :

 Xác định dữ liệu hoặc các tính năng cần thu thập;

 Thông qua các cơ chế định nghĩa và thu thập dữ liệu

 Vận dụng căn cứ vào hoàn cảnh đã có trước đó

 Điều chỉnh phương pháp ước lương

 Ước lượng công sức cho dự án mới

Để tìm hiểu thêm chi tiết, có thể tham khảo trong tài liệu “Estimating Software ProjectEffort Using Analogies” xuất bản năm 1993

3.2 Mạng nơ ron

Đây là những mô hình ước lượng có thể được đào tào qua các dữ liệu lịch sử để tạo racác kết quả chính xác hơn, thông qua việc tự động điều chỉnh các giá trị tham số củagiải thuật để hạn chế sự khác biệt giữa thực tiễn và các dự đoán của mô hình Gray vàMcDonell và các đồng sự đã mô tả dạng chung nhất của một mạng nơron được sử dụngtrong ước lượng là một mạng “phản hổi trước, được đào tạo và truyền ngược” “Truyềnngược ” là một phương pháp đào tạo mạng nơron thông thường, trong đó dữ liệu đầu racủa hệ thống được so sánh với giá trị mong đợi, và hệ thống sẽ hiệu chỉnh cho tới khi

sự sai khác giữa hai giá trị này được tối thiểu hóa “Phản hồi trước” là khái niệm mô tảmột loại hệ thống có thể tác động trở lại để thay đổi trong môi trường của nó, thường là

để duy trì một vài trạng thái mong đợi của hệ thống một hệ thống biểu thị hành vi

“Phản hồi trước” sẽ đáp ứng lại một tác động trước khi bị ảnh hưởng bởi tác động đó.Việc xây dựng một mạng như vậy bắt đầu bằng cách xây dựng một cách sắp xếp hợp lýcác nơron hoặc các kết nối giữa các nút mang Việc này bao gồm định nghĩa số lớpnơron, số nơron trong mỗi lớp, và cách mà chúng liên kết với nhau Cũng cần xác địnhcác hàm ước lượng được đánh trọng số giữa các nút và từng giải thuật đào tạo được sửdụng Khi đã xây dựng được mạng, mô hình cần được đào tạo bằng cách cung cấp cho

nó một tập các dữ liệu dự án đã hoàn thành làm đầu vào, các giá trị thức tế về chi phí

và thời gian Khi đó, mô hình sẽ thực hiện lặp giải thuật đào tạo của nó và tự động điềuchỉnh các tham số của các hàm ước lượng của nó tới khi độ chênh lệch giữa ước lượngcủa mô hình với giá trị thực tế nằm trong giới hạn delta cho trước việc xác định giá trịdelta rất quan trọng, nó quyết định độ chính xác cần thiết cho mô hình, và tránh việc

mô hình phải thực hiện việc đào tạo thái quá Việc đào tạo này giúp nâng cao tínhchính xác trong các ước lượng được đưa vào đào tạo, nhưng làm giảm khả năng ápdụng cho các dữ liệu rộng hơn, tổng quát hơn

Wittig đã đưa ra báo cáo về độ sai lệch nằm trong khoảng 10% đôi với một mô hìnhloại này khi được sử dụng để ước lượng công sức phát triển phần mềm Mặt khác ôngcũng cảnh báo về việc phải thận trọng khi sử dụng các mô hình này, vì chúng luôn gặpphải cùng một loại vấn đề thống kê với dữ liệu đào tạo được các kỹ thuật hồi quy chuẩn

sử dụng trong việc điều chỉnh các mô hình cũ hơn Thông thường, để đào tạo một cáchchính xác các mạng nơron với các cấu trúc trung gian, ở một độ phức tạp bất kỳ, cầnphải có các tập dữ liệu rất lớn cũng vậy, trong phân tích biến đông, các mạng nơronhầu như không hỗ trợ về trực giác cho việc nắm bắt những mối quan hệ biến động giữacác tham số điều khiển giá và các kết quả của mô hình Chúng gặp phải những khókhăn tương tự khi lập kế hoạch và kiểm soát

4 Các kỹ thuật dựa vào động học

4.1 Các kỹ thuật dựa vào động học

Các kỹ thuật dựa vào động học cho rằng công sức thực hiện hoặc các hệ số chi phí của

dự án phần mềm luôn thay đổi trong suốt thời gian phát triển dự án, tức là chúng cótính chất động theo thời gian Đây là một điểm mới khác biệt so với các kỹ thuật khác

đã đề cập tới Các kỹ thuật này dựa trên các mô hình tĩnh và đưa ra các dự đoán dựatrên những quan sát riêng biệt về một trạng thái phát triển tại một thời điểm nhất định.Tuy nhiên, các nhân tố như thời hạn cuối, nhân lực, các yêu cầu thiết kế, nhu cầu đàotạo, ngân sách… tất cả đều biến động theo tiến trình phát triển và gây ra những biếnđộng tương ứng trong năng suất của nhân lực dự án Điều này dẫn tới những ảnh hưởngtiêu cực tới khả năng dự án được thực hiện đúng hạn và không vượt quá ngân sách Các

kỹ thuật động nổi bật đều dựa trên phép tiếp cận động học hệ thống để mô hình hóa, doJay W.Forrester phát minh từ hơn 40 năm trước

4.2 Phép tiếp cận động học hệ thống

Đây là một phương pháp mô hình hóa mô phỏng liên tục, trong đó, các kết quả và hành

vi của mô hình được hiển thị trên đồ thị, với thông tin thay đổi theo thời gian Các môhinh được biểu diễn như các mạng, được chỉnh sửa với các vòng lặp phản hồi tích cực

và tiêu cực Các phần tử trong mô hình được biểu diễn như các tổng tích lũy hoặc cáccấp độ, có thể thay đổi linh động (các nút), các tốc độ hoặc các dòng lưu chuyển giữa

các cấp độ (các đường kết nối các nút), và các thông tin (liên quan tới hệ thống) thayđổi theo thời gian, ảnh hưởng một cách linh động tới tốc độ lưu chuyển giữa các cấp độ(các vòng lặp phản hồi).

Dưới đây là hình biểu diễn một mô hình động học hệ thống, diễn tả định luật nổi tiếngcủa Brooks: “thêm nhân lực vào một dự án bị chậm tiến độ sẽ làm nó càng chậm hơn.”

Cơ sở lập luận của Brooks là việc thêm người mới vào dự án không những cần phân bổlại công sức để đào tạo cho họ mà việc phối hợp và cộng tác cũng sẽ tăng theo cấp sốmũ

Mô hình động của Mandachy biểu diễn khái niệm của Brooks dựa trên các giả định:

i Những người mới cần được những người có kinh nghiệm đào tạo để cải thiệnnăng suất

ii Tăng nhân lực cho một dự án sẽ làm tăng sự phối hợp và giao tiếp lên rất nhiều.iii Những người đã từng làm việc trong dự án có năng suất làm việc cao hơnnhững người mới

Như trong hình trên, mô hình cho thấy có hai chuỗi lưu chuyển, biểu diễn nhân lực vàphát triển phần mềm Chuỗi phần mềm (ở phần trên của hình vẽ) bắt đầu với một cấp

độ của yêu cầu người dùng Nó cần được chuyển đổi thành một tổng tích lũy của phầnmềm đã phát triển Tốc độ chuyển đổi này phụ thuộc vào số lượng nhân viên đã đượcđào tạo làm việc trong dự án, mặt khác số nhân viên này là một hàm số của chuỗichuyển nhân lực (ở phía dưới của hình vẽ) những người mới được đưa vào dự án theotốc độ phân bố nhân lực và sau đó được chuyển đổi thành nhân lực có kinh nghiệmtheo tốc độ đồng hóa Các thành phần khác trong hình vẽ (hiệu suất trung bình, giaotiếp gia tăng, nhân lực có kinh nghiệm cần cho đào tạo, và đào tạo gia tăng) là các ví dụ

về các biến bổ sung, cũng có ảnh hưởng tới tốc độ phát triển phần mềm

Về mặt toán học, các mô hình mô phỏng động học hệ thống được biểu diễn bời một tậpcác biểu thức vi phân cấp một

x’(t)=f(x,t)trong đó:

x: một véctơ biểu diễn các cấp độ/ trạng thái trong mô hình

án Ông cũng áp dụng các kỹ thuật này trong tái sử dụng phần mềm và đạt được các kếtquả khá thú vị Ông phát hiện ra rằng, ban đầu, có một mối quan hệ có lợi giữa việc tái

sử dụng các thành phần phần mềm và năng suất của nhân lực dự án, do việc tạo ra cácmodule mới mất ít công sức hơn Tuy nhiên, theo thời gian, lợi ích này mất dần nếunhư các thành phần tái sử dụng cũ hơn không còn được sử dụng nữa, và không cóthành phần mới nào được viết để thay thế Do đó, bắt buộc phải tạm dừng chiến lượctái sử dụng cho tới khi tạo ra đủ các thành phần tái sử dụng mới, hay đến khi chiếmđược chúng từ một nguồn bên ngoài

Gần đây hơn, Madachy đã dùng động học hệ thống để mô hình hóa một quy trình vòngđời phần mềm dựa trên việc thanh tra Ông có thể chỉ ra rằng thực hiện thanh tra phầnmềm trong suốt giai đoạn phát triển làm tăng đôi chút công sức lập trình, nhưng làmgiảm công sức và thời gian khi kiểm thử và tích hợp Từ sự đánh giá đó, việc xác địnhxem có tiết kiệm công sức tổng thể hay không được thực hiện bởi một hàm tốc độ pháthiện lỗi trong giai đoạn phát triển, mức độ công sức cần để sửa các lỗi phát hiện khikiểm thử và hiệu quả của quá trình thanh tra Với các giá trị được dùng trong côngnghiệp của các tham số này, lượng tiết kiệm được do thanh tra lớn hơn chi phí thựchiện Các kỹ thuật dựa trên động học đặc biệt hữu ích cho việc lập kế hoạch và kiểmsoát, nhưng cũng đặc biệt rất khó điều chỉnh

5 Các kỹ thuật dựa vào hồi quy

Các kỹ thuật dựa vào hồi quy là những phương pháp phổ biến nhất để xây dựng các môhình Chúng được sử dụng kết hợp với các kỹ thuật dựa vào mô hình Chúng bao gồmhồi quy chuẩn và hổi quy mạnh,

5.1 Hồi quy chuẩn - phương pháp bình phương cực tiểu thông thường (OLS)

Hồi quy chuẩn đề cập tới phương pháp thống kê cổ điển của phép mô hình hóa hồi quytuyến tính, sử dụng bình phương cực tiểu Nó dựa trên phương pháp bình phương cựctiểu thông thường (OLS), một kỹ thuật tối ưu bằng toán học nhằm tìm ra một đườngphù hợp nhất với một tập dữ liệu bằng cách cố gắng tối thiểu hóa tổng các bình phương

khoảng cách giữa dữ liệu và hàm được phù hợp Nó phổ biến bởi tính đơn giản và dễ

sử dụng Nó được cung cấp như một tùy chọn trong một vài gói công cụ thống kê trênthị trường như: Minitab, Spluss, SPSS…

Có thể biểu diễn một mô hình sử dụng OLS như sau:

Phương pháp OLS thích hợp khi:

1) Sẵn có nhiều dữ liệu Điều này chỉ ra rằng có nhiều cấp độ để tự do lựa chọn và

số lượng quan sát lớn hơn rất nhiều số biến cần dự đoán Một trong những tháchthức lớn nhất trong lĩnh vực này là việc thu thập dữ liệu, do thiếu nguồn tàichính từ cấp quản lý cao hơn, do tồn tại đồng thời một vài quy trình phát triển,

do thiếu sự giải thích đúng đắn về mô hình…

2) Không phần dữ liệu nào bị mất Khi thời gian và ngân sách cho hoạt động thuthập dữ liệu bị hạn chế, hoặc do thiếu hiểu biết về dữ liệu được báo cáo sẽ dẫntới việc tạo ra dữ liệu thông tin bị thiếu hụt Dữ liệu này cần được lập báo cáo.3) Không có dữ liệu ngoại lệ Các trường hợp vượt khỏi giới hạn (do hiểu sai, thuthập dữ liệu thiếu chính xác hay do các quy trình phát triển khác)thường xuyênđược báo cáo trong dữ liệu kỹ nghệ phần mềm

4) Các biến ngoại sinh không tương quan với nhau Hầu hết các mô hình ướclượng phần mềm hiện tại có các tham số tương quan với nhau Điều này là viphạm giả định của phương pháp OLS

5) Khi được sử dụng trong mô hình, các biến ngoại sinh phải dễ hiểu, dễ giải thích.Điều này rất khó đạt được vì không dễ đưa ra các giả định hợp lệ về dạng củacác quan hệ hàm số giữa các biến ngoại sinh và phân bố của chúng

6) Tất cả các biến ngoại sinh đều cùng liên tục hoặc đều cùng rời rạc Ứng với mỗiloại biến này lại có những kỹ thuật thống kê khác nhau tập trung giải quyết.Nhưng không bao giờ trong cùng một mô hình lại tồn tại cả hai loại biến

Mỗi tiêu chí trên là một thách thức trong việc mô hình hóa các tập dữ liệu kỹ nghệphần mềm nhằm phát triển một mô hình ước lượng chi phí mạnh, dễ hiểu và có tínhxây dựng

5.2 Hồi quy mạnh

Đây là một cải tiến từ kỹ thuật OLS chuẩn Nó phần nào giải quyết vấn đề về các ngoại

lệ trong dữ liệu kỹ nghệ phần mềm quan sát được - mà đây là một điều rất hay gặptrong thu thập các dữ liệu bởi sự bất đồng về định nghĩa của các độ đo cũng như sự tồntại đồng thời một vài quy trình phát triển phần mềm và sự có mặt của các dữ liệu địnhtính

Có một số kỹ thuật thống kê thuộc loại hồi quy manh Một trong các kỹ thuật đó là dựa

trên phương pháp bình phương trung bình cực tiểu và rất giống với phương pháp OLS

ở trên Sự khác biệt duy nhất là kỹ thuật này làm giảm trung bình của tất cả các số hạnglỗi bình phương cực tiểu ri2

Một phương pháp khác có thể xếp vào hồi quy mạnh là kỹ thuật sử dụng các điểm dữliệu nằm trên hai hay ba độ lệch chuẩn của biến đáp ứng trung bình Phương pháp này

tự động loại bỏ các dữ liệu ngoại lệ và chỉ có thể sử dụng khi có đủ một số lượng cácquan sát, vì thế không có tác động lớn đến các mức độ tự do của mô hình Mặc dù kỹthuật này có thiếu sót là loại bỏ các dữ liệu ngoại lệ mà không suy luận trực tiếp, nóvẫn rất hữu ích khi xây dựng các mô hình ước lượng phần mềm chỉ với rất ít các biếnngoại sinh do thiếu dữ liệu hoàn chỉnh

Hầu hết các mô hình ước lượng dùng tham số hiện tại (COCOMO II, SLIM,Checkpoint…) đều có sử dụng một trong các dạng của các kỹ thuật dựa trên hồi quy

do tính đơn giản và được chấp nhận rộng rãi của chúng

6 Các kỹ thuật tổng hợp

Như đã đề cập ở trên, có rất nhiều ý kiến tranh luận về vấn đề sử dụng đơn thuần mộttrong số các kỹ thuật hiện có để ước lượng chi phí phần mềm Các kỹ thuật tổng hợpkết hợp một hoặc nhiều kỹ thuật để xây dựng công thức của dạng hàm thích hợp nhấtcho ước lượng

Phương pháp này cung cấp một quy trình chuẩn, trong đó, một đánh giá theo ý kiếnchuyên gia có thể kết hợp với thông tin mẫu để tạo ra một mô hình hậu nghiệm mạnh.Dùng lý thuyết Bayes, chúng ta có thể kết hợp hai nguồn thông tin có được như sau:

F( β | Y ) = f ( Y | β) f( β )

f(Y)Trong đó β là véc tơ của các tham số mà ta quan tâm, và Y là véc tơ của các quan sát

mẫu từ hàm mật độ chung F( β | Y ) Trong biểu thức trên, f ( Y | β) là hàmmật độ hậu nghiệm của β, còn f( β ) là thông tin tiền nhiệm tổng kết thôngtin đánh giá chuyên gia về β

Trong phân bố Bayes, xác suất tiền nhiệm là xác suất không điều kiện đơn giản để tínhcho các thông tin mẫu, còn xác suất hậu nghiệm là xác suất có điều kiện, mang lại kiếnthức về thông tin mẫu và thông tin tiền nhiệm

Phương pháp sử dụng thông tin tiền nhiệm không nằm trong dữ liệu mẫu bằng cáchcung cấp một phép kết hợp tối ưu hai nguồn thông tin Trung bình hậu nghiệm b**

Và

Trong đó X là ma trận các biến ngoại sinh, s là biến động của phần dư cho dữ liệu mẫu,còn H* và b* tương ứng là độ chính xác (nghịch đảo của biến động) và giá trị trungbình của thông tin tiền nhiệm

Phân tích Bayes có tất cả các ưu điểm của hồi quy chuẩn và nó kết hợp luôn kiến thứctiền nhiệm của các chuyên gia Nó cố gắng giảm rủi ro của việc thu thập dữ liệu chưahoàn hảo Dữ liệu kỹ nghệ phần mềm thường khan hiếm, không hoàn chỉnh và các nhàước lượng phải đối mặt với thách thức đưa ra các ước lượng chính xác dựa trên dữ liệunày Các kỹ thuật thống kê cổ điển mô tả ở trên rút ra các kết luận từ các dữ liệu sẵn có.Nhưng để đưa ra quyết định tốt nhất, ngoài nhưng dữ liệu mẫu có sẵn, cần kết hợp vớithông tin không phải là mẫu hoặc thông tin tiền nhiệm có liên quan Thường thì nhiềuđánh giá chuyên gia dựa trên thông tin sẵn có về các quy trình phần mềm và tác độngcủa một vài tham số lên công sức, chi phí, thời gian biểu, chất lượng … thông tin nàykhông cần thiết phải lấy từ nghiên cứu thông kê và do đó các kỹ thuật thống kê cổ điểnnhư OLS không kết hợp nó vào quá trình ra quyết định Trong quâ trình ra quyết định,các kỹ thuật Bayes sử dụng tốt nhất thông tin tiền nhiệm liên quan cùng với dữ liệumẫu được thu thập để xây dựng một mô hình mạnh hơn

Kết luận

Trên đây đã giới thiệu tổng quát về các kỹ thuật ước lượng phần mềm khác nhau, đưa

ra một các nhìn tổng thể về một số mô hình ước lượng phổ biến hiện tại Dựa trên cáctài liệu đã tham khảo được, có thể nhận thấy các kỹ thuật dựa trên mạng nơron và độnghọc chưa thuần thục bằng các lớp kỹ thuật khác Tuy nhiên, tất cả các lớp kỹ thuật trênđều đứng trước thách thức phải đối mặt với những bước thay đổi nhanh chóng trongcông nghệ phần mềm Có thể rút ra một kết luận quan trọng là không nên sử dụng chỉmột phương pháp hay một mô hình đơn lẻ trong việc ước lượng phần mềm Bí quyết để

có được những ước lượng đúng đắn là sử dụng kết hợp các phương pháp và công cụkhác nhau Nếu người thực hiện ước lượng có thể giải thích được những khác biệt đó ởmột mức độ thỏa mãn hợp lý, khi đó có lẽ là họ đã nắm rõ được những nhân tố tácđộng lên chi phí của dự án hiện hành Cũng nhờ vậy mà người ước lượng sẽ được trang

bị tốt hơn, nhằm hỗ trợ cho các nhiệm vụ lập kế hoạch và kiểm soát… được thực hiện

khi quản lý dự án

Sau khi đánh giá tổng quan về các kỹ thuật và mô hình ước lượng chi phí phần mềmphổ biến nhất hiện nay, em quyết định chọn mô hình COCOMO II để tập trung nghiêncứu, và dựa vào đó xây dựng lên một công cụ hỗ trợ tự động ước lượng chi phí phầnmềm Là một mô hình có các ước lượng có độ chính xác cao, lại công khai các tham sốcũng như các giải thuật ước lượng nên COCOMO II được chấp nhận rộng rãi Từ khi

mô hình ra đời đến nay vẫn luôn có những nghiên cứu để cải thiện bổ sung, điều chỉnh

và mở rộng mô hình Trong phần tiếp theo, ta sẽ nghiên cứu chi tiết về mô hình ướclượng COCOMO II

CHƯƠNG II: MÔ HÌNH COCOMO II

1 Tổng quan

COCOMO II sử dụng hai mô hình Post-Architecture (PA) và Early – Design (ED) đểước lượng cho việc phát triển dự án phần mềm mô hình PA là mô hình chi tiết được sửdụng khi một dự án đã sẵn sàng để phát triển và có thể duy trì Hệ thống đó đã có mộtkiến trúc vòng đời để cung cấp các thông tin chi tiết về các tham số đầu vào của hệthống, từ đó đảm bảo cho sự chính xác khi ước lượng Còn mô hình ED là một mô hìnhđược sử dụng để khảo sát các khả năng thay thế về kiến trúc hoặc các chiến lược pháttriển gia tăng Mức độ chi tiết của mô hình này phù hợp với tổng quát của các thông tin

có được và độ chính xác cần thiết ở giai đoạn sớm của dự án

Cả PA và ED đều sử dụng cùng một cách tiếp cận để ước lượng kích cỡ sản phẩm (baogồm cả phần tái sử dụng lẫn các hệ số tỷ lệ)

2 Các biểu thức ước lượng trong mô hình COCOMO II

Cả 2 mô hình PA và ED đều sử dụng cùng một dạng hàm số để ước lượng các tiêu chí,chỉ khác nhau về các tham số cụ thể trong các hàm này Các công thức có tính danhnghĩa về thời gian NS (Norminal Schedule) không bao gồm tham số về độ co giãn thờigian, bởi về danh nghĩa luôn giả định rằng các dự án được hoàn thành đúng thời gian.Các công thức sẽ được giới thiệu chi tiết ở phần sau

Lượng công sức danh nghĩa để hòan thành dự án được tình theo nhân công tháng PMNS(Person month) được tình theo công thức:

Các giá trị chuẩn A,B,EM,SF được xác định dựa theo dữ liệu từ 161 dữ liệu dự án phầnmềm của COCOMO II Trong đó 6 hệ số nhân công sức trong mô hình ED là tổng hợp

16 hệ số nhân công sức tương ứng trong mô hình PA các giá trị trong cocomo II

Các giá trị hằng số A,B,C,D này có thể được điều chỉnh cho phù hợp với môi trườngphát triển của tổ chức mỗi tổ chức đều nên hiệu chỉnh tối thiểu 2 giá trị A,C cho phùhợp với môi trường của mình để đạt được sự chính xác cần thiết cho ước lượng chứkhông nên chỉ áp dụng giá trị chuẩn mà COCOMO II đã đưa ra

mã lệnh cơ bản là mã được viết mới và mã lệnh sao chép có sửa đổi, bởi chỉ hai loạinày mới ảnh hưởng đến công sức phát triển phần mềm Và hai loại mã này đều đượcgộp chung lại sau khi đã quy đổi kích cỡ module tái sử dụng thành kích cỡ tươngđương

3.1 Đếm số dòng mã lệnh

Có nhiều phương pháp và kỹ thuật để thực hiện việc ước lượng số dòng mã lệnh Kích

cỡ của số dòng mã lệnh được tình theo đơn vị nghìn dòng lệnh KSLOC Để xác địnhchính xác được thế nào là một dòng lệnh nói chung là khó, vì nó phụ thuộc nhiều vàođặc thù riêng của từng ngôn ngữ lập trình Học viện kỹ thuật phần mềm SEI đưa ra mộtbản liệt kê các câu lệnh nguồn logic được dùng làm đơn vị đo lường cho dòng mã lệnh

Hình sau minh họa bảng liệt kê của SEI với mỗi dấu tích trong phần “include” là ứngvới thành phần tương ứng được tính là mã nguồn logic, còn tích trong “exclude” làthành phần không được tính

Bảng 1: Danh sách liệt kê các loại dòng lệnh được tính

Để ước lượng số dòng mã lệnh với độ chính xác chấp nhận được đòi hỏi phải có kinhnghiệm trong thiết kế, kinh nghiệm với các dự án tiền nhiệm của tổ chức Thôngthường, người ta áp dụng nhiều phương pháp như áp dụng tương tự, lấy ý kiến chuyêngia hay ước lượng theo chiều dài của bản đặc tả yêu cầu và thiết kế…

Ước lượng số dòng mã lệnh dựa theo chiều dài của bản đặc tả yêu cầu và thiết kế được

áp dụng khi một tổ chức phát triển phần mềm có môi trường chặt chẽ, quy định thốngnhất trong tất cả các dự án, và có tài liệu rõ ràng Trong môi trường như thế, người tathấy có thể tìm được tỷ lệ tương đối giữa chiều dài đặc tả yêu cầu và thiết kế với sốdòng mã lệnh

3.2 Đếm các điểm chức năng chưa điều chỉnh UFP

Phép tiếp cận ước lượng chi phí theo điểm chức năng dựa trên số lượng chức năng cótrong một dự án phần mềm và một tập các nhân tố đơn lẻ của dự án Điểm chức năngrất hữu ích cho việc ước lượng bởi chúng dựa trên thông tin có được từ giai đoạn sớmcủa dự án.

Việc đếm điểm chức năng của một dự án được thực hiện bằng cách tính số lượng cácđiểm chức năng xử lý theo 5 kiểu chính sau

Bảng 2: Các loại chức năng

Nhập dữ liệu EI Các chức năng nhập dữ liệu có ảnh

hưởng tới ILF

Các tệp logic trong ILF Các tệp logic được quản lý bởi ứng

dụng, Các tệp giao tiếp ngoài EIF Gồm các tệp của các ứng dụng khác

được gọi

Mỗi thể hiện của các kiểu chức năng trên được sắp xếp và phân chia theo các mức độphức tạp Kết hợp độ phức tạp với tất cả các điểm chức năng đếm được sẽ cho ta một

số điểm chức năng chưa điều chỉnh Đây là một đơn vị kích cỡ được COCOMO II sửdụng và chuyển đổi qua số KSLOC làm dữ liệu đầu vào về kích cỡ phần mềm

Quy trình xác định UFP gồm 4 bước:

 Đếm số các chức năng theo kiểu: dựa vào các đặc tả yêu cầu phần mềm, với kinhnghiệm của những chuyên viên hàng đầu để tính ra số lượng chức năng từng kiểu

 Xác định độ phức tạp: phân chia, sắp xếp các chức năng theo độ phức tạp tươngứng Thấp, trung bình, cao tùy theo số lượng các kiểu phần tử dữ liệu chứa trongchức năng đó và số lượng các kiểu tệp mà chức năng đó tham chiếu đến

 Xác định trọng số cho các chức năng: định trọng số cho từng kiểu chức năng theocác cấp độ phức tạp khác nhau

 Tính toán UFP: là tổng của tất cả trọng số các điểm chức năng đã được đếm

Bảng 3: Xác định trọng số theo độ phức tạp của chức năng

Mối liên hệ UFP với SLOC

Trong quá trình nghiên cứu, người ta thấy có sự tương quan giữa UFP và SLOC phụthuộc vào ngôn ngữ lập trình sử dụng Nói một cách khác, để thực hiện cùng một chức