Наиболее «узким» местом является полная обкатка модели, включая разработанные программные модули анализа, по максимальному количеству вариантов задания исходных данных для инициирующих бизнес-событий. Очевидно, что при количестве вариантов свыше нескольких десятков вероятность, что они все будут пройдены даже при условии формирования большой группы «тестировщиков», мала.
По этой причине актуальным является формирование механизмов автоматизированного тестирования, в рамках которого генерируются случайным образом (либо по заданному порядку) внешние и внутренние события бизнес-процессов:
♦ входные события для модели (внешняя среда);
♦ выборы по принимаемым решениям в точках ветвления бизнес-процесса (внутренняя среда).
В качестве ядра механизма генерации различных сочетаний событий могут использоваться стандартные процедуры для датчиков случайных чисел.
В целом необходимо отметить, что тестирование модели, подобно тестированию любой другой информационной системы, должно осуществляется в соответствии с хорошо зарекомендовавшими себя практиками и стандартами [17].
Обязательным этапом, предваряющим реализацию проектных решений построения модели бизнес-архитектуры, является разработка Соглашения о моделировании – свода единых правил моделирования.
Разработка Соглашения о моделировании
Соглашение о моделировании предназначено как для специалистов исполнителя, знающих принципы моделирования и интерфейс пользователя инструментальной системы, так и для сотрудников заказчика, проводящих экспертизу качества построенных моделей в рамках установленных границ проекта.
В рамках данного документа должны быть зафиксированы цели и задачи проекта, методические и технологические подходы по моделированию бизнес-процессов описываемой предметной области. Соглашение формирует единый язык общения внутри команды проекта и внутри организации заказчика при дальнейшем самостоятельном проектировании бизнес-процессов. Кроме того, позволяет настроить инструментальное средство моделирования для эффективной работы пользователей и последующей корректной генерации отчетов.
В рамках Соглашения целесообразно «зафиксировать» следующие основные вопросы проектирования модели.
♦ Концепция проекта. В данном разделе необходимо отобразить общую концепцию проекта, а именно указать цели и задачи проекта моделирования, используемые инструментальные средства поддержки, методологические подходы к построению бизнес-архитектуры, возможные ограничения при этом.
♦ Определение уровней моделирования. При определении уровней моделирования необходимо исходить из принципа разумной достаточности, то есть решение не должно быть слишком сложным по сравнению с самой решаемой задачей.
♦ Определение чувствительности моделей. В данном разделе уточняется, на что и каким образом будет реагировать создаваемая модель, то есть определяется набор входных параметров (параметров различий) модели и предлагаемый вариант реализации учета этих различий (чувствительности) моделей.
♦ Структура хранения моделей в базе данных. Элементы проекта, такие как модели и объекты (активности), желательно структурировать в определенные папки проекта в инструментальной среде.
При создании иерархии папок возможно использование нескольких критериев:
♦ согласно этапам проведения проекта;
♦ согласно процессно-ориентированной структуре;
♦ согласно функциональной структуре компании;
♦ согласно описываемым предметным областям;
♦ комбинации указанных выше критериев.
В данном разделе указываются выбранные критерии построения и непосредственно общая структура папок.
♦ Выбор моделей, используемых в проекте. Для обеспечения единой идеологии моделирования в рамках каждого проекта необходимо определиться с используемыми типами моделей. Выбор моделей напрямую зависит от целей проекта и ожидаемого результата, так как типы моделей представляют собой различные методы моделирования, они могут как дополнять друг друга, так и являться альтернативой друг другу.
♦ Спецификация типов объектов и используемых символов. Для обеспечения единой идеологии моделирования также необходимо определиться с используемыми типами объектов выбранных моделей. Данный выбор объектов осуществляется на основе поставленных целей моделирования и знаний таких основ, как:
– каждый тип объекта несет свое определенное значение в методологии и имеет специфические характеристики, определяющие конкретный объект данного типа;
– каждый тип объекта может использоваться в одном или нескольких типах моделей;
– каждый тип объекта может быть представлен одним или несколькими символами.
Также необходимо указать, на какие типы моделей могут быть детализированы те или иные типы объектов.
♦ Спецификация используемых типов связей. Типы связей определяют возможные взаимоотношения между объектами. В данном разделе необходимо указать, какие типы связей и между какими объектами будут использоваться в проекте.
Данный выбор типов связей осуществляется на основе поставленных целей моделирования и знаний таких основ, как:
– один и тот же тип связей между типами объектов может присутствовать в нескольких типах моделей;
– между двумя объектами может быть проведено несколько связей различного типа.
♦ Спецификация поддерживаемых типов атрибутов. Выбор типов атрибутов зависит от решаемых в рамках проекта задач, например для проекта по оптимизации продолжительности выполнения процессов необходимо задавать значения времени выполнения отдельных функций, а для других проектов этот атрибут использовать не имеет смысла. Участник проекта должен видеть только те атрибуты, которые он обязан задать, однако при этом некоторые из атрибутов могут быть необязательными, что и оговаривается в принимаемых Соглашениях о моделировании по проекту.
Выбор типов атрибутов основывается на знании того, что:
– каждый тип модели, объекта или связи обладает специфичным набором атрибутов;
– есть набор атрибутов, существующий у каждого типа модели, объекта или связи, например: Имя, Полное имя, Описание, Автор и др.;
– другие атрибуты могут существовать только для определенных типов модели, объекта или связи, например «Количество сотрудников» для объекта Подразделение.
♦ Определение соглашений по присвоению имен. В рамках проекта объекты зачастую идентифицируются при помощи их имен. Строгие правила присвоения имен объектам повышают целостность проекта, увеличивают удобство чтения моделей, облегчают поиск объектов в базе. Правила именования должны стать стандартом проекта и быть доведены до сведения каждого участника. Правила именования должны быть определены для каждого используемого типа объектов. Различают синтаксический и семантический аспекты задания правил именования.
Пример синтаксического аспекта наименования функции: «Проверка документов» – имя должно состоять из двух обязательных частей – отглагольного существительного, описывающего выполняемую функцию, и существительного, показывающего объект, над которым она выполняется.
Сам по себе синтаксический аспект именования не может гарантировать единства названий в проводимом проекте. Одно и то же действие может быть названо несколькими способами с использованием слов, близких по смыслу. Например, «Создать договор» и «Составить договор». Для решения данной проблемы целесообразно составить глоссарий терминов, которые должны быть использованы при задании имен объектам.
♦ Определение соглашений по графике. В данном разделе могут быть заданы правила взаимного расположения объектов на модели. Например, для иерархических моделей определяется, начиная с какого уровня иерархии происходит переход с горизонтального расположения объектов на вертикальное. Для моделей процессов определяется расположение графа – горизонтально или вертикально. Помимо этого, для удобства восприятия создаваемых моделей, возможно, потребуется установить ряд правил графического расположения определенных типов объектов и связей. Например:
– расположение последовательности событий и функций сверху вниз, то есть входящие стрелки в функцию должны быть расположены сверху, а исходящие стрелки из функции – снизу;
– потоки данных отображаются слева от функции, где входные документы (данные), обрабатываемые или используемые функцией, изображаются слева от функции входной стрелкой, а исходящие документы (данные), генерируемые функцией, изображаются слева от функции исходящей стрелкой;
