Phương pháp dựa trên giá trị phân tích chất lượng phần mềm nghiên cứu,thử nghiệm đánh giá độ tin cậy phần mềm

Theo định nghĩa hình thức về chất lượng sản phẩm phần mềm của Tổ chức tiêu chuẩn quốc tế ISO trong bộ tiêu chuẩn 8402, "chất lượng là khả năng đáp ứng toàn diện nhu cầu của người dùng v

MỤC LỤC

MỤC LỤC 1

LỜI CẢM ƠN 3

LỜI CAM ĐOAN 4

DANH MỤC KÝ HIỆU, CHỮ VIẾT TẮT 5

DANH MỤC CÁC BẢNG 6

DANH MỤC CÁC HÌNH VẼ, CÁC ĐỒ THỊ 7

MỞ ĐẦU 8

CHƯƠNG 1: TỔNG QUAN VỀ PHÂN TÍCH CHẤT LƯỢNG PHẦN MỀM 9

1.1 Tổng quan về chất lượng phần mềm 9

1.2 Hệ thống đánh giá chất lượng phần mềm 11

1.2.1 ISO/IEC 9126 11

1.2.2 ISO/IEC 14598 19

1.2.3 IEEE 1061 (1992) 21

1.2.4 ISO 12119 23

1.3 Các tiêu chí chất lượng phần mềm 24

1.3.1 Yêu cầu về chất lượng của người sử dụng 25

1.3.2 Yêu cầu chất lượng ngoài 25

1.3.3 Yêu cầu chất lượng trong 25

1.3.4 Chất lượng trong 26

1.3.5 Chất lượng ngoài ước lượng 26

1.3.6 Chất lượng ngoài 26

1.3.7 Chất lượng sử dụng ước lượng 26

1.3.8 Chất lượng sử dụng 26

1.4 Tiêu chí đánh giá sản phẩm phần mềm của doanh nghiệp trong nước 27

1.4.1 Các doanh nghiệp thuộc VINASA 28

1.4.2 Công ty HanoiSoftware 28

1.4.3 Tập đoàn Bưu chính Viễn thông Việt Nam 28

Kết chương 30

CHƯƠNG 2: CƠ SỞ LÝ LUẬN VỀ PHÂN TÍCH CHẤT LƯỢNG PHẦN

2.1 Công nghệ phần mềm dựa trên giá trị (VBSE) 31

2.2 Các công cụ hỗ trợ phân tích chất lượng phần mềm Cocomo và Coqualmo 32

2.2.1 Công cụ Cocomo 32

2.2.2 Công cụ Coqualmo 39

2.3 Phân tích chất lượng phần mềm dựa trên giá trị 41

2.3.1 Chất lượng phần mềm dựa trên giá trị (VBSQ) 41

2.3.2 Các mô hình chất lượng phần mềm dựa trên giá trị (VBSQM) 45

2.4 Tổng hợp các bước áp dụng phân tích chất lượng phần mềm dựa trên giá trị 51

2.4.1 Bước 1: Thiết lập yêu cầu đánh giá 51

2.4.2 Bước 2: Xác lập cơ chế đánh giá 52

2.4.3 Bước 3: Thiết kế 52

2.4.4 Bước 4: Thực hiện đánh giá 52

Kết chương 52

CHƯƠNG 3: ÁP DỤNG QUY TRÌNH PHÂN TÍCH CHẤT LƯỢNG PHẦN MỀM DỰA TRÊN GIÁ TRỊ ĐỂ ĐÁNH GIÁ THUỘC TÍNH ĐỘ TIN CẬY PHẦN MỀM SỬ DỤNG CÔNG CỤ SMERFS 53

3.1 Độ tin cậy phần mềm và hướng tiếp cận phân tích dựa trên giá trị 53

3.2 Công cụ hỗ trợ SMERFS 55

3.3 Thử nghiệm xây dựng quy trình đánh giá độ tin cậy 56

3.4 Áp dụng thử nghiệm và đánh giá 59

Kết chương 66

KẾT LUẬN 67

TÀI LIỆU THAM KHẢO 68

PHỤ LỤC 69

A Hướng dẫn sử dụng 71

B Áp dụng thử nghiệm đánh giá độ tin cậy phần mềm sử dụng công cụ SMERFS 74

LỜI CẢM ƠN

Tôi xin tỏ lòng biết ơn sâu sắc tới các thầy giáo, cô giáo Trường Đại học Bách khoa nói chung và Viện Công nghệ Thông tin - Truyền thông nói riêng đã tận tình giảng dạy và truyền đạt cho Tôi những kiến thức và kinh nghiệm trong suốt quá trình học tập tại Trường

Đặc biệt Tôi xin chân thành cảm ơn thầy giáo PGS.TS Huỳnh Quyết Thắng, Viện Công nghệ thông tin và Truyền thông, Trường Đại học Bách khoa Hà Nội đã quan tâm và hướng dẫn tận tình cho Tôi trong suốt quá trình làm luận văn thạc sĩ Nhờ có sự chỉ bảo và những ý kiến đóng góp quý báu của Thầy giúp Tôi có thể hoàn thành tốt luận văn thạc sĩ này

Cuối cùng, Tôi xin chân thành cảm ơn gia đình, bạn bè luôn động viên, khuyến khích Tôi trong suốt quá trình học tập và hoàn thành luận văn

Tôi xin chân thành cảm ơn!

LỜI CAM ĐOAN

Tôi xin cam đoan luận văn thạc sĩ công nghệ thông tin: "PHƯƠNG PHÁP PHÂN TÍCH CHẤT LƯỢNG PHẦN MỀM DỰA TRÊN GIÁ TRỊ: NGHIÊN CỨU, THỬ NGHIỆM ĐÁNH GIÁ ĐỘ TIN CẬY PHẦN MỀM" là công trình nghiên cứu của cá nhân Tôi dưới sự hướng dẫn của thầy giáo PGS.TS Huỳnh Quyết Thắng Các số liệu trong luận văn là số liệu trung thực, không sao chép toàn văn và được chỉ rõ nguồn trích dẫn trong tài liệu tham khảo

Hà Nội, ngày 1 tháng 12 năm 2012

Nguyễn Thị Thanh Thuỷ

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

TỪ VIẾT

lỗi

Relationship

Quan hệ ƣớc lƣợng thuộc tính chất lƣợng

model

Mô hình chất lƣợng phần mềm dựa trên giá trị

DANH MỤC CÁC BẢNG

Bảng 2.2: Số liệu dựa trên giá trị cho thuộc tính chất lƣợng phần mềm 45

Bảng 2.3: Quan hệ xếp hạng RELY và các pha trong chu trìnhphát triển phần mềm 47

Bảng 3.1: Các mô hình độ tin cậy phần mềm của SMERFS 3 57

Bảng 3.2: Thời gian giữa các dữ liệu lỗi theo ba dòng đƣợc xây dựng 63

DANH MỤC CÁC HÌNH VẼ, CÁC ĐỒ THỊ

Hình 1.1: Mô hình chất lƣợng cho chất lƣợng trong và ngoài 16

Hình 1.2: Mô hình chất lƣợng sử dụng 19

Hình 1.3: Mối liên hệ giữa tiêu chuẩn ISO 9126 và ISO 14598 20

Hình 1.4: Khung tham số chất lƣợng phần mềm 22

Hình 1.5: Chất lƣợng trong vòng đời sản phẩm 24

Hình 2.1: Quan hệ giữa chi phí phát triển phần mềm và yêu cầu độ tin cậy (RELY) 38

Hình 2.2: Cấu trúc mô hình COQUALMO 40

Hình 2.3: Quan hệ giữa lỗi phát hiện và xếp hạng gỡ lỗi 41

Hình 2.4: Cấu trúc của mô hình chất lƣợng phần mềm dựa trên giá trị 46

Hình 2.5: Quan hệ ƣớc lƣợng giá trị điển hình (VER) có sẵn 49

