Файлу проектирования и разработки (ФПР) для ПО с искусственным интеллектом

1. Назначение и область применения

ФПР является основополагающим документом, демонстрирующим и обеспечивающим прослеживаемость всех этапов жизненного цикла ПО от первичной концепции до выпуска и сопровождения. Документ должен подтверждать, что проектирование, разработка и верификация ПО осуществлялись в соответствии с установленными требованиями.

2. Нормативные ссылки

ФПР должен разрабатываться с учетом требований следующих нормативных документов:

3. Термины и определения

В ФПР должны быть определены ключевые термины, используемые в документе:

• ПО – программное обеспечение

• ИИ – искусственный интеллект

• МО – машинное обучение

• ФПР – файл проектирования и разработки

• SRS – спецификация требований к ПО (Software Requirements Specification)

• ПОНП (SOUP) – программное обеспечение неизвестного происхождения (Software of Unknown Provenance)

• OTS – готовое программное обеспечение (Off-The-Shelf)

• ЖЦ – жизненный цикл

• СМК – система менеджмента качества

• API – интерфейс прикладного программирования

• AUC ROC – площадь под ROC-кривой

• MAE – средняя абсолютная ошибка

• MAPE – средняя абсолютная процентная ошибка

4. Структура ФПР

ФПР должен включать следующие обязательные разделы:

4.1. Введение и общие положения

• Наименование медицинского изделия – полное наименование ПО с указанием технологии ИИ.

• Класс потенциального риска – с обоснованием присвоенного класса.

• Разработчик и изготовитель – наименование организации, юридический адрес.

• Назначение документа – цель создания ФПР.

• Область применения – процессы и подразделения, на которые распространяется документ.

4.2. Идентификация и управление файлом

• Порядок создания, хранения, утверждения и внесения изменений в ФПР.

• История изменений документа с указанием версий, дат и описаний изменений.

4.3. Классификация ПО

• Методология классификации – согласно ГОСТ IEC 62304.

• Обоснование класса безопасности – с применением принципа наихудшего сценария, учетом роли врача и отказом средств управления риском.

• Заключение по классу – для ПО с ИИ, влияющего на принятие клинических решений, класс безопасности должен быть не ниже B, чаще C.

4.4. Входные данные для проектирования и разработки

4.4.1. Анализ рынка и потребностей потребителей

• Результаты изучения рынка подобных изделий.

• Выявленные проблемы и потребности целевой аудитории.

• Экономические и клинические обоснования.

4.4.2. Анализ конкурентов

• Перечень конкурентных решений с их описанием.

• Отличия и преимущества разрабатываемого продукта.

4.4.3. Научные публикации

• Список публикаций, подтверждающих методологию и новизну.

• Описание вклада каждой публикации в разрабатываемое решение.

4.4.4. Задел по регистрации РИД

• Зарегистрированные базы данных (для обучения моделей).

• Зарегистрированное программное обеспечение.

• Товарные знаки.

4.4.5. Результаты Customer Development (CustDev)

• Методология проведения интервью.

• Обобщенные результаты с анализом ключевых проблем.

• Выводы и их влияние на требования к ПО.

4.5. Спецификация требований к ПО (SRS)

4.5.1. Концепция продукта

• Описание назначения и ключевых функций.

4.5.2. Пользовательские роли

• Перечень ролей и их описание (врачи-лаборанты, врачи-клиницисты, администраторы, пациенты).

4.5.3. Функциональные требования

• Модуль интеграции и сбора данных.

• Модуль прогнозирования (ядро системы).

• Модуль контроля качества.

• Модуль интерпретации и формирования заключения.

• Модуль возврата результатов.

• B2C-модуль (веб-сервис для пациентов).

4.5.4. Нефункциональные требования

• Производительность – время обработки запроса, пропускная способность, доступность.

• Точность моделей – метрики качества (R², MAE, MAPE, AUC ROC) с целевыми значениями.

• Надежность – обработка ошибок, сохранение работоспособности при частичных отказах.

• Безопасность – шифрование, аутентификация, логирование, обезличивание данных.

• Масштабируемость – горизонтальное масштабирование, контейнеризация.

• Сопровождаемость – документирование кода, контроль версий.

4.5.5. Требования к интерфейсам

• API-интерфейс (базовый URL, структура запроса и ответа).

• Пользовательский интерфейс (состав элементов, требования к отображению).

4.5.6. Требования к данным

• Объем и репрезентативность данных для обучения.

• Методология формирования наборов данных.

• Обезличивание и защита данных.

• Прослеживаемость версий моделей и датасетов.

4.5.7. Метрики качества

• Сводная таблица моделей с указанием:

• Типа модели (регрессия/классификация).

• Метрик качества (R², MAE, MAPE, AUC ROC).

• Размера обучающей выборки.

4.6. План разработки ПО (SDP)

4.6.1. Модель жизненного цикла

• Выбор модели (итеративная, инкрементальная, V-модель) с обоснованием.

• Структура жизненного цикла с указанием этапов и выходных данных.

