Ước lượng dự án trên cơ sở các ca sử dụng

Trong một hệ thống như vậy, các đặc trưng của tổ chức phát triển như kinh nghiệm, môi trường,… và phần mềm cần phát triển sẽ được mô tả, các ước lượng chi phí và nỗ lực được suy ra các t

1

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

MỤC LỤC

LỜI CAM ĐOAN 4

MỤC LỤC 5

BẢNG CÁC CHỮ VIẾT TẮT 7

DANH MỤC BẢNG BIỂU 9

DANH MỤC HÌNH VẼ 11

MỞ ĐẦU 12

CHƯƠNG 1: TỔNG QUAN VỀ ƯỚC LƯỢNG DỰ ÁN PHẦN MỀM 13

1.1 Khái niệm về ước lượng dự án phần mềm 13

1.2 Ước lượng kích thước 16

1.3 Ước lượng công sức 18

1.4 Ước lượng tài nguyên 20

1.4.1 Tài nguyên con người 20

1.4.2 Tài nguyên phần cứng 20

1.4.3 Tài nguyên phần mềm 21

1.5 Các tiếp cận ước lượng dự án phần mềm 22

CHƯƠNG 2: MỘT SỐ PHƯƠNG PHÁP ƯỚC LƯỢNG DỰ ÁN TRUYỀN THỐNG 23

2.1 Phương pháp Điểm chức năng 23

2.1.1 Giới thiệu 23

2.1.2 Nội dung của phương pháp 24

2.1.3 Đánh giá phương pháp 33

2.2 Các mô hình ước lượng dự án phần mềm 33

2.2.1 Mô hình ước lượng COCOMO 33

2.2.3 Mô hình ước lượng Putnam 38

2.2.4 Công cụ ước lượng tự động 40

2.2.5 Mô hình lập luận theo kinh nghiệm – CBR 42

CHƯƠNG 3: PHƯƠNG PHÁP ƯỚC LƯỢNG DỰ ÁN ĐIỂM CA SỬ DỤNG 45 3.1 Giới thiệu 45

3.2 Cơ sở của UCP 46

3.3 Nội dung phương pháp 47

3.3.1 Tính trọng số tác nhân 49

3.3.2 Tính trọng số ca sử dụng 49

3.3.3 Tính UUCP 50

3.3.4 Gán trọng số các yếu tố kỹ thuật và các yếu tố môi trường 51

3.3.5 Tính UCP 52

3.3.6 Ước lượng nỗ lực 53

3.4 Đánh giá phương pháp và đề xuất cải tiến 54

3.4.1 Ưu điểm của phương pháp ước lượng điểm ca sử dụng 54

3.4.2 Nhược điểm của phương pháp này 54

3.4.3 Hướng cải tiến phương pháp 55

CHƯƠNG 4: PHÁT TRIỂN CHƯƠNG TRÌNH ỨNG DỤNG 58

4.1 Chương trình ứng dụng 58

4.1.1 Môi trường phát triển 58

4.1.2 Các bước tính UCP trong chương trình 58

4.1.3 Thực đơn chính của chương trình 59

4.1.4 Một số giao diện chương trình 60

4.2 Áp dụng phương pháp ước lượng UCP 63

4.2.1 Mô tả yêu cầu nghiệp vụ 63

4.2.2 Yêu cầu hệ thống 70

4.2.3 Tiến trình ước lượng 81

KẾT LUẬN 86

TÀI LIỆU THAM KHẢO 88

PHỤ LỤC 90

P.1 Bảng chi tiết về trọng số và tham số ước lượng 90

P.2 Mô hình COCOMO 94

BẢNG CÁC CHỮ VIẾT TẮT

AA Assessment and Assimilation

AAF Adaptaion Adjustment Factor

AAM Adaptation Adjustment Modifier

ACAP Analyst Capability

ASCII American Standard Code for Information Interchange CBR Case Based Reasoning

CMM Maturity Model

COTS Commercial Off The Shelf

ECF Environment Complexibility Factor

ESLOC Equivalent Source Lines Of Code

FLEX Development Flexibility

FP Function Points

GUI Graphical User Interface

ILF Internal Logical File

KSLOC Thousand of Source Line Of Code

LCA Life Cycle Architecture

LOC Line Of Code

MAF Maintenance Adjustment Factor

MCF Maintenance Change Factor

PA Post – Architecture

PF Productivity Factor

PM Persons – month

PMAT Process Maturity

PREC Precedentedness

RESL Architecture/Risk Resolution

REVL Requirements Evolution and Volatility

RUSE Developed for Reusability

SLOC Source Line Of Code

SMPEEM Software Maintenance Project Effort Estimation Model

SU Software Understanding

TCF Technical Complexibility Factor

TCP/IP Transmission Control Protocol/Internet Protocol

TIME Execution Time Constraint

UAW Unadjusted Actors Weight

UCP Use Case Points

UFP Unadjusted Function Point

UML Unified Modeling Language

UNFM Requirements Evolution and Volatility

UUCP Unadjusted Use Case Point

UUCW Unadjusted Use Case Weight

VAF Value Adjustment Factor

DANH MỤC BẢNG BIỂU

Bảng 2.1 Chi số độ phức tạp với số UFP tương ứng 24

Bảng 3.1 Phân loại tác nhân 49

Bảng 3.2 Bảng phân loại ca sử dụng và trọng số 50

Bảng 3.3 Yếu tố phức tạp kỹ thuật 51

Bảng 3.4 Yếu tố phức tạp môi trường (kinh nghiệm) 52

Bảng 4 1 Bảng thống kê phân loại tác nhân của dự án iCoot 81

Bảng 4.2 Bảng thống kê phân loại ca sử dụng của dự án iCoot 82

Bảng 4.3 Bảng đánh giá các yếu tố phức tạp kỹ thuật dự án iCoot 83

Bảng 4.4 Bảng đánh giá các yếu tố phức tạp môi trường dự án iCoot 84

Bảng P.1 Bảng tính toán điểm chức năng không được điều chỉnh 90

Bảng P.2 Bảng các thừa số điều chỉnh giá trị 90

Bảng P.3 Trọng số các nhóm đặc tính (N = 32) 91

Bảng P.4 Hướng dẫn xác định các tham số cần thiết 92

Bảng P.5 Tham chiếu cho các chức năng 93

Bảng P.6 Bảng tính toán điểm chức năng không được điều chỉnh 93

Bảng P.7 COCOMO cơ sở 93

Bảng P.8 COCOMO trung bình 94

Bảng P.9 Các kiểu chức năng 98

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

Bảng P.11 Bảng chuyển đổi SLOC/UFP 100

Bảng P.12 Các ràng buộc và hướng dẫn xác định tham số phần mềm được thích ứng 103

Bảng P.13 Các giá trị hệ số tỉ lệ SFj cho các mô hình COCOMO II 108

Bảng P.14 Các cấp độ đánh giá tính tiền lệ 109

Bảng P.15 Các cấp độ đánh giá linh hoạt phát triển 109

Bảng P.16 Các cấp độ đánh giá hệ số RESL 110

Bảng P.17 Các thành phần đánh giá hệ số TEAM 111

Bảng P.18 Các mức độ đánh giá PMAT cho Cấp độ thuần thục về quy trình được ước lượng 112

Bảng P.19 Hệ số chi phí RELY 114

Bảng P.20 Hệ số chi phí DATA 114

Bảng P.21 Hệ số chi phí RUSE 115

Bảng P.22 Hệ số chi phí DOCU 116

Bảng P.23 Hệ số chi phí TIME 116

Bảng P.24 Các hệ số STOR 117

Bảng P.25 Hệ số chi phí PVOL 118

Bảng P.26 Hệ số chí phí ACAP 118

Bảng P.27 Hệ số chi phí PCAP 119

Bảng P.28 Hệ số chi phí PCON 119

Bảng P 29 Hệ số chi phí APEX 120

Bảng P.30 Hệ số chi phí PLEX 120

Bảng P.31 Hệ số chi phí TLEX 121

Bảng P.32 Hệ số chi phí TOOL 122

Bảng P 33 Hệ số chi phí SITE 122

Bảng P.34 Hệ số chi phí SCED 123

Bảng P.35 Các hệ số chi phí của mô hình ED và PA 124

Bảng P.36 Hệ số chi phí RELY 126

DANH MỤC HÌNH VẼ