Hình 2.6: Qui trình đánh giá chất lƣợng phần mềm 51

Hình 3.1: Quy trình đo độ tin cậy phần mềm 54

Hình 3.2: Phân tích SRGM / VC-Build 1 64

Hình 3.3: Phân tích SRGM / VC-Build 2 64

Hình 3.4: Phân tích SRGM / VC-Build 3 65

Hình 3.5: Phân tích SRGM / DISTeFAX 65

Hình 3.6: Dự án DISTeFAX - Execution Summary 66

MỞ ĐẦU

Đảm bảo chất lượng phần mềm đã trở thành một công việc quan trọng trong ngành công nghệ phần mềm Các sản phẩm phần mềm ngày càng phức tạp và phát triển đa dạng phục vụ nhu cầu ngày càng cao của người dùng dẫn đến việc đánh giá chất lượng các sản phẩm cũng trở lên khó khăn Do đó không thể đo trực tiếp các đặc trưng để đánh giá sản phẩm mà phải thông qua các thể hiện của nó Tuy nhiên, mỗi đối tượng liên quan đến phần mềm lại có những yêu cầu khác nhau về chất lượng sản phẩm Vì vậy, việc phân tích chất lượng phần mềm là một vần đề cần được xem xét trên nhiều khía cạnh

Phân tích chất lượng phần mềm đang là vấn đề bức xúc của nhà sản xuất cũng như người dùng Muốn làm được việc đó thì cần phải có một hệ thống các tiêu chuẩn, phương pháp đánh giá phù hợp để phân tích chất lượng phần mềm ở một mức độ nhất định nào đó Xuất phát từ thực tiễn nêu trên khiến Tôi đã lựa chọn đề tài: "PHƯƠNG PHÁP DỰA TRÊN GIÁ TRỊ PHÂN TÍCH CHẤT LƯỢNG PHẦN MỀM: NGHIÊN CỨU, THỬ NGHIỆM ĐÁNH GIÁ ĐỘ TIN CẬY PHẦN MỀM" Mục đích của luận văn là tìm hiểu về các hệ thống đánh giá chất lượng phần mềm đã có, mặt khác còn nghiên cứu một cách tiếp cận về phân tích chất lượng phần mềm dựa trên giá trị Ngoài ra, luận văn còn tổng hợp các bước áp dụng phân tích chất lượng phần mềm dựa trên giá trị và tiến hành áp dụng quy trình này để đánh giá thuộc tính độ tin cậy phần mềm sử dụng công cụ Smerfs

Luận văn được trình bày thành ba chương cụ thể:

Chương 1: Tổng quan về phân tích chất lượng phần mềm

Chương 2: Cơ sở lý luận về phân tích chất lượng phần mềm dựa trên giá trị Chương 3: Áp dụng quy trình phân tích chất lượng phần mềm dựa trên giá trị

để đánh giá thuộc tính độ tin cậy phần mềm sử dụng công cụ smerfs

Do thời gian làm luận văn có hạn, nên trong quá trình thực hiện khó tránh khỏi những thiếu sót, Em rất mong nhận được những ý kiến đóng góp quý báu của các Thầy giáo, Cô giáo giúp em có thể cập nhật kịp thời và bổ sung hoàn thiện kiến thức cho bản thân

Em xin chân thành cảm ơn!

CHƯƠNG 1: TỔNG QUAN VỀ PHÂN TÍCH CHẤT LƯỢNG PHẦN MỀM

Chương 1 giới thiệu tổng quan về những khái niệm, định nghĩa liên quan đến chất lượng phần mềm, các hướng tiếp cận khác nhau về việc đánh giá chất lượng phần mềm Trong chương này, tác giả cũng giới thiệu về hệ thống đánh giá chất lượng phần mềm đang được sử dụng và các tiêu chí chất lượng phần mềm Ngoài

ra, tác giả còn giới thiệu tiêu chí đánh giá chất lượng phần mềm của một số công ty trong nước

1.1 Tổng quan về chất lượng phần mềm

Theo định nghĩa hình thức về chất lượng sản phẩm phần mềm của Tổ chức

tiêu chuẩn quốc tế ISO trong bộ tiêu chuẩn 8402, "chất lượng là khả năng đáp ứng

toàn diện nhu cầu của người dùng về tính năng cũng như công dụng được nêu ra một cách tường minh hoặc không tường minh trong những ngữ cảnh xác định"

Ngay trong định nghĩa này chất lượng cũng được định nghĩa một cách rất "mờ", thiếu yếu tố định lượng Thêm nữa, để hiểu hết nhu cầu của người sử dụng quả thực

là rất khó Với những khó khăn về định lượng trong khái niệm chất lượng phần mềm, để có được một phần mềm tốt cách thông thường nhất là tiếp cận theo quy trình chất lượng Nghĩa là nếu chúng ta có quy trình sản xuất tốt thì sẽ có khả năng sản xuất ra sản phẩm tốt [2]

Tổ chức đầu tiên quan tâm đến chất lượng phần mềm thực hiện đầu tiên ở Mỹ Phát triển phần mềm với mô hình thác nước hướng hợp đồng, chuẩn 1974, MIL-S-

52779, “Software Quality Assurance Program Requirement”, định nghĩa đối tượng của đảm bảo chất lượng phần mềm (QA) cũng như “đảm bảo rằng phần mềm chuyển cho khách hàng phải đạt được những yêu cầu trong hợp đồng” Điều khó khăn của cách tiếp cận này là QA hoàn toàn chỉ dựa vào hợp đồng ban đầu Nếu hợp đồng này chỉ ra những yêu cầu chất lượng nghèo nàn và không đầy đủ thì kết quả sẽ thu được phần mềm với chất lượng kém Những tổ chức kinh doanh theo nhiều cách như: đặc tả giao diện người dùng nghèo nàn, đặc tả những yêu cầu thu được từ những người dùng sai, trở nên không thể bảo trì phần mềm và yêu cầu

mang tính chuẩn đoán Vào những năm 1980, bắt đầu một xu hướng từ những năm

1970 đặc tả hướng hợp dồng chuyển sang hướng thỏa mãn khách hàng hướng dịch

vụ là những đối tượng chất lượng khởi đầu Các phương pháp đảm bảo chất lượng phần mềm như: Quản lý chất lượng toàn bộ (Total Quality Management TQM) và triển khai chức năng chất lượng (QFD) dựa trên chất lượng về sự mong đợi của khách hàng bao gồm người dùng sản phẩm phần mềm Vì thế, năm 1990 định nghĩa

“Chất lượng” trong IEEE thêm “…đạt được những yêu cầu, mong đợi của người dùng và khách hàng” vào những định nghĩa ban đầu “…đạt được những yêu cầu đã đặc tả”

Một sáng kiến đưa ra giải quyết vấn đề năm 1990 tập trung vào xác định một tập đầy đủ về các bên liên quan trong một hệ thống phần mềm và tiếp tục mục tiêu của việc thỏa hiệp giữa các bên liên quan về các thuộc tính chất lượng phần mềm

Mở rộng phạm vi của “chất lượng” bao gồm những đề nghị của yêu cầu hệ thống về giá hoặc đề nghị về người bảo trì phần mềm trong khả năng bảo trì và khả năng mở rộng

Bộ tiêu chuẩn chất lượng ISO 9001-3 của tổ chức ISO, quy định về "Quy trình đảm bảo chất lượng" trong các tổ chức phát triển phần mềm Chứng chỉ ISO 9001 xác nhận các tổ chức, đơn vị có quy trình đảm bảo chất lượng hợp chuẩn Bên cạnh

đó, một mô hình khác là CMM (Capability Maturity Model) cũng đang rất được quan tâm tại Việt Nam Công ty nhận được chứng chỉ CMM nghĩa là công ty đó đã đạt được mức độ tương ứng với các cấp độ CMM của chứng chỉ Một doanh nghiệp phát triển phần mềm, nếu có chứng chỉ CMM hoặc ISO 9001 đều có khả năng sản xuất ra các phần mềm tốt hơn hẳn các công ty chưa có chứng chỉ Tuy nhiên, chúng

