Công nghệ phần mềm hướng giá trị bài toán kiểm định chất lượng phần mềm sử dụng phương pháp hướng giá trị

Công nghệ phần mềm hướng giá trị Bài toán kiểm định chất lượng phần mềm sử dụng phương pháp hướng giá trị Công nghệ phần mềm hướng giá trị Bài toán kiểm định chất lượng phần mềm sử dụng phương pháp hướng giá trị

MỤC LỤC

MỤC LỤC 1

DANH MỤC CÁC BẢNG 3

DANH MỤC HÌNH VẼ 4

DANH MỤC CÁC TỪ VIẾT TẮT 5

MỞ ĐẨU 6

CHƯƠNG 1: TỔNG QUAN VỀ CÔNG NGHỆ PHẦN MỀM HƯỚNG GIÁ TRỊ 8

1 Các lý thuyết về hệ thống phần mềm 8

1.1 Mô hình lập trình và sửa lỗi (Code and Fix Model) 8

1.2 Mô hình thác nước (The Waterfall Model) 9

1.3 Mô hình xoắn ốc (The Spiral Model) 11

1.4 Mô hình tạo mẫu nhanh (The Rapid ProtoTyping Model) 13

2 Công nghệ phần mềm hướng giá trị 14

2.1 Tổng quan các vấn đề 14

2.2 Ngắt kết nối ngữ cảnh 14

2.3 Ngắt kết nối giá trị các bên liên quan 16

2.4 Công nghệ phần mềm hướng giá trị 17

2.5 Mô hình lý thuyết W 20

3 Mô hình chất lượng 30

3.1 Phân loại 30

3.2 Mô hình phần mềm đáng tin cậy 34

3.3 Chi phí chất lượng phần mềm 36

4 Kết chương 37

CHƯƠNG 2: PHƯƠNG PHÁP PHÂN TÍCH CHẤT LƯỢNG PHẦN MỀM THEO HƯỚNG GIÁ TRỊ VÀ ĐỀ XUẤT ÁP DỤNG TẠI TRUNG TÂM CNTT-AGRIBANK 39

1 Phương pháp phân tích chất lượng theo mô hình hướng giá trị 39

1.1 Những nhân tố chính 39

1.1.1 Điểm lại chi phí về chất lượng phần mềm 39

1.1.2 Các nhân tố ảnh hưởng 41

1.2 Mô hình phân tích 44

1.2.1 Khái niệm cơ bản 44

1.2.2 Mô hình Thành phần 47

1.3 Mô hình thực nghiệm 51

1.3.1 Khái niệm cơ bản 51

1.3.2 Thành phần 52

1.4 FrameWork cụ thể ứng dụng mô hình lý thuyết W 53

2 Đề xuất Mô hình đánh giá chất lượng phần mềm, ứng dụng cho Phòng CoreBanking – Trung tâm Công nghệ thông tin Agribank 57

3 Kết chương 61

CHƯƠNG 3 : THỬ NGHIỆM VÀ ỨNG DỤNG THỰC TẾ 63

1 Các bước tiến hành triển khai mô hình đề xuất tại Phòng CoreBanking – Trung tâm CNTT – Agribank 63

1.1 Xây dựng module mẫu: Hệ thống thu phí tự động cho các tài khoản trên IPCAS 63

1.2 Các ứng dụng sau hệ thống mẫu 66

1.2.1 Hệ thống in phiếu khuyến mại tự động 66

1.2.2 Hệ thống VAMC 67

2 Hệ thống in phiếu dự thưởng trong hệ thống IPCAS 69

3 Kết chương 74

KẾT LUẬN VÀ KIẾN NGHỊ 75

1 Kết luận 75

2 Kiến nghị 76

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

TÀI LIỆU THAM KHẢO 78

PHỤ LỤC 79 Phụ lục 1 : Chương trình in phiếu dự thưởng Error! Bookmark not defined Phụ lục 2 : Chương trình tính phí tự động Error! Bookmark not defined

DANH MỤC CÁC BẢNG

Bảng 1 : Sự được và mất của các đối tượng tham gia[1] 21

Bảng 2 : Các lớp lợi ích 55

Bảng 3 : Số lượng giao dịch và tài khoản trung bình theo năm[4] 57

Bảng 4 : Các trường hợp ví dụ áp dụng cho mô hình đề xuất 60

Bảng 5 : Nhân sự tham gia trong dự án thu phí tự động 64

Bảng 6 : Chi phí khi phải sửa lỗi trước khi phát hành phiên bản 64

Bảng 7 : Chi phí phải sửa lỗi sau khi phát hành phiên bản 64

Bảng 8 : Tổng hợp chi phí cho dự án thu phí tự động 65

Bảng 9 : Kế hoạch nhân sự cho dự án in phiếu khuyến mại tự động 66

Bảng 10 : Tổng h ợp chi phí cho dự án in phiếu tự động 67

Bảng 11 : Kế hoạch nhân sự cho dự án VAMC 68

Bảng 12 : Tổng hợp chi phí cho dự án VAMC 69

Bảng 13 : Lợi ích hệ thống in phiếu tự động 73

Bảng 14 : Kế hoạch thực hiện 74

DANH MỤC HÌNH VẼ

Hình 1 : Mô hình Code and fix[1] 8

Hình 2 : Mô hình thác nước[1] 10

Hình 3 : Mô hình xoắn ốc[1] 12

Hình 4 : Mô hình tạo mẫu nhanh[1] 13

Hình 5: Chuỗi lợi ích theo mô tả của hệ ngữ cảnh hệ thống phần mềm[1] 15

Hình 6 : Hướng giá trị so với hướng tự nhiên[1] 18

Hình 7: Hiệu quả của phần mềm và sự biến động cổ phiếu trong rủi ro[1] 19

Hình 8 : Ngữ cảnh của tổ chức[1] 19

Hình 9 : Lý thuyết 4+1 – Các chìa khóa để xây dựng[1] 24

Hình 10 : Mô hình kết hợp sự phụ thuộc[1] 26

Hình 11: Giá trị của các bên tham gia ảnh hưởng lẫn nhau[1] 27

Hình 12 : Các lớp mô hình chất lượng [2] 32

Hình 13 : Các loại chi phí[2] 37

Hình 14 : Định nghĩa các loại chi phí[2] 40

Hình 15 : Sự lan truyền các khuyết tật thông qua tài liệu[2] 47

Hình 16 : Các thành phần chi phí trực tiếp[2] 48

Hình 18 : Frame Work theo các tiến trình 54

Hình 19 : Quy trình làm khuyến mại 71

Hình 20 : Mô hình công việc của người làm trực tiếp 72

DANH MỤC CÁC TỪ VIẾT TẮT

SCSs : success‐critical stakeholders

BRA : Benefits Realization Approach

VBSE : Value‐Based Theory for Developing Software Systems

COTS : commercial off‐the‐shelf

QA : Quality assurance

SQA : software quality assurance

KLOC : Kilo lines of Code

ROI : return on investment

PAF : Prevention, Appraisal, Failure

 Tính cấp thiết của đề tài

Hiện tại, phương pháp mà đề tài nghiên cứu trong phát triển phần mềm là hướng trên giá trị Dựa trên những giá trị này để ra quyết định và thực hiện các khâu trong phát triển phần mềm, và những giá trị này thường là những giá trị về mặt lợi ích cụ thể nó nên được đại diện bởi đơn vị tiền tệ như VND hay USD Để tài cũng đưa ra mô hình phần tích lợi ích của các bên liên quan đối với phần mềm, kết nối ngữ cảnh và kết nối giá trị với các bên liên quan, cũng như đưa ra một số mô hình về chi phí lợi ích và đánh giá phần mềm dựa trên kết quả lợi ích thu về

2 Mục đích của đề tài (các kết quả cần đạt được):

Mục đích nghiên cứu chính của đề tài nhằm hiểu được công nghệ phần mềm hướng giá trị, tìm hiểu một số mô hình công nghệ phần mềm hướng giá trị cũng như những trường hợp thực hiện thực tiễn của những mô hình trên

3 Nội dung của luận văn (Gồm 3 chương)

Mở đầu

Chương 1 : Tổng quan về công nghệ phần mềm hướng giá trị

Chương 2 : Phương pháp phân tích chất lượng phần mềm theo hướng giá trị và đề xuất áp dụng tại trung tâm CNTT - AGRIBANK

Chương 3 : Thử nghiệm và áp dụng thực tế

Kết luận

Trong quá trình thực hiện Luận văn, do thời gian cũng như trình độ còn hạn chế nên không thể tránh khỏi những thiếu sót Rất mong nhận được sự góp ý của các thầy, cô giáo và các bạn để Luận văn hoàn thiện hơn Tôi xin chân thành cảm ơn sự hướng dẫn,

giúp đỡ tận tình của thầy hướng dẫn: TS Phùng Văn Ổn các thầy trong viện công nghệ

thông tin và truyền thông – Đại học Bách khoa Hà Nội đã giúp đỡ tôi trong quá trình học tập cũng như trong quá trình làm Luận văn

CHƯƠNG 1: TỔNG QUAN VỀ CÔNG NGHỆ PHẦN MỀM

HƯỚNG GIÁ TRỊ

1 CÁC LÝ THUYẾT VỀ HỆ THỐNG PHẦN MỀM

Xem xét các tài liệu liên quan đến hệ thống phần mềm cho thấy, có nhiều giả thuyết khác nhau được sử dụng trong quá trình phát triển hệ thống phần mềm Trong đó, một số lý thuyết này còn hạn chế đối với dự toán chi phí, một số để làm kiến trúc và thiết kế, và một số khác cho rằng nhiều hoạt động khác nữa có liên quan đến quá trình phát triển Tuy nhiên, những nhận xét này có được giới hạn trong mô hình lý thuyết vòng đời cung cấp hỗ trợ trong (a) hướng dẫn các hoạt động cốt lõi của phát triển và (b) cố gắng một cách rõ ràng để trả lời "làm thế nào tốt nhất để phát triển một hệ thống phần mềm" Trong phần tiếp theo chúng ta sẽ xem xét các mô hình vòng đời khác nhau đã tăng lên nhanh chóng trong lĩnh vực hệ thống phần mềm

1.1 Mô hình lập trình và sửa lỗi (Code and Fix Model)

Mô hình lập trình và sửa lỗi (thường được gọi là cách tiếp cận xâm nhập) có lẽ là mô hình bị chỉ trích nhiều nhất trong việc phát triển hệ thống phần mềm do thiếu kỷ luật Điều này là do nó bắt đầu với ít hoặc không có kế hoạch ban đầu Tuy nhiên, lập trình và sửa lỗi vẫn tiếp tục là một sự lựa chọn rộng rãi cho thấy các nhà phát triển phần mềm, đặc biệt là khi họ đang phải đối mặt với một lịch trình phát triển chặt chẽ

HÌNH 1 : MÔ HÌNH CODE AND FIX[1]