Hình 1.1 Quy trình ước lượng dự án phần mềm 16

Hình 1.2 Phát triển ma trận công sức – chức năng 19

Hình 1.3 Tài nguyên 20

Hình 2.1 Khái niệm về SMPEEME 26

Hình 2.2 Phân bố công sức – điểm lớn 39

Hình 2.3 Chu trình lập luận theo kinh nghiệm 43

Hình 3 1 Tiến trình ước lượng nỗ lực 48

Hình 4.1 Giao diện chương trình ước lượng theo phương pháp UCP (1) 60

Hình 4.2 diện chương trình ước lượng theo phương pháp UCP (2) 61

Hình 4.3 Giao diện chương trình ước lượng theo phương pháp UCP (3) 61

Hình 4.4 Giao diện chương trình ước lượng theo phương pháp UCP (4) 62

Hình 4.5 Giao diện chương trình ước lượng theo phương pháp UCP (5) 62

Hình 4.6 Giao diện chương trình ước lượng theo phương pháp UCP (6) 63

Hình 4.7 Phác thảo giao diện người dùng 1 (tạo một truy vấn tìm kiếm) 70

Hình 4.8 Phác họa giao diện người dùng 2 (xem các kết quả tìm kiếm) 71

Hình 4.9 Phác họa giao diện người dùng 3 (xem thông tin chi tiết) 71

Hình 4.10 Phác họa giao diện người dùng 4 (chọn một tiêu đề chỉ mục) 72

Hình 4.11 Phác họa giao diện người dùng 5 (xem thông tin thành viên) 72

Hình 4.12 Phác họa giao diện người dùng 6 (xem các Thuê) 72

Hình 4.13 Phác họa giao diện người dùng 7 (xem các đặt thuê) 73

Hình 4.14 Phác họa giao diện người dùng 8 (thay đổi mật khẩu) 73

Hình 4.15 Biểu đồ ca sử dụng hệ thống 75

MỞ ĐẦU

Ước lượng giá cho một dự án phần mềm luôn là bài toán khó cho những người phát triển phần mềm Nhưng để triển khai một dự án phần mềm, thì bài toán đầu tiên là ước lượng giá và thời gian thực hiện dự án Ước lượng giá thấp

và thời gian thực hiện ngắn dễ gặp rủi ro và dẫn đến thất bại Ước lượng quá cao thì có nguy cơ phải từ bỏ dự án vì không đủ nguồn lực Đây là một bài toán luôn đặt ra mỗi khi cần phát triển một dự án phần mềm và là một thách thức nói chung cho ngành công nghiệp phát triển phần mềm vì tính đa dạng và phức tạp của nó Trong điều kiện phương pháp phát triển phần mềm hướng đối tượng phát triển mạnh mẽ chục năm lại đây, việc ước lượng các dự án phần mềm phát triển theo hướng này càng đòi hỏi có một phương pháp ước lượng thích hợp Vì những lý do trên mà đề tài ”Ước lượng dự án phần mềm trên cơ sở các ca sử dụng” được chọn làm đề tài luận văn của tôi

Mục tiêu của đề tài là đi sâu nghiên cứu các phương pháp ước lượng dự án phần mềm, đặc biệt những phương pháp được quan tâm trong thời gian gần đây Làm rõ cơ sở khoa học và thực tiễn của chúng, những kinh nghiệm áp dụng, so sánh những ưu và nhược điểm của mỗi phương pháp và đề xuất cải tiến cho trường hợp dự án phần mềm hướng đối tượng Tiếp đó xây dựng một chương trình thử nghiệm cho phương pháp mới nhất và áp dụng để đánh giá một dự án

đã cho nhằm trợ giúp cho việc triển khai các dự án phần mềm hướng đối tượng, đồng thời làm rõ những ưu điểm và hạn chế của phương pháp

Luận văn chia làm bốn chương:

Chương I: trình bày tổng quan về ước lượng dự án phần mềm

Chương II: trình bày một số phương pháp ước lượng dự án phần mềm truyền thống, đặc biệt là phương pháp COCOMO

Chương III: trình bày phương pháp ước lượng dự án “điểm ca sử dụng”, dành riêng cho các dự án phần mềm phát triển hướng đối tượng

Chương IV: phát triển chương trình ứng dụng dựa trên phương pháp đã trình bày và thử nghiệm với một ví dụ đã cho

Cuối cùng là tài liệu tham khảo và phụ lục

nó Để có được các ước lượng chi phí và công sức tin cậy, một số tùy chọn sau đây được sử dụng:

 Trì hoãn việc ước lượng tới giai đoạn sau của dự án (có thể đạt được ước lượng chính xác 100% khi dự án đã hoàn tất)

 Dùng các kỹ thuật phân rã để sinh ra ước lượng về chi phí và công sức dự án

 Phát triển mô hình kinh nghiệm cho chi phí và công sức làm phần mềm

 Thu được từ một hay nhiều công cụ ước lượng tự động

Tùy chọn đầu tiên là “hấp dẫn” nhưng lại không thực tế, vì các ước lượng chi phí cần phải được đưa ra ngay từ đầu làm cơ sở cho việc triển khai và quản lý dự

án Ba cách tiếp cận còn lại chỉ có thể cho ước lượng gần đúng đối với dự án phần mềm Có thể áp dụng các kỹ thuật tùy chọn trên nối tiếp nhau, và mỗi tùy chọn dùng như một phép kiểm tra cho tùy chọn khác Bằng cách phân rã một dự

án thành các chức năng chính và các nhiệm vụ kỹ nghệ phần mềm liên quan, việc ước lượng chi phí và nỗ lực có thể được thực hiện theo từng phần, từng bước Các mô hình ước lượng theo kinh nghiệm (dựa trên dữ liệu lịch sử) có thể được dùng như một giải pháp bổ sung và cho một cách tiếp cận ước lượng gần với thực tế Mô hình này có dạng:

d = f(vi)

d: là một trong một số các giá trị ước lượng (như công sức, chi phí, thời gian,…)

vi: các tham biến độc lập được chọn (LOC hoặc FP được ước lượng)

Có các công cụ ước lượng tự động cài đặt cho một hay nhiều kỹ thuật phân

rã (hay mô hình kinh nghiệm) Khi được tổ hợp với một giao diện tương tác người máy, cho phép chọn một tùy chọn thích hợp cho việc ước lượng Trong một hệ thống như vậy, các đặc trưng của tổ chức phát triển (như kinh nghiệm, môi trường,…) và phần mềm cần phát triển sẽ được mô tả, các ước lượng chi phí

và nỗ lực được suy ra các từ dữ liệu này [20]

Một dự án trước khi thực hiện hoặc lập kế hoạch cần phải đánh giá được quy mô của nó, các tài nguyên cần thiết, lịch trình thực hiện với các cột mốc quan trọng như: lập các kế hoạch, kết thúc một giai đoạn, gửi tài liệu, bàn giao… Thông thường thì giá thành và lịch trình thực hiện một dự án thường mang tính rủi ro cao khi không được ước lượng đúng mức Một số trong các lý

Quy trình ước lượng là một quá trình liên tục gồm các hoạt động:

1 Ước lượng kích thước (quy mô phần mềm)

2 Ước lượng chi phí và các nỗ lực

3 Ước lượng lịch trình

4 Ước lượng các tài nguyên

5 Đánh giá rủi ro

6 Kiểm tra/ xác nhận

7 Theo dõi và báo cáo tiến độ

8 Đánh giá và cải tiến quy trình

Các hoạt động ước lượng kích thước, nỗ lực và chi phí cần được thực hiện trước khi xây dựng các kế hoạch Tuy nhiên, việc xây dựng lịch trình thường được bắt đầu thực hiện trước khi hoàn thành tất cả các công việc xác định các nỗ lực Ngoài ra, việc sớm thiết lập bảng phân rã công việc WBS (Work Breakdown Structure) giúp việc phân chia các các công việc thành các phần việc độc lập để có thể lập lịch và sắp thứ tự ưu tiên thực hiện từng phần việc trong điều kiện cụ thể với sự hạn chế về các tài nguyên Sơ đồ tổng quát quy trình ước lượng dự án phần mềm cho ở hình 1.1

Hình 1.1 Quy trình ước lượng dự án phần mềm

1.2 Ước lượng kích thước

