Tạo, sử dụng và phân tích các số liệu. Số liệu phần mềm
Bộ sưu tập tài liệu mới để tải về! Chúng tôi đã thu thập các gói tài liệu về các chủ đề hiện tại, bao gồm các bài thuyết trình của chuyên gia, hội thảo trên web, bài viết, ví dụ triển khai, v.v.
Để tải tài liệu, nhấp vào nút thích hợp:
Tiêu chuẩn được biết đến và sử dụng rộng rãi nhất để tổ chức các quy trình kiểm soát chất lượng là loạt tiêu chuẩn ISO 9000. Đối với quy trình phát triển phần mềm, tiêu chuẩn ISO 9001 được sử dụng, bao gồm cả thiết kế theo sản xuất. Cần lưu ý rằng tiêu chuẩn này khó sử dụng trực tiếp trong quản lý chất lượng phát triển phần mềm vì ban đầu nó tập trung vào phát triển các sản phẩm công nghiệp. Đặc biệt để hỗ trợ các quy trình phát triển hệ thống phần mềm của tổ chức ISO, hướng dẫn ISO 9000-3 đã được phát triển, trong đó đưa ra các yêu cầu của mô hình chất lượng ISO 9001 để tổ chức quy trình phát triển phần mềm.
Do đó, các yêu cầu của hướng dẫn ISO 9000-3 có thể được sử dụng để đánh giá chất lượng của quá trình phát triển trong tổ chức của chính mình hoặc trong tổ chức của nhà thầu. Hiện tại, phiên bản 2000 của tiêu chuẩn đang được đưa vào sử dụng ở mọi nơi, trong đó việc kiểm soát quy trình được đặt lên hàng đầu, tuy nhiên, trong phiên bản tiêu chuẩn này không có tính đặc thù nào liên quan đến phát triển phần mềm.
Nhược điểm của tiêu chuẩn ISO 9000 là khó đo lường mức chất lượng của quy trình phát triển phần mềm theo mô hình chất lượng được đề xuất.
Trong số các nhà phát triển phần mềm, đặc biệt là ở nước ngoài (chủ yếu ở Mỹ), một mô hình chất lượng thay thế được đánh giá cao: CMM - SEI. Mô hình chất lượng này được phát triển tại Viện Kỹ thuật Phần mềm dưới sự tài trợ của Bộ Quốc phòng Hoa Kỳ. Ban đầu, mô hình chất lượng này được chính phủ, đặc biệt là quân đội, các tổ chức sử dụng khi đặt hàng phát triển phần mềm. Tiêu chuẩn này hiện được sử dụng rộng rãi để phân tích và chứng nhận quy trình phát triển phần mềm của các công ty sản xuất phần mềm phức tạp trong các lĩnh vực ứng dụng quan trọng. Ưu điểm quan trọng của mô hình CMM là việc lồng ghép các mô hình chất lượng theo thứ bậc, cho phép bạn đo lường và so sánh mức độ chất lượng quy trình trong các tổ chức khác nhau và đảm bảo cải thiện hiệu quả chất lượng quy trình.
ISO hiện cũng đã phát triển một mô hình chất lượng để đo lường và cải tiến chất lượng.
Ở một khía cạnh nào đó, mô hình chất lượng CMM và ISO có thể thay thế cho nhau, tuy nhiên, về bản chất, chúng không mâu thuẫn với nhau vì chúng dựa trên cùng một mô hình chất lượng - TQM - Quản lý chất lượng toàn diện.
Điều quan trọng cần lưu ý là chỉ cần có một quy trình phát triển phần mềm đáp ứng mức chất lượng cao không đảm bảo một sản phẩm chất lượng cao. Có một quy trình chất lượng có nghĩa là chất lượng của sản phẩm tạo ra sẽ được cải thiện đều đặn nhiều lần. Do đó, khi đưa ra quyết định, cần phải tính đến thời gian mà một quy trình đạt mức chất lượng cần thiết trong một lĩnh vực công nghệ nhất định được lắp đặt và vận hành. Tuy nhiên, việc thiếu thông tin về chất lượng của quy trình có nghĩa là chất lượng của sản phẩm đang được phát triển là không thể đoán trước được.
Chất lượng sản phẩm phần mềm
Chất lượng của các thành phần phần mềm
Sự phát triển của các hệ thống phần mềm lớn hiện đại hiện nay ngày càng dựa trên sự phát triển thành phần (Component Base System - CBS). Công nghệ xây dựng CBS có thể giảm đáng kể chi phí và thời gian phát triển. Đồng thời, rủi ro liên quan đến việc sử dụng các thành phần phần mềm do các nhà sản xuất khác nhau phát triển trong hệ thống cũng tăng lên.
Cách hiệu quả nhất để giải quyết vấn đề này là sử dụng các thước đo để quản lý chất lượng và rủi ro khi xây dựng CBS, nhằm đo lường các yếu tố khác nhau ảnh hưởng đến chất lượng cuối cùng của sản phẩm và loại bỏ các nguồn rủi ro. Trong trường hợp này, số liệu chất lượng nên được sử dụng để hỗ trợ việc ra quyết định ở các giai đoạn khác nhau của vòng đời phát triển về tính khả thi về mặt kinh tế của việc sử dụng các thành phần.
Theo quy định, mã nguồn của các thành phần không thể truy cập được đối với các nhà thiết kế hệ thống; ngoài ra, chúng còn cung cấp một giao diện có cấu trúc phức tạp. Hậu quả của việc này là có sự khác biệt đáng kể giữa các số liệu thường được áp dụng cho các hệ thống truyền thống và các số liệu dành cho CBS. Hầu hết các số liệu truyền thống được sử dụng trong giai đoạn lập kế hoạch và phát triển. Chìa khóa để quản lý chất lượng khi sử dụng số liệu trong quá trình phát triển hệ thống thành phần là việc lựa chọn số liệu chất lượng có thể áp dụng ở tất cả các giai đoạn của vòng đời và đánh giá cả chất lượng quy trình và chất lượng sản phẩm.
5). Khả năng bảo trì
Khả năng bảo trì là một tập hợp các thuộc tính cho biết nỗ lực cần thiết để thực hiện các sửa đổi bao gồm điều chỉnh, cải tiến và điều chỉnh phần mềm khi môi trường, yêu cầu hoặc thông số kỹ thuật chức năng thay đổi.
Khả năng bảo trì bao gồm các đặc tính phụ:
– Khả năng phân tích – thuộc tính xác định nỗ lực cần thiết để chẩn đoán lỗi hoặc xác định các bộ phận sẽ được sửa đổi;
– khả năng thay đổi là thuộc tính xác định nỗ lực dành cho việc sửa đổi, loại bỏ lỗi hoặc thực hiện các thay đổi để loại bỏ lỗi hoặc đưa các khả năng mới vào phần mềm hoặc môi trường vận hành;
– tính ổn định – thuộc tính chỉ ra rủi ro sửa đổi;
- khả năng kiểm thử - thuộc tính chỉ ra những nỗ lực trong quá trình xác nhận, xác minh nhằm phát hiện lỗi và sự không tuân thủ các yêu cầu, cũng như nhu cầu sửa đổi và chứng nhận phần mềm;
– tính nhất quán – thuộc tính thể hiện sự phù hợp của một thuộc tính nhất định với những thuộc tính được xác định trong tiêu chuẩn, thỏa thuận, quy tắc và quy định.
6). Tính di động– nhiều chỉ báo khác nhau cho thấy khả năng thích ứng của phần mềm để hoạt động trong các điều kiện mới của môi trường thời gian chạy. Môi trường có thể là tổ chức, phần cứng và phần mềm. Do đó, việc chuyển phần mềm sang môi trường thực thi mới có thể liên quan đến một tập hợp các hành động nhằm đảm bảo hoạt động của phần mềm đó trong một môi trường khác với môi trường mà nó được tạo ra, có tính đến khả năng phần mềm, tổ chức và kỹ thuật mới.
Tính di động bao gồm các đặc tính phụ:
– khả năng thích ứng – một thuộc tính xác định những nỗ lực dành cho việc thích ứng với các môi trường khác nhau;
– khả năng tùy chỉnh (dễ cài đặt) – một thuộc tính xác định nỗ lực cần thiết để khởi chạy hoặc cài đặt phần mềm này trong một môi trường đặc biệt;
– cùng tồn tại – một thuộc tính xác định khả năng sử dụng phần mềm đặc biệt trong môi trường hệ điều hành;
- khả năng thay thế lẫn nhau - một thuộc tính cung cấp khả năng tương tác khi làm việc cùng với các chương trình khác với việc cài đặt hoặc điều chỉnh phần mềm cần thiết;
– tính nhất quán là một thuộc tính cho thấy sự tuân thủ các tiêu chuẩn hoặc thỏa thuận để đảm bảo tính di động của phần mềm.
9.1.1. Số liệu chất lượng phần mềm
Hiện nay, hệ thống thước đo trong công nghệ phần mềm vẫn chưa được hình thành đầy đủ. Có nhiều cách tiếp cận và phương pháp khác nhau để xác định tập hợp và phương pháp đo lường của chúng.
Hệ thống đo lường phần mềm bao gồm các số liệu và mô hình đo lường được sử dụng để định lượng chất lượng của nó.
Khi xác định các yêu cầu phần mềm, các đặc tính bên ngoài tương ứng và các đặc tính phụ (thuộc tính) của chúng được chỉ định, xác định các khía cạnh khác nhau của chức năng và quản lý sản phẩm trong một môi trường nhất định. Đối với một tập hợp các đặc tính chất lượng phần mềm được chỉ định trong các yêu cầu, các số liệu, mô hình tương ứng để đánh giá chúng và một loạt các giá trị đo lường để đo các thuộc tính chất lượng riêng lẻ sẽ được xác định.
Theo tiêu chuẩn, số liệu được xác định bằng mô hình đo lường các thuộc tính phần mềm ở tất cả các giai đoạn của vòng đời (trung gian, số liệu nội bộ) và đặc biệt là ở giai đoạn thử nghiệm hoặc hoạt động (số liệu bên ngoài) của sản phẩm.
Hãy tập trung vào việc phân loại các số liệu phần mềm, các quy tắc tiến hành phân tích số liệu và quy trình đo lường chúng.
Các loại số liệu. Có ba loại số liệu:
– thước đo sản phẩm phần mềm được sử dụng để đo lường các đặc tính – thuộc tính của nó;
– số liệu quá trình được sử dụng để đo lường đặc tính của quá trình được sử dụng để tạo ra sản phẩm.
- số liệu sử dụng.
Chỉ số sản phẩm phần mềm bao gồm:
– số liệu bên ngoài cho biết đặc tính sản phẩm mà người dùng có thể nhìn thấy;
– số liệu nội bộ cho biết các thuộc tính chỉ có nhóm phát triển mới nhìn thấy được.
Số liệu bên ngoài sản phẩm bao gồm các chỉ số sau:
- độ tin cậy của sản phẩm, dùng để xác định số lượng khuyết tật;
– chức năng, với sự trợ giúp của nó, sự hiện diện và triển khai chính xác các chức năng trong sản phẩm được thiết lập;
– hỗ trợ, với sự trợ giúp của tài nguyên sản phẩm được đo lường (tốc độ, bộ nhớ, môi trường);
– khả năng ứng dụng của sản phẩm, giúp xác định mức độ tiếp cận để nghiên cứu và sử dụng;
- Chi phí quyết định giá thành của sản phẩm được tạo ra.
Số liệu nội bộ số liệu sản phẩm bao gồm:
- các kích thước cần thiết để đo sản phẩm bằng cách sử dụng các đặc tính bên trong của nó;
- độ phức tạp cần thiết để xác định độ phức tạp của sản phẩm;
– các phong cách dùng để xác định các phương pháp tiếp cận và công nghệ để tạo ra các thành phần riêng lẻ của sản phẩm và các tài liệu của nó.
Các số liệu nội bộ đo lường hiệu suất của sản phẩm và có liên quan đến các số liệu bên ngoài.
Các số liệu bên ngoài và bên trong được thiết lập ở giai đoạn hình thành các yêu cầu phần mềm và là chủ đề của các cách lập kế hoạch để đạt được chất lượng của sản phẩm phần mềm cuối cùng.
Số liệu sản phẩm thường được mô tả bằng một tập hợp các mô hình để đặt các thuộc tính và giá trị khác nhau của mô hình chất lượng hoặc để đưa ra dự đoán. Các phép đo thường được thực hiện sau khi hiệu chỉnh các số liệu ở giai đoạn đầu của dự án. Một thước đo phổ biến là mức độ truy nguyên, được xác định bởi số lượng dấu vết có thể truy nguyên bằng cách sử dụng các mô hình kịch bản (ví dụ: UML) và có thể là số lượng:
- các yêu cầu;
– kịch bản và nhân vật;
– các đối tượng có trong kịch bản và bản địa hóa các yêu cầu cho từng kịch bản;
– các tham số và hoạt động của đối tượng, v.v.
ISO/IEC 9126–2 xác định các loại biện pháp sau:
– thước đo kích thước phần mềm theo các đơn vị đo khác nhau (số lượng chức năng, dòng trong chương trình, kích thước bộ nhớ đĩa, v.v.);
– thước đo thời gian (chức năng của hệ thống, thực hiện thành phần, v.v.);
– thước đo nỗ lực (năng suất lao động, cường độ lao động, v.v.);
– các biện pháp kế toán (số lỗi, số lỗi, phản hồi của hệ thống, v.v.).
Một thước đo cụ thể có thể là mức độ sử dụng các thành phần tái chế và được đo bằng tỷ lệ kích thước của sản phẩm được làm từ các thành phần sẵn có với kích thước của toàn bộ hệ thống. Biện pháp này được sử dụng để xác định chi phí và chất lượng của phần mềm. Ví dụ về số liệu là:
– tổng số đối tượng và số lượng đối tượng được sử dụng lại;
– tổng số các thao tác, các thao tác được sử dụng lại và các thao tác mới;
– số lớp kế thừa các hoạt động cụ thể;
- số lớp mà lớp này phụ thuộc vào;
– số lượng người dùng của một lớp hoặc các hoạt động, v.v.
Khi ước tính tổng số đại lượng nhất định, số liệu thống kê trung bình thường được sử dụng (ví dụ: số lượng hoạt động trung bình trong một lớp, số lượng con cháu trung bình của một lớp hoặc các hoạt động của lớp, v.v.).
Theo quy định, các biện pháp phần lớn mang tính chủ quan và phụ thuộc vào kiến thức của các chuyên gia đưa ra đánh giá định lượng về các thuộc tính của các thành phần sản phẩm phần mềm.
Một ví dụ về số liệu chương trình bên ngoài được sử dụng rộng rãi là số liệu Halstead - đây là các đặc điểm của chương trình được xác định trên cơ sở cấu trúc tĩnh của chương trình trong ngôn ngữ lập trình cụ thể: số lần xuất hiện của các toán hạng và toán tử xuất hiện thường xuyên nhất; độ dài của mô tả chương trình là tổng số lần xuất hiện của tất cả các toán hạng và toán tử, v.v.
Dựa trên các thuộc tính này, có thể tính toán thời gian lập trình, mức độ của chương trình (cấu trúc và chất lượng) và ngôn ngữ lập trình (sự trừu tượng hóa các công cụ ngôn ngữ và định hướng cho một vấn đề nhất định), v.v.
Số liệu quy trình bao gồm các số liệu:
– chi phí xác định chi phí tạo ra sản phẩm hoặc kiến trúc dự án, có tính đến tính nguyên bản, hỗ trợ và tài liệu phát triển;
– ước tính chi phí công việc chuyên môn cho mỗi người – ngày hoặc tháng;
– độ không tin cậy của quy trình – số lỗi không được phát hiện trong quá trình thiết kế;
- khả năng lặp lại, xác định mức độ sử dụng các thành phần lặp lại.
Số liệu quy trình có thể bao gồm thời gian phát triển, số lỗi được tìm thấy trong giai đoạn thử nghiệm, v.v. Các số liệu quy trình sau đây được sử dụng thực tế:
– tổng thời gian phát triển và thời gian riêng biệt cho từng giai đoạn;
- thời gian sửa đổi mô hình;
- thời gian thực hiện quy trình;
- số lỗi được tìm thấy trong quá trình kiểm tra;
- chi phí kiểm soát chất lượng;
- chi phí của quá trình phát triển.
Số liệu sử dụng dùng để đo lường mức độ thỏa mãn nhu cầu của người dùng khi giải quyết vấn đề của mình. Chúng giúp đánh giá không phải các thuộc tính của chương trình mà là kết quả hoạt động của nó - chất lượng hoạt động. Một ví dụ là tính chính xác và đầy đủ của việc thực hiện các nhiệm vụ của người dùng cũng như các nguồn lực (chi phí lao động, năng suất, v.v.) được sử dụng để giải quyết hiệu quả các nhiệm vụ của người dùng. Việc đánh giá yêu cầu của người dùng được thực hiện chủ yếu bằng cách sử dụng các số liệu bên ngoài.
9.1.2. Phương pháp tiêu chuẩn để đánh giá các giá trị chỉ tiêu chất lượng
Đánh giá chất lượng phần mềm theo mô hình chất lượng bốn cấp bắt đầu từ cấp thấp nhất của hệ thống phân cấp, tức là. từ thuộc tính cơ bản nhất của thuộc tính được đánh giá của chỉ báo chất lượng theo các thước đo đã được thiết lập. Ở giai đoạn thiết kế, giá trị của các yếu tố đánh giá được thiết lập cho từng thuộc tính của chỉ báo của phần mềm được phân tích có trong yêu cầu.
ISO/IES 9126-2 định nghĩa thước đo chất lượng phần mềm là “mô hình đo lường một thuộc tính liên quan đến thước đo chất lượng của nó”. Để sử dụng số liệu khi đo lường các chỉ số chất lượng, tiêu chuẩn này cho phép bạn xác định các loại thước đo sau:
– thước đo kích thước theo các đơn vị đo lường khác nhau (số lượng chức năng, quy mô chương trình, lượng tài nguyên, v.v.);
– thước đo thời gian – khoảng thời gian thực, bộ xử lý hoặc lịch (thời gian vận hành hệ thống, thời gian thực hiện thành phần, thời gian sử dụng, v.v.);
– thước đo nỗ lực – thời gian hiệu quả dành cho việc thực hiện dự án (năng suất lao động của từng người tham gia dự án, cường độ lao động tập thể, v.v.);
- thước đo khoảng thời gian giữa các sự kiện, ví dụ, thời gian giữa các lần hỏng hóc liên tiếp;
– biện pháp đếm – bộ đếm để xác định số lượng lỗi được phát hiện, độ phức tạp về cấu trúc của chương trình, số lượng phần tử không tương thích, số lượng thay đổi (ví dụ: số lượng lỗi được phát hiện, v.v.).
Số liệu chất lượng được sử dụng để đánh giá mức độ có thể kiểm tra sau khi kiểm tra phần mềm trong nhiều thử nghiệm khác nhau (hoạt động không có lỗi, tính khả thi của chức năng, tính dễ sử dụng của giao diện người dùng, cơ sở dữ liệu, v.v.).
MTBF, với tư cách là một thuộc tính độ tin cậy, xác định thời gian trung bình kể từ khi xuất hiện các mối đe dọa bảo mật và đưa ra ước tính khó đo lường về thiệt hại do các mối đe dọa tương ứng gây ra.
Rất thường một chương trình được đánh giá bằng số dòng. Khi so sánh hai chương trình thực hiện một nhiệm vụ ứng dụng, chương trình ngắn sẽ được ưu tiên hơn vì nó được tạo bởi những nhân viên có trình độ cao hơn và có ít lỗi tiềm ẩn hơn cũng như dễ sửa đổi hơn. Nó đắt hơn, mặc dù mất nhiều thời gian hơn để gỡ lỗi và sửa đổi. Những thứ kia. Độ dài chương trình có thể được sử dụng làm thuộc tính phụ trợ khi so sánh các chương trình dựa trên trình độ kỹ năng tương tự của các nhà phát triển, phong cách phát triển chung và môi trường chung.
Nếu các yêu cầu phần mềm được chỉ định thu được một số chỉ báo thì chỉ báo được tính toán sau khi thu thập dữ liệu trong quá trình thực thi sẽ được nhân với hệ số trọng số tương ứng, sau đó tất cả các chỉ báo được tổng hợp để có được đánh giá toàn diện về mức chất lượng phần mềm.
Dựa trên việc đo lường các đặc tính định lượng và tiến hành kiểm tra các chỉ tiêu định tính bằng hệ số trọng số để phân loại các chỉ số khác nhau, đánh giá cuối cùng về chất lượng sản phẩm được tính bằng cách tổng hợp kết quả của từng chỉ tiêu và so sánh chúng với các chỉ tiêu chuẩn của phần mềm (chi phí, thời gian, nguồn lực). , vân vân.).
Những thứ kia. Khi đánh giá một chỉ số riêng lẻ bằng cách sử dụng các yếu tố đánh giá, một hệ số đáng kể sẽ được tính toán k- Hệ mét, j- mục lục, Tôi- thuộc tính. Ví dụ, như j– hãy lấy tính di động làm chỉ báo. Chỉ số này sẽ được tính toán dựa trên năm thuộc tính ( tôi = 1, ..., 5), và mỗi số đó sẽ được nhân với hệ số tương ứng k i .
Tất cả số liệu j– các thuộc tính được tổng hợp và hình thành Tôi - mức độ chất lượng. Khi tất cả các thuộc tính được đánh giá cho từng chỉ số chất lượng, việc đánh giá tổng thể chỉ số riêng lẻ sẽ được thực hiện và sau đó đánh giá chất lượng tổng thể được thực hiện, có tính đến hệ số trọng số của tất cả các chỉ báo phần mềm.
Cuối cùng, kết quả đánh giá chất lượng là tiêu chí đánh giá tính hiệu quả và khả thi của việc sử dụng các phương pháp thiết kế, công cụ và phương pháp đánh giá kết quả tạo ra một sản phẩm phần mềm ở các giai đoạn của vòng đời.
Để trình bày việc đánh giá giá trị của các chỉ số chất lượng, một tiêu chuẩn được sử dụng trình bày các phương pháp sau: đo lường, đăng ký, tính toán và chuyên gia (cũng như sự kết hợp của các phương pháp này).
Phương pháp đo dựa trên việc sử dụng các công cụ đo lường và phần mềm đặc biệt để thu thập thông tin về đặc tính của phần mềm, ví dụ: xác định khối lượng, số dòng mã, toán tử, số nhánh trong chương trình, số điểm vào (ra) , khả năng phản ứng, v.v.
Phương thức đăng kýđược sử dụng khi tính toán thời gian, số lần bị lỗi hoặc bị lỗi, thời điểm bắt đầu và kết thúc hoạt động của phần mềm trong quá trình thực thi.
Phương pháp tính toán dựa trên dữ liệu thống kê được thu thập trong quá trình thử nghiệm, vận hành và bảo trì phần mềm. Phương pháp tính toán được sử dụng để đánh giá các chỉ số về độ tin cậy, độ chính xác, độ ổn định, độ phản ứng, v.v.
Phương pháp chuyên giađược thực hiện bởi một nhóm chuyên gia - những chuyên gia có năng lực giải quyết một nhiệm vụ hoặc loại phần mềm nhất định. Đánh giá của họ dựa trên kinh nghiệm và trực giác chứ không dựa trên kết quả tính toán hoặc thí nghiệm trực tiếp. Phương pháp này được thực hiện bằng cách xem xét các chương trình, mã số, tài liệu đi kèm và góp phần đánh giá chất lượng sản phẩm được tạo ra. Với mục đích này, các đặc điểm được kiểm soát được thiết lập, tương quan với một hoặc nhiều chỉ số chất lượng và được đưa vào phiếu khảo sát chuyên gia. Phương pháp này được sử dụng để đánh giá các chỉ số như khả năng phân tích, khả năng ghi chép, cấu trúc phần mềm, v.v.
Để đánh giá giá trị của các chỉ số chất lượng tùy thuộc vào đặc điểm của các thuộc tính mà chúng sử dụng, mục đích và phương pháp xác định chúng, các thang đo sau được sử dụng:
– số liệu (1.1 – tuyệt đối, 1.2 – tương đối, 1.3 – tích phân);
– thứ tự (xếp hạng), cho phép bạn xếp hạng các đặc điểm bằng cách so sánh với các đặc điểm tham chiếu;
– phân loại, chỉ mô tả sự hiện diện hay vắng mặt của đặc tính đang được xem xét trong phần mềm đang được đánh giá.
Các chỉ số được tính toán bằng thang đo số liệu được gọi là định lượng và các chỉ số được tính bằng thang đo thứ tự và phân loại được gọi là định tính.
Các thuộc tính của một hệ thống phần mềm đặc trưng cho chất lượng của nó được đo bằng các thước đo chất lượng. Số liệu xác định thước đo của thuộc tính, tức là. một biến được gán một giá trị là kết quả của phép đo. Để đảm bảo sử dụng đúng kết quả đo, mỗi thước đo được xác định bằng thang đo.
- thang danh nghĩa phản ánh các loại đặc tính của đối tượng được đánh giá mà không có thứ tự của chúng;
– thang đo thứ tự được sử dụng để sắp xếp các đặc tính theo thứ tự tăng dần hoặc giảm dần bằng cách so sánh chúng với các giá trị cơ bản;
– thang đo khoảng xác định các thuộc tính thiết yếu của một đối tượng (ví dụ: ngày dương lịch);
– thang đo tương đối chỉ định một giá trị nhất định liên quan đến đơn vị được chọn;
– thang đo tuyệt đối cho biết giá trị thực tế của đại lượng (ví dụ số lỗi trong chương trình là 10).
9.1.3. Quản lý chất lượng PS
Dưới quản lý chất lượngđược hiểu là một tập hợp cơ cấu tổ chức và những người chịu trách nhiệm cũng như các thủ tục, quy trình và nguồn lực để lập kế hoạch và quản lý việc đạt được chất lượng phần mềm. Quản lý chất lượng – SQM (Software Quality Management) dựa trên việc áp dụng các quy định tiêu chuẩn về đảm bảo chất lượng – SQA (Software Quality Assurance).
Mục đích của quy trình SQA là đảm bảo rằng các sản phẩm và quy trình phù hợp với yêu cầu, phù hợp với kế hoạch và bao gồm các hoạt động sau:
– thực hiện các tiêu chuẩn và thủ tục liên quan để phát triển phần mềm ở các giai đoạn của vòng đời;
- đánh giá sự tuân thủ các quy định của tiêu chuẩn và thủ tục này.
Việc đảm bảo chất lượng như sau:
- Kiểm tra tính nhất quán và tính khả thi của kế hoạch;
– phối hợp các sản phẩm công việc trung gian với các chỉ số được hoạch định;
- kiểm tra các sản phẩm được sản xuất theo các yêu cầu quy định;
– phân tích các quy trình được áp dụng để tuân thủ hợp đồng và kế hoạch;
– môi trường và phương pháp phát triển nhất quán với trình tự phát triển;
- xác minh các số liệu được chấp nhận của sản phẩm, quá trình và phương pháp đo theo tiêu chuẩn và quy trình đo đã được phê duyệt.
Mục đích của quy trình quản lý SQM là giám sát chất lượng (kiểm soát một cách có hệ thống) để đảm bảo rằng sản phẩm sẽ làm hài lòng khách hàng và bao gồm các hoạt động sau:
- xác định các đặc tính chất lượng định lượng dựa trên nhu cầu của người sử dụng đã được xác định và dự đoán;
- Quản lý việc thực hiện các mục tiêu đã đề ra để đạt được chất lượng.
SQM dựa trên việc đảm bảo rằng:
- mục tiêu để đạt được chất lượng yêu cầu được thiết lập cho tất cả các sản phẩm công việc tại các điểm kiểm soát sản phẩm;
- chiến lược để đạt được chất lượng, thước đo, tiêu chí, kỹ thuật, yêu cầu đối với quá trình đo lường, v.v... đã được xác định;
- các hành động liên quan đến việc cung cấp sản phẩm có đặc tính chất lượng được xác định và thực hiện;
– kiểm soát chất lượng (SQA, xác minh và xác nhận) và các mục tiêu được thực hiện, nếu chúng không đạt được thì các quy trình sẽ được điều chỉnh;
– thực hiện các quá trình đo lường và đánh giá sản phẩm cuối cùng để đạt được chất lượng yêu cầu.
Các quy định tiêu chuẩn chính để tạo ra một sản phẩm chất lượng và đánh giá mức độ đạt được nêu bật hai quy trình đảm bảo chất lượng ở các giai đoạn của vòng đời PS:
– đảm bảo (xác nhận) chất lượng của phần mềm là kết quả của một số hoạt động nhất định ở từng giai đoạn của vòng đời với việc xác minh sự tuân thủ của hệ thống với các tiêu chuẩn và quy trình tập trung vào việc đạt được chất lượng;
– kỹ thuật chất lượng, là quá trình cung cấp các sản phẩm phần mềm với các đặc tính về chức năng, độ tin cậy, bảo trì và các đặc tính chất lượng khác.
Các quy trình chất lượng được thiết kế để:
a) quản lý, phát triển và duy trì sự đảm bảo theo các tiêu chuẩn và thủ tục quy định;
b) quản lý cấu hình (các hành động nhận dạng, tính toán trạng thái và xác thực), rủi ro và dự án theo các tiêu chuẩn và thủ tục;
c) kiểm soát phiên bản cơ bản của phần mềm và các đặc tính chất lượng được triển khai trong đó.
Việc thực hiện các quy trình này bao gồm các hành động sau:
– đánh giá các tiêu chuẩn và thủ tục được tuân thủ khi phát triển chương trình;
– kiểm tra việc quản lý, phát triển và cung cấp đảm bảo chất lượng cho phần mềm cũng như tài liệu dự án (báo cáo, lịch trình phát triển, thông điệp, v.v.);
– kiểm soát việc kiểm tra và xem xét chính thức;
– phân tích và kiểm soát việc nghiệm thu (thử nghiệm) trạm biến áp.
Đối với một tổ chức phát triển phần mềm, kể cả từ các thành phần, kỹ thuật chất lượng phần mềm phải được hỗ trợ bởi hệ thống chất lượng. , quản lý chất lượng (lập kế hoạch, kế toán và kiểm soát).
Kỹ thuật chất lượng bao gồm một tập hợp các phương pháp và hoạt động theo đó các sản phẩm phần mềm được kiểm tra để đáp ứng các yêu cầu về chất lượng và được cung cấp các đặc điểm được cung cấp trong các yêu cầu phần mềm.
Hệ thống chất lượng(Hệ thống chất lượng - QS) là tập hợp các cơ cấu tổ chức, phương pháp, hoạt động, quy trình và nguồn lực để thực hiện quản lý chất lượng. Để đảm bảo mức độ yêu cầu về chất lượng phần mềm, hai phương pháp được sử dụng. Một trong số đó tập trung vào sản phẩm phần mềm cuối cùng và thứ hai tập trung vào quá trình tạo ra sản phẩm.
Theo cách tiếp cận định hướng sản phẩm, việc đánh giá chất lượng được thực hiện sau khi thử nghiệm PS. Cách tiếp cận này dựa trên giả định rằng càng nhiều lỗi được phát hiện và loại bỏ trong sản phẩm trong quá trình thử nghiệm thì chất lượng của sản phẩm đó càng cao.
Ở cách tiếp cận thứ hai, các biện pháp được dự tính và thực hiện để ngăn chặn, xác định kịp thời và loại bỏ lỗi, bắt đầu từ những giai đoạn đầu của vòng đời theo kế hoạch và quy trình để đảm bảo chất lượng của phần mềm được phát triển. Cách tiếp cận này được trình bày trong loạt tiêu chuẩn ISO 9000 và 9000-1,2,3. Mục đích của tiêu chuẩn 9000–3 là đưa ra khuyến nghị cho các tổ chức phát triển nhằm tạo ra một hệ thống chất lượng theo sơ đồ được hiển thị trong Hình 9.3.
Chung
Hệ thống kiểm soát Công việc của người quản lý Chịu trách nhiệm
Chất lượng từ nhà thầu đến khách hàng
Chính sách chung
Trách nhiệm
và quyền hạn
Điều khiển
Kế hoạch thành tích
chất lượng PS
Hình.9.3. Yêu cầu tiêu chuẩn để tổ chức hệ thống chất lượng
Một vị trí quan trọng trong kỹ thuật chất lượng được dành cho quá trình đo lường các đặc điểm của các quá trình trong vòng đời, các nguồn lực của nó và các sản phẩm công việc được tạo ra trên chúng. Quá trình này được thực hiện bởi nhóm Chất lượng, Xác minh và Kiểm tra. Các chức năng của nhóm này bao gồm: lập kế hoạch, quản lý vận hành và đảm bảo chất lượng.
Kế hoạch chất lượngđại diện cho một hoạt động nhằm xác định mục tiêu và yêu cầu chất lượng. Nó bao gồm việc xác định, thiết lập các mục tiêu, yêu cầu chất lượng, phân loại và đánh giá chất lượng. Một kế hoạch lịch được lập ra để phân tích tình trạng phát triển và đo lường một cách nhất quán các chỉ số và tiêu chí đã hoạch định ở các giai đoạn của vòng đời.
Quản lý hoạt động bao gồm các phương pháp và loại hoạt động vận hành để quản lý liên tục quá trình thiết kế, loại bỏ các nguyên nhân khiến trạm biến áp hoạt động không đạt yêu cầu.
Đảm bảo chất lượng bao gồm việc thực hiện và xác minh rằng đối tượng phát triển đáp ứng các yêu cầu chất lượng đã chỉ định. Mục tiêu đảm bảo chất lượng có thể là nội bộ hoặc bên ngoài. Mục tiêu nội bộ là tạo niềm tin cho người quản lý dự án rằng chất lượng đang được đảm bảo. Mục tiêu bên ngoài là tạo niềm tin cho người dùng rằng chất lượng yêu cầu đã đạt được và kết quả là phần mềm có chất lượng cao.
Kinh nghiệm cho thấy một số công ty sản xuất sản phẩm phần mềm có hệ thống chất lượng đảm bảo họ tạo ra những sản phẩm có tính cạnh tranh. Hệ thống chất lượng bao gồm giám sát nhu cầu về loại sản phẩm mới, kiểm soát tất cả các giai đoạn sản xuất PS, bao gồm cả việc lựa chọn và cung cấp các thành phần hệ thống hoàn thiện.
Trong trường hợp không có dịch vụ chất lượng phù hợp, các nhà phát triển phần mềm phải áp dụng các tài liệu quy định và phương pháp luận của riêng họ quy định quy trình quản lý chất lượng phần mềm cho tất cả các loại nhà phát triển và người dùng sản phẩm phần mềm.
9.2. Mô hình đánh giá độ tin cậy
Trong tất cả các lĩnh vực công nghệ phần mềm, độ tin cậy của phần mềm là lĩnh vực được nghiên cứu nhiều nhất. Trước đó là sự phát triển của lý thuyết về độ tin cậy của phương tiện kỹ thuật, lý thuyết này ảnh hưởng đến sự phát triển độ tin cậy của trạm biến áp. Các vấn đề về độ tin cậy của trạm biến áp đã được giải quyết bởi các nhà phát triển trạm biến áp, cố gắng đảm bảo độ tin cậy làm hài lòng khách hàng bằng cách sử dụng các phương tiện hệ thống khác nhau, cũng như bởi các nhà lý thuyết, trong khi nghiên cứu bản chất hoạt động của trạm biến áp, đã tạo ra các mô hình toán học về độ tin cậy có tính đến nhiều khía cạnh khác nhau của vận hành trạm biến áp (xảy ra sai sót, hư hỏng, hư hỏng...) và đánh giá độ tin cậy thực tế. Kết quả là độ tin cậy của PS đã nổi lên như một môn khoa học lý thuyết và ứng dụng độc lập.
Độ tin cậy của PS phức tạp khác biệt đáng kể so với độ tin cậy của thiết bị. Phương tiện lưu trữ dữ liệu (tệp, máy chủ, v.v.) có độ tin cậy cao; các bản ghi trên chúng có thể được lưu trữ trong thời gian dài mà không bị phá hủy vì chúng không bị phá hủy và lão hóa.
Theo quan điểm của khoa học ứng dụng độ tin cậy- đây là khả năng của PS duy trì các đặc tính của nó (vận hành không có lỗi, độ ổn định, v.v.) để chuyển đổi dữ liệu ban đầu thành kết quả trong một khoảng thời gian nhất định trong các điều kiện vận hành nhất định. Độ tin cậy của PS giảm xảy ra do lỗi trong yêu cầu, thiết kế và triển khai. Các lỗi và lỗi phụ thuộc vào phương pháp sản xuất sản phẩm và xuất hiện trong các chương trình trong quá trình thực hiện chúng trong một khoảng thời gian nhất định.
Đối với nhiều hệ thống (chương trình và dữ liệu), độ tin cậy là chức năng mục tiêu chính của việc triển khai. Một số loại hệ thống (thời gian thực, hệ thống radar, hệ thống an ninh, thiết bị y tế có chương trình tích hợp, v.v.) phải tuân theo yêu cầu về độ tin cậy cao, chẳng hạn như khả năng chịu lỗi, độ tin cậy, an toàn, bảo mật, v.v.
Phần mềm Tài liệu
Vân vân. Web màu được cung cấp trong sách giáo khoa, khó nhận thức và hiểu được... công dụng của nó. MM. Petrukhin GOU VPO "... cơ sở. Trong ngày phần mềmkỹ thuật Có hai cách tiếp cận chính để phát triển phần mềmsự cung cấp ...
Trong bài viết này, theo quan điểm của tôi, tôi muốn xem xét một số số liệu QA quan trọng nhất. Đây sẽ là những chỉ số, hệ số và chỉ số cho phép bạn nắm bắt được bức tranh tổng thể về những gì đang diễn ra trong dự án về mặt chất lượng và xác định các bước để cải thiện nó. Các số liệu sẽ bao gồm 5 lĩnh vực khác nhau: yêu cầu, chất lượng phần mềm, hiệu quả của nhóm kiểm tra, chất lượng công việc QA và phản hồi. Điều quan trọng là phải đo lường và theo dõi đồng thời các chỉ số trong các phần khác nhau của quy trình phát triển phần mềm để phát hiện các vấn đề gốc, phổ biến, đồng thời có thể định cấu hình và tối ưu hóa toàn bộ quy trình.
Nhóm 1 - Yêu cầu đối với phần mềm đang phát triển
Nhóm số liệu này sẽ cho phép chúng tôi đánh giá mức độ chúng tôi đã đưa ra các yêu cầu (câu chuyện của người dùng) cho phần mềm tốt như thế nào, xác định các lỗ hổng và các tính năng phần mềm phức tạp nhất, có khả năng xảy ra sự cố cũng như hiểu được nơi cần kiểm soát đặc biệt:
1. Yêu cầu về phạm vi kiểm tra
Nói cách khác, đây là số lượng bài kiểm tra theo yêu cầu.
Mục đích đo lường: xác định điểm yếu trong phạm vi kiểm thử và nêu bật các rủi ro.
- Tất nhiên, số liệu này sẽ chỉ hoạt động nếu các yêu cầu được phân tách tốt và ít nhiều tương đương. Tất nhiên, điều này không phải lúc nào cũng có thể thực hiện được, nhưng nếu bạn có thể thực hiện các yêu cầu ở mức đủ nguyên tử thì số liệu này sẽ hiển thị độ lệch về mức độ bao phủ của từng yêu cầu so với mức trung bình. Giá trị càng khác 1 thì càng ít/nhiều bài kiểm tra được viết cho một yêu cầu hơn bình thường.
- Điều quan trọng nhất cần chú ý là các yêu cầu mà hệ số sẽ bằng hoặc gần bằng 0. Đối với những điều này, bạn cần cân nhắc việc thêm các bài kiểm tra.
- Nếu các yêu cầu không mang tính nguyên tử thì số liệu này sẽ chỉ đảm bảo rằng có ít nhất 1 bài kiểm tra cho mỗi yêu cầu. Để làm được điều này, hệ số phải luôn lớn hơn 0.
2. Mức độ liên kết của các yêu cầu
Số liệu này được tính bằng số lượng kết nối trung bình của từng yêu cầu với các yêu cầu khác.
Mục đích đo lường: cung cấp cơ sở để đánh giá thời gian thử nghiệm và tính đến các rủi ro có thể xảy ra. Ví dụ, khi biết mức độ ảnh hưởng lẫn nhau của các yêu cầu, bạn có thể lập kế hoạch bổ sung thời gian và các trường hợp để thử nghiệm từ đầu đến cuối, thực hiện kiểm tra hồi quy, hướng tới tích hợp, v.v.
- Giá trị của số liệu này sẽ nằm trong khoảng từ 0 đến 1. 1 có nghĩa là mỗi yêu cầu đều liên quan đến từng yêu cầu và 0 có nghĩa là không có mối quan hệ nào.
- Rất khó để đưa ra bất kỳ hạn chế nào đối với các giá trị của hệ số này; phụ thuộc rất nhiều vào đặc điểm cụ thể của chức năng, kiến trúc và công nghệ. Tuy nhiên, theo kinh nghiệm của bản thân, tôi có thể nói rằng sẽ tốt khi mức độ kết nối không vượt quá 0,2-0,3. Mặt khác, việc sửa đổi trong khuôn khổ một trong các yêu cầu sẽ dẫn đến một chuỗi thay đổi và do đó có thể xảy ra lỗi trong một phần quan trọng của sản phẩm.
3. Yêu cầu về hệ số ổn định
Mục đích đo lường: cho thấy có bao nhiêu yêu cầu đã được triển khai phải được làm lại từ bản phát hành này sang bản phát hành khác khi phát triển các tính năng mới.
- Tất nhiên, chức năng hoàn toàn biệt lập không tồn tại, nhưng số lượng yêu cầu mới sẽ chiếm ưu thế so với những yêu cầu đang thay đổi và hệ số tốt nhất nên nhỏ hơn 0,5. Trong trường hợp này, chúng tôi giới thiệu nhiều tính năng mới gấp 2 lần so với việc làm lại những tính năng hiện có.
- Nếu hệ số cao hơn 0,5, đặc biệt nếu nó lớn hơn 1, thì điều này rất có thể có nghĩa là trước đây chúng ta đã làm điều gì đó hóa ra không cần thiết. Nhóm không tập trung vào việc tạo ra các giá trị kinh doanh mới mà tập trung vào việc làm lại các tính năng đã phát hành trước đó.
- Số liệu này cũng đưa ra ý tưởng về mức độ dễ dàng mở rộng quy mô chức năng của hệ thống và bổ sung các tính năng mới.
Nhóm 2 - Chất lượng sản phẩm đang được phát triển
Đúng như tên gọi, nhóm số liệu này thể hiện chất lượng của phần mềm cũng như chất lượng của quá trình phát triển.
1. Mật độ khuyết tật
Tỷ lệ phần trăm lỗi trên mỗi mô-đun riêng lẻ trong quá trình lặp lại hoặc phát hành được tính toán.
Mục đích đo lường: nêu bật phần nào của phần mềm có vấn đề nhất. Thông tin này sẽ giúp đánh giá và lập kế hoạch làm việc với mô-đun này cũng như trong phân tích rủi ro.
- Lý do dẫn đến số lượng lớn lỗi trong bất kỳ mô-đun cụ thể nào (hệ số lớn hơn 0,3) có thể khác nhau: yêu cầu chất lượng kém, trình độ của nhà phát triển, độ phức tạp kỹ thuật, v.v. Trong mọi trường hợp, số liệu này sẽ ngay lập tức thu hút sự chú ý của chúng ta đến khu vực có vấn đề.
2. Hệ số hồi quy
Mục đích đo lường: cho biết nỗ lực của nhóm được sử dụng ở đâu: chúng ta có tham gia nhiều hơn vào việc tạo và gỡ lỗi các tính năng mới hay chúng ta buộc phải vá các phần hiện có của phần mềm trong hầu hết thời gian?
- Hệ số càng gần 0 thì càng ít lỗi xuất hiện trong chức năng hiện có khi triển khai các yêu cầu mới. Nếu giá trị lớn hơn 0,5 thì chúng ta sẽ mất hơn một nửa thời gian để khôi phục các chức năng phần mềm đang hoạt động trước đó
3. Tỷ lệ lỗi được mở lại
Mục đích đo lường:đánh giá chất lượng phát triển và sửa lỗi, cũng như độ phức tạp của sản phẩm hoặc mô-đun riêng lẻ
- Số liệu này có thể được tính cho toàn bộ phần mềm, mô-đun hoặc chức năng riêng lẻ. Giá trị kết quả càng gần 0 thì lỗi cũ càng ít lặp lại trong quá trình phát triển.
- Nếu hệ số lớn hơn 0,2-0,3, điều này có thể cho thấy độ phức tạp kỹ thuật của mô-đun và các yêu cầu có liên quan cao trong đó hoặc kiến trúc vụng về hoặc cách khắc phục trước đó được thực hiện kém.
4. Chi phí trung bình để sửa lỗi
Tỷ lệ giữa số lượng chi phí mà nhóm phải gánh chịu khi xử lý tất cả các lỗi (ví dụ: như một phần của bản phát hành) trên tổng số lỗi.
Mục đích đo lường: cho thấy chúng ta tốn bao nhiêu tiền để phát hiện và sửa từng lỗi. Điều này sẽ giúp tính toán lợi ích của việc giảm số lượng lỗi mắc phải và đánh giá tính khả thi của các kỹ thuật thích hợp.
- Tất nhiên, không có giá trị chính xác ở đây; mọi thứ sẽ được xác định bởi chi tiết cụ thể của một tình huống cụ thể.
5. Số lỗi trong mã của một nhà phát triển cụ thể
Mục đích đo lường: nêu bật những khó khăn có thể xảy ra trong nhóm phát triển mà các chuyên gia thiếu kinh nghiệm, kiến thức hoặc thời gian và cần sự giúp đỡ.
- Ví dụ: nếu 50% tổng số lỗi do 1 nhà phát triển gây ra và có 5 lỗi trong số đó trong nhóm thì rõ ràng là có vấn đề. Điều này không có nghĩa là lập trình viên này làm việc không tốt mà nó báo hiệu rằng cần phải hiểu rõ nguyên nhân dẫn đến tình trạng này.
- Số liệu, trong số những thứ khác, có thể là một chỉ báo về một hệ thống\chức năng\mô-đun đặc biệt khó phát triển và hỗ trợ.
Nhóm 3 – Năng lực và hiệu quả của nhóm QA
Mục đích chính của nhóm số liệu này là thể hiện bằng con số khả năng của nhóm thử nghiệm. Các chỉ số này có thể được tính toán và so sánh một cách thường xuyên, có thể phân tích các xu hướng và người ta có thể quan sát xem công việc của nhóm bị ảnh hưởng như thế nào bởi những thay đổi nhất định.
1. Tốc độ của đội QA
Nó được tính bằng tỷ lệ giữa các điểm câu chuyện (hoặc yêu cầu hoặc câu chuyện của người dùng) được triển khai trên một số lần, chẳng hạn như 4-5 lần lặp (Sprint) với số lần lặp đã chọn.
Mục đích đo lường: thể hiện một cách số lượng khả năng và tốc độ làm việc của nhóm để lập kế hoạch sâu hơn về phạm vi công việc và phân tích các xu hướng phát triển
- Số liệu này cho phép bạn theo dõi tốc độ làm việc của QA và quan sát những quy trình nội bộ hoặc ảnh hưởng bên ngoài nào trong nhóm có thể ảnh hưởng đến tốc độ này.
2. Tuổi thọ trung bình của khuyết tật
Tổng thời gian mà các lỗi được tìm thấy trong một lần lặp hoặc bản phát hành được mở cho tổng số lỗi.
Mục đích đo lường: cho biết trung bình cần bao nhiêu thời gian để xử lý một lỗi: đăng ký, sửa lỗi và tái tạo nó. Chỉ báo này sẽ cho phép bạn ước tính thời gian cần thiết để thử nghiệm và nêu bật các lĩnh vực của phần mềm gặp khó khăn lớn nhất.
- Thông thường, thời gian tồn tại của lỗi là toàn bộ thời gian từ khi tạo (trạng thái Đã tạo) đến khi đóng (Đã đóng), trừ đi tất cả các trường hợp Trì hoãn và Giữ. Bất kỳ trình theo dõi lỗi nào cũng cho phép bạn tính toán và tải thông tin này lên cho một lần chạy nước rút hoặc phát hành riêng.
- Ngoài ra, thời gian tồn tại trung bình của lỗi có thể được tính toán cho các mô-đun và chức năng phần mềm khác nhau hoặc thú vị nhất là riêng biệt cho từng người thử nghiệm và nhà phát triển trong nhóm. Điều này giúp bạn có cơ hội xác định các mô-đun đặc biệt phức tạp hoặc liên kết yếu trong nhóm phần mềm.
Nhóm 4 - Chất lượng công việc của đoàn kiểm thử
Mục đích của bộ số liệu này là để đánh giá mức độ thực hiện nhiệm vụ của người thử nghiệm và xác định mức độ năng lực và sự trưởng thành của nhóm QA. Có một bộ chỉ số như vậy, bạn có thể so sánh nhóm với chính nó ở các thời điểm khác nhau hoặc với các nhóm thử nghiệm bên ngoài khác.
1. Hiệu quả của các thử nghiệm và trường hợp thử nghiệm
Mục đích đo lường: cho thấy trung bình có bao nhiêu lỗi mà trường hợp của chúng tôi có thể phát hiện. Số liệu này phản ánh chất lượng của thiết kế thử nghiệm và giúp theo dõi xu hướng thay đổi của nó.
- Tốt nhất nên tính số liệu này cho tất cả các bộ thử nghiệm: cho các nhóm thử nghiệm chức năng riêng biệt, bộ hồi quy, Thử nghiệm khói, v.v.
- Chỉ báo về mức độ “tử vong” của các xét nghiệm cho phép bạn theo dõi hiệu quả của từng bộ dụng cụ, nó thay đổi như thế nào theo thời gian và bổ sung chúng bằng các xét nghiệm “mới”.
2. Tỷ lệ sai sót trên mỗi sản phẩm
Số lỗi được phát hiện sau khi phát hành \ tổng số lỗi trong phần mềm được phát hiện trong quá trình thử nghiệm và sau khi phát hành
Mục đích đo lường: chứng minh chất lượng kiểm tra và hiệu quả phát hiện lỗi - tỷ lệ lỗi đã được lọc ra và tỷ lệ lỗi được chuyển sang sản xuất.
- Tất nhiên, tỷ lệ phần trăm lỗi có thể chấp nhận được trong quá trình sản xuất sẽ phụ thuộc vào nhiều yếu tố. Tuy nhiên, nếu hệ số >0,1 thì điều này không tốt. Điều này có nghĩa là mọi lỗi thứ mười đều không được phát hiện trong quá trình thử nghiệm và dẫn đến các sự cố trong phần mềm đã được phân phối cho người dùng.
3. Thời gian làm việc thực tế của đội QA
Tỷ lệ thời gian nhóm trực tiếp dành cho các hoạt động QA trên tổng số giờ.
Mục đích đo lường: thứ nhất, để tăng tính chính xác của việc lập kế hoạch, thứ hai, để giám sát và quản lý hiệu suất của một nhóm cụ thể.
- Các hoạt động mục tiêu bao gồm phân tích, thiết kế, đánh giá, thử nghiệm, họp công việc và nhiều hoạt động khác. Các tác dụng phụ có thể xảy ra là thời gian ngừng hoạt động do trình chặn, vấn đề liên lạc, không có tài nguyên, v.v.
- Đương nhiên, hệ số này sẽ không bao giờ bằng 1. Thực tế cho thấy rằng đối với các đội hiệu quả, hệ số này có thể là 0,5-0,6.
4. Độ chính xác của việc ước tính thời gian theo khu vực\loại\loại công việc
Mục đích đo lường: cho phép sử dụng hệ số hiệu chỉnh cho các đánh giá tiếp theo.
- Mức độ chính xác của đánh giá có thể được xác định cho toàn bộ nhóm hoặc từng người kiểm tra, cho toàn bộ hệ thống hoặc các mô-đun phần mềm riêng lẻ.
5. Tỷ lệ lỗi chưa được xác nhận (bị từ chối)
Mục đích đo lường: cho thấy có bao nhiêu khiếm khuyết đã được tạo ra một cách “nhàn rỗi”.
- Nếu tỷ lệ lỗi bị từ chối vượt quá 20% thì nhóm có thể gặp phải tình trạng không đồng bộ trong việc hiểu đâu là lỗi và đâu là không.
Nhóm 5 - Phản hồi và sự hài lòng của người dùng
Và cuối cùng, một nhóm số liệu cho thấy sản phẩm được người dùng cuối chấp nhận như thế nào, sản phẩm đáp ứng mong đợi của họ tốt như thế nào. Nhưng không chỉ phản hồi phần mềm là quan trọng: một nhiệm vụ quan trọng khác của nhóm số liệu này là cho thấy người dùng có hài lòng với quá trình tương tác với nhóm CNTT nói chung và QA nói riêng hay không.
1. Sự hài lòng của người dùng với dịch vụ CNTT
Khảo sát thường xuyên về mức độ hài lòng của người dùng đối với dịch vụ CNTT bằng cách chấm điểm.
Mục đích đo lường: cho thấy liệu người dùng có tin tưởng vào nhóm CNTT hay không, liệu họ có hiểu cách thức và lý do công việc của nhóm được tổ chức hay không cũng như công việc này đáp ứng mong đợi tốt như thế nào.
- Số liệu này có thể đóng vai trò là chỉ báo cho thấy cần tập trung vào việc tối ưu hóa quy trình hoặc làm cho quy trình trở nên rõ ràng và minh bạch hơn cho người dùng.
- Chỉ số hài lòng có thể được tính toán dựa trên kết quả khảo sát sau khi phát hành. Chúng tôi thu thập tất cả các lớp và tính điểm trung bình. Điểm này sau đó có thể được tính toán lại sau khi thực hiện thay đổi trong quy trình.
2. Sự hài lòng của người dùng với sản phẩm
Khảo sát thường xuyên người dùng về mức độ hài lòng của họ với sản phẩm.
Mục đích đo lường: xác định xem sản phẩm đang được phát triển đáp ứng mong đợi của người dùng tốt đến mức nào, liệu chúng ta có đang đi đúng hướng hay không, liệu chúng ta có xác định chính xác tầm quan trọng của các tính năng và chọn các phương án giải pháp hay không.
- Để tính toán số liệu này, chúng tôi cũng tiến hành khảo sát người dùng và tính điểm trung bình. Bằng cách tính toán chỉ số này một cách thường xuyên (ví dụ: sau mỗi lần phát hành), bạn có thể theo dõi xu hướng hài lòng của người dùng.
3. Sự tham gia của các bên liên quan
Số lượng sáng kiến và đề xuất nhằm cải tiến quy trình và sản phẩm nhận được trong quá trình lặp lại (phát hành) từ các bên liên quan
Mục đích đo lường: xác định mức độ tham gia của các bên liên quan bên ngoài vào công việc tạo ra sản phẩm. Có trong tay thước đo như vậy, bạn có thể điều hướng đến nơi bạn cần nhận phản hồi để một ngày nào đó bạn không phải đối mặt với sự khinh thường và thù hận, các vấn đề và hiểu lầm.
Chúng tôi đã phát hành một cuốn sách mới, Tiếp thị nội dung trên mạng xã hội: Cách thu hút người theo dõi và khiến họ yêu thích thương hiệu của bạn.
Hãy tạo một báo cáo. Trong số liệu, hãy chọn “Đạt được mục tiêu” – “Mục tiêu mà bạn đã đặt chuyển đổi”. Đây thường là trang "Cảm ơn bạn đã mua hàng".
Do đó, chúng tôi sẽ nhận được dữ liệu về số lượng giao dịch mua ở mỗi Cộng hòa Kazakhstan và số tiền đã chi để thu hút những người dùng thực hiện chúng. Chia số chuyển đổi cho chi phí nhấp chuột để có được chi phí của một khách hàng tiềm năng. Nếu đã thiết lập xong bạn có thể thêm cột “Doanh thu” để ước tính lợi nhuận nhận được.
Phân khúc để nhắm mục tiêu lại và điều chỉnh giá thầu: cấp độ quan hệ mới với người mua tiềm năng
Trong phần này, chúng tôi sẽ tạo và lưu Yandex.Metrics cũng như xác định các điều chỉnh để sử dụng khi thiết lập chiến dịch trong Trực tiếp.
Hãy nhớ đặt khoảng thời gian để mẫu có tính đại diện. Điều cần thiết là dữ liệu phải được xây dựng trên cơ sở hành vi của một nhóm lớn du khách.
Giới tính và độ tuổi – điều chỉnh
Sau khi tạo báo cáo này, chúng tôi sẽ có thể biết ai mua hàng tốt hơn từ trang web của chúng tôi, nam hay nữ và độ tuổi của những người mua đó là bao nhiêu. Sau này, không có gì ngăn cản chúng tôi điều chỉnh tỷ giá cho phân khúc này.
Chọn: “Báo cáo” – “Khách truy cập” – “Giới tính” (1).
Do đó, chúng tôi thực hiện các điều chỉnh dành cho phụ nữ. Đồng thời, dữ liệu thu được giúp chúng tôi thấy rằng đại diện của phái mạnh cũng dành thời gian trên trang web của chúng tôi. Bạn cần phải làm việc với thông tin này. Ví dụ: viết quảng cáo có liên quan.
Thời gian và đồng hồ - điều chỉnh
Khách truy cập của bạn có thể có các hoạt động khác nhau trong ngày hoặc trong tuần, vì vậy tại thời điểm này, chúng tôi sẽ xác định những ngày và giờ chuyển đổi nhiều nhất cho tài nguyên của bạn, sau đó bạn có thể đặt điều chỉnh thời gian trong Trực tiếp.
“Báo cáo” – “Khách truy cập” – “Tham dự theo thời gian trong ngày”.
Trong các nhóm, chúng tôi thêm: Hành vi: ngày và giờ – “Mảnh ngày/giờ” – “Ngày trong tuần ghé thăm” (2). Chọn mục tiêu và sắp xếp theo chuyển đổi. Chúng tôi nhận được báo cáo hiển thị ngày và thời gian chuyển đổi tối đa.
Địa lý
“Báo cáo” – “Du khách” – “Địa lý”.
Báo cáo sẽ giúp các trang web xác định các khu vực đang bán chạy hơn các khu vực khác. Thông thường, đối với nhiều ngóc ngách, thị phần doanh thu lớn nhất đến từ Moscow hoặc St. Petersburg và các khu vực của họ. Do đó, phần lớn các nhà quảng cáo chia Cộng hòa Kazakhstan của họ thành các thành phố liên bang và phần còn lại của Nga.
Báo cáo địa lý sẽ giúp bạn tìm ra lộ trình phân mảnh hơn nữa các chiến dịch trong Trực tiếp hoặc xác định các chiến dịch quảng cáo theo khu vực có lợi nhuận yếu.
Phân đoạn “Giỏ hàng bị lãng quên”
Chúng tôi tạo: “Báo cáo” – “Khách truy cập” – “Thời gian kể từ lần truy cập đầu tiên”.
Đối với các mục tiêu, chúng tôi sẽ chọn mục tiêu vĩ mô - mua hàng, cuộc hẹn tư vấn tại văn phòng, v.v. Chúng tôi sắp xếp theo chuyển đổi. Chọn 2 dòng đầu tiên để vẽ đồ thị. Nhờ đó, chúng tôi sẽ nhận được thông tin về lượng thời gian khách hàng dành để suy nghĩ về quyết định mua hàng của họ. Ngoài ra, chúng tôi sẽ có thể sử dụng dữ liệu trong giao diện Trực tiếp để tránh hiển thị quảng cáo cho những người không còn cần ưu đãi của chúng tôi nữa.
Từ báo cáo, chúng tôi thấy rằng mục tiêu chủ yếu đạt được vào ngày truy cập, nhưng trong suốt tháng người dùng quay lại và chuyển đổi.
Bây giờ chính phân khúc đó. Chúng tôi sẽ tạo nó cho những người đã bỏ sản phẩm vào giỏ hàng nhưng chưa bao giờ mua nó.
Chúng ta hãy chuyển đến báo cáo “Nguồn” – “Tóm tắt” vốn đã quen thuộc, chỉ để lại dấu kiểm trong cột “Chuyển đổi quảng cáo”, nhấp vào + và chọn từ menu: “Hành vi” – “Đạt được mục tiêu” – “Mục tiêu: đã thêm vào giỏ hàng ” (mục tiêu javascript phải được đặt thành nút "Thêm vào giỏ hàng"). Chúng ta lưu và đặt tên cho phân đoạn, bây giờ hãy chuyển đến Direct.
Chúng tôi tìm thấy quảng cáo mà chúng tôi muốn hiển thị cho phân khúc này, nhấp vào “Điều kiện lựa chọn đối tượng”, sau đó nhấp vào “Thêm điều kiện”.
Báo cáo phân tích trang web: nghiên cứu và cải tiến
Trình giám sát web
Dữ liệu của nó sẽ giúp chúng tôi xác định điểm yếu của trang web và hiểu những khó khăn mà người dùng gặp phải.
Hãy xem xét các phân đoạn Webvisor cho các lượt truy cập mà mục tiêu vĩ mô của chúng tôi đã đạt được.
Hãy lấy một mẫu và xem người dùng đạt được nó như thế nào. Có lẽ chúng ta sẽ hiểu được những kiểu hành vi của khách hàng mà chúng ta chưa hề biết. Điều gì sẽ xảy ra nếu trước khi gửi đơn đặt hàng, hầu hết họ đều xem album ảnh hoặc tương tác với các yếu tố tương tác trên trang web và có lẽ đã dành nhiều thời gian để đánh giá? Dữ liệu đó sẽ giúp bạn quyết định cách định vị và thiết kế chính xác các khối trên trang web.
Phân khúc thứ hai là những người dùng đã dành đủ thời gian trên trang web của chúng tôi để mua hàng nhưng chưa bao giờ thực hiện. Phân tích những chuyến thăm như vậy sẽ cung cấp cái nhìn sâu sắc về những thách thức chính mà du khách phải đối mặt.
Cuộn/nhấp vào bản đồ
Bản đồ cuộn sẽ giúp bạn biết khách truy cập dành nhiều thời gian hơn trên màn hình nào. Có lẽ một số thông tin cần thiết sẽ giúp đưa ra quyết định mua hàng đang ở “vùng lạnh” và cần được chuyển đến nơi khác. Ví dụ: khách hàng chỉ được quảng cáo cho các yêu cầu chỉ ra ga tàu điện ngầm và bản đồ có địa chỉ và chỉ đường nằm ở cuối trang.
Kết quả là tỷ lệ từ chối cao vì vị trí của văn phòng tổ chức rất quan trọng đối với những khách hàng đưa ra những yêu cầu như vậy.
Ngoài SLOC, các đặc điểm định lượng còn bao gồm:
- số dòng trống,
- số lượng ý kiến,
- tỷ lệ phần trăm của nhận xét (tỷ lệ số dòng chứa nhận xét trên tổng số dòng, được biểu thị bằng phần trăm),
- số dòng trung bình cho các hàm (lớp, tệp),
- số dòng trung bình chứa mã nguồn của các hàm (lớp, tệp),
- số hàng trung bình cho các mô-đun.
Cũng nằm trong nhóm số liệu dựa trên việc đếm các đơn vị nhất định trong mã chương trình là số liệu Halstead. Các số liệu này dựa trên các chỉ số sau:
N1 - số câu lệnh chương trình duy nhất, bao gồm các ký hiệu
Dấu phân cách, tên thủ tục và dấu hiệu hoạt động (từ điển toán tử),
N2 - số toán hạng chương trình duy nhất (từ điển toán hạng),
N1 - tổng số câu lệnh trong chương trình,
N2 - tổng số toán hạng trong chương trình,
N1" - số lý thuyết của các toán tử duy nhất,
N2" là số lý thuyết của toán hạng duy nhất.
Có tính đến các ký hiệu được giới thiệu, chúng ta có thể xác định:
N=n1+n2 - từ điển chương trình,
N=N1+N2 - độ dài chương trình,
N"=n1"+n2" - từ điển lý thuyết của chương trình,
N"= n1*log 2 (n1) + n2*log 2 (n2) - độ dài chương trình lý thuyết (đối với các chương trình đúng về mặt phong cách, độ lệch của N so với N" không vượt quá 10%)
V=N*log 2 n - âm lượng chương trình,
V"=N"*log 2 n" là khối lượng lý thuyết của chương trình, trong đó n* là từ điển lý thuyết của chương trình.
L=V"/V - mức chất lượng lập trình, cho một chương trình lý tưởng L=1
L"= (2 n2)/ (n1*N2) - mức chất lượng lập trình, chỉ dựa trên các tham số của chương trình thực mà không tính đến các tham số lý thuyết,
E C =V/(L")2 - khó hiểu chương trình,
D=1/ L" - độ phức tạp của mã hóa chương trình,
Y" = V/ D2 - cấp độ ngôn ngữ biểu đạt
I=V/D - nội dung thông tin của chương trình, đặc điểm này cho phép bạn xác định chi phí tinh thần khi tạo chương trình
E=N" * log 2 (n/L) - đánh giá nỗ lực trí tuệ cần thiết khi phát triển chương trình, mô tả số lượng giải pháp cơ bản cần thiết khi viết chương trình
Khi sử dụng số liệu Halstead, những nhược điểm liên quan đến khả năng ghi cùng chức năng với số dòng và toán tử khác nhau sẽ được bù đắp một phần.
Một loại số liệu phần mềm khác mang tính định lượng là số liệu Gilb. Chúng cho thấy độ phức tạp của phần mềm dựa trên mật độ của các câu lệnh điều kiện hoặc câu lệnh lặp của chương trình. Số liệu này, mặc dù đơn giản nhưng phản ánh khá rõ sự phức tạp của việc viết và hiểu một chương trình và khi thêm một chỉ báo như mức lồng nhau tối đa của các câu lệnh có điều kiện và tuần hoàn, hiệu quả của số liệu này tăng lên đáng kể.
2. Số liệu về độ phức tạp của luồng điều khiển chương trình
Lớp số liệu lớn tiếp theo, không dựa trên các chỉ số định lượng mà dựa trên phân tích biểu đồ điều khiển chương trình, được gọi là số liệu độ phức tạp của luồng điều khiển chương trình.Trước khi mô tả trực tiếp các số liệu, để hiểu rõ hơn, biểu đồ điều khiển của chương trình và phương pháp xây dựng nó sẽ được mô tả.
Hãy để một số chương trình được trình bày. Đối với chương trình này, một đồ thị có hướng được xây dựng chỉ chứa một đầu vào và một đầu ra, trong khi các đỉnh của đồ thị tương quan với các phần của mã chương trình trong đó chỉ có các phép tính tuần tự và không có toán tử nhánh và vòng lặp, và các cung có tương quan với sự chuyển đổi từ khối này sang khối khác và các nhánh thực hiện chương trình. Điều kiện để xây dựng biểu đồ này: mỗi đỉnh có thể truy cập được từ đỉnh đầu tiên và đỉnh cuối cùng có thể truy cập được từ bất kỳ đỉnh nào khác.
Ước tính phổ biến nhất dựa trên phân tích biểu đồ kết quả là độ phức tạp chu kỳ của chương trình (số chu kỳ McCabe). Nó được định nghĩa là V(G)=e - n + 2p, trong đó e là số cung, n là số đỉnh, p là số thành phần được kết nối. Số lượng các thành phần liên thông của một đồ thị có thể được coi là số cung cần được thêm vào để biến đồ thị thành một đồ thị liên thông mạnh. Một đồ thị được gọi là liên thông mạnh nếu có hai đỉnh bất kỳ có thể chạm tới được lẫn nhau. Đối với đồ thị của các chương trình chính xác, tức là đồ thị không có các phần không thể truy cập được từ điểm vào và không có điểm vào và ra “lủng lẳng”, đồ thị được kết nối mạnh thường thu được bằng cách đóng một cung từ một đỉnh biểu thị điểm cuối của chương trình tới một đỉnh biểu thị điểm vào của chương trình này. Về cơ bản, V(G) xác định số lượng mạch độc lập tuyến tính trong đồ thị được kết nối mạnh. Vì vậy, trong các chương trình được viết chính xác, p=1, và do đó công thức tính độ phức tạp chu kỳ có dạng:
V(G)=e - n + 2.
Thật không may, sự đánh giá này không thể phân biệt giữa cấu trúc chu kỳ và cấu trúc có điều kiện. Một hạn chế đáng kể khác của phương pháp này là các chương trình được biểu diễn bằng cùng một biểu đồ có thể có các vị từ có độ phức tạp hoàn toàn khác nhau (vị ngữ là một biểu thức logic chứa ít nhất một biến).
Để khắc phục nhược điểm này, G. Myers đã phát triển một kỹ thuật mới. Để ước tính, ông đề nghị lấy một khoảng (ước tính này còn được gọi là khoảng), trong đó h đối với các vị từ đơn giản bằng 0 và đối với các vị từ n-ary h = n-1. Phương pháp này giúp phân biệt các vị từ có độ phức tạp khác nhau, nhưng trong thực tế nó hầu như không bao giờ được sử dụng.
Một sửa đổi khác của phương pháp McCabe là phương pháp Hansen. Thước đo độ phức tạp của chương trình trong trường hợp này được biểu diễn dưới dạng một cặp (độ phức tạp chu kỳ, số lượng câu lệnh). Ưu điểm của biện pháp này là độ nhạy của nó đối với cấu trúc của phần mềm.
Thước đo tôpô của Chen thể hiện độ phức tạp của một chương trình về số lượng điểm giao cắt ranh giới giữa các vùng được hình thành bởi biểu đồ chương trình. Cách tiếp cận này chỉ áp dụng cho các chương trình có cấu trúc chỉ cho phép kết nối tuần tự các cấu trúc điều khiển. Đối với các chương trình phi cấu trúc, độ đo Chen phụ thuộc đáng kể vào các nhánh có điều kiện và không có điều kiện. Trong trường hợp này, bạn có thể chỉ định giới hạn trên và giới hạn dưới của thước đo. Số trên cùng là m+1, trong đó m là số lượng toán tử logic lồng nhau. Giá trị dưới bằng 2. Khi biểu đồ điều khiển của chương trình chỉ có một thành phần liên thông, độ đo Chen trùng với độ đo chu kỳ McCabe.
Tiếp tục chủ đề phân tích biểu đồ kiểm soát của một chương trình, chúng ta có thể phân biệt một nhóm số liệu phụ khác - số liệu Harrison và Majel.
Những biện pháp này có tính đến mức độ đầu tư và thời gian của chương trình.
Mỗi đỉnh được gán độ phức tạp riêng tùy theo toán tử mà nó đại diện. Độ phức tạp của đỉnh ban đầu này có thể được tính theo bất kỳ cách nào, bao gồm cả việc sử dụng các phép đo Halstead. Đối với mỗi đỉnh vị ngữ, chúng ta chọn một đồ thị con được tạo bởi các đỉnh là điểm cuối của các cung xuất phát từ nó, cũng như các đỉnh có thể tiếp cận được từ mỗi đỉnh đó (ranh dưới của đồ thị con) và các đỉnh nằm trên các đường đi từ đỉnh vị ngữ tới một biên dưới nào đó. Đồ thị con này được gọi là phạm vi ảnh hưởng của đỉnh vị ngữ.
Độ phức tạp rút gọn của một đỉnh vị ngữ là tổng độ phức tạp ban đầu hoặc độ phức tạp rút gọn của các đỉnh nằm trong phạm vi ảnh hưởng của nó, cộng với độ phức tạp cơ bản của chính đỉnh vị ngữ đó.
Độ đo chức năng (SCOPE) của một chương trình là tổng độ phức tạp đã giảm của tất cả các đỉnh của biểu đồ điều khiển.
Quan hệ hàm số (SCORT) là tỷ lệ giữa số đỉnh trong biểu đồ điều khiển với độ phức tạp hàm của nó và các đỉnh cuối được loại trừ khỏi số đỉnh.
SCORT có thể lấy các giá trị khác nhau cho các đồ thị có cùng số chu trình.
Số liệu Pivovarsky là một sửa đổi khác của thước đo độ phức tạp chu kỳ. Nó cho phép bạn theo dõi sự khác biệt không chỉ giữa các cấu trúc điều khiển tuần tự và lồng nhau mà còn giữa các chương trình có cấu trúc và không cấu trúc. Nó được biểu thị bằng quan hệ N(G) = v *(G) + SUMMAPi, trong đó v *(G) là độ phức tạp chu trình được sửa đổi, được tính theo cách tương tự như V(G), nhưng có một điểm khác biệt: câu lệnh CASE với n đầu ra được coi là một toán tử logic, thay vì n -1 toán tử.
Pi là độ sâu lồng của đỉnh vị ngữ thứ i. Để tính toán độ sâu lồng của các đỉnh vị ngữ, số lượng “phạm vi ảnh hưởng” được sử dụng. Độ sâu lồng nhau được hiểu là số lượng tất cả "phạm vi ảnh hưởng" của các vị từ nằm hoàn toàn trong phạm vi của đỉnh được đề cập hoặc giao nhau với nó. Độ sâu của việc lồng ghép tăng lên do việc lồng ghép không phải của các vị từ mà là của “phạm vi ảnh hưởng”. Biện pháp Pivovarsky tăng lên khi chuyển từ các chương trình tuần tự sang chương trình lồng nhau và sau đó sang chương trình không có cấu trúc, đây là lợi thế rất lớn của nó so với nhiều biện pháp khác của nhóm này.
Thước đo Woodward - số giao điểm của các cung của biểu đồ điều khiển. Vì những tình huống như vậy sẽ không xảy ra trong một chương trình có cấu trúc tốt nên số liệu này được sử dụng chủ yếu trong các ngôn ngữ có cấu trúc yếu (Assembler, Fortran). Điểm giao nhau xảy ra khi điều khiển vượt ra ngoài hai đỉnh là các toán tử tuần tự.
Phương pháp giá trị biên cũng dựa trên việc phân tích đồ thị điều khiển của chương trình. Để định nghĩa phương pháp này, cần phải đưa ra một số khái niệm bổ sung.
Gọi G là đồ thị điều khiển của chương trình có một đỉnh đầu và một đỉnh cuối.
Trong biểu đồ này, số đỉnh đi tới của các cung được gọi là bậc âm của đỉnh và số cung đi ra từ đỉnh được gọi là bậc dương của đỉnh. Khi đó tập hợp các đỉnh đồ thị có thể được chia thành hai nhóm: các đỉnh có bậc dương<=1; вершины, у которых положительная степень >=2.
Chúng ta sẽ gọi các đỉnh của nhóm thứ nhất là các đỉnh nhận và các đỉnh của nhóm thứ hai là các đỉnh chọn.
Mỗi đỉnh nhận có độ phức tạp giảm đi là 1, ngoại trừ đỉnh cuối có độ phức tạp giảm xuống bằng 0. Độ phức tạp giảm của tất cả các đỉnh trong G được tổng hợp để tạo thành độ phức tạp biên tuyệt đối của chương trình. Sau đó, độ phức tạp cận biên tương đối của chương trình được xác định:
Trong đó S0 là độ phức tạp biên tương đối của chương trình, Sa là độ phức tạp biên tuyệt đối của chương trình, v là tổng số đỉnh của đồ thị chương trình.
Có một thước đo Schneidewind, được biểu thị bằng số lượng đường dẫn có thể có trong biểu đồ điều khiển.
3. Số liệu độ phức tạp của luồng dữ liệu
Lớp số liệu tiếp theo là số liệu độ phức tạp của luồng kiểm soát dữ liệu.Số liệu Chapin: bản chất của phương pháp là đánh giá sức mạnh thông tin của một mô-đun phần mềm bằng cách phân tích bản chất của việc sử dụng các biến từ danh sách đầu vào-đầu ra.
Toàn bộ tập hợp các biến tạo nên danh sách I/O được chia thành 4 nhóm chức năng:
1. P - biến đầu vào để tính toán và cung cấp đầu ra,
2. M - các biến được sửa đổi hoặc tạo trong chương trình,
3. C - các biến tham gia điều khiển hoạt động của module phần mềm (biến điều khiển),
Vì mỗi biến có thể thực hiện đồng thời nhiều chức năng nên nó phải được xem xét trong từng nhóm chức năng tương ứng.
Số liệu Chapin:
Q = a1*P + a2*M + a3*C + a4*T,
Trong đó a1, a2, a3, a4 là các hệ số trọng số.
Q = P + 2M + 3C + 0,5T
Số liệu khoảng thời gian dựa trên việc bản địa hóa các quyền truy cập dữ liệu trong mỗi phần chương trình. Spen là số câu lệnh chứa một mã định danh nhất định giữa lần xuất hiện đầu tiên và cuối cùng của nó trong văn bản chương trình. Do đó, mã định danh xuất hiện n lần có khoảng n-1. Với span lớn, việc kiểm tra và gỡ lỗi trở nên phức tạp hơn.
Một thước đo khác tính đến độ phức tạp của luồng dữ liệu là thước đo liên quan đến độ phức tạp của chương trình khi truy cập vào các biến toàn cục.
Một cặp biến toàn cục mô-đun được ký hiệu là (p,r), trong đó p là mô-đun có quyền truy cập vào biến toàn cục r. Tùy thuộc vào việc chương trình có thực sự truy cập vào biến r hay không, hai loại cặp “mô-đun - biến toàn cục” được hình thành: thực tế và có thể. Việc tham chiếu có thể tới r bằng p cho thấy miền tồn tại của r bao gồm p.
Đặc điểm này được biểu thị bằng Aup và cho biết số lần các mô-đun Up thực sự đã truy cập các biến toàn cục và số Pup cho biết số lần chúng có thể đã truy cập chúng.
Tỷ lệ số cuộc gọi thực tế và số cuộc gọi có thể được xác định
Công thức này cho thấy xác suất gần đúng của một mô-đun tùy ý tham chiếu đến một biến toàn cục tùy ý. Rõ ràng, xác suất này càng cao thì xác suất thay đổi bất kỳ biến nào “trái phép” càng cao, điều này có thể làm phức tạp đáng kể công việc liên quan đến sửa đổi chương trình.
Thước đo Kafur được tạo ra dựa trên khái niệm về luồng thông tin. Để sử dụng thước đo này, các khái niệm về dòng chảy cục bộ và toàn cầu được giới thiệu: luồng thông tin cục bộ từ A đến B tồn tại nếu:
1. Mô-đun A gọi mô-đun B (luồng cục bộ trực tiếp)
2. Mô-đun B gọi mô-đun A và A trả về B một giá trị được sử dụng trong B (luồng cục bộ gián tiếp)
3. Mô-đun C gọi mô-đun A, B và chuyển kết quả thực hiện mô-đun A sang B.
Tiếp theo, chúng ta nên đưa ra khái niệm về luồng thông tin toàn cầu: luồng thông tin toàn cầu từ A đến B thông qua cấu trúc dữ liệu toàn cầu D tồn tại nếu mô-đun A đưa thông tin vào D và mô-đun B sử dụng thông tin từ D.
Dựa trên những khái niệm này, giá trị I được giới thiệu - độ phức tạp thông tin của thủ tục:
Tôi = chiều dài * (fan_in * fan_out)2
Đây:
Độ dài - độ phức tạp của văn bản thủ tục (được đo thông qua một trong các số liệu âm lượng, chẳng hạn như số liệu Halstead, McCabe, LOC, v.v.)
Fan_in - số lượng luồng cục bộ đi vào thủ tục cộng với số lượng cấu trúc dữ liệu mà thủ tục lấy thông tin từ đó
Fan_out - số lượng luồng cục bộ phát ra từ thủ tục cộng với số lượng cấu trúc dữ liệu được thủ tục cập nhật
Độ phức tạp thông tin của một mô-đun có thể được định nghĩa là tổng độ phức tạp thông tin của các thủ tục có trong nó.
Bước tiếp theo là xem xét độ phức tạp thông tin của một mô-đun so với một số cấu trúc dữ liệu. Thước đo thông tin về độ phức tạp của mô-đun liên quan đến cấu trúc dữ liệu:
J = W * R + W * RW + RW *R + RW * (RW - 1)
W là số thủ tục chỉ cập nhật cấu trúc dữ liệu;
R - chỉ đọc thông tin từ cấu trúc dữ liệu;
RW - vừa đọc vừa cập nhật thông tin trong cấu trúc dữ liệu.
Một thước đo khác trong nhóm này là thước đo Oviedo. Bản chất của nó là chương trình được chia thành các phần tuyến tính không giao nhau - các tia toán tử tạo thành biểu đồ điều khiển của chương trình.
Tác giả của phép đo đưa ra các giả định sau: người lập trình có thể tìm thấy mối quan hệ giữa việc xác định và sử dụng lần xuất hiện của một biến trong một tia dễ dàng hơn so với giữa các tia; Số lần xuất hiện xác định riêng biệt trong mỗi tia quan trọng hơn tổng số lần xuất hiện có thể sử dụng biến đổi trong mỗi tia.
Chúng ta hãy biểu thị bằng R(i) tập hợp các lần xuất hiện xác định của các biến nằm trong bán kính tác dụng của tia i (sự xuất hiện xác định của một biến nằm trong bán kính tác dụng của tia nếu biến đó hoặc là cục bộ trong đó và có một sự xuất hiện xác định, hoặc đối với nó, có một sự xuất hiện xác định trong một số tia trước đó và không có định nghĩa cục bộ dọc theo đường đi). Chúng ta hãy biểu thị bằng V(i) tập hợp các biến có sự xuất hiện trong tia i. Khi đó thước đo độ phức tạp của tia thứ i được cho là:
DF(i)=SUM(DEF(v j)), j=i...||V(i)||
Trong đó DEF(v j) là số lần xuất hiện xác định của biến v j từ tập hợp R(i) và ||V(i)|| - lũy thừa của tập V(i).
4. Số liệu về luồng điều khiển và độ phức tạp của dữ liệu chương trình
Lớp số liệu thứ tư là các số liệu gần với cả lớp số liệu định lượng, lớp số liệu độ phức tạp của luồng điều khiển chương trình và lớp số liệu độ phức tạp của luồng điều khiển dữ liệu (nói đúng ra là lớp số liệu này và lớp kiểm soát chương trình). Các số liệu về độ phức tạp của luồng là cùng một lớp - các số liệu tôpô, nhưng sẽ hợp lý nếu tách chúng ra trong ngữ cảnh này cho rõ ràng). Lớp số liệu này thiết lập mức độ phức tạp của cấu trúc chương trình trên cơ sở tính toán định lượng và trên cơ sở phân tích các cấu trúc điều khiển.Số liệu đầu tiên trong số này là M-Measure thử nghiệm. Độ đo kiểm tra M là thước đo độ phức tạp thỏa mãn các điều kiện sau:
Biện pháp này tăng theo độ sâu lồng và có tính đến độ dài của chương trình. Liên quan chặt chẽ đến biện pháp kiểm tra là biện pháp dựa trên việc nhúng thường xuyên. Ý tưởng của thước đo độ phức tạp của chương trình này là đếm tổng số ký tự (toán hạng, toán tử, dấu ngoặc đơn) trong một biểu thức chính quy với số dấu ngoặc đơn yêu cầu tối thiểu mô tả biểu đồ điều khiển của chương trình. Tất cả các biện pháp trong nhóm này đều nhạy cảm với việc lồng ghép các cấu trúc điều khiển và độ dài của chương trình. Tuy nhiên, mức độ phức tạp tính toán tăng lên.
Ngoài ra, thước đo chất lượng phần mềm là sự gắn kết của các module chương trình. Nếu các mô-đun được liên kết chặt chẽ thì chương trình sẽ trở nên khó sửa đổi và khó hiểu. Biện pháp này không được thể hiện bằng số. Các loại kết nối mô-đun:
Kết nối dữ liệu - nếu các mô-đun tương tác thông qua việc truyền tham số và mỗi tham số là một đối tượng thông tin cơ bản. Đây là loại kết nối (khớp nối) được ưa thích nhất.
Kết nối theo cấu trúc dữ liệu - nếu một mô-đun gửi một đối tượng (cấu trúc) thông tin tổng hợp khác để trao đổi dữ liệu.
Khớp nối điều khiển - nếu một đối tượng gửi một đối tượng thông tin khác - một cờ được thiết kế để kiểm soát logic bên trong của nó.
Các mô-đun được liên kết bởi một khu vực chung nếu chúng tham chiếu đến cùng một khu vực dữ liệu toàn cầu. Việc ghép nối trên phạm vi toàn cầu là điều không mong muốn vì trước tiên, một lỗi trong mô-đun sử dụng phạm vi toàn cầu có thể xuất hiện bất ngờ trong bất kỳ mô-đun nào khác; thứ hai, những chương trình như vậy rất khó hiểu vì người lập trình khó xác định dữ liệu nào được sử dụng bởi một mô-đun cụ thể.
Sự gắn kết theo nội dung - nếu một trong các mô-đun liên kết bên trong một mô-đun khác. Đây là kiểu ghép nối không thể chấp nhận được vì nó hoàn toàn trái ngược với nguyên tắc mô đun hóa, tức là biểu diễn mô-đun dưới dạng hộp đen.
Khớp nối bên ngoài - hai mô-đun chia sẻ dữ liệu bên ngoài, chẳng hạn như giao thức truyền thông.
Kết nối sử dụng tin nhắn là loại kết nối tự do nhất; các mô-đun không được kết nối trực tiếp với nhau mà giao tiếp thông qua các tin nhắn không có tham số.
Thiếu khớp nối - các mô-đun không tương tác với nhau.
Ghép lớp con là mối quan hệ giữa lớp cha và lớp con, trong đó lớp con có liên quan đến lớp cha nhưng lớp cha không liên quan đến lớp con.
Liên quan đến thời gian - hai hành động được nhóm lại trong một mô-đun chỉ vì chúng xảy ra cùng một lúc do hoàn cảnh.
Một thước đo khác liên quan đến độ ổn định của mô-đun là thước đo Colofello, nó có thể được định nghĩa là số lượng thay đổi được yêu cầu thực hiện trong các mô-đun không phải là mô-đun có độ ổn định đang được kiểm tra và những thay đổi này phải liên quan đến mô-đun đang được kiểm tra .
Số liệu tiếp theo của lớp này là Số liệu McClure. Có ba giai đoạn trong việc tính toán số liệu này:
1. Đối với mỗi biến điều khiển i, giá trị hàm phức tạp C(i) của nó được tính bằng công thức: C(i) = (D(i) * J(i))/n.
Trong đó D(i) là giá trị đo phạm vi của biến i. J(i) là thước đo độ phức tạp trong tương tác của các mô-đun thông qua biến i, n là số lượng mô-đun riêng lẻ trong sơ đồ phân vùng.
2. Đối với tất cả các mô-đun có trong phạm vi phân vùng, giá trị hàm phức tạp M(P) của chúng được xác định theo công thức M(P) = fp * X(P) + gp * Y(P)
trong đó fp và gp lần lượt là số lượng mô-đun ngay trước và ngay sau mô-đun P, X(P) là độ phức tạp của việc truy cập mô-đun P,
Y(P) - độ phức tạp của việc điều khiển cuộc gọi từ mô-đun P của các mô-đun khác.
3. Độ phức tạp tổng thể của sơ đồ phân cấp MP để chia chương trình thành các mô-đun được tính theo công thức:
MP = SUM(M(P)) trên tất cả các giá trị có thể có của P - mô-đun chương trình.
Số liệu này tập trung vào các chương trình có cấu trúc tốt, bao gồm các mô-đun phân cấp xác định đặc tả chức năng và cấu trúc điều khiển. Cũng giả định rằng mỗi mô-đun có một điểm vào và một điểm thoát, mô-đun thực hiện chính xác một chức năng và các mô-đun được gọi theo hệ thống điều khiển phân cấp chỉ định mối quan hệ cuộc gọi trên nhiều mô-đun chương trình.
Ngoài ra còn có một thước đo dựa trên khái niệm thông tin, thước đo Berlinger. Độ phức tạp được tính bằng M=SUMf i *log 2 p i , trong đó f i là tần suất xuất hiện của ký hiệu thứ i, p i là xác suất xuất hiện của nó.
Nhược điểm của phép đo này là một chương trình chứa nhiều ký tự duy nhất nhưng với số lượng nhỏ sẽ có độ phức tạp tương tự như chương trình chứa một số lượng nhỏ ký tự duy nhất nhưng với số lượng lớn.
5. Số liệu hướng đối tượng
Liên quan đến sự phát triển của các ngôn ngữ lập trình hướng đối tượng, một loại thước đo mới đã xuất hiện, còn được gọi là thước đo hướng đối tượng. Trong nhóm này, bộ số liệu được sử dụng phổ biến nhất là bộ số liệu Martin và bộ số liệu Chidamber và Kemerer. Đầu tiên, chúng ta hãy nhìn vào nhóm con đầu tiên.Trước khi bắt đầu xem xét các thước đo Martin, cần phải giới thiệu khái niệm về danh mục lớp. Trong thực tế, một lớp hiếm khi được sử dụng lại một cách tách biệt với các lớp khác. Hầu hết mọi lớp đều có một nhóm các lớp mà nó hợp tác làm việc và không thể dễ dàng tách nó ra khỏi nhóm đó. Để sử dụng lại các lớp như vậy, bạn phải sử dụng lại toàn bộ nhóm lớp. Một nhóm các lớp như vậy có mối liên hệ chặt chẽ với nhau và được gọi là một phạm trù các lớp. Để tồn tại một thể loại lớp, các điều kiện sau tồn tại:
Các lớp trong một danh mục lớp bị khóa khỏi mọi nỗ lực thay đổi tất cả chúng cùng nhau. Điều này có nghĩa là nếu một lớp thay đổi thì tất cả các lớp trong danh mục đó đều có khả năng thay đổi. Nếu bất kỳ lớp nào cởi mở với một loại thay đổi nào đó thì tất cả họ đều cởi mở với loại thay đổi đó.
Các lớp trong một danh mục chỉ được sử dụng lại cùng nhau. Chúng rất phụ thuộc lẫn nhau và không thể tách rời nhau. Vì vậy, nếu có bất kỳ nỗ lực nào được thực hiện để sử dụng lại một lớp trong một danh mục thì tất cả các lớp khác phải được sử dụng lại cùng với nó.
Trách nhiệm, tính độc lập và tính ổn định của một danh mục có thể được đo lường bằng cách đếm các phụ thuộc tương tác với danh mục đó. Ba số liệu có thể được xác định:
1. Ca: Lực dính hướng tâm. Số lớp ngoài danh mục này phụ thuộc vào các lớp trong danh mục này.
2. Ce: Ly hợp ly tâm. Số lớp trong danh mục này phụ thuộc vào các lớp bên ngoài danh mục này.
3. I: Tính không ổn định: I = Ce / (Ca+Ce). Số liệu này có một loạt các giá trị.
I = 0 chỉ ra loại ổn định nhất.
I = 1 chỉ ra loại không ổn định nhất.
Bạn có thể xác định một số liệu đo lường tính trừu tượng (nếu một danh mục là trừu tượng thì nó đủ linh hoạt và có thể dễ dàng mở rộng) của một danh mục như sau:
A: Tính trừu tượng: A = nA/nAll.
NA - số_of_abstract_classes_in_category.
Không phải tất cả - tổng_số_of_classes_in_category.
Các giá trị của số liệu này khác nhau trong phạm vi.
Bây giờ, dựa trên số liệu Martin ở trên, bạn có thể xây dựng biểu đồ thể hiện mối quan hệ giữa tính trừu tượng và tính không ổn định. Nếu chúng ta dựng một đường thẳng trên đó, cho theo công thức I+A=1, thì đường thẳng này sẽ chứa các danh mục có sự cân bằng tốt nhất giữa tính trừu tượng và tính không ổn định. Dòng này được gọi là chuỗi chính.
Khoảng cách đến dãy chính: D=|(A+I-1)/sqrt(2)|
Khoảng cách chuẩn hóa đến chuỗi chính: Dn=|A+I-2|
Đúng với hầu hết mọi thể loại, càng gần với trình tự chính thì càng tốt.
Nhóm số liệu tiếp theo là số liệu Chidamber và Kemerer. Các số liệu này dựa trên phân tích các phương thức lớp, cây kế thừa, v.v.
WMC (Các phương thức có trọng số trên mỗi lớp), tổng độ phức tạp của tất cả các phương thức của lớp: WMC=SUMAc i , i=1...n, trong đó c i là độ phức tạp của phương thức thứ i, được tính bằng cách sử dụng bất kỳ số liệu nào ( Halstead, v.v. tùy thuộc vào tiêu chí quan tâm), nếu tất cả các phương pháp có cùng độ phức tạp thì WMC=n.
DIT (Độ sâu của cây kế thừa) - độ sâu của cây kế thừa (đường dẫn dài nhất dọc theo hệ thống phân cấp lớp đến một lớp nhất định từ lớp tổ tiên), càng lớn thì càng tốt, vì độ sâu trừu tượng của dữ liệu càng tăng, độ bão hòa của lớp với các phương thức giảm đi, nhưng với độ sâu đủ lớn, độ khó để hiểu và viết chương trình tăng lên rất nhiều.
NOC (Number of child) – số lượng con cháu (ngay lập tức), càng nhiều thì độ trừu tượng dữ liệu càng cao.
CBO (Coupling between object class) - khớp nối giữa các lớp, hiển thị số lượng lớp mà lớp gốc được liên kết. Đối với thước đo này, tất cả các câu lệnh được giới thiệu trước đó về khả năng kết nối của các mô-đun đều hợp lệ, nghĩa là với CBO cao, khả năng trừu tượng hóa dữ liệu sẽ giảm và việc tái sử dụng lớp trở nên khó khăn hơn.
RFC (Phản hồi cho một lớp) - RFC=|RS|, trong đó RS là tập phản hồi của một lớp, nghĩa là tập hợp các phương thức có thể được gọi bởi một phương thức lớp để phản hồi dữ liệu mà một đối tượng của lớp đó nhận được lớp học. Nghĩa là, RS=(((M)((R i )), i=1...n, trong đó M là tất cả các phương thức có thể có của lớp, R i là tất cả các phương thức có thể được gọi bởi lớp thứ i class. Khi đó RFC sẽ là sức mạnh của bộ này. Càng nhiều RFC thì việc kiểm tra và gỡ lỗi càng khó.
LCOM (Thiếu sự gắn kết trong Phương pháp) - thiếu sự gắn kết của các phương pháp. Để xác định tham số này, hãy xem lớp C với n phương thức M1, M2,… ,Mn, khi đó (I1),(I2),...,(In) là tập hợp các biến được sử dụng trong các phương thức này. Bây giờ chúng ta định nghĩa P - một tập hợp các cặp phương thức không có biến chung; Q là tập hợp các cặp phương thức có các biến chung. Khi đó LCOM=|P|-|Q|. Thiếu sự gắn kết có thể là tín hiệu cho thấy lớp có thể bị chia thành nhiều lớp hoặc lớp con khác, vì vậy tốt hơn là tăng sự gắn kết để tăng khả năng đóng gói dữ liệu và giảm độ phức tạp của các lớp và phương thức.
6. Số liệu về độ tin cậy
Loại thước đo tiếp theo là những thước đo gần với định lượng nhưng dựa trên số lượng lỗi và khiếm khuyết trong chương trình. Không có ích gì khi xem xét các tính năng của từng số liệu này, chỉ cần liệt kê chúng là đủ: số lượng thay đổi cấu trúc được thực hiện kể từ lần kiểm tra cuối cùng, số lượng lỗi được xác định trong quá trình xem xét mã, số lượng lỗi được xác định trong quá trình lập trình kiểm tra và số lượng thay đổi cấu trúc cần thiết để vận hành chương trình chính xác. Đối với các dự án lớn, các chỉ số này thường được xem xét liên quan đến hàng nghìn dòng mã, tức là. số lỗi trung bình trên một nghìn dòng mã.7. Số liệu kết hợp
Cuối cùng, cần phải đề cập đến một loại số liệu khác được gọi là số liệu kết hợp. Các số liệu của lớp này dựa trên các số liệu đơn giản hơn và thể hiện tổng có trọng số của chúng. Đại diện đầu tiên của lớp này là thước đo Kokol. Nó được định nghĩa như sau:H_M = (M + R1 * M(M1) +… + Rn * M(Mn)/(1 + R1 +… + Rn)
Trong đó M là thước đo cơ bản, Mi là các thước đo thú vị khác, Ri là các hệ số được chọn chính xác, M(Mi) là các hàm.
Các hàm M(Mi) và hệ số Ri được tính toán bằng phân tích hồi quy hoặc phân tích bài toán cho một chương trình cụ thể.
Số liệu Zolnovsky, Simmons, Thayer cũng là tổng trọng số của nhiều chỉ số khác nhau. Có hai tùy chọn cho số liệu này:
(cấu trúc, tương tác, khối lượng, dữ liệu) SUM(a, b, c, d).
(độ phức tạp của giao diện, độ phức tạp tính toán, độ phức tạp I/O, khả năng đọc) SUM(x, y, z, p).
Các chỉ số sử dụng trong mỗi phương án được lựa chọn tùy thuộc vào nhiệm vụ cụ thể, các hệ số - tùy thuộc vào giá trị của chỉ số để đưa ra quyết định trong trường hợp này.
