Метод под названием Структурный анализ процессов (Structured Process Analysis, SPA), разработанный компанией, использует принципы, взятые из теории моделирования данных. Он основан на принципе иерархии процессов. Как уже стало видно, процесс можно разбить на составляющие его субпроцессы. Если изучаемый процесс охватывает несколько отделов, то в этом случае сами субпроцессы скорее всего будут достаточно сложными и могут включать виды работ, выполняемые больше, чем одним отделом. Можно далее разделить каждый субпроцесс на главные виды работ, выполняемые внутри его, а каждый вид, в свою очередь, на отдельные работы. Например, процесс найма нового сотрудника включает в себя работу по рекламе имеющейся вакансии, работу по описанию рабочего места и требований к кандидату. Это в свою очередь включает в себя отдельные работы типа набора в текстовом редакторе требований к кандидату.

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

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

Способы описания бизнес-процессов

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

В настоящее время существуют три основных способа описания:

1. Текстовый: "Отдел продаж составляет договор и согласует его с юридическим отделом".

2. Табличный.

3. Графический.

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

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

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

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

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

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

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

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

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

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

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

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

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

Поскольку бизнес-процессы - это потоки работы - в них есть свои границы, другими словами начало и конец. Для любого отдельно взятого процесса эти границы установлены начальными или первичными входами, с которого он начинается (рис. 9.1) Эти входы открываются первичными поставщиками процесса. Ресурсы или входы процесса могут быть материально-техническими, энергетическими, человеческими, информационными.

Рис. 9.1. в

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

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

Первичные клиенты - те, которые получают первичный выход;

Вторичные клиенты, которые находятся вне процесса и получают вторичные выходы;

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

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

Внешние косвенные клиенты, потребители.

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

Таблица 9.1. КЛАССИФИКАЦИЯ БИЗНЕС-ПРОЦЕССОВ ПРЕДПРИЯТИЯ

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

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

Курсовой проект

по дисциплине: «Проектирования информационных систем»

Проектирование АИС «Детский развивающий центр»

Выполнила: студентка 4 курса

Тихонова К.В.

Введение

Дети – цветы жизни! В маленьком возрасте дети как "губки", впитывают в себя очень много материала и чем раньше начать с ним заниматься, тем более развитым он становиться.

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

Целью данного курсового проекта является разработка АИС «Детского развивающего центра». Для достижения поставленной цели следует выполнить несколько задач:

1. Проанализировать данную предметную область;

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

3. По результатам анализов создать информационную систему.

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

Глава 1. Анализ объекта исследования и разработке моделей его функционирования

Описание предметной области

Описание предметной области является одним из наиболее важных этапов работ при проектировании программных систем предприятий различного масштаба.

Основные задачи Детского развивающего центра:

1)привлечение клиентуры;

2)регистрация детей в детском центре;

3)проведение учебных и развивающих занятий, а также лечебно-восстановительных процедур;

4)подведение итогов деятельности ребенка;

5)выпуск ребенка из детского центра.

Направления работы Детского развивающего центра:

Возрастные курсы развития, а именно:

*Курсы для детей от 9 месяцев до 1,5 лет

*Курсы для детей от 1,5 до 2,5 лет

*Курсы для детей от 2,5 до 4 лет

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

*Занятия с психологом

*Занятия с логопедом

*Развивающие кружки, такие, как: гимнастика, изобразительное искусство, театральная деятельность, музыка, танцы. Орг.Структура Детского развивающего центра изображена на рис 1.1.

Рис. 1.1. Орг.структура детского центра

1.2 Структурный анализ бизнес-процессов

Описание бизнес-процессов.

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

Этапы описания бизнес-процессов:

Определение целей описания.

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

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

Описание потоков (материальных, информационных, финансовых) процесса, построение DFD-диаграмм.

Построение организационной структуры процесса (отделы, участники, ответственные). На рисунке 1.2 представлена контекстная диаграмма информационной системы «Детский развивающий центр», построенная при помощи BPwin:

Рис.1.2.Контекстная диаграмма

На входе в систему мы видим такие процессы, как «Данные ребенка и опекуна», «Регистрация детей в центре» и «Проведение оплаты за услуги». Это то, с чего в первую очередь сталкивается клиент перед самим процессом.

