CC BY
144
УДК: 004.896 ББК: 32.97-018.2
Куралесова Н.О.
МЕТОДЫ И МОДЕЛИ ФОРМИРОВАНИЯ ТРЕБОВАНИЙ АРХИТЕКТУРЫ
ПРЕДПРИЯТИЯ
Kuralesova N.O.
METHODS AND MODELS OF FORMATION OF REQUIREMENTS OF ENTERPRISE ARCHITECTURE
Ключевые слова: архитектура предприятий, модель требований, принципы формирования требований
Keywords: architecture enterprises, model requirements, the principles of formation of the requirements
Аннотация: в статье рассмотрен набор данных, описывающих функционал предприятия, определены методы и технологии их обработки, конкретизированы требования, формирующие архитектуру предприятия.
Absttact: in the article the data set describes the functionality of the enterprise, defined methods and technologies of their processing, specified requirements forming enterprise architecture.
Существующие технологии
моделирования архитектур предприятий имеют общую слабо решаемую задачу, а именно - определение требований к модели предприятия. Типовыми критериями построения модели являются: используемые данные; процессы и функции; места выполнения этих процессов и функции; организация, участники, компоненты; управляющие события; цели и ограничения, определяющие работу модели как системы. Специфика моделирования с учетом современных тенденций в развитии бизнеса и информационных технологий,
обеспечивающих его поддержку определена концепцией понятия «архитектура предприятия». Так в документах Финансово-контрольного управления США: «Архитектура предприятия описывает деятельность организации с двух позиций: с позиции логических терминов, таких как взаимодействующие бизнес-процессы и бизнес-правила, необходимая информация, структура и потоки информации, места расположения работы и пользователей; с позиции технических понятий, таких как аппаратные и компьютерные средства, программное обеспечение, коммуникация данных, защита и безопасность, а также используемые стандарты». На сайте Всемирной организации корпоративной
архитектуры» (GEAO - Global Enterprise Architecture Organization): «Архитектура предприятия описывает те способы, с помощью которых общее видение деятельности организации отражено в структуре и динамике предприятия. На различных уровнях абстракции она дает единый набор моделей, принципов, руководств и политик, которые используются для создания, развития и обеспечения соответствия систем в масштабе и контексте деятельности всего предприятия в целом». Оба определения приводят к решению построения архитектуры предприятия, но с разных концепций формирования для них базового набора требований (от формальных структурно-функциональных, до
взаимосвязей между различными моделями архитектуры).
Если считать, что архитектура предприятия определяет: структуру; поведение; наборы элементов; логическое обоснование решений; влияние ресурсов; используемые шаблоны; согласованность с внешней средой, то при решении задач определения базового набора требований необходимо анализировать множества стратегий деятельности, собственных параметров предприятия как системы, влияние внешних факторов на собственные
параметры системы (что включает модель Захмана).
Формирование таких множеств связано со слабоформализуемыми данными. В качестве основного инструмента обработки такого рода данных достаточно эффективно могут быть использованы методы и технологии нечеткой математики.
В настоящее время использование нечеткой математики приобрело
практическую направленность. При этом многие алгоритмы обработки нечетких данных легли в основу создания обширной базы информационных технологий. На принципах использования Fuzzy-технологии существуют ряд продуктов зарубежных фирм: Management Intelligenter TecRnologien GmbH, Fuzzy Logic Inc. Fuzzy Systems Engineering, консалтинговой компанией "ИНЭКС" и IDM Ltd Co - Fuzzy Calculator (FC), Fuzzy for Excel (FE), Expert Professional (ExPro), Data Engine (DE, Fuzzy Estimation of Critical Messages (FECM), МаркетЭффект (МЭ) и др.
Областью применения этих программных продуктов являются процессы поддержки принятия решений, где приходится иметь дело с информационной неопределенностью, с недостатком или недоверием к информации. Применение их наиболее эффективно в случае:
- недостаточной статистической информации либо когда эта информация не вызывает должного доверия;
- недостаточного объема или качества исходной информации;
- если информация только вербальная,
экспертная;
- если информация разнородна по источникам и составу (словесная и числовая);
- если необходимы прогнозы при неполных факторах;
- если предстоит анализировать риски.
Такие продукты можно рассматривать
как специализированные программные среды, позволяющие моделировать различные предметные области сложных динамических объектов. Базовая модель такого подхода, представлена на рисунке 1.
Основной проблемой использования Fuzzy-технологий является отбор факторов влияния на моделируемую систему или процесс, а так же оценка объектов предметной области как формальное описание концептуальной модели.
Оценки объектов находятся под влиянием внешних факторов, сила и состав которых меняются во времени. Эти факторы по отношению к текущему моменту времени разделяются на факторы прошедшего периода времени и будущего периода времени. Отображением факторов прошлого являются различного рода статистические данные, которые могут использоваться также для задания числовых характеристик объектов.
Факторы будущего отражают взгляды аналитика на динамику процессов и оценок объектов. Факторы будущего могут иметь различную физическую природу, но они могут быть описаны рядом общих прогнозных параметров: временем существования, силой проявления, важностью и возможностью влияния.
Рисунок 1 - Базовая модель определения требований
Такое представление позволяет моделировать широкий спектр возможных вариаций факторов будущего. Таким образом, набором исходных данных являются:
- набор характеристик оцениваемых объектов модели;
- система критериев оценки и предпочтений, отбора альтернатив;
- описание внешних факторов.
Оценка объектов предметной области - более
сложная задача, опирающаяся на следующую последовательность:
- классификация и анализ требований элементов и связей;
- согласование и обоснованность требований;
- описание специализаций требований объектов и связей;
- установление метрик и измерения (временная шкала);
- построение модели объектов;
- построение модели поведения;
- построение модели взаимосвязи объектов.
Классификация требований
использует три признака:
- признак требований к данным;
- признак функциональных требований;
- признак динамических требований.
В сравнении с другими этапами
разработки архитектуры предприятия установление требований -
взаимоувязывание технологических,
коммуникативных и управленческих компонентов (рисунок 2). Недостаточно тщательное выполнение этого этапа может привести к более серьезным последствиям, чем в случае с другими этапами.
Принципы установления требований определяют услуги, ожидаемые от системы (формулировки сервисов) и ограничения, которым система должна подчиняться (формулировки ограничений).
Формулировки сервисов можно объединить в три группы: группа границ системы, вторая - необходимые бизнес-функции (функциональные требования), а третья -требуемые структуры данных (требования к данным).
Выявление требований,
осуществляется различными методами: традиционными и современными (следуя Хофферу). Например, бизнес-аналитик определяет требования к системе посредством консультаций, к участию в консультациях привлекаются заказчики и эксперты в проблемной области. Требования, выявленные с помощью эксперта предметной области, составляют основу знаний о предметной области. Задача бизнес-аналитика состоит в том, чтобы объединить все наборы требований в бизнес-модели. Это вносит дополнительную неопределенность.
В общем случае, в нотациях ЦМЪ объекты предметной области (бизнес-классы) не должны выводиться из прецедентов. Однако на практике правильность модели бизнес-классов должна подтверждаться посредством сравнения с моделью бизнес-прецедентов. Это сравнение, как правило, приводит к уточнению настройки или расширения модели бизнес-классов.
Рисунок 2 - Взаимные влияния моделей процесса определения требований
Эффективность традиционных
методов обратно пропорциональна рискам системы. Высокий риск означает, что систему трудно реализовать - не вполне ясны даже обобщенные требования. Для таких проектов традиционных методов не достаточно.
К современным методам выявления требований относится использование программных прототипов, а также такие методы, как «совместная разработка требований» и «быстрая разработка требований». Эти подходы предлагают более глубокий анализ набора требований за счет дополнительных временных затрат. Применение современных методов также связано с дополнительным риском. К ним относятся неясные цели,
недокументированные процедуры,
нестабильные требования, неопытные разработчики и т.д.
Прототип представляет собой демонстрационную систему - "наскоро и грубо" сделанную рабочую модель решения, которая моделирует поведение системы при инициировании
исследователем различных событий.
Требования, полученные от объектов, могут дублироваться или противоречить друг другу. Некоторые требования могут быть неясными или нереальными. Другие требования могут остаться невыясненными. По этой причине прежде, чем требования попадут в документ описания требований, их необходимо согласовать.
В действительности согласование и проверка обоснованности требований
осуществляется параллельно с выявлением требований. Далее они подвергаются определенному уровню проверки. Для всех современных методов выявления требований, которые связаны с так называемой "групповой динамикой", это вполне естественно. Как бы там ни было, после того как выявленные требования собраны вместе, они в любом случае должны быть подвергнуты тщательному обсуждению и проверке.
Для проверки обоснованности требований необходима более полная версия документа, в котором все требования четко идентифицированы и
классифицированы. Детализированные взаимозависимости между системами могут быть раскрыты только на этапе анализа требований. Установление границ системы (системных рамок) - задача этапа анализа требований, так что проблема "растягивания рамок" может решаться на ранних этапах процесса разработки как составная часть этой задачи.
зависимости требований собой простой, но метод обнаружения перекрытий, когда
требований относительно
Матрица представляет эффективный противоречий количество
невелико. В противном случае описанный метод все же можно применить, если удается сгруппировать требования по категориям, а затем сравнить их отдельно в пределах каждой категории.
После того, как в результате снятия противоречий и устранения повторов в требованиях выработан пересмотренный
набор требований, их необходимо подвергнуть анализу рисков и назначить им приоритеты. Анализ рисков направлен на идентификацию требований, которые являются потенциальными источниками трудностей в разработке. Назначение приоритетов необходимо для того, чтобы обеспечить возможность без труда изменить рамки проекта в случае возникновения непредвиденных задержек.
Требования могут быть
"рискованными" вследствие влияния различных факторов. Требованиям свойственны следующие типичные виды рисков:
- технический риск, когда требование технически трудно реализовать;
- риск, связанный со снижением производительности, когда требование -будучи реализовано - может неблагоприятно сказаться на времени реакции системы;
- риск, связанный с нарушением безопасности, когда требование - будучи реализовано - может создать бреши в защите системы;
- риск, связанный с процессом разработки, когда для реализации требования необходимо использование специфичных методов разработки, незнакомых разработчикам (например, методов формальной спецификации);
- риск, связанный с нарушением целостности данных, когда требование не может быть легко проверено и может привести к противоречивости данных;
- политический риск, когда требование может оказаться трудно выполнить по внутриполитическим причинам;
- риск, связанный с нарушением законности, когда требование может привести к нарушению действующих законов или ожидаемого изменения закона;
- риск, связанный с изменчивостью, когда требование может потенциально изменяться или эволюционировать в течение процесса разработки.
В идеале приоритеты требованиям назначают отдельные заказчики в процессе выявления требований. Затем они согласовываются на совещаниях и снова изменяются после приложения к ним
факторов риска.
Для исключения неопределенности и облегчения назначения приоритетов, количество групп приоритетов не должно быть слишком велико. Их можно обозначить как "высокий", "средний", "низкий" и "неопределенный".
Дополнительно следует учесть управление требованиями, что в действительности представляет собой часть общего управления процессом
моделирования архитектуры. Это связано с тремя основными вопросами реализации модели определения требований:
1. Идентификация, классификация, организация и документирование требований.
2. Изменение требований (с помощью процессов, которые устанавливают способы выдвижения, согласования, проверки достоверности и документирования неизбежных изменений к требованиям).
3. Мониторинг требований (с помощью процессов, которые поддерживают отношения взаимозависимости между требованиями. И другими системными артефактами, а также, собственно, между требованиями).
Идентификация требований
описывается на естественном языке.
Типовая модель может состоять из сотен или тысяч формулировок требований. Для надлежащего управления таким огромным количеством требований можно использовать в качестве схемы идентификации дескрипторные таблицы. Схема может включать классификацию требований в виде групп, которые легче поддаются управлению.
Существующие методы
идентификации и классификации требований, такие как:
- уникальный идентификатор - обычно последовательный номер, присвоенный вручную или сгенерированный с использованием базы данных CASE-средства, в которой CASE-средства хранят факторы, выработанные в результате анализа;
- последовательный номер внутри, иерархии документа - присваивается с учетом положения требования в пределах
документа описания требований;
- последовательный номер в пределах категории требований - присваивается в дополнение к мнемоническому имени, которое обозначает категорию требований (где под категорией требований подразумевают функциональное
требование, требование к данным, требования к производительности, требования к безопасности и т.д.)
Каждый из этих методов идентификации обладает как плюсами, так и минусами.
Часть способны дополнительно поддерживать сопровождение нескольких версий одной и той же записи (за счет расширения значения уникального идентификатора с помощью номера версии). Наконец, данные идентификации могут обладать возможностями поддержки ссылочной целостности связей между объектами моделирования, включая требования, и могут, таким образом, обеспечить необходимую поддержку управляемости и прослеживаемости требований.
Упорядочивание требований в виде иерархической структуры, представляющей отношение родитель-потомок, позволит упростить процесс формализации и декомпозиции модели требований. Иерархические отношения позволяют ввести дополнительный уровень
классификации требований, что может непосредственно отражаться (или не отражаться) в идентификационном номере (с помощью использования точки в записи составного имени).
Иерархии требований позволяют определять требования на различных уровнях абстракции. Это согласуется с общим принципом моделирования, в соответствия с которым при переходе к более низкому уровню абстракции модели систематически обогащаются все новыми деталями. В результате для родительских требований можно сконструировать обобщенные требования, а
детализированные модели можно связать с дочерними требованиями. Что позволит завершить цикл формирования требований.
Формализация процесса определения
требований моделирования архитектуры предприятия и реализация его в программных продуктах позволят повысить эффективность процесса построения модели архитектуры предприятия.
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Куралесова, Н.О. Анализ неопределенности в моделях сбора, хранения и передачи информации // Наука - производству. - №11. - 2003.
2. Куралесова, Н.О. Модель отбора решений о формировании организационной структуры // Экономика и производство. - №1. - 2005.
3. Куралесова, Н.О. Имитационное моделирование организационных процессов // Вестник Волжского университета им. В.Н. Татищева. Серия «Информатика». Вып. 12. -Тольятти: Издательство Волжского университета им. В.Н. Татищева, 2009.
4. Куралесова, Н.О. Формирование принципов проектирования организации процесса слабоформализованного объекта // Вестник Волжского университета им. В.Н. Татищева. Серия «Информатика». Выпуск 18. -Тольятти: Издательство Волжского университета им. В.Н. Татищева, 2011.
5. Лешек, А. Мацяшек. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML. - М.: Вильямс, 2002.
6. Стандарт IEEE 1471-2000. Рекомендации IEEE по архитектурному описанию преимущественно программных систем.
7. О' Рурк, Кэрол, Нил, Фишман и Уоррен, Селкоу. Архитектура предприятия на основе структуры Захмана. - Бостон, штат Массачусетс: Технология курса, 2003.
