Mô hình định tính dựa trên các giá trị ứng dụng trong lượng giá dự án phần mềm

DANH MỤC CÁC KÝ HIỆU, VIẾT TẮT IT Information Technology Công nghệ thông tin NPV Net Present Value Giá trị hiện tại dòng MBASE Model Based Architecting và Software Engineering Kiến trúc

BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

NGUYỄN THỊ PHÚC

MÔ HÌNH ĐỊNH TÍNH DỰA TRÊN GIÁ TRỊ ỨNG DỤNG TRONG

LƯỢNG GIÁ DỰ ÁN PHẦN MỀM Chuyên ngành: Công nghệ thông tin

LUẬN VĂN THẠC SĨ KỸ THUẬT

NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS.TS HUỲNH QUYẾT THẮNG

Hà Nội - Năm 2016

LỜI CAM ĐOAN

Tôi xin cam đoan :

1 Những nội dung trong luận văn này là do tôi thực hiện dưới sự hướng dẫn trực tiếp của PGS.TS Huỳnh Quyết Thắng

2 Mọi tham khảo dùng trong luận văn đều được trích dẫn rõ ràng tên tác giả, tên công trình, thời gian, địa điểm công bố

3 Mọi sao chép không hợp lệ, vi phạm quy chế đào tạo, hay gian trá, tôi xin chịu hoàn toàn trách nhiệm

Người cam đoan

NGUYỄN THỊ PHÚC

MỤC LỤC

Trang

Chương 1 TỔNG QUAN VỀ LƯỢNG GIÁ DỰ ÁN PHẦN MỀM 4

1.1 Các quan điểm khác nhau về khái niệm giá trị công nghệ thông tin 4

1.2 Phạm vi nghiên cứu và qui trình nghiên cứu của đề tài 5

1.2.1 Phạm vi nghiên cứu 5

1.2.2 Qui trình nghiên cứu 5

1.3 Các yêu cầu kiên quyết trước khi lượng giá dự án phần mềm 6

1.3.1 Phương pháp nhận thức rõ các lợi ích 6

1.3.2 Kiến trúc và kỹ nghệ phần mềm dựa trên mô hình 8

1.3.3 Mô hình Win-Win/Lý thuyết W 9

1.3.4 Kỹ thuật dựa trên mục tiêu 10

1.4 Kỹ thuật giá trị thu được trong lượng giá dự án phần mềm 12

1.4.1 Định nghĩa về dự án thành công 13

1.4.2 Kỹ thuật giá trị thu được 15

1.4.3 Dự toán chi phí hoàn thành dự án phần mềm 19

1.4.4 Dự toán thời gian triển khai dự án phần mềm 20

1.4.5 Sử dụng kỹ thuật giá trị thu được để kiểm soát dự án phần mềm 21

1.4.6 Các hệ số thành công quan trọng của dự án phần mềm 22

1.5 Kết luận chương 25

Chương 2 KỸ THUẬT ĐỊNH TÍNH TRONG LƯỢNG GIÁ DỰ ÁN PHẦN MỀM 27

2.1 Đặt vấn đề 27

2.2 Kỹ thuật thẻ điểm cân bằng 28

2.2.1 Giới thiệu 28

2.2.2 Thẻ điểm cân bằng truyền thống 29

2.2.3 Liên kết chiến lược tới các độ đo 30

2.2.4 Thẻ điểm công nghệ thông tin cân bằng 32

2.2.5 Quản trị công ty 35

2.3 Quản lý danh sách vốn đầu tư dự án/quản trị IT 36

2.4 Xây dựng mô hình lượng giá dự án phần mềm 37

2.4.1 Giới thiệu 37

2.4.2 Tổng quan về mô hình 38

2.4.3 Mô hình cho lượng giá dự án phần mềm 39

2.5 Kết luận chương 42

Chương 3 CÀI ĐẶT THỬ NGHIỆM 44

3.1 Bài toán thử nghiệm 44

3.1.1 Ranh giới đầu tư 45

3.1.2 Ví dụ áp dụng mô hình lượng giá dự án phần mềm đa chiều 46

3.2 Chương trình thử nghiệm mô hình lượng giá 50

3.2.1 Các thuật toán sử dụng trong phần mềm 50

3.2.2 Giao diện của chương trình thử nghiệm 52

3.2.3 Kết quả và đánh giá chương trình thử nghiệm 53

3.3 Kết luận chương 53

KẾT LUẬN 55

A Các nội dung đã thực hiện trong luận văn 55

B Hướng phát triển của đề tài 55

TÀI LIỆU THAM KHẢO 57

DANH MỤC CÁC KÝ HIỆU, VIẾT TẮT

IT Information Technology Công nghệ thông tin

NPV Net Present Value Giá trị hiện tại dòng

MBASE Model Based Architecting và

Software Engineering

Kiến trúc và kỹ nghệ phần mềm dựa trên mô hình

BCWS Budget Cost for Work Scheduled Chi phí theo kế hoạch

BAC Budget At Completion Ngân quỹ dự kiến tới thời

điểm hoàn thành

ACWP Actual Cost for Work Performed Chi phí thực tế cho công việc

đã thực hiện

BCWP Budget Cost for Work Performed Chi phí ngân sách của công

việc được thực hiện

CPI Cost Performance Index Chỉ số chi phí thực tế

SV Schedule Variance Chênh lệch chi phí do thay

đổi tiến độ SPI Schedule Performance Index Chỉ số tiến độ thực hiện

EAC Estimate at Completion Dự toán tại thời điểm hoàn

thành

ETC Estimate to Completion Dự toán đến thời điểm hoàn

thành SAC Scheduled At Completion Tiến độ để hoàn thành

TETC

Time Estimate To Completion Dự toán thời gian đến thời

điểm hoàn thành dự án phần mềm

TEAC Time Estimate At Completion Thời điểm hoàn thành dự án

DANH MỤC CÁC HÌNH

Hình 1.1: Nền làm việc tích hợp mô hình MBASE [12] 8

Hình 1.2: Mối quan hệ giữa chu trình sống dự án phần mềm và chu trình sống sản phẩm phần mềm 13

Hình 1.3: Minh họa các độ đo PV, BAC, AC và EV 17

Hình 1.4: Theo dõi hiệu quả dự án phần mềm sử dụng kỹ thuật giá trị thu được 22

Hình 1.5: Quá trình kiểm soát dự án phần mềm bằng kỹ thuật giá trị thu được [8] 22 Hình 2.1: Ví dụ kỹ thuật thẻ điểm cân bằng cho tổ chức 30

Hình 2.2: Phân loại thể điểm cân bằng ứng dụng cho CNTT [29] 33

Hình 2.3: Mô hình cho việc lượng giá dự án phần mềm theo nhiều chiều 41

Hình 3.1: Ranh giới đầu tư: ROI và rủi ro thất bại 45

Hình 3.2: Ranh giới đầu tư: NPV và rủi ro thất bại 45

Hình 3.3: Lượng giá dự án phần mềm theo hệ số các mục tiêu CNTT và hệ số các chiến lưc tổ chức 48

Hình 3.4: Lượng giá dự án phần mềm theo hệ số các mục tiêu tổ chức và các hệ số thành công quan trọng của dự án 49

Hình 3.5: Lượng giá dự án phần mềm theo khía cạnh các mục tiêu CNTT và các hệ thống thành công của dự án 50

Hình 3.6: Giao diện chính của chương trình thử nghiệm 53

DANH MỤC CÁC BẢNG

Bảng 1.1: Các độ đo được sử dụng trong kỹ thuật giá trị thu được 15

Bảng 1.2: Mức độ hiệu suất về giá trị và sai lệch về tiến độ [7] 17

Bảng 1.3: Tổng hợp các chỉ số hiệu quả về mặt chi phí và về mặt tiến độ [7] 18

Bảng 1.4: Các dự toán chi phí để hoàn thành dự án phần mềm [7] 19

Bảng 1.5: Các dự toán thời gian để hoàn thành dự án phần mềm [7] 20

Bảng 1.6: Ước tính các hệ số thành công quan trọng cho dự án phần mềm ví dụ 23

