За последнее время я ознакомился с несколькими работами, посвященными «надежности программного обеспечения».
Первую [1] я просто прочитал и включил в список литературы по надежности цифровых устройств релейной защиты [3], а на вторую [2] написал рецензию [4].
Между собой эти работы объединяет рисунок, воспроизведенный ниже, где повторены подрисуночные подписи из этих работ.
Интенсивность отказов программного обеспечения и аппаратной части системы РЗА. (Рисунок 4 из [2])
Вид функции интенсивности отказов для ПО и аппаратной части.
(Рисунок 1 из [1])
Первое, что вызывает вопрос после ознакомления с рисунком, подрисуночными подписями к нему и текстом статей – появление у ПО неизвестной до сих пор характеристики - интенсивности отказов.
В этих работах отмечено, что особенность «надежности программного обеспечения заключается в том, что оно (ПО – примеч. моё) не изнашивается, надежность ПО со временем лишь увеличивается при наличии системы исправления ошибок».
Как изменяется надежность ПО, не имеющей ошибок, в этих работах ничего не сказано.
Другими словами, такой подход требует обязательного наличия ошибок в ПО, ведь только постоянное выявление ошибок (авторы приравнивают наличие ошибки к отказу ПО, хотя в стандарте [6] ошибка рассмотрена как дефект) в течение всего жизненного цикла позволяет нарисовать график, приведенный выше.
Здесь будет нелишним задать вопрос, как будет изменяться график в том случае, когда в ПО будут выявлены все ошибки, например, в момент времени t1?
Неясно так же, как изменяется график для ПО, имеющего ошибки, не влияющие на его работу?
Кстати, термин «интенсивность» отказов ПО отсутствует в терминологических стандартах [5, 6], а требование надежности в этих документах сформулировано только для программного средства.
В стандарте [6] надежность программного средства определена как его способность сохранять заданный уровень пригодности в заданных условиях в течение заданного интервала времени.
Примечание к определению этого термина в конце концов связывает надежность программного средства с надежностью работающей совместно с ним технической системы, более того сводит к всё к качеству ПО.
В других публикациях, например, в [8] предлагают различать понятия «ошибка» и «отказ». Применительно к надежности ПО, ошибка - это погрешность или искажение кода программы, неумышленно внесенные в нее в процессе разработки, которые в ходе функционирования этой программы могут вызвать отказ или снижение эффективности функционирования.
Под отказом автор [8] предлагает понимать событие, заключающееся в нарушении работоспособности объекта, как это предусмотрено в стандарте [7] для ТС.
В публикации [9] надежность программного обеспечения так же представлена как следствие исключения ошибок проектирования, т.е. ошибок, внесенных в процессе разработки программного обеспечения.
В конечном итоге в работе [2] надежность ПО предложено определять логико-вероятностным методом, опираясь на данные о надежности логических элементов.
На мой взгляд в дальнейших рассуждениях допущена принципиальная ошибка - высказано два ошибочных предположения:
После этого автор работы [2] сводит отказ в выполнении логических операций к одну из трёх видов отказов релейной защиты.
При этом в расчетную схему «отказ в срабатывании» включена аппаратная часть, что противоречит высказанному ранее предположению о том, что надежность аппаратной части не будет оказывать влияния на все виды отказов релейной защиты.
В расчетной схеме «излишнее срабатывание», в отличие от двух других расчетных схем, исключен исполнительный элемент, что вызывает вполне естественный вопрос – как же происходит «излишнее срабатывание»?
В конце публикации [2] автор предлагает надежность ПО оценивать через показатель эффективности, вводя в этот показатель коэффициенты неготовности, связь которых с надежностью ПО никак не пояснена.
Более того, предложенный автором интегральный показатель эффективности содержит такие показатели как «средняя наработка на отказ», «поток повреждений» и другие. О связи этих показателей с надежностью ПО в статье так же нет никаких пояснений.
Кроме этого, принципиальная ошибка допущена при выделении трёх видов отказов: «ложное срабатывание» [11], «отказ в срабатывании», «излишнее срабатывание» [12].
Почему-то всё это напоминает формулы надежности [13], предлагаемые другими специалистами.
ЗАХАРОВ О.Г.
Следует также отметить, что если число ошибок рассматривать как меру надежности, то в терминологии теории вероятностей это число есть случайная величина, однако самый главный вопрос - на каком пространстве элементарных событий она задана - нигде не затрагивался.
Наконец, важно подчеркнуть, что, с точки зрения надежности, в результате исправления ошибки или любой другой коррекции получается новая программа с другим, чем до коррекции, показателем надежности.
Таким образом, число ошибок в программе характеризует скорее не программу, а ее изготовителей и используемый инструментарий
watcher
О ТЕРМИНЕ "ПРОГРАММНОЕ ИЗДЕЛИЕ"
В соответствии с ГОСТ 19.004-80 программное изделие (ПИ) определяется, как программа на носителе данных, являющаяся продуктом промышленного производства. Поскольку ПИ - это программа, то и его свойства определяются свойствами программы. Однако такое понимание ПИ нередко порождает тупиковые ситуации. Наиболее яркие примеры тому - измерение производительности труда программистов в байтах или командах и оценка надёжности ПИ методами, принятыми в теории надёжности. И в том, и в другом случае делается попытка использовать методы, не соответствующие природе объекта. Дело в том, что из признания программирования промышленной деятельностью ещё не следует, что именно программы являются изделиями. Более того, из этого не следует даже, что вообще изготавливаются какие-либо изделия (есть и добывающая промышленность). И даже если изделия действительно изготавливаются, не всякий продукт труда в производстве изделий является изделием [1]: водитель автокара не изготавливает ничего, хотя участвует в процессе изготовления. Ничего не изготавливает и программист-технолог станков с ЧПУ: его программы считаются не изделиями, технологиями, и труд его нормируется, как труд технолога. Т.е. нормы устанавливаются в соответствии со сложностью задания [2], а не с длиной использованной перфоленты. - далее см. http://www.alex.krsk.ru/198_/1986/1986_06.htm