Показатели качества программ и варианты их упорядочения

Показатели качества программ и варианты их упорядочения

Как справедливо отмечается в http://oop.cs.technion.ac.il/236804-Fall-1997/metrics/part1.html в качестве параметров, характеризующих программу, могут выступать самые разнообразные показатели. Вплоть до веса распечатки в граммах, который можно рассматривать как грубое приближение наиболее распространенного показателя – числа строк кода. Поэтому вопрос заключается в выборе наиболее информативных показателей и соответствующих подходов для их сопоставления, выработке компромиссов и получения интегральных оценок.

В конечном счете, качество программы определяется ее потребительскими свойствами, и имеет стоимостное выражение, включающее оценки затрат на разработку и эксплуатацию, экономических выгод применения программы по сравнению с другими средствами решения данной прикладной задачи, а также перспектив дальнейшего использования наработанного программного материала при изменении окружения. Легче всего оценить эксплуатационные затраты на технические и программные средства, а также, услуги (например, аренду линий связи). Значительно труднее оценить перспективы.

Выгоды от эксплуатации программы определяет комплекс оценок, включающий проверку выполнения предписанных ей функций в реальных жизненных ситуациях, а также удобства ее использования по сравнению с другими средствами решения задачи.

Реальные ситуации включают как нормальные условия, так и всевозможные неблагоприятные обстоятельства (ошибки оператора, сбои и отказы среды, исчерпанность ресурсов, преднамеренные «атаки»). Время обслуживания включает, в частности, время на восстановление после сбоев/отказов, в том числе, время, необходимое для подключения специального персонала. А стоимостная оценка соответственно оплату этого персонала.

Большинство из характеристик, определяющих удобство, могут быть оценены в единицах времени: время, необходимое на освоение программы, время для подготовки входных данных, время выполнения задания, время анализа выходных данных и даже время, необходимое для восстановления сил пользователя после работы с программой. Если учесть заработную плату пользователя, то удобство можно выразить в денежных единицах.

Таким образом, даже в рамках целевых (потребительских) показателей программы имеется множество измерений, но реальные технические ориентиры еще более многообразны и противоречивы. Тем актуальней стоит вопрос об их рациональном упорядочении.

Как международный [2], так и отечественный [1] стандарты определяют три уровня характеристик. Первые два уровня представляют структурированный пользовательский взгляд на программу, которая рассматривается как готовый продукт, и поэтому не затрагиваются показатели, характеризующие затраты/сроки первоначальной разработки. На практике же, как правило, их приходится учитывать при выработке общего баланса требований.

К сожалению, предлагаемая стандартами структура явно недостаточна. Переход на третий уровень показателей (метрик) связан с существенными проблемами. Метрик очень много, и они обладают как положительной, так и отрицательной не фиксируемой стандартами корреляцией как между собой так и со свойствами верхних уровней.

В целом ни один из применяемых или даже пропагандируемых к применению показателей, не может служить надежной базой для оценки программы. Рассмотрим два наиболее характерных примера: показатель надежности – наработка на отказ и показатель «сложности» – длина программы. Первый относится к пользовательским характеристикам и может быть измерен при относительной готовности программы в процессе ее функционирования. Второй является техническим и характеризует взгляд разработчика.

Наработка на отказ – среднее время между появлением угроз, нарушающих безопасность [6] заменяет трудно измеримую оценку ущерба, наносимую соответствующими угрозами. Подход к измерению этой характеристики был заимствован из области оценки качества технических средств. Для большинства современных программных средств его информативность, к сожалению невелика. Например пользователь диалоговой программы привык пользоваться меню, указывая кнопки с помощью клавиатуры, а его коллеге удобнее правая кнопка «мыши». У первого программа работает стабильно, у второго нередки аварийные ситуации. Дефект программы заключается в том, что во всплывающем при нажатии кнопки «мыши» меню, при определенных обстоятельствах не отключена одна строка, случайное попадание на которую, вызывает отказ.

Или другой пример. Два программиста, разрабатывающие два похожих модуля пользуются одним новым компилятором. У первого проблем нет, у второго случаются. По-видимому, стиль программирования у второго программиста таков, что на нем всплыли дефекты компилятора.

В современных программах количество функций и возможных последовательностей их использования столь велико, что добиться сколько-нибудь однородного и стационарного потока входных воздействий не только при тестировании, но и даже в процессе эксплуатации фактически невозможно. А при его отсутствии статистическая представительность среднего времени между отказами невелика.

Чрезвычайно порочной необходимо признать процветающую до сегодняшнего дня практику оценки программы по числу строк (пусть не пустых и без комментариев) [7]. При сопоставлении двух программ, реализующих одну прикладную задачу в равной и достаточной степени проверенных, если одна много короче, то предпочтение нужно отдать ей. Почти наверняка она создавалась более квалифицированным персоналом, в ней меньше скрытых ошибок и ее, скорее всего, легче модифицировать. Стоить она также должна дороже. Хотя, конечно времени на отладку и модификацию длинной программы уйдет больше.

Длина программы может быть использована в качестве вспомогательной, дополнительной метрики, которая информативна для сравнения программ лишь при условии равной квалификации разработчиков, единого стиля разработки и общего окружения.

Для разработчика наиболее информативны непосредственные оценки принимаемых решений, причем бесполезно пытаться построить иерархию свойств. Характеристики со стороны пользователя и со стороны разработчика необходимо рассматривать отдельно, определяя для каждой конкретной пары соответствующую зависимость.