Lập trình và sửa lỗi là: “mô hình cơ bản được sử dụng trong những ngày đầu của phát triển phần mềm , nó gồm có hai bước sau: (a) Viết một số mã, (b) Sửa chữa các vấn đề trong các mã Vì vậy, thứ tự của các bước là trước hết làm một số mã hóa đầu tiên và sau đó suy nghĩ về các yêu cầu, thiết kế, kiểm tra, bảo trì Sau đó, mô hình 2 bước (lập trình và sửa lỗi) lặp đi lặp lại cho đến khi dự án được công bố hoàn thành hoặc hủy bỏ

Có hai lợi thế quan trọng của việc sử dụng các mô hình lập trình và sửa lỗi Đầu tiên, nó không có chi phí về thời gian dành cho việc lập kế hoạch, tài liệu, xác minh và xác nhận Thứ hai, nó đòi hỏi chuyên môn rất ít vì nó không có bất kỳ yêu cầu chính thức cho ứng dụng - bất cứ ai viết phần mềm (mà không sử dụng bất kỳ lý thuyết chính thức khác) là

sử dụng lập trình và sửa lỗi theo mặc định

Tuy nhiên, mô hình này có phần khó khăn quá Đầu tiên, vì nó không đòi hỏi các giá trị các bên liên quan được xác định và lý giải rõ ràng, phần mềm kết quả kém có thể không đúng với nhu cầu của các bên liên quan, do đó kết quả là hoàn toàn có thẻ bị bác bỏ phải làm lại Thứ hai, kể từ khi thực hiện do không tham gia vào bất kỳ thiết kế trước, nên sau khi một số bản sửa lỗi, phần mềm thường trở nên phi cấu trúc mà các bản sửa lỗi khác trở nên rất khó khăn Thứ ba, khi không có bất kỳ kế hoạch xác minh và xác nhận, các phần mềm trở nên rất tốn kém để sửa chữa trong các giai đoạn sau Trong quá trình các lý thuyết của hệ thống phần mềm, lập trình và sửa lỗi có lẽ là lý thuyết đầu tiên, mặc dù tính lý thuyết có thể là ít, nhưng nó chắc chắn là một thực hành quan sát

So với nghiên cứu này, các mô hình lập trình và sửa lỗi là cả giá trị các bên liên quan và các ngữ cảnh bị ngắt kết nối với nhau trong quá trình tiếp cận

1.2 Mô hình thác nước (The Waterfall Model)

Mô hình thác nước là một mô hình phát triển phần mềm chuỗi, trong đó phát triển được xem là chảy dần xuống dưới (như một thác nước) thông qua các giai đoạn của phân tích yêu cầu, thiết kế, thực hiện, kiểm tra (xác nhận), tích hợp và bảo trì (Wikipedia.com) Mô hình thác nước thường được gọi là mô hình cổ điển cho việc phát triển hệ thống phần mềm Đầu tiên tài liệu của Winston W Royce vào năm 1970, nó có lẽ vẫn là quá trình phát triển phần mềm sử dụng rộng rãi nhất, trong dạng này hay dạng khác Vòng đời thác nước bao gồm nhiều giai đoạn không chồng chéo, như thể hiện trong hình dưới Mô hình này bắt đầu bằng việc thiết lập các yêu cầu hệ thống và yêu cầu phần mềm và tiếp tục với thiết kế kiến trúc, thiết kế chi tiết, mã hóa, kiểm tra và bảo trì Mỗi giai đoạn trong mô

hình thác nước kết luận với một đánh giá để xác định xem dự án đã sẵn sàng để tiến tới giai đoạn tiếp theo hoặc tiếp tục lặp lại giai đoạn hiện tại hoặc sẽ trở lại giai đoạn trước

Mô hình thác nước hôm nay tiếp tục phục vụ như một cơ sở cho nhiều mô hình vòng đời khác

HÌNH 2 : MÔ HÌNH THÁC NƯỚC [1]

Mô hình thác nước làm việc tốt nhất cho các dự án có một định nghĩa sản phẩm ổn định

và các phương pháp kỹ thuật được tìm hiểu, và nó có hiệu quả nếu các cán bộ dự án là thiếu kinh nghiệm vì nó cung cấp cho dự án với một cấu trúc giúp trong việc giảm thiểu làm lại Tuy nhiên bất lợi cơ bản của mô hình thác nước là nó nhấn mạnh trên các tài liệu xây dựng đầy đủ như tiêu chuẩn hoàn thiện cho các yêu cầu và giai đoạn thiết kế vào đầu của dự án Vì trong nhiều trường hợp một số yêu cầu và các vấn đề thiết kế chỉ được phát hiện sau khi xây dựng đã bắt đầu, sửa đổi nội dung trong giai đoạn tiếp theo có thể dẫn đến một thiết kế nghèo nàn Cuối cùng là mô hình thác nước đòi hỏi yêu cầu một hệ thống phần mềm được xác định trước tuy nhiên, khi việc kinh doanh vẫn chỉ xuất hiện trong ý tưởng sản phẩm được sử dụng, yêu cầu hệ thống thường xuất hiện trước các chỉ dẫn

Để giải quyết một số vấn đề trong mô hình thác nước cổ điển, một số "thác nước sửa đổi"

mô hình đã được đề xuất trong các năm tiếp theo, những sửa đổi đã tập trung vào việc cho phép một số giai đoạn chồng lên nhau, do đó làm giảm các yêu cầu tài liệu và các chi phí quay trở lại giai đoạn trước đó để sửa lại chúng Một sửa đổi chung đã được kết hợp tạo mẫu thành các giai đoạn yêu cầu Trong khi chồng chéo các giai đoạn, chẳng hạn như giai đoạn yêu cầu và giai đoạn thiết kế làm cho nó có thể tích hợp thông tin phản hồi từ giai đoạn thiết kế thành các yêu cầu, vì thế khó xác định khi mỗi giai đoạn kết thúc, khi tiến tới giai đoạn tiếp theo Do đó, tiến độ là khó xác định và theo dõi hơn Nếu không có giai đoạn khác nhau, vấn đề có thể gây trì hoãn các quyết định quan trọng cho đến khi sau này trong quá trình khi đó tốn kém nhiều để sửa chữa

Mặc dù mô hình thác nước nói chung đã bị chỉ trích vì bất lợi của nó, song nó vẫn được

ưa thích trong giới quản lý nhất định Lý do là mô hình thác nước có đơn giản giải thích

và thu hồi, và nó mang lại cho cảm giác kiểm soát, một "trật tự, dự đoán, trách nhiệm, và quá trình, với cột mốc đơn giản tài liệu điều khiển, chẳng hạn như yêu cầu hoàn thành"

So với nghiên cứu này, mô hình thác nước ở một mức độ nắm bắt được giá trị các bên liên quan trong hình thức của một tài liệu yêu cầu Tuy nhiên, giá trị các bên liên quan, như giải thích ở trên, thường thay đổi, có thể gây ra vấn đề tốn kém trong vòng đời Ngoài ra, mô hình thác nước không thực hiện kết nối rõ ràng giữa các giá trị các bên liên quan và các hoạt động phát triển, chẳng hạn như trong kiến trúc hoặc thử nghiệm Cuối cùng, mô hình thác nước cũng bị ngắt kết nối với ngữ cảnh của nó

1.3 Mô hình xoắn ốc (The Spiral Model)

Việc giải quyết những bất cập của mô hình thác nước, đề xuất các mô hình xoắn ốc Ý tưởng cơ bản của mô hình xoắn ốc là bắt đầu trên một quy mô nhỏ ở giữa cột sống, khám phá những rủi ro, lập kế hoạch để xử lý các rủi ro, và cam kết một cách tiếp cận cho phiên bản kế tiếp, sau khi các rủi ro chính có tất cả được giải quyết, các mô hình xoắn ốc chấm dứt như một mô hình vòng đời thác nước

Giá trị cốt lõi của mô hình xoắn ốc là quản lý rủi ro, vấn đề lớn có thể được tìm thấy sớm hơn nhiều trong chu kỳ phát triển Ví dụ, trong mô hình thác nước, thiết kế phần mềm phải được hoàn tất trước khi xây dựng Với mô hình xoắn ốc, một dự án được chia thành một tập hợp các rủi ro có hướng dẫn quá trình phát triển Cho mỗi xoắn ốc (hoặc lặp đi lặp lại), nó đòi hỏi những nguy cơ quan trọng nhất được phân tích và giải quyết, chỉ sau

khi mà dự án có thể tiến hành các vấn đề tiếp theo (có nghĩa là, rủi ro theo thứ tự quan trọng)

Mô hình xoắn ốc làm tăng chi phí nhưng rủi ro giảm, và nếu rủi ro là không thể vượt qua,

mô hình sẽ cung cấp cho dự án là một dấu hiệu sớm, mà sẽ tiết kiệm thời gian và tiền bạc Tuy nhiên, mô hình này cũng có hai nhược điểm Đầu tiên, nó là phức tạp, đòi hỏi phải có lương tâm, chu đáo, và có kiến thức quản lý, thứ hai, trong nhiều trường hợp, các

mô hình xoắn ốc là không dễ phân huỷ thành các cấp độ dần dần tốt hơn các chi tiết trong

dự án phát triển phần mềm trong thế giới thực

HÌNH 3 : MÔ HÌNH XOẮN ỐC[1]

So với nghiên cứu này, mô hình xoắn ốc lặp đi lặp lại cố gắng để nắm bắt giá trị các bên liên quan trong các hình thức của mục tiêu, hạn chế và ưu tiên, và rủi ro tuy nhiên, nó làm cho không có kết nối rõ ràng với bối cảnh tổ chức Ví dụ, nó không yêu cầu tổ chức

phụ thuộc như môi trường được xác định Cuối cùng, nó không có gì để nói về giám sát tiến độ dự án đối với các giá trị liên quan với

1.4 Mô hình tạo mẫu nhanh (The Rapid ProtoTyping Model)

Mô hình tạo mẫu nhanh như các loại quy trình nhằm giảm sự không chắc chắn yêu cầu thông qua các yêu cầu thay đổi của các khía cạnh của hành vi hệ thống Mô hình tạo mẫu nhanh cho phép các nhà phát triển hệ thống để tạo ra các phần nổi bật nhất của một chương trình như một mẫu thử nghiệm và sau đó làm việc với người sử dụng để tinh chỉnh nó cho đến khi các mẫu thử nghiệm là tốt

Khi được chấp nhận, các mẫu thử nghiệm hoặc trở thành cơ sở cho các sản phẩm cuối cùng hoặc bị loại bỏ

HÌNH 4 : MÔ HÌNH TẠO MẪU NHANH[1]

