- Оценка затратной надежности кортежа действующей программы
- Оценка ожидаемых затрат при обновлении программы
- Учет экономического риска от ошибок программы
С ростом вычислительных ресурсов программирование из тонкого индивидуального искусства превращается в одну из индустриальных профессий. Отошли в прошлое виртуозные приемы экономии памяти и времени (три числа в одной ячейке, один индекс для всех циклов, использование побочных эффектов команд и т. п.). На смену этому пришел системный инструментарий. Современный программист иной раз за полчаса решает задачу, которая двадцать лет назад требовала годовой разработки. За рост производительности, как всегда, приходится платить повышенным расходом ресурсов. Трансляторы применяют избыточные стандартные решения, не учитывая специфики задачи. Однако имеется один аспект разработки программ, в котором по-прежнему решающую роль играет индивидуальный творческий труд. Это установление адекватности программы и исходной содержательной цели программирования.
Специфика понятия отказа программы
Многочисленные попытки определить понятие ошибки в программе как математическое привели к противоположному результату: стало понятно, что одна и та же программа может устроить одного и не устроить другого потребителя. Иными словам,и, программа оказалась не логическим, а физическим объектом, и вместо понятий правильно/неправильно к ней надо применять категории приемлемо/неприемлемо, имея в виду конкретного потребителя.
Критерий приемлемости может зависеть от совершенно нематематических факторов: например, из-за неудачного монитора потребитель отдаст преимущество программе, требующей меньшего внимания на экране (при прочих равных показателях); медленный дисковод может сделать перевес в сторону избыточной загрузки оперативной памяти и т. д. Однако такие предпочтения носят неустойчивый характер и меняются при обновлении оборудования. Более устойчивы требования, связанные с организационно-технологическими условиями эксплуатации программы, такими, как способы получения исходных данных, организация их ввода в машину, контроль их правильности, способы использования выхода программы. Обычно эти требования заранее известны неточно и в процессе эксплуатации уточняются. Бывают случаи отказа от закупленного программного обеспечения после первых попыток приспособиться к его особенностям. Даже в программировании технических и физических задач критерий приемлемости субъективен: достаточно вспомнить проблему необходимой точности вычислений, например, при расчете разностных схем.
Столь же субъективно понятие отказа программы. По сути оно означает, что использование выхода программы дало не те результаты, которые ожидались потребителем. Иногда можно предъявить разработчику определенные претензии. Если в наличии описание того, как программа должна работать, и оно явно нарушено, то можно говорить об объективно зафиксированной ошибке. В других случаях явной ошибки нет, но действуют непредусмотренные факторы, например при неявных автоматических округлениях в бухгалтерских расчетах. Если понятие ошибки в программе вполне аналогично понятию ошибки в конструкции физического устройства, то понятие программного сбоя или отказа имеет существенное отличие от технических аналогов. Отказ аппаратуры означает переход ее в новое, нерабочее состояние, которого нет у исправного прибора, а сбой аппаратуры - нежелательное изменение состояния прибора, порождающее нестабильность функционирования. Отказ программы ровным счетом ничего в ней не меняет и означает только ее неожиданное поведение, с самого начала в нее заложенное, но не предусмотренное при данном режиме эксплуатации. Говоря о сбое программы, имеем в виду, что программа может выдавать разные результаты при повторных запусках из одних и тех же исходных данных. Это может быть связано с особенностями аппаратуры или операционной системы, с которой программа взаимодействует, но не с изменением самой программы. Поэтому для программы отсутствует понятие ремонта в обычном смысле этого слова. Отказ по существу означает первое столкновение с ошибкой, а сбой - нестабильно проявляющуюся ошибку.
Такое положение вещей делает совершенно бессмысленным для программирования понятия наработки на отказ или вероятности отказа за определенное время, на которых построена вся теория надежности в технике. Ошибка в программе либо есть, либо нет, и при том для разных пользователей - по-разному. С другой стороны, у каждого пользователя складывается свое представление о надежности данного программного продукта, основанное на статистике ошибок в реализуемом режиме эксплуатации. Сложный программный продукт обычно невозможно модифицировать силами пользователя, а в случае внесения модификаций трудно предсказать, как поведет себя программа в уже опробованных ранее ситуациях. По сути, каждое исправление программы уничтожает весь накопленный опыт ее эксплуатации. Поэтому на практике используется внесение корректировок в руководство пользователя, которые либо запрещают использование программы в каких-то случаях, либо указывают дополнительные операции при обращении к программе, позволяющие обойти ошибку. Последний вариант является основным, поскольку наличие запретов на использование программы в практически нужных случаях обычно влечет отказ от программы в целом. Число и характер таких исправлений в руководстве пользователя субъективно говорит о ее надежности.
При использовании откорректированного руководства потери связаны уже не с появлением ошибок, а с дополнительным трудом по выполнению новых операций, позволяющих эти ошибки обойти. Это выражается в лишних затратах, связанных с замедлением работы или использованием дополнительного оборудования и т. п. Кроме того, требуется оплатить работу системного аналитика по обнаружению причин ошибки и выработки средств ее обхода (тех самых корректировок руководств). Эта работа проводится при каждом отказе или сбое, который проявился впервые. Таким образом, экономические показатели эксплуатации программного обеспечения естественным образом характеризуют его надежность в интуитивном смысле. При этом программу надо рассматривать совместно с руководством по эксплуатации (далее - инструкцией) и режимом эксплуатации, характеризующим частоту появления различных исходных данных, способы их получения, а также способы использования результатов счета. В конечном счете именно режим эксплуатации дает возможность определить приемлемость результата. Надо учесть также среду реализации программы, включающую трансляторы, ОС, такие характеристики компьютера как быстродействие, разрядность, скорость передачи данных и т. п. Изменение среды может изменить и оценку (ценность) полученного результата, например при повышении точности расчетов или сокращении времени решения задачи. Такой набор характеристик эксплуатации программы будем называть "кортежем программы", и понятие надежности относится именно к нему, а не к самой программе.
Математический анализ надежности будет построен на оценке избыточных затрат, возникающих при работе по откорректированной инструкции. Это позволит дать количественную оценку надежности кортежа программы и выработать методику принятия решения о замене программы на новую, с учетом риска обнаружения новых ошибок.
Как можно измерять надежность программы
Поскольку имеется несколько подходов к количественному измерению надежности ([1-4]), назрела необходимость развести их терминологически. Во-первых, можно рассчитать величину ЭКОНОМИЧЕСКОГО РИСКА, вызванного возможностью ошибок в программе. По сути, этот риск определяется разделами инструкции, устанавливающими использование результатов программы при данном режиме эксплуатации, и вероятностями ошибок, влияющими на каждый тип использования. Такой риск может быть основан только на прогнозе возможных ошибок, что значительно снижает ценность подобного подхода. В то же время разумно оценить РЕАЛЬНЫЕ ПОТЕРИ за период эксплуатации, вызванные ошибками. Если определить тенденцию изменения средних реальных потерь за конкретный период (например, за месяц или год), можно прогнозировать экономический риск на будущее.
Часто говорят о СТАТИСТИЧЕСКОЙ надежности программы, измеряемой как дополнительная вероятность обнаружения новой ошибки, не учтенной в предыдущих коррекциях, при очередном обращении к программе. Простейшей оценкой статистической надежности является величина
P(n) = 1 - f(n)/n +- e(d,n)
или
P(n) > 1 - f(n)/n - e(d,n)
где п - количество выполненных обращений к программе;
f(n) - число обнаруженных ошибок;
e(d,n) - доверительный интервал хи-квадрат [5] оценки вероятности ошибки f(n)/n при заданном уровне значимости.
В качестве оценки дисперсии d с гарантией можно пользоваться максимально возможной дисперсией (= 1/4) двоичной случайной величины (в соответствии с двумя возможными исходами обращения к кортежу: удача = 0, ошибка = 1).
Это соответствует подходу к программе как к черному ящику, иногда выдающему ошибки. Недостатком такого подхода является неявно использованная модель "урны с возвратом шаров", не учитывающая корректировки кортежа после обнаружения каждой новой ошибки. Ситуация исправляется, если учитывать только новые ошибки, не компенсируемые ранее сделанными корректировками инструкции.
Более сложной, но иногда оправданной оценкой статистической надежности может служить байесовская оценка вероятности верного срабатывания кортежа при задании некоторой экспертной оценки априорной вероятности ошибки и использовании статистической выборки отказов при обращениях к программе. Этот метод хорош, если есть серьезные основания для прогноза частоты ошибок в исходном кортеже. Не останавливаясь на конкретных формулах, отметим, что теоретически использование обеих оценок не вполне корректно, так как процесс, включающий коррекцию кортежа по каждой ошибке, не стационарен, а это предполагается в обосновании методов оценки вероятности.
Надо отметить также не вполне конструктивный, но логически безупречный подход к определению КОМБИНАТОРНОЙ надежности программы, определяемой как отношение числа вариантов исходных данных, на которых программа срабатывает верно, к общему числу вариантов исходных данных. В условиях динамической корректировки кортежа эта надежность постоянно растет. Однако оценить ее можно только статистически, используя формулы, приведенные выше, для "препарированной" статистической выборки результатов обращений к программе, из которой выброшены повторные варианты исходных данных. В общем случае возникает та же трудность с потерей стационарности процесса при корректировках. Но имеется одна ситуация, где эта трудность не возникает: статистическая оценка комбинаторной надежности, полученная на основе многократного тестирования программы, работающей безошибочно на всей серии тестовых обращений. Это соответствует стадии тестирования программы в процессе отладки, когда каждая обнаруженная ошибка исправляется на уровне программы или инструкции, а потом тестирование начинается заново по полной программе. В этом случае на каждом прогоне тестов корректировок не возникает, и процесс возникновения ошибки остается стационарным. Оценка хи-квадрат тогда дает Р(n) > 1 - e(1/4,n). Более тонкая оценка может быть основана на знании внутренней структуры программы.
НЕСТАБИЛЬНОСТЬ работы программы естественно измерять числом зарегистрированных ошибок за определенный период эксплуатации, т. е. числом внесенных в инструкцию корректировок за этот срок. В период устойчивой работы оборудования количество внесенных корректировок f можно оценить численным интегралом по времени от нестабильности D(i), измеренной на последовательных интервалах времени длительности h(i)
f = D(1)h(1) + ... + D(n)h(n).
Поскольку технического износа у программы, инструкции и режима эксплуатации нет, то до наступления износа компьютера нестабильность монотонно падает за счет корректировок. По мере износа компьютера (старение технической части среды) возникают специальные корректировки для обхода машинных сбоев и поломок: нестабильность начинает расти. При нормальном режиме эксплуатации предусматривается своевременная замена оборудования, и рост нестабильности ограничен введением предосторожностей на период освоения новых приборных средств.
В данной работе предлагается особый подход к понятию надежности программы, основанный на экономической оценке эксплуатации ее кортежа. Ошибки приводят к постепенному увеличению стоимости эксплуатации за счет накопления поправок в инструкции, увеличивающих работу по подготовке и осуществлению очередного обращения к программе (ввода данных, команд или сигналов). Кроме того, в периоды высокой нестабильности добавляется стоимость работы аналитиков, выявляющих причину ошибки и разрабатывающих изменения в инструкции (коррекции). Инструкция разбита на разделы, каждый из которых используется при обращении к программе с разной частотой. Удорожание эксплуатации за счет коррекции раздела тем выше, чем чаще повторяются обращения, использующие этот раздел инструкции.
В силу сказанного, надежность программного кортежа естественно измерять отношением номинальной цены эксплуатации при выполнении исходной инструкции кортежа к реальной цене эксплуатации с учетом разработки и выполнения необходимых поправок к инструкции. Обе цены следует отнести к фактическому сроку эксплуатации.
P=[средние затраты на 1 обращение по исходной инструкции]/[средние затраты на 1 обращение с учетом коррекции]
Можно также говорить о прогнозируемой остаточной надежности кортежа, учитывающей стоимость использования внесенных коррекций, но без стоимости их разработки, и прогноз ожидания числа новых ошибок за остаточный срок эксплуатации со стоимостью их анализа. При большом сроке эксплуатации остаточная надежность обычно несколько выше текущей надежности за счет малой вероятности обнаружения новых ошибок (разумеется, до периода старения технических средств). Введенную характеристику будем называть ЗАТРАТНОЙ НАДЕЖНОСТЬЮ.
Понятие кортежа программы
Прежде всего уточним, что подразумевается под программой. Во-первых, программа, так же, как и аппаратура, не существует изолированно, всегда имеется некоторая "окружающая среда", которая влияет на ее функционирование. Роль окружающей среды для программ исполняют другие программы - например, драйверы, сетевые программы, программы пользовательского интерфейса, различные прикладные библиотеки и т.д. При изменении окружающей среды (например, замене драйвера) надежность программы может ухудшиться, и вопрос о том, где источник ошибки, в программе или в среде, может оказаться нетривиальным. Во-вторых, надежность зависит от режима эксплуатации. Любая (достаточно сложная) программа допускает очень большое число комбинаций входных данных, из которого на практике используется ограниченное подмножество, причем для разных пользователей (или групп пользователей) эти подмножества различны. При одних входных данных программа отказывает чаще, чем при других, и этот факт можно сформулировать как изменение режима эксплуатации. Режим эксплуатации характеризуется частотой обращения к программе (вызов и/или ввод данных), временем работы программы, квалификацией пользователей, статистическим распределением вероятности (частот) разных областей исходных данных, организационной схемой и реализацией процедур получения исходных данных, использования выхода программы, проверки исходных и выходных данных программы, анализа результатов работы.
Наконец, обязательный атрибут современной программы - документация. В руководствах описывается, в частности, в какой программной среде должна функционировать программа и какие комбинации входных данных недопустимы.
Таким образом, говоря о надежности, следует иметь в виду следующий кортеж: "исходный текст программы, руководства, окружение, режим эксплуатации". Надежность характеризует не саму программу, а этот кортеж.
Исправления кортежа
Среда реализации, режим эксплуатации, инструкция могут меняться без изменения программы.
а) Изменения программы считаются переходом к новому кортежу, поскольку аннулируют весь прошлый опыт эксплуатации - возникает кортеж новой программы.
б) Изменение среды сопровождается и коррекцией в инструкции в той части, где существенны специальные свойства среды реализации.
в) Изменение режима эксплуатации должно фиксироваться в протоколе эксплуатации. Есть два подхода к накопленной статистике: отдельно по каждому режиму или общая выборка.
г) Основной тип правки кортежа: внесение изменений и добавлений в инструкцию для устранения ошибок и сбоев, обходов трудностей, изменений в составе задач.
д) Пока не внесена правка в исходный текст программы (не считая оболочки, обеспечивающей связь со средой), статистика сбоев считается непрерывной для кортежа. Протокол эксплуатации считается непрерывным с регистрацией всех поправок кортежа.
е) Любое изменение в программе требует начать новый протокол для нового полученного кортежа.
ж) Протокол не входит в кортеж, а входит в "статистику эксплуатации". Кроме того, статистика включает любые расчетные характеристики, основанные на протоколе и технических данных среды эксплуатации. У разных пользователей возможны существенно различные протоколы для одинаковых кортежей. Соответственно они могут получить разные характеристики надежности этого кортежа. Тем не менее рекомендуется ориентироваться только на свой протокол, поскольку возможны незарегистрированные документально отличия в аппаратных средствах (например, степень износа различных устройств), в ОС и в режиме эксплуатации.
Обработка сбоев и ошибок
Сбои и ошибки в программе обрабатываются таким образом:
а) При обнаружении действия программы, не соответствующего ее назначению, регистрируется ошибка (в протоколе).
б) Предпочтительной является поправка кортежа путем изменения инструкции. Возможны варианты: изменения в инструкции оператора, изменения в инструкции подготовки данных (для пользователя), наложение ограничений на допустимые исходные данные, т.е. запрещение на использование программы в определенных ситуациях.
в) Если необходимая правка инструкции нежелательна, то можно попробовать менять операционную систему, трансляторы или устройства с соответствующим изменением инструкции.
г) Если реализация (б) не допустима (слишком жесткие требования в инструкции), а реализация (в) слишком дорога, то надо менять кортеж, т.е. заменять или корректировать саму программу.
д) Режим эксплуатации считается не подлежащим изменению - это технологическое требование инфраструктуры, в которой функционирует программа.
Экономические характеристики кортежа
Роль технических характеристик промышленных изделий производственного назначения заключается прежде всего в том, что они позволяют, по крайней мере в принципе, рассчитывать экономические выгоды от ирименения того или иного изделия. Надежность в этом смысле не является исключением. Зная характеристики надежности, можно попытаться оценить убытки, связанные с отказами, и сопоставить их с выгодами от использования данного изделия.
В отношении программ ситуация осложнена тем, что общепризнанных критериев надежности до сих пор не существует. Вместе с тем очевидно, что по мере эксплуатации программы в ней, с одной стороны, выявляются ошибки, а с другой стороны, накапливается статистика правильных срабатываний (положительный эксплуатационный опыт). С практической точки зрения важно уметь рассчитывать момент времени, когда целесообразно переходить на новую версию программы. Здесь следует еще раз отметить, что при переходе на новую версию вся накопленная эксплуатационная статистика, включая проведенные коррекции кортежа, аннулируется. В данной работе предлагается методика, позволяющая определять оптимальный момент перехода на новую версию программы. Методика базируется на сравнении эксплуатационных затрат, рассчитываемых на основании экспертных и статистических оценок. Потери, вызванные обнаруженными или ожидаемыми ошибками кортежа, определяют коэффициент затратной надежности, описанный выше, принимающий значение 1 при безошибочной работе и снижающийся к нулю при росте затрат на отработку ошибочных ситуаций.
Цена эксплуатации программы складывается из затрат на подготовку и ввод данных и из работы аналитиков по обработке ошибок. Появление дополнений к инструкции усложняет, а значит, и удорожает обращение к программе (т.е. подготовку и ввод исходных данных). Эти затраты накапливаются на протяжении всего срока эксплуатации кортежа, ограниченного либо моральным старением программы, либо введением в эксплуатацию нового кортежа, заменяющего данный с точки зрения его инфраструктуры.
Моральное старение кортежа может определяться несколькими факторами:
а) появление новых задач, не предусмотренных в программе;
б) окончание работ, для которых создана программа;
в) появление новых стандартов входной и выходной информации, не совместимых с программой;
г) изменение требований к быстродействию, выше возможностей программы;
д) введение новой операционной системы или оболочки, в которой программа не работоспособна;
е) изменение базового языка программирования, на который ориентирована инфраструктура, где эксплатируется кортеж. Общие затраты на эксплуатацию программы следует исчислять на прогнозируемый срок морального старения.
Если известен срок морального старения программы, то замена ее на новую эффективна только в том случае, когда общая стоимость эксплуатации нового кортежа (с учетом априорной вероятности ошибок в новой программе) за остаточный срок меньше стоимости эксплуатации за то же время откорректированного старого кортежа. Кроме того, новая программа может выполнять дополнительные функции, которые требовали большой "ручной" работы при использовании старой программы. Это дает дополнительную экономию от внедрения нового кортежа. Надо учесть также разовые затраты на обучение пользователей и аналитиков работе с новыми инструкциями. Таким образом, условие эффективности замены кортежа выражается неравенством:
[стоимость остаточной эксплуатацвпл старого кортежа] > > [стоимость остаточной эксплуатации нового кортежа] + + [разовые затраты на изучение персоналом новсй инструкции] - - [остаточная экономия от использования новых функций ]
Конкретное использование этого принципа требует математической модели, позволяющей эффективно рассчитать компоненты неравенства.
Проанализируем затратную оценку надежности кортежа программы. Прежде чем перейти к расчетным формулам, укажем на характерные особенности динамики введенных характеристик по времени эксплуатации кортежа. Следует различать пять периодов эксплуатации:
(1) начальное освоение кортежа, характеризующееся относительно большой и неубывающей частотой обнаружения ошибок (несоответствий описания программы и ее фактической работы);
(2) отладка кортежа, характеризующаяся постепенным убыванием частоты ошибок за счет корректировок разделов инструкции;
(3) нормальная эксплуатация с низкой или нулевой частотой новых ошибок;
(4) начальный износ оборудования, когда возникают эпизодические сбои и отказы, для избегания или компенсации которых приходится вводить дополнительные корректировки в инструкцию;
(5) отказ оборудования, когда для продолжения работы приходится менять инструкцию, устраняя использование отказавших устройств (например, менять способ ввода информации в программу).
Математическая модель и расчет характеристик надежиости
Уточним модель эксплуатации программы. Обращение к программе - этолибозапуск программы с исходнымиданными, либо вводданных в работающую программу. Ввод данных осуществляется либо пользователем в диалоге, либо от внешних устройств автоматически. В дальнейшем для простоты описания будем рассматривать ручной ввод. Предполагается, что известна средняя частота обращения к программе м, т.е. за время эксплуатации Т (достаточно большое) произошло К=Tv обращений. Если при обращении к программе обнаружена ошибка, то она регистрируется в протоколе (журнал эксплуатации), и в работу вступает аналитик. Его задача - выяснить причину ошибки и, если она заложена в программу, найти такое изменение инструкции ввода, при котором программа даст верный результат (т.е. нужно указать пользователю действия, позволяющие обойти ошибку. При автоматическом вводе это может означать изменение предмашинной обработки данных). Если такое изменение инструкции невозможно, то в инструкцию вводится признак данных, для которых обращение кданной программезапрещено и требуетсядрутое средство обработки. В тех случаях, когда изменения слишком значительны, эксплуатация программы может стать невозможной. Но в данной работе рассматривается случай, когда программа содержит "приемлемые" ошибки, которые можно исправить коррекцией инструкции. Тогда за время эксплуатации Т накапливается f=f(T) изменений в инструкциях.
Оценка затратной надежности кортежа действующей программы
Введем экспертные оценки следующих параметров, выражающих цену обращения к программе:
Со - цена обращения при использовании нескорректированной инструкции;
Cu - цена дополнительной работы по выполнению скорректированной инструкции;
Са - цена работы аналитика при разборе ошибки и выработке рекомендаций по корректировке инструкции.
Все эти параметры носят усредненный характер: при разных обращениях к программе для разных разделов инструкции и разных ошибок они могут значительно варьироваться, но нас будет интересовать усредненная по большому числу обращений оценка. Потребуется также усредненная характеристика повторяемости разделов инструкции при обращениях: будем считать, что в среднем один раздел инструкции используется через А обращений. Тогда за время эксплуатации Т количество повторений каждой инструкции равняется:
m = Tv/A (1)
Для параметра "А" хорошей оценкой и интерпретацией является количество разделов инструкции, используемых в характерных для данного режима эксплуатации ситуациях: в среднем именно таковы интервалы между повторными использованиями одного раздела. Поэтому работа аналитика может изменить этот параметр (увеличить) за счет подразбиения каких-то разделов при внесении корректировок в инструкцию. Для оценки "А" надо пользоваться текущим состоянием инструкции, без учета тех ее разделов, которые используются только в исключительных ситуациях (аварии, экспериментальные изменения технологии, редкие производственные ситуации и т.п.) или вообще не используются.
Средние прогнозируемые затраты на одно будущее обращение к программе по результатам времени эксплуатации Т можно оценить сверху
q <= Со +(m*f/K + 1/K)Cu + (1/K)Ca (2)
Член (1/К) возникает как учет вероятности появления новых ошибок в еще не опробованной области исходных данных. При достаточно большом К можно считать, что попадание в новую область данных происходит с вероятностью, не превосходящей 1/К, а тогда и вероятность новой ошибки не выше. Аналогично, средние по времени затраты на эксплуатацию программы в будущем составят:
Q <= v(Со + (mf/K + 1/K)Cu + (1/K)Ca) (3)
Затраты за дополнительное время эксплуатации То составят:
С'(То | Т) = Q*To =< СоКо + (Ko f/A + Ko/K)Cu ++ (Ko/K)Ca (4)
где Ко To*v - ожидаемое количество обращений к программе за время То. Общие затраты за предыдущее время эксплуатации можно оценить как
С(Т)<= Со K + mf*Cu + fCa=Со K + (K/A) fCu + fCa (5)
Два последних члена оценивают затраты на корректировку кортежа программы, т.е. на ее освоение. В соответствии с описанной выше интерпретацией фактическая затратная надежность оценивается формулой
Рфак >= Со / ( Со + f Cu/A + f Ca/K ) (6)
Оценка прогнозируемой затратной надежности
Рож >= Со / ( Со + ( f+1/K )Cu/A + Ca/K ) (7)
Оценка ожидаемых затрат при обновлении программы
Для оценки затрат при введении нового кортежа (т.е. при замене или изменении текста программы) следует исходить из какой-то априорной оценки ожидаемого количества ошибок и из оценки затрат на освоение новой инструкции и выигрыша от использования новых функций программы, которых не было в предыдущем варианте.
Опять введем экспертные оценки:
f - ожидаемое количество ошибок в новой программе,
Cn - затраты на обучение персонала новой инструкции,
Cv- выигрыш (средний на одно обращение) от новых функций,
To - ожидаемое остаточное время эксплуатации комплекса задач, решаемых кортежем (с учетом морального старения системы, в которой работает кортеж).
Тогда оценка затрат при введении нового кортежа:
C"(To) = Co*Ko + (Ko*f'/A)Cu + f'Ca + Cn - Cv*Ko (8)
Условие целесообразности обновления программного обеспечения определяется неравенством
С' (To|T) > C"(TO) (9)
Особый случай, когда экспертная оценка f' отсутствует. Тогда приходится оценивать ожидаемое количество ошибок в новой программе по протоколу действующего кортежа: f' = f, Формулы (4)(8)(9) тогда дают условие целесообразности замены
CuKo/K > (f - Ko/K)Ca + Cn - Cv Ко (10)
С точки зрения практики желательно иметь регулярный метод выработки необходимых экспертных оценок. Приведем один из возможных способов, основанном на сведении затрат к заработной плате пользователей и аналитиков кортежа. Введем обозначения:
Za - зарплата аналитика;
Zu - зарплата пользователя;
Tz - периодичность выплаты зарплаты;
Ма - количество аналитиков кортежа;
Mu - количество активных пользователей кортежа;
So - среднее время обращения по исходной инструкции;
Su - среднее добавочное время обращения по коррекции;
Sa - среднее время анализа ошибки и корректировки инструкции;
Sna - время освоения нового кортежа аналитиком;
Snu - время освоения новой инструкции пользователем;,
Тс - время выполнения новых функций средствами старого кортежа;
Tn - время обращения к новой функции в новом кортеже;
Vn - доля обращения к новой функции среди всех обращений.
Тогда можно рассчитать необходимые экспертные оценки по следующим формулам:
Со = Zu So / Tz , (11) Cu = Zu Su / Tz , (12) Са = Za Sa / Tz , (13) Cn = (Ма Za Sna + Mu Zu Snu ) / Tz , (14) Cv = Vn ( Тс - Tn ) Zu / Tz . (15)
В таблице 1 приведена полная расчетная схема по приведенным выше формулам.
Таблица 1.
Расчетная схема эатратной надежности и целесообразности замены кортежа.
| ИСХОДНЫЕ ДАННЫЕ
f - число обнаруженных ошибок в кортеже; ДАННЫЕ ДЛЯ РАСЧЕТА ЦЕНОВЫХ ПАРАМЕТРОВ Za - зарплата аналитика; РАСЧЕТ ЦЕНОВЫХ ПАРАМЕТРОВ Co = Zu*So/Tz - цена обращения; РАСЧЕТ ЗАТРАТНОЙ НАДЕЖНОСТИ ПРОВЕРКА ЦЕЛЕСООБРАЗНОСТИ ЗАМЕНЫ КОРТЕЖА r=To/T$ КОНЕЦ РАСЧЕТА |
Учет экономического риска от ошибок программы
Во всех ранее проведенных расчетах не учитывались потери, которые несет пользователь, когда сталкивается с неверной работой программного обеспечения. Между тем этот риск может быть очень значительным, если на основе машинных расчетов принимаются ответственные решения или осуществляется управление дорогостоящим или технологически опасным для людей оборудованием. Оказывается, полученные формулы без труда переносятся и на этот случай. Дело в том, что потери возникают только при первом появлении ошибки, когда о ней нет предупреждения в инструкции. Таким образом, эти потери просто прибавляются к затратам на работу аналитиков, Разумеется, потребуется новая экспертная оценка для средних ожидаемых потерь от использования неверных результатов. В особо ответственных случаях следует брать завышенную оценку таких потерь.
Cs - экспертная оценка риска потерь от программной ошибки. Тогда на каждую новую ошибку приходится Ca+Cs затрат. Соответственно, получаем две оценки ожидаемых удельных затрат и риск-затратной надежности: аналогично (2), (7)
q <= Со +(m*f/K + 1/K)Cu + (1/K) (Са+Cs) (16)
Рож >= Со / ( Со + (f+1/K)*Cu/A + (Ca+Cs)/K ) (17)
Заключительные замечания
Экспертная оценка риска потерь от программной ошибки наиболее условна среди всех использованных экспертных оценок. Последствия ошибок отработки обращения к программе могут черезвычайно разниться в одном режиме эксплуатации. Стоимостное выражение этих последствий само по себе условно: они могут выражаться человеческими жертвами, экологическими катастрофами, социальными кризисами и т. п. В то же время другие ошибки могут быть всего лишь забавны. Именно поэтому формулы, содержащие оценку риска, приведены отдельно: это явно не основной тип приложений математического понятия надежности. При всей условности, эти оценки могут оказаться полезными в качестве критерия достоверности принятия решений о замене или переработке программного обеспечения: если решение проходит через критерий без учета риска, но не проходит с учетом риска, вероятно, следует привлечь дополнительные содержательные соображения для дальнейшего анализа. Учет риска всегда смещает оценку в консервативную сторону: новый программный кортеж на начальном этапе дает высокую вероятность новых ошибок, на которых и проявляется риск. Старый, уже "приработанный" кортеж с проверенной временем коррекцией инструкции таит в себе меньше неожиданностей. Но если учет риска не меняет принятого решения, значит, ему можно смело следовать.
Сравнительно простой линейный вид формул связан с использованиям усредненных по обращениям к программе оценок стоимости подготовки данных, анализа ошибки, выработки и внесения корректировок инструкции и выполнения дополнительных операций вследствие этих корректировок. Реальная стоимость, конечно, не линейна по обращениям, и приведенные оценки являются ее линейным приближением. Однако, при правильном выборе усредненных значений, за достаточно большое время будут получены близкие к истине значения суммарных затрат.
Литература
[1] Г. Майерс. Надежность программного обеспечения. М., Мир, 1980.
[2] Р. Лонгботтом. Надежность вычислительных систем. Москва, Энергоатомиздат, 1985
[3] А.А. Штрик, Л.Г. Осовецкий, И.Г. Мессих. Структурное ироектирование надежных ирограмм встроенных ЭВМ. Ленинград, Машиностроение, 1989.
[4] Р. Гласс. Руководство по надежному ирограммированию. Москва, Финансы и статистика, 1982.
[5] Д. Худсон. Статистика для физиков. Москва, Мир, 1967.