ta cần lưu ý đây chỉ là "khả năng" chứ không phải là "chắc chắn" Vẫn có doanh

nghiệp có quy trình tốt nhưng sản xuất ra sản phẩm chất lượng không cao Điều này chứng tỏ cách tiếp cận theo chất lượng quy trình chưa phải là cách tiếp cận toàn diện mà chỉ giải quyết vấn đề ở mức căn bản

Như vậy, định nghĩa về chất lượng phần mềm là khó Chất lượng của sản phẩm phần mềm được xem là tốt hay xấu phụ thuộc vào người thẩm định chúng

Chất lượng phần mềm nói chung là một khái niệm trừu tượng bao gồm sự mong đợi

của con người Theo Kan chất lượng là một khái niệm đa chiều bao gồm quan điểm

về các thuộc tính chất lượng Chất lượng là một khái niệm trừu tượng mà có những tầng khác nhau Có nghĩa là mọi người có thể có những định nghĩa khác nhau về chất lượng phụ thuộc vào nềng tảng riêng của họ Đối với người dùng cuối, chất lượng phần mềm tốt có nghĩa là sản phẩm cung cấp những chức năng cần thiết và

hiệu quả để hoàn thành nhiệm vụ được thiết kế để làm công việc đó

1.2 Hệ thống đánh giá chất lượng phần mềm

Những năm cuối thế kỷ 20, tổ chức ISO đã tập trung rất nhiều vào các tiêu chuẩn chất lượng cho phần mềm Cách tiếp cận về chất lượng của ISO đã thực sự tiến thêm một bậc, toàn diện hơn, phù hợp hơn Kết quả của sự tập trung này là một loạt các bộ tiêu chuẩn đã ra đời, nhằm hướng tới đánh giá chất lượng toàn diện trong suốt vòng đời của sản phẩm phần mềm, từ khi phôi thai cho tới lúc lạc hậu cần thay thế Theo cách tiếp cận của ISO, chất lượng toàn diện của phần mềm cần phải được quan tâm từ chất lượng quy trình, tới chất lượng phần mềm nội bộ (chất lượng trong), chất lượng phần mềm đối chiếu với yêu cầu của người dùng (chất lượng ngoài) và chất lượng phần mềm trong sử dụng (chất lượng sử dụng)

Mô hình chất lượng ISO-9126 trên thực tế được mô tả là một phương pháp phân loại và chia nhỏ những thuộc tính chất lượng, nhằm tạo nên những đại lượng

đo đếm được dùng để kiểm định chất lượng của sản phẩm phần mềm

Theo bách khoa toàn thư Wikipedia, mẫu chất lượng được thiết lập ở phần đầu của tiêu chuẩn, mô hình này được đặt tên là ISO 9126-1, phân loại chất lượng phần mềm theo một chuỗi có tổ chức các đặc trưng và đặc trưng phụ như dưới đây:

Tính chức năng

Một chuỗi các tính năng mà có liên quan đến sự tồn tại của hàng loạt các chức năng và những thuộc tính cụ thể của nó Những chức năng này làm thoả mãn cả nhưng nhu cầu đã xác định hoặc tiềm năng:

Tính tiện lợi

Một chuỗi các tính năng có liên quan đến những nỗ lực cần thiết cho việc sử dụng và có liên quan đến những đánh giá mang tính cá nhân đối với việc sử dụng của hàng loạt người dùng đã định hay tiềm năng:

Tính hiệu quả

Những tính năng mà có liên quan đến mối quan hệ giữa mức độ thực hiện của phần mềm và khối lượng tài nguyên được sử dụng trong những điều kiện nhất định:

 Quản lý thời gian

Khả năng bảo hành bảo trì

Những tính năng mà có liên quan đến những nỗ lực cần thiết cho việc tạo ra những biến đổi cụ thể

Tính khả chuyển

Những tính năng mà có liên quan đến khả năng chuyển rời phần mềm từ nơi này đến nơi khác:

Đặc trưng phụ tính thích hợp không được liệt kê ở trên nhưng áp dụng đối với tất cả các đặc trưng Ví dụ của tính thích hợp đối với pháp chế bao gồm tính tiện lợi

và tính đáng tin cậy

Mỗi đặc trưng phụ về chất lượng (như khả năng thích nghi) được phân chia thành 4 tính năng Mỗi tính năng là một thực thể có thể được kiểm tra lại hoặc giới hạn trong sản phẩm phần mềm Những tính năng này không được định nghĩa trong tiêu chuẩn vì chúng rất khác nhau trong những sản phẩm phần mềm khác nhau Sản phẩm phần mềm được định nghĩa theo nghĩa rộng: nó bao gồm lệnh thi hành, mã nguồn, những miêu tả về cấu trúc, Từ đó, những quan điểm của người

sử dụng được gửi cho những nhà quản lí cũng như những người lập trình Đó chính

là những người sử dụng các thành phần của phần mềm như những thư viện phần mềm

Tiêu chuẩn này tạo ra khuôn khổ giúp các tổ chức xác định mẫu chất lượng cho sản phẩm phần mềm Tuy nhiên, làm như vậy dẫn đến việc mỗi doanh nghiệp

sẽ phải thực hiện nhiệm vụ chi tiết một cách rõ ràng các mô hình của mình Nhiệm

vụ này sẽ được thực hiện bằng nhiều cách, ví dụ như việc cụ thể các ý nghĩa của mục tiêu về hệ đo lường chất lượng mà đánh giá mức độ các tính năng về chất lượng hiện có trong sản phẩm

Hệ đo lường bên trong không dựa trên việc triển khai sử dụng phần mềm

Hệ đo lường bên ngoài có thể được áp dụng khi chạy phần mềm Chất lượng

sử dụng hệ đo lường chỉ có giá trị khi sản phẩm cuối cùng được đưa vào sử dụng trong những điều kiện thực tế

Thật lý tưởng khi chất lượng bên trong xác định được chất lượng bên ngoài và chất lượng bên ngoài xác định chất lượng khi sử dụng Tiêu chuẩn này bắt nguồn từ một mô hình được xây dựng vào năm 1977 của McCall và đồng nghiệp của ông, những người đã đề xuất một mô hình có thể xác định được chất lượng phần mềm

Mô hình chất lượng của McCall được xây dựng dựa trên 3 loại đặc trưng về chất lượng

Các yếu tố (để xác định): Các yếu tố này miêu tả hình dáng bên ngoài của phần mềm trong mắt người sử dụng Tiêu chuẩn (để xây dựng): Tiêu chuẩn này miêu tả cấu tạo bên trong của phần mềm bởi người phát triển nó Hệ đo lường (để kiểm soát): Chúng được xác định và được sử dụng nhằm mục đích cung cấp một tỷ

lệ và phương thức cho sự đo lường ISO 9268 giúp phân biệt giữa nhược điểm và sự bất quy tắc; nhược điểm là việc không hoàn thành các yêu cầu sử dụng đã dự định, trong khi đó sự bất qui tắc là việc không hoàn thành các yêu cầu chi tiết Một cách phân biệt tương tự giữa xác nhận và xác minh hay còn được biết đến là V&V trong kinh doanh thử nghiệm

1.2.1.1 Phạm vi mô hình chất lượng ISO-9126

ISO-9126 mô tả một mô hình chất lượng sản phẩm phần mềm gồm hai phần:

Phần thứ nhất của mô hình xác định 6 tiêu chí của chất lượng trong, 6 tiêu chí

chất lượng ngoài; các tiêu chí này sau đó lại được chia nhỏ thành nhiều tiêu chí con

Những tiêu chí này được bộc lộ ra ngoài khi phần mềm được coi như là một phần của hệ thống máy tính và là kết quả của các thuộc tính phần mềm bên trong

Phần thứ hai của mô hình mô tả 4 tiêu chí chất lượng sử dụng Chất lượng sử

