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

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 kha

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

Công trình được hoàn thành tại TRƯỜNG ĐẠI HỌC BÁCH KHOA

Người hướng dẫn khoa học: TS Lê Thị Mỹ Hạnh

Phản biện 1: TS Đặng Hoài Phương

Phản biện 2: PGS.TS Lê Mạnh Thạnh

Luận văn sẽ được bảo vệ trước Hội đồng chấm Luận văn tốt nghiệp thạc sĩ ngành Khoa học máy tính, họp tại Trường Đại học Bách khoa vào ngày 06 tháng 01 năm 2018

Có thể tìm hiểu luận văn tại:

 Trung tâm Học liệu, Đại học Đà Nẵng tại Trường Đại học Bách khoa

 Thư viện Khoa CNTT, Trường Đại học Bách khoa - ĐHĐN

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 rất phổ biến Tuy nhiên, mô hình này dựa trên một số giá trị tham số không đổi của các phương trình ước lượng Những hằng số này chưa được tối ưu hóa, và do đó tính chính xác của việc ướ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 đượ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” sử dụng thuật toán Cuckoo Search

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

Nghiên cứu và ứng dụng thuật toán CS vào bài toán 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

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 phương pháp ướ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 theo mô hình COCOMO II, 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 các độ đo đá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 giải pháp ứng 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

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

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

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

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 đó là phương pháp ước lượng từ trên xuống và phương pháp ước lượng từ dưới lên

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

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ự

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

: 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 yếu tố quy mô , kích thước mã nguồn (SIZE)

có nguồn gốc từ ước tính kích thướ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ô

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, được các nhà quản lý dự án quan tâm rất nhiều 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

là tháng

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

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 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ư Mô hình Applications Composition, Mô hình Early Design và Mô hình Post-Architecture

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:

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.1 trên, được 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

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 đó là thiết

kế toàn vẹn bởi PDR và xoá bỏ rủi ro bởi PDR

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

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 là rất cao

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

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

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)

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

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

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

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

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

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

Kinh nghiệm ứng dụng (AEXP) được đề cập về trình độ kinh nghiệm ứng dụng của nhóm dự án phát triển hệ thống phần mềm hoặc hệ thống

con Các xếp hạng được xác định dựa trên mức độ kinh nghiệm tương đương của nhóm dự án với loại ứng dụng này Đánh giá rất thấp cho trải nghiệm ứng dụng dưới 2 tháng Đánh giá rất cao là kinh nghiệm từ 6 năm trở lên

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

LTEX một thước đo mức độ ngôn ngữ lập trình và kinh nghiệm công

cụ phần mềm của nhóm dự án phát triển phần mềm hoặc hệ thống con Phát triển phần mềm bao gồm việc sử dụng các công cụ thực hiện các yêu cầu và thiết kế đại diện và phân tích, quản lý cấu hình, trích xuất tài liệu, quản lý thư viện, phong cách chương trình và định dạng, kiểm tra tính nhất quán, v v Ngoài kinh nghiệm trong lập trình với một ngôn ngữ cụ thể công cụ

hỗ trợ thiết lập cũng có hiệu lực thời gian phát triển Đánh giá thấp cho LTEX là ít hơn 2 tháng và đánh giá rất cao cho LTEX là từ 6 năm trở lên

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

PCON là doanh thu hàng năm của dự án: từ 3%, rất cao, đến 48%, rất thấp

2.4 Yếu tố dự án

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

Các công cụ phần mềm đã được đề xuất cho những dự án từ năm

1970 và được sử dụng để hiệu chỉnh mô hình COCOMO Xếp hạng công

cụ này nằm trong khoảng từ việc đơn giản chỉnh sửa mã ở mức rất thấp đến việc tích hợp các công cụ quản lý vòng đời ở mức rất cao

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

Với tần suất ngày càng tăng của sự phát triển đa trung tâm, các dấu hiệu cho thấy hiệu quả phát triển đa quốc gia là rất lớn, yếu tố SITE đã được thêm vào CoCoMo II để xác định mức đánh giá chi phí bao gồm việc đánh giá và tính trung bình, có hai yếu tố đó là sự sắp xếp địa điểm và hỗ trợ truyền thông (từ việc sử dụng Email và điện thoại vào phần mềm một cách đầy đủ)

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

Yếu tố SCED được xây dựng để ràng buộc lịch biểu đối với nhóm dự

án phát triển phần mềm Xếp hạng được xác định trong các điều khoản của

tỷ lệ phần trăm của lịch biểu kéo dài ra cho một dự án yêu cầu một cho số tiền của nỗ lực Giai đoạn tăng tốc có xu hướng tạo ra nhiều nỗ lực hơn trong các giai đoạn phát triển sau này bởi vì vấn đề còn lại sẽ được xác định

do thiếu thời gian để giải quyết chúng sớm hơn Nếu tỉ lệ này giảm xuống 74% thì được đánh giá rất thấp Việc kéo dài thời gian biểu sẽ tạo ra nhiều

nỗ lực hơn trong các giai đoạn phát triển trước đó, khi đó có nhiều thời gian

để làm việc kỹ lưỡng hơn quy hoạch, đặc điểm kỹ thuật và xác nhận Ngược lại tỉ lệ này tăng lên 160% được đánh giá rất cao

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

Tóm lại, trong chương một tôi đã trình bày một cách khái quát và chi tiết nhấ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

I GIỚI THỆU

Các thuật toán tối ưu 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 Ví dụ, thuật toán tối ưu bầy đàn (PSO) được lấy cảm hứng từ trí thông minh của cá và chim, trong khi Firefly Algorithm lấy cảm hứng từ mô hình phát sáng của đom đóm nhiệt đới Các thuật toán tối ưu lấy cảm hứng tự nhiên này đã được sử dụng trong một loạt các vấn đề tối ưu hóa, bao gồm các vấn đề như người bán hàng, đi du lịch v.v

Sức mạnh của hầu hết các thuật toán học hiện đại bắt nguồn từ thực tế là chúng bắt chước tính chất tốt nhất trong tự nhiên, đặc biệt là hệ thống sinh học phát triển từ sự lựa chọn tự nhiên trong hàng triệu năm Hai đặc điểm quan trọng là lựa chọn thích hợp và thích ứng với môi trường Về phương diện tối ưu hóa, chúng có thể được tượng trưng cho hai đặc tính quan trọng của thuật toán hiện đại: tăng cường và đa dạng hóa Tăng cường sự tìm kiếm các giải pháp tốt nhất hiện tại và lựa chọn giải pháp tốt nhất, trong khi