Диссертация (1145120), страница 53
Текст из файла (страница 53)
То есть был найден разумный компромисс, что ихарактеризует обычно DSM-решение, позволяя ему быть более эффективным, чем общий подход, нацеленный на общую и часто неразрешимую в такой обобщённой постановке задачу.Следует также отметить, что в рамках генератора диаграммных отчётовподдержана декомпозиция больших древовидных диаграмм: для каждой такой диаграммы мы генерируем полный набор вариантов поддеревьев с частично свёрнутыми поддеревьями, и при клике мышью на портале на соответствующей вершине она раскрывается или сворачивается — то есть пользователю загружают ту или иную соответствующую, заранее заготовленнуюдиаграмму (вариацию). При этом на каждую диаграмму генерируется не более нескольких десятков вариаций, таким образом, подход оказываетсявполне осуществимым.
Это решение также является компромиссом: диаграммы на портале являются «неживыми», то есть загружаются с сервера целиком и являются заранее заготовленными (сгенерированными), а не отрисовываются на клиентской части портала. При этом они поддерживают реакцию символов на клики мышью — то есть можно для каждого узла на диаграмме вызвать дополнительные функции портала (например, выполнить егодальнейшую декомпозицию с помощью таблицы). Возможность поддержкиреакции на пользовательский клик мышью реализована через размещение ге327нератором графических отчётов дополнительной структуры данных в SVGфайле диаграммы с перечнем координат и размером символов для каждогоэлемента с тем, чтобы можно было вычислить, на какой символ пользовательуказал мышью.5.3.3 Метод использованияПользователями разработанных программных средств были аналитики, работающие в ОРГ-Мастере.
Они создавали выборки для визуализации, пользуясь генератором отчётов, а потом на основе этих выборок создавали соответствующие диаграммы и пересылали их разработчикам портала. Последние, после дополнительной обработки, размещали диаграммы на портале.Всего было создано около 1000 различных диаграмм.5.3.4 Процесс разработкиПроект разрабатывался в течение восьми месяцев силами двух человек, ипотом поддерживался ещё в течение полугода.
Однако общие трудозатратыможно оценить в 10 человеко-месяцев.Выработка концепции. Идея данного проекта заключалась в том, что наитоговом портале хотелось иметь визуальные модели. При этом было понимание того, что визуализировать нужно лишь часть информации. Таким образом, требовался настраиваемый генератор диаграмм по модели в ОРГМастере. Были сформулированы следующие верхнеуровневые требования.1. Сгенерированные диаграммы должны представляться в формате SVG(это было требование разработчиков портала). Генерируемые диаграммы должны содержать дополнительную служебную информацию.2. Диаграммы должны выглядеть красиво, что включало, в частности, оптимальную раскладку графических символов и связей. Первоначальнозаказчик хотел заниматься раскладкой символов «вручную», однако входе обсуждений было выявлено, что диаграмм планируется несколькосотен, при этом они будут меняться, так как модель постоянно дораба328тывалась.
Следовательно, стало необходимо реализовать эффективнуюавтоматическую раскладку. При этом определились, что ряд диаграммбудет раскладываться «вручную» — эффективную раскладку трудноили даже невозможно реализовать. Это касается диаграмм, которыеимеют «плоскую» графовую структуру (то есть не являются деревьямиили не содержат остовного дерева): существуют алгоритмы раскладкитаких диаграмм (см, например, [307]), однако такие алгоритмы не используют семантических критериев, а ориентируются на такие критерии, как минимальное пересечение связей.
Было решено минимизировать количество таких диаграмм.3. Как упоминалось выше, модель, а следовательно, и диаграммы должныбыли меняться в процессе разработки портала (то есть в процессе использования предполагаемого DSM-решения). Это значит, что для техдиаграмм, которые раскладываются «вручную», требуется поддержкагенерации, сохраняющей предшествующую версию диаграммы.4. Входные данные генератора диаграммных отчётов — выборка из модели и сама модель.
Выборка должна готовиться генератором отчётовОРГ-Мастера.5. Требования к самим диаграммам — был обозначен ряд диаграмм, подготовлены примеры для них.В качестве заказчика проекта выступили аналитики Системного Проекта,состоящая из двух групп — одна группа, находящая в Санкт-Петербурге,непосредственно общалась с разработчиками генератора диаграммных отчётов, вторая группа находилась в Москве и была недоступна для разработчиков. Однако именно она одобряла конечные варианты видов диаграмм. Кроме этого, была также команда разработчиков портала, с которой общение поСкайпу организовывали аналитики из Санкт-Петербурга. В качестве рисковразработки были идентифицированы изменчивость видов диаграмм, удалённость разработчиков портала и неясности относительно форматов служебной329информации в SVG-файлах, а также тот факт, что требовалось, по мере готовности видов диаграмм, разрабатывать генераторы XML-выборок.
То естьна начало разработки конкретики было мало, но генератор диаграмм былсрочно нужен.Планирование. Основная задача, которая решалась на данной фазе — этосогласование видов диаграмм, которые должны быть реализованы. Авторнастоял на использовании метамоделей для спецификации абстрактного иконкретного синтаксиса диаграмм и правил их раскладки, а также на предоставлении большого количества примеров. Как правило, примеров требовалось больше, чем один, так как идеи некоторых диаграмм появлялись в рамках создания первых примеров, а далее, при разработке дополнительныхпримеров, выяснялось, что идея диаграммы не очень удачна или что деталинотации не продуманы до конца и т.д.
Было также решено, какие виды диаграммы генерируются в SVG, а какие в Visio, и было выявлено, что Visioспособен генерировать приемлемый вариант SVG. В рамках данной фазыбыли достигнуты все необходимые договорённости с участвующими в разработке сторонами.Разработка. На этом этапе была выполнена всего одна итерация, в которой была реализована инфраструктура генератора и генерация несколькихпервых видов диаграмм. После этого решение было отдано пользователям.Разработка и использование. На этом этапе было выполнено три итерации, в рамках которых добавлялись новые виды диаграмм, а также изменялись прежние, уже реализованные. Следует отметить высокую изменчивостьтребований в данном проекте — от технического задания к первой итерациив финальном решении осталось менее 50% требований. Для каждой итерациисоздавалось новое техническое задание, но требования часто менялись в ходеитерации, так что не удавалось реализовать полноценную итерацию (sprint)метода Scrum.
Результатами проекта тут же начинали пользоваться, так как330для портала требовались диаграммы — портал постоянно демонстрировалсязаказчику.Передача. После завершения реализации самого генератора и всех видовдиаграмм команда поддерживала решение до окончания Системного Проекта. Код генератора был передан команде, сопровождающей ОРГ-Мастер.Эксплуатация и сопровождение. Эта фаза отсутствовала ввиду ограниченного времени применения решения.3315.4 Моделирование ИТ-архитектуры крупной корпорацииКрупная нефтегазовая российская корпорация (далее — Компания) использует несколько сотен информационных систем, больше половины из которых были специально созданы для этой компании.
При этом используетсяболее трёхсот различных платформ разработки и поддержки информационных систем — Oracle, SAP, 1С, различные Java-технологии и т.д., то есть,практически, все известные. Компания тратит большие усилия на инвентаризацию своих ИТ-активов, на унификацию процессов по закупке, разработке,эксплуатации и модернизации всех информационных систем, а также на ихсвязь с бизнес-задачами.
В связи с этим компания организовала серию КИТпроектов. Кроме того, данные КИТ-проекты интегрируются с результатамиещёоднойсерииКИТ-проектов,посвящённыхописаниюбизнес-архитектуры Компании.Автор не имеет возможности описать все эти проекты в рамках данной работы, поэтому он остановится на описании лишь одного КИТ-проекта из этойсерии, направленного на разработку и внедрение КИТ-решения на базе пакета ARIS. При этом язык моделирования был создан в рамках предыдущегопроекта, метод использования решения разрабатывался параллельно в рамкахещё одного проекта.
Уже после описываемого здесь проекта был организованследующий КИТ-проект, нацеленный на перенос КИТ-решения на новуюверсию ARIS, а также на исправления недочётов и ошибок предыдущих проектов.В рамках данных работ непосредственно автором было сделано следующее.1. Участие в разработке предметно-ориентированного языка моделирования корпоративной информационной архитектуры Компании, разработка компонентно-функциональной и информационной моделей, атакже модели требований.2. Разработка методик для моделирования сценариев и требований.3323. Проектирование и реализация для ARIS средств поддержки корректности визуальных спецификаций.4. Апробация созданных средств моделирования для четырёх информационных систем Компании на базе платформы SAP.5.4.1 Язык моделированияСозданный язык моделирования состоял из двух частей: первая частьпредназначалась для описания бизнес-архитектуры, вторая — для описанияинформационной архитектуры Компании.Бизнес-архитектура в данном проекте понималась как модели существенных аспектов организационной, управленческой и процессной деятельностиКомпании, а именно: функциональные модели бизнес-процессов Компании; модели организационной и территориальной структуры Компании,структуры ролей участников бизнес-процессов; модели целей и ключевых показателей деятельности Компании и бизнес-процессов; модели документационного обеспечения бизнес-процессов.Информационная архитектура (или ИТ-архитектура) в рамках данногопроекта была определена как описание структуры информации в Компании,информационного взаимодействия и носителей данных.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
