ГОСТ Р 53798 — 2010
8.5.1.3 Настройка в большинстве случаев определяется как действия по разработке программного
обеспечения, которые включают в себя написание процедурно программируемого кода в
Л
ИМС на языке,
запатентованном и поставленном разработчиком, или надругом языке третьей стороны. Кроме того, на
стройка может изменить способ, с помощью которого функции базовой системы были предназначены
для использования или добавления новых функций, не представленных в основном продукте продавца.
Настройки могут быть разработаныдля улучшения эффективности или качества путем автоматизации эта
пов или действий, обычно выполняемых пользователями в системе. Обеспечение динамического обнов
ления заданных пределов в базеданных
Л
ИМС путем интеграции с отдельной системой клиентской базы
данных позволяет определить, является ли предназначенный заказчику произведенный продукт приме
ром настройки.
8.5.1.4 Обычно конфигурирование может бытьдостигнуто быстро и эффективно с помощью админи
стративных предоставленных функций. Принятие решения о том. как лучше всего конфигурировать функ
циональные возможности, занимает от нескольких дней до нескольких недель работы с использованием
различных вариантов и оценкой их воздействия на другие функции системы. Настройка может занять от
несколькихдней до нескольких месяцев для создания проекта, кода и испытаний, зависящих от сложнос ти
затребованныхфункциональных возможностей.
8.5.1.5 Существует много методологий для конфигурирования и конструирования системы. Докумен
ты по ГОСТР ИСО/МЭК12207 могут адекватно объяснить различные принципы разработки программного
обеспечения. Кним относятся как варианты типа традиционного «водопада», так и поэтапные
эволюцион ные методологии.
8.5.1.6 При конфигурировании и разработке системы принцип «водопада» может использоваться в
том случае, когда проект системы полностью сконструирован и утвержден перед осуществлением дей
ствий по построению системы. Быстрое создание прототипа, характеризующееся итерациями проекта, кон
струкции и испытательныхдействий, доказало эффективную методологию и часто используется сегодня.
Как правило, планируется достижение создания прототипа в течение трех — пяти итераций, где для
каждой итерации требуется приблизительно отдвух недельдо двух месяцев или более.
8.5.1.7 При создании прототипа разрабатывается первоначальный проект, который должен использо
ваться для того, чтобы провести конструирование прототипа системы. Путем итераций проекта, конст
рукции и испытаний в спецификации проекта системы разрабатываются и документируются дополнитель
ные детали требований и проекта системы.Детализированные конфигурационные параметры и специфика
ции проекта модернизируются одновременно, но формально не могут быть утверждены до завершения
заключительной итерации.
8.5.1.8 Требования к конструированию системы
Л
ИМС разделяются на логические группыдля фор
мирования элементов конструкции или прототипа. Требования, изложенные вспецификациях, должны со
ответствовать конфигурации
Л
ИМС или. вслучае необходимости, пользовательскому коду. Модули пользо
вательского кода должны конструироваться с использованием стандартов качества. Этот процесс вклю
чает в себя установление общих стандартов для пояснения кода, определяемых переменных, любых
имен для переменных или модулей, индентироваиие и т. д. Стандарты должны устанавливаться и исполь
зоваться всей группой разработчиков. Руководитель технической команды или старший разработчикдол
жен рассмотреть код для того, чтобы четко следовать этим стандартам. Стандарты должны охватывать
следующие темы: модули должны иметь описательные рубрики (заголовки) программы, включая такую
информацию, какдата пересмотра (если предусмотрено, то номер конструкции), имя программиста, назва
ние системы (число пересмотров, если предусмотрено), название модуля, задачи модуля, любые необхо
димые синтаксисы для внешних ссылок (ввод или вывод) к модулю/из модуля и любые уникальные реше
ния для интеграции. История изменений (названия,даты, краткие описания изменений)должна быть вклю
чена в «шапку» (колонтитул) программы. Код должен быть структурирован и включать в себя достаточно
комментариев, чтобы позволитьдругим программистам легко понять работу с кодом.
8.5.1.9 В конце каждой итерации конструкции перед просмотром прототипа код и развертывание теку
щих возможностей опытного образца «замораживаются». Функциональные возможности прототипа долж
ны быть продемонстрированы пользователям.
Л
юбое изменение/исправление запросов должно быть до
кументировано с использованием процесса контроля изменения, где запросы анализируются и представ
ляются группе разработчиковдля включения в заключительную конструкцию системы.
8.5.1.10 Разработка системы и настроек в любом случае может занять от 25 дней до нескольких
месяцев или более, включая время на создание прототипа.
48