IDEF0. Знакомство с нотацией и пример использования

Управление - Бизнес-процессы

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

 Одна картинка стоит тысячи слов

Народная мудрость

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

Несколько слов о преимуществах графики

Как известно, функциональные модели IDEF0 — это всегда графические схемы. У них есть свои особенности и правила составления. Об этом мы поговорим чуть-чуть позже. А сейчас я хотел бы привести пару примеров эффективности графики. Почему я делаю на этом акцент? Скорей всего, после моего утверждения о необходимости функциональной модели работы компании, очень многие подумали, что это все необязательно, можно и на словах пояснить как работает та или иная функция в компании. Вот об этом я и хочу поговорить.

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

А потому идея Сытина была поистине революционной — он начал печатать литографические копии карт с обозначением укреплений и расположений воинских частей. Назывались эти карты “Для читателей газет. Пособие”. Идея оказалась настолько актуальной, что первый же тираж “Пособий” разошелся мгновенно. И потом такие приложения были очень востребованы. Причина очевидна. Графика помогала понять то, что при помощи одних слов разобрать было практически невозможно.

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

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

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

Почему это важно для моей работы

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

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

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

Пример одного из моих отчетов в текстовом виде

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

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

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

Что такое нотация описания бизнес-процессов

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

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

В общем, нотации можно назвать языком программирования при бизнес-анализе

Что такое IDEF0?

IDEF0 — методология функционального моделирования (англ. function modeling) и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является ее акцент на соподчиненность объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временнаL9;я последовательность (поток работ). Википедия

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

Функциональная модель компании

Функциональная модель IDEF0 представляет собой набор блоков, каждый из которых представляет собой «черный ящик» со входами и выходами, управлением и механизмами, которые детализируются (декомпозируются) до необходимого уровня. Наиболее важная функция расположена в верхнем левом углу. А соединяются функции между собой при помощи стрелок и описаний функциональных блоков. При этом каждый вид стрелки или активности имеет собственное значение. Данная модель позволяет описать все основные виды процессов, как административные, так и организационные.

Стрелки могут быть:

  • Входящие – вводные, которые ставят определенную задачу.
  • Исходящие – выводящие результат деятельности.
  • Управляющие (сверху вниз) – механизмы управления (положения, инструкции и пр).
  • Механизмы (снизу вверх) – что используется для того, чтобы произвести необходимую работу.

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

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

IDEF0 – это очень простой и одновременно наглядный язык описания бизнес-процессов. С помощью этого стандарта возможна передача информации между разработчиками, консультантами и пользователями. Стандарт очень тщательно разрабатывался, он удобен для проектирования, универсален. Для работы с ним существует множество инструментов, например, VISIO, BPWIN, ERWIN, Bussines studio и т.д.

Кроме того, использование для создания бизнес-моделей IDEF0 — это не только удобно, это еще и правильно. Этот инструмент был разработан для бизнес-аналитики, он прошел длительную и тщательную отладку и шлифовку. А потому при помощи IDEF0 создать функциональную модель без ошибок намного проще, чем без применения этого стандарта.

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

Пример создания функциональной модели IDEF0

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

Основной блок – «Написать статью».

Пример описания функциональной модели верхнего уровня

Входящие стрелки – «Опыт», «Информация из сторонних источников». Это те вводные, которые необходимы для начала работы.

Управляющие для написания статьи – это «План публикации», «Требования издателя», «Правила русского языка».

А в роли «Механизмов» выступают автор, копирайтер, корректор и программное обеспечение. В данном случае автор создает аудиоматериал, в котором собирает все мысли и идеи, которые должны быть отражены в статье. Копирайтер – это человек, который создает на основе этого материала, руководствуясь требованиями издателя, планом публикации и правилами русского языка, готовый текст статьи. Корректор проверяет материал на ошибки. А программное обеспечение – это те инструменты, которые используют в работе все участники процесса.

Таким образом, я задал основные параметры процесса, его вход, выход, а также все необходимое для успешного проведения процесса. Но это – только основные рамки процесса. Так описывается общая схема работы компании в целом.

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

В нашем случае работа делится на 4 основных этапа:

  1. Подготовить аудио.
  2. Подготовить текст
  3. Подготовить текст к публикации.
  4. Разместить статью в издании.

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

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

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

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

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

