Размещено на http://www.allbest.ru/

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ

МОСКОВСКИЙ ИНЖЕНЕРНО-ФИЗИЧЕСКИЙ ИНСТИТУТ (ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ)

Экономико-аналитический институт МИФИ

КАФЕДРА ЭКОНОМИЧЕСКОЙ ДИНАМИКИ

Специальность: 351400 прикладная информатика в экономике

КУРС ЛЕКЦИЙ

ПО КУРСУ «ПРОЕКТИРОВАНИЕ ИС»

Москва 2007

Оглавление

Лекция 1. Роль и место бизнес-процессов на современном предприятии. ЖЦ внедрения ИС. Методы моделирования бизнес-процессов. CASE-средства

Лекция 2. Принципы структурного анализа. Базовые структурные методологии (SADT) и методология нотации (DFD, ERD). CASE-средства, поддерживающие структурный подход к проектированию ИС (AllFussion Process Modeler)

Лекция 3. Принципы процессного анализа. Базовые процессные методологии (ARIS) и нотации (модели Organization chart, Function tree, EPC, ERD). CASE-средства, поддерживающие процессный подход к проектированию ИС (ARIS). Методология и нотация ARIS

Лекция 4. Основные подходы к реорганизации бизнес-процессов: принципы Э. Деминга, японская парадигма улучшения бизнес-процессов (TQM, 6-сигм), BPR (принципы Хаммера/Чампи)

Лекция 5. Сравнительный анализ подходов к проектированию ИС

Лекция 6. Бизнес-процессы и информационные технологии: классификация информационных систем, современные подходы к построению корпоративной информационной системы (КИС) (обзор рынка систем, основной функционал, факторы риска при внедрении систем класса ERP, критерии выбора ERP)

Лекция 7. Обзор ERP-систем «крупного» класса. Обзор рынка систем. Основной функционал систем, на примере системы SAP R3

Лекция 8. Обзор ERP-систем «среднего» класса. Обзор рынка систем. Основной функционал систем, на примере системы Microsoft DynamicsAx

Лекция 9. Обзор ERP-систем «малого» класса. Обзор рынка систем. Основной функционал систем, на примере системы 1С или БОСС

Лекция 10. Сравнительный анализ ERP-систем

Заключение

Литература

Приложение

Лекция 1. Роль и место бизнес-процессов на современном предприятии. ЖЦ внедрения ИС. Методы моделирования бизнес-процессов. CASE-средства

Роль и место бизнес-процессов на современном предприятии

Процессы: определения, характеристики, свойства

Существует множество определений бизнес-процессов. Рассмотрим ключевые определения бизнес-процесса:

1. Совокупность различных видов деятельности, в рамках которой "на входе" используются один или более видов ресурсов, и в результате этой деятельности на "выходе" создается продукт, представляющий ценность для потребителя (Хаммер, Чампи, 1993).

2. Набор логически взаимосвязанных действий, выполняемых для достижения определенного выхода бизнес-деятельности (Davenport, Short, 1990).

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

4. Сущность, определяемая через точки входа и выхода, интерфейсы и организационные устройства, частично включающие устройства потребителя услуг\товаров, в которой происходит наращивание стоимости производимой услуги\товара (Porter, Millar,1985).

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

6. Логические серии взаимозависимых действий, которые используют ресурсы предприятия для создания или получения в обозримом или измеримо предсказуемом будущем полезного для заказчика выхода, такого как продукт или услуга (Зиндер, 1996).

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

8. Любые виды деятельности в работе организации (Deming, 1982).

9. Систематизированное последовательное исполнение функциональных операций, которые приносят специфический результат (TeleManagement forum).

10. Совокупность взаимосвязанных ресурсов и деятельности, которая преобразует входящие элементы в выходящие (Госстандарт, 1997).

11. Множество взаимосвязанных и взаимодействующих операций, которые преобразуют входы в выходы (ISO, 2000).

12. Ряд взаимосвязанных видов деятельности, преобразующих входы в выходы (ISO/IEC, 2001).

13. Действие, переводящее вход системного объекта в выход (Никаноров, 1969).

