Методологические указания в оценке TRL

В сегодняшней статье мы поговорим о том, на что следует обратить внимание оценщику и владельцу технологии при оценке её готовности.

Упор будем делать на проекты по информационным технологиям и информационной безопасности. Именно в них ожидание по уровню готовности далеко не всегда совпадает с реальностью.

Важно! Информация получена из описания услуги по проверке TRL проектов в области высоких технологий RTM Group.

Отметим: даже полностью рабочий прототип, имеющий идеальную матмодель – это лишь первый этап TRL.

То есть детально прописанное ТЗ, в том числе по 34 ГОСТ – это только базовая готовность системы. Для перехода на следующий уровень необходимо удостовериться, что проведена апробация на условиях, приближенных к реальным.

То есть межсетевой экран установлен, как минимум, в офисе разработчика, а, например, мобильное приложение размещено в App Store.

В тоже время, если приложение размещено в магазине, но теоретические основы не описаны или описаны не окончательно – даже первый уровень не будет достигнут. То есть все уровни должны быть подтверждены последовательно.

Калькулятор расчёта ГОСТ 58048

Применяя калькулятор для расчета, приведенный, например, в ГОСТ 58048, необходимо подробно заполнять свидетельства и/или обоснования выставленной оценки. Недостаточно указать, что предоставлено ТЗ. Необходимо уточнить, какие разделы там подтверждают оцениваемый показатель.

Также важно помнить о том, технология какого типа оценивается. Крайне распространенная ошибка – оценка всех вопросов для уровня готовности, независимо от вида системы и области анализа.

При проведении как самооценки, так и внешней оценки рекомендуется в калькуляторе проставить отметки напротив не оцениваемых вопросов (например, Н/О по аналогии с оценкой 382-П или Н по аналогии с ГОСТ 57580) и согласовать их между участниками во избежание расхождений в будущем.

Калькулятор для проведения самооценки рекомендуется разработать самостоятельно и проверить результативность на крайних показателях – 05 и 100% готовности. Данная задача, разумеется, на стоит для аудиторов, выполняющих задачу регулярно.

Диалог разработчика и оценщика

Свидетельства для оценки – немаловажная составляющая. Если при самооценке и внешней оценке использованы разные версии документов, и, тем более, их наборы – это прямой путь к конфликту. Не стоит скрывать от внешнего оценщика технологическую документацию.

Разумеется, NDA должен быть составлен и подписан до начала работ. Ну и выбирать оценщика, к которому недостаточно доверия – не стоит. Как найти подходящего? Тема отдельной статьи. Поэтому если просят код – лучше его передать. Более высокая, и объективная оценка никому не мешала.

В ходе проведения оценки важен диалог разработчиков технологии и оценщиков. Даже при проведении регламентных аудитов, таких как ГОСТ 57580, интервью сотрудников Заказчика – не только допустимая, но и важная составляющая.

Подробное заполнение опросных листов аудитора сократит время, затраченное на оценку и, что немаловажно, нагрузку на специалистов Заказчика. Поэтому если получен вопрос – ответ на него должен быть развернутым и подробным. Это залог того, что на месте этого вопроса не возникнет двух новых.

Декомпозиция ПО

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

Как декомпозировать программное обеспечение? Минимально – фронт и бэк. Очевидно, что готовность системы будет определяться по минимальной готовности компонент. Это важно понимать при самостоятельном анализе технологии и поможет избежать завышенных ожиданий, и, как следствие, конфликта с оценщиком.

Итог

В целом, оценка TRL (а также CRL и т.д.) – процесс взаимодействия заказчика и внешнего оценщика, в котором взаимное уважение играет немаловажную роль. Поскольку при оценке готовности оценщик не является зависимым, проявление этики необходимо максимизировать.

Это не обозначает, что следует ставить оценку, которую хочет Заказчик. Однако, следует как можно внимательнее рассматривать пожелания и комментарии – это позволит не только с блеском завершить проект, но и углубить свои знания в предметной области технологии. Что является залогом профессионального роста любого оценщика.