Для обеспечения работы процесса необходим обслуживающий персонал и учебный инвентарь. Также имеются такие входные документы, как «Законы РФ», «Нормативная документация» и «Лицензия», что говорит о правомерности работы Детского развивающего центра. Итогом работы всей системы является «Подведение итогов учебного процесса» и «Выпуск ребенка из детского центра».

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

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

Для получения более подробной информации, была проведена декомпозиция с третьим уровнем детализации. На рис.1.4 изображена диаграмма декомпозиции процесса «Составление индивидуального учебного плана».

Рис.1.4 Диаграмма декомпозиции «Составление индивидуального учебного плана».

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

Все этапы контролируются законами РФ, нормативной документацией и лицензией фирмы. Помимо данной методологии можно также использовать DFD. Диаграмма потоков данных (DFD) – это методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.

Рис.1.5 Диаграмма декомпозиции DFD «Проведение занятий»

На рис.1.5 что этап «Проведение учебных и развивающих занятий и лечебных процедур» разбита на 2 процесса. На входе первого процесса «Выбор системы обучения» расположена внешняя сущность «Учебный стандарт», что говорит о том, что все системы обучения, выбранные специалистами, должны соответствовать определенным учебным стандартам РФ. После выбора системы происходит составление плана занятия (урока) и соответственно проведение самого занятия. После прохождения всех этапов проводится проверка выполненной работы персонала (педагогов и мед.работников).

Далее при помощи IDEF3 был декомпозирован процесс «Регистрация ребенка в детском центре». IDEF3 показывает причинно-следственные связи между ситуациями и событиями в понятной эксперту форме, используя структурный метод выражения знаний о том, как функционирует система, процесс или предприятие.

Рис.1.6 Диаграмма декомпозиции IDEF3 «Регистрация ребенка»

При разработке организационной структуры предприятия, базирующейся на методологии реинжиниринга бизнес - процессов, одним из первых и наиважнейших шагов является анализ деятельности предприятия. Анализ начинается с выделения и описания бизнес-процессов, протекающих на предприятии .
Разработка модели реинжиниринга бизнес-процессов (БП) организации представляет собой сложную задачу, решение которой требует применения специальных методик и инструментов, в основе которых лежат методы структурного анализа.
Структурным анализом принято называть метод исследования системы, который начинается с общего ее обзора и затем детализируется, приобретая иерархическую структуру со все большим числом уровней. Для таких методов характерно :
- разбиение на уровни абстракции с ограничением числа элементов на каждом из уровней (обычно от 3 до 7, при этом верхняя граница соответствует возможностям человеческого мозга воспринимать определенное количество
взаимоувязанных объектов, а нижняя выбрана из соображений здравого смысла);
ограниченный контекст, включающий лишь существенные на каждом уровне детали;
использование строгих формальных правил записи;
последовательное приближение к конечному результату. Методы структурного анализа позволяют преодолеть сложность больших систем путем расчленения их на части («черные ящики») и иерархической организации этих «черных ящиков» . Преимущество использования «черных ящиков» заключается в том, что их пользователю не требуется знать, как они работают. Необходимо знать лишь его входы и выходы, а также его назначение (т. е. функцию, которую он выполняет). В окружающем нас мире «черные ящики» встречаются в большом количестве: магнитофон и телевизор на бытовом уровне, предприятие с позиций клиента и т. п.
Таким образом, первым шагом упрощения сложной системы является ее разбиение на «черные ящики» (принцип «разделяй и властвуй» - принцип решения трудных проблем путем разбиения их на множество независимых задач, легких для понимания и решения), при этом такое разбиение должно удовлетворять следующим критериям:
каждый «черный ящик» должен реализовывать единственную функцию системы;
функция каждого «черного ящика» должна быть легко понимаема независимо от сложности ее реализации (например, в системе управления ракетой может быть черный ящик для расчета места ее приземления: несмотря на сложность алгоритма, функция черного ящика очевидна - расчет точки приземления);
связь между «черными ящиками» должна вводиться только при наличии связи между соответствующими функциями системы (например, в бухгалтерии один черный ящик необходим для расчета общей заработной платы служащего, а другой - для расчета налогов. Необходимая связь между этими «черными ящиками» - размер заработанной платы требуется для расчета налогов);
- связи между «черными ящиками» должны быть простыми, насколько это возможно, для обеспечения независимости между ними.
Второй важной идеей, лежащей в основе структурных методов, является идея иерархии. Для понимания сложной системы недостаточно разбиения ее на части, необходимо эти части организовать определенным образом, а именно в виде иерархических структур. Все сложные системы Вселенной организованы в иерархии. Да и сама она включает галактики, звездные системы, планеты, молекулы, атомы, элементарные частицы. Таким образом, второй принцип структурного анализа (принцип иерархического упорядочения) в дополнение к тому, что легче понимать проблему, если она разбита на части, декларирует, что устройство этих частей также существенно для понимания. Понимаемость проблемы резко повышается при организации ее частей в древовидные иерархические структуры, т. е. система может быть понята и построена по уровням, каждый из которых добавляет новые детали.
Третий принцип: структурные методы широко используют графические нотации, также служащие для облегчения понимания сложных систем. Известно, что «одна картинка стоит тысячи слов».
Для целей структурного анализа традиционно используются три группы средств, иллюстрирующих:
функции, которые система должна выполнять;
отношения между данными;
¦ зависящее от времени поведение системы (аспекты реального времени).
Среди многообразия графических нотаций, используемых для решения перечисленных задач, в методологиях структурного анализа наиболее часто и эффективно применяются следующие:
DFD (Data Flow Diagrams) - диаграммы потоков данных совместно со словарями данных и спецификациями процессов (мини-спецификациями);
ERD (Entity-Relationship Diagrams) - диаграммы «сущность-связь»;
STD (State Transition Diagrams) - диаграммы переходов состояний.
Все они содержат графические и текстовые средства моделирования: первые - для удобства отображения основных компонент модели, вторые - для обеспечения точного определения ее компонент и связей.