Bảng 2.1: Các mỗi quan hệ nhân quả hỗ trợ mục tiêu chiến lược tăng bán hàng 31

Bảng 2.2: Độ đo hỗ trợ mục tiêu chiến lược tăng bán hàng 31

Bảng 3.1: Các thông số phục vụ áp dụng mô hình lượng giá cho bài toán thử nghiệm 47

1

MỞ ĐẦU

Những năm gần đây chi phí phần mềm của các công ty đã tăng một cách đáng kể Việc tăng chí phí này, các công ty mong muốn tăng lợi nhuận cho công ty và cho xã hội Mối quan hệ này khó mô tả dẫn đến các ý kiến khác nhau về giá trị của công nghệ thông tin Mặc dù phần mềm đã có mặt ở mọi vị trí trong các công ty và trong

xã hội, nhưng sự tác động của phần mềm và giá trị của các dự án phần mềm khó định tính Giá trị phần mềm phụ thuộc vào nhiều khía cạnh nên khó khăn trong việc xây dựng giá trị phần mềm Giá trị phần mềm ở mức xã hội, giá trị phần mềm ở mức tổ chức và giá trị phần mềm ở mức dự án riêng biệt cần được ước lượng theo các cách khác nhau Giá trị phần mềm cũng phụ thuộc vào người sử dụng Giá trị phần mềm ở mức xã hội nói chung khác với giá trị phần mềm ở mức người sử dụng

và giá trị phần mềm ở mức công ty Trong báo cáo này, tác giả sẽ tập trung nghiên cứu ước tính giá trị của các dự án phần mềm từ khía cạnh công ty hay nói cách khác các dự án phần mềm mang lại cho công ty lợi ích về mặt giá trị như thế nào

Do tăng người sử dụng phần mềm nên vai trò của phần mềm trong sự thành công của công ty và trong xã hội nói chung tiếp tục phát triển Giá trị của các dự án phần mềm có thể được ước tính theo nhiều khía cạnh như mức độ đáp ứng các yêu cầu về mặt giá trị, mức độ đáp ứng các vấn đề về mặt tài chính và mức độ đáp ứng các vấn

đề hỗ trợ các mục tiêu hoặc các chiến lược

Các phương pháp kiểm soát và theo dõi dự án phần mềm hiện tại như các kỹ thuật giá trị thu được (earned value techniques), được đưa ra bởi các tổ chức chuyên nghiệp để mô tả việc kiểm soát và theo dõi dự án phần mềm, đang được thực hiện dựa vào kế hoạch thực hiện dự án phần mềm Việc hoàn thành một kế hoạch dự án phần mềm chưa hẳn đã tương quan với giá trị phần mềm Vì vậy việc nghiên cứu giá trị phần mềm là cần thiết Kiểm soát và theo dõi dự án phần mềm dựa vào đường gốc giá trị (value baseline) sẽ dẫn đến đạt được các mục tiêu, các chiến lược

và các lợi ích về mặt tài chính tốt hơn Các thành phần cần thiết để xây dựng đường gốc giá trị sẽ được tác giả nghiên cứu và trình bày trong báo cáo này

Có vài kỹ thuật đã sử dụng để định lượng lợi ích về mặt tài chính hoặc để định lượng lợi nhuận thu được từ một dự án phần mềm Giá trị hiện tại dòng (NPV - Net Present Value) của dự án phần mềm được tính bởi từ lãi và chi phí theo tỷ lệ thích hợp để tính toán tổng giá trị hiện tại dòng của dự án phần mềm Nội suất sinh lợi và cách nhìn xen kẽ bên trong các con số giống nhau hỗ trợ tính toán NPV Khả năng

2

ứng dụng của kỹ thuật này và sử dụng trong lượng giá dự án phần mềm cũng sẽ được tác giả nghiên cứu và trình bày

Các kỹ thuật cho việc suy luận, đối chiếu và đo lường sự thỏa mãn các yêu cầu

về giá trị đã được phát triển và đòi hỏi phải được xác định trước khi ước tính giá trị của dự án phần mềm Xác định trước tất cả các yêu cầu về giá trị quan trọng và hiểu vai trò của dự án phần mềm muốn lượng giá nằm trong các hệ thống lớn (gồm các ứng dụng phần mềm khác và các hành động của con người có ý nghĩa trong việc xác định và đối chiếu các yêu cầu về giá trị)

Từ lý do trên em đã chọn luận văn: “Mô hình định tính dựa trên giá trị ứng dụng trong lượng giá dự án phần mềm”

Mục tiêu của đề tài: Nghiên cứu tổng quan về lượng giá dự án phần mềm để nắm những kiến thức cơ bản và kỹ thuật giá trị thu được trong lượng giá dự án phần mềm; Nghiên cứu một số kỹ thuật định tính trong lượng giá dự án phần mềm như

Kỹ thuật thẻ điểm cân bằng, và đưa ra được mô hình lượng giá dự án phần mềm

đa chiều bằng cách kết hợp các kỹ thuật định lượng và định tính trong lượng giá dự

án phần mềm Cuối cùng, ứng dụng mô hình đa chiều này vào lượng giá dự án phục

vụ cho việc lựa chọn dự án, xây dựng chương trình thử nghiệm lựa chọn dự án sử dụng mô hình đa chiều này

Cấu trúc của luận văn được chia thành 3 chương cụ thể như sau:

Chương 1: Tổng quan về lượng giá dự án phần mềm

Trình bày quan điểm về giá trị công nghệ thông tin; phạm vi nghiên cứu và qui trình nghiên cứu Đồng thời cũng trình bày các yêu cầu kiên quyết trước khi lượng giá dự án phần mềm Đặc biệt trình bày kỹ thuật giá trị thu được trong lượng giá dự

án phần mềm

Chương 2: Các kỹ thuật định tính trong lượng giá dự án phần mềm

Trình bày kỹ thuật thẻ điểm cân bằng, kỹ thuật liên kết chiến lược tới các độ đo, và đặc biệt trình bày mô hình lượng giá dự án phần mềm đa chiều bằng cách kết hợp các kỹ thuật lượng giá định tính và định lượng với nhau

Chương 3: Cài đặt thử nghiệm

Trình bày ví dụ áp dụng mô hình lượng giá dự án phần mềm đa chiều để lựa chọn

dự án hiệu quả; trình bày chương trình thử nghiệm trong việc lựa chọn dự án cần

3

đầu tư dựa vào mô hình lượng giá dự án phần mềm đa chiều, đưa ra kết quả và nhận xét

Để hoàn thành được luận văn, em xin được gửi lời cảm ơn tới các Thầy giáo

trong Viện Công nghệ thông tin và Truyền thông - Trường Đại học Bách Khoa Hà Nội đã tận tình giảng dạy, cung cấp nguồn kiến thức quý giá trong suốt quá trình học tập

Đặc biệt em xin chân thành cảm ơn thầy giáo PGS TS Huỳnh Quyết Thắng đã tận tình hướng dẫn, góp ý, tạo điều kiện cho em hoàn thành luận văn này

4

Chương 1 TỔNG QUAN VỀ LƯỢNG GIÁ DỰ ÁN PHẦN MỀM

Trong chương này, tác giả sẽ tập trung nghiên cứu và trình bày những quan điểm khác nhau về khái niệm “giá trị” và lượng giá dự án phần mềm, phạm vi nghiên cứu của đề tài Đồng thời tác giả cũng trình bày kỹ thuật giá trị thu được và các yêu cầu kiên quyết trước khi lượng giá dự án phần mềm Dưới đây là nội dung chi tiết của từng phần mà tác giả muốn trình bày trong chương

1.1 Các quan điểm khác nhau về khái niệm giá trị công nghệ thông tin