Như đã đề cập, một trong những vấn đề chính với mô hình thác nước là yêu cầu thường xuyên không được hiểu rõ trong các giai đoạn phát triển ban đầu Mô hình nguyên mẫu nhanh thay vì phục vụ như một công cụ hiệu quả để chứng minh rằng một giải pháp đáp ứng một loạt các yêu cầu Người ta có thể xây dựng một nguyên mẫu, điều chỉnh các yêu cầu, và sửa đổi các mẫu thử nghiệm nhiều lần cho đến khi tất cả các bên liên quan có một hình ảnh rõ ràng về các giải pháp tổng thể Ngoài việc làm rõ các yêu cầu, một mô hình nguyên mẫu cũng xác định nhiều lĩnh vực thiết kế cùng một lúc

Tuy nhiên sức mạnh của nó cũng là nguồn gốc của sự yếu kém lớn nhất của nó Vì nó có thể làm các bên liên quan thấy rằng có tồn tại một hệ thống làm việc, họ có thể mong đợi một hệ thống hoàn chỉnh sớm hơn là có thể Trong hầu hết các trường hợp, nguyên mẫu được xây dựng trên sự thỏa hiệp cho phép nó để đến với nhau một cách nhanh chóng nhưng ngăn chặn các mẫu thử nghiệm, từ một cơ sở có hiệu quả cho sự phát triển trong

tương lai Ngoài ra, sử dụng một mô hình mẫu thường có thể trở thành một ngụy trang cho một chu kỳ phát triển mã và sửa chữa Cuối cùng, nó làm cho nó theo nghĩa đen không thể thực hiện bất kỳ ước tính về chi phí, tiến độ các dự án phát triển hệ thống phần mềm

So với nghiên cứu này, các mô hình tạo mẫu nhanh trong khi cố gắng để nắm bắt một số giá trị các bên liên quan thông qua mẫu lặp đi lặp lại, nó làm như vậy với chi phí từ phụ thuộc nhiều thuộc tính mong muốn khác của một hệ thống phần mềm Ví dụ, một vấn đề

cố hữu trong cách tiếp cận tạo mẫu nhanh là nó không mở rộng quy mô cho các ứng dụng lớn, hoặc không sử dụng các ứng dụng theo định hướng giao diện Ngoài ra, mô hình tạo mẫu nhanh cũng bị ngắt kết nối từ ngữ cảnh của nó

2 CÔNG NGHỆ PHẦN MỀM HƯỚNG GIÁ TRỊ

2.1 Tổng quan các vấn đề

Những thiếu sót của thực tiễn hiện tại là gì?

Có rất nhiều lý do có thể và giải thích cho một trạng thái ảm đạm của các vấn đề trong phát triển hệ thống phần mềm Nghiên cứu này cung cấp hai cách giải thích trong việc tìm hiểu một số vấn đề Đầu tiên, thực tiễn hiện tại chủ yếu là bị ngắt kết nối từ các ngữ cảnh (tổ chức và môi trường) – do đó, phạm vi của họ (đơn vị phân tích) là quá hạn chế Thứ hai, thực tiễn hiện tại đang bị ngắt kết nối từ các giá trị liên quan - đó là, có hướng dẫn quá trình nhỏ về cách tốt nhất để giải quyết vấn đề giá trị các bên liên quan trong việc cân bằng khi các đặc tính mong muốn (bộ tính năng, bảo mật, dễ sử dụng) của một

hệ thống là một trong hai mâu thuẫn, cạnh tranh hoặc phụ thuộc vào nhau cho nguồn lực hạn chế

2.2 Ngắt kết nối ngữ cảnh

Phát triển hệ thống phần mềm dựa trên một tập hợp các đặc điểm kỹ thuật chính thức không đảm bảo rằng hệ thống sẽ tạo ra các giá trị dự kiến phù hợp cho các bên liên quan Kết nối rõ ràng giữa hệ thống phần mềm và bối cảnh tổ chức phải thực sự được xem xét Phương pháp tiếp cận lợi ích thực (Benefits Realization Approach - BRA) là phương pháp để hiển thị như thế nào các sáng kiến phần mềm phải được kết nối với bối cảnh tổ chức để thành công trong việc thực hiện các lợi ích mong đợi Nghiên cứu mở rộng cách tiếp cận của họ bằng cách yêu cầu các bên liên quan đến sự thành công thành công phải được xác định một cách rõ ràng trong bối cảnh

Hình dưới cho thấy bối cảnh tổ chức của một hệ thống để xử lý mà công ty đã đặt ra để phát triển đáp ứng những thiếu sót của hệ thống hiện có của nó Sơ đồ này cho thấy một chuỗi lợi ích kết nối một hệ thống phần mềm với bối cảnh của nó bằng cách liên kết các sáng kiến phần mềm hệ thống (ví dụ, thực hiện một hệ thống đơn hàng mới cho bán hàng) để đóng góp (không có hệ thống phân phối, nhưng nó tác động về hoạt động tồn tại hiện có) và kết quả, mà có thể dẫn đến là tiếp tục đóng góp hoặc gia tăng giá trị (ví dụ, tăng việc bán hàng) Nó cũng giúp phát hiện ra các giả định thường ẩn trong bối cảnh tổ chức mà thành công của hệ thống phần mềm phụ thuộc Ví dụ, nếu thị trường trì trệ do sự kiện bất khả kháng, dẫn đến giảm thời gian để cung cấp các sản phẩm thì doanh số bán hàng giảm xuống

HÌNH 5: CHUỖI LỢI ÍCH THEO MÔ TẢ CỦA HỆ NGỮ CẢNH HỆ THỐNG PHẦN

MỀM[1]

Bằng cách bao gồm bối cảnh tổ chức, các thành viên dự án một hệ thống phần mềm có thể làm việc với các bên liên quan để xác định hoạt động không phải về phần mềm để bổ sung có thể là cần thiết để nhận ra giá trị của các bên liên quan có liên quan đến các sáng

kiến phần mềm hệ thống Ngữ cảnh cũng giúp trong việc xác định các bên liên quan một

số phân tích cụ thể quan trọng khác, những người cần được đại diện và đưa tham gia vào nhóm dự án

Ví dụ, các sáng kiến để thực hiện một hệ thống đơn hàng mới có thể làm giảm thời gian cần thiết để xử lý đơn đặt hàng chỉ khi một sáng kiến khác để thuyết phục các nhân viên bán hàng rằng hệ thống mới sẽ tốt cho sự nghiệp của họ và đào tạo họ làm thế nào để sử dụng hệ thống hiệu quả Nếu hệ thống đơn hàng là rất hiệu quả tối ưu hóa nhưng nó không theo dõi các khoản tín dụng bán hàng, nhân viên bán hàng sẽ đấu tranh không sử dụng phần mềm đó, để bán hàng để tăng cũng có thể yêu cầu thêm một tính năng để theo dõi các khoản tín dụng bán hàng để người bán hàng sẽ muốn sử dụng hệ thống mới Hơn nữa, giảm chu trình xử lý đơn hàng sẽ làm giảm thời gian để cung cấp sản phẩm chỉ khi các sáng kiến bổ sung được đưa ra kịp thời để phối hợp các hệ thống đơn hàng với hệ thống thực hiện đơn hàng

Chuỗi lợi ích là một trong nhiều cách để kết nối với một hệ thống phần mềm với ngữ cảnh của nó

2.3 Ngắt kết nối giá trị các bên liên quan

Quyết định về hệ thống phần mềm thường được thực hiện trong các điều kiện khác nhau

về chi phí, tiến độ, chất lượng, tính năng, thực hành tốt so với thực tế xấu, kỹ thuật, hoặc phương pháp điều khiển Thật không may, những yếu tố trên không có gì để nói về giá trị của các bên liên quan Vì vậy , thực tiễn hiện tại vẫn bị ngắt kết nối từ giá trị các bên liên quan

Ví dụ, chấp nhận thử nghiệm thường là bước cuối cùng trong vòng đời phát triển của hệ thống Nó được thực hiện bởi khách hàng trước khi chấp nhận giao hàng hoặc nhận chuyển quyền sở hữu Nó bao gồm một tập hợp các phần mềm theo định hướng kiểm tra

sự chấp thuận của khách hàng như tiêu chí đủ điều kiện phát triển thành công Vì vậy, một chấp nhận thử nghiệm cũng như một cam kết ràng buộc giữa các nhà phát triển và khách hàng

Theo ý nghĩ về mặt pháp lý, điều này chắc chắn là được nhắc đến Tuy nhiên, trong một

hệ thống phần mềm, chẳng hạn như một hệ thống xử lý đơn hàng đã được phát triển để giảm chi phí hoạt động, tăng thị phần, tăng sự hài lòng của khách hàng và sự hài lòng của nhân viên, một thử nghiệm như vậy sẽ chỉ có nghĩa là phần mềm tuân thủ một số hành vi

theo yêu cầu của nó khách hàng Đây không phải là một hạn chế của việc thực hành thử nghiệm chấp nhận cho mỗi gia nhập, mà là trong thực hành hướng dẫn quy trình kiểm tra nghiệm thu

Vấn đề với cách tiếp cận là không cung cấp bất kỳ hướng dẫn bao nhiêu thử nghiệm là đủ hoặc cách tiếp cận khác nhau đối với kiểm tra ảnh hưởng của các giá trị bên liên quan Một lần xuất hiện phổ biến trong cách thực hành phần mềm được thiết kế là họ bị ảnh hưởng bởi các nguyên tắc hướng dẫn mà đã nổi lên như phổ biến và vượt thời gian Chất lượng đã trở thành một nguyên tắc hướng dẫn như vậy và đã thống trị hai thập kỷ qua về

kỹ thuật trong các hình thức như các mô hình trưởng thành năng lực Tìm hiểu không ngừng về chất lượng đã làm trong nhiều tổ chức, trong khi những người khác đã phải vật lộn với nó

Chất lượng đã được sử dụng cho mỗi gia nhập thực hiện chưa được tuyên bố chiến lược

và kinh tế rõ ràng Ví dụ rằng nếu một ngân hàng khuyến khích cán bộ tín dụng của mình giảm thiểu tỷ lệ phần trăm của các khoản nợ xấu, quan chức của mình sẽ sớm khám phá

ra rằng bằng cách giảm số lượng tổng thể của khoản vay mà họ có thể làm giảm tỷ lệ nợ xấu Điều này, tuy nhiên, sẽ mang lại ít tiền cho ngân hàng Trong khi theo đuổi chất lượng nói chung là tốt, nó không thay thế cho các trình điều khiển giá trị khác

2.4 Công nghệ phần mềm hướng giá trị

Tại sao các phương pháp tiếp cận dựa trên giá trị tốt hơn?

Các chuẩn IEEE định nghĩa "phần mềm kỹ thuật" như một "cách tiếp cận định lượng cho

sự phát triển, vận hành và bảo trì phần mềm" Tuy nhiên một phương pháp kỹ thuật tiếp cận dựa trên giá trị không thành lập trên nguyên tắc định lượng so với chất lượng, đúng