Л
Классическая DFD показывает внешние по отношению к системе источники и стоки (адресаты) данных, идентифицирует логические функции (процессы) и группы элементов данных, связывающие одну функцию с другой (потоки), а также идентифицирует хранилища (накопители) данных, к которым осуществляется доступ. Структуры потоков данных и определения их компонент хранятся и анализируются в словаре данных. Каждая логическая функция (процесс) может быть детализирована с помощью DFD нижнего уровня; когда дальнейшая детализация перестает быть полезной, переходят к выражению логики функции при помощи спецификации процесса (мини- спецификации). Содержимое каждого хранилища также сохраняют в словаре данных, модель данных хранилища раскрывается с помощью ERD. В случае наличия реального времени DFD дополняется средствами описания зависящего от времени поведения системы, раскрывающимися с помощью STD. Эти взаимосвязи показаны на рисунке 2.3.
Перечисленные выше графические нотации используются (в том или ином наборе) практически во всех современных методологиях структурного системного анализа. Роль этих методологий заключается в регламентации основ разработки сложных систем. Они описывают последовательность шагов, модели и подходы.
В настоящее время успешно используются практически все известные методологии структурного анализа, однако наибольшее распространение получили:
методологии SADT (Structured Analysis and Design Technique);
структурного системного анализа Гейна -Сарсона (Gane-Sarson) ;
структурного анализа и проектирования Иодана-Де Марко (Yourdon- DcMarko) ;
развития систем Джексона (Jackson);
развития структурных систем Варнье-Oppa (Warmer- Orr);
анализа и проектирования систем реального времени У орд а- Меллора (Ward-Mellor) и Хатли (Hatley);
информационного моделирования Мартина (Martin) .
Перечисленные структурные методологии жестко регламентируют фазы анализа требований и проектирования спецификаций и отражают подход к системной разработке с позиций рецептов «кулинарной книги».
Основные символы и термины DFD (в нотация Иодана) представлены на рисунке 2.4.
Потоки данных являются механизмами , использующимися для моделирования передачи информации (или физических компонент) из одной части системы в другую. Потоки на диаграммах обычно изображаются именованными стрелками, ориентация которых указывает направление движения информации. Иногда поток может двигаться в одном направлении, обрабатываться и возвращаться назад в се источник. Такая ситуация может моделироваться либо двумя различными потоками, либо одним двунаправленным.
Назначение процесса состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса, Это имя должно содержать глагол в неопределенной форме с последующим дополнением. Кроме того, каждый процесс должен иметь уникальный номер для ссылок на него внутри диаграммы. Этот номер может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели. Компонента Обозначение Компонента Обозначение Поток данных Имя > Управляющий поток Имя Процесс ^Имя^ Управляющий процесс > \ t ъ
f Имя j
* /
4 У
^ t у Хранилище Имя Управляющее хранилище Имя Внешняя сущность Имя Узел смены имени Групповой узел Имя Узел смены типа Рисунок 2.4 - Основные символы диаграммы потоков данных
Хранилище (накопитель) данных (материалов) позволяет на определенных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет "срезы" потоков данных во времени. Информация (сырье, полуфабрикат), которую оно содержит, может использоваться в любое время после ее определения, при этом данные (объекты) могут выбираться в любом порядке. Имя хранилища должно
идентифицировать его содержимое и быть существительным. В случае, когда поток данных входит или выходит в/из хранилища, и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое нет необходимости отражать на диаграмме.
Внешняя сущность (или терминатор) представляет сущность вне контекста системы, являющуюся источником или приемником системных данных. Ее имя должно содержать существительное, например, склад товаров. Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке.
Декомпозиция DFD осуществляется на основе декомпозиции процессов - каждый процесс может раскрываться с помощью DFD нижнего уровня.
Важную специфическую роль в модели играет специальный вид DFD - контекстная диаграмма, моделирующая систему наиболее общим образом. Контекстная диаграмма отражает интерфейс системы с внешним миром, а именно, информационные потоки между системой и внешними сущностями, с которыми она должна быть связана, Она идентифицирует эти внешние сущности, а также, как правило, единственный процесс, отражающий главную цель или природу системы насколько это возможно. И хотя контекстная диаграмма выглядит тривиальной, несомненная ее полезность заключается в том, что она устанавливает границы анализируемой системы. Каждый проект должен иметь ровно одну контекстную диаграмму, при этом нет необходимости в нумерации единственного ее процесса.
DFD первого уровня строится как декомпозиция процесса, который присутствует на контекстной диаграмме.
Построенная диаграмма первого уровня также имеет множество процессов, которые в свою очередь могут быть декомпозированы в DFD нижнего уровня. Таким образом строится иерархия DFD с контекстной диаграммой в корне дерева. Этот процесс декомпозиции продолжается до тех пор, пока процессы могут быть эффективно описаны с помощью коротких (до одной страницы) миниспецификаций обработки (спецификаций процессов).
При таком построении иерархии DFD каждый процесс более низкого уровня необходимо соотнести с процессом верхнего уровня.
Индивидуальные данные в системе часто являются независимыми. Однако иногда необходимо иметь дело с несколькими независимыми данными одновременно. Например, в системе имеются потоки «яблоки», «апельсины» и «груши». Эти потоки могут быть сгруппированы с помощью введения нового потока «фрукты». Для этого необходимо определить формально поток «фрукты» как состоящий из нескольких элементов-потомков. Такие потоки, объединяющие несколько потоков, получили название групповых. Обратная операция, расщепление потоков на подпотоки, осуществляется с использованием группового узла, позволяющего расщепить поток на любое число подпотоков.
Аналогичным образом осуществляется и декомпозиция потоков через границы диаграмм, позволяющая упростить детализирующую DFD. Пусть имеется поток ФРУКТЫ, входящий в детализируемый процесс. На детализирующей этот процесс диаграмме потока «фрукты» может не быть вовсе, но вместо него могут быть потоки «яблоки» и «апельсины» (как будто бы они переданы из детализируемого процесса). В этом случае должно существовать БНФ-определение потока ФРУКТЫ, состоящего из подпотоков «яблоки» и «апельсины», для целей балансирования.
Применение этих операций над данными позволяет обеспечить структуризацию данных, увеличивает наглядность и читабельность диаграмм.
Для обеспечения декомпозиции данных и некоторых других сервисных возможностей к DFD добавляются следующие типы объектов:
групповой узел. Предназначен для расщепления и объединения потоков. В некоторых случаях может отсутствовать (т.е. фактически вырождаться в точку слияния/расщепления потоков на диаграмме);
узел изменения имени. Позволяет неоднозначно именовать потоки, при этом их содержимое эквивалентно. Например, если при проектировании разных частей системы один и тот же фрагмент данных получил различные имена, то эквивалентность соответствующих потоков данных обеспечивается узлом изменения имени. При этом один из потоков данных является входным для данного узла, а другой - выходным;
управляющий процесс. Представляет собой интерфейс между DFD и спецификациями управления, собственно моделирующими и документирующими аспекты реального времени. Его имя указывает на тип управляющей деятельности, вырабатываемой спецификацией. Фактически управляющий процесс представляет собой преобразователь входных управляющих потоков в выходные управляющие потоки; при этом точное описание этого преобразования должно задаваться в спецификации управления;
управляющее хранилище. Представляет «срез» управляющего потока во времени. Содержащаяся в нем управляющая информация может использоваться в любое время после ее занесения в хранилище, при этом соответствующие данные могут быть использованы в произвольном порядке. Имя управляющего хранилища должно идентифицировать его содержимое и быть существительным. Управляющее хранилище отличается от традиционного тем, что может содержать только управляющие потоки; все другие их характеристики идентичны;
управляющий поток представляет собой "трубопровод", через который проходит управляющая информация. Его имя не должно содержать глаголов, а только существительные и прилагательные. Обычно управляющий поток имеет дискретное, а не непрерывное значение. Это может быть, например, сигнал, представляющий состояние или вид операции.
Логически управляющий процесс есть некий командный пункт, реагирующий на изменения внешних условий, передаваемые ему с помощью управляющих потоков, и продуцирующий в соответствии со своей внутренней логикой выполняемые процессами команды;
узел изменения типа - поток данных является входным для этого узла, а управляющий поток - выходным. Например, поток данных «скорость машины» в отдельных случаях может использоваться как управляющий для контроля критического значения.
Таким образом, разработчики моделей БП пришли к выводу, что простейшим способом стандартизации такой работы является введение в обращение правил графического изображения БП и интерпретации этих
графических изображений. Эти правила, естественно, должны признаваться тем или иным авторитетным сообществом. Такой способ стал наиболее эффективным с появлением первых программных инструментов, автоматизирующих деятельность команд модельеров, объединяющих усилия в рамках одного проекта. Реализаций рассматриваемого способа довольно много, и они в основном ассоциированы с конкретным CASE-средством. Однако, уже сейчас можно говорить о некоторых исторически подтвержденных мета-тенденциях.
Сравнение существующих инструментов - крайне трудный процесс в виду сложности инструментов и наукоемкости идей, заложенных в них. Объективная слабость сравнительных мотивировок, приводимых специалистами в области реинжиниринга бизнес-процессов обусловлена трудностью или нецелесообразностью овладения в совершенстве более чем одним инструментом организационного проектирования. По этой же причине мнение такого специалиста - лишь отражение степени совместимости его мировоззрения, сформированного опытом ни одного года работы .
Сейчас можно говорить о двух основных направлениях развития инструментов организационного проектирования. Одно выражается в создании условий, снижающих степень свободы проектировщика. Это - определение жестких стандартов оформления умозаключений, обеспечивающих приемлемое взаимопонимание разработчиков и пользователей инструментов, поддерживающих весь проектный цикл, но не позволяющих «творить» так, как нам хочется. Другое - охватывает лишь отдельные фрагменты проектного цикла и направлено на представление сервиса для выражения «творческих» взглядов на проектирование организационных процессов. Другими словами, два подхода различаются количеством стандартных отношений, которые представляет программная среда для описания организационных процессов.
Попытка сравнения некоторых характеристик и особенностей описания бизнес-процессов, реализованных в программном продукте Rational Rose фирмы Rational Software, и продуктах, основанных на методологии IDEF0, наиболее распространенным из которых на российском рынке является BPwin корпорации Computer Associates позволяет сделать вывод, что первая система относится к категории «творческих», а вторая «жестких».
Поскольку характерные компоненты «жестких» систем, основанных на IDEF и DFD ,были подробно рассмотрены выше, остановимся подробнее на характерных особенностях «творческой» Rational Rose. Rational Rose не поддерживает ни одну из известных методологий моделирования и анализа бизнес-процессов. Методика построения так называемых «бизнес-моделей», содержащаяся в дополнительном наборе рекомендаций или методике RUP, которая сопровождает пакет Rational Rose, предлагает диаграммы Use Case и Activity для описания бизнес-процессов. Однако автор убежден, что эти диаграммы позволяют описать лишь малую часть сведений, которые нужны для моделирования бизнес-процессов и которые представляются средствами IDEF0. Кроме того, дуги Use Case и Activity диаграмм не имеют тех смысловых типов, которые были указаны для дуг IDEF0. Синтаксические соглашения, диктуемые системой при разработке Use Case и Activity-диаграмм, не объединены в законченную систему; этим диаграммам не дается никакой интерпретации, объясняющей, как их применять при моделировании.
По этим причинам пользователям Rational Rose при разработке Use Case и Activity-диаграмм приходится придумывать свои оригинальные синтаксические соглашения и давать свою интерпретацию имеющимся, чтобы отразить всю существенную для анализируемого процесса информацию.
Другими словами, пользователь Rational Rose вынужден разрабатывать свои «формализмы» для получения методики построения моделей и анализа бизнес-процессов .
Существуют и российские программные средства основанные на использовании CASE-технологий, например отечественный пакет - CASE.аналитик.
CASE.Аналитик представляет собой графическую систему класса CASE (Computer Aided Software/System Engineering), работающую под Microsoft Windows 9.X. CASE.Аналитик предоставляет следующие возможности;
средства для функционального моделирования системы с помощью диаграмм потоков данных;
автоматическое ведение базы данных проекта;
автоматическая верификация проекта, контроль целостности и полноты;
современный графический интерфейс;
ясное и строгое описание системы (спецификации системы);
средства презентации проекта, например, диаграммы размером 2x2м (на любом принтере);
автоматическая генерация документации на проект по ГОСТ 19.XXX и 34.XXX;
более 40 видов отчетов и протоколов.
Окно диаграмм является основным рабочим окном программы в том смысле, что оно определяет текущую диаграмму проекта и не может быть закрыто. В окне диаграмм можно создавать и редактировать диаграммы. Новая диаграмма может быть создана только при детализации (декомпозиции) какого- либо узла на текущей диаграмме. Таким образом, все диаграммы автоматически формируют иерархическое дерево проекта .
Каждая диаграмма проекта может быть одного из следующих типов:
КД - контекстная диаграмма;
ДПД - диаграмма потоков данных;
ДПУ - диаграмма потоков управления.
Самая верхняя диаграмма проекта - всегда контекстная диаграмма.
Каждый тип диаграммы имеет свою палитру объектов в правой части
окна.
Перечисленные подходы, несмотря на все их многообразие, при организационном проектировании предприятий исходят из принципов целостности, то есть внешняя среда в данных моделях присутствует лишь как внешняя сущность, формирующая входные сигналы (материальные потоки) и замыкающая линии обратной связи.
Однако ранее было показано, что одной из характерных тенденций организационного строительства современных компаний является размытие границ организации, утрата разницы между внутренней и внешней средой корпорации вследствие многочисленных кооперативных связей,
диверсификации, консалтингового и финансового взаимоучастия компаний в деятельности друг друга.
Наиболее ярким проявлением «организационного взаимопроникновения» стал аутсорсинг. О специфике данного экономического явления и возможности использования анализа степени «аутсорсингоприемлемости» при структурном проектировании организаций пойдет речь в еле дуто щем разделе.