Такое моделирование не только наглядно, но и очень удобно для принятия эффективных управленческих решений. Например, в описанном выше бизнес-процессе есть два отдельных специалиста — копирайтер и корректор. Если я поставлю задачу оптимизировать финансирование проекта, то я благодаря схеме сразу увижу, где это и как можно сделать. Так, к копирайтер и корректор пользуются примерно одинаковыми правилами, но копирайтер получает аудио, а выдает результат в виде текста, корректор же и принимает, и отдает текст. А потому при необходимости я могу, скажем, за половину стоимости обязанности корректора предложить копирайтеру. Так я сэкономлю средства и время на взаимодействие разных специалистов. Конечно, я понимаю все заслуги корректоров и почему лучше работать с отдельным специалистам. Но напоминаю — у меня стоит задача: оптимизация затрат.

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

Как создавать нотации IDEF0

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

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

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

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

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

Требования стандарта IDEF0

Базовые требования стандарта IDEF0, в принципе, я описал выше и показал на примере.

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

Стандарт IDEF0 включает в себя также общепринятые обозначения, правила, требования к блокам диаграмм, имеет собственную семантику. Подробно ознакомиться с ними можно в документе «Методология функционального моделирования IDEF0».

Типичные ошибки

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

Использование различных цветов

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

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

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

Слишком большое количество блоков

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

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

Нарушение структуры при внесении корректировок

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

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

Правила названия управляющих элементов и блоков

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

Чаще всего ошибки допускают при названии блоков. Например, вместо «Создать статью» пишут «Создание статьи». Блоки в данном подходе – это действия, а потому они должны быть всегда глаголами.

Выгоды использования IDEF0

  • Самая первая выгода очевидна – это наглядность. Вы сами начинаете понимать, как работает та или иная система, и можете также наглядно пояснить, где в этой системе «тонкие места» и как ваши решения помогут избавиться от них.
  • Взаимопонимание и отсутствие разночтений. При обсуждении работы компании с использованием функциональной модели у вас имеются наглядные и понятные интуитивно блоки задач с управляющими элементами. Кроме того, функциональное моделирование предполагает создание в случае необходимости глоссария, в котором раскрываются условные обозначения и термины. В результате вы с клиентом, руководителем, другими сотрудниками при обсуждении проблемы говорите на одном языке.
  • Простота и высокая скорость создания модели. Конечно, научиться моделированию не так просто, как кажется. Ведь схема — это, по сути, сверхплотная подача информации, что очень хорошо для понимания, но для реализации такой подачи требуется особый подход. Мозг аналитика выступает в данном случае как очень мощный пресс с одной стороны, и фильтр – с другой. Но с опытом этот процесс становится очень быстрым. В результате вы получаете инструмент, который поможет и самому разобраться, что же происходит в той или иной системе, и при помощи созданного в сжатые сроки наглядного пособия проиллюстрировать важные моменты коллегам или заказчикам.
  • Дисциплина и отсутствие ошибок. Стандарт IDEF0 предполагает строгие рамки и правила. Такой подход дисциплинирует, а привычка действовать в рамках стандарта помогает избежать ошибок по невнимательности. Любые нарушения стандарта становятся сразу заметны.

В чем трудность применения IDEF0

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

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

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

См. также

Комментарии
1. Андрей Скрылев (SkrAn) 1 29.06.17 06:17 Сейчас в теме
Можно еще один пример для наглядности. Какой нибудь сферический БП в организации, в вакууме. Допустим кадровая докладная - согласование, регистрация, рассмотрение.
2. Николай Больсунов (boln) 974 29.06.17 11:34 Сейчас в теме
Имеется классическая книга по теме:
"Дэвид А. Марка и Клемент МакГоуэн. МЕТОДОЛОГИЯ СТРУКТУРНОГО АНАЛИЗА И ПРОЕКТИРОВАНИЯ SADT"

Но, по имеющейся информации, методология SADT (IDEF0) не получила почему-то широкого распространения.
3. Виталий Попов (Сурикат) 170 29.06.17 11:39 Сейчас в теме
А про DFD статью не напишите или про сравнение нотаций? Почему вы используете IDEF0?

И часто ли вы используете иерархические схемы (когда вложение процессов используется)?
4. Рамиль Кинзябулатов (raiml) 621 29.06.17 12:06 Сейчас в теме
(3) Сравнение нотаций семейства IDEF0 не имеет смысла, так как цели их использования различны.