14. Процесс - последовательность действий, которые создают дополнительные ценности путем преобразования с помощью ресурсов входящих элементов в требуемые выходящие. («European Quality» №2, том 6, 1999 г., стр. 24-25).

Проанализировав данные определения, дадим совокупное определение бизнес-процесса:

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

Рассмотрим структуру любого бизнес-процесса (Рис.1):

Рис.1 Структура бизнес-процесса

Для анализа Рис.1 введем базовые понятия:

· Вход бизнес-процесса - объект бизнес-процесса (процедура, операция), взаимодействующий с внешними бизнес-процессам и получающая от них информацию/материальные ресурсы

· Выход бизнес-процесса - объект бизнес-процесса (процедура, операция), взаимодействующий с внешними бизнес-процессам и передающая им информацию/материальные ресурсы, являющиеся результатом выполнения бизнес-процесса

· Операция (работа) - часть бизнес-процесса.

· Декомпозиция бизнес-процесса - детальное описание бизнес-процесса, осуществляемое путем разбиения процесса на несколько частей и последующего их описания при помощи более подробных моделей

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

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

· Инициирующее событие - объект модели бизнес-процесса, отражающий событие, являющееся управляющим воздействием, необходимым для начала выполнения процедуры (функции)

· Ресурсы - информация (документы, файлы), финансы, материалы, персонал, оборудование, инфраструктура, среда, программное обеспечение, необходимые для выполнения бизнес-процесса

· Показатели бизнес-процесса - количественные и/или качественные параметры, характеризующие бизнес-процесс и его результат.

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

· Поставщик - субъект, предоставляющий ресурсы.

· Потребитель (клиент) - субъект, получающий результат бизнес-процесса. Потребитель может быть:

· а) внутренний - то есть находящийся в организации и, в ходе своей деятельности, использующий результаты (выходы) предыдущего бизнес-процесса;

· б) внешний - то есть находящийся за пределами организации и использующий или потребляющий результат деятельности (выход) организации.

Отличительными чертами любого бизнес-процесса являются:

· Хозяин Процесса - должностное лицо, несущее ответственность за ход и результаты Процесса;

· Ресурсы - ресурсы, выделенные в распоряжение Хозяина Процесса для его проведения (оборудование, персонал, помещения, среду, транспорт, связь, материалы, финансы, документация и т. д.);

· Параметры Процесса - характеристики, по которым Хозяин Процесса и высший руководитель могут судить о том, насколько эффективно выполняется Процесс и достигаются ли запланированные результаты;

· Потребитель - потребитель результатов Процесса, степень удовлетворенности которого, также предназначена для оценки эффективности Процесса;

· Входы Процесса - входные объекты (сырье, продукция, комплектация, информация или услуга), которые преобразуются в Выходы Процесса, в ходе выполнения Процесса. Часто Входы одного Процесса являются выходами другого;

· Выходы Процесса - продукция, информация или услуга ради которой существует Процесс.

Любой процесс обладает следующими отличительными характеристиками:

· Результативность - характеризует соответствие результатов процесса нуждам и ожиданиям потребителей

· Управляемость - характеризует степень, в которой производится управление выполнением процесса производства требуемых продуктов/услуг, отвечающих определенным целевым показателям

· Повторяемость - характеризует способность процесса создавать выходные потоки с одинаковыми характеристиками при повторных его реализациях

· Определенность - отражает степень,с которой реальный процесс соответствует описанию

· Эффективность - отражает, насколько оптимально используются ресурсы при достижении необходимого результата процесса

· Гибкость (адаптируемость)- способность процесса приспосабливаться к изменениям внешних условий, перестраиваться так, чтобы не снижались ни результативность, ни эффективность

· Стоимость процесса - описывает финансовые затраты на процесс

Раскроем понятие владельца процесса (Рис.2):

· Владелец процесса - это отдельное лицо, несущее полную ответственность за процесс и наделенное полномочиями в отношении этого процесса

· В сложных процессах - менеджер высшего уровня

· Владелец процесса не касается функций, выполняемых в рамках процесса отдельными департаментами. Ему важна успешная реализация всего процесса

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

Критерии выбора владельца процесса:

· Детальное знание бизнес-процесса, компетентность и профессиональные знания

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