5.1.Сущность методологии функционального моделирования
бизнес-процессов (SADT-методологии)

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

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

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

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

SADT -методология (Structured Analysis and Design Technics) получила столь широкое распространение благодаря тому, что ориентирована на комплексное представление структуры материальных, информационных, финансовых и управленческих потоков, отображение организационной структуры.
В силу этого, SADT-методология в большей степени нацелена на реорганизацию всей системы управления, чем другие методологии функционального моделирования, основанные на использовании диаграмм потоков данных, главная цель которых проектирование информационных процессов.

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

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

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

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

Функциональная модель начинается с построения общего описания процесса, которое представляется в диаграмме нулевого уровня или контекстной диаграмме (рис. 10).

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

Рис. 10. Контекстная диаграмма

Диаграммы следующих уровней детализируют функции процесса каждого предыдущего уровня. Так, функциональный блок А0 декомпозируется на совокупность взаимосвязанных подфункций А1, А2, А3, … (рис. 11). В свою очередь, каждый функциональный блок 1-го уровня может быть декомпозирован на совокупность подфункций, например А2 на А21, А22, А23, А24 ... и так дальше, пока на последнем уровне не получатся элементарные действия. На каждом уровне рекомендуется размещать не более 6 функциональных блоков. Число уровней декомпозиции не ограниченно. Обычно для структурного анализа бизнес-процессов достаточно 2–3 уровней декомпозиции, последующие уровни декомпозиции требуются для алгоритмизации информационных процессов и разработки инструкций для исполнителей бизнес-процессов.