so với sai, nhưng được xây dựng dựa trên định nghĩa về "kỹ thuật" của Webster - và do

đó liên kết hướng tới "hữu ích" (giá trị) cho các bên liên quan Nếu mục đích của việc phát triển một hệ thống phần mềm là để làm cho nó hữu ích cho các bên liên quan, sau đó một cách tiếp cận dựa trên giá trị sẽ mang lại kết quả tốt hơn

Kinh doanh luôn có mục mục tiêu cuối cùng là tối đa hóa lợi nhuận, và vì thế luôn có những cơ hội để cải thiện quá trình (hoặc các khoản đầu tư khác) hơn là có những nguồn lực sẵn có Không bao giờ có "đủ" tiền để "làm đúng" cho bất cứ ai Các doanh nghiệp có

hệ thống tương tác cao, trong đó mỗi chức năng ảnh hưởng đến toàn bộ bằng nhiều cách

khác nhau Không có gì là vô dụng hơn một chức năng đã được tối ưu hóa cao trong sự

cô lập

Ý tưởng dựa trên tinh thần phương pháp tiếp cận dựa trên giá trị Sử dụng một ống kính dựa trên giá trị, phát triển hệ thống phần mềm giải quyết cả hai - các mâu thuẫn, cạnh tranh, và các giá trị liên quan phụ thuộc với bối cảnh hệ thống lớn hơn

Theo nhiều nghiên cứu về chất lượng phần mềm, thị phần xói mòn, và cho thấy nguy cơ như thế nào một cách tiếp cận dựa trên giá trị để thử nghiệm có thể mang lại kết quả tốt hơn so với sử dụng phương pháp truyền thống

HÌNH 6: HƯỚNG GIÁ TRỊ SO VỚI HƯỚNG TỰ NHIÊN[1]

Ví dụ hình trên mô tả bối cảnh thử nghiệm cho hệ thống thanh toán một tổ chức viễn thông, trong đó có các dịch vụ của nó được sử dụng bởi mười sáu loại khách hàng - và với một số loại khách hàng tạo ra doanh thu nhiều hơn những người khác Bullock cho thấy cách kiểm tra từng loại khách hàng được cải thiện doanh thu thanh toán 75-90 % và một trong những loại khách hàng 15 tạo ra 50 % của tất cả doanh thu thanh toán Nếu thử nghiệm ban đầu là tập trung vào đó một loại khách hàng, nó sẽ cung cấp trở lại nhanh hơn và tốt hơn trên đầu tư thử nghiệm

Trong hình 7 cho thấy cách thức tổ chức khác nhau ảnh hưởng đến đầu tư của họ về chất lượng phần mềm Ví dụ, môt tổ chức mới thành lập sẽ có tác động rủi ro cao hơn nhiều

do thị trường cổ phiếu biến động hơn một tổ chức thương mại hoặc một tổ chức tài chính cao Vì vậy, từ một điểm nguy cơ được xem xét, nó là tốt hơn cho một tổ chức mới với sản phẩm chất lượng thấp hơn so với đầu tư vào chất lượng vượt ngưỡng tiêu cực trở lại

do thị phần xói mòn

HÌNH 7: HIỆU QUẢ CỦA PHẦN MỀM VÀ SỰ BIẾN ĐỘNG CỦA CỔ PHIẾU TRONG

RỦI RO[1]

Tuy nhiên, thị phần xói mòn vẫn là một trong nhiều yếu tố khác trong bối cảnh của một

tổ chức phải được giải quyết trong thử nghiệm dựa trên giá trị Theo hình 8 không chỉ bao gồm các thị trường (môi trường) mà còn các yếu tố khác bên trong và bên ngoài của một tổ chức

HÌNH 8 : NGỮ CẢNH CỦA TỔ CHỨC[1]

Các mũi tên trong 8 chỉ ra thực nghiệm đã chứng minh ảnh hưởng giữa các yếu tố của cặp bối cảnh của một tổ chức Ví dụ, nếu chiến lược của một tổ chức dựa trên sự lãnh đạo sản phẩm sau đó nó sẽ có tác động cao không chỉ với thị phần xói mòn mà còn thiếu sự đổi mới Thực hành thử nghiệm do đó cũng cần phải giải quyết mới lạ để tương thích với chiến lược của tổ chức Nhiều tổ chức đã sử dụng các "phòng thí nghiệm khả năng sử dụng" để có được thông tin phản hồi của người tiêu dùng trên một cách dễ dàng của sản phẩm sử dụng, và nhận thức của người tiêu dùng của sản phẩm so với các sản phẩm đối thủ cạnh tranh khác Sử dụng phương pháp này, một thực tế thử nghiệm cũng sẽ có thể thiết lập một biện pháp cho mới lạ

Ngày nay hầu hết thực hành sử dụng trong việc phát triển hệ thống phần mềm đã được giới hạn bởi đơn vị của họ về phân tích, có nghĩa là, trong ranh giới của một dự án Họ không bao gồm bối cảnh tổ chức khi lập luận về một hệ thống phần mềm Ví dụ, như đã giải thích trước đây, mức độ của một hệ thống chất lượng phụ thuộc vào chiến lược một

tổ chức, môi trường v v Và mức độ chất lượng hơn nữa phụ thuộc vào mức độ thử nghiệm, nguồn lực sẵn có, v.v… Tuy nhiên, hầu hết các phần mềm và thực hành kỹ thuật

hệ thống không giải quyết phụ thuộc lẫn nhau như vậy khi hướng dẫn trên, nói rằng, kiểm thử phần mềm Thay vào đó họ chỉ tối ưu hóa chi phí và lịch trình

Quyết định cạnh tranh, các thuộc tính mâu thuẫn và phụ thuộc của hệ thống phần mềm là một vấn đề phức tạp để giải quyết Điều này là do (1) giá trị các bên liên quan có thể được giới hạn hợp lý và gián tiếp, và (2) có rất nhiều phụ thuộc lẫn nhau giữa các hệ thống phần mềm, tổ chức có liên quan, và môi trường của họ phải được yếu tố ra quyết định May mắn thay, với ứng dụng các phương pháp và lý thuyết thích hợp, những phức tạp có thể được giải quyết

2.5 Mô hình lý thuyết W

Đây là một trong những mô hình cụ thể của mô hình công nghệ phần mềm hướng giá trị Hai định lý hình thành cốt lõi của lý thuyết W, Lý thuyết căn bản hệ thống thành công và

Lý thuyết thực hành hệ thống thành công”

Lý thuyết Căn bản hệ thống thành công:

"Một hệ thống sẽ thành công khi và chỉ khi nó làm cho lợi ích của các bên liên quan cũng thành công như nó."

Ta có thể chứng minh và giải thích như sau :

Chứng minh của "nếu":

(a) Mọi người đều có ý nghĩa là một người chiến thắng

(b) Không ai đáng bị bỏ để khiếu nại

Chứng minh "chỉ nếu":

(a) Không ai muốn để bị mất

(b) Thất bại tiềm năng sẽ từ chối tham gia, hoặc sẽ phản công

(c) Các kết quả thông thường là cùng mất

Các bằng chứng của "nếu" là khá rõ ràng Bằng chứng "chỉ khi" có thể không được rõ ràng như vậy, vì vậy nó là tiếp tục minh họa trong ba ví dụ thường xuyên xảy ra các bên liên quan chính trong một doanh nghiệp liên quan đến một khách hàng ký hợp đồng với một nhà phát triển cho một hệ thống phần mềm sẽ được hưởng lợi một cộng đồng người

sử dụng, như thể hiện trong Bảng 1:

Nhanh, rẻ, sản phẩm cẩu thả Người phát triển, khách

Khách hàng, người sử dụng Người phát triển

Bảng 1: Sự được và mất của các đối tượng tham gia[1]

Trong trường hợp 1, khách hàng và người phát triển nỗ lực để giành chiến thắng các chi phí của người sử dụng khi dành quá ít nỗ lực cho chất lượng Khi trình bày các sản phẩm, người dùng từ chối sử dụng nó, rời bỏ tất cả mọi người với thất bại đối với những mong đợi của họ

Trong trường hợp 2, các nhà phát triển và người dùng cố gắng để giành chiến thắng tại các chi phí của khách hàng (thường là chi phí thêm trên một hợp đồng) bằng cách thêm nhiều giá trị thấp "chuông và còi" cho sản phẩm tức là những phần không cần thiết cho khách hàng Khi ngân sách của khách hàng bị cạn kiệt mà không có một sản phẩm dẫn

đến giá trị gia tăng, một lần nữa tất cả mọi người lại thất bại đối với những kỳ vọng của

họ

Trong trường hợp 3, người sử dụng và khách hàng biên soạn một bộ các tính năng mong muốn được phát triển và áp lực cạnh tranh phát triển là phải chào giá thấp hoặc bị xử thua Một lần khác trên hợp đồng, nhà thầu sẽ thường phản công bởi cấu kết với người sử dụng hoặc khách hàng để chuyển đổi dự án vào trường hợp 2 (thêm người dùng chuông

và còi với tài trợ đề xuất thay đổi kỹ thuật) hoặc trường hợp 1 (thường bằng cách khai thác sự mơ hồ trong tuyên bố hợp đồng làm việc để cung cấp một hệ thống hợp đồng phù hợp nhưng không sử dụng được một trong hai phải được vứt bỏ hoặc tốn kém cố định) một lần nữa, tất cả mọi người là một kẻ thất bại đối với những kỳ vọng của họ

Lý thuyết thực hành hệ thống thành công:

Phân tích lợi ích thành công của các bên liên quan (success‐critical stakeholders SCSs) bao gồm:

(a) Xác định tất cả các SCSs

(b) Sự hiểu biết như thế nào SCSs muốn giành chiến thắng

(c) Có các SCSs đàm phán một cùng thắng thiết lập các kế hoạch sản phẩm và quá trình

(d) Kiểm soát tiến trình hướng tới thực hiện SCS cùng thắng, bao gồm thích ứng với thay đổi

Lý thuyết W như một Cơ sở lựa chọn

Việc đầu tiên là tự giải thích - "Xác định tất cả các SCSs" liên quan đến việc sử dụng lý thuyết phụ thuộc Ở những phần trước cho thấy như thế nào lợi ích phân tích chuỗi, một hình thức của lý thuyết phụ thuộc có thể giúp đỡ trong việc liên kết các bên liên quan khác nhau trên các sáng kiến khác nhau

Việc thứ hai "Tìm hiểu như thế nào SCSs muốn giành chiến thắng" đòi hỏi cả hai lý thuyết phụ thuộc để xác định sự phụ thuộc cơ bản mệnh đề giá trị của họ (điều kiện giành chiến thắng), và lý thuyết sở thích hay mong muốn để xác định các mệnh đề giá trị của họ (điều kiện giành chiến thắng) Giá trị các bên liên quan có thể được chuyển đổi thành chức năng tiện ích

