Số liệu chất lượng phần mềm

Các chỉ số phần mềm có thể được phân thành ba loại:

Product metrics - Mô tả các đặc tính của sản phẩm như kích thước, độ phức tạp, tính năng thiết kế, hiệu suất và mức chất lượng.
Process metrics - Những đặc điểm này có thể được sử dụng để cải thiện các hoạt động phát triển và bảo trì của phần mềm.
Project metrics- Số liệu này mô tả các đặc điểm của dự án và việc thực hiện. Ví dụ bao gồm số lượng nhà phát triển phần mềm, mô hình nhân sự trong vòng đời của phần mềm, chi phí, lịch trình và năng suất.

Một số chỉ số thuộc nhiều danh mục. Ví dụ: số liệu chất lượng trong quá trình của một dự án vừa là số liệu quá trình vừa là số liệu của dự án.

Software quality metricslà một tập hợp con các chỉ số phần mềm tập trung vào các khía cạnh chất lượng của sản phẩm, quy trình và dự án. Những điều này có liên quan chặt chẽ hơn với các chỉ số về quy trình và sản phẩm hơn là với các chỉ số của dự án.

Các chỉ số chất lượng phần mềm có thể được chia thành ba loại:

Chỉ số chất lượng sản phẩm
Chỉ số chất lượng trong quy trình
Chỉ số chất lượng bảo trì

Chỉ số chất lượng sản phẩm

Các chỉ số này bao gồm những điều sau:

Thời gian thất bại trung bình
Mật độ khuyết tật
Các vấn đề của khách hàng
Sự hài lòng của khách hàng

Thời gian thất bại trung bình

Đó là thời gian giữa những lần thất bại. Chỉ số này chủ yếu được sử dụng với các hệ thống quan trọng về an toàn như hệ thống kiểm soát giao thông hàng không, thiết bị điện tử hàng không và vũ khí.

Mật độ khuyết tật

Nó đo lường các khuyết tật liên quan đến kích thước phần mềm được biểu thị dưới dạng dòng mã hoặc điểm chức năng, v.v. tức là nó đo chất lượng mã trên mỗi đơn vị. Số liệu này được sử dụng trong nhiều hệ thống phần mềm thương mại.

Các vấn đề của khách hàng

Nó đo lường những vấn đề mà khách hàng gặp phải khi sử dụng sản phẩm. Nó chứa đựng quan điểm của khách hàng đối với không gian vấn đề của phần mềm, bao gồm các vấn đề định hướng không lỗi cùng với các vấn đề lỗi.

Chỉ số vấn đề thường được thể hiện dưới dạng Problems per User-Month (PUM).

PUM = Total Problems that customers reported (true defect and non-defect oriented 
problems) for a time period + Total number of license months of the software during 
the period

Ở đâu,

Number of license-month of the software = Number of install license of the software × 
Number of months in the calculation period

PUM thường được tính cho mỗi tháng sau khi phần mềm được phát hành ra thị trường và cũng cho mức trung bình hàng tháng theo năm.

Sự hài lòng của khách hàng

Sự hài lòng của khách hàng thường được đo lường bằng dữ liệu khảo sát khách hàng thông qua thang điểm năm -

Rất hài lòng
Satisfied
Neutral
Dissatisfied
Rất không hài lòng

Sự hài lòng về chất lượng tổng thể của sản phẩm và các kích thước cụ thể của nó thường có được thông qua nhiều phương pháp khảo sát khách hàng. Dựa trên dữ liệu thang năm điểm, một số chỉ số có sự thay đổi nhỏ có thể được xây dựng và sử dụng, tùy thuộc vào mục đích phân tích. Ví dụ -

Phần trăm khách hàng hoàn toàn hài lòng
Phần trăm khách hàng hài lòng
Phần trăm khách hàng không hài lòng
Phần trăm khách hàng không hài lòng

Thông thường, phần trăm sự hài lòng này được sử dụng.

Chỉ số chất lượng trong quá trình

Các thước đo chất lượng trong quá trình liên quan đến việc theo dõi sự xuất hiện của lỗi trong quá trình thử nghiệm máy chính thức đối với một số tổ chức. Chỉ số này bao gồm -

Mật độ khuyết tật trong quá trình kiểm tra máy
Mẫu xuất hiện khiếm khuyết trong quá trình kiểm tra máy
Mẫu loại bỏ khuyết tật dựa trên giai đoạn
Hiệu quả loại bỏ khiếm khuyết