Kích cỡ của phần mềm thường được đánh giá bằng số dòng mã lệnh SLOC (Source Lines of Code) hoặc số nghìn dòng mã KSLOC (Thousands of Source Lines of Code) Phần mềm có thể được phát triển bằng cách viết mới hoàn toàn hoặc dùng một hay nhiều môđun có sẵn Do vậy, việc ước lượng bao gồm việc ước lượng các đoạn mã mới cần viết và cả phần sử dụng lại Việc ước lượng kích cỡ có thể được đánh giá qua đơn vị điểm chức năng FP (Function Points) dựa trên các chức năng của phần mềm thường nhận được ngay trong pha tìm hiểu yêu cầu Dòng mã LOC và điểm chức năng FP là những dữ liệu cơ bản để tính ra độ đo hiệu năng phát triển phần mềm

Ước lượng LOC và FP là các kỹ thuật ước lượng tách biệt, nhưng cả hai đều có một số đặc trưng chung Từ một tuyên bố về phạm vi phần mềm, người lập dự án bắt đầu phân rã phần mềm thành các chức năng nhỏ hơn để có thể được áp dụng riêng biệt LOC và FP sẽ được ước lượng cho từng chức năng con Các ước lượng này được tổ hợp lại để tạo ra một ước lượng tổng thể cho toàn bộ

dự án

Các ước lượng LOC và FP phụ thuộc vào mức độ chi tiết của bảng phân rã công việc WBS LOC được ước lượng trực tiếp từ WBS, còn FP được xác định gián tiếp qua số đầu vào, đầu ra, tệp dữ liệu, câu hỏi và giao diện ngoài và sử dụng 14 giá trị điều chỉnh độ phức tạp Fi bằng việc trả lời những câu hỏi sau:

1 Hệ thống có đòi hỏi sao lưu và phục hồi không?

2 Có đòi hỏi trao đổi dữ liệu không?

3 Có chức năng xử lý phân tán không?

4 Có đòi hỏi cao về làm việc tốt không?

5 Hệ thống có chạy trong môi trường mà nặng về vận hành tiện ích không?

6 Hệ thống có đòi hỏi việc vào dữ liệu trực tuyến không?

7 Việc vào dữ liệu trực tuyến có đòi hỏi phải xây dựng thao tác đưa vào và thông qua nhiều màn hình thao tác không?

8 Tệp chính có phải cập nhật trực tuyến không?

9 Đầu vào, đầu ra, tệp, truy vấn có phức tạp không?

10 Xử lý bên trong có phức tạp không?

11 Mã chương trình có được thiết kế để dùng lại không?

12 Việc chuyển đổi và cài đặt có được đưa vào trong thiết kế không?

13 Hệ thống có được thiết kế cho nhiều cài đặt trong các tổ chức khác nhau hay không?

14 Liệu ứng dụng có được thiết kế để làm thuận tiện cho việc thay đổi và dễ dàng cho người dùng không?

Bất kể là tham số ước lượng nào được dùng, người lập kế hoạch dự án về

cơ bản phải đưa ra một phạm vi các giá trị cho từng chức năng được phân rã Bằng cách dùng dữ liệu lịch sử hay trực giác, người lập kế hoạch thường dùng

ba ước lượng cho LOC hay FP là các giá trị lạc quan (a), có thể nhất (m) và bi quan (b)

Ví dụ:

4 E=

6

a m b

Số này cho một sự tin cậy nhất định đối với ước lượng và có thể tính đến phân bố xác suất của nó Tại giai đoạn này, người lập kế hoạch áp dụng một trong hai cách tiếp cận sau:

1 Tất cả giá trị tham số ước lượng của các chức năng con có thể được nhân lên với hiệu năng trung bình lấy từ dữ liệu lịch sử tương ứng với tham số ước lượng

đó Chẳng hạn, giả sử ta đã ước lượng được tổng điểm chức năng là 310 FP và hiệu năng trung bình của FP từ các dự án quá khứ là 5.5 FP/người-tháng thì tổng công sức ước lượng cho dự án sẽ là:

Công sức =310 56

5.5  người-tháng

2 Giá trị ước lượng cho từng chức năng con có thể được nhân với hiệu năng được điều chỉnh dựa vào mức độ phức tạp nhận biết được của các chức năng con: nếu

nó có độ phức tạp trung bình, thì dùng độ đo hiệu năng trung bình Tuy nhiên,

độ đo được điều chỉnh lên hay xuống đối với chức năng con cụ thể tùy thuộc vào độ phức của nó cao hơn hay thấp hơn độ phức tạp trung bình

Các ước lượng này có đúng hay không là điều chưa chắc chắn Vì thế, mọi kỹ thuật ước lượng, cần phải được kiểm tra bằng các cách tiếp cận khác nhau [20]

1.3 Ƣớc lƣợng công sức

Ước lượng công sức là số người-tháng hay người-năm được dùng cho giải pháp của từng nhiệm vụ dự án Giống như kỹ thuật LOC và FP, ước lượng công sức bắt đầu bằng việc phác họa các chức năng phần mềm thu được từ phạm vi

dự án Các nhiệm vụ của kỹ nghệ phần mềm như phân tích yêu cầu, thiết kế, mã hóa và kiểm thử – phải được thực hiện cho từng chức năng

Hình 1.2 Phát triển ma trận công sức – chức năng Những dữ liệu này chứa trong ma trận trung tâm của bảng Tỷ lệ lao động (chi phí/ đơn vị công sức) được áp dụng cho từng nhiệm vụ kỹ nghệ phần mềm Rất có thể là tỷ lệ này sẽ thay đổi theo mỗi loại nhiệm vụ Như thường thấy: nhân viên cấp cao tham gia nhiều vào việc phân tích yêu cầu và thiết kế, còn các nhân viên tập sự (lương thấp) tham gia vào các nhiệm vụ thiết kế chi tiết, mã hóa và kiểm thử

Chi phí và công sức cho từng chức năng và nhiệm vụ kỹ nghệ phần mềm thường được được tính vào lúc cuối Nếu chúng thực hiện độc lập với ước lượng LOC và FP thì ta có hai ước lượng cho chi phí và công sức để so sánh Nếu cả hai tập các ước lượng này có sự phù hợp hợp lý thì ta có lý do để tin rằng, các ước lượng là tin cậy Trong trường hợp ngược lại cần tiến hành thêm các nghiên cứu và phân tích

Những khác biệt lớn của các ước lượng thường do hai nguyên nhân:

1 Phạm vi của dự án chưa thích đáng hoặc bị hiểu sai

2 Dữ liệu về hiệu năng lập mã được dùng là không thích hợp đối với ứng dụng hiện tại, do đã lạc hậu hoặc đã bị hiểu sai

Người lập kế hoạch phải xác định được nguyên nhân của sự khác biệt để củng

cố lại ước lượng

1.4 Ƣớc lƣợng tài nguyên

Hình 1.3 mô tả các tài nguyên cần có cho phát triển phần mềm Các công

cụ – phần cứng và phần mềm – cần phải có để hỗ trợ cho sự phát triển Ở mức cao hơn, tài nguyên chính là con người Mỗi tài nguyên đều được xác định với bốn thuộc tính: mô tả tài nguyên, tính có sẵn, thời gian cần có, thời hạn tài nguyên được sử dụng Hai đặc trưng cuối có thể xem như cửa sổ thời gian

Hình 1.3 Tài nguyên

Tính sẵn có của tài nguyên đối với một cửa sổ phải được thiết lập ở giai đoạn thực hành sớm nhất

1.4.1 Tài nguyên con người

Người lập kế hoạch bắt đầu bằng việc ước lượng phạm vi và lựa chọn kỹ năng cần để hoàn thành việc phát triển Các vị trí trong tổ chức (như người quản

lý, kỹ sư phần mềm cấp cao,…), tính chuyên môn (về viễn thông, cơ sở dữ liệu,

bộ vi xử lý) và số lượng đều phải xác định rõ Với những dự án tương đối nhỏ (1 người-năm hay ít hơn), một người có thể thực hiện tất cả các bước kỹ nghệ phần mềm khi có tư vấn của các chuyên gia Số người cần cho dự án phầm mềm có thể được xác định chỉ khi đã xây dựng được ước lượng nỗ lực phát triển (người-tháng hay người-năm)

1.4.2 Tài nguyên phần cứng