Việc thứ thứ ba, "Có SCSs đàm phán một cùng thắng để thiết lập các kế hoạch sản phẩm

và quá trình" đòi hỏi một sự kết hợp của lý thuyết sở thích trong các tình huống khi mệnh

đề giá trị của họ cần phải được điều chỉnh, lý thuyết phụ thuộc cho sự hiểu biết phụ thuộc lẫn nhau (cân bằng) tham gia vào cuộc đàm phán, và lý thuyết quyết định để đánh giá các lựa chọn khác nhau đối với các mệnh đề giá trị khác nhau

Việc thứ tư "Kiểm soát trực tiếp đối với SCS cùng thắng thực hiện, bao gồm thích ứng với thay đổi" liên quan đến việc sử dụng các lý thuyết điều khiển Hệ thống phần mềm được phát triển và triển khai trong một môi trường thay đổi mà có thể có hậu quả đáng kể trong việc làm cho ổn định hệ thống, như cơ chế kiểm soát như vậy có thể giúp trong việc kiểm soát và thích ứng với thay đổi

Bốn việc của thành công hệ thống Thực hiện như vậy (trong hình thức yêu cầu) cung cấp một hướng dẫn trong việc xác định các cấu trúc lý thuyết quan trọng khác của lý thuyết cuối cùng

Vấn đề nghiên cứu như một Lý do lựa chọn

Phần này trình bày một lý do cho việc xác định các cấu trúc quan trọng bởi liên quan các vấn đề nghiên cứu để định nghĩa của phân tích quyết định Các vấn đề nghiên cứu mà nghiên cứu này đề cập đến là:

Có một lý thuyết đầy đủ cho quá trình phát triển hệ thống phần mềm có thể cung cấp một khuôn khổ thống nhất cho lý luận về cách kết hợp giá trị các bên liên quan vào vô số

"quyết định” cần thiết để cung cấp các hệ thống như vậy?

Như rõ ràng trong vấn đề nghiên cứu , nghiên cứu này được giải quyết như thế nào để kết hợp các giá trị bên liên quan vào vô số "quyết định" cần thiết để cung cấp các hệ thống Như vậy, bằng mong muốn của vấn đề nghiên cứu, lý thuyết quyết định phải được xác định là một cấu trúc lý thuyết quan trọng trong lý thuyết kết quả Ta định nghĩa, một quyết định là một sự lựa chọn cho một tập hợp của các sở thích (tiện ích mong muốn), và một phần thông tin về quan hệ nhân quả (phụ thuộc) giữa sự lựa chọn và kết quả Theo định nghĩa này, lý thuyết tiện ích và lý thuyết phụ thuộc là điều kiện tiên quyết của việc

áp dụng lý thuyết quyết định Vì vậy, cả hai đều là các cấu trúc lý thuyết giá trị trong lý thuyết kết quả Ngoài ra, nghiên cứu này, và nói chung các khái niệm về kỹ thuật dựa trên giá trị của hệ thống phần mềm có một hệ thống quan điểm mở Vì trong một hệ thống mở, môi trường không được coi là tĩnh, hình thức kiểm soát phải được áp dụng để

ngăn chặn bất kỳ sự bất ổn do sự thay đổi Vì vậy, sự lựa chọn của lý thuyết điều khiển cũng là hợp lệ

HÌNH 9: LÝ THUYẾT 4+1 – CÁC CHÌA KHÓA ĐỂ XÂY DỰNG[1]

Hình 9 tóm tắt cấu trúc "4+1" của VBTSE (Value‐Based Theory for Developing Software Systems) Động cơ trong trung tâm là các phân tích thành công đúng mực của các bên liên quan (SCS) win-win Lý thuyết W, giải quyết những câu hỏi của "những giá trị nào là quan trọng?" Và "làm thế nào là thành công đảm bảo" cho một hệ thống doanh nghiệp kỹ thuật nhất định Bốn lý thuyết bổ sung mà nó thu hút trên là lý thuyết phụ thuộc (làm thế nào để phụ thuộc ảnh hưởng đến thực hiện giá trị? Về những gì các bên liên quan không thành công phụ thuộc), lý thuyết tiện ích (làm thế nào biết giá trị là quan trọng?), Lý thuyết quyết định (làm thế nào để giá trị các bên liên quan xác định các quyết định?), và lý thuyết điều khiển (làm thế nào để thích ứng với thay đổi và kiểm soát thực hiện giá trị?)

Lý thuyết phụ thuộc

Giả sử rằng các yêu cầu ban đầu của hệ thống chỉ định một giây thời gian đáp ứng cho một hệ thống để xử lý lớn Tuy nhiên, có sẵn hệ thống quản lý cơ sở dữ liệu COTS tốt nhất chỉ cung cấp một thời gian đáp ứng hai giây cho khối lượng công việc dự kiến của

hệ thống Trong nhiều trường hợp thời gian đáp ứng một giây như vậy sẽ được đánh giá

lại để phù hợp với các sản phẩm có sẵn COTS tốt nhất Xây dựng máy chủ quản lý cơ sở

dữ liệu của chính mình sẽ là lựa chọn khác, nhưng thường là không khả thi do ngân sách

và tiến độ hạn chế (nó không phải là một yêu cầu nếu bạn không thể có được) Như vậy, một sự phụ thuộc giữa các yêu cầu của hệ thống thời gian đáp ứng, những gì một COTS sản phẩm chào hàng, và thời gian và hạn chế chi phí được thành lập

Chúng ta nên quan tâm đến phụ thuộc bởi vì họ có thể giúp đưa ra quyết định:

(a) Thực hiện các quyết định tốt hơn bằng cách sắp xếp các quyết định hệ thống với giá trị các bên liên quan và bối cảnh tổ chức;

(b) Làm sáng tỏ mâu thuẫn giữa các bên liên quan đề xuất giá trị trước khi họ trở thành vấn đề nghiêm trọng;

(c) Phát hiện ra nhân tố bên ngoài vào hệ thống và có thể ảnh hưởng đến kết quả của dự án

Các hình thức khác nhau của lý thuyết phụ thuộc có thể được sử dụng trong quá trình phát triển một hệ thống phần mềm

Sắp xếp hệ thống quyết định

Nếu một người quản lý dự án yêu cầu "bao nhiêu thử nghiệm là đủ trước khi tôi sử dụng

hệ thống của tôi?" Phản ứng của VBTSE sẽ là "nó phụ thuộc" Một cách tự nhiên theo dõi sau đó sẽ là "Về những gì hiện nó phụ thuộc"? Phản ứng của VBTSE sẽ là trên các giá trị bên liên quan, và trên bối cảnh tổ chức

Hình 10 dưới đây cho thấy rằng các quyết định hệ thống cũng nên bao gồm các mục tiêu của dự án, hạn chế và ưu tiên (trong cột hệ thống) như vậy mà quyết định hệ thống cũng được liên kết với mệnh đề giá trị các bên liên quan và ràng buộc hệ thống cấp khác

Ví dụ, khi lý luận về sự lựa chọn của một mô hình vòng đời của hệ thống phầm mềm cho thấy (trong cột hệ thống) khi vỏ tăng trưởng của hệ thống là "giới hạn để lớn", sự hiểu biết về các yêu cầu, nhu cầu mạnh mẽ, và sự hiểu biết kiến trúc là "cao", sau đó sử dụng

mô hình thác nước thường là phù hợp nhất Ở cấp độ tổ chức, cho biết rằng sự lựa chọn của một mô hình vòng đời (họ sử dụng các kì hạn công nghệ) cũng phụ thuộc vào sự không chắc chắn của môi trường- nếu có một sự không chắc chắn cao trong môi trường thì một công nghệ thường xuyên (Mô hình thác nước) sẽ xung đột với môi trường Hơn nữa, chiến lược tổ chức trên sản phẩm và quá trình đổi mới, phong cách lãnh đạo cũng

cần được liên kết với sự lựa chọn của các mô hình quá trình Ví dụ, nếu mức độ kiểm soát cao, ưu tiên cho ủy quyền là thấp, và ưu tiên cho rủi ro lo ngại là cao, sau đó phương pháp linh hoạt như cố gắng lập trình sẽ xung đột với các tổ chức vì phương pháp nhanh được tối ưu hóa cho sự thay đổi và không chắc chắn

HÌNH 10: MÔ HÌNH KẾT HỢP SỰ PHỤ THUỘC[1]

Ngày nay hầu hết thực hành sử dụng trong việc phát triển hệ thống phần mềm là một trong hai giá trị trung lập, hoặc bị giới hạn trong đơn vị của họ về phân tích- có nghĩa là, chỉ trong ranh giới của một dự án Họ không rõ ràng được giá trị các bên liên quan hoặc bối cảnh tổ chức khi lập luận về một hệ thống phần mềm Thay vào đó, họ chỉ tối ưu hóa chi phí và lịch trình Sử dụng một số các tiếp cận mô tả ở trên, chúng tôi đã chỉ ra rằng việc xác định phụ thuộc như vậy và điều chỉnh các quyết định cấp hệ thống với các yếu tố khác là rất quan trọng cho sự thành công của một dự án

Xung đột về giá trị đề xuất của các bên liên quan

Một phụ thuộc giữa hai yếu tố được thiết lập nếu họ tương tác với nhau Trong một mối quan hệ phụ thuộc hai yếu tố có thể xung đột, cạnh tranh hoặc bổ sung cho nhau Các nghiên cứu về xung đột mô hình (xem hình 11) trình bày cách mệnh đề giá trị các bên liên quan khác nhau có thể xung đột với sự lựa chọn của hệ thống các mô hình quy trình, sản phẩm và tài sản qua các giả định cơ bản của họ Bốn góc phần tư trong số các xác định các bên liên quan dự án phổ biến nhất (người sử dụng, thu mua, phát triển và bảo trì)

và các mệnh đề giá trị phổ biến nhất họ thường có Trong khi mỗi dòng xác định một cuộc xung đột giữa các mệnh đề giá trị, màu xám ánh sáng đại diện cho các vụ xung đột

mô hình mà cản trở dự án

HÌNH 11: GIÁ TRỊ CỦA CÁC BÊN THAM GIA ẢNH HƯỞNG LẪN NHAU[1]

Ví dụ, người dùng muốn nhiều tính năng, chẳng hạn như tự do để xác định lại tính năng thiết lập bất cứ lúc nào, khả năng tương thích giữa các hệ thống mới và các hệ thống hiện

có của họ, và nhiều thứ khác nữa Tuy nhiên, họ cho thấy rằng giá trị đề xuất của người

sử dụng thì xung đột với giá trị đề xuất của các bên liên quan khác Ví dụ, nhiều tính năng của người sử dụng xung đột với sự giới hạn về ngân sách cũng như tiến độ kế hoạch của những người mua