Mật độ khuyết tật trong quá trình kiểm tra máy

Tỷ lệ sai sót trong quá trình kiểm tra máy chính thức (kiểm tra sau khi mã được tích hợp vào thư viện hệ thống) tương quan với tỷ lệ sai sót trong hiện trường. Tỷ lệ sai sót cao hơn được tìm thấy trong quá trình thử nghiệm là một chỉ báo cho thấy phần mềm đã bị tiêm lỗi cao hơn trong quá trình phát triển của nó, trừ khi tỷ lệ lỗi thử nghiệm cao hơn là do nỗ lực thử nghiệm bất thường.

Chỉ số lỗi đơn giản này trên mỗi KLOC hoặc điểm chức năng là một chỉ báo tốt về chất lượng, trong khi phần mềm vẫn đang được thử nghiệm. Nó đặc biệt hữu ích để theo dõi các bản phát hành tiếp theo của một sản phẩm trong cùng một tổ chức phát triển.

Mẫu xuất hiện khiếm khuyết trong quá trình kiểm tra máy

Mật độ khuyết tật tổng thể trong quá trình thử nghiệm sẽ chỉ cung cấp tóm tắt về các khuyết tật. Mẫu lỗi đến cung cấp thêm thông tin về các mức chất lượng khác nhau trong lĩnh vực này. Nó bao gồm những điều sau:

Các lỗi đến hoặc lỗi được báo cáo trong giai đoạn thử nghiệm theo khoảng thời gian (ví dụ: tuần). Ở đây tất cả sẽ không phải là khuyết tật hợp lệ.
Mẫu lỗi hợp lệ xuất hiện khi việc xác định vấn đề được thực hiện trên các vấn đề được báo cáo. Đây là mẫu khuyết tật thực sự.
Mô hình tồn đọng khiếm khuyết ngoài giờ. Số liệu này là cần thiết vì các tổ chức phát triển không thể điều tra và khắc phục tất cả các vấn đề được báo cáo ngay lập tức. Đây là một tuyên bố khối lượng công việc cũng như một tuyên bố chất lượng. Nếu tồn đọng khiếm khuyết lớn ở cuối chu kỳ phát triển và nhiều bản sửa lỗi vẫn chưa được tích hợp vào hệ thống, thì tính ổn định của hệ thống (do đó chất lượng của nó) sẽ bị ảnh hưởng. Kiểm tra lại (kiểm tra hồi quy) là cần thiết để đảm bảo đạt được các mức chất lượng sản phẩm mục tiêu.

Mẫu loại bỏ khuyết tật dựa trên giai đoạn

Đây là phần mở rộng của thước đo mật độ khuyết tật trong quá trình thử nghiệm. Ngoài việc kiểm tra, nó còn theo dõi các khiếm khuyết ở tất cả các giai đoạn của chu kỳ phát triển, bao gồm cả việc xem xét thiết kế, kiểm tra mã và xác minh chính thức trước khi kiểm tra.

Vì một tỷ lệ lớn các lỗi lập trình liên quan đến các vấn đề thiết kế, việc tiến hành đánh giá chính thức hoặc xác minh chức năng để nâng cao khả năng loại bỏ lỗi của quy trình ở front-end sẽ giảm thiểu lỗi trong phần mềm. Mô hình loại bỏ khuyết tật theo giai đoạn phản ánh khả năng loại bỏ khuyết tật tổng thể của quá trình phát triển.

Đối với các thước đo cho giai đoạn thiết kế và mã hóa, ngoài tỷ lệ sai sót, nhiều tổ chức phát triển sử dụng các thước đo như phạm vi kiểm tra và nỗ lực kiểm tra để quản lý chất lượng trong quá trình.

Hiệu quả loại bỏ khiếm khuyết

Nó có thể được định nghĩa như sau:

$$ DRE = \ frac {Lỗi \: loại bỏ \: trong khi \: a \: phát triển \: phase} {Các khiếm khuyết \: tiềm ẩn \: in \: the \: product} \ times 100 \% $$

