ГОСТ Р МЭК 62279—2016
D.37 Метрики
Цель. Прогнозирование характеристик программ, исходя из свойств самих программ, а не из информации об
их разработке или тестовой истории.
Описание. Данные модели оценивают некоторые структурные свойства программного обеспечения и связы
вают их с требуемой характеристикой, такой как сложность. Для оценки большинства мер требуются программные
инструментальные средства.
Некоторые применяющиеся метрики перечислены ниже:
- графо-теоретическая сложность: эта мера мажет быть применена на ранних стадиях жизненного цикла,
чтобы оценить компромиссные решения, и основывается на величине сложности графа управления программы,
представленной ее значением цикломатической сложности:
- число способов активизации определенного компонента (доступность): чем больше к компоненту выполня
ется обращений, тем более качественно он должен быть отлажен;
- меры сложности Холстеда: эта мера вычисляет длину программы, считая число операторов и операндов.
Она обеспечивает меру сложности и оценивает ресурсы, необходимые для разработки:
- число входов и выходов на компонент: уменьшение числа точек входа/выхода является ключевой характе
ристикой методов структурного проектирования и программирования.
D.38 Модульный подход
Цель. Декомпозиция программного обеспечения на небольшие законченные модули с целью сокращения
сложности системы.
Описание. Модульный подход или модульность включает в себя несколько различных правил для этапов
проектирования, кодирования и сопровождения проекта программного обеспечения. Эти правила меняются в со
ответствии с реализуемым методом проектирования. Большинство методов подчиняются следующим правилам:
- программный модуль (компонент) должен выполнять одну четко сформулированную задачу или функцию;
- связи между программными модулями (компонентами) должны быть ограничены и строго определены,
уровень связности каждого программного модуля должен быть высоким:
- совокупности подпрограмм должны строиться так. чтобы обеспечивать несколько уровней программных
модулей (компонент).
- размеры подпрограмм следует ограничить некоторыми конкретными значениями, обычно от двух до четы
рех размеров экрана;
- подпрограммы должны иметь только один вход и один выход;
- программные модули (компоненты) должны взаимодействовать с другими программными модулями (ком
понентами) через свои интерфейсы. Если используются глобальные или общие переменные, то они должны быть
хорошо структурированы; доступ к ним должен находиться под контролем, и их использование в каждом конкрет
ном случае должно быть обосновано:
- все интерфейсы программных модулей (компонент) должны быть полностью документально оформлены;
- все интерфейсы программных модулей (компонент) должны содержать только минимальное число пара
метров. необходимых для их функционирования;
- обычно наиболее подходящее ограничение для числа параметров равно 5.
D.39 Моделирование реализации
Цель. Гарантировать, что рабочая производительность системы достаточна для удовлетворения специфи
цированных требований.
Описание. Спецификация требований включает в себя требования к пропускной способности и реакции кон
кретных функций, возможно, объединенных с ограничениями на использование общих системных ресурсов. Пред
ложенный проект системы сравнивается с установленными требованиями путем:
- создания модели процессов системы и их взаимодействий;
- определения используемых каждым процессом ресурсов (время процессора, полоса пропускания канала
связи, объем памяти и т. п.);
- определения распределения запросов, выдаваемых системе при средних и наихудших условиях;
- вычисления для средних и наихудших случаев значений величин пропускной способности и времени от
вета для конкретных функций системы.
Для простых систем может оказаться достаточным аналитическое решение, тогда как для более сложных
систем более подходящим для получения точных результатов является создание модели системы.
Перед детальным моделированием может быть использована более простая проверка «бюджета ресур
сов». которая суммирует требования к ресурсам всех процессов. Если сумма этих требований к системе превы
шает возможности спроектированной системы, проект считается нереализуемым. Даже в случав, если проект
проходит эту простую проверку, моделирование выполнения может показать, что слишком большие времена за
держки и откликов происходят из-за недостатка ресурсов. Для исключения такой ситуации инженеры часто про
ектируют системы, использующие только часть (например 50 %) общих ресурсов для уменьшения вероятности
нехватки ресурсов.
83