· Коммуникативные способности

· Понимание важности порученного дела и надлежащая мотивация

На представлено взаимодействие Владельца процесса и Менеджера процесса:

Размещено на http://www.allbest.ru/

Рис. 3 Взаимодействие Владельца процесса и Менеджера процесса

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

· По масштабу

· По сложности

· По количеству задействованных исполнителей

· По количеству потребляемых ресурсов

· По потребителям выходных результатов и т.д.

Обычно все процессы организации классифицируются с точки зрения отношения к основному результату деятельности организации. Дадим определение Классификации:

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

При этом выделяют следующие классы бизнес-процессов (Рис.4):

· Основные процессы - добавляют качество, кросс-функциональны в рамках предприятия, взаимодействуют как с клиентами, так и с партнерами. Должно быть выделено в качестве основных 5-8 процессов. Требуют особого внимания группы процессов:

Ш логистика выполнения заказа

Ш разработка нового продукта/услуги

Ш управление взаимоотношениями с клиентами

Примеры: производство, логистика доставок/поставок планирование ресурсов, управление произвоственными мощностями

· Вспомогательные процессы - создают инфраструктуру организации, оказывают инфраструктурную и иную помощь.

Примеры: управление финансами, управление персоналом, управление информационными ресурсами

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

Примеры: стратегическое управление, управление рисками, бюджетирование

Методы моделирования бизнес-процессов

Описание любого процесса включает в себя:

· описание последовательности функций процесса

ь При описании необходимо использовать подход «сверху-вниз», т.е. отталкиваться от описания бизнес-процессов компании верхнего уровня, а затем, выделив процесс описывать его, последовательно детализируя.

ь Каждый процесс представляется в виде последовательности выполняемых функций

ь Степень детализации представления функций определяется целью описания процесса

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

· описание входов и выходов процесса (Рис. 4)

· описание поставщиков и потребителей процесса (Рис. 5)

· определение ресурсного окружения процесса (Рис.6)

ь людские ресурсы - участники процесса (кто выполняет)

ь производственные ресурсы - станки, оборудование, компьютеры, транспорт (при помощи чего выполняет)

ь материальные ресурсы - материалы, комплектующие, энергетические ресурсы (с использованием чего выполняет)

ь информационные ресурсы - данные, документы, информация (на основании чего выполняет)

ь интеллектуальные - знания и полномочия участников и владельца процесса

ь Все эти ресурсы должны определены и описаны для каждой функции, выполняемой в процессе

Варианты описания процессов:

· текстовый

· табличный

· графический

Размещено на http://www.allbest.ru/

Рис. 4 Описание входов и выходов процесса

К основным подходам моделирования относят:

Ш Структурный

Ш Процессный

Ш Объектно-ориентированный

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

ЖЦ внедрения ИС

Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов:

· основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

Модели жизненного цикла ПО

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

К настоящему времени наибольшее распространение получили следующие две основные модели ЖЦ:

· каскадная модель (70-85 г.г.);

· спиральная модель (86-90 г.г.).

В изначально существовавших однородных ИС каждое приложение представляло собой единое целое. Для разработки такого типа приложений применялся каскадный способ. Его основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа на следующий происходит только после того, как будет полностью завершена работа на текущем (Рис. 7). Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.

Положительные стороны применения каскадного подхода заключаются в следующем:

· на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;

· выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.

Рис. 7 Каскадная схема разработки ПО

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

Рис. 8. Реальный процесс разработки ПО по каскадной схеме

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

Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ [10] (Рис. 9), делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации.

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

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



Рис.9 Спиральная модель ЖЦ

CASE-средства

Структурный анализ как совокупность методов моделирования сложных систем вследствие большой размерности решаемых задач должен опираться на мощные средства компьютерной поддержки, обеспечивающей автоматизацию труда системных аналитиков. Таким средством являются CASE-средства - Computer Aided Software Engineering.

Большинство CASE -средств основано на парадигме - «Методология - Модель - Нотация - Средства».

Дадим определения выше перечисленным компонентам:

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

· Модели - это совокупность символов (математических, графических и т.п.), их свойств, атрибутов и отношений между ними, которая адекватно описывает некоторые свойства моделируемого объекта.

