Tối ưu tham số trong mô hình cocomo để ước lượng phát triển phần mềm

LỜI CAM ĐOAN Tôi cam đoan rằng, luận văn thạc sĩ : Tối ưu các tham số trong mô hình CoCoMo để ước lượng nỗ lực phát triển phần mềm” là công trình nghiên cứu của riêng tôi.. ÁP DỤNG THUẬ

TRƯỜNG ĐẠI HỌC BÁCH KHOA -

LỜI CẢM ƠN

Trước hết em xin gửi lời cảm ơn chân thành đến toàn thể các thầy cô giáo trong Khoa Công nghệ Thông tin – Trường Đại học Bách khoa – Đại học Đà Nẵng đã tận tình dạy dỗ chúng em trong suốt quá trình học tập và nghiên cứu tại trường

Đặc biệt, em xin bày tỏ lòng biết ơn sâu sắc đến Cô giáo TS Lê Thị Mỹ Hạnh Khoa Công nghệ Thông tin – Trường Đại học Bách khoa – Đại học Đà Nẵng đã quan tâm hướng dẫn và đưa ra những gợi ý, góp ý, chỉnh sửa vô cùng quý báu cho em trong quá trình làm luận văn tốt nghiệp

Cuối cùng xin chân thành cảm ơn những người bạn, đồng nghiệp, gia đình đã tạo điều kiện giúp đỡ, chia sẽ với em trong suốt quá trình làm luận văn

Đà Nẵng, ngày 11 tháng 11 năm 2017 HỌC VIÊN

Đặng Quang Văn

LỜI CAM ĐOAN

Tôi cam đoan rằng, luận văn thạc sĩ : Tối ưu các tham số trong mô hình CoCoMo

để ước lượng nỗ lực phát triển phần mềm” là công trình nghiên cứu của riêng tôi

Các số liệu, kết quả nêu trong luận văn là trung thực và chưa từng được ai công bố trong bất kỳ công trình nào khác

Đà Nẵng, Ngày 11 tháng 11 năm 2017

TÁC GIẢ LUẬN VĂN

Đặng Quang Văn

MỤC LỤC

LỜI CAM ĐOAN ii

CÁC LOẠI DANH MỤC vii

1 Danh mục các ký hiệu, các chữ viết tắt vii

2 Danh mục các bảng ix

3 Danh mục các hình vẽ x

MỞ ĐẦU 1

1 TÍNH CẤP THIẾT CỦA ĐỀ TÀI 1

2 MỤC ĐÍCH NGHIÊN CỨU 2

3 ĐỐI TƯỢNG VÀ PHẠM VI NGHIÊN CỨU 2

4 PHƯƠNG PHÁP NGHIÊN CỨU 2

5 Ý NGHĨA KHOA HỌC VÀ THỰC TIỄN CỦA ĐỀ TÀI 2

6 CẤU TRÚC LUẬN VĂN 2

CHƯƠNG 1 4

TỔNG QUAN VỀ ƯỚC LƯỢNG NỖ LỰC PHÁT TRIỂN PHẦN MỀMTRONG MÔ HÌNH COCOMO II 4

I ƯỚC LƯỢNG NỖ LỰC VÀ CÁC MÔ HÌNH ƯỚC LƯỢNG NỖ LỰC TRONG PHÁT TRIỂN PHẦN MỀM 4

1 Ước lượng nỗ lực 4

1.1 Tiếp cận ước lượng từ dưới lên (Bottom-up estimation approach) 5

1.2 Tiếp cận ước lượng từ trên xuống (The top-down estimation approach) 7

2 Các mô hình ước lượng nỗ lực phát triển phần mềm 8

II TIẾP CẬN MÔ HÌNH ƯỚC LƯỢNG NỖ LỰC PHÁT TRIỂN PHẦN MÊM COCOMO II 9

III CẤU TRÚC MÔ HÌNH COCOMO II 11

1 Các yếu tố quy mô của dự án 13

1.1 Tính tiên phong (PREC) và Tính linh hoạt trong phát triển (FLEX) 14

1.2 Kiến trúc giải quyết rủi ro (RESL) 15

1.3 Sự gắn kết đội (TEAM) 17

1.4 Quy trình trưởng thành (PMAT) 18

2 Các nhân tố nỗ lực của trình điều khiển chi phí 18

2.1 Yếu tố sản phẩm phần mềm 18

2.1.1 Độ tin cậy phần mềm 18

2.1.2 Kích thước dữ liệu (DATA) 19

2.1.3 Tính phức tạp của sản phẩm (CPLX) 19

2.1.4 Yêu cầu khả năng sử dụng lại (RUSE) 22

2.1.5 Tài liệu phù hợp với nhu cầu của vòng đời (DOCU) 22

2.2 Yếu tố nền tảng 22

2.2.1 Hạn chế thời gian thực hiện (TIME) 22

2.2.2 Hạn chế lưu trữ chính (STOR) 23

2.2.3 Nền tảng biến động (PVOL) 23

2.3 Yếu tố Nhân sự 24

2.3.1 Khả năng phân tích (ACAP) 24

2.3.2 Khả năng lập trình (PCAP) 24

2.3.3 Kinh nghiệm ứng dụng (AEXP) 25

2.3.4 Kinh nghiệm về ngôn ngữ và công cụ (LTEX) 25

2.3.5 Nhân sự liên tục (PCON) 25

2.4 Yếu tố dự án 26

2.4.1 Sử dụng công cụ phần mềm (TOOL) 26

2.4.2 Phát triển đa chiều (SITE) 26

2.4.3 Lịch phát triển bắt buộc (SCED) 27

IV TIỂU KẾT CHƯƠNG I 27

CHƯƠNG 2 28

THUẬT TOÁN TÌM KIẾM CUCKOO SEARCH (CS) 28

I GIỚI THỆU 28

II HÀNH VI SINH SỐNG CỦA LOÀI CHIM CUCKOO VÀ CHUYẾN BAY LÉVY 28 1 Hành vi sinh sống của loài chim cuckoo 28

2 Chuyến bay Lévy 29

III THUẬT TOÁN TÌM KIẾM CUCKOO SEARCH (CS) 32

1 Kiến trúc thuật toán tìm kiếm Cuckoo search(cs) 32

2 Thiết kế và cài đặt thuật toán 33

3 Một số ứng dụng của thuật toán CS 35

IV TIỂU KẾT CHƯƠNG 2 36

CHƯƠNG 3 37

ÁP DỤNG THUẬT TOÁN CUCKOOS SEARCH (CS) TỐI ƯU CÁC THAM SỐ TRONG MÔ HÌNH COCOMO II ĐỂ ƯỚC LƯỢNG NỖ LỰC PHÁT TRIỂN PHẦN MỀM 37

I GIỚI THIỆU 37

II THU THẬP DỮ LIỆU, PHÂN TÍCH, MÔ HÌNH ĐÁNH GIÁ 37

1 Thu thập dữ liệu 37

2 Phân tích mô hình CoCoMoII 40

3 Mô hình đánh giá chất lượng ước tính 42

III ÁP DỤNG THUẬT TOÁN CUCKOO SEARCH (CS) ĐỂ TỐI ƯU CÁC THAM SỐ TRONG MÔ HÌNH COCOMO II 43

1 Thuật toán cuckoo search(CS) 43

2 Hàm chất lượng ước tính (fitness) 44

3 Ứng dụng thuật toán Cuckoo search (CS) tối ưu các tham số trong mô hình CoCoMo II 44

IV KẾT QUẢ VÀ ĐÁNH GIÁ HIỆU QUẢ CỦA THUẬT TOÁN, SO SÁNH VỚI MỘT SỐ THUẬT TOÁN KHÁC 47

1 Kết quả thuật toán 47

2 Đánh giá hiệu quả của thuật toán và so sánh với một số thuật toán khác 47

