Диссертация (1145120), страница 51
Текст из файла (страница 51)
В связи с этим пользы РУПрешения было меньше, чем могло бы быть, так как много работы оказалосьуже сделано к моменту его появления. В качестве DSM-платформы был выбран пакет Microsoft Visio [351], потому что он позволяет легко создаватьмногофункциональные графические средства. В данном проекте в качествесредства разработки кода редактора был выбран встроенный в Visio VBA(Visual Basic for Application), поскольку разрабатываемый редактор был небольшим. Однако модуль интеграции с ОРГ-Мастером был создан на языкеC# и среда Microsoft Visual Studio в силу удобства использования. Ещё однойпричиной выбора Visio как платформы для разработки РУП-решения былото, что мы исходно начали создавать модели в Visio, ещё не собираясь разрабатывать специального программного решения.
При разработке требований крешению мы тщательно следили за тем, чтобы не заниматься реализациейизбыточной функциональности. Мы опускали требования, сопровождаемыесловами «хорошо бы…» или «так правильно…», если за ними не стоял реальный запрос со стороны контекста использования РУП-решения — ISSпроекта. Так, мы отказались от реализации следующей функциональности,которая обычно входит в графические средства. Мы не стали реализовывать двустороннюю циклическую разработку,хотя возможность менять схему модели прямо из ОРГ-Мастера с отражением появившихся классификаторов и проекций в РУП-редакторебыла бы, без сомнения, удобна. Мы не реализовали функцию загрузки элемента на диаграмму.
Анализотношения количества повторно используемых элементов в нашей модели (нормированное затратами на поддержку «ручной» синхронизации) к затратам на реализацию этой функциональности, а также имевшиеся у нас ресурсы (люди, время) на разработку РУП-решения, при315вели нас к выводу, что эффективнее оставить эту функциональностьнереализованной и выполнять соответствующую работу «вручную». В нашем редакторе не реализована полная поддержка целостности,например, контроль того, что во всей модели существует только однаобласть, а также того, что в модели нет повторяющихся подобластей.Всего таких сущностей в нашей модели меньше десяти, так что поддержка целостности «вручную» здесь не представила затруднений.Также мы не стали тратить усилия на разработку инсталляционного пакетаи ряда других возможностей, облегчающих распространение и развёртку решения, поскольку пользователей у него было немного.Разработка. Разработка РУП-решения велась итеративно — на данной фазе было произведено две итерации.
Были реализованы все виды диаграмм иосновная функциональность редактора. После этого с помощью решения были нарисованы все диаграммы. Инсталляционный пакет не создавался, распространение продукта производилось вместе с vsd-файлом модели, а такжедополнительными файлами настройки.Разработка и использование. Далее продукт дорабатывался вместе с егоиспользованием — диаграммы обсуждались и доделывались, собиралась дополнительная информация. На этом этапе было проведено пять итераций,при этом два раза все диаграммы пришлось полностью перерисовывать из-занесовместимости версий редактора.
Всего было создано 15 диаграмм формата А4. Созданная модель подробно описана в работах [50], [57]. В итоге РУПрешение активно использовалось на этой фазе при работе с моделью контента, позволяя нам решить наши главные проблемы: легко вносить изменения исоздать красивые диаграммы (для использования в проектных презентацияхи отчётах).Передача. В разработке РУП-решения данный этап отсутствовал, так как,во-первых, решение использовалось во время его разработки и в целом былоограничено сжатыми сроками ISS-проекта.
Во-вторых, кроме самих разра316ботчиков и руководителя проекта у решения было еще два пользователя, которые выступали как тестеры решения и на момент окончания разработкивладели полной информацией о правилах использования решения.3175.3 Диаграммная Web-визуализация деятельности правительствагорода МосквыГосударственная программа города Москвы «Информационный город(2012–2016 годы)» была утверждена постановлением правительства Москвы№ 349-ПП от 9 августа 2011 года. В качестве целей этой программы былообозначено повышение качества жизни населения города Москвы за счёт активного использования информационных технологий, а также повышениеэффективности и прозрачности городского управления.
Для обеспечения реализации мероприятий программы был инициирован Системный Проект, посвящённый описанию и оптимизации управленческих процессов правительства города Москвы. Проект подразумевал создание архитектурной модели сиспользованиемEAM-средств,атакжеразработкуинформационно-аналитического портала (см. рис.
5.20), на котором вся информация, собранная и упорядоченная в рамках модели, должна быть представлена для конечных пользователей (чиновников и граждан Москвы) в максимально доступном виде. Проект разрабатывался консорциумом российских организаций воглаве с НИУ ВШЭ, в который входила компания АНО «КМЦ Бизнесинжиниринг» — владелец программно-методической EAM-технологии ОРГМастер.Моделирование происходило в пакете ОРГ-Мастер, портал разрабатывалсяотдельной командой. При этом требовалось представить результаты моделирования на портале, что выполнялось с помощью генератора отчётов ОРГМастера — отчёты генерировались как в таблично-текстовом, так и в диаграммном виде, и после этого размещались на портале.Однако если для таблично-текстовых отчётов хватало имеющихся средствОРГ-Мастера, то для графических отчётов требовались дополнительныесредства — как разработка новых графических нотаций, так и создание соответствующего генератора.
Соответственно, возникала потребность в отдельном проекте, которым и занимался автор диссертационной работы. Этот про318ект был DSM-проектом, так как включал в себя создание новых визуальныхязыков и реализацию соответствующих программных средств.Рис. 5.20. Первая страница порталаВ данном проекте автор выполнил следующие работы: (i) участвовал вразработке графических нотаций для представления информации о государственных функциях органов исполнительной власти, городских процессах,информационных ресурсах и системах города Москвы на аналитическомпортале департамента информационных технологий города Москвы; (ii)предложил использовать для формализации требований к «древовидным»диаграммам упрощённые метамодели, объединяющие в рамках одной спецификации абстрактный и конкретный синтаксис, включая требования к расположению элементов диаграммы; (iii) предложил и реализовал идею динамической декомпозиции диаграмм портала; (iv) разработал архитектуру программных средств.3195.3.1 Язык моделированияКратко опишем структуру модели Системного Проекта.
Эта модель является онтологией (далее в этом разделе термины «онтология» и «модель» будем использовать как синонимы), которая представляет собой систему понятий, созданных для описания деятельности правительства города Москвы.Онтология реализована с помощью классификаторов и проекций ОРГМастера. Содержание онтологии было представлено на портале, в основном,в табличном виде, при этом позиции таблиц раскрываются дальше в видедругих таблиц или набора таблиц.
Для некоторых позиций было предусмотрено также диаграммное представление (предмет рассматриваемого DSMрешения).Разработанную в рамках Системного Проекта онтологию можно разделить на следующие части (которые мы, вслед за [104], будем называть моделями).1. Процессная модель — описывает процессы, выполняемые как внутриодного органа власти, так и несколькими. Кроме процессов, данная модель содержит декомпозицию сфер ведения и государственных функций.2. Модель результативности описывает показатели для оценки эффективности управления городским хозяйством. В эту модель также входит описание ценностей, создаваемых органами управления.3.
Информационная модель описывает информационные сущности, которые используются при управлении городским хозяйством Москвы, атрибуты и связи этих сущностей, а также связь информационных сущностей с процессами и информационными системами. В этой моделитакже описываются информационные ресурсы правительства Москвы(например, различные реестры и регистры).4. Модель информационных систем содержит перечень разрабатываемыхи используемых правительством Москвы информационных систем, а320также паспорт каждой такой системы и описание их функциональныхвозможностей.Дадим определение для ряда элементов онтологии, которые задействованына диаграммах.Сфераведения — этовзаимосвязаннаясовокупностьсоциально-экономических объектов регулирования, находящихся в зоне ответственности определённого органа власти.
Ниже представлен список выделенныхсфер ведения: социальная сфера, образование, семейная и молодёжная политика, регистрация актов гражданского состояния, градостроительный комплекс, имущественно-земельный комплекс, жилищно-коммунальное хозяйство, топливно-энергетическая сфера, природа и экология, транспорт, экономика и финансы, СМИ и реклама, культура и культурное наследие, торговля,труд и занятость, физическая культура и спорт, промышленность, наука иинновации, туризм и гостиничное хозяйство.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