· Нотации - система условных обозначений, принятая в используемой модели.

· Средства - аппаратное и программное обеспечение, реализующее выбранные методологию, модели и нотации.

К характеристикам CASE-средств относятся:

· мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности;

· интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки информационной системы;

· использование специальным образом организованного хранилища проектных метаданных (репозитория). Интегрированное CASE-средство (или комплекс средств, поддерживающих полный жизненный цикл ПО) содержит следующие компоненты:

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

· графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели информационной системы;

· средства разработки приложений, включая языки 4GL и генераторы кодов;

· средства конфигурационного управления;

· средства документирования;

· средства тестирования;

· средства управления проектом;

· средства реинжиниринга.

На сегодняшний день наиболее распространенными CASE-средствами в России являются:

· ARIS;

· AllFusion Modeling Suite.

Лекция 2. Принципы структурного анализа. Базовые структурные методологии (SADT) и методология нотации (DFD, ERD). CASE-средства, поддерживающие структурный подход к проектированию ИС (AllFussion Process Modeler)

Принципы структурного анализа. Базовые структурные методологии (SADT) и методология нотации (DFD, ERD)

Прежде чем перейти к понятию структурного анализа, дадим следующие определения:

· Системный подход - методология специального научного познания и социальной практики, и также объяснительный принцип, в основе которого лежит исследование любого объекта как сложной целостной кибернетической социально-экономической системы

· Системный подход реализует представление сложного объекта в виде иерархической системой взаимосвязанных моделей, позволяющих фиксировать целостные свойства объекта, его структуру и динамику

К основным принципам системного подхода относится:

· Целостность - позволяет рассматривать одновременно систему как единое целое и в то же время как подсистему для вышестоящих уровней.

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

· Структуризация - позволяет анализировать элементы системы и их взаимосвязи в рамках конкретной организационной структуры. Как правило, процесс функционирования системы обусловлен не столько свойствами ее отдельных элементов, сколько свойствами самой структуры.

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

Применение системного подхода:

· Для формулирования политики и стратегии - создание всеобъемлющих и достойных планов, связывающих входы функций и процессов

· Для установления целей и плановых показателей - цели и ключевые показатели результативности конкретных процессов приведены в соответствие с ключевыми стратегическими целями организации

· Для управления операциями - более широкий взгляд на эффективность процессов, что приводит к пониманию причин проблем и проведению своевременных мероприятий по усовершенствованию

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

Основные принципы структурного анализа:

· Абстрагирования - выделение существенных с некоторых позиций аспектов системы и отвлечение от несущественных с целью представления проблемы в простом общем виде.

· Формализации - заключается в необходимости строгого методологического подхода к решению проблемы.

· Скрытия - заключается в сокрытии несущественной на конкретном этапе информации.

· Полноты - заключается в контроле на присутствие лишних элементов.

· Непротиворечивости - заключается в обоснованности и согласованности элементов.

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

· Структурирования данных - заключается в то, что данные должны быть структурированы и иерархически организованы.

Задачи структурного анализа:

· выявление структуры как относительно устойчивой совокупности отношений;

· признание методологического примата отношений над элементами в системе;

· частичное отвлечение от развития объектов;

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

Типы структурных методологий:

· процедурно(функционально) - ориентированные

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

· информационно - ориентированные

- структуры данных определяются первыми, а процедурные компоненты являются производными от данных.

- Методология ARIS является одной из таких информационно-ориентированных методологий

Введем основные (базовые) понятия структурного подхода:

· Система - это совокупность взаимосвязанных и взаимодействующих элементов (ИСО 9000)

· Цель системы - достижение и сохранение желаемого состояния или желаемого результата поведения системы

· Система целей - совокупность взаимоувязанных целей, например: стратегические и тактические цели; долгосрочные и краткосрочные цели

Связь системы с внешней средой представлена на Рис. 10.

Размещено на http://www.allbest.ru/

Рис. 10 Связь системы с внешней средой

Один из принципов моделирования при структурном подходе представлен на Рис.11.

Размещено на http://www.allbest.ru/