Chúng ta thuờng xem phần cứng như là tiềm năng tính toán Nhưng nó cũng là một phương tiện cho việc phát triển và vận hành phần mềm Có ba loại

phần cứng cần phải được xem xét tới khi lập kế hoạch dự án phần mềm: hệ thống phát triển, máy đích và các phần tử khác của hệ thống mới

Hệ thống phát triển là một máy tính và các thiết bị ngoại vi có liên quan sẽ được dùng cho phát triển phần mềm Nó có thể hỗ trợ cho nhiều người dùng, duy trì khối lượng thông tin lớn để dùng chung và hỗ trợ phong phú về công cụ phần mềm Vì phần lớn các tổ chức phát triển đều có nhiều vị trí cần truy nhập vào hệ thống này nên người lập kế hoạch phải mô tả cẩn thận cửa sổ thời gian cần thiết và kiểm chứng rằng tài nguyên đã sẵn sàng

1 Nếu phần mềm hiện có đáp ứng được yêu cầu thì hãy dùng nó, và chi phí để có được chúng bao giờ cũng phải ít hơn chi phí để phát triển một phần mềm tương

tự

2 Nếu phần mềm hiện có đòi hỏi phải sửa đổi trước khi được tích hợp với hệ thống thì chi phí để sửa đổi nó phải nhỏ hơn chi phí phát triển phần mềm tương đương Trong thực tế, các tài nguyên phần mềm lại hay bị bỏ qua trong khi lập kế hoạch Cần xác định sớm yêu cầu tài nguyên phần mềm, nhờ đó, việc đánh giá

kỹ thuật cho các phương án có thể được tiến hành và thu được kết quả đúng hạn

1.5 Các tiếp cận ƣớc lƣợng dự án phần mềm

Việc ước lượng các dự án phần mềm có một số cách tiếp cận khác nhau, và tương ứng với mỗi cách tiếp cận đó là những phương pháp ước lượng tương ứng

Tiếp cận theo định hướng phát triển phần mềm có:

 Phát triển phần mềm định hướng cấu trúc Theo định hướng này, ta có mô hình COCOMO, mà cơ sở của nó là tính điểm chức năng của các chức năng phần mềm [13]

 Phát triển phần mềm định hướng đối tượng, ta có phương pháp điểm ca sử dụng, mà cơ sở của nó là tính điểm ca sử dụng dựa trên đặc tả yêu cầu bằng các

ca sử dụng [1]

 Phát triển phần mềm theo hướng hình thức hóa Hiện chưa có nhiều dự án được phát triển theo hướng này, nên phương pháp ước lượng dự án phần mềm chủ yếu dựa trên kinh nghiệm dữ liệu các dự án đã có, nên chưa có phương pháp ước lượng được thừa nhận

 Một số phương pháp đưa ra có tính chất nghiên cứu nhiều hạng mục áp dụng rất hạn chế

CHƯƠNG 2: MỘT SỐ PHƯƠNG PHÁP ƯỚC LƯỢNG

DỰ ÁN TRUYỀN THỐNG

2.1 Phương pháp Điểm chức năng

Điểm chức năng (Function Points – FP) [12] là phương pháp được Allan

Albrecht phát triển và công bố rộng rãi vào năm 1979 Nó cung cấp một độ đo chung và không phụ thuộc vào công nghệ được sử dụng cho phát triển phần mềm FP là một phương pháp chuẩn để tính kích thước phần mềm dựa trên việc phân tích các chức năng mà phần mềm đó thực hiện

2.1.1 Giới thiệu

Mô hình điểm chức năng đã đưa ra các quy tắc, thiết lập các chuẩn cho việc

sử dụng mô hình này một cách rõ ràng Phân tích điểm chức năng (Function Point Analysis - FPA) cung cấp một phương pháp luận chuẩn để ước lượng ứng

dụng phần mềm Xét từ quan điểm người dùng, nó dựa chính vào các yêu cầu của người dùng để xác định hai đại lượng

Kích cỡ các yêu cầu chức năng, được tính bằng cách gán trọng số cho mỗi chức năng đã biết Sau đó tính đại lượng Điểm chức năng chưa điều chỉnh (Unadjusted Function Points- UFP)

Nhân tố giá trị điều chỉnh (Value Adjustment Factor – VAF) Nhân tố này

phản ánh các đặc trưng cụ thể đối với hệ thống phần mềm đang xây dựng như độ phức tạp môi trường, độ phức tạp của ứng dụng, các yêu cầu phi chức năng… Điểm chức năng là thước đo kiểu hàm số để xác định kích thước của phần mềm ứng dụng Nó dựa trên năm hàm logic có thể được người dùng xác định, và chia thành hai kiểu hàm dữ liệu và ba kiểu hàm giao dịch (bảng 2.1) Đối với một ứng dụng, mỗi hàm sẽ được xác định kích thước và mức độ quan trọng, có tính đến các phần tử đặc trưng, ví dụ các tham chiếu tệp hoặc các trường logic [12]

Thấp Trung bình Cao

EIF (Tệp logic bên ngoài) 5 7 10

Bảng 2.1 Chi số độ phức tạp với số UFP tương ứng Các số UFP thu được sẽ kết hợp với hệ số điều chỉnh (VAF) để có được ước lượng cuối cùng của FP Có các công thức riêng được sử dụng cho từng kiểu dự án cụ thể: ứng dụng, dự án phát triển hoặc dự án tăng cường

2.1.2 Nội dung của phương pháp

2.1.2.1 Mô hình điểm chức năng

a Các chức năng trong mô hình

Mô hình điểm chức năng (Function Points Model - FPM) xác định năm kiểu chức năng cơ bản để ước lượng quy mô của phần mềm Hai kiểu chức năng

dữ liệu là các tệp logic trong (Internal Logical File-ILF) và các tệp giao diện ngoài (External Logical File - EIF) và ba kiểu chức năng giao dịch là các đầu vào ngoài (External Input - EI), đầu ra ngoài (External Output - EO) và các truy vấn ngoài (External Query - EQ)

Để lựa chọn mô hình FP, việc tính toán điểm chức năng của bảo trì dự án

và cải tiến phần mềm gồm ba thành phần: (1) chức năng ứng dụng nằm trong phần yêu cầu sử dụng trong dự án, (2) chức năng chuyển đổi, và (3) nhân tố giá trị điều chỉnh (VAF)

Chức năng ứng dụng bao gồm các điểm chức năng được bổ sung, thay đổi

và xóa khi bảo trì dự án Chức năng chuyển đồi bao gồm các điểm chức năng được cấp phát bởi một quá trình chuyển đổi Nhân tố giá trị điều chỉnh (VAF) được tính trên cơ sở tính trọng số của 14 đặc trưng Mức độ ảnh hưởng của một nhân tố có trọng số nằm trong khoảng từ 0 đến 5: từ không ảnh hưởng đến ảnh

hưởng mạnh Công thức tính toán điểm chức năng bảo trì dự án và cải tiến phần mềm được xác định như sau:

EFP = (ADD + CHG + CFP) x VAFa + DEL x VAFb

Trong đó, EFP điểm chức năng cho dự án cải tiến phần mềm, gồm phần bổ sung (ADD), thay đổi (CHG), xóa (DEL), phần không thay đổi (CFP), và các giá trị điều chỉnh VAFa và VAFb

Các tính toán điểm chức năng là một phép đo kích thước phần mềm phù hợp hơn so với cách tính dòng mã lệnh Tuy nhiên, các nhân tố giá trị điều chỉnh (VAF) của mô hình này lấy từ dự án phát triển phần mềm mới Một vài nhân tố giá trị điều chỉnh (VAF) như là truyền dữ liệu, xử lý phân tán và thực thi,… lại không thể áp dụng trong môi trường bảo trì [12]

b Các yếu tố hiệu suất về bảo trì phần mềm

Nhìn chung, các chi phí bảo trì là khó dự toán, vì chúng phụ thuộc vào số lượng sản phẩm, quy trình và các yếu tố tổ chức liên quan đến hiệu suất bảo trì phần mềm

Từ những nghiên cứu về hiệu suất phần mềm (SPR), người ta đã giới thiệu một cách mới để tính các điểm chức năng: Để xử lý tính phức tạp, người ta chia

chúng thành ba phạm vi riêng biệt: Tính phức tạp thuộc về vấn đề, tính phức tạp