Sử dụng hình thức lý thuyết phụ thuộc không phải là mới trong lĩnh vực của hệ thống kỹ thuật – tài liệu trong lĩnh vực kỹ thuật giải quyết chúng với các điều khoản như mô hình xung đột, bất xứng hợp, các cuộc xung đột, mâu thuẫn, khả năng tương tác, và ở các cấp

độ khác nhau của trừu tượng và các giai đoạn như định nghĩa hệ thống, yêu cầu, thiết kế

và phân tích, thực hiện và kiểm tra truy xuất nguồn gốc và nhất quán Có khả năng một

số lượng rất lớn phụ thuộc mà có thể tồn tại trong một hệ thống Một số giúp đỡ trong việc kết nối - nội bộ hay bên ngoài Tuy nhiên, không phải tất cả đều quan trọng Một số phụ thuộc, khi không xác định có thể có một tác động đáng kể vào kết quả của dự án, trong khi một số phụ thuộc khác có thể được xác định và giải quyết trong quá trình phát triển Cách tiếp cận rủi ro minh họa là một khung tốt cho ưu tiên phụ thuộc vào những đóng góp đáng kể nhất đối với kết quả của dự án Có nhiều mô hình trong nó có những

mô tả ở trên có thể được sử dụng để xác định và giải quyết phụ thuộc thành công quan trọng của dự án Trong bốn phần sau đây, chúng tôi cung cấp một số hướng dẫn và tham khảo mô hình như vậy dựa trên các khía cạnh khác nhau của một dự án

Kích thước số người

Số người phụ thuộc thường bắt nguồn từ những động lực chính trị - xã hội của một tổ chức Như môi trường, đây không những thường là ngoại sinh mà còn có cả nội sinh, có thể nhìn thấy trong hệ thống phân cấp quản lý , liên tổ chức và cơ chế phối hợp trong nội

bộ tổ chức Trong khi những người phụ thuộc thường được coi là "dính" vì bản chất chính trị - xã hội của họ, quá trình xác định tất cả các phân tích thành công của các bên liên quan (bao gồm cả các tổ chức có ảnh hưởng) đầu vào dự án và sử dụng các kỹ thuật như quản lý kỳ vọng và xây dựng một chia sẻ tầm nhìn thông qua đàm phán cùng có lợi

có thể làm giảm đáng kể sự phức tạp của các phụ thuộc

Kích thước tiến trình

Phụ thuộc quá trình là khá phổ biến và gần như bắt nguồn từ tất cả các kích thước - từ phụ thuộc môi trường, (ví dụ, tuân thủ Đạo luật Sarbanes- Oxley của Mỹ năm 2002 các tổ chức cần thiết để thực hiện quá trình đó sẽ cung cấp thêm trách nhiệm và tầm nhìn vào các dự án), hoặc từ sản phẩm phụ thuộc (ví dụ, sử dụng chuyên sâu của các sản phẩm COTS đòi hỏi quy trình cho phép các bên liên quan giá trị các mệnh đề được nổi hơn thông qua COTS đánh giá hơn trước các chỉ dẫn), hoặc đôi khi từ những người phụ thuộc (ví dụ, liên quan đến các nhân viên bán hàng trong sự phát triển của một hệ thống quản lý

chuỗi cung ứng cũng sẽ yêu cầu may quá trình phát triển bao gồm chúng như các bên liên quan thành công quan trọng)

Kích thước sản phẩm

Phụ thuộc sản phẩm thường là nguồn lớn nhất của phụ thuộc cho một hệ thống nhất định

và dự án phần mềm Như với quá trình phụ thuộc, họ bị ảnh hưởng bởi tất cả bốn kích thước khác (môi trường, con người, quy trình, và bất động sản) Tuy nhiên, với sự ra đời của COTS và lựa chọn thay thế công nghệ khác hiện nay, họ cũng có ảnh hưởng mạnh đến quá trình và kích thước bất động sản Ví dụ, lựa chọn cấu trúc của hệ thống và các thành phần kiến trúc sẽ trực tiếp phụ thuộc vào môi trường, con người, quy trình sử dụng,

và ngân sách/kế hoạch/tài sản hiệu quả Ngược lại, một hệ thống COTS chuyên sâu sẽ ảnh hưởng đến quá trình và tài sản

Kích thước tài sản

Phụ thuộc tài sản đối phó với các vấn đề của hệ thống và có một vai trò duy nhất trong mạng lưới phụ thuộc như ảnh hưởng xuyên suốt Người mua của một hệ thống thường quan tâm nhiều hơn trong các đặc tính như chi phí, tiến độ, thu nhập từ đầu, và giá trị Ngoài ra, người dùng trong hoạt động, khả năng sử dụng, an toàn và sự riêng tư, các nhà phát triển trong chi phí, thời gian, và có thể dùng lại, v.v phụ thuộc tài sản như vậy có liên quan trực tiếp đến giá trị gia đề xuất của các bên liên quan và do đó mấu chốt của dự

án

Lý thuyết sở thích

Lý thuyết sở thích giúp trong việc tìm hiểu các ưu đãi (tiện ích) của các phân tích thành công của các bên liên quan một hệ thống phần mềm Sự hiểu lầm sở thích ưu đãi SCS không bảo đảm sự thất bại nếu một doanh nghiệp có được may mắn Nhưng, sự hiểu biết như thế nào SCSs muốn giành chiến thắng chủ yếu là một điều kiện cần thiết cho Win-Win cải thiện

Lý thuyết phụ thuộc hỗ trợ lý thuyết sở thích bằng cách cung cấp các bên liên quan với đánh giá của các phụ thuộc và các mối quan hệ cân bằng giữa các mệnh đề giá trị của họ, bao gồm cả đánh giá về chi phí và lợi ích của việc lựa chọn để giảm thiểu rủi ro bằng cách mua thông tin về trạng thái của thiên nhiên thông qua tạo mẫu, mô hình hóa, mô phỏng, v.v

Lý thuyết quyết định

Lý thuyết quyết định giúp có SCSs một hệ thống phần mềm để đàm phán cùng có lợi theo kế hoạch Nghiên cứu này có một cách tiếp cận bản quy phạm bằng cách yêu cầu một cách rõ ràng rằng các bên liên quan quyết định trên một quá trình và kế hoạch sản phẩm dựa trên các giá trị phân tích thành công của tất cả các bên liên quan

Lý thuyết điều khiển

Lý thuyết điều khiển giúp trong việc kiểm soát tiến độ thực hiện các bên liên quan thực hiện giá trị bằng cách thích ứng với những thay đổi bên ngoài Như đã nêu các điều kiện cần thiết để kiểm soát doanh nghiệp thành công là khả năng quan sát (khả năng quan sát các doanh nghiệp nhà nước hiện hành), khả năng dự đoán (khả năng dự đoán được doanh nghiệp hướng tới một trạng thái không thể chấp nhận), khả năng điều khiển (khả năng chuyển hướng dự án phát triển hệ thống phần mềm hướng tới một nhà nước trong ngắn hạn chấp nhận được và trạng thái kết thúc thành công), và sự ổn định (tránh chu kỳ phản hồi tích cực gây ra các hệ thống kiểm soát trên mức bù lại và trở nên không ổn định) Đặc biệt đối với các lý thuyết VBSE, điều quan trọng hơn để áp dụng nguyên tắc lý thuyết điều khiển với giá trị dự kiến sẽ được thực hiện bởi các dự án chứ không phải chỉ

để dự án tiến liên quan đến kế hoạch Phụ thuộc lý thuyết hỗ trợ kiểm soát lý thuyết bằng cách xác định mà các bên liên quan và các hiện vật bị ảnh hưởng bởi các nguồn của sự thay đổi, và bằng cách đánh giá chi phí, lịch trình, và tác động hiệu suất của phản ứng thay thế để thay đổi yêu cầu

3 MÔ HÌNH CHẤT LƯỢNG

Trong phần này, chúng tôi cung cấp một cái nhìn tổng quan của các mô hình được sử dụng để mô tả và đánh giá chất lượng phần mềm Đầu tiên, chúng tôi phân loại các loại khác nhau của mô hình có sẵn và sau đó mô tả hai loại cụ thể của mô hình chất lượng - phần mềm mô hình độ tin cậy và kinh tế chất lượng phần mềm - một cách chi tiết hơn

3.1 Phân loại

Như chúng ta ý nghĩa của chất lượng và đã đưa ra một định nghĩa về chất lượng phần mềm Trong quá trình phát triển phần mềm quan trọng là phải phân tích chất lượng để cải thiện sản phẩm và quá trình này và để hỗ trợ quản lý dự án, ví dụ như quản lý phát hành

Do đó, chúng ta cần các biện pháp định lượng về chất lượng phần mềm và các mô hình

để giải thích kết quả

(Quality Model) Một mô hình chất lượng hoặc mô hình chất lượng đánh giá là một trừu

tượng của các mối quan hệ của các thuộc tính của các đồ tạo tác, quá trình, con người

và một hoặc nhiều thuộc tính chất lượng của sản phẩm

Mục đích: Mô hình có một trong hai mục tiêu: (1) đánh giá chất lượng hiện nay, (2) dự

đoán chính xác chất lượng tương lai, hoặc (3) xác định các vấn đề khu vực trong các đồ tạo tác hoặc quá trình Chúng tôi sử dụng một cách tiếp cận tương tự để phân loại các mô hình Chúng tôi bắt đầu với hai loại đảm bảo chất lượng: xây dựng và phân tích Do đó, chúng tôi cũng có các mô hình chất lượng xây dựng và phân tích Mô hình chất lượng xây dựng được sử dụng để giải thích mối quan hệ giữa các hoạt động xây dựng trong quá trình phát triển và một hoặc nhiều thuộc tính chất lượng Ví dụ, thêm người giám sát để kiến trúc làm tăng sự sẵn có của hệ thống Mô hình chất lượng phân tích có thể được chia nhỏ hơn để đánh giá và mô hình chất lượng tiên đoán Các mô hình đánh giá tương ứng với các mục tiêu 1 và 3 ở trên Chúng có mục đích để ước tính giá trị hiện tại của một hay nhiều thuộc tính chất lượng và qua đó có thể xác định vấn đề khu vực Các mô hình chất lượng dự báo đưa ra dự đoán về sự phát triển tương lai của các thuộc tính chất lượng dựa trên các thông tin hiện tại và lịch sử Do đó, chúng ta có thể phân loại các mô hình chất lượng trong ba loại:

• Mô hình chất lượng xây dựng

• Mô hình chất lượng đánh giá

• Mô hình chất lượng dự đoán

Tổng quan chất lượng Một vấn đề chính là những điểm khác nhau về chất lượng phần

mềm Mô hình chất lượng khác nhau hỗ trợ quan điểm khác nhau tốt hơn hoặc tồi tệ hơn