Robert Solow, nhà kinh tế học giành giải Nobel đã nói: “chúng ta có thể thấy quá trình phát triển của máy tính ở mọi nơi dựa vào các thống kê sản phẩm” [1] Trong [2], Carr đưa ra sự so sánh thể hiện rằng sự phát triển sử dụng công nghệ thông tin tương tự như sự phát triển sử dụng đường sắt và điện tử trong quá khứ, theo mô hình phát triển giống nhau Carr cho rằng điện tử và đường sắt đã trở thành các loại hàng hóa vì vậy CNTT cũng đã trở thành hàng hóa Nếu CNTT là hàng hóa khi đó các công ty sẽ tìm cách hạn chế tối đa sử dụng CNTT, sử dụng các giải pháp có sẵn hơn là sử dụng các giải pháp CNTT riêng biệt cho công ty và sử dụng chỉ ở mức độ đảm bảo các công ty có các nguồn tài nguyên CNTT đủ để ngang hàng với những đối thủ cạnh tranh Nếu CNTT có thể cung cấp các lợi thế chiến lược cho các công

ty, khi đó các công ty sẽ tăng cường sử dụng CNTT và phát triển các ứng dụng và giải pháp CNTT có giá trị riêng cho công ty CNTT sẽ cung cấp các lợi thế cạnh trạnh Nguyên lý của Carr và các nguyên lý tương tự khác đã tạo ra tranh luận lớn Trước Carr có các phản hồi tranh luận về thiếu giá trị của CNTT Các tranh luận này có thể được phân chia thành hai nhóm:

- Nhóm thứ nhất cố gắng hiểu các nguồn giá trị CNTT và cố gắng nâng cao giá trị CNTT thông qua sử dụng các kỹ thuật xác định yêu cầu (requirements techniques) Việc thiếu giá trị CNTT được xem như là thiết sót trong việc hiểu những vấn đề cần thiết trong kinh doanh và trong kinh doanh các thay đổi cần thiết đều sử dụng các giải pháp CNTT hiệu quả

- Nhóm thứ hai cố gắng hiểu giá trị CNTT tạo ra (định lượng và định tính) Giá trị CNTT có thể được nghiên cứu ở ba mức:

+ Ở mức xã hội hoặc mức quốc gia CNTT mang đến cho dân số những gì?

5

+ Ở mức công ty CNTT có vai trò gì trong việc mang lại cho công ty mạnh hơn? CNTT mang đến lợi thế cạnh tranh cho công ty không? Lợi thế cạnh tranh có thể được khai thác tối đa như thế nào?

+ Ở mức dự án Đơn giản chỉ là giá trị của các dự án CNTT là gì? Các dự án CNTT sẽ được lựa chọn, được ưu tiên và được kiểm soát như thế nào?

Trong báo cáo này, tác giả sẽ chỉ nghiên cứu và trình bày giá trị CNTT ở mức dự

án phần mềm, nghiên cứu các kỹ thuật xác định giá trị của các dự án CNTT và xác định giá trị của việc lựa chọn các dự án CNTT

1.2 Phạm vi nghiên cứu và qui trình nghiên cứu của đề tài

1.2.1 Phạm vi nghiên cứu

Các câu hỏi được giải quyết trong báo cáo này như sau: Giá trị của dự án phần mềm có thể được hiểu và được ước tính như thế nào? Xét hai dự án sau đây:

- Dự án A được ước tính với giá trị 200.000 USD và kéo dài trong 6 tháng Thực

tế, nó được hoàn thành với giá 180.000 USD trong 5 tháng

- Dự án B được ước tính với giá trị 300.000 USD và kéo dài trong 9 tháng Thực

tế, nó được hoàn thành với giá 800.000 USD trong 18 tháng

Câu hỏi đặt ra là “Dự án nào có giá trị nhiều hơn?” Câu trả lời chính xác đó là chúng ta không thể trả lời được từ những thông tin đã cung cấp ở trên (chỉ có thông tin giá trị dự án và thông tin khả năng hoàn thành của dự án được thực hiện bởi người quản lý dự án và không có giá trị kinh doanh của dự án) Chúng ta có thể cho rằng dự án B mang lại giá trị nhiều hơn cho công ty phần mềm

Luận văn này định hướng trực tiếp vào nghiên cứu để trả lời các câu hỏi trên, đó

là hiểu giá trị dự án phần mềm (định lượng và định tính)

1.2.2 Qui trình nghiên cứu

Tổng hợp và trình bày lại các bài báo nghiên cứu từ các lĩnh vực khác nhau, bao gồm: khoa học máy tính và kỹ nghệ phần mềm, quản lý chung, quản lý dự án và tài chính Các phương pháp và các khái niệm liên quan từ các bài báo nghiên cứu (hoặc nguồn tài liệu) trên được kết hợp và được phân tích thành hệ thống với mục tiêu tổng kết để hiểu các bài báo nghiên cứu trên và lượng giá dự án phần mềm và cung cấp qui trình từng bước được sử dụng để lượng giá dự án phần mềm

6

1.3 Các yêu cầu kiên quyết trước khi lượng giá dự án phần mềm

Kỹ thuật các yêu cầu (requirements techniques) được xem như là các yêu cầu cần thiết trước khi lượng giá các dự án phần mềm Trong tất cả các kỹ thuật để lượng giá các dự án phần mềm thì có một giả thiết ẩn ý rằng phạm vi của dự án phần mềm

và các yêu cầu cần thiết cho dự án phần mềm được biết đầy đủ để hỗ trợ các ước tính giá trị phù hợp với trạng thái hiện tại trong chu trình sống của dự án phần mềm

Cụ thể, ban đầu khi các dự án phần mềm được yêu cầu hoặc được đề xuất, hiểu biết đầy đủ về phạm vi của dự án phần mềm được yêu cầu để đưa ra ước tính chi phí và ước tính lợi ích ở mức khái quát Vì các yêu cầu kiên quyết cần thiết được đưa ra, được phân tích và được hợp lý hóa nên ước tính chi phí và ước tính lợi ích cũng sẽ được đưa ra để phản ánh việc hiểu dự án phần mềm tốt hơn Các kỹ thuật các yêu cầu tốt có thể được xem như là cần thiết để đưa ra việc hiểu và các chi tiết của dự án phần mềm trong việc hỗ trợ các kỹ thuật lượng giá dự án phần mềm

Kinh phí CNTT đã chiếm phần trăm lớn trong kinh phí của nhiều tổ chức Một câu hỏi tự nhiên là giá trị mang lại bởi chi phí CNTT? Giá trị này được xác định và được mang lại bởi chỉ các nhóm CNTT? Thorp [9] phát biểu một cách chính xác rằng các ảnh hưởng CNTT hoặc các dự án CNTT chỉ là một phần nhỏ của ảnh hưởng thương mại và dự án CNTT cần xem xét ảnh hưởng về mặt giá trị thu được

và giá trị độ đo liên quan tới thương mại Trong vấn đề quản lý dự án, giá trị cần phải được xây dựng từ chương trình thương mại và các dự án CNTT tổng thể Chỉ bản thân dự án CNTT có thể không mang lại giá trị

1.3.1 Phương pháp nhận thức rõ các lợi ích

Phương pháp nhận thức rõ các lợi ích [9] (Benefits Realization Approach) là một nền tảng làm việc (framework) cho phép xem xét chương trình thương mại tổng thể, trong đó ảnh hưởng CNTT hoặc dự án CNTT là một phần Phương pháp này sử dụng kỹ thuật mô hình hóa đơn giản để hỗ trợ suy diễn các ảnh hưởng liên quan cần thiết để đưa ra được giá trị thương mại Phương pháp này nhìn tập điều kiện cần thiết một cách tổng thể với mục đích thành công; không chỉ mỗi ảnh hưởng của CNTT Chu trình sống của sản phẩm phần mềm thương mại không chỉ được xác định ở khía cạnh dự án phần mềm Khái niệm phương pháp tiền mặt được sử dụng

để thu được giá trị

Chìa khóa để hiểu phương pháp nhận thức rõ các lợi ích là khái niệm về giải pháp CNTT, không cần chú ý đến các giá trị của phương pháp, sẽ không giành được

7