mã lệnh và tính phức tạp dữ liệu Nhờ vậy, có thể giảm được nỗ lực để tính toán

Bảng các câu hỏi cũng đã yêu cầu thu thập những thông tin về các đặc tính môi trường, bao gồm cả các ràng buộc kỹ thuật (thời gian đáp ứng, bảo mật, khả năng chịu tải, nền), công cụ và kỹ thuật bảo trì (phương pháp luận phát hiện, các công cụ), các yếu tố liên quan đến nhân sự (số lượng lập trình viên, kinh nghiệm)

c Mô hình ước lượng nỗ lực bảo trì dự án phần mềm

Cấu trúc Mô hình ước lượng nỗ lực bảo trì dự án phần mềm (Software Maintenance Project Effort Estimation Model- SMPEEM) dựa trên các khái

niệm trình bày trong hình 2.1 Trước tiên, ước lượng quy mô của nhiệm vụ bảo trì sử dụng khái niệm của mô hình điểm chức năng Thứ hai, để điều chỉnh điểm chức năng liên quan đến môi trường bảo trì, ở đây giới thiệu khái niệm mới của yếu tố giá trị điều chỉnh (VAF) Các VAF của mô hình này liên quan đến các

nhóm đặc trưng như: kỹ năng của kỹ sư, các đặc tính kỹ thuật và môi trường bảo trì [12]

Hình 2.1 Khái niệm về SMPEEME

d Tính toán các điểm chức năng

Với mỗi loại ứng dụng cần phải đếm các điểm chức năng để ước lượng quy

mô của dự án bảo trì Có 3 loại bảo trì ứng dụng như: bổ sung, thay đổi và xóa Quy tắc đếm điểm chức năng được sử dụng như trong mô hình của tổ chức những người sử dụng điểm chức năng quốc tế (IFPUG)

Một loại bảo trì ứng dụng có thể nằm trong số năm loại chức năng sau: IFL, EIF, EI, EO hay EQ Mỗi loại này được đánh giá riêng biệt về tính phức tạp và được đưa ra những giá trị trọng số từ 3 (đối với EIs đơn giản) đến 15 (đối với ILFs phức tạp) (cụ thể xem bảng P.2 phần phụ lục)

Điểm chức năng không điều chỉnh (FC) được tính bằng cách nhân mỗi tính toán thô với trọng số (W):

*

SoLuongChucNang W CacKieuChucNang



FC =

Trong đó, FC là điểm chức năng và W là trọng số phức tạp của mỗi loại chức năng

e Điều chỉnh các điểm chức năng

Mười yếu tố giá trị điều chỉnh (VAFs) được bổ sung để hiệu chỉnh Trong

mô hình SMPEEM, ba loại VAFs gồm: (1) kỹ sư được coi như là kỳ vọng về

“con người”, (2) tính kỹ thuật được coi là kỳ vọng của sản phẩm, (3) các đặc tính môi trường bảo trì được coi như là kỳ vọng của quy trình

Nhóm đặc tính đầu tiên là kỹ năng của kỹ sư cần thiết cho bảo trì phần

mềm, bao gồm ba yếu tố như: tri thức về miền ứng dụng, hiểu biết ngôn ngữ lập

trình và kinh nghiệm đối với phần mềm hệ thống (OS, DBMS) Các yếu tố này

mô tả mức độ năng lực của nhân viên bảo trì

Nhóm đặc tính kỹ thuật thứ hai chứa đựng bốn yếu tố là: cấu trúc của môđun, tính độc lập của môđun, tính dễ thay đổi/đọc được của ngôn ngữ chương trình và tính có thể dùng lại các môđun Các yếu tố này đại diện cho trạng thái

của các môđun chương trình

Nhóm đặc tính cuối cùng là môi trường bảo trì bao gồm các yếu tố như:

tính cập nhật tài liệu, tuân theo các chuẩn kỹ thuật phần mềm và dễ kiểm thử

Các yếu tố này liên quan nhiều hơn đến quy trình bảo trì Tài liệu phù hợp với các nhu cầu vòng đời, tính thuần thục của quy trình và dễ kiểm thử được tham chiếu như là các yếu tố hiệu năng để giảm chi phí bảo trì

Các yếu tố này được các nhà quản lý dự án bảo trì lựa chọn, nhằm điều chỉnh điểm chức năng sau khi đếm nó Một vài yếu tố liên quan có thể bị loại trừ

do không có hoặc không nhận biết được

f Phương pháp điều chỉnh

Điểm chức năng không điều chỉnh được nhân với giá trị điều chỉnh VAF để tạo ra điểm chức năng cuối cùng Trong mô hình SMPEEM, ba nhóm đặc tính trong số mười VAFs có giá trị trọng số lần lượt cho mỗi nhóm và cho mỗi yếu

100 100 (2.3) Trong đó, Wg và Wf là các giá trị trọng số của mỗi nhóm đặc tính và các yếu tố của chúng VAF nằm trong khoảng từ 0 đến 50 VAF này có thể được sử dụng để điều chỉnh số đếm chức năng chưa được điều chỉnh theo phương trình 2.3 hoặc bằng phương trình 2.4

Trong đó, d là giá trị tuyệt đối của dải điều chỉnh Ví dụ, nếu một tổ chức

dự định điều chỉnh các số đếm chức năng trong khoảng  20%, d của phương

trình 2.4 có thể được thay thế bằng một giá trị tuyệt đối  20 để được phương trình sau:

FP = FC x 0.8 + 0.008 x VAF (2.5)

g Đánh giá nỗ lực bảo trì dự án

Các mô hình ước lượng chi tiết phần mềm thường có một tham số theo luật

số mũ liên quan đến một tỷ lệ khi một dự án phần mềm tăng quy mô Tham số này nhìn chung được thể hiện như số mũ B trong phương trình:

= A x (quymo)Quan hệ giữa nỗ lực bảo trì phần mềm và các FPs có thể được biểu diễn trong phương trình mũ sau:

= a x FP (2.6) Trong đó, các hằng số a và b là các hệ số đã cho từ kết quả thống kê Do vậy, nếu bất kỳ một dự án bảo trì nào đã biết được FP và VAF, thì đều có thể ước lượng nỗ lực bảo trì theo phương trình 2.6

2.1.2.2 Các bước thực hiện

Phương pháp tính số điểm chức năng sử dụng phân tích điểm chức năng [12] được thực hiện qua năm bước dưới đây:

Bước 1: Phân loại và xác định chức năng

a Phân loại chức năng

Các yêu cầu ứng dụng được phân thành các loại chức năng khác nhau, xác định độ phức tạp của nó và gán giá trị điểm chức năng Các loại yêu cầu chức năng là:

1 Các chức năng về dữ liệu

Tệp logic trong (Internal Logical File -ILF) là các tệp dữ liệu logic được ứng dụng

quản lý, ví dụ các bảng của cơ sở dữ liệu Khái niệm “tệp” ở đây cần được hiểu là một nhóm dữ liệu thường được truy cập cùng với nhau

Tệp giao diện với bên ngoài (External Interface File - EIF) là các tệp dữ liệu của hệ

thống khác được ứng dụng truy xuất đến Ví dụ: bảng nhân viên của hệ thống nhân sự được hệ thống kế toán truy xuất đến, nó là EIF của hệ thống kế toán

Các tệp dữ liệu ở đây được xét ở trạng thái tĩnh, nên chúng còn được gọi là kiểu tệp được tham chiếu (FTR’s)

2 Các chức năng về giao dịch

− Các đầu vào ngoài (External Inputs - EI) là các chức năng cập nhập dữ

liệu, có thể liên quan đến một hay nhiều ILF Ví dụ: nhập chứng từ Trong thực tế, một ứng dụng sẽ có một số lượng rất lớn EI Đây là cách để ứng dụng nhận thông tin hoặc thay đổi hành vi

− Các đầu ra ngoài (External Outputs - EO) là các chức năng cung cấp dữ

liệu cho người dùng, thông thường là các báo cáo nghiệp vụ

− Các truy vấn ngoài (External Inqueries - EQ) là các chức năng tra cứu, trợ

giúp, lấy dữ liệu Các chức năng này chỉ cung cấp thông tin chứ không làm thay đổi các tệp

Các chức năng về giao dịch liên quan đến dữ liệu ở trạng thái động