Рис.11 Принцип моделирования «сверху-вниз»

Примеры методологий структурного анализа:

· DFD (Data Flow Diagrams) - диаграммы потоков данных, обеспечивающих анализ требований и функциональное проектирование информационных систем;

· STD (State Transition Diagram) - диаграммы перехода состояний для проектирования систем реального времени;

· ERD (Entity-Relationship Diagrams) - диаграммы «сущность-связь»;

· структурные карты Джексона и/или Константайна для проектирования межмодульных взаимодействий и внутренней структуры объектов;

· FDD (Functional Decomposition Diagrams) - диаграммы функциональной декомпозиции;

· SADT (Structured Analysis and Design Technique - Технология структурного анализа и проектирования, 1969 -1973) - полная методология для создания описания систем, основанная на концепциях системного моделирования.

Связь между методологией SADT и стандартами структурного анализа (Рис.12)

Размещено на http://www.allbest.ru/

Рис.12 Методология SADT ее описывающие

Основные принципы методологии SADT:

· Четкое описание цели моделирования;

· Фиксация единой точки зрения на моделируемую систему;

· Определение границ системы;

· Декомпозиция, обеспечивающая последовательную детализацию описания;

· Цель модели - получение ответов на некоторую совокупность вопросов;

· Точка зрения - это позиция наблюдателя, которую необходимо выбрать, чтобы увидеть систему в действие;

· У модели может быть только одна точка зрения!!!

· SADT модель должна иметь единственный субъект;

· В SADT-моделях используются как естественный, так и графический языки;

· Диаграмма - совокупность графического и соответствующего текстового описания

Семейство IDEF

· IDEF0 - методология функционального моделирования, позволяющая описать процесс в виде иерархической системы взаимосвязанных функций; (Р50.1.028-2001. Методология функционального моделирования)

· IDEF1 - методология анализа и изучения взаимосвязей между информационными потоками в рамках коммерческой деятельности предприятия;

· IDEF1X - методология информационного моделирования, основанная на концепции «сущность-связь».

· IDEF3 - методология документирования технологических процессов.

· IDEF4 - методология объектно-ориентированного проектирования.

· IDEF5 - методология, обеспечивающая наглядное представление данных обработки онтологических запросов

Стандарт IDEF0

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

· Достоинство функциональной модели - простота графического представления:

– Функциональный блок - описание функций (действий, работ)

– Интерфейсная дуга - линия, связывающая функциональные блоки и описывающая объекты (потоки объектов)

Описание функциональных блоков в стандарте IDEF0 (Рис. 13)

· Функциональный блок - визуализируется в виде прямоугольника

· Название блоков должны быть глаголы в неопределенной форме с последующим дополнением (например, «Принять заказ на поставку», «Оприходовать номенклатуру на склад»).

· Название пишется внутри блока - должно быть лаконичным и кратким

· В правом нижнем углу проставляется номер блока

· Число блоков на одной диаграмме должно быть от 2-7

· Блоки размещаются на диаграмме по степени важности или очередности выполнения - принцип доминирования

· Более доминирующие блоки располагаются выше и левее относительно менее доминирующих

· Каждый из блоков при необходимости подвергаться декомпозиции

· Связи основных блоков с детализирующими можно проследить по нумерации

Размещено на http://www.allbest.ru/

Рис. 13 Описание функциональных блоков в стандарте IDEF0

Синтаксические правила для функциональных блоков:

1. Блоки должны быть прямоугольники с прямыми углами

2. Размеры блоков должны быть выровнены по ширине текста

3. Имя блока должно отражать сущность функции

4. Блоки должны быть нарисованы сплошными линиями

5. Цвета линий различных блоков могут быть различны

Спецификация сторон функциональных блоков в стандарте IDEF0 (Рис.14)

Размещено на http://www.allbest.ru/

Рис.14 Спецификация сторон функциональных блоков в стандарте IDEF0

Нумерация диаграмм в стандарте IDEF0 (Рис.15)

Описание интерфейсных дуг в стандарте IDEF0:

1. Стрелки могут состоять только из вертикальных или горизонтальных отрезков

2. Вертикальные и горизонтальные участки ломанных стрелок соединяются при помощи закруглений

