Начинаем собирать информацию для оценки систем. Важной проблемой, которая возникает в этом случае: заключение может формироваться не на основе анализа первичных данных, а на основе интерпретаций первичных данных.
Например, если бы врач проводил диспансеризацию пациентов не по анализам, дающим относительно объективную информацию, а на основе опроса:
Как Вы себя чувствуете?
Хорошо
Ну и славно.
Здесь доктор делает заключение о здоровье пациента, не на основе первичных данных, а на основе интерпретации пациентом своего самочувствия. Конечно «жалобы» пациента важны для доктора,но если решения о лечении принимать только на основе "данных" от пациента - значит использовать для анализа не объективные факты (анализы), а "интерпретации" пациента. Т.е. для анализа нужны первичные объективные данные, не вторичные данные, полученные "допросом" свидетеля.
В нашей системе "Федерация", заложен принцип из медицины:
для обследования у нас есть свой список данных(анализов) о системе,
на основе которых можно получить все необходимую для оценки первичную информацию
Проиллюстрирую на примере: мы не спрашиваем - у вас оптимальная структура БД для данного типа задач? Категорически нет, мы:
запрашиваем физическую структуру БД - Entity Relationship Diagram(ERD),
анализируем тип системы : OLTP - транзакционная или OLAP - аналитическая),
выясняем задачи, для которых она предназначена: процессинг или кадровая система
условия эксплуатации : объем бизнеса, кол-во пользователей-клиентов
и только тогда даем заключение – система имеет оптимальную структуру БД для использования в заданных условиях.
Исходя из этого, мы подготовили «карту анализов» или "Технологическую анкету системы". Это список первичных данных, необходимых и достаточных для анализа систем по всей критериальной модели. В данной части мы рассмотрим поблочно упрощенную анкету, для иллюстрации принципа. Детальная анкета для публикации не предназначена.
Это блок данных анкеты позволяет оценить команду продукта по критериям раздела «Ресурсы организации» (детали см. в части 6.2.) :
нет будет ли конкуренции за ресурсы в команде?
хватит ли компетенций для задач потребителя решения?
Не то, что поставщик говорит – обещаю и клянусь, а какими ресурсами реально располагает поставщик. Может случится так, что после этого поставщик пойдет на рынок, наймет людей формально все будет выглядеть пристойно, но каково «качество» масштабированных ресурсов? А если мы запросим текущую численность, то сами поймем - есть ли там риски или нет. Например, команда очень компактная, привыкла иметь дело с небольшими проектами и вдруг «замахнется» на большой проект. Очевидно для этого «нарастит» команду неподготовленными кадрами и в целом уровень компетенции упадет. Первичные данные о команде, более надёжны, чем заверения поставщика.
Запрашиваем данные без фамилий и других персональных данных, только человеческие «мощности» поставщика.
Это первичные данные для раздела «Траектория развития продукта». Анализируем вычищены ли детские болезни, какой потенциал модернизации (производитель уже боится что-то трогать), сколько версий и т.д.
Данные для раздела «Траектория развития продукта» и «Ограничения использования». Какие уважаемые организации, а может и регуляторы «благословили» продукт? Если есть в Реестре МинЦифры – значит с ИТ-суверенитетом все хорошо и т.д?
Идем дальше :
Данные для раздела критериальной модели «Ограничения использования». Может требуется лицензия от третьей стороны, а этот лицензиар из недружественной юрисдикции, или у потребителя и третьей стороны есть свои сложности, как у Китая с Индией?
На этом общие сведения заканчиваются, и мы переходим с непосредственно к архитектуре системы.
Куда можно «вывести» систему, если она обладает фронтальной частью? Не «можем вывести на Android», а уже вывели – есть соответствующее приложение для устройств Android, а не «можем предложить браузерную версию» и т.д. Нужно явно указать какой модуль системы содержит данный функционал.
Список модулей системы и краткое описание функционала каждого модуля. Получим функционал системы в форме "часть-целое", можно оценить декомпозицию системы и как «нарезана» система, на какие части? См. часть 3. Шапка архитектора.
Какие способы и стили интеграции используются в системе? Как с ней интегрироваться «родным» способом?
Какие компетенции могут еще понадобиться? Нет технологий от «неХороших» третьих сторон? Оставшуюся часть анкеты приведу без дополнительных комментариев.
Так выглядит схема "Технической анкета продукта". Детальная структура, как и указывал выше, не предназначена для публикации, но приведенный "эскиз" позволяет сформировать понимание инструмента "Техническая анкета продукта".
Стоит еще напомнить, что развитие инструментов "Критериальной модели" и "Технологическая анкета продукта", как ее части идет по операционным моделям, описанным в части 5. Критериальная модель – принципы построения.
Далее уместно рассмотреть двухфазную оценку систем, но это уже в следующей части.