Mỗi yêu cầu của hệ thống thường được xác định ở giai đoạn đầu của tiến trình dự án Các yêu cầu này đều thuộc một trong năm loại chức năng ở trên Do

đó có thể xác định 5 loại chức năng trên của ứng dụng ngay từ giai đoạn đầu

Chú ý:

− Tất cả các tệp hoặc bảng của cơ sở dữ liệu của ứng dụng (kể cả bảng danh mục hay bảng giao dịch) mà có yêu cầu thêm mới/sửa/xóa, đều được coi là ILE, trừ các tệp làm việc (work tệp) hay các tệp tạm trong quá trình tạo báo cáo,

− Tất cả các tệp cơ sở dữ liệu của các ứng dụng khác (thường là các giao diện hoặc bảng) mà ứng dụng đang xét truy xuất đến được coi là các EIF Các ILF của các ứng dụng khác được sử dụng bởi hệ thống cũng được coi là các EIF của hệ thống

− Tất cả các thao tác để nhận dữ liệu từ ngoài hệ thống vào được coi là EI

Dữ liệu có thể là thông tin điều khiển, thông tin tác nghiệp Nếu dữ liệu là thông tin điều khiển, nó không nhất thiết phải là một ILF

− Tất cả các báo cáo nghiệp vụ được coi là EO Các EO không làm thay đổi đến các ILF Chúng là các dữ liệu được sinh ra và đưa ra ngoài phạm vi của ứng dụng

− Tất cả các tiến trình có kết hợp cả dữ liệu vào – ra mà kết quả là dữ liệu được truy vấn ra và không làm thay đổi ILF được gọi là EQ Tất cả các truy vấn nghiệp vụ, trợ giúp cũng được coi là EQ

Để giúp phân biệt rõ ràng hơn giữa EO và EQ, phiên bản 4.1 IFPUG đã có một số thay đổi nhỏ trong cách xác định Đó là, giao dịch có lấy về dữ liệu hoặc cập nhật một ILF thì nó được coi là một EO, ngược lại, nó được coi là một EQ

b Xác định độ phức tạp của chức năng

Để xác định độ phức tạp của mỗi chức năng, phương pháp FPA cung cấp một bảng đối chiếu dựa trên số loại bản ghi sơ cấp (Record Element Types – DET) Dựa trên độ phức tạp, một giá trị theo kinh nghiệm (thấp/trung bình/cao)

sẽ được gán cho mỗi chức năng Các hằng số này được Albrecht xác định dựa trên hàng ngàn dự án mà hãng IBM đã được phát triển và chúng đã được kiểm thử kỹ

Các tham số cần thiết cho việc đánh giá độ phức tạp là:

− Loại bản ghi sơ cấp (Record Element Type -RET)

− Kiểu tệp dữ liệu được tham chiếu (File Type Referenced - FTR)

− Kiểu trường dữ liệu được tham chiếu (Data Element Type - DET)

c Cách xác định độ phức tạp của một loại chức năng

Sau khi xác định các tham số để tính độ phức tạp: RETs, FETs, DETs của mỗi chức năng, sử dụng bảng đối chiếu để quyết định xem chức năng đó có độ phức tạp là thấp/trung bình/cao Độ phức tạp của một chức năng được xác định

từ việc kết hợp các thuộc tính của nó:

− Độ phức tạp của ILF và ELF được xác định dựa trên các RET và DET

− Độ phức tạp của EI, EO và EI được xác định dựa trên các RET và DET

− Riêng trường hợp của EI phải xác định cả Vào và Ra, sau đó lấy giá trị lớn nhất

d Cách gán tổng UFP cho một chức năng

Dựa vào việc phân loại chức năng (xem bảng P.4 phần phụ lục) để gán tổng các điểm chức năng chưa điều chỉnh (UFP) cho mỗi loại chức năng dựa trên độ phức tạp của nó

Bước 2: Tính tổng UFP

Giá trị điểm chức năng được gán cho các chức năng (dựa trên yêu cầu người dùng) thuộc các loại chức năng khác nhau sẽ được cộng lại để tính tổng UFP

UFP = Sum(FP của tất cả các loại chức năng)

Bước 3: Gán mức độ ảnh hưởng cho tất cả các đặc trưng chung

Các đặc trưng chung của hệ thống là các yếu tố ảnh hưởng đến độ phức tạp của việc phát triển, các mục tiêu hiệu năng, cấu hình, độ thân thiện,… Chúng được phân thành 14 đặc trưng khác nhau và có mức độ ảnh hưởng (DI) thuộc một trong 3 loại: Có, Có nhưng ít và Không

Các đặc trưng chung của hệ thống (GSCs) là:

 Trao đổi dữ liệu – Data Communications

 Xử lý dữ liệu phân tán – Distributed Data Processing

 Hiệu năng – Performance

 Cấu hình có tần suất sử dụng lớn – Eieavily Used Configuration

 Tần suất giao dịch – Transaction Rate

 Vào dữ liệu trực tuyến – Online Data Entry

 Hiệu quả sử dụng của người dùng cuối – End User Efficiency

 Cập nhật trực tuyến – Online Update

 Xử lý phức tạp – Complex Processing

 Tính tái sử dụng – Reuseability

 Dễ cài đặt – Installation Ease

 Thao tác dễ dàng – Operation Ease

 Nhiều liên kết – Multiple Site

 Dễ thay đổi – Facilitate Change

Với mỗi GSC, gán giá trị mức độ ảnh hưởng theo các mức:

0 – không có hoặc không ảnh hưởng

Bước 4: Tính các giá trị của các yếu tố điều chỉnh

Các yếu tố điều chỉnh (Value Adjustment Factor – VAF) được tính theo

công thức:

0.65 0.01 *

Với TDI là tổng các giá trị DI của tất cả các yếu tố

Chú ý rằng: giá trị VAF tính được sẽ nằm trong đoạn từ 0.65 đến 1.35, vì nếu tất cả các yếu tố đều có giá trị DI = 5, tổng sẽ là 70 = 14 * 5 và VAF sẽ là 0.65 + 0.01 * 70 = 1.35

Giá trị cực đại của VAF là 1.35

Tương tự, nếu như tất cả các yếu tố đều không ảnh hưởng, DI = 0 Khi đó, VAF = 0.65 Giá trị lý tưởng là TDI = 35 và do đó VAF = 1

Bước 5: Tính tổng FP của ứng dụng

FP = UFP * VAF Các FP được tính dựa trên năm bước ở trên sẽ xác định kích thước của ứng dụng dưới góc độ chức năng mà nó cần phải có Tuy nhiên, để biết được năng suất dưới dạng số FP/người-ngày, mỗi tổ chức phải sử dụng các số liệu thông kê

từ các dự án trên những môi trường tương tự trước đó Kích thước của dự án tính

bằng FP là một độ đo chung không kể đến yếu tố môi trường phát triển cũng như kinh nghiệm của nhóm phát triển [12]

2.1.3 Đánh giá phương pháp

Ưu điểm của phương pháp FP:

1 Độc lập với kỹ thuật và công cụ lập trình

2 Dễ hiểu đối với người dùng

3 Áp dụng được ngay trong giai đoạn đầu của chu trình phần mềm

4 Áp dụng tốt cho các phần mềm hệ thống thông tin quản lý (MIS)

Những khó khăn trong việc sử dụng phương pháp FP:

1 Việc xác định trọng số cho mức độ ảnh hưởng của các yếu tố đặc trưng của hệ thống không có một căn cứ xác định

2 Phương pháp FP không cho thấy mối quan hệ giữa các chức năng trong hệ thống Nếu hệ thống có các chức năng ít có quan hệ với nhau hơn thì đơn giản hơn khi quan hệ giữa các chức năng của nó là phức tạp

3 Đôi khi đánh giá một phần mềm đã được hoàn thành là không chính xác, vì có một số chức năng được thêm vào trong quá trình phát triển, khi đó chúng ta phải sửa đổi lại cả các chức năng khác,…

4 Không thích hợp cho các hệ thống thời gian thực, các hệ thống tính toán phức tạp, đánh giá độ phức tạp một cách chủ quan

2.2 Các mô hình ƣớc lƣợng dự án phần mềm

2.2.1 Mô hình ước lượng COCOMO