V TIỂU KẾT CHƯƠNG 3 49

TÀI LIỆU THAM KHẢO 50

TỐI ƯU CÁC THAM SỐ TRONG MÔ HÌNH COCOMO ĐỂ ƯỚC LƯỢNG

NỖ LỰC PHÁT TRIỂN PHẦN MỀM

Học viên: Đặng Quang Văn Chuyên ngành: Khoa Học Máy Tính

Mã số: ………Khóa: K32 Trường Đại học Bách khoa - ĐHĐN Tóm tắt - Ước lượng nỗ lực, chi phí phần mềm là một hoạt động quan trọng trong chu trình phát triển để kiểm soát rủi ro và lập kế hoạch lịch trình dự án Chính xác dự toán của chi phí trước khi bắt đầu một dự án là điều cần thiết cho cả hai nhà phát triển và khách hàng

Do đó, nhiều mô hình đã được đề xuất để giải quyết vấn đề này, trong đó COCOMO II đã được sử dụng rộng rãi trong các dự án phần mềm hiện đại Mô hình này là một trong những

mô hình ước lượng nỗ lực đã đem lại kết quả ước lượng tốt nhất trong mọi dự án phần mềm, đảm bảo tính khả thi cao cho dự án Tuy nhiên, các thông số này chưa được ước tính và kết quả không gần với kết quả thực tế Trong luận văn này, một phương pháp mới để tối ưu hóa các tham số cho mô hình COCOMO II bằng cách sử dụng thuật toán CS được đề xuất lấy từnguồn cảm hứng của thiên nhiên để tối ưu hóa Hiệu suất của mô hình đã được thử nghiệm trên dữ liệu dự án phần mềm NASA Các kết quả báo cáo rằng việc cải thiện các thông sốđược cung cấp bởi mô hình COCOMO II

Từ khóa - COCOMO II, dự toán chi phí, phần mềm NASA, tối ưu hóa, thuật toán CS

OPTIMIZATION OF PARAMETERS IN COCOMO MODEL II TO

ESTIMATE THE SOFTWARE DEVELOPMENT

Summary - Estimating effort, software costs are an important activity in the development cycle for risk control and project scheduling Accurate estimation of costs before starting a project is essential for both developers and clients Therefore, many models have been proposed to solve this problem, in which COCOMO II has been widely used in modern software projects This model is one of the effort estimation models that has yielded the best estimate of all software projects, ensuring high feasibility for the project However, these parameters have not been estimated and the results are not close to the actual results In this essay, a new method for optimizing parameters for the COCOMO II model using the proposed CS algorithm is derived from the inspiration of nature for optimization The performance of the model was tested on NASA software project data The results reported that the improvement of parameters was provided by the COCOMO II model

Keywords - COCOMO II, cost estimation, NASA software, optimization, CS algorithm

PCON Nhân sự liên tục

PEXP Nền tảng Kinh nghiệm

PM Nỗ lực (Người - tháng)

PVOL Nền tảng biến động

RELY Yêu cầu Phần mềm Độ tin cậy

RUSE Yêu cầu khả năng sử dụng lại

SCED Lịch phát triển bắt buộc

SITE Phát triển đa chiều

SLOC Dòng mã nguồn

STOR Hạn chế lưu trữ chính

TIME Hạn chế thời gian thực hiện

TOOL Sử dụng các công cụ phần mềm

TDEV Xác định thời gian để phát triển (tháng)

DATA Kích thước dữ liệu DATA

CPLX Tính phức tạp của sản phẩm

DOCU Tài liệu phù hợp với nhu cầu của vòng đời

ACAP Khả năng phân tích

AEXP Kinh nghiệm ứng dụng

PREC Tính tiên tiến

FLEX Tính linh hoạt trong phát triển

RESL Kiến trúc / Giải quyết Rủi ro

TEAM Sự gắn kết đồng đội

PMAT Quy trình trưởng thành

SF Yếu tố quy mô

EM Yếu tố điều khiển chi phí

SIZE Kích thước mã nguồn

CS Thuật toán Cuckoo search

KLOC Đơn vị ngàn dòng lệnh

MMRE Độ lớn trung bình của lỗi tương đối

PRED (N) Dự đoán ở mức N

TLBO Thuật toán dạy và học

COCOMO Mô hình ước lượng, nỗ lực phát triển phần mềm

1.1 Các yếu tố quy mô cho các mô hình COCOMO II và các mô hình

hậu kiến trúc một giao diện mô đun đáng kể, % xác định, % rủi ro

3.1 Bảng giá trị về các nhân tố nỗ lực của trình điều khiển chi phí dự án 38

3.4 Bảng các giá trị PRED cho ước tính sử dụng CS, COCOMO II và

3 Danh mục các hình vẽ

Số hiệu

bảng vẽ

MỞ ĐẦU

1 TÍNH CẤP THIẾT CỦA ĐỀ TÀI

Ngày nay, với nhu cầu sử dụng phần mềm và sự cạnh tranh giữa các cá nhân tổ chức danh nghiệp phát triển phần mềm ngày một phức tạp Vì vậy để đảm bảo tính khả thi và hiệu quả cho một dự án phần mềm, việc ước lượng nỗ lực dự án phần mềm

là một trong những vấn đề then chốt và quan trọng nhất trước khi bắt đầu triển khai dự

án và đưa đến người sử dụng Một loạt các kỹ thuật ước lượng sử dụng dữ liệu thu thập được từ các dự án trước đó cộng với công thức toán học để dự đoán chi phí cho

dự án được giới thiệu như mô hình COCOMO II, SLIM, Kỹ thuật ước lượng được phân bố vào các mô hình hồi quy, phương pháp chuyên gia dựa trên các phương pháp học tập theo định hướng và phương pháp Bayesian Nhưng những phương pháp trên khó có thể đưa ra được một sự ước lượng chính xác tốt nhất so với thực tế và sự thành công hay thất bại của một dự án điều phụ thuộc rất lớn vào độ chính xác của kết quả ước lượng chi phí và tiến độ Do đó, bài toán được đặt ra là cần phải tìm ra một phương pháp tối ưu hơn để ước lượng chi phí dự án phần mềm Mô hình COCOMO II được phát triển vào năm 1995, là một mô hình cho phép ước tính chi phí, nỗ lực và tiến độ lập kế hoạch cho một hoạt động phát triển phần mềm mới Trong COCOMO II,

nỗ lực này được thể hiện như Người-tháng (PM) Một tháng là khoảng thời gian được tính cho một người dành khoảng thời gian đó làm việc cho dự án phát triển phần mềm Qua việc giới thiệu mô hình COCOMO II đã góp phần đáng kể vào việc nâng cao

độ chính xác trong ước lượng chi phí phần mềm và hiện nay đây là một trong những

mô hình được sử dụng phổ biến nhất Tuy nhiên, mô hình này dựa trên một số giá trị không đổi của các phương trình ước lượng dựa trên tham số Những hằng số này đã không được tối ưu hóa, và do đó tính chính xác của ước lượng đối với các dự án không cao so với nỗ lực và thời gian thực tế

Trong khi đó, Các thuật toán hiện đại ngày càng được lấy cảm hứng từ tự nhiên đang nổi lên và chúng ngày càng trở nên phổ biến Thuật toán Cuckoo là một thuật toán siêu dữ liệu mới, được gọi là Cuckoo Search (CS), để giải quyết các vấn đề tối ưu hoá Thuật toán này dựa trên hành vi ký sinh trùng bắt buộc của một số loài chim cu cùng với sự di chuyển được phân phối bởi Le'vy của một số loài chim và ruồi giấm

Vì những lý do như trên, tôi quyết định chọn đề tài:

“ Tối ưu tham số trong mô hình CoCoMo để ước lượng nỗ lực phát triển phần

