Замечание. Фиксация методик чрезвычайно важна. В разделе 2.2.2 отмечалось, что обычной методикой определения значения атрибута завершенности «наработка на отказ при отсутствии рестарта» выбирается измерение времени нормального функционирования ИС с момента ее запуска до первого сбоя или отказа. Однако есть и другие, например – измерение всех временных интервалов нормального функционирования ИС (а не только первого) и выбор из них минимального значения или среднего значения (MTF - Mean Time between Failures - среднее время наработки на отказ). То же самое относится и к атрибуту устойчивости «наработка на отказ при наличии автоматического рестарта», а также к длительности восстановления (определение MTR - Mean Time to Repair - среднего времени восстановления, т.е. среднего времени между моментом проявления дефекта и моментом возврата системы к полноценному функционированию). Для определения коэффициента готовности ИС также могут использоваться усредненные значения: MTF/(MTF+MTR).
Результаты, полученные по разным методикам, могут существенно отличаться, что иногда приводит к весьма неприятным коллизиям между разработчиком и заказчиком – причем уже на заключительных стадиях проекта.
Более детально этот процесс определения атрибутов субхарактеристик надежности проходит в два этапа.
Первый этап – сбор данных для принятия решений.
1.1. Базовая номенклатура субхарактеристик и атрибутов надежности, стандартизированных в ISO 9126, предварительно упорядочивается по приоритетам с учетом специфики и сферы применения проекта ИС.
1.2. Определяются потребители - заказчики, подразделения – пользователи, конкретные пользователи, специалисты сопровождения и т. д. - которым необходимы определенные показатели надежности.
1.3. Потребители ранжируются по приоритетам с учетом специфики их деятельности и профессиональных интересов.
1.4. По упорядоченной номенклатуре субхарактеристик и атрибутов потребители формулируют свои требования к надежности ИС, которые должны быть формализованы в контракте, техническом задании или в спецификации требований заказчика и согласованы с разработчиками.
Замечание. По стандарту приоритет выставляется по 10-ти балльной шкале, где 10 баллов означает обязательное требование.
В п. 2 этого перечня происходит модификация базовой номенклатуры субхарактеристик с учетом специфики конкретного проекта. По требованию заказчика какие – то предусмотренные стандартом субхарактеристики и атрибуты могут быть исключены (с объяснением заказчику возможных последствий – снижение качества, неконкурентоспособность продукта, несоответствие госстандартам). Также по требованию заказчика какие – то не предусмотренные стандартом субхарактеристики и атрибуты могут быть добавлены. Часто добавляют такой атрибут завершенности как «степень покрытия тестами функций и структуры программы» (мера - %, шкала – 50 – 100).
{Можно также добавить такую субхрактеристику, как «кошерность» с одноименным атрибутом и с двоичной шкалой, но это уже будет категорийно – описательная метрика.}
В результате получается нечто вроде матрицы, элементами которой являются требования пользователя. При этом некоторые субхарактеристики и атрибуты, предусмотренные базовой номенклатурой, могут быть исключены (что очень нежелательно), а какие-то добавлены. Например, к субхарактеристике завершенности иногда добавляют атрибут «степень покрытия тестами функций ИС» с мерой «%» и шкалой «50 - 100».
Второй этап - собственно принятие решений.
2.1. С учетом ранжирований по приоритетам из матрицы выбираются конкретные элементы для каждого показателя (субхарактеристика + атрибут).
2.2. Для каждого отобранного показателя специалисты, обеспечивающие ЖЦ ИС и реализацию установленных показателей надежности, совместно с заказчиком и пользователями, устанавливают метрику, шкалу оценок и методику измерения.
2.3. Для количественных измерений, кроме номинальных значений, требуемых спецификациями, устанавливаются допуски на отклонения.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.