4.6.2. Организационная структура

• Состав команды разработки с указанием ролей и ответственности.

• Схема взаимодействия участников.

4.6.3. Процессы разработки ПО

• Анализ требований – входные данные, выходные данные, верификация.

• Проектирование архитектуры – обязательные элементы для класса C.

• Детальное проектирование – декомпозиция на программные блоки.

• Реализация – стандарты кодирования, модульное тестирование.

• Интеграция и интеграционное тестирование – процесс интеграции, критерии.

• Системное тестирование – объем, требования, метрики приемки.

• Выпуск ПО – критерии готовности, процедура выпуска.

4.6.4. Процесс управления рисками

• Интеграция с процессом менеджмента риска.

• Прослеживаемость рисков от опасной ситуации до меры управления.

• Управление рисками при разработке.

4.6.5. Управление конфигурацией

• Идентификация конфигурационных единиц.

• Система контроля версий (Git).

• Управление версиями ПО (схема A.B.C.D.).

4.6.6. Управление проблемами

• Процесс регистрации, классификации и устранения проблем.

• Приоритеты и сроки устранения дефектов.

4.6.7. Верификация и валидация

• Стратегия верификации по уровням (требования, архитектура, дизайн, реализация, интеграция, система).

• Стратегия валидации (пользовательская, процессов).

4.6.8. Ресурсы и инструменты

• Аппаратные ресурсы (рабочие станции, серверная инфраструктура).

• Программные инструменты (IDE, библиотеки ML, фреймворки, инструменты тестирования).

4.6.9. Ключевые метрики процесса разработки

• Покрытие кода тестами (≥ 80%).

• Количество критических дефектов (0 на релиз).

• Время закрытия критических дефектов (≤ 24 часа).

• Выполнение плана итерации (≥ 90%).

4.7. Требования по киберзащищенности

4.7.1. Идентификация активов

• Перечень активов, подлежащих защите, с указанием места размещения и критичности.

4.7.2. Идентификация угроз

• Типология угроз (конфиденциальность, целостность, доступность, аутентичность).

• Детализированный перечень угроз с ID, источником и потенциальными последствиями.

• Оценка рисков реализации угроз.

4.7.3. Требования к обеспечению киберзащищенности

• Аутентификация и идентификация (логин/пароль, хеширование, блокировка).

• Разграничение доступа (изоляция данных, одноролевая/многоролевая модели).

• Защита каналов передачи данных (HTTPS/TLS, сертификаты, файрволлы).

• Защита от вредоносного ПО (антивирусное ПО, проверки).

• Защита от несанкционированного изменения ПО и моделей (обфускация, цифровая подпись).

• Логирование и аудит (фиксация событий, защита логов).

• Управление сеансами (таймаут, контроль единовременной активности).

• Защита персональных данных (обезличивание, шифрование).

• Резервное копирование и восстановление (периодичность, глубина хранения).

4.7.4. Требования к защите от незаконного распространения

• Уникальные учетные данные для каждой организации.

• Контроль единовременной активности.

• Блокировка при обнаружении параллельного использования.

4.7.5. Организационные меры

• Ответственность медицинской организации-заказчика.

• Ответственность производителя.

4.8. Проект архитектуры ПО

4.8.1. Архитектурная концепция

• Выбор архитектурного стиля (микросервисная, контейнеризация) с обоснованием.

4.8.2. Высокоуровневая архитектурная схема

• Графическое представление компонентов и их взаимодействия.

4.8.3. Детальное описание архитектурных компонентов

Для каждого компонента:

• Назначение.

• Класс безопасности.

• Связь с требованиями SRS.

• Основные функции.

• Требования к интерфейсам.

4.8.4. Требования к инфраструктуре

• Платформа развертывания.

• Требования к безопасности инфраструктуры (сеть, шифрование, бэкапы, мониторинг).

4.8.5. Матрицы прослеживаемости

• SRS → Архитектура.

• CustDev → Архитектура.

• Архитектура → Риски (ГОСТ ISO 14971).

4.8.6. Требования к изоляции компонентов

• Уровни изоляции для компонентов разного класса безопасности.

4.9. Проект детального дизайна ПО

4.9.1. Декомпозиция программных компонентов

• Общая структура программных блоков (Software Units).

• Идентификаторы, наименования, принадлежность к компонентам, класс безопасности.

4.9.2. Детальное описание программных блоков

Для каждого блока:

• Идентификатор.

• Назначение.

• Входные данные.

• Выходные данные.

• Алгоритм (последовательность действий).

• Интерфейсы.

• Связь с требованиями SRS.

• Примечания.

4.9.3. Матрицы прослеживаемости

• Архитектурные компоненты → Программные блоки.

• Требования SRS → Программные блоки.

• Программные блоки → Риски (ГОСТ ISO 14971).

4.9.4. Требования к реализации

• Стандарты кодирования (PEP 8, стиль, документация).

• Требования к модульному тестированию (покрытие, инструменты).