dụng là hệ quả của 6 tiêu chí chất lượng sản phẩm phần mềm đối với người dùng Các tiêu chí sản phẩm phần mềm này có thể áp dụng cho tất cả các loại phần mềm Những tiêu chí sản phẩm phần mềm tạo ra sự nhất quán đối với chất lượng sản phẩm phần mềm, đồng thời cung cấp một khung cho việc xác định các yêu cầu đối với chất lượng phần mềm

Trong phần này, chất lượng sản phẩm phần mềm được xác định và đánh giá theo nhiều hướng, gắn với kết quả thu được, các yêu cầu, sự phát triển, sử dụng, đánh giá, hỗ trợ, tính ổn định, đảm bảo chất lượng và kiểm định của phần mềm Nó

có thể được sử dụng bởi nhà phát triển, tổ chức sử dụng, nhân viên đảm bảo chất lượng phần mềm hay người đánh giá độc lập Đồng thời nó đặc biệt thích hợp cho việc xác định và đánh giá chất lượng sản phẩm phần mềm Ví dụ, mô hình chất lượng này có thể được dùng để:

chỉnh

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

Chất lượng sản phẩm phần mềm có thể được đánh giá qua một mô hình chất lượng cụ thể Sản phẩm phần mềm nên được phân tách theo cấp bậc vào một mô hình phần mềm với những tiêu chí và những tiêu chí con, sao cho có thể sử dụng chúng như một danh sách để kiểm tra những vấn đề phát sinh liên quan đến chất lượng [2]

Mô hình chất lượng ISO-9126 trên thực tế được mô tả là một phương pháp phân loại và chia nhỏ những thuộc tính chất lượng, nhằm tạo nên những đại lượng

đo đếm được dùng để kiểm định chất lượng của sản phẩm phần mềm Mô hình chất

lượng trong và chất lượng ngoài của sản phẩm trong ISO-9126 thể hiện trên hình 1.1

Hình 1.1: Mô hình chất lượng cho chất lượng trong và ngoài

Mỗi tiêu chí chất lượng, tiêu chí chất lượng con của phần mềm đều được định nghĩa Với mỗi tiêu chí và các tiêu chí con, khả năng của phần mềm được xác định bằng tập các thuộc tính trong có thể đo đạc được Các tiêu chí và các tiêu chí con cũng có thể đo đạc trong phạm vi khả năng của hệ thống chứa phần mềm

 Tính chức năng

Khả năng của phần mềm cung cấp các chức năng đáp ứng được nhu cầu sử dụng khi phần mềm làm việc trong điều kiện cụ thể

- Tính phù hợp: là khả năng của một phần mềm có thể cung cấp một tập các

chức năng thích hợp cho công việc cụ thể phục vụ mục đích của người sử dụng

- Tính chính xác: là khả năng của phần mềm có thể cung cấp các kết quả hay

hiệu quả đúng đắn hoặc chấp nhận được với độ chính xác cần thiết

- Khả năng hợp tác làm việc: khả năng tương tác với một hoặc một vài hệ

thống cụ thể của phần mềm

- Tính an toàn: khả năng bảo vệ thông tin và dữ liệu của sản phẩm phần mềm,

sao cho người, hệ thống không được phép thì không thể truy cập, đọc hay chỉnh sửa chúng

- Tính năng phù hợp: các phần mềm theo các chuẩn, quy ước, quy định

 Tính tin cậy

Là khả năng của phần mềm có thể hoạt động ổn định trong những điều kiện cụ thể

- Tính hoàn thiện: khả năng tránh các kết quả sai

- Khả năng chịu lỗi: khả năng của phần mềm hoạt động ổn định tại một mức

độ cả trong trường hợp có lỗi xảy ra ở phần mềm hoặc có những vi phạm trong giao diện

- Khả năng phục hồi: khả năng của phần mềm có thể tái thiết lại hoạt động tại một mức xác định và khôi phục lại những dữ liệu có liên quan trực tiếp đến lỗi

- Tính tin cậy phù hợp: phần mềm thoả mãn các chuẩn, quy ước, quy định

 Tính khả dụng

Là khả năng của phần mềm có thể hiểu được, học được, sử dụng được và hấp dẫn người sử dụng trong từng trường hợp sử dụng cụ thể

- Có thể hiểu được: người dùng có thể hiểu được xem phần mềm có hợp với

họ không và và sử dụng chúng thế nào cho những công việc cụ thể

- Có thể học được: người sử dụng có thể học các ứng dụng của phần mềm

- Có thể sử dụng được: khả năng của phần mềm cho phép người dùng sử dụng và điều khiển nó

- Tính hấp dẫn: khả năng hấp dẫn người sử dụng của phần mềm

- Tính khả dụng phù hợp: phần mềm thoả mãn các chuẩn, quy ước, quy định

- Sử dụng tài nguyên: khả năng của phần mềm có thể sử dụng một lượng, một loại tài nguyên hợp lý để thực hiện công việc trong những điều kiện cụ thể

- Tính hiệu quả phù hợp: thoả mãn các chuẩn, quy ước, quy định

 Khả năng bảo hành, bảo trì

Khả năng của phần mềm có thể chỉnh sửa Việc chỉnh sửa bao gồm: sửa lại cho đúng, cải tiến và làm phần mềm thích nghi được với những thay đổi của môi trường, của yêu cầu và của chức năng xác định

- Có thể phân tích được: phần mềm có thể được chẩn đoán để tìm những thiếu sót hay những nguyên nhân gây lỗi hoặc để xác định những phần cần sửa

- Có thể thay đổi được: phần mềm có thể chấp nhận một số thay đổi cụ thể trong quá trình triển khai

- Tính ổn định: khả năng tránh những tác động không mong muốn khi chỉnh sửa phần mềm

- Có thể kiểm tra được: khả năng cho phép đánh giá được phần mềm chỉnh sửa

- Khả năng bảo hành bảo trì phù hợp: thoả mãn các chuẩn, quy ước, quy định

và tính thoả mãn (hình 1.2)

Chất lượng sử dụng

Hình 1.2: Mô hình chất lượng sử dụng

 Tính hiệu quả: khả năng của phần mềm cho phép người dùng đạt được mục

đích một cách chính xác và hoàn toàn, trong điều kiện làm việc cụ thể

 Tính năng suất: khả năng của phần mềm cho phép người dùng sử dụng lượng

tài nguyên hợp lý tương đối để thu được hiệu quả công việc trong những hoàn cảnh

cụ thể

 Tính an toàn: phần mềm có thể đáp ứng mức độ rủi ro chấp nhận được đối với

người sử dụng, phần mềm, thuộc tính, hoặc môi trường trong điều kiện cụ thể

 Tính thoả mãn: phần mềm có khả năng làm thoả mãn người sử dụng trong

Phần 3: Quy trình cho người phát triển

Phần 4: Quy trình cho người sử dụng

Phần 5: Quy trình cho người đánh giá

Phần 6: Tài liệu các hợp phần đánh giá

Phần 1 của chuẩn ISO/IEC 14598 giới thiệu chung, đưa ra quy trình đánh giá chung cho sản phẩm phần mềm Nó cung cấp một cái nhìn tổng quát về các tiêu chuẩn và giải thích mối quan hệ giữa ISO/IEC 14598 và mô hình chất lượng trong

ISO/IEC 9126 như trong hình 1.3 Phần này xác định một cách rõ ràng các thuật ngữ công nghệ được sử dụng trong các phần khác, bao gồm các yêu cầu chung, đánh giá chất lượng phần mềm và các khái niệm chung

Bên cạnh đó phần 1 cung cấp mô hình cơ bản để đánh giá chất lượng cho các sản phầm phần mềm và các yêu cầu cho các phương pháp đo và đánh giá sản phẩm phần mềm ISO/IEC 14598 được sử dụng cho người phát triển, người sử dụng và những người đánh giá độc lập có trách nhiệm đánh giá sản phầm phần mềm

Tài nguyên

và môi

trường

