Такой анализ позволит создать интегрированную кис, органически вписывающуюся в жизнедеятельность (бизнес-процессы и орг структуру) о - polpoz.ru o_O
Главная
Поиск по ключевым словам:
страница 1
Похожие работы
Название работы Кол-во страниц Размер
Методические указания по выполнению курсовой работы Курсовая работа... 1 29.02kb.
Анализ состава, структуры и динамики активов бухгалтерского баланса 3 468.17kb.
Учебной дисциплины «Анализ, оптимизация и реинжиниринг бизнес-процессов»... 1 41.64kb.
Программа дисциплины по направлению 080200. 68 «Менеджмент» Магистерская... 2 555.14kb.
Учебное пособие для студентов специальностей «Менеджмент организации»... 11 1584.27kb.
Учебно-методический комплекс дисциплины «Технологические процессы... 4 671.91kb.
Председатель совета Зинчук Г. М 1 55.58kb.
Программа дисциплины Системный анализ и проектирование Для направления... 1 186.93kb.
Магрупова Зульфия Мазгаровна канд экон 1 119.98kb.
Аналитические материалы в отношении влияния на жизнедеятельность... 2 672.6kb.
Росстат: разработка таблиц «затраты-выпуск» позволит России войти... 1 14.13kb.
Болезни системы кровообращения и в первую очередь ишемическая болезнь... 1 58.39kb.
1. На доске выписаны n последовательных натуральных чисел 1 46.11kb.

Такой анализ позволит создать интегрированную кис, органически вписывающуюся в жизнедеятельность - страница №1/1

Лк.10. Истоки задачи формирования требований

Контекст задачи анализа требований

Результаты анализа требований во многом определяют успех проекта, но роль бизнес-анализа и бизнес-моделирования не столь очевидна. Поэтому стоит разобраться в каком случае следут применять



  • анализ требований,

  • бизнес-анализ или

  • бизнес-моделирование.

Смысл этого выражения - в основе задачи формирования требований к КИС лежит бизнес-модель организации. Это крайне важно. Именно, такой анализ позволит создать интегрированную КИС, органически вписывающуюся в жизнедеятельность (бизнес-процессы и орг.структуру) организации!

На изучение этого материала отпускается



  • 2 часа аудиторных занятий и

  • 2 часа домашней подготовки

10.1. Анализ требований, бизнес-анализ, анализ проблемной области

Стоит или не стоит изучать бизнес модели организации

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

Авторы [5.1], "отцы-основатели" RUP и UML, в этом вопросе дают определенную свободу: можно создавать бизнес-модели при помощи соответствующих расширений UML и рекомендаций RUP, а можно ограничиться выработкой глоссария объектов предметной области. Как и в вопросе выбора глубины проработки артефактов АТ, вопрос - проводить или не проводить бизнес-анализ (или, точнее говоря, анализ проблемной области), решается в зависимости от конкретной задачи.

Роль глоссария при АТ.

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

Задачу анализа бизнес-процессов (деловое моделирование), столь популярную в последние десятилетия ввиду устойчивой конъюнктуры, следует рассматривать, как часть более общей задачи, анализа проблемной области. Работы, посвященные анализу проблемной области, появились в отечественной литературе в середине прошлого века; данная тематика неразрывно связано с задачным подходом и инженерией экспертных систем.

Применимы ли методы, принятые при построении интеллектуальных систем для такой "более приземленной" задачи, как задача построения АИС - безусловно, да.

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

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



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

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

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



http://tester/downloads/бабак_пис/requirecommon/integrationmodel.png

Рис. 5.1. 


Рассмотрим теперь обобщенную "формулу" создания АИС (рис. 5.1).



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


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

  2. Анализируя модель проблемной области, в ней можно вычленить,

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

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

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

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

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

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

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

10.2. Методологии бизнес-анализа
Методологии бизнес анализа можно разделить на три категории по типам моделей:

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

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

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


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

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

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

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

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

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

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

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

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

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

Данное разделение является в определенной мере условным; выделенные "подсистемы" не являются подсистемами в смысле системного анализа, т.к. взаимопроникают и пересекаются. Они представляют скорее совокупность предметов исследования, разных взглядов на исследуемый объект.



10.3. Требования и архитектура АИС

Требования и архитектура АИС

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

Метафора архитектуры RUP описывается в виде 4+1 представлений:


  1. логическое, представление процессов,

  2. представление реализации и

  3. физическое представление

  4.         связываются между собой представлением вариантов использования   (use case), которое играет центральную роль в выработке архитектуры системы (рис. 5.2).

Требования первичны по отношению к архитектуре. Но это не значит, что требования и архитектура должны разрабатываться последовательно.

http://tester/downloads/бабак_пис/requirecommon/archrup.png

Рис. 5.2.


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

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




Анализ требований и другие рабочие потоки программной инженерии

Рассмотрим краткий обзор рабочих потоков RUP и их связь с потоком работ АТ (рис. 5.3).


http://tester/downloads/бабак_пис/requirecommon/requeirestrim.png

Рис. 5.3.


Поток работ "деловое моделирование" служит основой для анализа и формирования требований к АИС, позволяет избежать ошибок.

Поток работ "управление средой" предоставляет исходную информацию для рабочей группы АТ, регламентирующую форматы оформления, CASE-средства, регламенты работы.

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

Поток работ "анализ и проектирование" осуществляется на основе исходных данных, предоставленных АТ. В определенной мере эти потоки работ проводятся параллельно. При обнаружении проблем, связанных с требованиями, возникает обратная связь от этого потока работ к потоку работ АТ.

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

Для потока работ "реализация" связь с требованиями не указана. Между тем автор считает, что требования должны анализироваться и учитываться во ВСЕХ рабочих потоках проекта, даже если это формально не предусмотрено выбранным группой процессом.



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