И часто ли вы используете иерархические схемы (когда вложение процессов используется)?

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

Имеется классическая книга по теме:
"Дэвид А. Марка и Клемент МакГоуэн. МЕТОДОЛОГИЯ СТРУКТУРНОГО АНАЛИЗА И ПРОЕКТИРОВАНИЯ SADT"

Классическая ?

Но, по имеющейся информации, методология SADT (IDEF0) не получила почему-то широкого распространения.

У кого имеется и откуда взялась?
5. Николай Больсунов (boln) 974 29.06.17 12:35 Сейчас в теме
(4)
Классическая ?
По глубине изложения материала вполне может претендовать. Если у Вас есть на примете другая книга под это определение, пожалуйста, предложите.

У кого имеется и откуда взялась?
Из литературы. Я занимался моделированием около 10 лет назад, изучал разные источники. Очень мало было отсылок к SADT. Хотя мне самому эта методология очень нравится - строгость и простота.
6. Рамиль Кинзябулатов (raiml) 621 29.06.17 12:42 Сейчас в теме
(5)
По глубине изложения материала вполне может претендовать. Если у Вас есть на примете другая книга под это определение, пожалуйста, предложите.

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

У кого имеется и откуда взялась?
Из литературы. Я занимался моделированием около 10 лет назад, изучал разные источники. Очень мало было отсылок к SADT. Хотя мне самому эта методология очень нравится - строгость и простота.

10 лет назад...
Изучал самые разные источники...
Очень мало было отсылок к SADT....
Предоставьте пожалуйста аналитику и пруфы.
7. Николай Больсунов (boln) 974 29.06.17 12:44 Сейчас в теме
(6) Здесь не научная конференция. Я высказал субъективное мнение. Не настаиваю, чтобы со мной соглашались.
8. Рамиль Кинзябулатов (raiml) 621 29.06.17 12:47 Сейчас в теме
(7) Вы не делайте таких спорных утверждений и никто не будет вас спрашивать о пруфах. Я вас за язык не тянул.
9. Николай Больсунов (boln) 974 29.06.17 13:11 Сейчас в теме
(8)
Вы не делайте таких спорных утверждений и никто не будет вас спрашивать о пруфах. Я вас за язык не тянул.
Вот, например, точка зрения, с доводами об ограниченной применимости SADT:
http://www.interface.ru/fset.asp?Url=/case/defs92.htm
10. Рамиль Кинзябулатов (raiml) 621 29.06.17 13:22 Сейчас в теме
(9) И что вы этим хотели сказать?
35. Сергей Космачев (ksnik) 276 16.03.18 11:49 Сейчас в теме
(3) сравнение различных нотаций есть в Конспекте лекций по курсу «Автоматизированные информационные системы» https://infostart.ru/public/139095/ на этом сайте
11. Петр Малыгин (pm74) 105 29.06.17 14:56 Сейчас в теме
12. Сергей Беликов (HAMMER_59) 34 30.06.17 07:52 Сейчас в теме
Очень странный подход к описанию стандарта IDEF0, как уже было написано в одном из комментариев, у стандарта есть другое название SADT - методология структурного анализа и проектирования.
Мягко говоря очень странное утверждение, что при использовании SADT получится не 400 страниц техзадания, а компактное графическое представление.
При использование методологии SADT получится не 400 страниц техзадания, а 500, т.к. методология SADT это не только и не столько графическое представление.

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

Очень странно что в статье нет ничего про особенностью человеческого мышления, в особенности про краткосрочную память, а ведь именно на этом и построена вся методология SADT. 15 умножить на 17 многие ведь смогут в уме, а 15 на 173, уже ошибки пойдут, а 158 на 173 - а в чем проблема операция то ведь одна и та же, умножай да складывай простая ведь задача?"

Отдельно мне понравились комментарий что SADT не прижилась, за унифицированным языком моделирования UML будущее, мне вот интересно сами то пробовали применить RUP на практике? Очень интересно как у вас это получится применить язык созданный для ООП, к среде разработке которая не является ООП.
13. Сергей Беликов (HAMMER_59) 34 30.06.17 08:11 Сейчас в теме
(12)Правильная ведь мысль была в статье, что вот было 400 страниц, и с этим невозможно работать.
Но примеры в статье мне напомнили сдачу дипломных работ.
У всех простейшие блок-схемы. И зачем эти схемы если у вас всего 4 действия и 6 входных данных?
Смысл то как раз в том, когда на входе 50 входных данных, и 30 действий, вот тогда нужно применять синтез.
Кроме того у всех на дипломной, такой замечательный и линейный процесс, ну как в книжках, из этого блока в этот.
Такого в реальной жизни, в принципе не бывает, всегда есть различные варианты.

