47640 (588493), страница 3

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 3)

Выводы: результаты анализа требований во многом определяют успех проекта, требования являются необходимой составляющей в разработке проекта, от правильно сформулированных и разработанных требований, зависит успех проекта, но какова роль бизнес-анализа и бизнес-моделирования предстоит исследовать и проанализировать. Стоит разобраться, в каком случае следует применять анализ требований, бизнес-анализ или бизнес-моделирование.

1.2 Функциональное моделирование бизнес-процессов

Проведение исследований в области бизнес моделирования показало, что существуют уже сотни методик, методологий, процессов, стандартов, регламентирующих те или иные детали выбора и комплексирования потоков работ при разработке автоматизированных информационных систем. Работы, связанные с бизнес-анализом и бизнес-моделированием до недавнего времени были не популярны у проектировщиков ИС. Их роль не столь очевидна и принимается далеко не всеми методологиями. Возникает вопрос собирать информацию о предприятии, для которого разрабатывается (выбирается) АИС в виде бизнес-моделей или стоит пропустить этот этап и сразу формировать требования к системе и приступать к её разработке?

Заказчик и Разработчик всегда говорят на разных языках. Общее понимание вырабатывается с трудом, этот процесс занимает время, но важность его трудно переоценить: ведь успешная реализация проекта в области и внедрения АИС во многом зависит от того, удастся ли выработать и документировать их общее представление о предмете разработки. Если же Разработчик идет еще дальше и вникает в особенности ведения дел на предприятии Заказчика – он, во-первых, сможет добиться лучшего понимания требований к АИС и, во-вторых, участвовать наряду с Заказчиком в формулировке требований, анализе пропущенных требований и пр.

Задачу анализа бизнес-процессов (деловое моделирование), столь популярную в последние десятилетия ввиду устойчивой конъюнктуры, следует рассматривать, как часть более общей задачи, анализа проблемной области³. Работы, посвященные анализу проблемной области, появились в отечественной литературе в середине прошлого века; данная тематика неразрывно связано с задачным подходом и инженерией экспертных систем. Первые шаги в области моделирования были проведены в построении интеллектуальных систем. Для такой «более приземленной» задачи, как задача построения АИС – эти методы начали применяться позднее. Стратегии извлечения знаний во многом пересекаются с работой аналитика, методы решения задачи путем редукции на подзадачи и поиска в пространстве состояний нашли свое отражение во множестве методик бизнес-анализа, анализа и синтеза программных систем и этот список можно продолжать. В дипломной работе рассматривается вопрос насколько результативно применение тех или иных моделей и методов при описании организационных систем.

Что бы решить этот вопрос надо определить цели и задачи самого бизнес-анализа, как этапа построения КИС.

С позиций моделирования, анализ требований (АТ) и анализ проблемной области (АПО) – принципиально разные процессы.

АПО преследует классические цели создания модели: налицо объект (автоматизируемое предприятие или организационная система⁴, ОС) и задача аналитика – отразить этот объект в создаваемой модели с требуемой степенью точности схема процесса разработки представлена на рисунке 3.

Рис. 3 Схема процесса разработки КИС

Анализ требований, напротив, направлен на моделирование воображаемого, еще не существующего объекта (АИС). Т.е. сначала создается модель, а затем, на ее основании, синтезируется объект. Рассмотрим теперь обобщенную «формулу» создания АИС.

ОС->М(ОС)->М(АИС)->М’ (АИС)->М’’ (АИС)->М’’’ (АИС)->АИС

Проведя анализ организационной системы можно создать модель М(ОС). Это – модель бизнес-анализа (проблемной области).

Анализ проблемной области позволяет вычленить:

• с одной стороны, задачи и функции, реализуемые внутри ОС и функции коммуникации ОС и среды,

• с другой – устройство предметной области (в начале – на уровне концептуальной модели),

• с третьей – требования к информации и ее обработке.

Выделив среди функций те, которые подлежат автоматизации, мы получаем основу для выявления функциональных требований к системе. Остальная, собранная на этапе АПО, информация служит для поиска нефункциональных требований. В результате получаем модель АТ, как первое приближение модели АИС, М(АИС).

Углубленный анализ и проектирование, формируют, соответственно, аналитическую модель М’ (АИС), проектную модель М’’ (АИС) и модель реализации М’’’ (АИС).

Модель уровня реализации позволяет объединить собственно АИС, как совокупность программных, информационных, организационных факторов.

АИС в свою очередь представляет собой модель организационной системы М’ (ОС), замыкая цикл моделирования. Для того, чтобы прояснить связь между этими процессами, необходимо заметить, что создаваемая АИС также является моделью, по отношении к ОС. Таким образом, создавая документ АТ, мы тем самым порождаем как бы «модель второго порядка», т. к. документ АТ является ничем иным, как моделью модели ОС. Не обладая моделью АПО, мы, конечно, можем создать модель АТ. Но при этом мы рискуем тем, что при синтезе оригинала модели (т.е. АИС), не обладая знаниями об ОС, мы можем попасть в ситуацию рассогласования: результирующая АИС не будет ингерентна (согласована с) ОС и, тем самым, не станет жизнеспособной.

Процесс разработки АИС можно отобразить в виде диаграмм в программе BPwin. На рисунке 4 отображены этапы разработки АИС. Диаграммы верхнего уровня – Создание программы (рис. 4) состоит из двух диаграмм второго уровня Разработка и Тестирование (рис. 5 и рис. 6).

