Начинаем собирать информацию для оценки систем. Важной проблемой, которая возникает в этом случае: заключение может формироваться не на основе анализа первичных данных, а на основе интерпретаций первичных данных.

Например, если бы врач проводил диспансеризацию пациентов не по анализам, дающим относительно объективную информацию, а на основе опроса:

Как Вы себя чувствуете?
Хорошо
Ну и славно.

Здесь доктор делает заключение о здоровье пациента, не на основе первичных данных, а на основе интерпретации пациентом своего самочувствия. Конечно «жалобы» пациента важны для доктора,но если решения о лечении принимать только на основе "данных" от пациента - значит использовать для анализа не объективные факты (анализы), а "интерпретации" пациента. Т.е. для анализа нужны первичные объективные данные, не вторичные данные, полученные "допросом" свидетеля.

В нашей системе "Федерация", заложен принцип из медицины:

для обследования у нас есть свой список данных(анализов) о системе,
на основе которых можно получить все необходимую для оценки первичную информацию

Проиллюстрирую на примере: мы не спрашиваем - у вас оптимальная структура БД для данного типа задач? Категорически нет, мы:

запрашиваем физическую структуру БД - Entity Relationship Diagram(ERD),
анализируем тип системы : OLTP - транзакционная или OLAP - аналитическая),
выясняем задачи, для которых она предназначена: процессинг или кадровая система
условия эксплуатации : объем бизнеса, кол-во пользователей-клиентов

и только тогда даем заключение – система имеет оптимальную структуру БД для использования в заданных условиях.

Исходя из этого, мы подготовили «карту анализов» или "Технологическую анкету системы". Это список первичных данных, необходимых и достаточных для анализа систем по всей критериальной модели. В данной части мы рассмотрим поблочно упрощенную анкету, для иллюстрации принципа. Детальная анкета для публикации не предназначена.

**Таблица 1. Сведения о команде (кликните для увеличения изображения)**

Это блок данных анкеты позволяет оценить команду продукта по критериям раздела «Ресурсы организации» (детали см. в части 6.2.) :

нет будет ли конкуренции за ресурсы в команде?
хватит ли компетенций для задач потребителя решения?

Не то, что поставщик говорит – обещаю и клянусь, а какими ресурсами реально располагает поставщик. Может случится так, что после этого поставщик пойдет на рынок, наймет людей формально все будет выглядеть пристойно, но каково «качество» масштабированных ресурсов? А если мы запросим текущую численность, то сами поймем - есть ли там риски или нет. Например, команда очень компактная, привыкла иметь дело с небольшими проектами и вдруг «замахнется» на большой проект. Очевидно для этого «нарастит» команду неподготовленными кадрами и в целом уровень компетенции упадет. Первичные данные о команде, более надёжны, чем заверения поставщика.

Запрашиваем данные без фамилий и других персональных данных, только человеческие «мощности» поставщика.

Таблица 2. История продукта (кликните для увеличения изображения) — Таблица 2. История продукта **(кликните для увеличения изображения)**

Это первичные данные для раздела «Траектория развития продукта». Анализируем вычищены ли детские болезни, какой потенциал модернизации (производитель уже боится что-то трогать), сколько версий и т.д.

**Таблица.3. Сертификация продукта (кликните для увеличения изображения)**

Данные для раздела «Траектория развития продукта» и «Ограничения использования». Какие уважаемые организации, а может и регуляторы «благословили» продукт? Если есть в Реестре МинЦифры – значит с ИТ-суверенитетом все хорошо и т.д?

Идем дальше :

**Таблица.4.Необходимое лицензирование (кликните для увеличения изображения)**

**Таблица.5. Ограничения на использование вне зависимости от лицензий (кликните для увеличения изображения)**

Данные для раздела критериальной модели «Ограничения использования». Может требуется лицензия от третьей стороны, а этот лицензиар из недружественной юрисдикции, или у потребителя и третьей стороны есть свои сложности, как у Китая с Индией?

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

**Таблица 6. Каналы взаимодействия с пользователем (кликните для увеличения изображения)**

Куда можно «вывести» систему, если она обладает фронтальной частью? Не «можем вывести на Android», а уже вывели – есть соответствующее приложение для устройств Android, а не «можем предложить браузерную версию» и т.д. Нужно явно указать какой модуль системы содержит данный функционал.

**Таблица 7. Функциональная декомпозиция (кликните для увеличения изображения)**

Список модулей системы и краткое описание функционала каждого модуля. Получим функционал системы в форме "часть-целое", можно оценить декомпозицию системы и как «нарезана» система, на какие части? См. часть 3. Шапка архитектора.

**Таблица 8. Интеграция (кликните для увеличения изображения)**

Какие способы и стили интеграции используются в системе? Как с ней интегрироваться «родным» способом?

**Таблица 9. Технологии (кликните для увеличения изображения)**

Какие компетенции могут еще понадобиться? Нет технологий от «неХороших» третьих сторон? Оставшуюся часть анкеты приведу без дополнительных комментариев.

**Таблица. 10 Архитектура системы (остаток анкеты) (кликните для увеличения изображения)**

Так выглядит схема "Технической анкета продукта". Детальная структура, как и указывал выше, не предназначена для публикации, но приведенный "эскиз" позволяет сформировать понимание инструмента "Техническая анкета продукта".

Стоит еще напомнить, что развитие инструментов "Критериальной модели" и "Технологическая анкета продукта", как ее части идет по операционным моделям, описанным в части 5. Критериальная модель – принципы построения.

Далее уместно рассмотреть двухфазную оценку систем, но это уже в следующей части.

Система «Федерация». Часть 6.3/8 Критериальная модель – технологическая анкета