Если не изменяет память, в книгах у Вендрова, есть более жизненные примеры, вот там кадр дня (все документы, действия), из него получается очень не маленькая табличка, и самих табличек получается не мало и вот с этим надо уже надо работать, вот и попробуйте туда свой UML прицепить.
14. Николай Больсунов (boln) 974 30.06.17 09:18 Сейчас в теме
(12) Согласен, только Вы смешали посты разных авторов.
Отдельно мне понравились комментарий что SADT не прижилась, за унифицированным языком моделирования UML будущее, мне вот интересно сами то пробовали применить RUP на практике? Очень интересно как у вас это получится применить язык созданный для ООП, к среде разработке которая не является ООП.
Про SADT и UML говорили разные люди. И я не вижу, чтобы кто-то здесь говорил про UML как альтернативу SADT.
15. Сергей Беликов (HAMMER_59) 34 30.06.17 10:50 Сейчас в теме
(14) Почитал конкретно ту статью, которую вы выложили.
Вкратце, диаграммы потоков данных лучше чем SADT, потому что потому.
Никогда не видел, чтобы DFD где-то применялись, слабо себе представляю практическое применение, разве что как нижний уровень в SADT моделях.

Может, дадите ссылки на какую-нибудь более детальную информацию по DFD.
16. Николай Больсунов (boln) 974 30.06.17 11:19 Сейчас в теме
(15)
Почитал конкретно ту статью, которую вы выложили.
Вкратце, диаграммы потоков данных лучше чем SADT, потому что потому.
Не согласен, там есть вполне конкретные тезисы. Например, такие:
Методология SADT успешно работает только для реорганизации хорошо специфицированных и стандартизованных западных бизнес-процессов, поэтому она и принята на Западе в качестве типовой. Например, в Министерстве Обороны США десятки лет существуют четкие должностные инструкции и методики, которые жестко регламентируют деятельность, делают ее высокотехнологичной и ориентированной на бизнес-процесс. В российской действительности с ее слабой типизацией бизнес-процессов, их стихийным появлением и развитием, разумнее ориентироваться на методологию организации и/или реорганизации потоков информации и отношений: для таких задач методологии, основанные на потоковых диаграммах, не просто допустимы, а являются единственно возможными.

SADT-диаграммы значительно менее выразительны и удобны для моделирования систем обработки информации (сравните рис. 9.1 и 9.4). Так, дуги в SADT жестко типизированы (вход, выход, управление, механизм). В то же время применительно к системам обработки информации стирается смысловое различие между входами-выходами, с одной стороны, и управлениями и механизмами, с другой: входы, выходы и управления являются потоками данных и/или управления и правилами их трансформации. Анализ системы при помощи потоков данных и процессов, их преобразующих, является более прозрачным и недвусмысленным.

Более того, в SADT вообще отсутствуют выразительные средства для моделирования особенностей систем обработки информации. DFD с самого начала создавались как средство проектирования информационных систем (тогда как SADT - как средство проектирования систем вообще) и имеют более богатый набор элементов, адекватно отражающих специфику таких систем (например, хранилища данных являются прообразами файлов или баз данных, внешние сущности отражают взаимодействие моделируемой системы с внешним миром).
По крайней мере, если Вы с этим не согласны, здесь есть конкретно чему можно возразить, а не просто "потому что потому". Это книга Г. Калянова "Консалтинг при автоматизации предприятий", у меня есть бумажное издание. Хотя мне самому субъективно ближе SADT, но мне его доводы кажутся весомыми. Вероятно, как Вы сказали, SADT - на верхнем уровне, DFD - на нижнем. И думаю, SADT можно вытащить в ТЗ, заказчик поймет, а вот DFD - больше для внутреннего применения разработчиков.
HAMMER_59; +1 Ответить
17. Николай Больсунов (boln) 974 30.06.17 11:29 Сейчас в теме
(15) Вот, выкопал ссылку на начало книги, там до нее трудно добраться :)
http://www.interface.ru/fset.asp?Url=/case/defs0.htm

