Анализ требований, бизнес-анализ, анализ проблемной области
В настоящее время существуют уже сотни методик, методологий, процессов, стандартов, регламентирующих те или иные детали выбора и комплексирования потоков работ при разработке автоматизированных информационных систем. То, что АТ стоит в начале цепочки работ и что ее результаты во многом определяют успех проекта, мало у кого вызывает сомнения. Другое дело - работы, связанные с бизнес-анализом и бизнес-моделированием. Их роль не столь очевидна и принимается далеко не всеми методологиями. Итак, стоит ли собирать информацию о предприятии, для которого разрабатывается (выбирается) АИС в виде бизнес-моделей или стоит пропустить этот этап и сразу формировать артефакты АТ?
Авторы [5.1], "отцы-основатели" RUP и UML, в этом вопросе дают определенную свободу: можно создавать бизнес-модели при помощи соответствующих расширений UML и рекомендаций RUP, а можно ограничиться выработкой глоссария объектов предметной области. Как и в вопросе выбора глубины проработки артефактов АТ, вопрос - проводить или не проводить бизнес-анализ (или, точнее говоря, анализ проблемной области), решается в зависимости от конкретной задачи.
Роль глоссария при АТ.
Несколько утрируя, можно сказать, что Заказчик и Разработчик всегда говорят на разных языках. Общее понимание вырабатывается с трудом, этот процесс занимает время, но важность его трудно переоценить: ведь успешная реализация проекта в области внедрения АИС во многом зависит от того, удастся ли выработать и документировать их общее представление о предмете разработки. Если же Разработчик идет еще дальше и вникает в особенности ведения дел на предприятии Заказчика - он, во-первых, сможет добиться лучшего понимания требований к АИС и, во-вторых, участвовать наряду с Заказчиком в формулировке этих требований, анализе пропущенных требований и пр. Глоссарий (подробнее см. в "Классификация и специфицирование требований" ) можно рассматривать как документ, удостоверяющий общее понимание основной терминологии Заказчиком и Разработчиком.
|
|
|
Задачу анализа бизнес-процессов (деловое моделирование), столь популярную в последние десятилетия ввиду устойчивой конъюнктуры, следует рассматривать как часть более общей задачи систем для анализа проблемной области. Работы, посвященные анализу проблемной области, появились в отечественной литературе в середине прошлого века; данная тематика неразрывно связана с задачным подходом и инженерией экспертных систем. Применимы ли методы, принятые при построении интеллектуальных систем для такой, "более приземленной" задачи, как задача построения АИС - безусловно, да. Так, стратегии извлечения знаний, рассмотренные в [5.2], во многом пересекаются с рекомендациями по работе аналитика [5.3], методы решения задачи путем редукции на подзадачи и поиска в пространстве состояний нашли свое отражение во множестве методик бизнес-анализа, анализа и синтеза программных систем, и этот список можно продолжать. Другой вопрос - насколько результативно применение тех или иных моделей и методов при описании организационных систем.
|
|
|
Ключ к решению этого вопроса лежит в следующем: вначале надо определить цели и задачи самого бизнес-анализа, как этапа построения КИС.
С позиций моделирования, анализ требований (АТ) и анализ проблемной области (АПО) - принципиально разные процессы.
АПО преследует классические цели создания модели: налицо объект (автоматизируемое предприятие или организационная система, ОС) и задача аналитика - отразить этот объект в создаваемой модели с требуемой степенью точности (рис. 5.1).
Анализ требований, напротив, направлен на моделирование воображаемого, еще не существующего объекта (АИС) (рис. 5.2). Т.е. сначала создается модель, а затем, на ее основании, синтезируется объект.
Для того, чтобы прояснить связь между этими процессами, необходимо заметить, что создаваемая АИС также является моделью по отношению к ОС. Таким образом, создавая документ АТ, мы тем самым порождаем как бы "модель второго порядка", т.к. документ АТ является ничем иным, как моделью модели ОС. Не обладая моделью АПО, мы, конечно, можем создать модель АТ. Но при этом мы рискуем тем, что при синтезе оригинала модели (т.е. АИС), не обладая знаниями об ОС, мы можем попасть в ситуацию рассогласования: результирующая АИС не будет ингерентна (согласована с) ОС и, тем самым, не станет жизнеспособной.
|
|
|
Рис. 5.1.
Следует ли из этого, что этап АПО является необходимым звеном создания КИС? Нет, не всегда. Здесь уместно обратиться к классификации задач и методологий А. Коберна [5.4]. Кроме того, это зависит от состава третьей компоненты "треугольника моделирования" - моделирующего субъекта, в нашем случае - коллектива Разработчика. Если моделирующий субъект обладает неявными знаниями об ОС в достаточном объеме - значит, АПО можно исключить. На практике это возможно в следующих случаях:
· Разработчик является частью (структурным подразделением, дочерним предприятием и т.д.) ОС, в коллектив Разработчика входят эксперты, хорошо знающие предметную область;
|
|
|
· Заказчик наравне с Разработчиком участвует в создании документа АТ и разделяет с ним ответственность за принятие решений. Это - путь "agile методологий" (см. материалы "Требования в управлении проектом" ).
Рассмотрим теперь обобщенную "формулу" создания АИС. ОС->М(ОС)->М(АИС)->М'(АИС)->М''(АИС)->М'''(АИС)->АИС (рис. 5.1).
Анализ организационной системы позволяет создать ее модель М(ОС). Это - модель бизнес-анализа (проблемной области).
Анализируя модель проблемной области, в ней можно вычленить,
· с одной стороны, задачи и функции, реализуемые внутри ОС и функции коммуникации ОС и среды,
· с другой - устройство предметной области (в начале - на уровне концептуальной модели),
· с третьей - требования к информации и ее обработке.
Выделив среди функций те, которые подлежат автоматизации, мы получаем основу для выявления функциональных требований к системе. Остальная собранная на этапе АПО информация служит для поиска нефункциональных требований. В результате получаем модель АТ, как первое приближение модели АИС, М(АИС).
Затем, путем углубленного анализа и проектирования, формируются, соответственно, аналитическая модель М'(АИС), проектная модель М''(АИС) и модель реализации М'''(АИС).
Модель уровня реализации позволяет синтезировать собственно АИС, как совокупность программных, информационных, организационных и др. артефактов.
АИС в свою очередь представляет собой модель организационной системы М'(ОС), замыкая цикл моделирования.
Методологии бизнес-анализа
Методологии бизнес анализа можно разделить на три категории по типам моделей:
· модели, преследующие цель анализа и улучшения организационной системы (например, SWOT , VCM, BPR, CPI/TQM/ISO9000, BSC),
· модели общего назначения, такие, как SADT, DFD, IDEF1, IDEF3, IDEF5 и другие,
· модели, специально разработанные для использования при автоматизации (например, ISA, BSP, ARIS, RUP).
CPI (Continuous Process Improvement) - непрерывный процесс усовершенствования [41]. Относится ко всем аспектам деятельности компании; предусматривает постоянный поиск способов улучшения работы организации и использование этих способов для совершенствования продукции компании, создания более благоприятного рабочего климата на предприятии и т. п.
ISO (International Organization for Standardization) - Международная организация по стандартизации, ИСО, http://www.iso.org/iso/ru. Является одной из самых крупных и значимых организаций, занимающейся разработкой международных стандартов. Членами ИСО являются национальные органы по стандартизации (в том числе – российский), которые представляют интересы своей страны в ИСО, а также представляют ИСО в своей стране.
Наиболее развитая модель описания проблемной области предлагается в методологии ARIS.
ARIS (Architecture of Integrated Information Systems) [24] — архитектура интегрированных информационных систем. Методология и CASE-средство для моделирования бизнес-процессов организаций c целью их автоматизации от компании Softwareag http://www.softwareag.com/corporate/products/aris. Основные черты методологии - поддержка 5 различных, но взаимосвязанных между собой точек зрения на предприятие; наличие сверхмощного, не имеющего аналогов графического языка, насчитывающего десятки различных диаграмм и сотни специальных символов для всевозможных аспектов деятельности предприятий и его автоматизации. Сюда вошли многие наработки из мирового арсенала бизнес-моделирования, инкапсулирован также и UML. Наиболее известная диаграмма ARIS – EPC.
CASE (Computer Aided Software Engineering) – набор инструментов и методов, позволяющих автоматизировать отдельные этапы жизненного цикла программной инженерии. Согласно IEEE STD.620.12-1990, CASE – это "использование компьютеров, способствующее процессу программной инженерии; может включать приложения программных средств для проектирования, трассировки требований, генерации кода, тестирования, генерации документации и других действий программной инженерии".
Архитектура ARIS [5.5] выделяет в организации следующие подсистемы.
· Организационная. Определяет структуру организации - иерархию подразделений, должностей и конкретных лиц, многообразие связей между ними, а также территориальную привязку структурных подразделений.
· Функциональная. Определяет функции, выполняемые в организации.
· Подсистемы входов/выходов. Определяют потоки используемых и производимых продуктов и услуг.
· Информационная (подсистема данных). Описывает получение, распространение и доступ к информации (данным).
· Подсистема процессов управления. Определяет логическую последовательность выполнения функций посредством событий и сообщений. Можно сказать, что подсистема управления - это совокупность разнесенных во времени сообщений разного рода.
· Подсистема целей организации. Описывает иерархию целей, достигаемых в ходе выполнения того или иного процесса.
· Подсистема средств производства. Описывает жизненный цикл основных и вспомогательных средств производства.
· Подсистема человеческих ресурсов. Описывает прием на работу, обучение и продвижение по службе персонала организации.
· Подсистема расположения организационных структур. Описывает территориальное расположение организационных единиц.
Данное разделение является в определенной мере условным; выделенные "подсистемы" не являются подсистемами в смысле системного анализа, т.к. взаимопроникают и пересекаются. Они представляют скорее совокупность предметов исследования, разных взглядов на исследуемый объект.
Слушателю курса предлагается самостоятельно проанализировать, какие группы и категории требований к системе позволяет прояснить та или иная компонента принятой в ARIS структуризации объекта исследования.
Требования и архитектура АИС
Говоря об архитектуре АИС, обычно подчеркивают деление на аппаратные, программные, информационные, организационные компоненты, их связность и детализацию.
Метафора архитектуры RUP описывается в виде 4+1 представлений: логическое, представление процессов, представление реализации и физическое представление связываются между собой представлением вариантов использования (Use case), которое играет центральную роль в выработке архитектуры системы (рис. 5.2).
Требования первичны по отношению к архитектуре. Но это не значит, что требования и архитектура должны разрабатываться последовательно.
Рис. 5.2.
Напротив, эти процессы взаимосвязаны и должны быть существенно запараллелены. Как только собран минимальный набор ключевых требований, дающих понимание о том, что нужно делать - должна быть найдена архитектура, объясняющая, как это может быть реализовано. В крупных, ответственных проектах обычно рассматривается несколько альтернативных архитектур, их достоинства и недостатки применительно к исходным требованиям.
В процессе работы с требованиями они детализируются, детализируется и архитектура. В случае множественности альтернативных архитектур на определенном уровне детализации необходимо остановиться на одной, чтобы не распылять ресурсы. Но природа требований такова, что, помимо детализации они еще и изменяются. С изменением требований изменяются и детали архитектуры. Устойчивость архитектуры проявляется в незначительных ее изменениях при добавлении, детализации и изменении требований. Если наступил момент, при котором появление новой информации о требованиях перестало оказывать влияние на архитектуру - значит, архитектура стабилизировалась.
Это - нормальный, естественный путь развития требований и архитектуры. Но что делать, если требования изменились настолько, что архитектура перестала им соответствовать? Причины тому могут быть разные, например: неопытная архитектурная группа не проявила достаточно дальновидности; группа по сбору требований пропустила на ранних стадиях критичные, архитектурно значимые требования; в бизнес-сфере Заказчика произошли большие перемены, вызвавшие коренное изменение требований к системе. Следствия также могут быть различными: договоренность об увеличении сроков и сумм по контракту; исправление ситуации за счет Разработчика; разрыв контракта.
Альтернативный выход предлагается в методологии XP: архитектура - не догма, а всего лишь метафора. Если требования вошли вразрез с существующей архитектурой - значит, архитектуру нужно просто изменить. Следует понимать, что путь и рецепты XP при кажущейся простоте ориентированы далеко не на любой коллектив. Команда XP состоит из профессионалов, имеющих позитивный опыт работы в этой методологии.
XP eXtreme Programming, экстремальное программирование. Одна из гибких (гиперссылка на agile) методологий разработки программного обеспечения, развитая в трудах Кента Бека, Уорда Каннингема, Мартина Фаулера и др., ориентированная на использование группами от 2 до 10 программистов. Согласно [44], Экстремальное программирование – это дисциплина разработки программного обеспечения и ведения бизнеса в области создания программных продуктов, которая фокусирует усилия обеих сторон (программистов и бизнесменов) на общих, вполне достижимых целях. Автор [44] выделяет следующие основные черты XP: Разработка через опережающее тестирование; "Игра в планирование"; "Заказчик всегда рядом"; Парное программирование; Непрерывная интеграция; Рефакторинг; Частые небольшие релизы (Small releases); Простота; Метафора системы; Коллективное владение кодом; Стандарт кодирования; 40-часовая рабочая неделя.
Дата добавления: 2021-03-18; просмотров: 152; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!