giá trị hoặc lợi ích đầy đủ của phương pháp nếu không xem xét các thay đổi rộng hơn trong thương mại Thorp [10] chú ý rằng dù cho CNTT là chủ yếu nhưng khi sản phẩm CNTT được tích hợp đầy đủ vào trong chương trình thương mại các thay đổi và các đầu tư thực chất là khía cạnh thương mại Các tổ chức không phân tích, hiểu hoặc theo dõi các chi phí thương mại liên quan đến các vấn đề trên Thorp đặt tên phương pháp là “Benefits Realization Approach - Phương pháp nhận thức rõ các lợi ích” Ba tiền đề chính của phương pháp [10]: (1) Các lợi ích không chỉ vừa mới xảy ra; (2) Các lợi ích ít xảy ra liên quan tới kế hoạch; (3) Hiểu rõ các lợi íc’h là một tiến trình liên tục

Có một khoảng thời gian làm theo sản phẩm mới và thử nghiệm (learning curve) như mọi người học cách để sử dụng tốt nhất các chức năng của sản phẩm mới Liên quan tới điều này là khái niệm hiểu rõ giá trị (lợi ích) thành công yêu cầu huấn luyện và một kế hoạch chuyển từ trạng thái hiện tại sang trạng thái mới sử dụng phần mềm đã được phát triển

Để giành được giá trị (hoặc lợi ích) yêu cầu các bước:

Bước 1 Cần thiết phải hiểu các độ đo giá trị Từ lĩnh vực kinh tế tài chính và kinh tế kỹ thuật, cần hiểu ý nghĩa giá trị tài chính của các dự án phần mềm (hoặc rộng hơn là các chương trình) Cách đánh giá dự án phần mềm liên quan tới chiến lược CNTT và chiến lược mang tính tổ chức và các mục tiêu là cũng cần thiết Bước 2 Cần hiểu và làm rõ các lợi ích và các giá trị của những người sử dụng Các kỹ thuật mô hình hóa như các phương pháp dựa vào mục tiêu và chuỗi các kết quả có thể làm rõ các yêu cầu mà sẽ mang lại giá trị của những người sử dụng Thu thập tập các yêu cầu đầy đủ này và các mục tiêu trên và hiểu các thành phần thương mại và CNTT cần thiết là các chìa khóa để lấy giá trị

Bước 3 Các kết quả phân tích ban đầu, ước tính giá trị của ảnh hưởng, trường hợp thương mại, các tập mục tiêu, các yêu cầu và các khởi tạo phải được lấy vì chúng là ước tính ban đầu của những gì cần phải được thực hiện và những gì phải được đưa ra

Bước 4 Tiến trình phải được đo, các tính toán tài chính phải được tính toán lại và giành được dựa trên các mô hình của người sử dụng và giá trị tổ chức phải được kiểm soát như là các độ đo thực tế Vài ước tính ban đầu sẽ được chứng minh chính xác và không chính xác Nếu không có các độ đo thì dự án phần mềm hoặc chương trình thương mại đang thực hiện một cách mù và sẽ không chắc chắn thu được các

8

kết quả mong muốn, càng không chắc chắn rằng các ước tính và các kế hoạch ban đầu là hoàn hảo Ước tính các mô hình tài chính, các yêu cầu và các mục tiêu, và các trường hợp thương mại cần phải được thực hiện sớm và thường xuyên

1.3.2 Kiến trúc và kỹ nghệ phần mềm dựa trên mô hình

Kiến trúc và kỹ nghệ phần mềm dựa trên mô hình (Model Based Architecting and Software Engineering – MBASE) [12, 13] là một kỹ thuật khác cố gắng xác định tất cả các điều kiện cần thiết để có được giá trị Cố gắng nhìn dọc theo bốn chiều để tối đa hóa giá trị Một tiến trình lặp được sử dụng để đảm bảo các mô hình biểu diễn mỗi chiều là tin cậy

Hình 1.1: Nền làm việc tích hợp mô hình MBASE [12]

Các chiều được xem xét như sau [12]:

- Mô hình sản phẩm: Hệ thống đang được phát triển Các mô hình trong chiều này biểu diễn các yêu cầu, code và kiến trúc

9

- Mô hình tiến trình: Các tiến trình được sử dụng để phát triển hệ thống Các ví

dụ về các mô hình tiến trình gồm các mô hình phát triển thác nước, các mô hình xoắn ốc, các phương pháp lặp

- Mô hình đặc điểm: Đây là các mô hình đặc điểm của sản phẩm hoặc tiến trình Các mô hình này gồm mô hình quản lý dự án (các ước tính chi phí và tiến độ) và

mô hình sản phẩm (các mô hình hiệu quả và tin cậy)

- Mô hình thành công: Mỗi lớp người sử dụng cần được thỏa mãn những gì Các

mô hình thành công gồm các mô hình tài chính được trình bày trong Chương 2 và các mô hình thỏa mãn người sử dụng như Win-Win

Những chiều trên có thể được trình bày trừu tượng như trong hình 1.1 [12]

1.3.3 Mô hình Win-Win/Lý thuyết W

Các kỹ thuật làm rõ và thu được giá trị người sử dụng là các mô hình hiểu giá trị người sử dụng và đối chiếu các giá trị của những người sử dụng thay đổi Lý thuyết

W là một lý thuyết mà phát biểu rằng dự án thành công có thể giành được bằng cách thỏa mãn các yêu cầu giá trị của tất cả những người sử dụng phê bình Khả năng IT

sẽ có nhiều người sử dụng gồm những người sử dụng cuối, các khách hàng, quy tắc quản lý kinh doanh, quản lý công nghệ thông tin, người quản lý dự án, phân tích, những người phát triển, những người duy trì hệ thống tương lai (giữa các hệ thống khác) Mỗi nhóm người sử dụng sẽ có các mục tiêu của họ mà có thể xung đột với những nhóm người sử dụng khác Giải quyết những xung đột này có thể là chìa khóa để thu được giá trị

10

Chìa khóa để tạo ra các tình huống Win-Win là sự đàm phán Trong quyển sách, Getting to Yes [16], năm nguyên tắc được xây dựng để hướng tới việc tạo ra các tình huống win-win

- Không thỏa thuận buôn bán trên các quan điểm

Quan điểm là lý lẽ của cá nhân Lý lẽ hoặc thỏa thuận buôn bán trên các quan điểm chỉ có thể kết quả sẽ mất một phần

- Tách biệt con người từ bài toán

Các việc thỏa thuận là con người Những cảm xúc và mối quan hệ của con người

có thể tác động vào các quan điểm và các thỏa thuận của con người trên các quan điểm Điều quan trọng là tách biệt độc lập các hệ số này ra khỏi bài toán

- Tập trung vào các những vấn đề quan trọng, không tập trung vào quan điểm Tập trung vào các vấn đề quan tâm và cần thiết quan trọng của từng người sử dụng và không tập trung vào quan điểm hiện tại của họ

- Các lựa chọn thông minh trong việc tăng cường tác động lẫn nhau

Các lựa chọn mở rộng hoặc thông minh có thể chuyển một tình huống win-lose thành tình huống win-win

- Đẩy mạnh sử dụng tiêu chuẩn mục tiêu

Các kỹ thuật được miêu tả trong Getting to Yes và từ Lý thuyết W có thể cải tiến việc xác định và tạo ra các điều kiện Win-Win Các điều kiện win-win là có thể có

1.3.4 Kỹ thuật dựa trên mục tiêu

Một phần chính trong việc lượng giá dự án phần mềm là làm rõ các yêu cầu Hiểu và phát triển các yêu cầu đầy đủ là quan trọng để xác định các yêu cầu giá trị người sử dụng, đơn giản chúng là giá trị gì Mô hình mục tiêu là một kỹ thuật mà có thể được sử dụng để xây dựng các yêu cầu người sử dụng Xây dựng và định nghĩa của các mục tiêu người sử dụng được coi là một thành phần quan trọng trong nhiều khía cạnh của kỹ thuật các yêu cầu Việc tạo một cấu trúc phân cấp các mục tiêu liên quan ở các mức trừu tượng khác nhau có thể dẫn đến việc xác định, làm rõ và

kỹ lượng của các yêu cầu tốt hơn Phân tích các mục tiêu bằng phương pháp tinh vi, hỏi “như thế nào”, và bằng trừu tượng, hỏi “tại sao”, có thể dẫn đến một tập các yêu cầu đầy đủ hơn Các phương pháp GORE nói chung gồm GBRAM [17] [18], i* [19] [20], nền làm việc NFR [21] và KAOS [22, 23] Các khái niệm GORE tổng quát được miêu tả dưới đây