Упомянутая Вами книга Вендрова мне нравится, но, по моим ощущениям, она больше учебное, чем практическое пособие. Могу ошибаться, спорить не буду.
HAMMER_59; +1 Ответить
18. Сергей Беликов (HAMMER_59) 34 30.06.17 11:31 Сейчас в теме
(17) Спасибо за ссылку на книгу.
У Вендрова есть разные книги, есть и учебные пособия, есть и практика.
19. Николай Больсунов (boln) 974 30.06.17 11:32 Сейчас в теме
(18) Да, видимо, мне как раз учебник тогда попался.
20. Сергей Беликов (HAMMER_59) 34 30.06.17 12:20 Сейчас в теме
Попробую собрать свой поток мыслей, и изложить.
Методологию я предпочитаю назвать SADT - методология структурного анализа и проектирования - это изначальное название, потом уже когда включили в ISO методологии дали аббревиатуру IDEF0.

Какую проблему помогает решать SADT. SADT помогает решать сложные задачи, т.е. все эти простые примеры они бессмысленны, точно также как примеры по ООП.

Что же такое сложная задача?
Рассмотрим всем понятный пример (хотя, я не уверен, что это статья для 1С специалистов). Например, нам нужно написать обработку проведения документа.
Если алгоритм проведения простой, к примеру, необходимо сделать записи в регистр накопления, мы все это реализуем в одной функции.
Но чем будет сложнее алгоритм проведения, тем мы больше будем стремится к декомпозиции, а также объединению переменных, например в списки значений. Есть, конечно, любители писать процедуры в которых тысячи строк (ещё и гордятся этим), хорошо если такой код будет работать без ошибок, но самое страшное настанет, когда придется вносить какие-либо изменения в алгоритм, спустя длительный промежуток времени. Разобрать такой код, как правило не может, даже сам автор, проще заново переписать.
В чем же проблема больших функций?
Краткосрочная память человека сильно ограничена, пишут про магическое число 7, иногда указывает диапазон 5-8, например, в методологии SADT , всего столько ячеек памяти. А чем больше процедура тем больше в ней переменных и непосредственно самого кода.
Опять вспомнил сдачу диплома, на каждой второй схеме десятки входных данных в какой-либо блок, проверяют научные работник и отличные отметки ставят, главное ведь на .NET (а если на SAP, тем сразу почёт и уважение) пишут да ещё интернет решение, а 1С-ков всех жестко валят.

С бизнес-процессами на предприятии ситуация обстоит примерно также. Пока бизнес-процессы небольшие - никаких проблем, но как только попадается большой бизнес-процесс для которого написаны десятки регламентов, в котором участвуют различные отделы, вот с этого момента и начинаются настоящие проблемы. Т.к. каждый видит только свою узкую область, а охватить всю задачу целиком, становится крайне сложно.
По следующим причинам:
- Очень много параметров, что осложняет переключение контекста;
- Очень много процессов. Часто в примерах изображают линейный бизнес-процесс, взяли гайку, взяли болтик, прикрутили получилась гайка с болтиком (I have a pen Ihave an aple, ooop I have panaple....). Но в реальности все не так.

Что же делать со всей этой кучей регламентов?
На мой взгляд, все-таки основная работа это не анализ (декомпозиция), а как раз наоборот синтез.

Удивляет меня простота, о которой пишет автор публикации. Пришел, нарисовал, всем понятно, все счастливы.
Типичная работа.
Указание фин. директора: "Разберись с отрицательными остатками по партиям, а также с нулевыми остатками по количеству, но при этом не нулевыми остатками по стоимости"
Какие 400 листов ТЗ? Одна простая фраза.
Начинаем разбираться, смотрим сколько документов работает с партиями - уже не кисло.
Приход, Распределение расходов, Расход - вроде не так все сложно.
Пока не доходит дело до редактирования документов задним числом.
При этом фин. директор стоит на том, что быть такого не может, чтобы что-либо редактировали задним числом.
Ловим за руку (и это не так быстро как звучит), получаем ответ, того же фин. директора: "Ну нам ведь надо". Все врут (Доктор Хаус)
И вот у нас уже схема многократно разрастается, в которой уже никто и ничего понять не может, а главное не хочет.