Quá trình đánh giá

Ảnh hưởng của sản phẩm phần mềm

Hỗ trợ

đánh giá

Quá trình đánh giá

Phép đo trong

Phép đo ngoài lượng sử dụngPhép đo chất 14598-1

14598-2

14598-3 14598-4 14598-5

9126-1

Sản phầm phần mềm

Hình 1.3: Mối liên hệ giữa tiêu chuẩn ISO 9126 và ISO 14598

Quá trình đánh giá sản phẩm phần mềm trong ISO 14598 dành cho 3 đối tượng khác nhau:

 Người phát triển: các tiến trình đánh giá phần mềm dành cho người phát triển

có thể được áp dụng cho các tổ chức có kế hoạch phát triển các sản phẩm mới hay cải tiến các sản phẩm sẵn có Nó cũng phù hợp với các tổ chức dự định sử dụng chính nhân viên kỹ thuật của mình để thực hiện đánh giá sản phẩm phần mềm

 Người mua sản phẩm: các quá trình đánh giá phần mềm dành cho người mua

sản phẩm có thể được sử dụng bởi các tổ chức có kế hoạch khai thác, tái sử dụng các sản phẩm phần mềm đã có hoặc sắp phát triển Nó có thể được sử dụng để xác định xem sản phẩm phần mềm có chấp nhận được không hoặc để lựa chọn phần

mềm thích hợp giữa các sản phẩm cùng chức năng

 Người đánh giá: người đánh giá (thường làm việc cho một bên thứ 3) sử dụng

những quá trình đánh giá riêng để có những kết luận độc lập về một sản phẩm phần mềm Người phát triển hệ thống, người khai thác hay một bên liên quan nào đó có thể yêu cầu thực hiện những quá trình này

1.2.3 IEEE 1061 (1992)

Chuẩn này cung cấp phương pháp luận để xác định yêu cầu chất lượng cần đạt, đồng thời chỉ rõ cách phân tích, ứng dụng quy trình kiểm tra tham số phần mềm Phương pháp luận này áp dụng cho tất cả các giai đoạn trong chu trình của bất cứ phần mềm nào

Đối tượng sử dụng:

- Người quản lý dự án để xác định yêu cầu chất lượng cho hệ thống

- Người phát triển hệ thống nên thiết kế phần mềm thế nào nhằm đáp ứng yêu cầu chất lượng

- Người thẩm định phần mềm có thể đánh giá phần mềm có đạt được các yêu cầu chất lượng không

- Người vận hành hệ thống để quản lý các thay đổi trong quá trình nâng cấp sản phẩm

- Người sử dụng đặc tả yêu cầu chất lượng cho hệ thống

Khung tham số chất lượng phần mềm (hình 1.4) trong tiêu chuẩn IEEE 1061 –

1992

Chất lượng phần mềm của hệ thống X

Nhân tố Các phép đo trực tiếp

Nhân tố Các phép đo trực tiếp

Nhân tố Các phép đo trực tiếp

Nhân tố con Nhân tố con Nhân tố con

Hình 1.4: Khung tham số chất lượng phần mềm

Phương pháp xác định tham số chất lượng

Các bước trong phương pháp:

cho từng pha trong chu trình phần mềm

tích và báo cáo hỗ trợ điều chỉnh hướng phát triển phần mềm và hoàn thiện nó

- Phân tích giá thành-lợi ích

- Tham số/thông tin sản phẩm

- Ma trận

- Lên kế hoạch Phân tích kết quả tham số chất

Nội dung ộ tiêu chuẩn SO EC 1211 là về đánh giá gói sản phẩm phần mềm

Tiêu chuẩn ISO/IEC 12119:1994 được áp dụng để đánh giá chung cho các tài liệu hướng dẫn, tài liệu mô tả sản phẩm, chương trình và dữ liệu và kiểm thử phần mềm

Mô tả sản phẩm: bao gồm các yêu cầu chung về mặt nội dung, các chỉ số và đưa ra kết quả về tính chức năng, độ tin cậy, tính khả dụng, tính hiệu quả, khả năng bảo hành bảo trì và tính khả chuyển

Tài liệu hướng dẫn sử dụng: phải bao gồm các thông tin cần thiết cho việc sử

dụng sản phẩm đó Tất cả các chức năng có thể được truy xuất bởi người sử dụng trong chương trình sẽ được mô tả đầy đủ trong tài liệu sử dụng và bao gồm các yêu cầu về:

Chương trình và dữ liệu: bao gồm 06 tiêu chí giống với các tiêu chí trong mô

hình chất lượng của tiêu chuẩn ISO-9126

Thuộc tính chất lượng ngoài

Thuộc tính chất lượng

sử dụng Phụ thuộc Phụ thuộc Phụ thuộc

Quá trình đánh giá Phép đánh giá trong Phép đánh giá ngoài Đánh giá chất lượng sử dụng

Tác động Tác động Tác động

Hoàn cảnh

sử dụng Quá trình Sản phẩm phần mềm Kết quả sản phẩm phần mềm

Hình 1.5: Chất lượng trong vòng đời sản phẩm

Việc đánh giá sản phẩm phần mềm để thoả mãn các yêu cầu chất lượng là một trong những quy trình trong vòng đời phát triển của phần mềm (Hình 1.5) Chất lượng sản phẩm phần mềm cần được đánh giá bằng việc đo kiểm các thuộc tính bên trong (thường là các phương pháp đo tĩnh trên các sản phẩm trung gian), hoặc bằng cách đo kiểm các thuộc tính bên ngoài (thường là đo các đáp ứng của mã lệnh khi thực thi), hoặc bằng cách đo kiểm chất lượng các thuộc tính sử dụng Mục đích là

để sản phẩm đáp ứng được những yêu cầu trong từng trường hợp sử dụng cụ thể Quy trình chất lượng góp phần cải tiến chất lượng sản phẩm, và chất lượng sản phẩm góp phần cải tiến chất lượng sử dụng Do đó, việc đánh giá và cải tiến một quy trình đồng nghĩa với cải tiến chất lượng sản phẩm Tương tự, việc đánh giá chất lượng sử dụng có thể tác động ngược trở lại để cải tiến một sản phẩm và đánh giá một sản phẩm phần mềm có thể tác động trở lại để cải tiến một quy trình

Các thuộc tính trong thích hợp của phần mềm là yêu cầu tiền đề để đạt được các phản ứng bên ngoài, và các hoạt động bên ngoài thích hợp là yêu cầu tiền đề để đạt được chất lượng sử dụng

Các yêu cầu cho chất lượng sản phẩm phần mềm sẽ bao gồm các tiêu chí đánh giá chất lượng trong, chất lượng ngoài và chất lượng sử dụng, để đáp ứng yêu cầu của người sử dụng, người bảo dưỡng, tổ chức sử dụng, và người dùng cuối

1.3.1 Yêu cầu về chất lượng của người sử dụng

Các yều cầu về chất lượng của người sử dụng được xác định là các yêu cầu chất lượng trong phép đo chất lượng sử dụng, phương pháp đo chất lượng ngoài, thậm chí cả phương pháp đo chất lượng trong Những yêu cầu này được xác định bằng phương pháp đo và sử dụng như chuẩn khi đánh giá sản phẩm Để có được một sản phẩm thoả mãn nhu cầu của người dùng đòi hỏi quá trình phát triển phần mềm phải liên tục và luôn luôn có những phản hồi từ phía họ

1.3.2 Yêu cầu chất lượng ngoài

Các yêu cầu chất lượng ngoài xác định các mức yêu cầu đối với chất lượng theo hướng nhìn từ bên ngoài Chúng bao gồm các yêu cầu xuất phát từ nhu cầu người sử dụng, gồm các yêu cầu chất lượng sử dụng Các yêu cầu chất lượng ngoài được sử dụng như là đích của quá trình kiểm tra tại mỗi giai đoạn phát triển Các yêu cầu chất lượng ngoài cho tất cả các tiêu chí chất lượng xác định trong phần này nên được đặt trong các đặc tả yêu cầu chất lượng sử dụng phương pháp đo ngoài, nên được chuyển đổi sang các yêu cầu chất lượng trong, và nên được sử dụng như