• Требования к интерфейсам между блоками (gRPC, REST, OpenAPI).

4.10. План тестирования ПО

4.10.1. Объекты тестирования

• Перечень компонентов с указанием класса безопасности.

4.10.2. Уровни тестирования

• Модульное тестирование.

• Интеграционное тестирование.

• Системное тестирование.

• Валидационное тестирование.

4.10.3. Виды тестирования

• Функциональное.

• Нефункциональное (производительность, надежность, безопасность, масштабируемость, совместимость).

• Регрессионное.

• Тестирование точности моделей ML (с указанием метрик).

4.10.4. Стратегия тестирования

• Соотношение автоматизированного и ручного тестирования.

• Инструменты автоматизации.

• Требования к покрытию тестами.

4.10.5. Тестовые данные

• Источники тестовых данных (синтетические, обезличенные клинические, пилотные испытания).

• Требования к тестовым данным (объем, репрезентативность, методология).

• Управление тестовыми данными (хранение, доступ, защита).

4.10.6. Критерии приемки

• Для итерации.

• Для релиза.

• Завершения тестирования.

4.10.7. Среда тестирования

• Аппаратная среда.

• Программная среда.

• Тестовые окружения (Dev, Test, Staging, Production).

4.10.8. График тестирования

• По итерациям с указанием этапов и длительности.

4.10.9. Обработка дефектов

• Классификация дефектов (критические, высокие, средние, низкие).

• Процесс управления дефектами (обнаружение, регистрация, анализ, исправление, верификация, закрытие).

• Документирование дефектов.

4.10.10. Матрица прослеживаемости

• Требования → Тестовые сценарии.

4.10.11. Выходные документы

• Отчет о модульном тестировании.

• Протокол интеграционного тестирования.

• Отчет о системном тестировании.

• Отчет о нагрузочном тестировании.

• Отчет о дефектах.

• Сводный отчет о тестировании.

4.11. Выходные данные для Технических условий (ТУ)

ФПР должен содержать раздел, в котором перечислены выходные данные, подлежащие включению в Технические условия:

• Общие сведения об изделии.

• Функциональные характеристики.

• Технические характеристики (производительность, время обработки, доступность, точность моделей).

• Требования к входным данным.

• Требования к выходным данным.

• Требования к данным для обучения.

• Требования к интерфейсам.

• Требования к безопасности и защите информации.

• Маркировка и упаковка.

4.12. Приложения

В состав ФПР могут включаться приложения, содержащие:

• Анкеты для проведения Customer Development.

• Отчеты о тестировании.

• Отчеты о верификации.

• Отчеты о валидации.

• Иные документы, подтверждающие результаты разработки.

5. Специальные требования для ПО с ИИ

5.1. Требования к данным для обучения

• Должна быть обеспечена прослеживаемость между версиями моделей и использованными для обучения датасетами.

• Данные должны быть репрезентативны (разные регионы, разные анализаторы, разные популяции).

• Методология формирования наборов данных должна соответствовать ГОСТ Р 59921.5-2022.

• Данные должны быть обезличены в соответствии с требованиями законодательства.

5.2. Требования к точности моделей

• Для каждой модели должны быть определены целевые метрики качества:

• Для регрессионных моделей: R², MAE, MAPE.

• Для классификационных моделей: AUC ROC, чувствительность, специфичность.

• Метрики должны быть подтверждены на независимых тестовых выборках.

• Должен быть проведен анализ устойчивости моделей к выбросам и искажениям входных данных.

5.3. Требования к управлению рисками для ИИ

• Должны быть идентифицированы специфические опасности, связанные с использованием ИИ:

• Ложноотрицательные и ложноположительные результаты.

• Дрейф концепций (concept drift) – изменение распределения данных в эксплуатации.

• Непредсказуемое поведение моделей на данных, выходящих за пределы обучающей выборки.

• Должны быть реализованы меры управления рисками:

• Мониторинг качества прогнозов в эксплуатации.

• Механизмы обратной связи для дообучения моделей.

• Указание уровня уверенности модели.

5.4. Требования к кибербезопасности для ИИ

• Предобученные модели должны храниться в защищенном хранилище с ограниченным доступом.

• Должна быть обеспечена защита от несанкционированной модификации моделей.

• Должна быть обеспечена прослеживаемость версий моделей.

6. Заключение

Файл проектирования и разработки является ключевым документом, демонстрирующим соответствие процессов разработки ПО с ИИ требованиям регуляторных стандартов. Документ должен обеспечивать полную прослеживаемость от первичных требований до готового продукта, включая все этапы проектирования, реализации, верификации и валидации.

При разработке ФПР для ПО с ИИ особое внимание следует уделять:

1. Обоснованию класса безопасности (вероятно, класс C).

2. Качеству и репрезентативности данных для обучения.

3. Метрикам точности моделей и их подтверждению.

4. Управлению рисками, связанными с использованием ИИ.

5. Кибербезопасности, включая защиту моделей от модификации.

6. Прослеживаемости всех артефактов разработки.