Диссертация (1145120), страница 48
Текст из файла (страница 48)
5.10. Архитектура продукта ОРГ-МастерКомпонента «Поддержка моделей» включает в себя кроме стандартныхфункций открытия/закрытия модели ещё также импорт/экспорт модели вформатах XML/Excel, возможность задания свойств и настроек режимовдоступа к элементам модели и средствам их редактирования, операциюслияния двух версий модели, поддержку опорных моделей (создание моделина основе некоторой существующей).Компонента «Поддержка классификаторов» включает в себя средствасоздания классификаторов и позиций, а также их многочисленных свойств.При этом, поскольку объёмы классификаторов оказываются большими — донескольких сотен позиций, — то реализованы различные дополнительныесредства для удобства работы с этими массивами информации, например,возможность отмечать несколько позиций (не обязательно идущих подряд) иподдержка дополнительных операций с отмеченными позициями.
Кроме66DevExpress, https://www.devexpress.com/.293того, поддерживается импорт/экспорт классификатора в различные внешниеформаты.Компонента «Поддержка проекций» включает в себя средства для работыс проекциями и связями. Основная сложность этой компоненты —поддержка удобного функционала для работы с многомерными проекциями(то есть проекциями, связывающими более чем два классификатора), которыеактивно используются аналитиками, работающими с ОРГ-Мастером.Компонента «Метаредактор» позволяет создавать расширения на основебазового языка моделирования ОРГ-Мастер с помощью типов — позиций,связей, а также свободных атрибутов. Кроме того, сюда же входитвнутренний редактор, предназначенный для создания схемы модели.
Такимобразом, именно здесь появляются основные сущности предметной области,с которыми далее происходит работа в КИТ-проекте, выполняемом спомощью ОРГ-Мастера.Компонента «Генератор отчётов» предназначена для создания схемыотчётов, а также конкретных отчётов в соответствии с этими схемами.Компонента включает функционал по созданию схемы выборки, а также погенерации отчётов в различных выходных форматах.Компонента «Поддержка плагинов» позволяет создавать дополнительныесервисы для ОРГ-Мастера и встраивать их в интерфейс продукта,обеспечивая доступ к модели ОРГ-Мастера через специальный программныйинтерфейс.Компонента «Внешние редакторы»реализует функциональность поподдержке графических средств работы с моделью ОРГ-Мастера на базеMicrosoft Visio.
Остановимся подробнее на одном таком редакторе.Редактор BPMN является отдельно подключаемым модулем, имеетсобственный инсталляционный пакет и подключается к ОРГ-Мастеру черезинтерфейс плагинов.294бавРис. 5.11. BPMN-редактор: начало работыПосле его установки в панели ОРГ-Мастера «Диаграммы» появляетсяотдельная позиция под названием «Диаграммы BPMN» — см.
рис. 5.11, а.При попытке создать новую модель будет предложено автоматически создатьсоответствующие классификаторы и проекции в модели (схема этихклассификаторов представлена на рис. 5.7), которые выступают в ролирепозитория для BPMN-модели — см. рис. 5.11, б. После этого будет созданазапрашиваемая BPMN-модель (см. рис. 5.11, в).295Рис.
5.12. Работа в Microsoft VisioРис. 5.13. Репозиторий редактора бизнес-процессов в ОРГ-Мастере:классификатор «Элементы потока управления»2965.1.3 Метод использованияОРГ-Мастер предназначен, в первую очередь, для использованияаналитиками компании-заказчика при реализации КИТ-проектов. Именноаналитики были основным источником требований к продукту. Крометого, поскольку в КИТ-проектах принимают участие также представителикомпаний, для которых создаётся архитектура, то они также должныиметь возможность моделировать. Для того чтобы облегчить последнимввод данных в модель, служат внешние редакторы.
Наконец, данныйпродукт может использоваться аналитиками компании для поддержкиописаний архитектуры уже после завершения КИТ-проекта, созданного спомощьюОРГ-Мастера,хотяследуетотметить,чтоосновныминтерфейсом между заказчиком и КИТ-проектом являются отчёты,представляющие созданные описания в виде документов и рисунков. Поканепредполагается,чтопродуктбудетраспространятьсякак«коробочный», хотя созданная версия является хорошей основой длякоробочного продукта.5.1.4 Программная интеграция с другими средствамиМодели можно импортировать/экспортировать в XML-формате. Эта возможность используется для совместимости с предыдущей версией продукта,а также для автоматизированной обработки модели сторонними средствами,например, при размещении модели на Web-портале.
Классификаторы можноэкспортировать в Excel и Word. Отчёты можно экспортировать в HTML, Excel, Word (речь идёт об обычных, не диаграммных отчётах). Кроме того, какбыло подробно описано выше, продукт интегрирован с Microsoft Visio дляреализации концепции внешних графических редакторов.2975.1.5 Разработка, поддержка и сопровождениеПроект выполнялся три года командой из пяти человек при активном участии аналитиков заказчика (разработка требований, выполнение пользовательского тестирования).Выработка концепции.
На данном этапе были конкретизированы основные задачи проекта и выбраны приоритеты, исходя из потребностей заказчика, требований больших КИТ-проектов (текущих и будущих), а также ограничений на бюджет. В связи с этим был также согласован бюджет проекта.Первоначально планировалось выполнить проект силами компании заказчика: в компании уже работали программисты, и планировалось нанять дополнительных людей для реализации проекта. Однако автору удалось убедитьруководство компании в том, что к разработке проекта лучше привлечь готовую профессиональную команду, а после окончания проекта выполнить передачу результатов программистам компании.
В качестве решающего аргумента выступил тот факт, что компания заказчика специализируется на бизнес-инжиниринге, а не на разработке ПО, поэтому данной компании будетсложно организовать эффективный процесс разработки. Ещё одним аргументом было то, что предлагаемая команда имела опыт в проектировании иразработке средств визуального моделирования. В рамках данной фазы былотакже определено, кто занимается разработкой требований к системе — каксо стороны заказчика, так и со стороны команды разработчиков.
Были такжеопределены тестировщики системы со стороны заказчика (в их роли выступили два аналитика компании). В качестве рисков был выделен тот факт, чтопри многочисленных требованиях к продукту исходная документация почтиполностью отсутствовала: в рамках проекта команда разработчиков должнабыла разобраться в функционале существующего продукта и модифицировать его надлежащим образом, при этом создав и согласовав с заказчикомновый пользовательский интерфейс. Второй риск заключался в том, заказчикне был готов к кропотливой работе над документами, составляющими техни298ческое задание.
Финальный документ имел объем около ста страниц, представители заказчика прочитали его лишь один раз. В такой ситуации былавелика вероятность различного понимания тех или иных свойств/группсвойств продукта при сдаче проекта.Планирование. В рамках этого этапа были выполнены необходимые модернизации языка моделирования, выполнен выбор технологий разработки (втом числе был выбран продукт Microsoft Visio для реализации дополнительных средств визуального моделирования), а также создано техническое задание.
Разработка технического задания на весь проект и обоснование технологий реализации продукта было выполнено в рамках отдельного этапа. В рамках этого этапа был разработан каркас будущего продукта, который включалв себя реализацию репозитория, общий макет среды моделирования и пользовательского интерфейса, реализацию простейших методов работы с классификаторами и проекциями, а также чтение XML-представления модели(для интеграции с предыдущей версией продукта).Разработка.
Для реализации созданного технического задания было выполнено три итерации. Результаты каждой итерации принимались тестировщиками-аналитиками заказчика. В рамках приёма результатов первой итерации были проблемы с разночтениями технического задания — тестировщикине участвовали в его разработке и руководствовались в большей степени своим опытом, чем принятыми соглашениями. В связи с этим возник большойобъем доработок, которые были предъявлены команде как ошибки, которыенеобходимо исправить в рамках данной итерации. Однако эти проблемы удалось решить — часть недоработок команда исправила в рамках этой итерации, а часть были перенесены на следующую. Потом была выполнена стабилизация продукта: реализован и отлажен импорт прежних моделей в новоесредство, создан инсталляционный пакет, оказана консультативная помощьпри переносе и первых шагах в использовании продукта, исправлены самые299срочные ошибки, препятствующие использованию продукта.
Дальнейшаяразработка продукта проводилась параллельно с его использованием.Разработка и использование. На этом этапе было выполнено ещё двеитерации. В первой итерации, кроме исправления большого числа ошибок инедочётов, был также реализован алгоритм слияния моделей. В рамках второй итерации были реализованы и интегрированы в ОРГ-Мастер средстваграфического моделирования бизнес-процессов. Эти итерации проходилиболее гладко, чем итерации предыдущего этапа: во-первых, основной функционал был уже реализован и принят заказчиком, во-вторых, уже был налажен процесс взаимодействия команды разработчиков и заказчика, основывающийся на взаимопонимании.
Последний фактор нельзя назвать напрямуюпринадлежащим программной инженерии, однако он очень важен: не всеудаётся в процессе разработки решить методами, документами и договорённостями — многие трудности решаются взаимопониманием, если оно наступает. В данном случае взаимопонимание было достигнуто.Передача. Ещё на предыдущих этапах заказчик создал группу поддержкии сопровождения из программистов, имевшихся в штате компании. Во времявыполнения предыдущих этапов проекта эти программисты вместе с другимиработами занимались также знакомством с кодом проекта и его инфраструктурой. На данном этапе они были освобождены от других задач и стали активно заниматься DSM-проектом.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