Số liệu này có thể được tính toán cho toàn bộ quá trình phát triển, cho giao diện người dùng trước khi tích hợp mã và cho từng giai đoạn. Nó được gọi làearly defect removal khi được sử dụng cho giao diện người dùng và phase effectivenesscho các giai đoạn cụ thể. Giá trị của số liệu càng cao, quá trình phát triển càng hiệu quả và càng ít khuyết tật được chuyển sang giai đoạn tiếp theo hoặc hiện trường. Số liệu này là một khái niệm chính của mô hình loại bỏ lỗi để phát triển phần mềm.

Chỉ số chất lượng bảo trì

Mặc dù không thể làm gì nhiều để thay đổi chất lượng của sản phẩm trong giai đoạn này, nhưng sau đây là các bản sửa lỗi có thể được thực hiện để loại bỏ các khuyết tật càng sớm càng tốt với chất lượng sửa chữa tuyệt vời.

Sửa chỉ mục quản lý tồn đọng và tồn đọng
Sửa thời gian phản hồi và sửa khả năng phản hồi
Phần trăm sửa lỗi quá hạn
Sửa chữa chất lượng

Sửa chỉ mục quản lý tồn đọng và tồn đọng

Khắc phục tồn đọng liên quan đến tỷ lệ lỗi đến và tốc độ có sẵn các bản sửa lỗi cho các vấn đề được báo cáo. Đó là một số lượng đơn giản các vấn đề được báo cáo vẫn còn vào cuối mỗi tháng hoặc mỗi tuần. Sử dụng nó ở định dạng biểu đồ xu hướng, số liệu này có thể cung cấp thông tin có ý nghĩa để quản lý quy trình bảo trì.

Chỉ số quản lý tồn đọng (BMI) được sử dụng để quản lý tồn đọng của các vấn đề đang mở và chưa được giải quyết.

$$ BMI = \ frac {Số \: trong số \: sự cố \: đã đóng \: trong \: \: tháng} {Số \: trong \: sự cố \: đến \: trong \: \: tháng} \ lần 100 \% $$

Nếu BMI lớn hơn 100, nghĩa là lượng công việc tồn đọng giảm xuống. Nếu BMI dưới 100, thì lượng công việc tồn đọng sẽ tăng lên.

Sửa thời gian phản hồi và sửa khả năng phản hồi

Chỉ số thời gian phản hồi khắc phục thường được tính là thời gian trung bình của tất cả các vấn đề từ mở đến đóng. Thời gian phản hồi sửa chữa ngắn dẫn đến sự hài lòng của khách hàng.

Các yếu tố quan trọng của khả năng đáp ứng sửa chữa là mong đợi của khách hàng, thời gian khắc phục đã thỏa thuận và khả năng đáp ứng cam kết của một người với khách hàng.

Phần trăm sửa lỗi quá hạn

Nó được tính như sau:

$ Percent \: Delinquent \: Fixes = $

$ \ frac {Số \: trong số \: sửa chữa \: điều đó \: đã vượt quá \: \: phản hồi \: thời gian \: tiêu chí \: bởi \: ceverity \: cấp} {Số \: trong số \: bản sửa lỗi \: đã giao \: trong \: a \: được chỉ định \: time} \ lần 100 \% $

Sửa chữa chất lượng

Chất lượng sửa chữa hoặc số lượng sửa chữa lỗi là một thước đo chất lượng quan trọng khác cho giai đoạn bảo trì. Bản sửa lỗi bị lỗi nếu nó không khắc phục được sự cố được báo cáo hoặc nếu nó đã khắc phục được sự cố ban đầu nhưng lại đưa vào một lỗi mới. Đối với phần mềm quan trọng trong sứ mệnh, các bản sửa lỗi có thể gây hại cho sự hài lòng của khách hàng. Chỉ số phần trăm các bản sửa lỗi bị lỗi là phần trăm của tất cả các bản sửa lỗi trong một khoảng thời gian bị lỗi.

Việc sửa lỗi có thể được ghi theo hai cách: Ghi vào tháng mà nó được phát hiện hoặc ghi vào tháng đã giao sửa. Đầu tiên là thước đo khách hàng; thứ hai là thước đo quy trình. Sự khác biệt giữa hai ngày là khoảng thời gian tiềm ẩn của việc sửa lỗi.

Usually the longer the latency, the more will be the customers that get affected. If the number of defects is large, then the small value of the percentage metric will show an optimistic picture. The quality goal for the maintenance process, of course, is zero defective fixes without delinquency.