Рис. 4 Этап Создание программы

Разработка (рис. 5) состоит из Построения каркаса программы и Создания тела программы.

Рис. 5 Этап Разработка

Третий уровень Построение каркаса программы (рис. 6)

Рис. 6 Этап построение каркаса

Четвертый уровень (рис. 7) Создание тела программы.

Рис. 7 Создание тела программы

Пятый уровень (рис. 8) Тестирование

Рис. 8 Этап тестирования

Рассмотрев бизнес-моделирование, перейдем к бизнес-процессам. Изучение методологии бизнес-процессов приводит к возможности их деления на три категории:

• модели, преследующие цель анализа и улучшения организационной системы (например, SWOT, VCM, BPR, CPI/TQM/ISO9000, BSC),

• модели общего назначения, такие, как SADT, DFD, IDEF1, IDEF3, IDEF5 и другие,

• модели, специально разработанные для использования при автоматизации (например, ISA, BSP, ARIS, RUP).

Наиболее развитая модель описания проблемной области предлагается в методологии ARIS. Архитектура ARIS [25.5] выделяет в организации следующие подсистемы:

• Организационная. Определяет структуру организации – иерархию подразделений, должностей и конкретных лиц, многообразие связей между ними, а также территориальную привязку структурных подразделений.

• Функциональная. Определяет функции, выполняемые в организации.

• Подсистемы входов / выходов. Определяют потоки используемых и производимых продуктов и услуг.

• Информационная (подсистема данных). Описывает получение, распространение и доступ к информации (данным).

• Подсистема процессов управления. Определяет логическую последовательность выполнения функций посредством событий и сообщений. Можно сказать, что подсистема управления – это совокупность разнесенных во времени сообщений разного рода.

• Подсистема целей организации. Описывает иерархию целей, достигаемых в ходе выполнения того или иного процесса.

• Подсистема средств производства. Описывает жизненный цикл основных и вспомогательных средств производства.

• Подсистема человеческих ресурсов. Описывает прием на работу, обучение и продвижение по службе персонала организации.

• Подсистема расположения организационных структур. Описывает территориальное расположение организационных единиц.

Данное разделение является в определенной мере условным; выделенные «подсистемы» не являются подсистемами в смысле системного анализа, т.к. взаимопроникают и пересекаются. Они представляют скорее совокупность предметов исследования, разных взглядов на исследуемый объект. Принцип улучшения бизнес-процессов основывается на четыре подходах: методика быстрого анализа решения (FAST); бенчмарткетинг процесса; перепроектирование процесса; реинжениринг процесса.

В настоящее время существует ряд методик и инструментов, которые применяются при реализации преобразований. Метод построения иерархических моделей, направленн на описание и анализ бизнес-процессов как элементов экономических систем. При этом крайне важно четко сформулировать постановку задачи и цели моделирования, это определяет выбор адекватных методик и инструментальных средств.

Для решения задач функционального моделирования, то есть описания существующих процессов или процессов, которые мы стремимся получить в идеале, широко используется методология структурного анализа и проектирования технология SADT⁵.

Основная идея методологии SADT – построение древовидной функциональной модели предприятия. Сначала функциональность предприятия описывается в целом, без подробностей. Такое описание называется контекстной диаграммой. Взаимодействие с окружающим миром описывается в терминах входа (данные или объекты, потребляемые или изменяемые функцией), выхода (основной результат деятельности функции, конечный продукт), управления (стратегии и процедуры, которыми руководствуется функция) и механизмов (необходимые ресурсы). При создании контекстной диаграммы формулируются цель моделирования, область (описание того, что будет рассматриваться как компонент системы, а что как внешнее воздействие) и точка зрения (позиция, с которой будет строиться модель). Обычно в качестве точки зрения выбирается точка зрения лица или объекта, ответственного за работу моделируемой системы в целом.

В дальнейшем общая функция разбивается на крупные подфункции. Этот процесс называется функциональной декомпозицией. Затем каждая подфункция декомпозируется на более мелкие – и так далее до достижения необходимой детализации описания. На рис. 2 показано дерево функций, называемое деревом узлов функциональной модели.

Рис. 9. Пример декомпозиции – диаграмма узлов функциональной модели

Каждый узел в диаграмме соответствует отдельному фрагменту описания диаграммы. Модель представляет собой совокупность иерархически выстроенных диаграмм, каждая из которых является описанием какой-либо функции или работы (activity).

Работы на диаграммах изображаются в виде прямоугольников (функциональные блоки). Каждая работа изображает какую-либо функцию или работу и именуется глаголом или глагольной фразой, обозначающей действие, например «Изготовление изделия», «Обслуживание клиента» и т.д. Стрелки помечаются существительным и обозначают объекты или информацию, связывающую работы между собой и с внешним миром. В отличие от моделей, отображающих структуру организации, работа на диаграмме верхнего уровня в функциональной модели – это не элемент управления нижестоящими работами. Работы нижнего уровня – это то же самое, что работа верхнего уровня, но в более детальном изложении.

Разрабатывая новую информационную технологию целесообразно ориентироваться на процессы, реализуемые на конкретном рабочем месте.

Под бизнес – процессом понимается поток информации, переходящий от одного рабочего места к другому. В задаче могут быть выделены несколько бизнес – процессов.

Характеристики

Список файлов ВКР