3. Концы стрелок должны присоединяться к внешним границам функциональных блоков, присоединение в углах блока не допускается

4. Стрелки должны быть нарисованы сплошными линиями

5. Цвет и толщина для различных линий может быть различна

6. Дуги помечаются текстовыми метками. Метки должны быть именами существительными или существительными с определениями

7. Метки размещаются либо непосредственно на дугах, или на свободных местах диаграммы и связываются зигзагообразной линией

Правила построения интерфейсных дуг в стандарте IDEF0

1. Управляющие объекты обязательно должны отражаться в функциональной модели, а входные объекты - не обязательно (например, список поставщиков, прайс-лист, список номенклатуры)

2. Механизмы - это объекты, которые выполняют процесс (должностные лица, структурные подразделения)

Варианты графического изображения прямых и обратных взаимосвязей в стандарте IDEF0 (Рис.16)

Туннельные дуги

1. Помещение дуги в туннель является способом скрыть ее источник

• Со скрытым источником

• Со скрытым приемником

2. От одной стороны функционального блока не рекомендуется отводить/присоединять 5-7 дуг

Пример диаграммы IDEF0 (Рис.17)



Рис.17 Пример диаграммы IDEF0

Предназначение IDEF 1X

· IDEF1Х - это метод для разработки Реляционных БД, использует удобный синтаксис, специально разработанный для удобного построения концептуальной схемы (универсальное представление структуры данных, независимо от конечной реализации БД и аппаратной платформы)

· Целесообразней использовать для построения логической структуры БД после того, как:

– все информационные ресурсы исследованы;

– решение о внедрении реляционной БД как части корпоративной информационной системы принято.

· Не целесообразно использовать IDEF1X для описания нереляционных систем

Концепция и семантика IDEF1X (Рис.18)

· Сущности и их атрибуты

• Сущность - конкретный набор экземпляров реального времени;

• Сущность в стандарте IDEF1Х описывается в виде прямоугольника

• Атрибут - признак сущности;

• Разделяют Ключевые и Неключевые атрибуты сущности

· Связи между сущностями

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

• У связей имеется координальность: (1,1), (1,N), (N,M)

· ПРИМЕРЫ:

• Отдел <состоит из> нескольких Сотрудников

• Самолет <перевозит> нескольких Пассажиров.

• Сотрудник <пишет> разные Отчеты.

Идентификация сущностей. Представление о ключах

· Каждый прямоугольник, отображающий собой сущность, разделяется горизонтальной линией на часть, в которой расположены ключевые поля и часть, где расположены не ключевые поля.

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

· Ключевая область содержит первичный ключ для сущности

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

· Неключевой атрибут - это атрибут, который не был выбран ключевым

Рис.19 Идентификация сущностей. Представление о ключах

Правила выбора «ключа»

· Уникальным образом идентифицировать экземпляр сущности.

· Не использовать NULL значений.

· Не изменяться со временем. Экземпляр идентифицируется при помощи ключа. При изменении ключа, соответственно меняется экземпляр.

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

Лекция 3. Принципы процессного анализа. Базовые процессные методологии (ARIS) и нотации (модели Organization chart, Function tree, EPC, ERD). CASE-средства, поддерживающие процессный подход к проектированию ИС (ARIS). Методология и нотация ARIS

Сравнительный анализ функционального и процессного подходов

· Противопоставление процессного и "функционального" подхода принципиально неверно

· Противоречий между двумя подходами не существует - они не только дополняют друг друга, но и в известной степени должны применяться параллельно

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

· У этих двух подходов есть существенное сходство в базовых посылках: и тот и другой постулируют изначальный набор типовых процессов/функций, который в дальнейшем детализируется и привязывается к конкретному предприятию

· Функциональный подход отвечает на вопрос «Что делать?», процессный «Как делать?»

Рассмотрим организацию с точки зрения бизнес-процессов:

· Предприятие - взаимосвязанная совокупность бизнес-процессов.

· Работа должна быть организована вокруг процессов.

· «Не товары, а эффективные процессы их содания приносят компаниям долгосрочный успех» (Чампи)

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