Ví dụ, các mô hình khả năng sử dụng vốn dĩ dựa trên mô hình chất lượng người dùng Mục đích chính là để xây dựng một hệ thống có thể dễ dàng sử dụng Mô hình kinh tế của chất lượng phần mềm như một trong những đề xuất trong chương Sau hỗ trợ rõ ràng hơn của một cái nhìn dựa trên giá trị về chất lượng Ví dụ có thể tìm thấy tất cả các ý thảo luận

Sự riêng biệt Thêm vào đó là kích thước hơn nữa trừu tượng hoặc chỉ định Điều này là

quan trọng như cho các mục đích khác nhau mức độ chi tiết khác nhau là cần thiết Trước

tiên chúng ta phân biệt giữa hai loại mô hình với một sự khác biệt lớn về trừu tượng Mô hình chất lượng khái quát tổng thể mô tả chất lượng sản phẩm về xu hướng trung bình hoặc chung công nghiệp Những điều này không đòi hỏi dữ liệu sản phẩm hoặc quy trình

cụ thể được áp dụng nhưng rõ ràng có thể cho kết quả chỉ hạt thô Loại thứ hai là các mô hình chất lượng sản phẩm cụ thể sử dụng dữ liệu thực tế từ một sản phẩm cụ thể, dự án hoặc công ty Tổng quan được mô tả trong hình 12 dưới đây:

HÌNH 12: CÁC LỚP MÔ HÌNH CHẤT LƯỢNG [2]

Mô hình tổng thể là mô hình chất lượng mà không phải là cụ thể cho một sản phẩm, dự

án nhất định Các mô hình chất lượng chung nhất là mô hình tổng thể cung cấp cho một ước tính duy nhất của chất lượng tổng thể trong ngành công nghiệp Một ví dụ là làm giảm chất lượng cho số lượng lỗi trên mỗi dòng mã trong mô hình khiếm khuyết mật độ

và đưa ra một giá trị trung bình tổng thể về số liệu này Một mô hình tổng thể có thể được cấu trúc thành một mô hình phân đoạn có các ước tính khác nhau cho các phân đoạn công nghiệp khác nhau Ví dụ, chúng ta có thể cung cấp cho tỷ lệ thất bại điển hình cho các sản phẩm phần mềm trong các lĩnh vực khác nhau Cuối cùng, chúng ta có thể giới thiệu thời gian bổ sung vào phân tích, tức là, sự tiến triển theo thời gian của các số liệu chất lượng được xem xét Điều này cho phép phân tích xu hướng trong sự phát triển của môi trường ảnh hưởng chất lượng và lớn hơn Những mô hình được gọi là mô hình năng động

Mô hình sản phẩm cụ thể Thứ nhất, chúng tôi có các mô hình lịch sử dựa trên sử dụng

dữ liệu lịch sử, thông thường là từ phiên bản cũ hơn, dự án tương tự, để dự đoán chất

lượng cho các dự án hiện tại Nó cũng có thể tùy chỉnh mô hình tổng quát cho một dự án

cụ thể Một ví dụ là sự phân bố của các khuyết tật tìm thấy trong giai đoạn phát triển Mô hình quan sát dựa trên kết hợp quan sát hiện tại của phần mềm và các hoạt động quá trình đánh giá chất lượng của phần mềm Một ví dụ là phần mềm mô hình tăng trưởng độ tin cậy có liên quan thời gian sử dụng và thời gian giữa thất bại để đánh giá độ tin cậy khía cạnh chất lượng Thứ ba, các mô hình đo lường dựa trên không dựa trên những quan sát, tức là, việc thực hiện các phần mềm nhưng đo một số khía cạnh tĩnh Mô hình này xác định mối quan hệ giữa các phép đo đầu và chất lượng sản phẩm để có thể sử dụng thông tin này trong đảm bảo chất lượng và cải tiến Số liệu phức tạp mã có thể được sử dụng để xác định các mô-đun lỗi dễ bị, ví dụ Thông tin này cho phép tập trung đảm bảo chất lượng trên các mô-đun

Thêm các trường hợp riêng Cuối cùng, mô hình chất lượng có thể có kích thước hơn

nữa trong trường hợp cụ thể Như đã nói ở trên, họ có thể chung hoặc sản phẩm cụ thể Tuy nhiên, cũng có các loại trong trường hợp cụ thể rất quan trọng Mô hình thường kỹ thuật cụ thể, ví dụ, phân tích những tác động của sự phát triển cụ thể hoặc kỹ thuật phát hiện sai sót Ví dụ, có một số mô hình được dành riêng cho việc kiểm tra phân tích Mô hình chất lượng cũng có thể là giai đoạn cụ thể, ví dụ, hầu hết các mô hình độ tin cậy chỉ tập trung vào kiểm tra hệ thống và sử dụng lĩnh vực Cuối cùng, nhiều mô hình có thuộc tính cụ thể bằng cách tập trung vào một thuộc tính chất lượng nói riêng Có rất nhiều ví

dụ cho điều đó như bảo trì hoặc độ tin cậy mô hình

Đo lường Mỗi mô hình chất lượng có yêu cầu dữ liệu khác nhau mà phải được thực hiện

để có thể sử dụng mô hình Kết quả các nỗ lực để thu thập dữ liệu có thể khác nhau đáng

kể Một mô hình khiếm khuyết mật độ đơn giản chỉ yêu cầu để đo lường số lượng các khuyết tật và kích thước của phần mềm Trên cùng cực, chi tiết phần mềm kinh tế chất lượng khác thường cần dữ liệu về chi phí của thất bại trường và chi phí loại bỏ lỗi Chúng

Hai mô hình chúng tôi đề xuất trong luận án này có thể được phân loại như sau đó mô hình sản phẩm cụ thể, các mô hình phân tích kinh tế có chất lượng là một lịch sử cơ bản,

mô hình dự báo trong khi bộ số liệu cho khiếm khuyết là một phép đo dựa trên mô hình tiên đoán

3.2 Mô hình phần mềm đáng tin cậy

Chúng tôi tập trung vào độ tin cậy thuộc tính chất lượng trong luận án này Lý thuyết độ tin cậy và các mô hình tính toán và dự đoán độ tin cậy đã được phát triển trong nhiều thập kỷ Chúng tôi giải thích một số vấn đề cơ bản và tóm tắt các thành tích và hạn chế trong những điều sau đây Ý tưởng chung đằng sau hầu hết các mô hình độ tin cậy là chúng tôi muốn để dự đoán hành vi thất bại tương lai - và do đó độ tin cậy - một phần mềm dựa trên dữ liệu thực tế thất bại Trong định nghĩa từ phần 2.1.2 độ tin cậy đã được xác định như xác suất Điều đó có nghĩa rằng chúng tôi sử dụng dữ liệu từ những thất bại như là dữ liệu mẫu trong một mô hình ngẫu nhiên để ước tính các thông số mô hình Có nhiều loại khác của các mô hình độ tin cậy sử dụng các cơ chế khác nhau, nhưng họ không phải là sử dụng rộng rãi

Các dữ liệu thất bại bao gồm các dữ liệu mẫu có thể là một trong hai loại: (1) thời gian giữa thất bại (TBF) dữ liệu hoặc (2) dữ liệu được nhóm Loại thứ nhất có chứa mỗi thất bại và thời gian đã trôi qua kể từ sự thất bại cuối cùng Loại thứ hai có chiều dài của sự kiểm tra, hoạt động khoảng thời gian và số lượng thất bại đã xảy ra trong khoảng thời gian đó Loại thứ hai là không chính xác như loại đầu tiên nhưng các dữ liệu được dễ dàng hơn để thu thập trong các dự án thực tế

Có sử dụng dữ liệu mẫu để ước tính các thông số mô hình chúng ta có thể sử dụng mô hình với các thông số dự đoán hành vi trong tương lai Có nghĩa là mô hình có thể tính toán số lượng hữu ích của phần mềm tại một thời điểm trong tương lai Ngoài độ tin cậy của số lượng chủ yếu được sử dụng là số lượng dự kiến của thất bại lên đến một thời gian nhất định t (thường ký hiệu là μ (t)) và dẫn xuất của nó, là cường độ thất bại (ký hiệu là λ (t)) Sau này trực giác có thể được xem như là con số trung bình của thất bại xảy ra trong một khoảng thời gian tại thời điểm đó t Dựa trên những số lượng chúng ta cũng có thể

dự đoán, ví dụ, trong bao lâu chúng ta phải tiếp tục thử nghiệm để đạt được một mục tiêu cường độ nhất định thất bại

Thời gian thực hiện và Lịch Thời gian

Kinh nghiệm cho thấy rằng biện pháp tốt nhất của thời gian là thời gian thực hiện CPU thực tế Độ tin cậy của phần mềm cũng như phần cứng không được thực thi không thay đổi Chỉ khi nó được điều hành có khả năng thất bại và chỉ sau đó có thể có một sự thay đổi trong độ tin cậy Nguyên nhân chính của thất bại đối với phần cứng được coi là đưa

ra Do đó, nó có thể liên quan đến thời gian thực hiện để lịch thời gian trong một số trường hợp Đối với phần mềm này có vẻ là khó khăn hơn và do đó thời gian thực hiện nên được sử dụng

Tuy nhiên, thời gian của CPU có thể không có, và có thể tái cấu trúc các phép đo và các

mô hình độ tin cậy về số liệu tiếp xúc khác: đồng hồ thời gian, trong dịch vụ thời gian (thường là một khoản thời gian đồng hồ do nhiều phần mềm ứng dụng chạy đồng thời trên nhiều hệ thống nhiều CPU đơn hoặc), thời gian hợp lý (chẳng hạn như số lượng các trường hợp thực hiện kiểm tra, truy vấn cơ sở dữ liệu, hoặc các cuộc gọi điện thoại), hoặc bảo hiểm cấu trúc (như tuyên bố đạt được bảo hiểm hoặc chi nhánh) 100 tháng thời gian dịch vụ có thể được liên kết với 50 tháng (đồng hồ thời gian) của hai hệ thống hoặc 1 tháng (đồng hồ thời gian) của 100 hệ thống Tất cả những xấp xỉ cũng được gọi là thời gian sử dụng

Trong mọi trường hợp, sự kết hợp của mẫu thống kê với dự toán của các đơn vị bán là tốt hơn nhiều so với thời gian sử dụng lịch vì cái gọi là tải, hoặc cả đều nằm, có hiệu lực Nếu hiệu ứng này không được tính, hầu hết các mô hình giả định một cách sử dụng liên tục trong thời gian đó là không hợp lý trong nhiều trường hợp thực tế Khó khăn là để xử

lý số lượng khác nhau cài đặt và nỗ lực thử nghiệm trong vòng đời của phần mềm

Tham số ước tính

Ước lượng tham số là phần quan trọng nhất của việc áp dụng mô hình độ tin cậy phần mềm cho một dự án phát triển thực sự Mô hình chính nó là hy vọng một trừu tượng trung thành của quá trình thất bại nhưng chỉ ước tính thích hợp của các thông số mô hình

