Информационные процессы и системы синергия. ответы тут. Тема Основные концепции и понятия теории информационных процессов и систем Цели изучения темы познакомиться с понятиями информационная система
 Скачать 1.18 Mb.
|
|
Тема 5. Моделирование деловых процессов. Цели изучения темы: познакомиться с постановкой задачи моделирования деловых процессов в контексте создания информационных систем; познакомиться с основными подходами к моделированию деловых процессов. Задачи изучения темы: изучить основные термины и понятия, относящиеся к моделированию деловых процессов; познакомиться с наиболее известными методологиями моделирования деловых процессов. Успешно изучив тему, Вы: Получите представление о: сущности, назначении и применении деловых моделей; методиках, применяемых для создания деловых моделей; проблемах и тенденциях развития методик создания деловых моделей. Будете знать: требования к деловым моделям; особенности и средства конкретных методологий, таких IDEF; основные принципы процесса разработки деловых моделей. Вопросы темы: 1. Деловые процессы и их моделирование. 2. Методология моделирования IDEF. 3. Язык моделирования UML. 4. Автоматизация моделирования деловых процессов. Вопрос 5. Деловые процессы и их моделирование. Как уже отмечалось, информационная система в настоящее время должна рассматриваться не как самостоятельная единица, а в ее тесной взаимосвязи с основной деятельностью предприятия или структуры, в которую она включается как органическая составная часть. Поэтому требования к системе формулируются на основе детального рассмотрения всех протекающих в реальной системе (организации, структуре) деловых процессов, к которым будем относить любой вид регулярно выполняющихся действий или операций, направленных на достижение одной или нескольких определенных целей и имеющих (или использующих) необходимый для этого набор ресурсов. Здесь следует сделать небольшое отступление. Часто английский термин business process в отечественной литературе дается в транслитерированном виде – бизнес-процесс. Оставляя без обсуждения возможные в подобных случаях издержки для русского языка, заметим, что перевод термина на русский язык (деловой процесс) более точно передает его смысл. Английское business означает (согласно словарю, Merriam-Webster) деятельность преимущественно коммерческого характера. Однако в данном контексте под термином business process подразумеваются процессы, протекающие не обязательно в коммерческих организациях, к ним могут относиться процессы, протекающие, например, в органах государственного управления или благотворительных организациях. На этот расширительный смысл термина авторы книг на английском языке часто особо обращают внимание читателя. В русском языке слово деловой в отличие от английского business не несет никакого коммерческого оттенка, поэтому в дополнительных разъяснениях необходимости нет. Цели выражают желаемое состояние ресурсов, которое достигается в результате протекания процессов. Цели формулируются в виде одного или нескольких правил. Понятие ресурс включает объекты, которые использует или потребляет процесс. В качестве таких объектов могут быть выступать люди, сырье, информация или произведенный продукт. Ресурсы образуют связанные между собой структуры. Ресурсы могут представлять собой объекты, которые потребляются или подвергаются преобразованию, такие как сырье в материальном производстве. Этот вид ресурсов относится к входным ресурсам. Выходными ресурсами являются конечные результаты, имеющие ценность для их получателя, и могут представлять собой совершенно новый объект или объект, получившийся как преобразование входных ресурсов. В задачах анализа бывает полезно классифицировать ресурсы на материальные (физические), абстрактные и информационные. Правило (деловое правило) представляет собой утверждение относительно каких-либо характеристик деловых процессов или наложенных на них ограничений. Правила могут отражать особенности внешней среды и иметь вид законов, постановлений, государственных или местных стандартов, либо диктоваться внутренними условиями в виде установленных корпоративных стандартов и нормативов, распорядка или регламента. Они могут указывать способ, которым должны выполняться операции, требования к составу и параметрам промежуточных и итоговых результатов, вводить ограничения на использование ресурсов, задавать последовательность выполнения отдельных операций. Правила можно классифицировать на функциональные, поведенческие и структурные. Формулировку целей и распределение ресурсов осуществляет владелец деловых процессов. Проектирование среды протекания деловых процессов, их логической структуры и параметров, определение потребностей характера необходимых ресурсов, их объема и распределения входят в задачу аналитика, которую он решает в типичном случае на основе разработанной им модели. Моделирование деловых процессов преследует цель получить абстракцию реально протекающих процессов, предоставив тем самым возможность всем лицам, имеющим отношение к работе предприятия, во-первых, понять текущее состояние, и, во-вторых, определить пути для его улучшения и инноваций. Последние термины нуждаются в уточнении. Под улучшением деловых процессов понимаются их небольшие поэтапные изменения, носящие непрерывный эволюционный характер. Инновации означают существенные изменения, носящие дискретный характер. Дающие потенциальную возможность значительно повысить эффективность деловых процессов инновации вместе с тем характеризуются высоким уровнем риска неудачи. Наиболее радикальным видом инноваций является реинжиниринг деловых процессов, применение которого может, с одной стороны, повысить эффективность в несколько раз, с другой стороны, увеличивает риск. Одним из основных вариантов инновации является внедрение информационной системы, и здесь деловая модель помогает решить одну из главных задач, решаемых на начальных этапах ее жизненного цикла. Если под архитектурой информационной системы понимать совокупность элементов и отношений между ними, которые формируют систему с ее основными функциями, то этой главной задачей является задача определения архитектуры системы и требований к ее параметрам. Реализация (физическое воплощение) системы может происходить по-разному ( Рис. 3), главное, чтобы информационная система (или несколько систем) представляла собой органичную составляющую всей системы.  Рис. 3. Взаимосвязи моделей и систем Построение деловой модели (более точно, модели деловой среды, предприятия, объекта) позволяет не только значительно снизить уровень риска за счет выявления возможных узких мест и упущений. Применение современных методов разработки моделей дает возможность использовать одну и ту же модель для анализа и проектирования на ее основе различных реализаций информационной системы, что положительно сказывается на стоимости внедрения. Другими важными задачами, решение которых обеспечивает деловая модель, являются задачи обучения персонала предприятия и выявление возможных вариантов для аутсорсинга – передачи каких-либо из выполняемых функций (действий процесса) сторонним исполнителям. Задачей разработчика системы является создание и внедрение поддерживающей деловые процессы информационной системы путем разработки новой или адаптации какой-либо существующей ее реализации. Правильно составленная деловая модель позволяет, как отмечено выше, применять ее для определения архитектуры информационной системы. В частности, с помощью деловой модели можно достаточно точно определить такие требования к программному обеспечению информационной системы как: наиболее подходящий для данной деловой модели тип информационной системы (новая, типовая, наследованная); функции, которые должна выполнять система; тактико-технические характеристики системы. Однако перенос компонентов деловой модели в модель программной архитектуры не может осуществляться чисто формально и требует приложения определенных усилий. С другой стороны, обратившись к истории можно констатировать, что задача разработки программной архитектуры возникла значительно раньше, чем задача моделирования деловых процессов, и в течение этого периода для моделирования архитектуры программного обеспечения появилось довольно много методов и инструментальных средств. Несмотря на то, что прямое применение этих методов и инструментальных средств к моделированию деловых процессов невозможно, ряд подходов, предложенных для моделирования деловых процессов, основан на адаптации методологий моделирования программного обеспечения, в типичном случае - путем включения в языки моделирования специальных дополнений. В число наиболее широко применяемых методологий входят методология IDEF и язык моделирования UML. Вопрос 6. Методология моделирования IDEF. Методология IDEF (Integrated DEFinition) была разработана в 1970-х годах в рамках программы ВВС США под названием ICAM (Integrated Computer Aided Manufacturing). Первоначально методология предназначалась для моделирования систем производственного назначения и включала метод функционального моделирования IDEF0, метод концептуального моделирования IDEF1 и метод спецификаций моделей динамических систем IDEF2. В дальнейшем методология была дополнена другими методами и стала широко применяться для моделирования деловых процессов. В настоящее время в нее входят методы от IDEF0 до IDEF14 (IDEF7 к настоящему времени не реализован). Наиболее часто используемыми методами являются IDEF0, IDEF1х, IDEF3 и IDEF4. В силу своих интуитивно понятных не подготовленному читателю изобразительных средств, упрощающих и повышающих надежность взаимодействия аналитиков и конечных пользователей, методы моделирования IDEF получили довольно широкое распространение и продолжают совершенствоваться. Для целей моделирования деловых процессов применяются в основном методы IDEF0 и IDEF3, в основу которых положены графические языки описания моделируемых объектов и процессов. Начальный этап построения модели требует принятия решения по нескольким ключевым вопросам, которые уже обсуждались в разделе, посвященном основам системного анализа настоящего курса. В частности, разработчиками должны быть определены: Назначение модели. В первую очередь, определяется тип создаваемой модели выбором из двух возможностей: Как есть (AS IS) - описание существующей деловой среды. Как должно быть (TO BE) - описание желаемой деловой среды, построенной с применением средств автоматизации деловых процессов. Границы моделирования. Специфицируется широта охвата в смысле включаемых в рассмотрение компонентов деловой среды, деловых процессов и глубина детализации их описаний. Решения во многом предопределяются решением по назначению модели. Целевая аудитория. Определяется круг заинтересованных лиц, для которых создаются модель. Точка зрения. Выбирается перспектива, под которой наблюдается деловая среда в процессе создания модели. При необходимости могут создаваться несколько моделей, отображающих различные точки зрения (например, пользователь услуг предприятия, системный администратор, финансовый директор). IDEF0. Метод IDEF0 предназначен для разработки функциональных моделей, т.е., спецификаций того, что должна делать система. В основу метода положена методика SADT (Structured Analysis and Design Technique), разработанная в 1970-х годах. С помощью IDEF0 аналитик может описать деловые процессы, отображая также существенные для понимания объекты типа вход, выход, управление и механизм (исполнительный механизм). Эти объекты, которые часто именуются также как ICOM (Input-Control-Output-Mechanism), определяются следующим образом ( Рис. 4): входы представляют собой ресурсы, потребляемые или подвергаемые преобразованию описываемым процессом; выходы представляют собой некоторые объекты, появляющиеся как результат потребления или преобразования входов; управления представляют собойнекоторые объекты, организующие и контролирующие протекание процесса - стратегии, законы, правила, стандарты; механизмы представляют собой объекты и субъекты, участвующие в выполнении отдельных операций процесса, такие как люди или устройства и оборудование.  Рис. 4. Общий вид IDEF0-диаграммы Название функции записывается в функциональном (процессном) блоке в виде глагола повелительном наклонении или отглагольного существительного. На Рис. 5 показан пример IDEF0-диаграммы.  Рис. 5. Пример IDEF0-диаграммы Основным методологическим приемом IDEF0 является декомпозиция – каждый функциональный блок может быть представлен своим более подробным описанием в виде отдельной (дочерней) диаграммы, на которой могут присутствовать несколько соединенных между собой функциональных блоков (Рис. 6).  Рис. 6. Декомпозиция блоков IDEF0-диаграмм Иерархия связей между родительской и дочерними диаграммами отображается системой обозначений блоков диаграмм. Так на Рис. 6 блок диаграммы высшего уровня (контекстной диаграммы) обозначается А0, блоки дочерней диаграммы – А1, А2, А3, А4. Следующая диаграмма, показанная на рисунке, является декомпозиций блока А4, три блока которой обозначаются А41, А42, А43. Наконец, последняя диаграмма рисунка, дочерняя для блока А42, содержит блоки с обозначениями А421, А422, А423. Стрелки IDEF0-модели могут, как разветвляться, так и сливаться, причем слияние сохраняет за каждой стрелкой ее содержательную идентичность. Часть стрелок может туннелироваться, т.е., стрелки могут впервые появляться только на дочерней диаграмме некоторого уровня, оставаясь на всех родительских диаграммах скрытыми. Допускается также и обратное – можно отменить присутствие ненужных стрелок на всех дочерних диаграммах. Такая возможность позволяет избежать загромождения диаграмм верхних уровней излишними деталями (в первом случае) или, наоборот, сведениями слишком неконкретного характера (во втором). На IDEF0-диаграммах туннели обозначаются парой круглой скобок, стоящих в начале стрелки (скрытой на родительских диаграммах) или в конце стрелки (скрытой на дочерних диаграммах). На Рис. 7 показан пример, иллюстрирующий описанные механизмы.  а) контекстная диаграмма  б) диаграмма декомпозиции блока А0  в) диаграмма декомпозиции блока А3 Рис. 7. Пример декомпозиции Помимо примеров сливающихся и ветвящихся стрелок на рисунке присутствует и пример туннеля в виде стрелки «Поваренная книга» диаграммы декомпозиции блока А3. Однако метод IDEF0 не позволяет дать представление о хронологии протекания процессов, иначе говоря, диаграмма отражает только состав функций, но не логическую последовательность их выполнения. Элементы диаграммы могут содержать сведения относительно условий выполнения функций, но не сведения о том, каковы должны быть условия для того, чтобы процесс мог начаться, или в какой момент процесс будет завершен. Описание этих характеристик может быть получено с помощью средств моделирования IDEF3. IDEF3. Аналогично методу IDEF0 объектом рассмотрения метода IDEF3 являются деловые процессы предприятия. Модель IDEF3 дополняет описание системы IDEF0-модели информацией о динамических (поведенческих) аспектах протекающих в системе процессов. При этом в отличие от IDEF0-модели IDEF3-модель может сочетать в себе несколько описаний (представлений) о временных предшествованиях процессов. По этой причине итог применения метода правильнее, строго говоря, характеризовать как частично формализованное описание системы, но не как модель. Изобразительные средства включают два подхода. В первом из них, в диаграммах протекания процесса, сведения о процессах представляются в виде сценария, отдельными единицами описания которого являются действия, или работы (activity), называемые UOB (Unit Of Behavior - единица поведения), или UOW (Unit Of Work - единица работы). Применительно к конкретной задаче UOB может представлять отдельную функцию, действие, операцию или процесс. Связи с блоками IDEF0 устанавливаются посредством механизма ссылок. Связи между действиями (arrow, link) могут быть трех типов:
Аналогично имеющейся в методе IDEF0 возможности декомпозиции функциональных блоков, действия (UOB) в модели IDEF3 также могут декомпозироваться, поэтому для номера действия обычно используется десятичная нотация (Рис. 8).  Рис. 8. Нумерация действий в модели IDEF3 На Рис. 9 показан пример IDEF3-диаграммы процессов.  Рис. 9. Диаграмма протекания процесса в модели IDEF3 Действие J1 на Рис. 9 означает, что в данной точке осуществляется обязательный выбор ровно одного из двух возможных направлений дальнейшего протекания процесса: будет выполняться либо действие 4, либо действие 5. J1 представляет собой один из трех определяемых в методе IDEF3 видов соединений, или перекрестков (junction). Помимо показанного на Рис. 9 разворачивающего соединения Исключающее (Эксклюзивное) ИЛИ в IDEF3 определены и другие типы, перечень которых приведен в Таблица 4. Таблица 4. Соединения в IDEF3
Буква Р в Таблица 4означает разворачивающее соединение (Fan-out Junction), буква С- сворачивающее соединение (Fan-in Junction). На Рис. 10 и Рис. 11 показаны примеры использования разворачивающих и сворачивающих соединений ИЛИ и И.  Рис. 10. Пример использования соединений типа ИЛИ  Рис. 11. Пример использования соединений типа И В модели IDEF3 может также отражаться зависимость между моментами начала действий, выходящих из соединения, или окончания действий, входящих в соединения. В отличие от рассмотренных в примерах асинхронных соединений, где моменты начала или окончания могут быть отличаться друг от друга, в синхронных соединениях, обозначаемых на диаграммах прямоугольниками с двумя вертикальными линиями вместо одной, эти моменты должны совпадать. Диаграммы переходов состояний объектов в IDEF3 отражают видение происходящего в изучаемой системе с точки зрения возможных изменений состояний объекта, который подвергается трансформации или обработке в результате процесса. Эти диаграммы состоят символов, означающих состояние объекта (окружности), символов перехода из одного состояния в другое (стрелки) и объектов ссылок (прямоугольники). Состояния определяются как значения существенного свойства (признака) объекта и условий. Переходы осуществляются в зависимости от выполнения предусловий или постусловий. На Рис.12 показан пример диаграммы переходов (диаграмма процесса этого же примера показана на Рис. 9).  Рис.12. Диаграмма состояний в модели IDEF3. Описание исследуемой системы, представленное средствами методики IDEF3, является достаточно подробным для построения на его основе моделей для количественного оценивания показателей системы, в частности, аналитических и имитационных моделей, которые будут рассмотрены далее. Вопрос 7. Язык моделирования UML. Язык UML (Unified Modelling Language - Единый Язык Моделирования) появился в результате развития методов объектно-ориентированного анализа и проектирования конца 1980-х – начала 1990-х годов. На этом языке основана, в частности, известная методология проектирования и разработки программного обеспечения фирмы IBM называемая RUP (Rational Unified Process). Язык UML образуют множество символов и множество правил. В языке определены девять типов диаграмм, из которых для моделирования деловых процессов применяются семь. Диаграммы классов (class diagram) служат для описания структуры моделируемой системы и содержат спецификации классов и отношений между классами. Классами могут быть информация, продукция, документы или организации. Пример диаграммы классов показан на Рис. 13 (на концах связей поставлены обозначения кратности и указаны роли, которые каждый класс играет в данном отношении).  Рис. 13. Пример диаграммы классов Классы связываются друг с другом с помощью ассоциаций (связей, отношений - association), которые могут представлять собой агрегат (aggregation - целое, составленное из частей), композицию (composition - специальный тип агрегата, в котором действуют ограничения на владение и время жизни), обобщение (generalisation) и зависимость (dependency). На диаграммах виды ассоциаций отображаются в виде различных окончаний у стрелок, связывающих классы (на Рис. 13 ассоциация обозначена треугольным маркером и дополнена именем, показывающим природу отношений между объектами). Диаграммы объектов (object diagram) представляют множество объектов - экземпляров классов, присутствующих на диаграмме классов для специфических ситуаций (в некоторый момент времени). Диаграммы состояний (statechart diagram) служат для описания основных этапы жизненного цикла объектов или систем путем отображения возможных их состояний и событий, которые могут перевести их в другое состояние (Рис. 14).  Рис. 14. Пример диаграммы состояний Диаграммы деятельности, или активности (activity diagram) описывают действия и мероприятия, происходящие в системе. Их можно использовать для отображения последовательности выполнения отдельных этапов деловых процессов (Рис. 15).  Рис. 15. Пример диаграммы деятельности Диаграммы последовательностей действий (sequence diagram) описывают передачу сообщений между множеством объектов. На ней точно воспроизводятся логическая последовательность и хронология действий, сообщения могут быть как синхронными (выполняться полностью до начала каких-либо действий), так и асинхронными (отправитель не ждет ответа перед продолжением своих действий), снабжаться параметрами и указателями. Диаграммы кооперации (collaboration diagram) схожи с диаграммами последовательности действий, но могут отображать более сложные правила взаимодействия между объектами. Информативность достигается за счет усложнения восприятия этих диаграмм. Диаграммы вариантов использования, или прецедентов (use case diagram) применяются для описания функций системы. Прецедент характеризует конкретное использование возможностей системы актором, или актантом (actor), обозначающим пользователя каких-либо возможностей системы. Диаграмма отражает взаимосвязи между прецедентами, каждый из которых может включать какой-либо прецедент, расширять какой-либо прецедент или быть обобщением других прецедентов. Диаграммы компонентов используются для описания компонентной структуры программных систем и для моделирования деловых процессов не применяются. Диаграммы развертывания (deployment diagram) представляют собой диаграммы классов, описывающих отображение оборудование - программное обеспечение, и для моделирования деловых процессов не используются. С тем, чтобы предоставить пользователям возможность адаптировать язык к их специфическим потребностям, в языке предусмотрены средства его расширения. В состав этих средств входят следующие: Стереотипы (stereotypes), позволяющие разработчику добавлять новые конструктивные блоки на основе существующего набора. Именованные значения (tagged values) содержат дополнительные сведения в виде пары тег–значение (tag-value), которыми можно снабжать любой элемент UML-модели. Ограничения (constraints) отображают правила, применяемые в UML-модели, которые можно записать на языке описания ограничений OCL (Object Constraint Language), являющимся составной частью языка UML. При моделировании деловых процессов OCL применяется для описания деловых правил. Спецификации языка содержат также «Расширения UML для моделирования деловых процессов», описывающие возможные расширения и правила их применения для моделирования деловых процессов. Однако в силу того, что возможностей языка для моделирования деловых процессов недостаточно, некоторыми авторами предложены свои расширения UML. В качестве примера таких расширений можно указать метод Эриксона-Пенкера (Eriksson-Penker). Язык OCL используется в этом методе для описания деловых правил. Деловой процесс представляется образцом на диаграмме деятельности (как деятельность со стереотипом <<process>>), процесс использует входные ресурсы (левая часть диаграммы) и формирует выходные ресурсы (правая часть диаграммы). Основными объектами в процессной модели являются объекты цели (goal), входа (input), выхода (output), поставки (supplying), управления (control). Обобщенная диаграмма процесса показана на Рис. 16.  Рис. 16. Обобщенный вид диаграммы процесса. Нетрудно видеть, что диаграмма имеет много общего IDEF0-диаграммой, что свидетельствует о том, что, несмотря на различие изобразительных средств, обе методологии строятся на одинаковых концепциях. Диаграмма деятельности используется в модифицированном виде под названием диаграмма сборочной линии (assembly line). Обычно эти диаграммы служат для представления информационных объектов информационной системы и показывают, как осуществляется доступ к информации и как она используется в процессах, которые показываются в их верхней части диаграммы. Обобщенный вид диаграммы показан на Рис. 17, R-read (чтение), W-write (запись).  Рис. 17. Обобщенный вид диаграммы сборочной линии Диаграммы сборочной линии связаны с диаграммами вариантов использования, так как отображают интерфейс между деловыми процессами и информационной системой. Для обеспечения возможности повторного использования разработанной модели для описания схожих процессов можно применять механизм шаблонов, или паттернов (pattern), которые классифицируются по их применению. Для целей моделирования деловых процессов также предложен ряд шаблонов. Вопрос 8. Автоматизация моделирования деловых процессов. К настоящему времени разработано довольно много программных продуктов, поддерживающих процессы разработки моделей по различным методикам, в частности, IDEF и UML. Степень автоматизации варьируется в широком диапазоне. Средства нижнего уровня, например, MS Office Visio предоставляют средства графического интерфейса. Программы промежуточного уровня, например, CA AllFusion Business Process Modeler - BPwin помимо изобразительных средств позволяют проводить проверку корректности построенных моделей. Средства верхнего уровня (CASE-системы) автоматизируют основные этапы системного анализа с возможностью генерации схем баз данных, программного кода на различных языках и выпуска проектной документации. В качестве примеров таких систем можно назвать системы ARIS и IBM Rational Rose. Выбор конкретного средства зависит, в первую очередь, от масштаба проектируемой системы (предприятия), а также от состава группы аналитиков (консультантов) – увеличение численных характеристик будет смещать предпочтения при выборе от наиболее простых систем автоматизации в сторону более крупных. Пакеты распространяются на коммерческой основе (как указанные выше), свободно распространяются в виде дистрибутивных файлов (Design/IDEF) или доступны для бесплатного применения через Веб-интерфейс (IDEF0 on WEB for free using http://e-a-m.ru/rsvIDEF0net.aspx, http://e-a-m.ru/Docs/Help.htm). Есть продукты (например, EAM IDEF0\Doctor) снабженные исходными текстами, что позволяет проводить их функциональную адаптацию к потребностям конкретных пользователей. В Приложении к курсу содержатся краткие сведения относительно функциональных возможностей, правил и порядка работы с пакетом Design/IDEF, которыми можно воспользоваться для выполнения практического задания по настоящей теме. Выводы: Эффект внедрения информационной системы определяется в первую очередь степенью ее интеграции с деловой средой. Средством повысить вероятность успеха внедрения, выявить архитектуру будущей системы и сформулировать перечень требований к ней является модель деловых процессов, содержащая их максимально точное описание. Создание и применение деловых моделей может вестись с использованием различных методологий и стандартов. Одними из наиболее широко распространенных подходов к моделированию являются методики семейства IDEF и язык UML. Преимуществами первой методологии являются простота применения и понимания конечными пользователями, вторая методология, базируясь на объектно-ориентированном подходе, позволяет автоматизировать преобразование созданной деловой модели в программный код. Большинство известных подходов к моделированию деловых процессов строятся на базовых принципах и методиках общей теории систем и системного анализа, в частности, таких как иерархичность и декомпозиция. Несмотря на различия в средствах описания, методологии (в частности, IDEF и UML) не имеют принципиальных отличий и которые позволяют представить в достаточном объеме существенные сведения о моделируемых деловых процессах. Вопросы для самопроверки: 1. Что называется деловым процессом? 2. Что понимается под целью процесса? 3. Что такое ресурс процесса?? 4. Какие выделяются виды ресурсов? 5. Что такое деловое правило? 6. Как классифицируются деловые правила? 7. В чем состоят отличия между улучшением, инновацией и реинжинирингом? 8. Что понимается под архитектурой информационной системы? 9. Какие выгоды можно получить от создания деловой модели? 10. Какие требования к программному обеспечению информационной системы дает возможность сформулировать деловая модель? 11. Что представляет собой методология IDEF? 12. Какие методы методологии IDEF в основном используются для моделирования деловых процессов? 13. Какие требования и ограничения необходимо определить до начала разработки IDEF0-модели? 14. Как можно классифицировать IDEF0-модели по их назначению? 15. Из каких конструктивных единиц состоит IDEF0-модели? 16. Какие объекты определены в IDEF0-модели? Дайте краткую характеристику каждому типу. 17. В чем состоит сущность приема декомпозиции IDEF0-диаграммы? 18. Какие термины используются для отображения иерархии IDEF0-диаграмм? 19. Что такое туннель и для чего он используется? 20. Что не позволяют и что не позволяют отобразить IDEF0-модели? 21. Какую информацию можно представить с помощью IDEF3-модели? 22. Какие виды изобразительных средств могут применяться в IDEF3-модели? 23. Что понимается под терминами сценарий и действие в IDEF3-модели? 24. в IDEF3-модели? 25. Какие типы связей между действиями могут задаваться в IDEF3-модели? 26. Что понимается под соединением в IDEF3-модели, какие существуют виды соединений? 27. Что отражает диаграмма переходов состояний объектовв IDEF3-модели? 28. Что представляет собой язык UML? Какие множества элементов образуют выразительные средства языка? 29. Какие диаграммы определены в языке UML? 30. Для чего нужны расширения языка UML? 31. Какие средства расширения существуют в языке UML? 32. Для чего применяется метод Эриксона-Пенкера? 33. Как представляется деловой процесс в методе Эриксона-Пенкера? 34. Какие сведения даются с помощью диаграммы сборочной линии в методе Эриксона-Пенкера? 35. Дайте сравнительную характеристику подходам к построению деловых моделей на основе методологий IDEF и UML. Литература по теме: Основная литература: 1. Козлов А.С. Проектирование и исследование бизнес-процессов – М.:Флинта, 2011 – 268 с. – То же [Электронный ресурс]. URL: http://biblioclub.ru/. Дополнительная литература: 1. С.В.Черемных, И.О.Семенов, В.С.Ручкин Моделирование и анализ систем. IDEF-технологии: практикум, М., Финансы и статистика, 2005.-192с. 2. Д. Марка, К. Макгоуэн. SADT™. Методология структурного анализа и проектирования. – М.:МетаТехнология, 1993 - 240 с. 3. Г. Буч, Д. Рамбо, А. Джекобсон. Язык UML. Руководство пользователя - М.: ДМК Пресс, 2003. - 432 с 4. Hans-Erik Eriksson. Business Modeling with UML: Business Patterns at Work/ Hans-Erik Eriksson, - Magnus Penker John Wiley & Sons, 2000 -459 p. 5. Noran O. Business modeling:UML vs. IDEFGriffith University, 2002. |