là chuẩn để kiểm tra sản phẩm

1.3.3 Yêu cầu chất lượng trong

Các yêu cầu chất lượng trong xác định các mức chất lượng yêu cầu theo hướng nhìn từ bên trong của sản phẩm Các yêu cầu chất lượng trong được sử dụng

để xác định tiêu chí của các sản phẩm trung gian Chúng có thể bao gồm các mô hình tĩnh hoặc động, các tài liệu và mã nguồn khác nhau Các yêu cầu chất lượng trong có thể được coi là đích cho các kiểm tra tại các giai đoạn khác nhau trong quá trình phát triển Chúng cũng có thể được sử dụng để xác định các chiến lược phát triển, chuẩn để đánh giá, các kiểm tra trong quá trình phát triển Có thể sử dụng một

số phương pháp đo mở rộng (ví dụ: cho việc tái sử dụng), nằm ngoài phạm vi của ISO/IEC 9126 Các yêu cầu chất lượng trong nên được xác định một cách định lượng qua việc sử dụng phương pháp đo trong

1.3.4 Chất lượng trong

Chất lượng trong là tổng hợp của tất cả các tiêu chí của sản phẩm phần mềm theo cách nhìn từ bên trong Chất lượng trong được đo kiểm và đánh giá theo các yêu cầu chất lượng trong Các chi tiết của chất lượng sản phẩm phần mềm có thể được cải tiến trong suốt quá trình triển khai mã hoá, kiểm thử, nhưng bản chất cơ bản của chất lượng sản phẩm phần mềm thể hiện qua chất lượng trong thì không thay đổi trừ khi có sự thiết kế lại

1.3.5 Chất lượng ngoài ước lượng

Chất lượng ngoài ước lượng (dự đoán) là chất lượng mà ước lượng hoặc dự đoán được của sản phẩm phần mềm tại cuối mỗi giai đoạn trong quá trình phát triển đối với mỗi tiêu chí chất lượng, dựa trên những hiểu biết về chất lượng trong

1.3.6 Chất lượng ngoài

Chất lượng ngoài là tổng hợp của các tiêu chí của sản phẩm phần mềm theo cách nhìn từ bên ngoài Đó là chất lượng khi phần mềm hoạt động, thường được đo kiểm, ước lượng trong khi kiểm thử trong môi trường giả lập với dữ liệu giả lập, sử dụng phương pháp đo ngoài Trong quá trình kiểm thử, hầu hết các lỗi cần được phát hiện và khắc phục Tuy nhiên, sau kiểm thử, vẫn còn lại một số lỗi Bởi vì rất khó để sửa chữa kiến trúc và các vấn đề liên quan đến thiết kế cơ bản của phần mềm, nên thiết kế cơ bản của phần mềm thường không thay đổi khi kiểm thử

1.3.7 Chất lượng sử dụng ước lượng

Chất lượng sử dụng ước lượng (dự đoán) là chất lượng mà ước lượng hay dự đoán được của sản phẩm phần mềm tại cuối mỗi giai đoạn phát triển đối với mỗi tiêu chí chất lượng sử dụng, dựa trên hiểu biết về chất lượng trong và ngoài

1.3.8 Chất lượng sử dụng

Chất lượng sử dụng là cách nhìn của người dùng về chất lượng của sản phẩm phần mềm khi nó được sử dụng trong một môi trường và hoàn cảnh cụ thể Nó xác định phạm vi mà người sử dụng có thể đạt được mục đích của mình trong một môi trường cụ thể, hơn là xác định các tiêu chí của bản thân phần mềm

Chất lượng trong môi trường của người sử dụng có thể khác với trong môi trường của người phát triển, đó là do sự khác nhau giữa nhu cầu và khả năng của những người sử dụng khác nhau, và sự khác nhau giữa các phần cứng và môi trường Người sử dụng chỉ đánh giá các tiêu chí của phần mềm mà họ dùng tới Đôi khi, các thuộc tính của phần mềm, xác định bởi người sử dụng trong khi phân tích yêu cầu không đáp ứng được nhu cầu của người sử dụng trong quá trình sử dụng, đó

là do những thay đổi yêu cầu của người sử dụng và các khó khăn trong việc xác định nhu cầu

1.4 Tiêu chí đánh giá sản phẩm phần mềm của doanh nghiệp trong nước

Trong phần này trình bày về tiêu chí đánh giá chất lượng phần mềm của một

số công ty trong nước

Các tổ chức sẽ xây dựng một chính sách và lên các kế hoạch cho tất cả các hoạt động đánh giá Trong tất cả các hoạt động đánh giá, cũng phải xác định trách nhiệm của các chức năng hỗ trợ Lên kế hoạch và thực thi hoạt động đánh giá sản phẩm phần mềm phải theo các bước sau:

dự án đánh giá Kế hoạch này có thể phân chia thành các mức kế hoạch thấp hơn, tuỳ thuộc vào sự phức tạp của từng công việc đánh giá cụ thể

chức, nhằm làm giàu thêm các kiến thức về đánh giá phần mềm cho tổ chức

Tổ chức cần triển khai tất cả các hoạt động đánh giá phần mềm sao cho:

hay chuẩn nội bộ không

theo dõi được

lai là khả thi

1.4.1 Các doanh nghiệp thuộc VINASA

Với mục đích hỗ trợ các doanh nghiệp phần mềm Việt Nam trong việc nâng cao chất lượng của sản phẩm phần mềm cũng như việc thống nhất quản lý chất lượng phần mềm trong các doanh nghiệp thành viên của VINASA Hiệp hội phần mềm và dịch vụ công nghệ thông tin Việt Nam (VINASA) đã chính thức thành lập Ban công tác chất lượng VINASA (VINASA QUALITY COMMITEE -VQC), với nhiệm vụ xây dựng các tiêu chuẩn và đánh giá chất lượng phần mềm Việt Nam Ban công tác chất lượng này sẽ tư vấn cho các doanh nghiệp phần mềm về quy trình đảm bảo chất lượng phần mềm, cung cấp cho doanh nghiệp các chỉ tiêu, các chuẩn

để đánh giá chất lượng phần mềm trong các lĩnh vực khác nhau dựa trên các chuẩn quốc tế (ISO-9000, ISO-9126, ISO-14598 ) về chất lượng phần mềm [2]

1.4.2 Công ty HanoiSoftware

Công ty Cổ phần phần mềm Hà Nội (HanoiSoftware) kinh doanh trên các giải pháp phần mềm cho Website thương mại điện tử, phát triển và triển khai các cổng thông tin tích hợp Chất lượng sản phẩm phần mềm tuân theo tiêu chuẩn ISO 9126 Công ty xây dựng các sản phẩm phần mềm đáp ứng các mô hình chất lượng của tiêu chuẩn ISO-9126

1.4.3 Tập đoàn Bưu chính Viễn thông Việt Nam

Tập đoàn Bưu chính Viễn thông Việt Nam thực hiện đánh giá sản phẩm phần mềm theo tiêu chuẩn ISO/IEC 12119:1994 về “Yêu cầu và kiểm tra chất lượng phần mềm” Ví dụ đánh giá về tài liệu thực hiện theo các bước sau:

Tài liệu cần đánh giá bao gồm: tài liệu hướng dẫn sử dụng, tài liệu mô tả sản phẩm và các tài liệu kỹ thuật phục vụ việc triển khai, bảo trì toàn bộ hệ thống Các sản phẩm phải phù hợp với yêu cầu về xây dựng tài liệu trong tiêu chuẩn ISO/IEC 12119: 1994 Các nội dung đánh giá cụ thể như sau:

Tài liệu mô tả sản phẩm:

- Những yêu cầu chung về nội dung

- Yêu cầu trình bày về nhận dạng và chỉ định