Ведь так приятно и просто звучит: "Избавься от нулей и отрицательных остатков в партиях". Зачем же всё усложнять?
vardeg; user597616_i.d.kravchenko; +2 Ответить
21. Владимир Очаковский (leobrn) 94 03.07.17 12:07 Сейчас в теме
Скажите, пожалуйста, какие инструменты используете для моделирования BPMN и IDEF0?
24. Рамиль Кинзябулатов (raiml) 621 05.07.17 23:44 Сейчас в теме
(21) BPMN.IO и ERwin
(22) И каким же требованиям времени она не соответствует
(23) UML нельзя сравнивать с IDEF0
26. Kravchenko_Ivan Кравченко (user597616_i.d.kravchenko) 06.07.17 11:19 Сейчас в теме
(24) Я говорю о том, что целесообразно использовать объектные методологии проектирования. В качестве аналога IDF0 - use case. На мой взгляд можно более детально описать бизнес - процесс ... Есть возможность представить различные отношения между кейсами. Опять же в вариантах использования можно более наглядно декомпозировать конкретный процесс.

Коллеги, не в оправдание, но я просто хочу сказать, что мне более удобно использовать нотацию UML. Если кто - то до сих пор использует структурную методологию для проектирования - почему бы и нет =)

"UML нельзя сравнивать с IDEF0" - согласен. Скорее стоит все таки сравнивать в общем структурный подход и объектный. Цель обоих нотаций - наглядное описание бизнес - процесса, разве нет?
28. Николай Больсунов (boln) 974 06.07.17 12:42 Сейчас в теме
(26)
Я говорю о том, что целесообразно использовать объектные методологии проектирования. В качестве аналога IDF0 - use case. На мой взгляд можно более детально описать бизнес - процесс ... Есть возможность представить различные отношения между кейсами. Опять же в вариантах использования можно более наглядно декомпозировать конкретный процесс.
Я полагаю, что диаграмма usecase - это скорее некая альтернатива DFD, чем SADT. И она, как мне представляется, элемент языка разработчиков, но не элемент техзадания, которое должен понимать также и заказчик.

Как Вы полагаете, целесообразно ли включать диаграммы прецедентов (вариантов использования) в ТЗ? Не покажутся ли они заказчику детскими картинками, и, главное, желает ли заказчик знать, что, например, такое "актант" и что такое отношение "расширяет"? Он бизнесмен, эти понятия не его сфера, деловые люди "грузиться" не любят. У заказчика может возникнуть подозрение, что ему морочат голову, а на этапе согласования ТЗ это крайне опасно для исполнителя.

А если показать заказчику диаграмму SADT, то, скорее всего, он больше заинтересуется и поймет. Эта диаграмма очень проста и строга. Вход, Выход, Управление, Механизм - что это такое, человек въезжает сразу, с полоборота, это интуитивно понятные термины. И, как я считаю, вести разговор в контексте схемы SADT с заказчиком будет намного проще и свободнее. Заказчик сможет оценить, правильно ли разработчик понял схемы бизнес-процессов предприятия и внести соответствующие коррективы.

А после согласования ТЗ с использованием SADT можно уже начинать проектирование - с составления диаграммы вариантов использования. А можно перед этим на бумажках нарисовать себе и DFD - если это сделает картину более прозрачной, а потом уже определять usecase'ы. Ну, а от них далее, к концептуальной модели - тут уже начинается "объектная" стадия проектирования...

Кстати, ведь диаграммы вариантов использования - это "дообъектная" стадия проекта, там еще никаких сущностей не выявляется. Только прецеденты. Так что со "структурными" диаграммами их совместить можно :)
29. Kravchenko_Ivan Кравченко (user597616_i.d.kravchenko) 06.07.17 13:18 Сейчас в теме
(28)

Николай, не холивара ради ... не везде могу с вами согласится =)

Попробую конкретизировать.


Я полагаю, что диаграмма usecase - это скорее некая альтернатива DFD, чем SADT.

Опять же не соглашусь. В качестве аналога DFD я бы представил диаграмму деятельности (activity diagram).

"Как Вы полагаете, целесообразно ли включать диаграммы прецедентов (вариантов использования) в ТЗ?"

