ГОСТ Р ИСО/МЭК 16680—2015
Продолжение таблицы А. 1
Направление
OSIMM
Текущим
уровень
запер*
темности
Краткая оценка
Целевой
уровень
завер
шенно
сти
Рекомендации
Приложения
(интерфейс
ные)
3
Сильныестороны:
- компонентная, многоуровневая ар
хитектура;
- используютсяобъектные модели.
Слабыестороны:
- минимальная степень повторного
использования кода;
- объектные модели не поддержи
вают совместного использования и
разрабатываются независимо друг
отдруга;
- используютсяспециализированные
(или не используются вовсе) ВРМ и
рабочие процессы;
архитектураприложениянестандар
тизирована
5
Реализоватьобъектную модель
в масштабе всегопредприятия.
Обеспечить повторное исполь
зование кода на уровне компо
нента ибиблиотеки.
Стандартизировать эталонную
архитектуру приложений, ша
блоны проектирования и пере
довые практики.
Реализовать механизм управ
ления бизнес-правилами.
Модернизировать и разбить на
компоненты приложения, соз
данные на Коболе
Приложения
(унаследо
ванные)
2
Сильныестороны:
- проводятся работы по модерниза
ции архитектурыприложений;
- унаследованныепредставлениядо
ступа обеспечивают последователь
ный подход к повторному использо
ванию кода.
Слабые стороны;
- унаследованная архитектура, свя
занная с разработкой на Коболе,
сложна в изменении.
- нетединогоподхода к компонентно
мупредставлениюсистемы:
- используютсяспециализированные
(или не используются вовсе) ВРМ и
рабочие процессы;
- архитектураприложенийнестандар
тизирована и не направлена на ис
пользование серверных приложений
Интеграция
архитектуры
и сервисы
(интер
фейсные)
3
Сильныестороны:
- в большинстве приложений исполь
зованы унаследованные представ
ления доступа, основанные на стан
дартном подходе;
- некоторые приложения действуют
как поставщики сервисов;
- файлы WSDL публикуются в каж
дом приложении.
Слабые стороны:
- интеграция точка—точка.
для интеграции с мейнфреймом ис
пользованы разные протоколы и ме
ханизмы трансляции;
- несогласованная архитектура без
опасности
5
Реализовать бизнес-сервисы с
возможностью повторного ис
пользования.
Реализоватькорпоративнуюин
теграционную модель данных
(каноническую модельданных).
Реализовать унифицированный
транспортный протокол для
веб-сервисов.
Весьобмен даннымис внутрен
ними и внешними системами
следует осуществлять через
ESB.
Поддерживать клиентов унас
ледованных приложений через
ESB.
38