- Yêu cầu trình bày về chức năng

- Yêu cầu trình bày về độ tin cậy

- Yêu cầu trình bày về tính khả dụng

- Yêu cầu trình bày về tính hiệu quả

- Yêu cầu trình bày về khả năng bảo trì

- Yêu cầu trình bày về khả năng chuyển đổi hệ thống

Tài liệu hướng dẫn sử dụng

Các yêu cầu cần đánh giá bao gồm:

- Yêu cầu tính đầy đủ

- Yêu cầu tính chính xác

- Yêu cầu tính thống nhất

- Yêu cầu tính dễ hiểu

- Yêu cầu tính tổng quan

Tài liệu kỹ thuật khác:

Tài liệu hướng dẫn cài đặt, cấu hình hệ thống :

- Phải có các đặc tả về các yêu cầu hệ thống cần thiết trước cài đặt

- Các bước thực hiện phải được mô tả rõ ràng

- Phương pháp cùng các đặc tả để xác định việc cài đặt là thành công

- Mô tả đầy đủ, chính xác các thiết lập tham số cấu hình để hệ thống hoạt động đúng mô hình và yêu cầu sử dụng

Các tiêu chí đánh giá về phần mềm của Trung tâm Công nghệ thông tin CDIT thuộc Học viện Bưu chính Viễn thông được xây dựng dựa trên 6 đặc tính chất lượng nêu trong tiêu chuẩn ISO/IEC 9126 và áp dụng tiêu chuẩn ISO/IEC 12119:1994 để đánh giá chung cho các tài liệu hướng dẫn, tài liệu mô tả sản phẩm, chương trình và

dữ liệu

Kết chương

Chương 1 đã trình bày tổng quan về chất lượng phần mềm Để đánh giá sản phẩm phần mềm một cách toàn diện hơn, một loạt các bộ tiêu chuẩn đã ra đời, nhằm hướng tới đánh giá chất lượng trong suốt vòng đời của sản phẩm phần mềm,

từ khi phôi thai cho tới lúc lạc hậu cần thay thế Theo cách tiếp cận của SO, chất lượng toàn diện của phần mềm cần phải được quan tâm từ chất lượng quy trình, tới chất lượng phần mềm nội bộ (chất lượng trong), chất lượng phần mềm đối chiếu với yêu cầu của người dùng (chất lượng ngoài) và chất lượng phần mềm trong sử dụng (chất lượng sử dụng)

Trong chương tiếp theo, tác giả sẽ giới thiệu một cách phân tích chất lượng phần mềm dựa trên giá trị

CHƯƠNG 2:

CƠ SỞ LÝ LUẬN VỀ PHÂN TÍCH CHẤT LƯỢNG PHẦN MỀM

DỰA TRÊN GIÁ TRỊ

Chương 2 giới thiệu về công nghệ phần mềm dựa trên giá trị và phân tích chất lượng phần mềm dựa trên giá trị Đây là một cách tiếp cận để phân tích chất lượng phần mềm: xem xét các khía cạnh kinh tế trong toàn bộ chu kỳ phát triển phần mềm Trước hết tác giả nêu những hiểu biết về công nghệ phần mềm dựa trên giá trị Tiếp theo tìm hiểu hai công cụ hỗ trợ phân tích chất lượng phần mềm Cocomo và Coquamo Sau đó, nêu định nghĩa về chất lượng phần mềm dựa trên giá trị (VBSQ),

và các mô hình chất lượng phần mềm dựa trên giá trị Cuối cùng, tác giả tổng hợp các bước phân tích đánh giá chất lượng phần mềm dựa trên giá trị

2.1 Công nghệ phần mềm dựa trên giá trị (VBSE)

VBSE (Value-Based Software Engineering) là một qui tắc xem xét các khía

cạnh kinh tế trong toàn bộ chu kỳ phát triển phần mềm Nó có thể được định nghĩa

là một mô hình phát triển phần mềm trong đó yêu cầu giá trị thương mại được xem

là quan trọng và bình đẳng trong các tiến trình phần mềm, quản lý và quyết định

công nghệ, công cụ, kỹ thuật sử dụng trong suốt vòng đời phần mềm [4]

Cùng với sự phát triển của VBSE, những thách thức khác nhau đã phát sinh như phát triển các mô hình mới, công cụ, kỹ thuật và phương pháp hoặc thậm chí

mở rộng những cái hiện có để kích hoạt tính năng lập kế hoạch, phân tích, mô hình hóa, thực hiện, kiểm tra và theo dõi giá trị khác nhau được quan tâm trong suốt các pha phát triển phần mềm Nó cũng cho phép các bên liên quan (gồm doanh nghiệp, quản lý kỹ thuật, nhân viên phát triển, phân tích dịch vụ, người dùng) đo mối quan tâm các giá trị khác nhau và phân tích giá trị thương mại Hơn nữa, các mô hình như vậy giúp các nhà quản lý kinh doanh quyết định về tài chính tại bất kỳ giai đoạn nào của chu kỳ phát triển phần mềm khả thi hơn và toàn diện hơn

Một chương trình nghị sự toàn diện như là một nền tảng cơ sở cho VBSE đã được đề xuất Nó được thảo luận về khái niệm, thuật ngữ liên quan cũng như các giai đoạn kỹ nghệ phần mềm thiết yếu, trong đó giá trị kinh doanh cần được xem xét Trong đó bao gồm các yêu cầu kĩ thuật, kiến trúc và thiết kế, phát triển, xác minh và xác nhận, lập kế hoạch và kiểm soát, quản lý rủi ro, quản lý chất lượng và quản lý con người Nó tiếp tục đề xuất một khung nền tảng (framework) cho mô hình VBSE bao gồm 7 yếu tố chính: lợi ích thực hiện phân tích, …

Cách tiếp cận VBSE đã tập trung vào các mô hình hóa và mô phỏng giá trị kinh tế cho thấy ảnh hưởng giữa các khía cạnh khác nhau

2.2 Các công cụ hỗ trợ phân tích chất lượng phần mềm Cocomo và Coqualmo 2.2.1 Công cụ Cocomo

• Cocomo viết tắt của Constructive Cost Model [8]

 Cocomo là mô hình do Barry Boehm thiết kế nhằm dự báo (ước tính) số Người – Tháng (man-months) trong triển khai sản phẩm phần mềm

 Mô hình này dựa trên khảo sát (nghiên cứu) 60 dự án tại công ty Northrop Grumman cuối năm 2002

 Chương trình được viết bằng ngôn ngữ PL/I (Programming Language/One Ngôn ngữ thương mại và khoa học phối hợp nhiều chức năng của FORTRAN và COBOL), từ 2000 đến 100.000 dòng lệnh

• Cocomo bao gồm 3 dạng:

 Basic COCOMO

 Intermediate COCOMO: Chi phí được tính như độ lớn của phần mềm theo dòng lệnh Cộng thêm đánh giá sản phẩm, phần cứng, nhân lực và các thuộc tính của dự án

 Detailed COCOMO: tích hợp mọi đặc trưng của Cocomo trung gian cộng thêm đánh giá của chi phí ảnh hưởng (phân tích, thiết kế,…) trong mỗi giai đoạn của qui trình công nghệ phần mềm (the software engineering process)

• Cocomo có thể áp dụng cho ba lớp dự án phần mềm:

 Organic Projects: đội ngũ nhỏ có kinh nghiệm ứng dụng tốt, và làm việc trên môi trường với những yêu cầu không quá cứng nhắc

 Semi-detached Projects: đội ngũ có kinh nghiệm hỗn hợp, và làm việc trên môi trường với những yêu cầu không quá cứng nhắc

 Embedded Projects: được triển khai trong điều kiện chặt chẽ phần cứng, phần mềm và các ràng buộc về vận hành

2.2.1.1 Basic COCOMO

Basic COCOMO: Mô hình cho giá trị đơn, chi phí được tính như độ lớn của phần mềm theo dòng lệnh