có thể phù hợp với những mô hình cho vấn đề hiện tại Có một số cách để thực hiện điều

đó nhưng một sự đồng thuận dường như đạt đến một cách tiếp cận năng tối đa trên các dữ liệu không quan sát phù hợp nhất đối với hầu hết các mô hình Một khả năng khác là sử dụng các số liệu phần mềm khác hoặc dữ liệu thất bại từ các dự án cũ làm cơ sở cho việc lập dự toán nhưng điều này chỉ nên khi không có dữ liệu không có sẵn, ví dụ, trước khi thử nghiệm hệ thống

Giá trị và hạn chế

Việc sử dụng các mô hình độ tin cậy ngẫu nhiên cho phần mềm là một thực tế đã được chứng minh và đã được nghiên cứu nhiều thập kỷ nay Những mô hình có một dường như

cơ sở toán học có thể mang lại các số liệu hữu ích giúp trong việc xác định độ tin cậy cấp

độ hiện tại và trong việc quyết định các vấn đề phát hành

Tuy nhiên, các mô hình thường khó sử dụng bởi vì (1) một số hiểu biết về số liệu thống

kê cơ bản và (2) mất thời gian, tài liệu hướng dẫn các số liệu chi tiết và bộ sưu tập là cần thiết Hơn nữa, công cụ hỗ trợ có sẵn là vẫn không thỏa mãn Việc thiếu hụt chính là, tuy nhiên, các mô hình chỉ áp dụng trong quá trình kiểm tra hệ thống và sử dụng lĩnh vực và thậm chí cả trong khi thử nghiệm hệ thống mà họ phụ thuộc vào cách sử dụng dựa trên thử nghiệm, tức là, họ cho rằng các bài kiểm tra theo hồ sơ cá nhân hoạt động phản ánh việc sử dụng tương lai trong lĩnh vực Phương pháp sử dụng các số liệu khác hoặc dữ liệu thất bại từ dự án cũ là rất mong manh Đặc biệt là sử dụng các số liệu phần mềm khác đã không dẫn đến một giá trị tiên đoán thỏa mãn Điều này thu hẹp giá trị của các mô hình này

Các loại chi phí Chi phí chất lượng là một khu vực đang được nghiên cứu trong các lĩnh

vực khác nhau Chúng tôi hiểu họ như các chi phí có liên quan đến việc phòng ngừa, phát hiện, và sửa chữa công trình bị lỗi Các chi phí này được chia thành phù hợp và không phù hợp của hoạt động chi phí, còn được gọi là kiểm soát chi phí và thất bại của kiểm soát chi phí Chúng tôi có thể tiếp tục phá vỡ các chi phí vào sự khác biệt giữa phòng, thẩm định, và thất bại chi phí mà cung cấp cho các mô hình tên PAF Mô hình cơ bản được bắt nguồn từ ngành công nghiệp sản xuất nhưng đã được sử dụng nhiều lần cho chất lượng phần mềm Giới thiệu đồ họa được đưa ra trong hình 13

HÌNH 13: CÁC LOẠI CHI PHÍ [2]

Chi phí phù hợp Chi phí phù hợp bao gồm tất cả chi phí mà cần phải được dành để xây

dựng phần mềm trong một cách mà nó phù hợp với yêu cầu chất lượng của nó Điều này

có thể được chia nhỏ hơn chi phí phòng ngừa và thẩm định Chi phí phòng ngừa là ví dụ đào tạo phát triển, chi phí công cụ, hoặc kiểm tra chất lượng, tức là chi phí cho các phương tiện để ngăn chặn sự tiêm lỗi Chi phí thẩm định là do sử dụng các loại khác nhau của các bài kiểm tra và đánh giá

Chi phí không hợp lý Chi phí không tuân thủ đi vào các vị trí khi phần mềm không phù

hợp với các yêu cầu chất lượng Các chi phí này được chia thành chi phí thất bại nội bộ

và chi phí thất bại bên ngoài Trước đây có chi phí gây ra bởi lỗi xảy ra trong quá trình phát triển, sau này mô tả chi phí phát sinh từ thất bại ở máy khách

Tóm tắt: Mô hình PAF cho các chi phí của chất lượng là cơ sở chấp nhận rộng rãi cho

kinh tế chất lượng phần mềm Nó hỗ trợ chủ yếu là sản xuất-cách tiếp cận chất lượng, tức

là, tập trung vào sự phù hợp và không phù hợp với các đặc điểm kỹ thuật hoặc yêu cầu

có Vấn đề với mô hình này là nó vẫn khá trừu tượng và nó cần phải được tinh chế được

sử dụng trong thực tế

4 KẾT CHƯƠNG

Chương 1 giới thiệu tổng quan về các lý thuyết công nghệ phần mềm, và đưa ra những giải thích định hướng về công nghệ phần mềm hướng giá trị Qua tài liệu tham khảo [1] thì công nghệ phần mềm hướng giá trị cũng đã được tổng hợp từ thực tiễn thành lý thuyết

để chúng ta có thể dễ dàng thực hành công nghệ phần mềm theo hướng dựa trên giá trị trên cơ sở các lý thuyết liên quan như lý thuyết về sự phụ thuộc, lý thuyết về lợi ích, lý

thuyết về sự ra quyết định, lý thuyết về điều khiến Ta cũng giới thiệu qua các mô hình chất lượng để có thể dễ dàng tiếp cận với việc đảm bảo chất lượng phần mềm Là cơ sở

để trong chương 2 ta xây dựng các phương pháp phân tích chất lượng phần mềm theo hướng giá trị Chúng ta sẽ đưa ra các giá trị cụ thể mà qua đó phản ánh được sự đảm bảo chất lượng của phần mềm

CHƯƠNG 2: PHƯƠNG PHÁP PHÂN TÍCH CHẤT LƯỢNG PHẦN MỀM THEO HƯỚNG GIÁ TRỊ VÀ ĐỀ XUẤT ÁP DỤNG

TẠI TRUNG TÂM CNTT-AGRIBANK

Chương này gồm 2 phần, phần phương pháp phân tích chất lượng theo mô hình giá trị được tác giả tiếp thu từ tài liệu [1] và [2], phần sau tác giả đề xuất đánh giá theo hướng giá trị tại Trung tâm Công nghệ thông tin Agribank Phần phương pháp phân tích chất lượng phần mềm trình bày những nội dung sau: một mô hình phân tích của chất lượng phần mềm theo giá trị kinh tế của kỹ thuật phát hiện khiếm khuyết Đối với điều này, chúng tôi xem xét lại mô hình chung của chi phí chất lượng phần mềm và xác định các yếu tố ảnh hưởng chính chi phí Chúng được kết hợp trong (1) lý thuyết (2) mô hình phân tích, thực hành và giới thiệu một áp dụng cụ thể của lý thuyết W Dựa các mô hình này, chúng tôi phân tích và củng cố kiến thức đề xuất mô hình đánh giá chất lượng áp dụng tại Trung tâm CNTT AGRIBANK

1 PHƯƠNG PHÁP PHÂN TÍCH CHẤT LƯỢNG THEO MÔ HÌNH

HƯỚNG GIÁ TRỊ

1.1 Những nhân tố chính

Trước tiên chúng ta cần phải xác định và thảo luận về các yếu tố cơ bản của chi phí ảnh hưởng đến chất lượng của kỹ thuật phát hiện khiếm khuyết Chúng tôi xem xét lại mô hình PAF (Prevention, Appraisal, Failure) chi phí chất lượng và tinh chỉnh nó Sau đó chúng tôi lấy được những yếu tố đó sẽ được sử dụng trong các mô hình phân tích

1.1.1 ĐIỂM LẠI CHI PHÍ VỀ CHẤT LƯỢNG PHẦN MỀM

Chúng tôi mô tả những điều cơ bản của chi phí chất lượng và chi phí chất lượng phần mềm nói riêng Trong phần này, chúng tôi xem lại (phòng chống, thẩm định, thất bại) mô hình chi phí chất lượng PAF và thích ứng với nhu cầu cụ thể của chúng tôi như là một bước đầu tiên để một mô hình phân tích của kinh tế kỹ thuật có khiếm khuyết phát hiện Chúng tôi tập trung vào phân tích SQA vì xây dựng bảo đảm chất lượng có đặc điểm khác nhau đáng kể và yếu tố ảnh hưởng Do đó, một mô hình mà có thể xử lý tất cả các loại đảm bảo chất lượng sẽ vô cùng phức tạp và khó sử dụng Vì vậy, chúng ta có thể loại

bỏ các chi phí phòng ngừa từ chi phí chất lượng phần mềm như chúng ta không nhìn thấy

để ngăn ngừa khuyết tật tiềm năng trong khi đang phát hiện thì nó vẫn tồn tại Hơn nữa, người ta có thể cho rằng khi xem xét các yêu cầu hoặc đánh giá thiết kế có ngăn ngừa khuyết tật trong mã Tuy nhiên, chúng tôi xem xét tất cả các loại khuyết tật trong tất cả các loại tài liệu Các khuyết tật này đôi khi được lan truyền cho các giai đoạn và các tài liệu tiếp theo nhưng đôi khi chúng không lan truyền Quá trình xem xét sau đó để thẩm định các tài liệu với mục đích để phát hiện và loại bỏ các khiếm khuyết nhiều hơn hơn một hoạt động để ngăn ngừa khuyết tật

Đã cắt giảm các mô hình PAF cơ bản thành một (thẩm định, thất bại) mô hình AF, phần còn lại đang hoàn thiện để có thể xác định các yếu tố chi phí có liên quan từ một điểm độ tin cậy của xem Ngoài ra còn có nhiều loại chi phí khác để xem xét , ví dụ, chi phí cho bảo trì thích ứng hoặc chi phi cho việc bảo trì bị ảnh hưởng bởi các kỹ thuật như kiểm tra

có thể cải thiện khả năng đọc và tính hay thay đổi Tuy nhiên, nó thuộc ngoài phạm vi của luận văn này bởi vì chúng tôi tập trung vào khiếm khuyết phát hiện và loại bỏ Mô hình tinh chế hoàn chỉnh được thể hiện trong hình 14 Chi phí thẩm định được trình bày chi tiết về chi phí thiết lập và chi phí thực hiện Trước đây cấu thành tất cả các chi phí ban đầu để mua các tool, cấu hình môi trường kiểm tra, và nhiều chi phí khác nữa Sau này có nghĩa là tất cả các chi phí được kết nối với thử nghiệm thực tế hoặc cuộc họp đánh giá, chủ yếu là chi phí nhân sự

HÌNH 14 : ĐỊNH NGHĨA CÁC LOẠI CHI PHÍ [2]

Ở phía bên chi phí không mong muốn, chúng tôi có chi phí loại bỏ lỗi mà có thể là do các chi phí thất bại nội bộ cũng như các chi phí thất bại bên ngoài Điều này là bởi vì nếu