Mô hình ước lượng COCOMO (Constructive Cost Model) là mô hình ước lượng chi phí phần mềm do tiến sỹ Barry Boehm đưa ra đầu năm 1981, trong cuốn “Software Engineering Economics” (Kinh tế học kỹ nghệ phần mềm) Phiên bản đầu tiên này của COCOMO còn được gọi là “COCOMO 81” Từ khi

ra đời cho đến nay, mô hình liên tục được nghiên cứu và cải tiến để phù hợp với

sự thay đổi của kỹ nghệ phần mềm Năm 1987, hai phiên bản của mô hình COCOMO là Ada COCOMO và Incremental COCOMO (COCOMO gia tăng) được giới thiệu Trong hai năm tiếp theo 1988 và 1989, mô hình Ada COCOMO được tinh chỉnh Tuy nhiên, điểm nhấn trong sự phát triển của mô hình

COCOMO là vào những năm 1990 khi COCOMO II đã ra đời [13] COCOMO

II là phiên bản chính thức thứ hai đáp ứng được những thay đổi của thực tiễn phát triển phần mềm chuyên nghiệp từ những năm 1970 đến bấy giờ

2.2.1.1 Lợi ích của COCOMO II đối với người dùng

Mô hình COCOMO II có thể trợ giúp cho người dùng:

− Đưa ra quyết định đầu tư hoặc các chính sách tài chính có đòi hỏi nỗ lực phát triển phần mềm

− Thiết lập các ngân sách và lịch biểu, làm cơ sở cho việc lập kế hoạch và kiểm soát

− Ra quyết định, thương lượng hay chọn thỏa hiệp giữa các yếu tố chi phí lịch biểu, chức năng, tính năng hay chất lượng phần mềm

− Đưa ra các quyết định quản lý rủi ro về chi phí và thời gian phát triển

− Quyết định việc phát triển, tái sử dụng, xuất xưởng hoặc mua những phần nào trong một hệ thống phần mềm

− Đưa ra các quyết định kiểm kê đối với những phần mềm kế thừa

− Xác định các chiến lược đầu tư kết hợp để tăng cường năng lực phần mềm của tổ chức, thông qua tái sử dụng, các công cụ, sự thuần thục về quy trình, thuê bên ngoài gia công

− Đưa ra quyết định về cách thức thực hiện một chiến lược nhằm cải thiện quy trình

2.2.1.2 Mục đích của mô hình COCOMO II

Từ những nhu cầu cải tiến và qua những phản hồi của người dùng, mô hình cải tiến COCOMO II được xây dựng với những mục đích sau [13]:

− Mang lại những ước lượng chính xác về chi phí và thời gian cho những dự

án hiện tại và có thể cả trong tương lai

− Cho phép các tổ chức có thể dễ dàng điều chỉnh lại, xác lập hoặc mở rộng COCOMO II để phù hợp hơn với hoàn cảnh cụ thể của họ

− Cung cấp các định nghĩa chi tiết, dễ hiểu về các đầu vào, các đầu ra và các giả định của mô hình

− Cung cấp một mô hình có tính xây dựng

− Cung cấp một mô hình quy chuẩn

− Cung cấp một mô hình tiến triển

AAM =

AA + AAF + (SU x UNFM)

, AAF > 50 100

i = 1

PM = A x Size x EM + PM

5 j j=1

E = B + 0.01 x SF

AT AdaptedSLOC x

i = 1

PM = A x Size x EM + PM

Biểu thức về thời gian phát triển

Phương trình này đã được giới thiệu trong phần 2.2.4

 F NS

Phân loại các mô hình COCOMO [20]

Trong một số cuốn sách về kinh tế kỹ nghệ phần mềm, các mô hình ước lượng phần mềm mang tên COCOMO được sắp thứ tự như sau:

Mô hình 1, COCOMO cở sở là một đơn trị tĩnh tính ra công sức để phát triển phần mềm xem như hàm kích cỡ chương trình được diễn đạt theo số dòng

mã ước lượng

Mô hình 2, COCOMO trung bình tính công sức phát triển phần mềm như một hàm của kích cỡ chương trình và một tập các hướng dẫn chi phí bao gồm các định giá chủ quan về sản phẩm, phần cứng, nhân sự và thuộc tính dự án

Mô hình 3, COCOMO nâng cao tổ hợp tất cả các đặc trưng của các bản trung bình về việc định giá chi phí hướng dẫn ảnh hưởng lên từng bước (phân tích, thiết kế,…) của tiến trình kỹ nghệ phần mềm

COCOMO có thể được áp dụng cho 3 lớp phần mềm sau:

− Mode có cấu trúc: các dự án phần mềm tương đối nhỏ, đơn giản, làm việc

với một tập các yêu cầu ít chặt chẽ (ví dụ: chương trình phân tích nhiệt dùng cho nhóm truyền nhiệt)

− Mode bán cấu trúc: một dự án phần mềm trung bình về kích cỡ và độ phức

tạp, phải đáp ứng các yêu cầu chặt chẽ và kém chặt chẽ (ví dụ: hệ thống xử

lý giao tác cho phần cứng là thiết bị đầu cuối và phần mềm là cơ sở dữ liệu)

− Mode nhúng: một dự án phần mềm phải được phát triển bên trong một tập

phần cứng, phần mềm và các ràng buộc chặt chẽ (như phần mềm kiểm soát bay của máy bay)

Phương trình COCOMO cơ bản có dạng:

E = a (KSLOC) exp(b )

D = c (E) exp(d )

Với E là công sức được áp dụng theo người-tháng, D là thời gian phát triển theo tháng còn KSLOC là số được ước lượng về số dòng mã (biểu diễn theo nghìn dòng) phải bàn giao cho dự án (Hệ số ab và cb và phần mũ bb và db xem trong bảng P.7 phần phụ lục)

Mô hình cơ sở được mở rộng để xem xét một tập các thuộc tính hướng dẫn chi phí có thể được gộp lại thành bốn loại chính:

 Tính dễ thay đổi của môi trường máy ảo

 Thời gian quay vòng cần thiết

Thuộc tính nhân viên:

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

 Khả năng kỹ nghệ phần mềm

 Kinh nghiệm ứng dụng

 Kinh nghiệm máy ảo

 Kinh nghiệm ngôn ngữ lập trình

Thuộc tính dự án:

 Dùng công cụ phần mềm

 Ứng dụng phương pháp kỹ nghệ phần mềm

 Lập lịch phát triển theo yêu cầu

Phương trình COCOMO trung bình có dạng:

E = a (LOC) exp(b ) * EAF

Với E là công sức được áp dụng theo người-tháng còn LOC là số ước lượng về dòng mã phải bàn giao cho dự án (Chi tiết hệ số ai và số mũ bi xem bảng P.8 phần phụ lục)

COCOMO biểu thị cho một mô hình kinh nghiệm toàn diện cho việc ước lượng phần mềm Để minh họa cho việc dùng COCOMO, áp dụng mô hình cơ

sở cho thí dụ phần mềm CAD đã mô tả trước đây Dùng ước lượng LOC được phát triển và hệ số cho trong bảng P.26 để được:

E = 3.0 (LOC) exp(1.12) = 3.0 (33.3)1.12 = 152 người-tháng Giá trị này khá phù hợp với ước lượng được suy dẫn trong các mục trước (ước lượng LOC, FP và công sức)

Để tính thời hạn dự án ta dùng ước lượng công sức được mô tả ở trên:

D = 2.5 (E) exp (0.35) = 2.5 (125)0.35 = 14.5 tháng

Giá trị cho thời hạn dự án giúp cho người lập kế hoạch xác định một số người cần cho dự án:

N = E/D = 152/14.5  11 người Trong thực tế, người lập kế hoạch có thể quyết định dùng bốn người và kéo dài thời hạn dự án tương ứng

Chi tiết về mô hình COCOMO xem P.2 Mô hình COCOMO phần phụ lục

2.2.3 Mô hình ước lượng Putnam

Mô hình ước lượng Putnam là một mô hình đa biến động, giả thiết có một

sự phân bố riêng về nỗ lực trên vòng đời của dự án phát triển phần mềm [20]

Mô hình này đã được suy dẫn từ phân bố lao động thường gặp phải trong các dự

án lớn (công sức tổng cộng khoảng 30 người-năm hoặc hơn) Tuy nhiên, có thể ngoại suy cho các dự án phần mềm nhỏ hơn

Phân bố công sức cho các dự án phần mềm lớn có thể được biểu diễn ở hình 2.2:

Hình 2.2 Phân bố công sức – điểm lớn Đường cong lớn trong hình này có dạng cổ điển lần đầu tiên được Rayleigh

mô tả theo cách vẽ phân tích Dữ liệu kinh nghiệm trên việc phát triển hệ thống

do Norden thu thập, đã được dùng để thay thế cho đường cong Do đó, phân bố công sức được vẽ trên hình còn được gọi là đường cong Rayleigh – Norden Đường cong Rayleigh – Norden có thể được dùng để suy dẫn ra “phương trình phần mềm” đặt quan hệ giữa số các dòng mã bàn giao (câu lệnh gốc) với công sức và thời gian phát triển như sau:

tư liệu, xử lý theo lô), Ck = 8000 cho môi trường phát triển phần mềm tốt (có phương pháp luận, tài liệu thích hợp, xử lý thực hiện tương tác), Ck = 11000 cho một môi trường “tuyệt vời” (công cụ và kỹ thuật tự động hóa) Hằng Ck có thể được suy diễn cho các điều kiện cục bộ dùng dữ liệu lịch sử thu thập từ công thức phát triển quá khứ Bố trí lại phương trình phần mềm trên có thể đi tới một biểu thức cho công sức phát triển K*:

và bảo trì phần mềm, còn td là thời gian phát triển theo năm Phương trình cho công sức phát triển có thể được liên hệ với chi phí phát triển bằng việc bao hàm nhân tố tỷ lệ lao động ($/người-năm)

Mối quan hệ lũy thừa cấp cao cho trong phương trình phần mềm có thể chỉ

ra rằng, sự mở rộng tương đối nhỏ trong ngày bàn giao có thể tạo ra sự tiết kiệm khá lớn cho công sức dùng trong dự án Nói cách khác, mối quan hệ giữa công sức cần dùng và thời hạn bàn giao là phi tuyến cao độ

Người lập kế hoạch dự án phần mềm phải ước lượng ba điều trước khi một

dự án bắt đầu: dự án kéo dài bao lâu, cần bao nhiêu công sức và bao nhiêu người cần tham gia Bên cạnh đó, người lập kế hoạch phải dự kiến các tài

nguyên (phần cứng và phần mềm) sẽ cần tới và rủi ro trong dự án

2.2.4 Công cụ ước lượng tự động

Kỹ thuật phân rã và các mô hình ước lượng kinh nghiệm được mô tả ở các mục trên có thể được cài đặt trong các phần mềm Những công cụ ước lượng tự động hóa này cho phép người lập kế hoạch ước lượng chi phí và công sức và thực hiện các phân tích Mặc dù đã có nhiều công cụ ước lượng tự động hóa nhưng tất cả đều có cùng đặc trưng tổng quát và yêu cầu một hay nhiều phân loại dữ liệu sau:

1 Ước lượng định lượng về cỡ dự án (LOC) hay chức năng (FP)

2 Các đặc trưng định lượng về dự án như độ phức tạp, độ tin cậy cần có hoặc yêu cầu nghiệp vụ

3 Một mô tả nào đó về đội ngũ phát triển và/hoặc môi trường phát triển

Mô hình được cài đặt bởi các công cụ ước lượng tự động xây dưng trên cơ

sở các mô hình cho ra những ước lượng về công sức cần để hoàn thành dự án, chi phí, đội ngũ nhân viên, và trong một số trường hợp, phát triển cả lịch biểu và rủi ro liên quan

Một số công cụ ước lượng tự động dựa trên COCOMO như: BYL (Before You Leap – trước khi bạn hành động) được nhóm GORDEN phát triển, WICOMO (Wang Institute Cost Model) do viện nghiên cứu Wang phát triển, DECPlan do công ty DEC phát triển Mỗi công cụ này đều yêu cầu người dùng phải cung cấp các ước lượng LOC ban đầu Những ước lượng này được phân loại theo ngôn ngữ lập trình Người dùng cũng phải xác định giá trị cho các thuôc tính hướng dẫn chi phí đã mô tả trong các mục trên

Một hệ thống tính chi phí tự động dựa trên đường cong Rayleigh - Norden cho vòng đời phần mềm và mô hình ước lượng Putnam là SLIM Hệ thống này giúp cho người lập kế hoạch phần mềm thực hiện các chức năng: (1) định cỡ môi trường phát triển phần mềm bằng cách diễn giải dữ liệu lịch sử do người lập

kế hoạch cung cấp, (2) tạo ra một mô hình thông tin về phần mềm cần phát triển bằng cách suy luận ra các đặc trưng phần mềm cơ sở, thuộc tính nhân sự và những xem xét về môi trường, (3) tiến hành định cỡ phần mềm Cách tiếp cận trong SLIM là phức tạp hơn, tự động hóa hơn trong kỹ thuật đánh giá LOC ESTIMACS là một mô hình ước lượng vĩ mô dùng phương pháp ước lượng điểm chức năng có nâng cao để kiểm soát sự biến thiên của các nhân tố dự án và con người Công cụ này giúp cho người lập kế hoạch có khả năng ước lượng được: (1) công sức phát triển hệ thống, (2) nhân viên và chi phí, (3) cấu hình phần cứng, (4) rủi ro, (5) hiệu quả vốn đầu tư phát triển

SPQR/20 do Software Productivity Research phát triển, cho người dùng một tập đơn giản các câu hỏi nhiều lựa chọn, đề cấp tới: kiểu dự án (chương trình mới, bảo trì), phạm vi dự án (bản mẫu, môđun dùng lại), mục tiêu (thời hạn tối thiểu, chất lượng cao nhất), lớp dự án (chương trình, sản phẩm cá nhân), kiểu ứng dụng (theo lô, hệ chuyên gia), tài liệu người dùng (hình thức, không hình thức), thời gian đáp ứng, kinh nghiệm nhân viên, phần trăm mã gốc dùng lại, ngôn ngữ lập trình, độ phức tạp logic của thuật toán, độ phức tạp mã và dữ liệu… là những đầu vào SPQR/20 sẽ đưa ra các dữ liệu đã được mô tả cho các công cụ khác, ngoài ra còn ước lượng tổng số trang tư liệu dự án, tổng số khiếm khuyết tiềm năng của dự án, tổng số khiếm khuyết khi bàn giao, số các khiếm khuyết theo KLOC…

Costar là công cụ ước lượng chi phí phần mềm dựa trên COCOMO được

mô tả bởi Dr Barry Boehm trong cuốn Software Engineering Economics và cuốn Software Cost Estimation with COCOMO II Phần mềm quản lý dự án sử dụng

Costar cho kết quả ước lượng thời gian của dự án và chi phí của dự án

2.2.5 Mô hình lập luận theo kinh nghiệm – CBR

Mô hình lập luận theo kinh nghiệm (Case-based reasoning - CBR) [18] giải

quyết bài toán phù hợp với những miền có tính chất mở như ước lượng chi phí

dự án phần mềm [25] Trong mô hình đề xuất, chi phí cho một dự án mới được ước lượng bằng cách tìm kiếm những dự án tương tự đã có trong quá khứ sau đó hiệu chỉnh chi phí của dự án cũ đó cho phù hợp với ngữ cảnh của dự án mới Mô hình này có thể áp dụng trong ngữ cảnh hẹp của một công ty, tại thời điểm ban đầu của quá trình phát triển, khi thông tin dự án còn chưa được xác định rõ ràng

Mô hình lập luận theo kinh nghiệm được nhà tâm lý học người Mỹ, Roger Schank [22] đề xuất vào năm 1982 Ý tưởng cơ bản của mô hình này là tìm lời giải bài toán trên cơ sở tìm kiếm và hiệu chỉnh lời giải của các bài toán tương tự

đã có trong quá khứ Aarmodt [18] đã biểu diễn quá trình tìm lời giải theo mô hình lập luận kinh nghiệm bằng chu trình gồm 4 pha (hình 2.2):

1 Tìm kiếm lại (Retrieve) một hoặc nhiều ca lập luận tương tự

2 Sử dụng lại (Reuse) lời giải của các ca lập luận cũ cho ca lập luận mới

3 Xem xét lại (Revise) lời giải

4 Lưu lại (Retain) ca lập luận mới

Ở đây ca lập luận được dùng để chỉ bộ (đặc tả bài toán + lời giải)