11

Các khái niệm kỹ thuật các yêu cầu hướng mục tiêu

Các mục tiêu là yếu tố cơ bản cho xử lý các yêu cầu Yu đã nói [20]: “Có lẽ làm

rõ và thao tác các mục tiêu là một phần kế thừa và tự nhiên của thực hiện RE, các phương pháp RE trước kia không chỉ ra điều này, và không cung cấp hỗ trợ liên kết

Sự giải thích này là hợp lý vì các yêu cầu được biểu diễn tự nhiên”

“Kỹ thuật các yêu cầu hướng mục tiêu (Goal-oriented requirements engineering - GORE) sử dụng các mục tiêu để làm rõ, xây dựng cấu trúc, chỉ rõ, phân tích, điều kiện thỏa mãn, tài liệu và thay đổi các yêu cầu” [22] Thực tế trước kia các yêu cầu truyền thống tập trung vào hệ thống có mục đích làm gì mà chủ yếu dựa vào chức năng của hệ thống Những người sử dụng và các nguồn tài nguyên khác của các yêu cầu truyền thống biểu diễn các yêu cầu thành danh sách các đặc điểm Ngược lại,

các kỹ thuật GORE tập trung vào tại sao để hiểu hơn về hệ thống được đề xuất

trong môi trường hệ thống và làm cho hệ thống hoàn thiện hơn; và tập trung vào

như thế nào Hiểu dự án phần mềm tốt hơn có thể dẫn đến việc giành giá trị tốt hơn

Mối quan hệ giữa các mục tiêu và các yêu cầu là tương tự như mối quan hệ giữa thiết kế và code Các yêu cầu hoàn thành các mục tiêu Tập các yêu cầu có thể được ước tính để xác định cách các yêu cầu thỏa mãn tốt các mục tiêu được xác định Các kỹ thuật Gore có thể đóng một vai trò trong nhiều khía cạnh của kỹ thuật các yêu cầu, nhưng các kỹ thuật Gore liên quan đến nhau một cách cụ thể trong quá trình xử lý Các mục tiêu cơ bản là ở mức cao và hiểu mục đích người sử dụng và các sự thúc đẩy đầy đủ có thể dẫn tới phát triển các yêu cầu thành công Hai phương pháp cơ bản của GORE là:

- Bắt đầu với tập các mục tiêu người sử dụng ban đầu ở mức cao và dẫn ra các mục tiêu con Phương pháp tinh vi lặp các mục tiêu con dẫn đến các yêu cầu

- Bắt đầu với một miêu tả hệ thống, các kịch bản hoặc các đặc điểm chức năng

Từ những vấn đề này, xác định tập các mục tiêu ban đầu Phương pháp tinh vi lặp các mục tiêu này dẫn tới tập các yêu cầu

Khái niệm mục tiêu là cơ bản Một mục tiêu là một đối tượng hoặc một mục đích quan tâm cho hệ thống Các mục tiêu tồn tại ở các mức trừu tượng khác nhau Ở mức cao nhất các mục tiêu phải thể hiện chiến lược tổng thể của tổ chức (công ty),

cụ thể, “cung cấp các dịch vụ kế toán cho các máy khách” Ở mức thấp nhất các mục tiêu phải thỏa mãn các hành động của một agent (tác tử) đơn và ánh xạ trực

12

tiếp vào trong một yêu cầu Các mục tiêu có thể được liên quan tới khía cạnh chức năng hoặc không chức năng của một hệ thống Các mục tiêu chức năng biểu diễn các hoạt động hoặc các dịch vụ cá nhân mà hệ thống hỗ trợ Các mục tiêu không chức năng là các chất lượng của hệ thống Các kỹ thuật hướng mục tiêu cung cấp một cách đánh giá định tính và định lượng có tính hệ thống về các mục tiêu chức năng và không chức năng Các yêu cầu có thể được liên kết ngược lại tới các mục tiêu không chức năng và thỏa mãn các mục tiêu này bằng tập các yêu cầu được ước tính đề xuất

Nhiều mục tiêu không chức năng là các mục tiêu mềm Một mục tiêu mềm là một mục tiêu mà có thể thay đổi phạm vi Cụ thể, khả năng sử dụng là một mục tiêu mềm Khả năng sử dụng hệ thống cuối cùng sẽ được hỗ trợ tới các phạm vi khác nhau bởi tập các yêu cầu, các thiết kế và các cài đặt hoàn thiện khác nhau

Các mục tiêu được liên kết với nhau Cấu trúc phân cấp mục tiêu có thể được xây dựng liên kết từng mục tiêu với các mục tiêu con của nó Thỏa mãn từng mục tiêu

có thể yêu cầu rằng tất cả các mục tiêu con được thỏa mãn, được gọi là phương pháp tinh vi - AND, hoặc thỏa mãn một mục tiêu con nào đó có kết quả thỏa mãn mục tiêu cha, được gọi là phương pháp tinh vi - OR Các mục tiêu mềm được liên kết với nhau với các mục tiêu con dẫn đến khái niệm của một mục tiêu đang được thỏa mãn bởi các mục tiêu con của nó Các mục tiêu con được thêm hoặc lấy đi từ việc hoàn thiện của mục tiêu cha

Phát triển một cấu trúc phân cấp mục tiêu được thực hiện bằng cách hỏi lặp đi lặp

lại tại sao và thế nào Phương pháp tinh vi các mục tiêu có thể được thực hiện bởi

việc hỏi “thế nào” để chia từng mục tiêu thành các mục tiêu con Sự trừu tượng của

các mục tiêu ở mức cao hơn có thể được thực hiện bằng cách hỏi “tại sao”

Các phương pháp dựa trên mục tiêu xây dựng hệ thống ghép, đó là hệ thống phần mềm nằm trong môi trường lớn hơn của nó Các phương pháp dựa trên mục tiêu xem như là cách để xác định các yêu cầu cần thiết kiên quyết để dự án phần mềm giành được giá trị

1.4 Kỹ thuật giá trị thu được trong lượng giá dự án phần mềm

Chúng ta phải phân biệt một cách rõ ràng giữa dự án phần mềm đang được quản

lý và sản phẩm phần mềm đang được thiết kế và được xây dựng Nhiều kỹ thuật quản lý dự án và nhiều độ đo thành công chỉ nghiên cứu cho dự án phần mềm đang được quản lý trong khi sản phẩm phần mềm đang được thiết kế và được xây dựng

13

chỉ nghiên cứu nguồn của giá trị Thực tế sử dụng các kỹ thuật như kỹ thuật giá trị thu được (có ích trong việc kiểm soát và đo tiến trình dự án phần mềm) không cung cấp thông tin về giá trị được tạo ra bởi dự án phần mềm Không có “giá trị” trong kỹ thuật giá trị thu được; thực tế kỹ thuật giá trị thu được là kỹ thuật theo dõi giá trị của

dự án phần mềm

1.4.1 Định nghĩa về dự án thành công

Ý nghĩa của “Dự án thành công” về cơ bản sẽ được hiểu theo hướng phát triển của các nền tảng làm việc mà được sử dụng để lượng giá các dự án phần mềm và để theo dõi hướng thành công trong việc đạt được giá trị Định nghĩa về thành công là yếu tố chính trong việc hiểu các yếu tố nào cần được đo và cần được theo dõi để lượng giá dự án phần mềm Thành công có thể được đo theo nhiều hướng khác nhau

và lượng giá dự án phần mềm theo từng hướng có thể là quyết định cho việc dự án thành công và ước lượng giá trị của dự án phần mềm

Phân biệt khái niệm giữa dự án phần mềm và sản phẩm phần mềm; và giữa chu trình sống của dự án phần mềm và chu trình sống của sản phẩm phần mềm là quan trọng “Một dự án là một cam kết nỗ lực tạm thời để tạo ra một sản phẩm, dịch vụ hoặc kết quả duy nhất” [3] Sản phẩm phần mềm là kết quả của dự án phần mềm và