· Правильно выстроенный процесс - интеллектуальное достояние компании

· Автоматизация существующих процессов с помощью ИТ, как правило, не дает ожидаемого эффекта

Рассмотрим процессный подход к управлению организацией:

· сокращение зависимости процессов от функциональной иерархии («прямые» бизнес-процессы)

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

· максимальное использование квалификации сотрудников

· делегирование полномочии и ответственности в рамках процесса

· ориентация сотрудников и подразделений на конечный результат

· устранение проблем на «стыках» между подразделениями

Сущность применения процессного подхода заключается в:

1. Определить цели организации и результаты их достижения

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

3. Выявить внутренних и внешних потребителей, поставщиков и других участвующих в процессе сторон

4. Выявить и измерить входы и выходы процесса

5. Выявить интерфейсы процесса с функциями организации

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

7. Четко распределить ответственность, полномочия и подотчетность при управлении процессом

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

Применение процессного подхода дает следующие преимущества:

· Определить процесс достижения желаемого результата

· Выявить и измерить входы и выходы процесса

· Выявить интерфейсы процесса с функциями организации

· Оценить возможный риск и последствия влияния процесса на потребителей, поставщиков и другие участвующие в нем стороны

· Распределить ответственность, полномочия и подотчетность при управлении процессом

· Выявить внутренних и внешних потребителей, поставщиков и других участвующих в процессе сторон

· Уделить при проектировании процессов внимание шагам процессов, видам деятельности, потокам, контрольным величинам, потребностям в подготовке персонала, оборудовании, методах, информации, материалов и других ресурсах, необходимых для достижения желаемого результата

Методология ARIS - пример процессного подхода к проектированию ИС:

· ARIS - инструментальная среда описания и анализа бизнес-процессов

· ARIS - лидер на рынке средств описания процессов (Рис. 20)

Размещено на http://www.allbest.ru/

Возможные цели использования ARIS:

Размещено на http://www.allbest.ru/

Рис. 21 Цели использования ARIS

Что дает применение ARIS:

· Стандарт общения в организации

· Удаленный доступ и публикацию проектных данных

· Централизованное хранение и ведение данных проекта

· Интеграция с SAP R/3

· Использование референтных моделей IDS и отраслевых прототипов

· Фиксацию накопление и сохранение коллективных знаний

· Автоматизация получения проектных документов

· Организация и регламентация коллективной работы команды проекта

· Регламентация взаимодействия Заказчика и Консультанта

Основы методологии ARIS

· Методология ARIS представляет собой современный подход к структурированному описанию деятельности организации и представлению ее в виде взаимосвязанных и взаимодополняющих графических моделей, удобных для понимания и анализа

· Методология ARIS основывается на концепции интеграции, предлагающей целостный взгляд на процессы, и представляет собой множество различных методик, объединенных в рамках единого системного подхода, такие известные как:

Ш диаграммы eEPC (Extended Event driven Process Chain - событийная цепочка процесса)

Ш модели ERM - (Entity Relationship Model - модель «сущность-связь»)

Ш язык UML (Unified Modeling Language - универсальный язык моделирования)

Ш методики OMT (Object Modeling Technique - методика объектно-ориентированного моделирования)

Ш методика ABC (Activity Based Costing - пооперационный расчет стоимости процессов)

Ш методики BSC (Balanced Scorecard - система сбалансированных показателей)

Уровни описания ARIS (Рис. 22 -23):

· Организационное представление

· Функциональное представление

· Процессное представление

· Представление на уровне данных

На каждом из выше указанных уровней предметная область описывается на следующих подуровнях:

· Определение требований

· Спецификация проекта

· Описание реализации

Размещено на http://www.allbest.ru/

Инструментальная система ARIS:

· 105 типов моделей для описания деятельности предприятия

· Более 250 типов объектов, описывающих различные аспекты предметных областей

· Более 600 различных типов связей, описывающих различные отношения между объектами предметной области

· Встроенные механизмы управления, проверки, анализа, экспорта/импорта, архивирования моделей

Возможные действия над моделями:

· Семантические проверки корректности моделей

· Cоставление отчетов по моделям

· Сравнение моделей

· Организация и управление непрерывным улучшением модели

