ГОСТРМЭК 62304—2013
так же соответствовать этим требованиям. Спецификации проекта ПО определяют, как ПО будет спроектировано и
разложено на составные части, чтобы осуществить эти требования и функциональные спецификации.
Традиционно программные требования, функциональные спецификации и спецификации проекта записа
ны как набор из одного и более документов. В настоящее время возможно рассматривать эту информацию как
элементы данных внутри общей базы данных. Каждый элемент может иметь один или более признаков, которые
определяют его цель и его соединение с другими элементами в базе данных. Этот подход допускает представ
ление и печать различных видов информации, которая лучше всего подходит для каждой группы
предполагае мых пользователей (например, продавцов, изготовителей, тестеров, аудиторов) и поддерживает
ПРОСЛЕЖИВАЕ МОСТЬ. чтобы демонстрировать соответствующее выполнение тестовых заданий проверяемым
требованиям до установленной степени. Инструменты, поддерживающие этот подход, могут быть такими же
простыми, как гипер текстовый документ, использующий гиперссылки HTML или столь же сложными, как CASE
(computer aided software engineering — разработка компьютерного ПО).
ПРОЦЕСС определения требований кСИСТЕМЕ находится вне области применения настоящего стандарта.
Однако решение о внедрении функциональных МЕДИЦИНСКИХ ИЗДЕЛИЙ с ПО обычно осуществляется по время
проектирования СИСТЕМЫ. Некоторые или все требования к СИСТЕМЕ выделяются, чтобы быть осуществлен
ными в ПО. Анализ требований к программному обеспечению заключается в анализе требований, выделяемых на
программное обеспечение ПРОЦЕССОМ определения требований к СИСТЕМЕ, и в получении полного набора
требований к ПО. отражающих выделенные требования.
Чтобы гарантировать целостность СИСТЕМЫ. ИЗГОТОВИТЕЛЬ должен обеспечить механизм для ведения
переговоров об изменениях и уточнения требований СИСТЕМЫ, чтобы исправлять непрактичность, несоответ
ствия или двусмысленности в требованиях любой родительской СИСТЕМЫ или в программных требованиях.
Процесс охвата и анализа СИСТЕМЫ и требований ПО может быть итеративным.
Настоящий стандарт не требует, чтобы ПРОЦЕССЫ были строго разделены на два слоя. На практике СИ
СТЕМНАЯ АРХИТЕКТУРА и АРХИТЕКТУРА ПО часто обрисовываются вобщих чертах одновременно, и СИСТЕМ
НЫЕ и программные требования впоследствии документируются в форме слоев.
В.5.3 Проектирование АРХИТЕКТУРЫ ПО
Этадеятельность требует, чтобы ИЗГОТОВИТЕЛЬ определил главные структурные компоненты ПО. их внеш
не видимые свойства и взаимосвязь между ними. Если поведение компонента может оказывать влияние на другие
компоненты, то такое поведение должно быть описано в АРХИТЕКТУРЕ ПО. Эго описание особенно важно для
поведения, которое может затронуть компоненты МЕДИЦИНСКОГО ИЗДЕЛИЯ, находящиеся вне ПО. АРХИТЕК
ТУРНЫЕ решения чрезвычайно важны для осуществления мер по УПРАВЛЕНИЮ РИСКАМИ. Без понимания идо
кументирования поведения компонента, которое может оказать влияние на другие компоненты, почти невозможно
доказать, что СИСТЕМА безопасна. АРХИТЕКТУРА ПО необходима, чтобы гарантировать правильное
выполнение программных требований. АРХИТЕКТУРА ПО не считается завершенной, если все требования ПО не
могут быть осуществлены определенными ЭЛЕМЕНТАМИ ПО. Поскольку проект ивыполнение ПО зависят от
АРХИТЕКТУРЫ. АРХИТЕКТУРА ВЕРИФИЦИРУЕТСЯ для завершения этойдеятельности. Как правило.
ВЕРИФИКАЦИЮ АРХИТЕК ТУРЫ выполняют путем технического ОЦЕНИВАНИЯ.
Классификация ПРОГРАММНЫХ ЭЛЕМЕНТОВ во время активности АРХИТЕКТУРЫ ПО создает основание
для последующего выбора ПО ПРОЦЕССОВ. Записи о классификации находятся всоставе ФАЙЛА МЕНЕДЖМЕН
ТА РИСКА.
Множество последующих событий может сделать классификацию недействительной. Они включают в себя,
например:
- изменения спецификации СИСТЕМЫ, программной спецификации или АРХИТЕКТУРЫ:
- обнаружения ошибок вАНАЛИЗЕ РИСКОВ, особенно непредвиденных ОПАСНОСТЕЙ и
- обнаружение неосуществимости требований, особенно мер по УПРАВЛЕНИЮ РИСКОМ.
Поэтому, во время всех видов деятельности, следующих за проектом АРХИТЕКТУРЫ ПО. классификация
ПРОГРАММНЫХ СИСТЕМ и ПРОГРАММНЫХ ЭЛЕМЕНТОВ должна быть ПЕРЕОЦЕНЕНА и. если необходимо,
пересмотрена. Это вызывает доработку с применением дополнительных ПРОЦЕССОВ к отдельному ЭЛЕМЕНТУ
ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ в результате его модернизации до более высокого класса. ПРОЦЕСС менед
жмента конфигурации ПО (см. раздел 8) используется для обеспечения уверенности в том. что все необходимые
доработки были идентифицированы и завершены.
В.5.4 Детализация проекта ПО
Эта деятельность требует от ИЗГОТОВИТЕЛЯ усовершенствовать ПРОГРАММНЫЕ ЭЛЕМЕНТЫ и интер
фейсы. определенные в АРХИТЕКТУРЕ, чтобы создать ПРОГРАММНЫЕ МОДУЛИ и их интерфейсы. Хотя ПРО
ГРАММНЫЕ МОДУЛИ часто считаются единичными функциями или модулями, эта точка зрения не всегда яв
ляется приемлемей. ПРОГРАММНЫЙ модуль был определен как ПРОГРАММНЫЙ ЭЛЕМЕНТ, не делимый на
более мелкие элементы. ПРОГРАММНЫЕ МОДУЛИ могут быть проверены отдельно. ИЗГОТОВИТЕЛЮ следует
определить уровень детализации ПРОГРАММНОГО МОДУЛЯ. Детализированный проект определяет алгоритмы
представления данных и взаимодействия между ПРОГРАММНЫМИ МОДУЛЯМИ и структурами данных. Детали
зированный проект также должен касаться и формирования ПРОГРАММНОГО ПАКЕТА. Необходимо документи
ровать проект для каждого ПРОГРАММНОГО МОДУЛЯ и его интерфейса так. чтобы ПРОГРАММНЫЙ МОДУЛЬ
мог быть реализован правильно. Детализированный проект заполняет детали, необходимые для проектирования
28