có khoảng thời gian sống kéo dài đến kết thúc dự án phần mềm Mối quan hệ giữa chu trình sống dự án phần mềm và chu trình sống sản phẩm phần mềm được minh hoạ trong Hình 1.2 [4]

Hình 1.2: Mối quan hệ giữa chu trình sống dự án phần mềm và chu trình sống sản

phẩm phần mềm

Kế hoạch kinh doanh

14

Điều quan trọng khác đó là xem xét sự khác nhau giữa chu trình sống của dự án phần mềm và chu trình sống của sản phẩm phần mềm Các độ đo truyền thống về

dự án thành công như kỹ thuật giá trị thu được đã tập trung vào độ đo thời gian, độ

đo giá trị và độ đo phạm vi trong chu trình sống của dự án phần mềm Các độ đo truyền thống này đã tập trung vào chu trình sống của dự án phần mềm nên dẫn đến việc chỉ đo các độ đo hoạt động và không quan tâm đến giá trị chiến lược của dự án phần mềm Trong [5] dự án thành công theo hướng các độ đo dự án phần mềm bên trong hơn là theo hướng những gì dự án phần mềm mang lại cho công ty phần mềm

Vì vậy, đo dự án phần mềm dựa vào kế hoạch gốc của dự án phần mềm, nhưng lại không xem xét giá trị dự án phần mềm mang lại cho những người hưởng lợi/hữu quan (stakeholders) Chu trình sống của dự án phần mềm được xem xét đến lúc kết thúc sản phẩm phần mềm và gắn cùng với bắt đầu các hoạt động của sản phẩm phần mềm, khi đó sản phẩm phần mềm được hoàn thành

Judgev [5] cho rằng hiểu dự án thành công theo hướng tập trung mối quan hệ chức năng có thể giành được “bằng cách đo thành công trong giai đoạn các hoạt động và loại bỏ các dịch vụ tích cực của sản phẩm phần mềm khi các độ đo được đánh giá và xem xét đầu vào từ những người sử dụng khác nhau” Bằng cách xem xét chu trình sống của sản phẩm phần mềm là chính dự án phần mềm, hơn là chỉ xem xét chu trình sống của dự án phần mềm, chúng ta có thể đo giá trị của dự án phần mềm mang lại cho tổ chức (công ty) và thu được những phản hồi từ những người sử dụng Đo giá trị dự án phần mềm trong giai đoạn hoạt động của sản phẩm phần mềm cũng là phản hồi mà cho phép định giá của các kỹ thuật định giá được thực hiện sớm hơn trong dự án phần mềm

Một xem xét khác về đo dự án thành công là sự khác nhau giữa hiệu quả (efficiency) dự án và hiệu lực (effectiveness) dự án Hiệu quả dự án nhìn về mặt thời gian, phạm vi và giá trị Hiệu lực dự án tập trung vào việc thỏa mãn các yêu cầu và các mục tiêu của người sử dụng (stakeholder) Đây là một cái nhìn rộng hơn

về dự án thành công Hiệu quả dự án là hoạt động tập trung vào đo dự án thành công dựa vào kế hoạch của dự án phần mềm Hiệu lực dự án mang tính chiến lược

đo giá trị mà dự án phần mềm mang lại cho công ty (tổ chức) Một mô tả thay thế

sự khác nhau giữa hiệu quả dự án và hiệu lực dự án đó là sự khác nhau giữa thành công quản lý dự án và dự án thành công Cooke-Davies [6] đưa ra sự khác biệt giữa thành công quản lý dự án và dự án thành công như sau:

dự án hơn là đo dự án thành công

Jugdev [5] đã đưa ra đánh giá về các độ đo của dự án thành công Ban đầu 1980), thành công được định nghĩa chủ yếu liên quan đến độ đo giá trị, độ đo thời gian và độ đo phạm vi Các độ đo này không xem xét sự thỏa mãn của người sử dụng/toàn bộ sản phẩm và dẫn đến lỗi các độ đo dự án thành công Giá trị của dự án phần mềm phải xem xét đánh giá về mặt tài chính của sản phẩm và phải định giá dự