Все зависит от того, знаком - ли заказчик с нотацией. В моей практике бывали случаи, когда от заказчика поступало "ТЗ", где описание было представлено в usecase. Не обязательно представлять сложные отношения между кейсами для поверхностного описания бизнес - процесса.


"А если показать заказчику диаграмму SADT, то, скорее всего, он больше заинтересуется и поймет. Эта диаграмма очень проста и строга. Вход, Выход, Управление, Механизм - что это такое, человек въезжает сразу, с полоборота, это интуитивно понятные термины."

Знаете, вполне может быть. Та же IDF3 выглядит интуитивно понятно. Хотя я сейчас я редко встречаю практическое применение ....

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

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

Поймите правильно, не хочется спорить ради спорта. Если есть успешная практика применения структурного подхода, в частности SADT- это хорошо. Меня просто удивило то, что сейчас вообще данную нотацию (если хотите "методологию") вообще вспомнили=) Я с ней последний раз очень давно сталкивался.
30. Николай Больсунов (boln) 974 06.07.17 13:48 Сейчас в теме
(29) Да нет, Иван, я тоже не имею желания развязывать холивар. Я прочитал Ваши возражения и тоже подумаю над ними.

Холивар "объектное - структурное", на мой взгляд, не имеет под собой основания. Я полагаю, эти подходы можно "подружить" - в том смысле, что на верхнем уровне, на этапе согласования ТЗ, может пригодиться структурный подход. Я исхожу из пессимистического варианта - заказчик не знаком с UML, не владеет его понятийным аппаратом. Если владеет - это вообще подарок... Но, если у него экономическое образование, то это ему ни к чему. Т. е. для "непосвященных" считаю более понятными модели SADT.

Поэтому я и сказал "теплое с мягким": UML и SADT - они о разном, и второе может помогать первому.

А на этапе разработки с SADT можно только сверяться, чтобы сильно не уйти от согласованного с заказчиком бизнес-процесса.

Мне очень нравятся книги Крэга Лармана по UML-разработке. Ну, и классика - книга "трех друзей" на эту тему.
user597616_i.d.kravchenko; +1 Ответить
31. Шевченко Владислав (ofshadows) 07.07.17 11:58 Сейчас в теме
(21) у предшественников хватило ума купить Business Studio. За неимением лучшего в ней и работаем.
Должен сказать, что производит впечатление сырой восьмерки (1с8), но для бизнес- процессов.
22. Dmitry Semenov (dima1c) 25 03.07.17 17:44 Сейчас в теме
мне кажется это все уже устарело.
сейчас другой мир уже..
user597616_i.d.kravchenko; +1 Ответить
23. Kravchenko_Ivan Кравченко (user597616_i.d.kravchenko) 05.07.17 10:22 Сейчас в теме
Наистарейшая нотация. Не могу представить, где в современном мире моделируют на IDF или DFD и пр. Инструментов - то нету толком уже ....

Коллеги, курите UML нотацию)
25. Николай Больсунов (boln) 974 06.07.17 06:26 Сейчас в теме
(23)
Наистарейшая нотация. Не могу представить, где в современном мире моделируют на IDF или DFD и пр. Инструментов - то нету толком уже ....

Коллеги, курите UML нотацию)
А курить-то надо бросать ;)
Тогда, может, и не будем сравнивать тёплое с мягким.
27. Kravchenko_Ivan Кравченко (user597616_i.d.kravchenko) 06.07.17 11:30 Сейчас в теме
(25)
А курить-то надо бросать ;)
Николай, я лишь хотел сказать, что для описания бизнес - процесса при разработки (например) программных средств наиболее удобно, с моей точки зрения использовать вместо структурного подхода объектно - ориентированный. В частности я предложил использовать нотацию UML. На мой взгляд у объектного подхода есть все таки преимущества в описании.
32. Дмитрий Н (Nehc) 17 26.07.17 11:34 Сейчас в теме
Интересно, только у меня картинки не открываются, или у всех так? ;)

Отдельный вид мазохизма - читать статью по IDEF0, без иллюстраций!
33. Дмитрий Н (Nehc) 17 26.07.17 11:38 Сейчас в теме
34. Николай Больсунов (boln) 974 26.07.17 11:44 Сейчас в теме
(32) Да, картинки в статье почему-то перестали грузиться. Раньше нормально было.
36. Иван Филимонов (DarkAn) 713 29.03.18 16:06 Сейчас в теме
Оставьте свое сообщение