ГОСТР 53195.5—2010
ния к требуемым характеристикам, например надежность или сложность. Для оценки большинства средств
требуются программные инструменты. Некоторые применяющиеся метрики перечислены ниже:
- теоретическая сложность графа. Эта метрика может быть применена на раннем этапе жизненного цикла
для оценки компромиссных решений и основана на величине сложности графа управления программы, пред
ставленной ее цикломатическим числом;
- число способов активизации некоторых программных модулей (доступность) — чем больше программных
модулей может быть доступно, тем должна быть ббльшая вероятность их отладки;
- теория метрик Холстеда. При помощи этих средств вычисляют длину программы путем подсчета числа
операторов и операндов; данная метрика дает меру сложности и размеры, которые формируют основу для
сравнений при оценке будущих разрабатываемых ресурсов;
- число входов и выходов на программный модуль. Сведение к минимуму числа точек входов/выходов явля
ется ключевой особенностью методов структурного проектирования и программирования.
Более подробное описание данного метода/средства приведено в [211—213].
В.5.15Инспекция программ
П р и м е ч а н и е — Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблица Б.8).
Цель: обнаружение ошибок на всех этапах разработки программ.
Описание: формальный аудит гарантирующих качество документов, направленный на отыскание ошибок.
Процедура инспекции (проверки) состоит из пяти этапов: планирование, подготовка, исследование, анализ и учет.
Каждый из этих этапов имеет свои конкретные цели. Должна быть проанализирована вся разработка системы
(спецификация, проектирование, кодирование и тестирование).
Более подробное описание данного метода/средсгва приведено в [214. 215].
В.5.16 Сквозной контроль/анализ проекта
П р и м е ч а н и е — Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблица Б.8).
Цель: обнаружение ошибок в различных частях проекта с высокой оперативностью и экономичностью.
Описание: в МЭК опубликовано руководство по общему представлению формального анализа проектов,
которое содержит общее описание представления формального анализа проектов, его цели, подробные сведе
ния о различных типах анализа проекта, состав группы анализа проекта и относящиеся к ним обязанности и
ответственности. Это руководство содержит также общие руководящие материалы по планированию и выполне
нию формального анализа проектов, а также конкретные подробные сведения, относящиеся к роли независи
мых специалистов в группе по анализу проекта. Например, помимо прочего, в функции специалистов входят
надежность, поддержка обслуживания и доступность.
В упомянутом выше руководстве МЭК рекомендуется, чтобы формальный анализ проекта проводился для
всех новых изделий/процессов, применений и при пересмотрах существующих изделий и производственных про
цессов. влияющих на функции, производительность, безопасность, надежность, способность анализировать об
служивание. доступность, способность к экономичности и другие характеристики, влияющие на конечные изде-
лия/процессы. пользователей или наблюдателей.
Закодированный сквозной контроль состоит из группы сквозного контроля, выбирающей небольшой набор
изложенных на бумаге тестовых примеров, представляющих наборы входных данных и соответствующие предпо
лагаемые выходы для программы. После этого тестовые данные вручную трассируются через логику программы.
Более подробное описание данного метода/средсгва приведено в [200. 216. 217].
В.5.17 Макетирование/анимация
П р и м е ч а н и е — Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблицы Б.З и Б.5).
Цель, проверка возможности реализации системы при наличии заданных ограничений. Увязка интерпре
тации разработчика спецификации системы с ее потребителем для исключения непонимания между ними.
Описание: выделяются подмножество системных функций, ограничения и требования к рабочим парамет
рам. С помощью инструментов высокого уровня строится макет. На данном этапе не требуется рассмотрение
ограничений (например, используемый компьютер, язык реализации, обьем программ, обслуживание, надеж
ность и доступность). Макет оценивается по критериям потребителя, и системные требования могут быть моди
фицированы в свете этой оценки.
Более подробное описание данного метода/средства приведено в [218—220].
В.5.18 Моделирование процесса
П р и м е ч а н и е — Ссылка на данный метод/средство приведена в ГОСТ Р 53195.4 (таблица Б.З).
Цель: тестирование функции программной системы вместе с ее интерфейсами во внешнем окружении, не
допуская модификации реального окружения.
Описание: создание системы только для целей тестирования, имитирующей поведение управляемого обо
рудования (УО).
Имитация может осуществляться только программным обеспечением либо сочетанием ПО и АС. Она
должна:
- обеспечить входы, эквивалентные входам, которые могут быть при фактической установке УО.
61