ГОСТ Р МЭК 62279—2016
D.43 Макетирование/анимация
Цель. Проверка возможности реализации системы при наличии заданных ограничений. Увязка интерпрета
ции разработчика спецификации системы с ее потребителем для исключения непонимания между ними.
Описание. Выделяются подмножество системных функций, ограничения и требования к рабочим параме
трам. С помощью инструментов высокого уровня строится макет. На данном этапе не требуется рассматривать
ограничения, например используемый компьютер, язык реализации, объем программ, обслуживание, надежность
и доступность. Макет оценивается по критериям потребителя, и системные требования могут быть модифициро
ваны в результате этой оценки.
D.44 Блок восстановления
Цель: Повышение вероятности выполнения программой, в конечном счете, своих заданных функций.
Описание: Некоторые различные разделы программы, которые часто пишутся независимо, предназначены
для выполнения одной требуемой функции. Из таких разделов конструируется окончательная программа. Сначала
выполняется первый раздел, называемый первичным. Далее происходит тестирование его результатов. Если про
верка проходит успешно, результат принимается и передается следующим разделам программы. Если проверка
дает отрицательный результат, то все побочные эффекты первого сбрасываются и выполняется второй раздел, на
зываемый первой альтернативой. Далее следует тестирование второго раздела, которое выполняется аналогично
первому. При необходимости могут быть предусмотрены вторая, третья и т. д. альтернативы.
D.45 Ограничения на время ответа и объем памяти
Цель. Обеспечение соответствия системы требованиям к параметрам времени и памяти.
Описание. Спецификация требований к системе и программному обеспечению включает в себя требования
к памяти и времени выполнения системой конкретных функций, возможно, объединенных с ограничениями на
использование общих системных ресурсов. Выполняется анализ для определения распределения запросов при
средних и наихудших условиях. Такой анализ требует оценки используемых ресурсов и затраченного времени
каж дой функцией системы. Такие оценки могут быть получены различными способами, например сравнением с
суще ствующей системой или макетированием и дальнейшим сравнением времени реакции с критическими
системами.
D.46 Повторный запуск механизмов восстановления после ошибок
Цель. Пытаться обеспечить функциональное восстановление в условиях обнаруженного сбоя с помощью
повторного запуска механизмов восстановления.
Описание. В случав обнаружения сбоя или ошибочного условия предпринимаются попытхи восстановления
ситуации путем повторного выполнения того же кода. Восстановление с помощью повторной попытки может быть
полным в виде перезагрузки и повторного запуска процедуры, либо небольшим в виде перепланирования и повтор ного
запуска задачи после выполнения блокировки по времени программы или управляющего действия задачи. Методы
повторного запуска широко используются при коммуникационных сбоях или при восстановлении после ошибок, и
условия повторного запуска могут быть отделены флажками от ошибки протокола связи (контрольная сумма и т. д.)
или от подтверждающего ответа блокировки по времени коммуникации.
D.47 Методы «подушки безопасности»
Цель: Защита от необнаруженных на этапах спецификации и реализации ошибок в программных средствах,
которые неблагоприятно влияют на их безопасность.
Описание: Метод «подушки безопасности» представляет собой использование внешнего монитора, реали
зованного на независимом компьютере с другой спецификацией. Данный метод касается исключительно гарантии
того, чтобы главный компьютер выполнял безопасные, не обязательно корректные, действия. «Подушка безопас
ности» непрерывно контролирует главный компьютер и предотвращает вхождение системы в опасное состояние.
Кроме того, если обнаружится, что главный компьютер вошел в возможно опасное состояние, система должна воз
вратиться обратно в безопасное состояние с помощью либо «подушки безопасности», либо главного компьютера.
D.48 Управление конфигурацией программного обеспечения
Цель. Обеспечение согласованности результатов работы групп поставщиков проекта, а также изменений в
этих поставках. В общем случае управление конфигурацией применимо к разработке как аппаратных, так и про
граммных средств.
Описание. Управление конфигурацией программных средств представляет собой метод, используемый в
течение всей разработки. В сущности он требует документального оформления разработки каждой версии каждой
«значимой» ее поставки и каждой взаимосвязи между различными версиями разработки различных поставщиков.
Полученная документация позволяет проектировщику определять, как влияет на другие поставки изменение в
предыдущей поставке (особенно одного из ее элементов). В частности, системы или подсистемы могут надежно
компоноваться (конфигурироваться) из согласованных наборов версий элементов.
D.49 Строго типизированные языки программирования
Цель. Снижение вероятности ошибок путем использования языка, который компилятором обеспечивает вы
сокий уровень проверки.
85