mềm”

2 MỤC ĐÍCH NGHIÊN CỨU

Áp dụng thuật toán CS vào bài toán tối ưu tham số trong mô hình COCOMO II

để ước lượng nỗ lực phát triển phần mềm

3 ĐỐI TƯỢNG VÀ PHẠM VI NGHIÊN CỨU

Đối tượng nghiên cứu: Nghiên cứu các ước lượng nỗ lực phát triển phần mềm và

mô hình ước lượng COCOMO II, thuật toán tối ưu CS

Phạm vi nghiên cứu: Nghiên cứu về ước lượng nỗ lực phát triển phần mềm trong

mô hình COCOMO II, phương pháp tối ưu các tham số trong mô hình COCOMO II sử dụng thuật toán CS

4 PHƯƠNG PHÁP NGHIÊN CỨU

Tôi sử dụng kết hợp nhiều phương pháp, trong đó chủ yếu là nghiên cứu lý thuyết và nghiên cứu thực nghiệm

Phương pháp nghiên cứu lý thuyết: Tìm hiểu, tra cứu, phân tích và tổng hợp từ sách, các bài báo, tạp chí khoa học, các trang web, các bài luận văn thạc sĩ trong nước

và nước ngoài

Phương pháp thực nghiệm: Cài đặt thuật toán CS để tối ưu các tham số trong mô hình COCOMO II trên công cụ MATLAB, đánh giá kết quả tối ưu qua kỹ thuật đánh giá MMRE, PRED

5 Ý NGHĨA KHOA HỌC VÀ THỰC TIỄN CỦA ĐỀ TÀI

Ý nghĩa khoa học: Đề xuất phương pháp tối ưu mới bằng cách áp dụng thuật toán

CS để tối ưu tham số trong mô hình CoCoMo II

Ý nghĩa thực tiễn của đề tài: Kết quả nghiên cứu giúp cho việc ước lượng nỗ lực, chi phí, thời gian phát triển phần mềm trong mô hình CoCoMo II một cách chính xác nhất, đảm bảo tính khả thi cho dụ án

6 CẤU TRÚC LUẬN VĂN

Luận văn được trình bày gồm 3 chương

Chương 1: Tổng quan về ước lượng nỗ lực phát triển phần mềm trong mô

hình COCOMO II

Nội dung chương này sẽ trình bày chi tiết về tầm quan trọng của việc ước lượng trong dự án phát triển phần mềm, ước lượng nỗ lực và mô hình ước lượng nỗ lực phát triển phần mềm, tiếp cận ước lượng nỗ lực phát triển phần mềm trong mô hình

CoCoMo II và cấu trúc của nó và đưa ra phương trình tổng quát về ước lượng nỗ lực, thời gian phát triển phần mềm trong mô hình CoCoMo II

Chương 2: Thuật toán tìm kiếm Cuckoo Search (CS)

Trong nội dung chương này, giới thiệu và mô tả chi tiết về thuật toán tìm kiếm cuckoos search (CS), là một trong những thuật toán lấy cảm hứng từ thiên nhiên, dựa vào hành vi ký sinh trùng của một số loài chim Cuckoos

Chương 3: áp dụng thuật toán CUCKOO SEARCH (CS) tối ưu các tham số trong mô hình COCOMO II để ước lượng nỗ lực phát triển phần mềm

Trong chương 3 này sẽ trình bày chi tiết về cách tối ưu các tham số trong mô hình CoCoMo II sử dụng thuật toán CS để ước lượng nỗ lực, chi phí và thời gian trong phát triển dự án phần mềm Trong đó, giới thiệu lý do tối ưu, các mô hình đánh giá và phân tích mô hình tuyến tính trong mô hình CoCoMo II Giới thiệu sơ lược về thuật toán CS

và ứng dụng thuật toán này vào việc tối ưu các tham số A, B, C và D trong mô hình

CoCoMo II

CHƯƠNG 1

TỔNG QUAN VỀ ƯỚC LƯỢNG NỖ LỰC PHÁT TRIỂN PHẦN

MỀMTRONG MÔ HÌNH COCOMO II

Trên thế giới, số lượng dự án phần mềm được sản xuất để phục vụ cho nhu cầu xã hội mỗi năm là rất lớn Tuy nhiên nhiều dự án trong số này có chất lượng không như

kỳ vọng của khách hàng hoặc không cung cấp các phần mềm trong phạm vi ngân sách

và thời gian hoàn thành Tại sao quá nhiều dự án phần mềm thất bại? Mặc dù có rất nhiều lý do, một trong những lý do quan trọng nhất là quản lý, ước lượng dự án phần mềm không phù hợp Ví dụ, các lý do chính làm cho việc ước lượng dự án phần mềm

có sự chênh lệch rất lớn so với thực tế là mục tiêu và lập kế hoạch không rõ ràng, không làm chủ công nghệ mới, thiếu phương pháp quản lý dự án, và không quản lý được rủi ro trong dự án v v

Chính vì lẽ đó, việc ước lượng là một trong những nhiệm vụ rất quan trọng và phức tạp nhất trong quản lý dự án Với mục tiêu là để chính xác các nguồn lực cần thiết và lịch trình yêu cầu cho các dự án phát triển phần mềm Quá trình ước lượng phần mềm bao gồm ước tính kích cỡ của sản phẩm phần mềm sẽ được tạo ra, ước tính các nỗ lực cần thiết, xây dựng sơ đồ dự án ban đầu, và cuối cùng là ước tính toàn bộ chi phí của dự án Trong vài năm nghiên cứu gần đây, có nhiều phương pháp, mô hình ước lượng chi phí, nỗ lực phần mềm có sẵn bao gồm các phương pháp thuật toán, ước tính bằng phương pháp tương tự, phương pháp đánh giá chuyên gia, mô hình AGILE, CoCoMo v.v, đã góp phần đưa ra một kết quả ước lượng chính xác so với thực tế

I ƯỚC LƯỢNG NỖ LỰC VÀ CÁC MÔ HÌNH ƯỚC LƯỢNG NỖ LỰC TRONG PHÁT TRIỂN PHẦN MỀM

1 Ước lượng nỗ lực

Ước lượng thường diễn ra sau giai đoạn phân tích, tức là khi người quản lý dự án ước lượng nỗ lực, các yêu cầu đã được hiểu rõ ràng Các quy trình nghiệp vụ được tổ chức để hỗ trợ phương pháp này Ví dụ, giai đoạn yêu cầu đôi khi được thực hiện như một dự án riêng biệt với dự án phát triển phần mềm

Với nhiều phương pháp ước lượng đã được đề xuất, người quản lý dự án có thể lựa chọn bất kỳ phương pháp ước lượng nào miễn là nó thích hợp với tính chất công việc Đôi khi, người quản lý dự án có thể thực hiện ước lượng bằng cách sử dụng nhiều

phương pháp khác nhau, để xác nhận độ chính xác của một ước lượng được làm bởi một phương pháp chính nào đó hoặc để giảm rủi ro, đặc biệt là khi không có nhiều dữ liệu quá khứ của dự án tương tự Có 2 phương pháp cơ bản để ước lượng nỗ lực

1.1 Tiếp cận ước lượng từ dưới lên (Bottom-up estimation approach)

Đa số các dự án phát triển phần mềm được thực hiện thì rất khác nhau, sự tiếp cận từ dưới lên cũng được ưa thích và được khuyến khích Với phương pháp này sử dụng đơn vị công việc, mặc dù một số hạn chế của chiến lược này đã được khắc phục thông qua việc sử dụng các dữ liệu quá khứ và cơ sở về khả năng của quy trình