· Копирование моделей

· Создание вариантов моделей

· Генерация моделей на основе существующих моделей

· Перенос моделей из одной базы данных в другую

· Экспорт/импорт моделей в другие программные системы

· Хранение моделей, в том числе и в виде резервных копий

· Очищение моделей от неиспользуемых объектов

· Консолидация множественных определений объектов моделей

Архитектура ARIS

Возможные конфигурации среды ARIS (Рис. 24):

Размещено на http://www.allbest.ru/

Рис.24 Конфигурации ARIS

Семейство программных продуктов ARIS фирмы IDS Scheer AG (Рис.25):



Рис. 25 Семейство программных продуктов ARIS фирмы IDS Scheer AG

Рассмотрим функциональное насыщение основных компонент платформы ARIS:

ARIS Easy Design

· Графическая среда для моделирования бизнес-процессов

· Поддержка многоязычных моделей

· Конфигурация клиент-сервер

· Стандартный интерфейс Explorer Windows

· Возможность доступа в Internet

ARIS Toolset

Дополнительные функции (к функциям ARIS Easy Design)

· конфигурация/настройка фильтров

· определение форм отчетов

· консолидация объектов

· проверка соответствия модельным соглашениям

· анимация «бизнес-вариантов»

· ведение репозитория

ARIS ABC

· Дополнительный модуль, подключаемый к среде ARIS Toolset, позволяющий реализовывать анализ стоимости бизнес-процессов на основе ABC-методологии

ARIS Simulation

· Модуль имитационного моделирования. Используется в случае необходимости динамического моделирования разработанных моделей бизнес-процессов.

ARIS BSC

· Модуль стратегического анализа и управления. Позволяет анализировать достижение стратегических целей и их взаимосвязь с текущей деятельностью.

Модуль ARIS Quality Management Scout

· Модуль ARIS Quality Management Scout может быть использован при создании процессно-ориентированной системы управления качеством или при приведении существующей системы управления качеством в соответствие требованиям стандартов ISO 9000:2000.

· ARIS Quality Management Scout предоставляет проверочные листы, вопросники по аудиту СМК и другую помощь, облегчающую выполнение индивидуальных действий.

Модуль ARIS Process Risk Scout

· Модуль ARIS Process Risk Scout - это инструментальное средство, предназначенное для создания и эксплуатации системы управления рисками.

· ARIS Process Risk Scout охватывает полный жизненный цикл проекта по управлению рисками от определения политики в отношении рисков и их анализа до быстрого получения отчетов о рисках всей компании и управления ими.

Модуль ARIS Process Performance Manager

· ARIS Process Performance Manager автоматически собирает данные о производительности непосредственно из бизнес-процессов компании, в частности, данные из нескольких различных информационных систем, например, таких как ERP-, SCM- и CRM-системы.

· Главную роль играют бизнес-процессы, реализованные в качестве информационных систем фирмы SAP

ARIS Web Publisher

· ARIS Web Publisher используется в тех случаях, когда надо разместить информацию о бизнес-процессах в Интернет.

· Модуль ARIS Web Publisher помогает публиковать модели бизнес-процессов в Интернет и интранет.

· Web-интерфейс модуля позволяет всем служащим компании сразу знакомиться со всеми изменениями бизнес-процессов, позволяет преодолевать пространственные и географические барьеры между различными подразделениями компании.

Модуль ARIS Web Designer

· Модуль ARIS Web Designer позволяет всем территориально удаленным служащим компании совместно проектировать бизнес-процессы. Он обеспечивает пользователям компании доступ к центральной базе данных бизнес-процессов.

ARIS Server

· Модуль, необходимый для поддержки коллективной работы, который содержит:

ь средства организации многопользовательского режима, управления работой пользователей

ь хранилище, используемое всеми подключенными пользователями

ь средства обмена данными между БД проектов

ь средства проверки на непротиворечивость внутреннего представления данных

Организационное представление ARIS



Размещено на http://www.allbest.ru/

Рис.26 Диаграммы организационного представления ARIS

Организационная схема (Organizational chat) - предназначена для моделирования организационной структуры предприятия с различной степенью детализации.

...