(1960-án phần mềm liên quan tới những người sử dụng cần được thỏa mãn các yêu cầu của họ

1.4.2 Kỹ thuật giá trị thu được

Kỹ thuật giá trị thu được cho phép theo dõi và kiểm soát dựa trên ước tính về thời gian, ước tính về phạm vi của các độ đo Kỹ thuật giá trị thu được cho phép tính toán tiến độ bị thay đổi và chi phí bị thay đổi và cung cấp một cách tính dự toán đến thời điểm hoàn thành và thời gian dự kiến hoàn thành (thời gian hoàn thành các tiến trình của dự án phần mềm) Kỹ thuật giá trị thu được đóng một vai trò trong việc phát hiện sớm tiến độ bị thay đổi và thời gian bị thay đổi Kỹ thuật giá trị thu được thường được sử dụng trong thực tế và là độ đo chính của dự án thành công Kỹ thuật giá trị thu được dựa trên 4 độ đo [7]:

Bảng 1.1: Các độ đo được sử dụng trong kỹ thuật giá trị thu được

Tổng giá trị dự kiến

(PV hoặc BCWS)

Đây là ngân sách được cấp để thực hiện

dự án tính đến thời điểm kết thúc dự án

Xét một quá trình tuyến tính, một nhiệm vụ ước tính sử dụng 2 tháng và ngân sách cấp là 10000 sẽ có PV =

5000 vào thời điểm cuối tháng

Ngân quỹ dự kiến

tới thời điểm hoàn

thành (BAC):

Đây là ngân quỹ dự kiến cấp cho dự án để hoàn thành dự án

Một nhiệm vụ ước tính tới giá trị

1000 có ngân quỹ ở mức hoàn thành

là 10000

Chi phí thực tế (AC) Đây là chi phí thực tế Giả sử tại thời điểm cuối tháng nào đó

6000 đã được sử dụng để thực hiện một công việc Chi phí thực tế của công việc này là 6000

Giá trị thu được

(EV) hoặc chi phí

ngân sách của công

việc được thực hiện

(BCWP)

Đây là giá trị thu được của công việc hoàn thành tại một thời điểm

Xét một nhiệm vụ được ước tính với giá trị 10000 Nếu nhiệm vụ hoàn thành 45% thì giá trị thu được của nhiệm vụ này là 4500

Các độ đo PV, BAC, AC và EV tại thời điểm cuối tháng đầu tiên đối với các ví

dụ trình bày trong bảng trên được minh họa trong Hình 1.2 Để hiểu rõ về giá trị thu được thì phải thông qua ví dụ Giả sử một dự án phần mềm gồm hai nhiệm vụ liên tiếp Giả thiết rằng các ước tính đã được xem xét lại và đã được chấp nhận và chi phí ngân sách đã được chấp thuận Các ngân sách đến thời điểm hoàn thành của hai nhiệm vụ tương ứng là 20000 USD và 30000 USD

Nhiệm vụ A: Giá trị được ước tính 20000 USD, được ước tính trong 2 tháng

Nhiệm vụ B: Giá trị được ước tính 30000 USD, được ước tính trong 3 tháng

Tổng dự án: Giá trị được ước tính 50000 USD, được ước tính trong 5 tháng

Giả sử sau một tháng, 12000 USD đã được sử dụng cho nhiệm vụ A và nhiệm vụ

AC của nhiệm vụ A và dự án phần mềm tại thời điểm một tháng là 12000 USD

EV của nhiệm vụ A và dự án phần mềm tại thời điểm một tháng là:

EV = phần trăm hoàn thành * Ngân sách dự kiến (BAC)

= 0.45 * 20000 USD = 9000 USD

17

Từ các độ đo trên, chúng ta có thể tính toán mức độ hiệu suất về giá trị và sai lệch về tiến độ của dự án phần mềm tại thời điểm một tháng và đưa ra các dự đoán

về giá trị dự án phần mềm và khoảng thời gian hoàn thành dự án phần mềm

Hình 1.3: Minh họa các độ đo PV, BAC, AC và EV

Bảng 1.2: Mức độ hiệu suất về giá trị và sai lệch về tiến độ [7]

SV = EV - PV Chênh lệch giá trị thu được so với

giá trị dự kiến (theo kế hoạch)

(Critical Ratio - CR) CR = CPI * SPI

Một độ đo sức khỏe dự án [8] Được miêu tả trong Bảng 1.3 Tổng hợp chỉ số chi phí thực tế và chỉ số tiến

độ thực hiện

Tiếp tục với ví dụ trên:

18

Chênh lệch chi phí (CV) = EV - AC = 9000 - 12000 = -3000 USD Diễn giải điều này như sau: 12000 USD đã được sử dụng để tạo ra 9000 USD Tiền đang được sử dụng nhiều hơn tiền thu được

Chỉ số chi phí thực tế (CPI) = EV/AC = 9000/12000 = 0.75 Nếu tiền được sử dụng chính xác thì CPI sẽ bằng 1.0 CPI nhỏ hơn một chỉ ra rằng chi phí hoàn tất công việc cao hơn so với kế hoạch

Chênh lệch chi phí do thay đổi tiến độ (SV) = EV - PV = 9000 - 10000 = -1000 USD Điều này được diễn giải như sau: 10000 USD theo kế hoạch sẽ được tạo ra trong tháng đầu tiên nhưng thực tế chỉ có 9000 được tạo ra như vậy chậm hơn so với kế hoạch

Chỉ số tiến độ thực thiện (SPI) = EV/PV = 9000/10000 = 0.9 Nếu dự án phần mềm phát triển theo đúng tiến độ thì SPI sẽ bằng 1 SPI nhỏ hơn 1 chỉ ra rằng dự án chậm hơn so với tiến độ

Tỷ lệ quan trọng (CR) = CPI * SPI = 0.75*0.9 = 0.675 Tỷ lệ quan trọng là độ đo sức khỏe dự án [8] Tỷ lệ quan trọng lớn hơn một là mong muốn, nhỏ hơn một chỉ

ra rằng dự án phần mềm chậm tiến độ hoặc chi phí không hiệu quả hoặc cả hai Chúng ta có thể thấy rằng CPI và SPI riêng biệt thì là các độ đo không đủ Giả thiết

dự án phần mềm có chi phí thực tế lớn hơn giá trị thu được (AC > EV hoặc CPI < 0) và dự án phần mềm vượt tiến độ (EV > PV hoặc SPI > 0) Dự án phần mềm có thể chi phí lớn hơn nhưng có thể hoàn thành sớm hơn Hoặc giả thiết rằng dự án phần mềm có chi phí thực tế nhỏ hơn giá trị thu được (EV > AC hoặc CPI > 0) và

dự án phần mềm chậm hơn so với tiến độ (EV < PV hoặc SPI < 0) Dự án phần mềm có thể chi phí nhỏ hơn nhưng có thể hoàn thành muộn hơn Hai trường hợp trên phụ thuộc nhiều vào dự án phần mềm cụ thể nhưng CR là độ đo ngặt nghèo của các dự án tiềm năng

Bảng 1.3: Tổng hợp các chỉ số hiệu quả về mặt chi phí và về mặt tiến độ [7]

CPI SPI CR Giá trị thu được Tiến độ Diễn giải

Giá trị thu được lớn hơn chi phí theo kế

hoạch

Chậm tiến độ

Giá trị thu được lớn hơn so với chi phí chi nhưng chậm tiến độ

< 1, EV < > 1, EV > Phụ Giá trị thu được nhỏ Vượt Chi phí vượt so với

19

AC PV thuộc hơn chi phí theo kế

hoạch tiến độ kế hoạch nhưng vượt tiến độ

1.4.3 Dự toán chi phí hoàn thành dự án phần mềm

Kỹ thuật giá trị thu được có thể được sử dụng để dự toán chi phí hoàn thành dự

án phần mềm Hai độ đo cần quan tâm là:

- Dự toán đến thời điểm hoàn thành (Estimate at Completion - EAC): Là kết quả

dự tính của nhà quản lý, về tổng chi phí của dự án phần mềm tính đến thời điểm hoàn thành từ thời điểm theo dõi hiện tại

- Dự toán để hoàn thành (Estimate to Completion - ETC): Là ước tính để hoàn thành dự án phần mềm thì cần phải bổ sung bao nhiêu chi phí nữa tính từ thời điểm theo dõi hiện tại

ETC và EAC phụ thuộc vào chênh lệch chi phí và nguyên nhân có thể có của các chênh lệch được tổng hợp trong bảng 1.4 dưới đây Chi phí ở bảng 1.4 đã cung cấp một cách để dự toán chi phí đến thời điểm hoàn thành các công việc của dự án phần mềm và dự toán chi phí tại thời điểm hoàn thành dự án phần mềm Bảng 1.4 cũng cung cấp hướng dẫn làm dự toán mới cho dự án phần mềm khi được yêu cầu

Bảng 1.4: Các dự toán chi phí để hoàn thành dự án phần mềm [7]

AC+ETC

Cần dự toán mới để hoàn thành công việc còn lại Các nguyên nhân có thể dẫn đến việc dự toán ban đầu sai là phạm vi dự án phần mềm được định nghĩa không đúng hoặc các tài nguyên cung cấp cho

dự án phần mềm phần mềm không chính xác

Diễn giải như sau: chi phí thử nghiệm vượt so với mong muốn EAC là chi phí AC cộng với dự toán chi phí tính đến thời điểm hoàn thành dự án phần mềm (BAC-EV)

Hiệu suất quá

(BAC-Dự toán chi phí ban đầu cho công việc còn lại (BAC-EV) được co giãn bởi hiệu suất tới ngày (1/CPI)

và được thêm chi phí cho thời gian tiếp theo (AC)

1.4.4 Dự toán thời gian triển khai dự án phần mềm

Tương tự như ETC và EAC, chúng ta cũng có thể dự toán thời gian tại thời điểm hoàn thành dự án phần mềm (Time Estimate At Completion) và dự toán thời gian đến thời điểm hoàn thành dự án phần mềm (Time Estimate To Completion), sử dụng các độ đo dưới đây:

- Tiến độ để hoàn thành (SAC): Đây là tiến độ được dự toán ban đầu để triển khai dự án phần mềm

- Thời gian thực tế (AT): Thời gian hoàn thành thực tế của dự án phần mềm

Bảng 1.5: Các dự toán thời gian để hoàn thành dự án phần mềm [7]

Không chênh lệch

Dự toán tiến độ ban đầu cho dự án phần mềm một cách chính xác, dự án phần mềm theo đúng tiến

độ

21

Dự toán thời gian

ban đầu không chính

xác

Phát sinh dự toán thời gian mới cho các công việc còn lại

AT + TETC

Cần dự toán thời gian mới cho các công việc còn lại Các nguyên nhân gây ra lỗi trong dự toán thời gian ban đầu là phạm vi được định nghĩa không rõ ràng hoặc hiểu

dự án phần mềm không chính xác

Tiến độ bị chậm

nhưng dự toán thời

gian ban đầu hợp lý

Dự toán thời gian ban đầu cho công việc còn lại

SAC - TV

Diễn giải như sau: thời gian thử nghiệm nhiều hơn mong muốn

Hiệu suất quá khứ là

độ đo tốt cho công

việc tương lai

(SAC-AT)/SPI SAC/SPI

Dự toán thời gian ban đầu cho công việc còn lại (SAC - AT) được co giãn bởi hiệu suất tới ngày (1/SPI) và được thêm thời gian đã sử dụng cho

Trong trường hợp này,

có chênh lệch thời gian nhưng được giả thiết rằng chênh lệch này sẽ được tạo ra bằng cách này hay cách khác Điều này là rất không thực tế Bảng trên cung cấp một cách để dự toán thời gian được yêu cầu để hoàn thành dự

án phần mềm và thời gian tổng thể cần thiết để hoàn thành dự án phần mềm

1.4.5 Sử dụng kỹ thuật giá trị thu được để kiểm soát dự án phần mềm

Chênh lệch chi phí và chênh lệch thời gian có thể được kiểm soát trên toàn bộ các tiến trình của dự án phần mềm Đây là cách để theo dõi tiến trình và cách để đánh giá hiệu quả các kiểm soát dự án Dưới đây là ví dụ trình bày cách CPI, SPI và

CR được vẽ biểu đồ và kiểm soát các tiến trình của dự án phần mềm [8]

22

Hình 1.4: Theo dõi hiệu quả dự án phần mềm sử dụng kỹ thuật giá trị thu được

Dự án phần mềm đang triển khai theo kế hoạch hoặc tốt hơn về khía cạnh chi phí khi đó CPI >=1 Dự án phần mềm đang triển khai theo kế hoạch hoặc tốt hơn về khía cạnh tiến độ khi đó SPI >= 1 Khi độ đo nào mà nhỏ hơn một, dự án phần mềm phải cần các độ đo chính xác Kỹ thuật giá trị thu được được sử dụng như là một hình thức phản hồi để kiểm soát dự án phần mềm dựa trên kế hoạch ban đầu Quá trình kiểm soát dự án phần mềm được minh họa dưới đây

Hình 1.5: Quá trình kiểm soát dự án phần mềm bằng kỹ thuật giá trị thu được [8]

1.4.6 Các hệ số thành công quan trọng của dự án phần mềm

Các hệ số thành công quan trọng (Critical Success Factors - CSFs) là tập các điều kiện được liên kết với một xác suất của dự án thành công cao hơn Cụ thể, nền tảng

Đo giá trị thực tế và

hoàn thành

CPI > 1

và SPI >1 Yes

Xác định hành động chính xác

No

23

về mặt kỹ thuật của đội dự án phần mềm là một hệ số thành công quan trọng Dự án phần mềm có đội được huấn luyện tốt, kỹ năng tốt và kinh nghiệm sẽ thành công hơn dự án phần mềm có đội ít kinh nghiệm hơn Có nhiều nghiên cứu về các hệ số thành công quan trọng trong các bài báo, báo cáo này trình bày một phân tích của ba bài báo [24, 25, 26]

Belassi [24] cho rằng các hệ số thành công quan trọng có thể được phân lớp thành bốn nhóm:

- Các hệ số liên quan tới dự án phần mềm

- Các hệ số liên quan tới quản lý dự án phần mềm và tới đội dự án phần mềm

- Các hệ số liên quan tới tổ chức

- Các hệ số liên quan đến môi trường bên ngoài

Các hệ số thành công quan trọng chi tiết được trình bày trong [24, 25, 26] có thể được ánh xạ thành bốn nhóm trên Tập các hệ số thành công quan trọng được lựa chọn trong báo cáo này không mang ý nghĩa tối ưu nhưng có thể phục vụ để trình bày một kỹ thuật để lượng giá dự án phần mềm bằng các hệ số thành công quan trọng

Một bảng đơn giản có thể được sử dụng để ước tính các dự án phần mềm dựa vào các hệ số thành công tiêu chuẩn được trình bày dưới đây

Bảng 1.6: Ước tính các hệ số thành công quan trọng cho dự án phần mềm ví dụ

Nhóm

Hệ số thành công tiêu chuẩn

Thấp (L) Trung bình

(M) Cao (H)

Thứ tự của

dự án phần mềm ví dụ

Dự án

Độ phức tạp về mặt

kỹ thuật

Kỹ thuật mới

Kỹ thuật biết tốt, cứng

Kỹ thuật biết tốt, dễ dàng

M

Dự án Phức tạp của các

yêu cầu

Phức tạp, không chắc chắn, chủ đề

để thay đổi

Phức tạp, nhưng ổn định

Đơn giản,

dễ dàng để hiểu

M

Quản lý dự

án

Các kỹ năng về mặt kỹ thuật

24

Quản lý dự

án

Giao tiếp dựa trên các kỹ năng

Đội dự án

Kinh nghiệm với các dự án tương tự

Không kinh nghiệm

Một vài thành viên trong đội có kinh nghiệm liên quan đến dự án

Phần lớn các thành viên trong đội có kinh nghiệm liên quan đến dự án

L

Tổ chức

Cẩn thận với quá trình xử lý phần mềm

Không có các quá trình

xử lý đặc biệt

Các quá trình xử lý

có khả năng lặp đi lặp lại

Các quá trình xử lý được tối ưu

M

Tổ chức

Người sử dụng tích cực trong các yêu cầu kiên quyết

Yếu

Giới hạn người sử dụng tham gia

Mở rộng người sử dụng tham gia

Thông

ĐIỂM (SCORE) 1.92

Trong Bảng 1.6, điểm (score) đã được tính toán như sau (3 * số lượng xếp hạng

H + 2 * số lượng xếp hạng M + số lượng xếp hạng thấp)/ số lượng các hệ số thành công tiêu chuẩn Chúng ta thấy rằng xếp hạng thứ tự chưa chắc đã là tối ưu nhưng các tổ chức có thể xác định các hệ số tương quan với các dự án thành công của các

tổ chức và các dự án mới đó có thể được xếp hạng dựa vào các hệ số này cho các mục đích dưới đây

25

- Như là một cổng trạng thái để xác định xem xét dự án tại tất cả các vấn đề Điểm nhỏ nhất nào đó sẽ được yêu cầu để thực hiện

- Như cách để đánh giá khả năng thành công của các dự án khác nhau Điều này

sẽ phục vụ như là một trong các tiểu chuẩn lựa chọn dự án

1.5 Kết luận chương

Trong chương này, đầu tiên tác giả đã trình bày những quan điểm khác nhau về giá trị CNTT Sau đó, tác giả đã đưa ra phạm vi nghiên cứu, qui trình nghiên cứu của đề tài Tiếp đến, tác giả trình bày kỹ thuật giá trị thu được và các kỹ thuật các yêu cầu phục vụ trong việc lượng giá dự án phần mềm

Như vậy, chúng ta thấy kỹ thuật giá trị thu được đóng một vai trò có ích trong việc theo dõi và kiểm soát chi phí và tiến độ trong các dự án phần mềm Kỹ thuật giá trị thu được có hiệu quả trong việc kiểm soát dự án phần mềm dựa trên kế hoạch ban đầu Kỹ thuật giá trị thu được đo thành công quản lý dự án hơn là dự án thành công Kỹ thuật giá trị thu được đo sự phù hợp của kế hoạch ban đầu Không xem xét rõ ràng kế hoạch này ảnh hưởng đến vấn đề tài chính hoặc ảnh hưởng đến các yêu cầu giá trị của người sử dụng

Mặt khác, chúng ta cũng thấy có các yêu cầu tốt là một bước quan trọng trong việc lượng giá dự án phần mềm Nếu định nghĩa không rõ ràng về những gì cần được thực hiện, trong phần mềm và thương mại được liên kết với nhau và các thay đổi của tiến trình thì có ít hy vọng trong việc lấy giá trị của những người sử dụng

Có vài kỹ thuật (phương pháp hiểu rõ các lợi ích, MBASE và kỹ thuật các yêu cầu dựa trên mục tiêu) được tổng hợp và trình bày như là các các kỹ thuật để lấy ra các yêu cầu tốt trong việc lượng giá dự án phần mềm

Các hệ số thành công quan trọng của dự án phần mềm có ích trong dự đoán các khả năng của dự án thành công và là độ đo phân biệt cho việc lựa chọn dự án phần mềm

Trong trường hợp có nhiều dự án phần mềm, một câu hỏi đặt ra lượng giá các dự

án phần mềm này như thế nào? Với phạm vi nghiên cứu của đề tài, trong chương

26

tiếp theo tác giả sẽ nghiên cứu và trình bày những kỹ thuật định tính để lượng giá các dự án phần mềm trong trường hợp triển khai nhiều dự án phần mềm cùng một lúc, cụ thể gồm các kỹ thuật sau: Kỹ thuật thẻ điểm cân bằng và kỹ thuật quản lý danh sách vốn đầu tư dự án phần mềm Sau đó trình bày mô hình lượng giá dự án phần mềm theo nhiều khía cạnh khác nhau, nghĩa là kết hợp của nhiều kỹ thuật lượng giá định tính và định lượng dự án phần mềm với nhau