Trong phương pháp đơn vị công việc, người quản lý dự án đầu tiên chia phần mềm sắp được phát triển ra thành các chương trình chính hoặc đơn vị chương trình Mỗi đơn vị chương trình sau đó được phân loại là trung bình, đơn giản hoặc phức tạp dựa trên các tiêu chí nhất định Đối với mỗi đơn vị phân loại, người quản lý dự án xác định một nỗ lực tiêu chuẩn cần thiết để cài đặt mã và tự kiểm thử (cả hai công việc này được gọi chung là nỗ lực xây dựng Nỗ lực xây dựng chuẩn này có thể được xác định từ dữ liệu quá khứ của một dự án tương tự, từ các hướng dẫn nội bộ có sẵn, hoặc kết hợp những khả năng này Một khi số lượng các đơn vị trong ba loại phức tạp được biết và nỗ lực xây dựng đã được ước lượng cho mỗi chương trình được chọn, số nỗ lực tổng thể cho giai đoạn xây dựng của dự án sẽ được biết Từ nỗ lực xây dựng, nỗ lực được cần cho các giai đoạn và các hoạt động khác sẽ được xác định bằng một tỷ lệ phần trăm của nỗ lực cài đặt mã Dựa vào cơ sở về khả năng của quy trình hoặc cơ sở dữ liệu quy trình, phân phối nỗ lực trong dự án được biết Nhà quản lý dự án sử dụng tỷ lệ phân phối này

để xác định các nỗ lực cho giai đoạn và các hoạt động khác nhau Từ những ước lượng này, nỗ lực tổng thể cho dự án được biết Phương pháp này đã sử dụng một hỗn hợp của kinh nghiệm và dữ liệu một cách hợp lý Nếu không có sẵn dữ liệu phù hợp (ví dụ, nếu bạn đang bắt đầu một kiểu dự án mới), bạn có thể ước lượng nỗ lực xây dựng dựa theo kinh nghiệm sau khi bạn phân tích dự án xong và khi bạn biết số lượng các đơn vị chương trình khác nhau Với các ước lượng đã có sẵn, có thể ước lượng cho các hoạt động khác nhau bằng cách sử dụng dữ liệu về tỷ lệ phân phối nỗ lực của các dự án trong quá khứ Chiến lược này có khả năng tính đến các hoạt động mà chúng thường khó được liệt kê ra ở giai đoạn đầu của dự án, khi thực hiện phân phối nỗ lực cho một

dự án, loại khác thường được sử dụng để thực hiện các công việc hoặc nhiệm vụ linh tinh

Quy trình (thủ tục) ước lượng có thể được tóm tắt theo trình tự các bước như sau:

 Xác định các chương trình trong hệ thống và phân loại chúng là đơn giản, trung bình, hoặc phức tạp (S/M/C) Càng nhiều càng tốt, hãy sử dụng các định nghĩa chuẩn đã được cung cấp hoặc các định nghĩa của các dự án trong quá khứ

 Nếu một cơ sở riêng của dự án tồn tại, hãy tính ra nỗ lực xây dựng trung bình cho các chương trình S/M/C từ cơ sở này

 Nếu cơ sở riêng của dự án chưa tồn tại, hãy sử dụng: loại dự án, công nghệ, ngôn ngữ, và các thuộc tính khác để tìm kiếm các dự án tương tự trong cơ sở

dữ liệu quy trình Hãy sử dụng dữ liệu từ các dự án này để xác định nỗ lực xây dựng cho các chương trình S/M/C

 Nếu không có dự án tương tự tồn tại trong cơ sở dữ liệu quy trình và cũng không có cơ sở riêng của dự án, hãy sử dụng nỗ lực xây dựng trung bình cho các chương trình S/M/C từ cơ sở chung về khả năng quy trình

 Sử dụng các yếu tố riêng của dự án để tinh chỉnh các nỗ lực xây dựng cho chương trình S/M/C

 Tính ra tổng nỗ lực xây dựng bằng cách sử dụng nỗ lực xây dựng của các chương trình S/M/C và đếm chúng

 Sử dụng tỷ lệ phân phối nỗ lực được đưa ra trong cơ sở về khả năng hoặc trong các dự án tương tự trong cơ sở dữ liệu quy trình, ước lượng nỗ lực cho các công việc/nhiệm vụ khác và nỗ lực tổng

 Tinh chỉnh lại các ước lượng dựa trên các yếu tố riêng của dự án Thủ tục này

sử dụng cơ sở dữ liệu quy trình và cơ sở về khả năng quy trình Nếu nhiều dự

án có cùng một loại đang được thực hiện, bạn có thể xây dựng một cơ sở về khả năng của dự án Một cơ sở như vậy là tương tự như các cơ sở chung nhưng chỉ sử dụng dữ liệu từ vài dự án cụ thể Các cơ sở này đã được nhận thấy là tốt nhất để ước lượng nỗ lực cho một dự án mới có cùng loại đó Vì thế, chúng được ưa thích khi được sử dụng cho ước lượng

Bởi vì nhiều yếu tố khác nhau có thể ảnh hưởng đến lượng nỗ lực cần thiết cho một dự án, điều quan trọng khi làm ước lượng là phải xác định được các yếu tố riêng của dự án Thay vì phân loại các tham số ra thành các mức khác nhau và sau đó xác định mức độ ảnh hưởng lên lượng nỗ lực được cần, phương pháp được nêu ra ở đây cho phép người quản lý dự án xác định tác động của các yếu tố riêng của dự án lên ước lượng Người quản lý dự án có thể thực hiện điều chỉnh bằng cách sử dụng kinh nghiệm của họ, kinh nghiệm của các thành viên trong nhóm, hoặc dữ liệu từ các dự án được tìm thấy trong cơ sở dữ liệu quy trình

Lưu ý rằng phương pháp phân loại các chương trình ra thành vài loại và sử dụng số nỗ lực xây dựng trung bình cho mỗi loại được áp dụng để thực hiện ước lượng nỗ lực tổng thể Tuy nhiên, khi lập kế hoạch chi tiết, người quản lý dự án phân công mỗi đơn

vị kích thước cho một thành viên của nhóm để cài đặt mã, và thời gian cho các hoạt động đặc trưng của một đơn vị kích thước sẽ được ghi nhận xem nó có cần thời gian nhiều hơn hoặc ít hơn so với trung bình

1.2 Tiếp cận ước lượng từ trên xuống (The top-down estimation approach)

Giống như tiếp cận từ dưới lên, ở phương pháp tiếp cận này bắt đầu với một ước lượng kích thước mã nguồn của các phần mềm dùng các điểm chức năng Các điểm chức năng có thể được đếm bằng cách sử dụng các quy tắc đếm điểm chức năng chuẩn Ngoài ra, nếu kích thước được ước lượng bằng LOC, nó có thể được chuyển đổi thành các điểm chức năng

Ngoài ước lượng kích thước mã nguồn, tiếp cận từ trên xuống đòi hỏi phải ước lượng năng suất Các tiếp cận cơ bản là bắt đầu với các mức năng suất của các dự án tương

tự (dữ liệu đã có sẵn trong cơ sở dữ liệu quy trình) hoặc với số liệu năng suất chuẩn (mà dữ liệu về nó đã có sẵn trong baseline về khả năng của quy trình), sau đó phải điều chỉnh lại các mức này nếu cần thiết, để phù hợp với dự án đang được ước lượng Ước lượng năng suất sau đó được sử dụng để tính ra nỗ lực tổng thể Từ nỗ lực tổng thể, nỗ lực cho các giai đoạn khác nhau được ước lượng bằng cách sử dụng các bảng phân phối tỷ lệ phần trăm Như trong tiếp cận từ dưới lên, những phân phối này có thể thu được từ cơ sở dữ liệu quy trình hoặc cơ sở về khả năng quy trình

Tóm tắt tiếp cận tổng thể để thực hiện ước lượng từ trên xuống bao gồm các bước sau đây:

 Ước lượng kích thước tổng cộng của phần mềm bằng các điểm chức năng

 Sử dụng các dữ liệu về năng suất từ cơ sở về khả năng của dự án, từ cơ sở về khả năng của quy trình, hoặc từ các dự án tương tự, sửa chữa lại các mức năng suất cho phù hợp với dự án đang được ước lượng

 Có được nỗ lực tổng thể của dự án từ năng suất và kích thước

 Tinh chỉnh lại ước lượng, có xem xét đến mức độ ảnh hưởng của các yếu tố riêng của dự án

 Sử dụng dữ liệu về phân phối nỗ lực từ cơ sở về khả năng của quy trình hoặc

từ các dự án tương tự để ước lượng nỗ lực cho các giai đoạn khác nhau Cũng giống như tiếp cận từ dưới lên, tiếp cận từ trên xuống cũng cho phép tinh chỉnh lại kết quả ước lượng bằng cách sử dụng các yếu tố riêng của dự án Sự cho phép này (không thực sự định nghĩa các yếu tố nào) báo hiệu rằng mỗi dự

án là duy nhất và có thể có vài yếu tố đặc trưng có thể không có mặt trong các

dự án khác Không thể liệt kê ra những yếu tố đặc trưng này hoặc lập mô hình một cách hình thức về sự ảnh hưởng của chúng lên năng suất Do đó, hãy để cho người quản lý dự án quyết định các yếu tố nào cần được xem xét và chúng sẽ ảnh hưởng lên dự án thế nào

2 Các mô hình ước lượng nỗ lực phát triển phần mềm

Một mô hình ước lượng phần mềm định nghĩa các đặc trưng của dự án mà giá trị của những đặc trưng này được dùng để tính nỗ lực (effort) Một mô hình ước lượng không thể hoạt động trong chân không, nó cần các yếu tố đầu vào để tạo ra nỗ lực ở đầu ra Ở lúc bắt đầu dự án, khi các chi tiết của phần mềm chưa được biết đến, mô hình ước lượng sẽ đòi hỏi các giá trị của các yếu tố đặc trưng có thể được xác lập ở giai đoạn này Kích thước mã nguồn (SIZE) của phần mềm là yếu tố quan trọng nhất trong việc xác định bao nhiêu nỗ lực là cần thiết để xây dựng nó Tuy nhiên, SIZE cuối cùng thì không được biết khi dự án vẫn còn đang được hình thành, và phần mềm chưa thực sự tồn tại Do đó, nếu SIZE được sử dụng cho một mô hình ước lượng nỗ lực thì

nó phải được ước lượng ngay từ lúc đầu

Tiếp cận phổ biến thông thường sử dụng một phương trình đơn giản để có được một ước lượng nỗ lực tổng thể từ ước lượng kích thước mã nguồn Phương trình này có thể được xác định thông qua phân tích hồi quy các dữ liệu quá khứ về nỗ lực (effort) và SIZE Sau đó, một khi nỗ lực tổng thể của dự án được biết, nỗ lực phân bổ cho các giai đoạn hoặc các hoạt động khác nhau có thể được xác định bằng một tỷ lệ phần trăm của

nỗ lực tổng thể

Nhiều mô hình đã đề xuất sử dụng tiếp cận từ trên xuống (top-down approach) để ước lượng, ví dụ như mô hình nổi tiếng COCOMO Các mô hình sử dụng điểm chức năng thay vì LOC làm đơn vị kích thước mã nguồn cũng đã được xây dựng Trong các

mô hình này, được xác định thêm các yếu tố khác (có ảnh hưởng đến nỗ lực) để điều chỉnh lại các ước lượng dựa trên các yếu tố này Đây là tiếp cận được thực hiện trong

mô hình COCOMO model Một tiếp cận khác là điều chỉnh kích thước mã nguồn của

hệ thống dựa trên các thông số (parameters), như đã được thực hiện trong điểm chức năng (Function points)

Trong tiếp cận từ dưới lên (bottom-up approach), trước tiên thực hiện các ước lượng cho các phần của dự án và sau đó ước tính cho tổng thể dự án Tức là, ước lượng tổng thể của dự án được suy ra từ các ước lượng của các bộ phận của nó Một tiếp cận từ dưới lên được gọi là ước lượng dựa trên các hoạt động

Trong chiến lược này, trước hết các hoạt động chính được liệt kê ra, và sau đó nỗ lực cho từng hoạt động được ước lượng Từ những ước lượng này, bạn thu được nỗ lực cho toàn bộ dự án

Tiếp cận ước lượng từ dưới lên là ước lượng trực tiếp (ước lượng ngay) nỗ lực, một khi dự án được phân chia thành các công việc hoặc nhiệm vụ nhỏ hơn thì việc ước lượng trực tiếp nỗ lực cần thiết cho chúng là điều có thể Mặc dù kích thước đóng một vai trò quan trọng trong việc xác định các nỗ lực cho các hoạt động trong một dự án,

nhưng lợi thế của tiếp cận từ dưới lên là nó không cần ước lượng kích thước cho phần mềm Thay vào đó, nó đòi hỏi một danh sách các công việc hoặc nhiệm vụ trong dự án

có thể được chuẩn bị dễ dàng hơn

Một rủi ro của tiếp cận từ dưới lên là có thể bỏ qua một số hoạt động quan trọng trong danh sách các công viêc hoặc nhiệm vụ Khi nỗ lực được ước lượng trực tiếp cho các công việc hoặc nhiệm vụ, khó có thể ước lượng cho các công việc hoặc nhiệm vụ về quản lý, chẳng hạn như quản lý dự án trong suốt chu kỳ sống, đây là các công việc không được xác định rõ ràng như cài đặt mã hoặc kiểm thử

Cả hai tiếp cận từ trên xuống và từ dưới lên điều cần các thông tin về dự án: kích thước (đối với tiếp cận từ trên xuống) và một danh sách các công viêc hoặc nhiệm vụ (đối với tiếp cận từ dưới lên) Bằng nhiều cách, những tiếp cận này có thể bổ sung cho nhau Cả hai loại ước lượng sẽ cho kết quả chính xác hơn nếu thông tin về dự án có được biết nhiều hơn Ví dụ, ước lượng kích thước từ các yêu cầu ở mức cao (high level requirements) thì khó hơn nhiều so với ước lượng kích thước khi đã thiết kế (design) xong, và thậm chí sẽ dễ dàng hơn và chính xác hơn khi mã (code) đã được phát triển Như vậy, độ chính xác của ước lượng phụ thuộc vào thời điểm mà tại đó nỗ lực ước lượng, và độ chính xác sẽ tăng khi có thêm thông tin về dự án được biết

II TIẾP CẬN MÔ HÌNH ƯỚC LƯỢNG NỖ LỰC PHÁT TRIỂN

PHẦN MÊM COCOMO II

Mô hình CoCoMo II là một trong những mô hình ước lượng chi phí, nỗ lực sử dụng phương pháp tiếp cận ước lượng từ trên xuống Trong mô hình này, đơn vị tính của ước lượng nỗ lực(PM) là người-tháng Một người tháng là thời gian mà một người dành thời gian đó làm việc cho dự án phát triển phần mềm trong một tháng Thời gian này là không kể các ngày lễ và ngày nghỉ mà chỉ tính đến thời gian nghỉ cuối tuần Số tháng người khác với số tháng thời gian nó sẽ mất để hoàn thành dự án, đây được gọi

là tiến độ phát triển Phương trình tổng quát của mô hình CoCoMo II:

E: là số mũ, cho phép phân chia quy mô phụ thuộc vào năm trình điều khiển quy mô dự án theo công thức (1.2)

: Là nhân tố nỗ lực của trình điều khiển chi phí

Phương trình (1.1) là mô hình tổng quát nhất cho mô hình ước lượng nỗ lực, chi phí thiết kế và hậu thiết kế Đầu vào là kích thước mã nguồn, một hằng số A, B và các

của module phần mềm sẽ tạo thành chương trình ứng dụng Nó cũng có thể được ước tính từ các điểm chức năng không điều chỉnh (UFP), được chuyển đổi sang SLOC sau

đó chia cho 1000 Và cuối cùng là các nhân tố nỗ lực của trình điều khiển chi phí , bao gồm 17 nhân tố nỗ lực về sản phẩm phần mềm, nền tảng, nhân sự, và dự án Trong phương trình (1.1), hệ số mũ E được tính theo công thức sau:

E = B + 0.01 * (1.2)

Trong đó

B = 0,91 (B là hằng số)

: Các yếu tố quy mô

Với E <1.0, thì ước lượng nỗ lực của dự án sẽ giảm dần theo các yếu tố quy mô Nếu kích thước mã nguồn (SIZE) của dự án tăng lên gấp đôi, thì nỗ lực của dự án sẽ ít hơn gấp đôi Do đó, năng suất của dự án tăng lên khi các yếu tố quy mô của dự án tăng lên

Với E = 1.0, thường được sử dụng để ước lượng chi phí các dự án nhỏ, và được sử dụng cho mô hình CoCoMo II Applications Composition

Với E > 1.0, thì việc ước lượng nỗ lực, chi phí dành cho các dự án lớn hơn và các

dự án này sẽ có thêm nhân lực Do đó, sẽ có nhiều mối quan hệ tiêu cực hoặc tích cực giữa các cá nhân cũng làm ảnh hưởng đến dự án phát triển phần mềm

Ngoài ước lượng nỗ lực, chi phí cho dự án thì việc ước lượng thời gian phát triển

dự án cũng rất quan trọng và được các nhà quản lý dự án rất quan tâm Bởi vì, việc ước lượng thời gian phát triển để kết thúc dự án đúng thời hạn thì được xem như đảm bảo tiến độ hoàn thành dự án mà khách hàng mong đợi, hạn chế được rủi ro ngoài ý muốn Ngược lại, nếu không ước lượng thời gian phát triển dự án thì không có cơ sở

để lập lịch cho dự án dẫn đến việc kết thúc dự án không đúng thời hạn, rủi ro và phát sinh chi phí tăng cao, sức ép về tiến độ gây căng thẳng và có thể phá vỡ những quy định trong dự án v.v Đó là một trong những nguyên nhân dẫn đến dự án thất bại, không có khả thi Vì vậy, ước lượng thời gian để kết thúc dự án đúng hạn là một trong

những thách thức lớn Trong mô hình CoCoMo II, công thức ước lượng thời gian được tính từ nỗ lực của dự án

Trong mô hình CoCoMo II, các công thức (1.1), (1.2), (1.3), điều là tuyến tính, đầu

ra là các ước lượng nỗ lực, chi phí và thời gian phụ thuộc vào các giá trị đầu vào như kích thước mã nguồn, các yếu tố về chi phí và quy mô của dự án Đối với đầu vào là các hệ số A, B, C và D trong mô hình này là một hằng số Tuy nhiên trong thực tế có nhiều kiểu dự án khác nhau và tùy thuộc vào từng khu vực nên các hệ số này thay đổi

Do đó, đầu ra của việc ước lượng nỗ lực cho các dự án phát triển phần mềm sẽ thay đổi theo

Mô hình CoCoMo II được phát triển vào năm 1995, là một mô hình cho phép ước tính chi phí, nỗ lực và tiến độ lập kế hoạch cho một hoạt động phát triển mới phần mềm Được kế thừa và khắc phục những hạn chế của mô hình CoCoMo ban đầu ra đời

1981 Những yếu tố cơ bản tạo nên mô hình CoCoMo II :

- Thứ nhất, không giống như mô hình CoCoMo ban đầu, các dự án phần mềm hiện tại và trong tương lai sẽ được điều chỉnh bởi các trình điều khiển quá trình của nó Những trình điều khiển quá trình bao gồm COTS hoặc khả năng sử dụng lại phần mềm, mức độ hiểu biết về kiến trúc và yêu cầu tình hình thị trường hoặc các hạn chế lịch biểu khác, kích thước và yêu cầu độ tin cậy

- Thứ hai, mức độ chi tiết của mô hình ước lượng nỗ lực phần mềm được sử dụng cần phải nhất quán với mức độ chi tiết thông tin có sẵn để hỗ trợ ước lượng nỗ lực phần mềm Trong giai đoạn đầu của một dự án phát triển phần mềm, hầu như không được biết trước về kích thước mã nguồn của phần mềm sẽ được phát triển, bản

chất của nền tảng, bản chất của nhân viên tham gia dự án, hoặc chi tiết cụ thể của quá trình sẽ được sử dụng

Hình 1.1: Chi phí phần mềm và xác định độ chính xác so với giai đoạn

Trong hình trên, cho thấy rằng hiệu quả của sự không khả thi trong các dự án về

độ chính xác của kích thước phần mềm và ước tính chi phí, nỗ lực Trong giai đoạn đầu, chúng ta không thể biết bản chất cụ thể của sản phẩm phần mềm được phát triển tốt hơn Khi vòng đời dự án được tiến hành và quyết định sản phẩm được thực hiện, bản chất của sản phẩm và kết quả kích thước của nó được biết đến nhiều hơn, kết quả bản chất của quá trình này và các trình điều khiển chi phí của nó được biết đến nhiều hơn

- Thứ ba, mô hình CoCoMo II cung cấp ba giai đoạn tương ứng với ba mô hình phụ

để ước lượng chi phí, nỗ lực trong phát triển phần mềm như sau

 Mô hình Applications Composition: Liên quan đến các nỗ lực tạo mẫu để giải quyết tiềm năng các vấn đề có độ rủi ro cao như về giao diện người dùng, tương tác với phần mềm hoặc hệ thống, công nghệ trưởng thành Chi phí của loại hình nỗ lực này được đánh giá tốt nhất bởi ứng dụng mô hình Applications Composition

 Mô hình Early Design: Mô hình liên quan đến việc xem xét, thăm dò phần mềm hoặc hệ thống kiến trúc thay thế và khái niệm về hoạt động sử dụng các điểm chức năng

 Mô hình Post-Architecture: Liên quan đến sự phát triển và duy trì thực tế của một sản phẩm phần mềm Mô hình này có hiệu quả về chi phí nếu chu

kỳ sống phần mềm đã được phát triển, xác nhận đối hệ thống hoạt động rủi ro và được thiết lập làm khuôn khổ cho sản phẩm phần mềm Nó sử dụng hướng dẫn nguồn hoặc chức năng điểm cho kích thước mã nguồn và một bộ tham số gồm 17 các yếu tố của trình điều khiển chi phí, 5 yếu tố quy mô của dự án

1 Các yếu tố quy mô của dự án

Trong công thức (1.2) dùng để tính toán hệ số mũ E được sử dụng trong phương trình 1.1 Việc lựa chọn các yếu tố quy mô dự án dựa trên cơ sở lý luận rằng chúng là một nguồn đáng kể biến thể hàm mũ trên một nỗ lực của dự án hoặc biến thể năng suất Mỗi yếu tố quy mô có một loạt các cấp độ đánh giá, từ rất thấp đến cao nhất Mỗi cấp độ đánh giá có trọng lượng SF, và giá trị cụ thể của trọng lượng đó được gọi là một yếu tố quy mô Một yếu tố quy mô của dự án là tổng của tất cả các yếu tố, được sử dụng để xác định số mũ E thông qua công thức (1.2) Các yếu tố quy mô SF được thể hiện trong bảng sau:

Bảng 1.1: Các yếu tố quy mô trong mô hình COCOMO II

có

Gần như chưa từng

có

Nói chung quen thuộc

Phần lớn quen thuộc

Quen thuộc

FLEX nghiêm

ngặt

Thỉnh thoảng không nghiêm ngặt

một số không nghiêm ngặt

Sự phù hợp chung

một số phù hợp

Mục tiêu chung

(40%)

Thường (60%)

Nói chung (75%)

Chủ yếu (90%)

Đầy đủ (100%)

tương tác

rất khó

Một số tương tác khó

Về cơ bản tương tác hợp tác

Chủ yếu hợp tác

Gắn kết cao

Tương tác gắn kết chặt chẽ

PMAT Đánh giá, xếp hạng quá trình trưởng thành có tổ chức dựa trên CMM

1.1 Tính tiên phong (PREC) và Tính linh hoạt trong phát triển (FLEX)

Hai yếu tố quy mô này thể hiện được sự khác biệt của mô hình COCOMO gốc [Boehm 1981] Bảng 1.2 dưới đây, tổ chức lại [Boehm 1981, Bảng 6.3] để lập bản đồ các đặc trưng của dự án lên tính tiên phong và tính linh hoạt

Bảng 1.2: Các yếu tố quy mô liên quan đến các phương thức phát triển COCOMO II

bình/ cao

Cao nhất Tính tiên phong

Sự hiểu biết về tổ chức các mục tiêu sản phẩm

Tính linh hoạt phát triển

Cần phải tuân theo phần mềm với các thiết lập

sẵn yêu cầu

bản Cần phải tuân thủ với phần mềm bên ngoài thông

số giao diện

bản

1.2 Kiến trúc giải quyết rủi ro (RESL)

Yếu tố này kết hợp hai yếu tố quy mô trong Ada COCOMO, "Thiết kế toàn vẹn bởi PDR" Và "Xoá bỏ rủi ro bởi PDR" Bảng 1.3 củng cố xếp hạng Ada COCOMO để tạo thành một định nghĩa toàn diện hơn cho các mức đánh giá của RESL trong mô hình COCOMO II

Kế hoạch quản lý rủi

Nói chung

Chủ yếu

Nói chung

Chủ yếu

Có ý nghĩa

Phần trăm phần mềm bắt buộc nhà thiết kế sẵn sàng cho dự án

1.3 Sự gắn kết đội (TEAM)

Hệ số cân bằng nhóm cho các nguồn của sự bất ổn của dự án do những khó khăn trong đồng bộ hóa các bên liên quan của dự án như người sử dụng, khách hàng, nhà phát triển, người duy trì, giao diện, những người khác Những khó khăn này có thể phát sinh từ sự khác biệt về mục tiêu và văn hoá của các bên liên quan, khó khăn trong việc đối chiếu các mục tiêu, sự thiếu hụt của các bên liên quan kinh nghiệm và sự quen thuộc trong hoạt động như một nhóm Bảng 1.3 cung cấp một định nghĩa chi tiết cho các mức đánh giá TEAM tổng thể Đánh giá cuối cùng là trung bình trọng số của các đặc điểm được liệt kê trong bảng 4

Bảng 1.4: Thành phần đánh giá của đội

Tính nhất quán của

các bên liên quan

mục tiêu và văn hoá

Kinh nghiệm của các

bên liên quan trong

1.4 Quy trình trưởng thành (PMAT)

Thủ tục xác định PMAT được tổ chức xung quanh mô hình trưởng thành năng lực của viện kỹ thuật phần mềm (CMM) Khoảng thời gian để xếp hạng quá trình trưởng thành là thời gian bắt đầu dự án Có hai cách đánh giá quá trình trưởng thành Kết quả đầu tiên ghi lại kết quả của một đánh giá có tổ chức dựa trên CMM Nhìn chung mức

độ trưởng thành được tính từ mức độ 1 đến mức độ 5 Kết quả thứ hai được tổ chức xung quanh 18 tiêu chí về quy trình chính (KPAs) trong mô hình trưởng thành năng lực SEI [Paulk et al 1993, 1993a] Thủ tục xác định PMAT là quyết định tỷ lệ tuân thủ của mỗi KPA Nếu dự án đã trải qua một đánh giá CMM gần đây thì tỷ lệ tuân thủ cho KPA tổng thể (dựa trên KPA Key Practice Dữ liệu đánh giá tuân thủ) được sử dụng Nếu đánh giá chưa được thực hiện thì mức độ tuân thủ các mục tiêu của KPA là được sử dụng

PMAT = 5 – (1.4)

2 Các nhân tố nỗ lực của trình điều khiển chi phí

Đây là 17 nhân tố nỗ lực được sử dụng trong mô hình COCOMO II Post Architecture, để điều chỉnh nỗ lực ước lượng người tháng, được phản ánh trên các sản phẩm phần mềm đang phát triển Chúng được chia thành bốn loại: sản phẩm phần mềm, nền tảng, nhân sự, và dự án Bất cứ khi nào đánh giá của trình điều khiển chi phí

là giữa các cấp xếp hạng luôn luôn đúng với xếp hạng ước lượng

2.1 Yếu tố sản phẩm phần mềm

2.1.1 Độ tin cậy phần mềm

Yêu cầu độ tin cậy của phần mềm (RELY) đây là thước đo mức độ mà phần mềm phải thực hiện chức năng dự định trong một khoảng thời gian Nếu kết quả thất bại của phần mềm nhỏ thì RELY là thấp và nếu sự thất bại có nguy cơ cao thì RELY

Trung bình,

dễ dàng thu hồi được vốn

Mất mát tài chính cao

Nguy cơ ảnh hưởng mất vốn

2.1.2 Kích thước dữ liệu (DATA)

Yếu tố về kích thước dữ liệu (DATA) được xây dựng để nắm bắt các yêu cầu về

số liệu lớn đối với việc phát triển sản phẩm Bởi vì, kích thước cơ sở dữ liệu rất quan trọng để xem xét nó và những nỗ lực cần thiết để tạo ra dữ liệu thử nghiệm sẽ được sử dụng để thực hiện chương trình Xếp hạng được xác định bởi tính D / P

= (1.5)

DATA được đánh giá thấp nếu D / P nhỏ hơn 10 và rất cao nếu nó lớn hơn 1000

Bảng 1.6: Kích thước số liệu DATA

Bảng 1.7: Tính phức tạp của sản phẩm CPLX

Hoạt động

kiểm soát

Tính toán các hoạt động

Phụ thuộc vào các hoạt động của thiết bị

Quản lý dữ liệu các hoạt động

Giao diện người dùng

Ví dụ, A = B + C * (D-E)

Đọc, viết báo cáo với định dạng đơn giản

Các mảng đơn giản trong bộ nhớ chính, đơn giản truy vấn COTS-DB, Cập nhật

Đơn giản các mẫu đầu vào

Không cần thiết bộ vi

xử lý cụ thể hoặc đặc điểm thiết bị vào, ra thực hiện ở mức GET / PUT

Tách tập tin đơn với thay đổi cấu trúc

dữ liệu, không

có chỉnh sửa, không có tệp trung gian

Các truy vấn COTS-DB phức tạp vừa phải

Sử dụng các trình xây dựng đồ hoạ (GUI) đơn giản

kê Hoạt động ma trận, vector

cơ bản

Xử lý vào,

ra bao gồm lựa chọn thiết bị, kiểm tra trạng thái

và xử lý lỗi

Nhập nhiều tập tin và đầu

ra tập tin duy nhất Thay đổi

cơ cấu đơn giản, chỉnh sửa đơn giản

Đơn giản sử dụng bộ tiện ích

Cao Toán tử lập cấu

đa biến, phương trình

vi phân bình thường

Các thao tác

ở mức vào,

ra vật lý (bản dịch địa chỉ

bộ nhớ vật

lý, tìm kiếm, đọc, v.v )

Tối ưu hóa vào, ra chồng lên nhau

kích hoạt bởi các nội dung luồng dữ liệu

Tái cấu trúc

dữ liệu phức tạp

Phát triển và

mở rộng

bộ dụng

cụ Đơn giản bằng giọng nói vào,

ra, đa phương tiện

ma trận gần nhất, một phần Phương trình vi phân

Các quy trình chẩn đoán gián đoạn, phục

vụ, che giấu

Giao tiếp đường dây

xử lý Hiệu suất cao các

hệ thống nhúng

Phân phối cơ

sở dữ liệu phối hợp Trật

tự phức tạp

Tối ưu hóa tìm kiếm

Phức hợp 2D / 3D phức tạp, đồ họa động, đa phương tiện

Phân phối kiểm

soát thời gian

thực khó khăn

Phân tích số liệu khó và không có cấu trúc: Phân tích chính xác cao các

dữ liệu nhiễu, ngẫu nhiên

Các thao tác lập trình mã hoá phụ thuộc vào thời gian thiết bị.Hiệu suất hệ thống nhúng quan trọng

Kết hợp cao, năng động, quan hệ và cấu trúc đối tượng Quản

lý dữ liệu ngôn ngữ tự nhiên

Đa phương tiện phức tạp, thực

tế ảo

2.1.4 Yêu cầu khả năng sử dụng lại (RUSE)

Yêu cầu khả năng sử dụng lại là một yếu tố được bổ sung cần thiết để xây dựng

các thành phần dự định để sử dụng lại trên hiện tại hoặc tương lai dự án RUSE được

sử dụng với việc tạo ra thiết kế chung chung hơn của phần mềm, tài liệu phức tạp hơn,

và nhiều hơn nữa thử nghiệm rộng rãi để đảm bảo các thành phần đã sẵn sàng để sử dụng trong các ứng dụng khác

Bảng 1.8: Yêu cầu khả năng sử dụng lại

Rất

thấp

Thấp Trung

bình

dự án

Dựa trên chương trình

Dựa trên dòng sản phẩm

Dựa trên nhiều sản phẩm

2.1.5 Tài liệu phù hợp với nhu cầu của vòng đời (DOCU)

Một số mô hình ước tính chi phí phần mềm có xây dựng tài liệu phù hợp với nhu cầu của vòng đời Trong COCOMO II, thang điểm đánh giá của DOCU được đánh giá dựa trên sự phù hợp của tài liệu dự án với nhu cầu chu kỳ sống của nó Đánh giá quy

mô từ Very Low (rất thấp nhu cầu của chu kỳ sống) đến Very High (rất cao đối với nhu cầu của chu kỳ sống)

Bảng 1.9: Tài liệu phù hợp với nhu cầu của vòng đời (DOCU)

mở ra

Vòng đời nhu cầu

Quá mức cho vòng đời nhu cầu

Rất quá mức cho vòng đời nhu cầu

2.2 Yếu tố nền tảng

Yếu tố này được đề cập đến máy tính, mục tiêu của phần cứng và phần mềm cơ sở

hạ tầng Các yếu tố đã được sửa đổi để phản ánh đến các đề cập trên như đã được mô

tả trong phần dưới đây Một số yếu tố nền tảng bổ sung là xem xét, chẳng hạn như phân phối, song song, nhúng, và các hoạt động thời gian thực

2.2.1 Hạn chế thời gian thực hiện (TIME)

Đây là một biện pháp của thời gian để thực hiện hạn chế áp đặt cho một hệ thống phần mềm Đánh giá được thể hiện dưới dạng phần trăm thời gian thực hiện có sẵn dự

kiến sẽ được sử dụng bởi hệ thống hoặc hệ thống con tiêu tốn thời gian thực hiện tài nguyên Mức đánh giá từ ước lượng, ít hơn 50% thời gian thực hiện tài nguyên sử dụng, đến mức cao, 95% tài nguyên thời gian thực hiện được sử dụng

Bảng 1.10: Hạn chế thời gian thực hiện (TIME)

nhất

có sẵn thời gian thực hiện

2.2.2 Hạn chế lưu trữ chính (STOR)

Yếu tố này thể hiện mức độ hạn chế về lưu trữ chính đối với hệ thống phần mềm hoặc hệ thống con Đáng chú ý tăng thời gian thực hiện bộ xử lý có sẵn và lưu trữ chính, người ta có thể đặt câu hỏi liệu các biến ràng buộc này vẫn còn liên quan, thích hợp Tuy nhiên, nhiều ứng dụng tiếp tục mở rộng để tiêu thụ bất kỳ nguồn nào có sẵn, làm cho những chi phí này trình điều khiển vẫn còn có liên quan Xếp hạng dao động

từ ước lượng, ít hơn 50%, đến mức cao 95%

Nền tảng biến động (PVOL) là phức hợp phần cứng và phần mềm (OS, DBMS,

) mà sản phẩm phần mềm gọi đến thực hiện nhiệm vụ của mình Nếu phần mềm được phát triển là một hệ điều hành thì nền tảng này là phần cứng máy tính Nếu một

hệ thống quản lý cơ sở dữ liệu sẽ được phát triển sau đó nền tảng này là phần cứng và

hệ điều hành Nếu một văn bản mạng trình duyệt sẽ được phát triển sau đó nền tảng là mạng, phần cứng máy tính, hệ điều hành và phân phối kho thông tin Nền tảng này bao gồm bất kỳ trình biên dịch hoặc lắp ráp nào hỗ trợ phát triển phần mềm hệ thống Xếp hạng này dao động từ mức thấp khi có sự thay đổi lớn đến 12 tháng, còn xếp hạng ở mức rất cao khi có sự thay đổi khoảng hai tuần

1 tháng

Lớn : 6 tháng Vừa: 2 tuần

Lớn: 2 tháng;

Vừa: 1 tuần

Lớn: 2 tuần;

Nhỏ: 2 ngày

2.3 Yếu tố Nhân sự

2.3.1 Khả năng phân tích (ACAP)

Khả năng phân tích là những nhân viên làm việc theo yêu cầu, thiết kế cấp cao và thiết kế chi tiết Các thuộc tính chính cần được được đánh giá trong đánh giá này là khả năng phân tích và thiết kế, hiệu quả và sự toàn diện, và khả năng giao tiếp và hợp tác Xếp hạng không nên xem xét mức độ kinh nghiệm của nhà phân tích, đó là đánh giá với AEXP Các nhà phân tích rơi vào phần trăm thứ 15 được đánh giá là rất thấp

và những phần nằm trong phần trăm thứ 95 được đánh giá là rất cao

Bảng 1.13: Khả năng phân tích (ACAP)

Phần trăm thứ 55

Phần trăm thứ 75

Phần trăm thứ 90

2.3.2 Khả năng lập trình (PCAP)

Khả năng lập trình (PCAP) đề cập đến tầm quan trọng của các nhà phân tích có năng lực cao Tuy nhiên, vai trò ngày càng phức tạp bởi COTS, sự đòn bẩy năng suất đáng kể liên quan đến khả năng của các lập trình để đối phó với những COTS gói đã cho thấy một xu hướng tầm nhìn quan trọng hơn của khả năng lập trình là tốt Đánh giá nên dựa trên khả năng của các lập trình viên như một đội chứ không phải là các cá nhân Các yếu tố chính cần được xem xét trong đánh giá là khả năng, hiệu quả và triệt

để, khả năng giao tiếp và hợp tác Các kinh nghiệm của các lập trình viên không nên được xem xét ở đây, nó được đánh giá cao với AEXP Một đội lập trình đánh giá cao được đánh giá rất thấp phần trăm thứ 15 và một đội lập trình được xếp hạng rất cao nằm trong phần trăm thứ 95