Phương trình của Basic COCOMO có dạng:

E=ab(KLOC)bb; D=cb(E)db; P=E/D Trong đó:

 E = Ước tính của Người/Tháng

 D = Thời gian triển khai tính theo tháng

 KLOC = Số dòng lệnh (đơn vị=1000) ước tính của sản phẩm dự án phần mềm

 Hệ số ab, bb, cb và db được cho bởi bảng sau đây:

 P = Số người được yêu cầu

Cocomo cơ bản rất tốt cho ước tính chi phí thô, dễ dàng và nhanh Tuy nhiên,

sự chính xác sẽ bị giới hạn vì thiếu một số nhân tố chưa kể đến là sự khác nhau trong ràng buộc về phần cứng, kinh nghiệm và khả năng chuyên nghiệp của con người, việc sử dụng các công cụ hiện đại và các đặc trưng khác có ảnh hưởng đến chi phí phần mềm

2.2.1.2 Intermediate COCOMO

Intermediate COCOMO là mở rộng của mô hình Basic COCOMO, và được dùng để ước tính thời gian lập trình trong triển khai sản phẩm phần mềm Sự mở rộng này, xem xét trên một tập hợp “Chi phí của các đặc trưng các bộ phận điều khiển (driver)” được chia thành 4 nhóm (15 tính chất):

Đặc trưng của sản phẩm:

 Yêu cầu về tính độ tin cậy của phần mềm

 Khối lượng CSDL (database) của ứng dụng

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

 Đặc trưng của phần cứng

 Ràng buộc về tính năng Run-time

 Ràng buộc về Bộ nhớ

 Tính không ổn định của môi trường máy ảo

 Yêu cầu về thời gian chuyển hướng (turnabout time)

Đặc trưng về Chuyên gia

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

 Khả năng về kỹ sư PM (Software engineer)

 Kinh nghiệm ứng dụng

 Kinh nghiệm về máy ảo

 Kinh nghiệm về ngôn ngữ lập trình

Đặc trưng về Dự án

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

 Ứng dụng các phương pháp của CNPM (software engineering)

 Yêu cầu về triển khai lịch biểu (development schedule)

Mỗi tính chất được đánh giá (cho điểm) theo thang điểm có 6 mức từ rất chậm (very low) đến quá cao (extra high) Dựa trên thang điểm, hệ số cố gắng (effort multiplier) sẽ được xác định theo bảng sau: Tích các hệ số cố gắng = EAF (Effort Adjustment Factor, thường có giá trị từ 0.9 - 1.4.)

Cost Drivers

Ratings

Rất chậm Chậm

Bình thường Cao

Rất cao

Quá cao

Tính không ổn định của môi trường máy ảo 0.87 1.00 1.15 1.30

Đặc trưng về chuyên gia

Đặc trưng về dự án

Yêu cầu về development schedule 1.23 1.08 1.00 1.04 1.10

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

E=a i(KLOC)(bi).EAF

Trong đó:

– E = Ước tính của Người/Tháng

– KLOC = Số dòng lệnh (đơn vị=1000) ước tính của sản phẩm dự án

– EAF được cho bởi bảng trên

Software Project a i b i

Semi-detached 3.0 1.12

Thời gian triển khai D được tính từ E tương tự như Cocomo Cơ bản

2.2.1.3 Mô hình Cocomo II

Cocomo II là mô hình cho phép ước tính chi phí, sự cố gắng và lịch biểu khi lập

kế hoạch cho một dự án phần mềm mới [6] Gồm có 3 module: Tổng hợp ứng dụng; Thiết kế sớm; và Hậu thiết kế cụ thể là;

Mô hình tổng hợp ứng dụng bao gồm các nỗ lực làm bản mẫu để phát hiện và hạn chế những rủi ro tiềm năng như giao diện người dùng, tương tác giữa phần mềm và môi trường triển khai, hiệu năng, và sự phát triển của công nghệ

khác nhau và các khái niệm về nghiệp vụ Trong giai đoạn này, không có đủ thông tin hỗ trợ việc ước lượng chính xác chi phí Chức năng tương ứng với giai đoạn này trong mô hình Cocomo II bao gồm việc sử dụng điểm chức năng và một tập hợp gồm 7 “hướng dẫn chi phí”

mềm thực sự (không còn nằm trên thiết kế nữa) Trong giai đoạn này, sẽ tiết kiệm được chi phí nếu một kiến trúc vòng đời phần mềm được xây dựng từ trước, phù hợp với nhiệm vụ của hệ thống và thao tác thực hiện, lường trước rủi ro; và kiến trúc này được thiết lập như là một khung làm việc cho sản phẩm Mô hình Cocomo

II tương ứng với giai đoạn này cũng tương tự như mô hình Cocomo gốc và Ada Cocomo Nó sử dụng các hướng dẫn nguồn (Source Instruction) và/hoặc điểm chức năng; một tập gồm 17 hướng dẫn chi phí; một tập gồm 5 nhân tố xác định số mũ tỷ

lệ của dự án Những nhân tố này thay thế cho các phương thức phát triển trong mô hình Cocomo gốc, cũng như 4 nhân tố của mô hình Ada Cocomo [6]

Tóm lại, Cocomo II cung cấp một chuỗi ba giai đoạn các mô hình ước lượng cho các dự án phần mềm về tạo ứng dụng, tích hợp hệ thống và kiến trúc nền tảng

hợp hệ thống và kiến trúc nền tảng sẽ bao gồm sự kết hợp của ba mô hình xử lý chính Mô hình phù hợp sẽ phụ thuộc vào từng ứng dụng cụ thể

Mô hình Cocomo II thiết lập ban đầu quan hệ ước lượng chi phí (CER) được cung cấp bởi mô hình Cocomo II [4] Tham số CER cho phép người dùng biểu diễn khả năng xử lý thông tin theo từng giai đoạn thời gian về mặt kích thước phần mềm tương đương, và ước lượng chi phí đầu tư chu kỳ sống của phần mềm theo từng giai đoạn về kích cỡ của phần mềm và sản phẩm của dự án, con người và thuộc tính dự

án

Vấn đề cốt lõi của mô hình chi phí phần mềm Cocomo II là quan hệ toán học gồm 24 biến sử dụng để ước lượng số nỗ lực của người – tháng được yêu cầu để phát triển sản phẩm phần mềm được định nghĩa bởi các biến Bằng cách nhân số nỗ lực của dự án với chi phí trên một người – tháng, chúng ta có thể ước lượng được chi phí của dự án

Các tham số của Cocomo II bao gồm kích cỡ tương đương của sản phẩm trong hàng nghìn dòng lệnh (KSLOC) hoặc điểm chức năng; đặc điểm về con người như: khả năng, kinh nghiệm, tính liên tục; thuộc tính dự án như thời gian thực hiện, ràng buộc về lưu trữ; thuộc tính sản phẩm như độ phức tạp, khả năng tái sử dụng và yêu cầu về độ tin cậy

Các phân tích hồi qui đã xác định kích thước và ảnh hưởng của từng tham số lên nỗ lực dự án Ví dụ, ảnh hưởng của tham số RELY (Required Software Reliability) lên hiệu năng dự án được thể hiện ở hình sau:

Hình 2.1: Quan hệ giữa chi phí phát triển phần mềm và yêu cầu độ tin cậy

Hệ số nỗ lực tương ứng liên quan đến một giá trị trên danh nghĩa là 1.0 cho thấy chi phí liên quan một nguồn cho mỗi mức đánh giá, giả định rằng mức độ đánh giá của biến khác là liên tục Vì vậy, chi phí tương đối của một sản phẩm quan trọng an toàn sẽ là 26% cao hơn so với một sản phẩm phần mềm trong nội bộ trên danh nghĩa Giá trị này thể hiện ảnh hưởng của các nỗ lực để ngăn chặn, phát hiện, và sửa chữa các lỗi phần mềm so với việc giảm thiểu nỗ lực phải làm lại do phát hiện lỗi sớm