Пока народ готовится праздновать НГ и РХ., ххочу озадачить почтенную публику вот каким вопросом.

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

1. число блоков при декомпозиции должно быть 3-6 (хотя допустимо до 8, а минимум естественно 0).
Все это обусловленно сверху особенностями человеческого мышления оперировать не более 5-9 объектами одновременно и логикой, что декомпозиция в 2 блока и менее бессмысленна.
Однако часто сталкиваешься с стуацией, когда приходится вынужденным образом создавать 3 блок

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

3. Завершение декомпозиции несовсем ясно, хотя у Рубцова(IDEF0/Doctor) можно подметить, что декомпозицию следует завершать, когда блок генерирует один (или несколько но связанных общим смыслом) выход, т.е. когда о процессе формирования выхода можно в общем догадаться:
пример Обработать деталь -
на выходе готовая деталь и Отходы производства детали
против готовая деталь и Ведомость-спецификация себестоимости

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

5 Аналогичная путаница с механизмом - в опеределение есть - это нерастрачиваемый или условно не растрачиваемый ресурс.

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

Читая разные книги, стандарты и прочее сталкиваешься с большими противоречиями и отличной отмазкой - все определяется точкой зрения!!!

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

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

darco, было это давно, и я уже основательно забыл, что послужило толчком.

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

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

Естественно в случае например банковских операция деньги могут быть входом, но вопрос а во что они преобразуются например в другую валюту, но если мы рассматриваем деньги как абстаркцию, то что сосбвтенно с ними происходит? смена владельца и все

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

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

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

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

Встречный вопрос: по какому источнику Вы изучаете IDEF0?
Управление, вообще говоря, реализуется через обратную связь, причем это не в терминах IDEF0, а согласно общей теории управления. Ищите термин "цикл управления".
"В методологии SADT требуется только пять типов взаимосвязей между блоками для описания их отношений: управление, вход, обратная связь по управлению, обратная связь по входу, выход-механизм."
Почитайте об этом в книжке Дэвида А. Марка и Клемента МакГоуэна "Методология структурного анализа и проектирования"

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

Кстати, Вы неверно отвечаете на вопрос о цели? Правильный ответ кроется где-то между "повысить эффективность взаимодействия кадровой службы и бухгалтерии" и "экономией бумаги при выпуске кадровых приказов" :о))

P.S. кнопочка "зарегистрировать приказ" - операция, являющаяся составной частью одноименной функции.

Распишу ситуацию. В данный момент я занимаюсь программированием. Хочу сменить специализацию на аналитика. В качестве практики решил описать по стандартам одну из систем, разработанных мной. Может, мне мешает "программистский" взгляд на жизнь? Нарисовал модель данных в ервине. Нарисовал моментально, решил приступить к описанию функций... и застрял. Вот у нас есть функция "регистрация приказа". Это activity? То есть должен быть квадратик с именем "регистрация приказа"? Если так, то что в него должно входить сверху и что снизу?
Я кажется понимаю как расписать юз-кейсы. Кажется понимаю как нарисовать IDEF3. Но решил идти по порядку, начать с IDEF0... может я её неправильно понимаю и применяю?
Читаю Дубейковского - пишет много, и правильно, но непонятно о чём На уровне общих слов понятно, как приложить к делу - непонятно.

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

Ничего страшного. Для этого и форум, чтобы задавать вопросы и получать по возможности ответы.

Начал изучать IDEF0, и совершенно не понимаю, что принимать за управление и за механизм.

Ну для начала скажу, что управление - это то, что управляет , регламентирует, ограничивает. Это тоже вход - но вход управляющий преобразованием входа (input) в выход (output). Например, чертеж - это явное управление в том смысле, что он регламентирует(указывает) как соединять детали.
Механизм или ресурс - то с помощью чего вход преобразуется в выход. При этот механизм не каким образом не входит в выход (хотя может это не совсем так . Молоток - это инструмент, механизм, с помощью которого Вы делаете например стул. Ясно что молоток стачивается, он может изломаться, но это не значит, что он каким-то образом входит в состав выхода.

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

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

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

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

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

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

И вот конкретно в контексте информационной системы я никак не могу понять, когда пользователь нажимает на кнопочку "зарегистрировать приказ" - в чём будет управление и в чём механизм?

Ну в такой ситуации - это может быть подача команды "зарегистрировать", механизмом - сотрудник ОК, ИС кадровой службы ...

Эдуард, не в обиду, посмотри на мой предыдущий пост, ОК?

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

Весьма похвальное желание расти.

Может, мне мешает "программистский" взгляд на жизнь?

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

Нарисовал модель данных в ервине. Нарисовал моментально

Хорошо. Впрочем, это неудивительно.

решил приступить к описанию функций... и застрял. Вот у нас есть функция "регистрация приказа". Это activity? То есть должен быть квадратик с именем "регистрация приказа"?

Да, activity :о)) Да, должен :о))
Тут, правда, есть один (но очень большой) подводный камень, заключающийся в ответе на вопрос: что Вы моделируете?

Если так, то что в него должно входить сверху и что снизу?

А кто сможет ответить на этот вопрос, не зная как это сделано в Вашей системе?
Впрочем, если НЕ привязываться именно к Вашей системе, я могу :о)) В качестве варианта: сверху - инструкция по регистрации приказов, снизу - журнал регистрации приказов, ручка :о))

Я кажется понимаю как расписать юз-кейсы.

Хорошо. Теперь вопрос: как Вы свяжете Ваши юзкейсы с моделями IDEF0?

Кажется понимаю как нарисовать IDEF3.

Хорошо. Опять вопрос: Что это Вам дает?

Но решил идти по порядку, начать с IDEF0... может я её неправильно понимаю и применяю?

Почему именно с IDEF0? Есть масса других методологий, помимо SADT.
Но бог с ним, SADT так SADT, но начните с DFD.

P.S. Читайте первоисточники (ссылка Выше) - будет понятнее и пример есть.

Эдуард, не в обиду, посмотри на мой предыдущий пост, ОК?

Вадим, просто когда я пытался ответить, твоего еще не было письма, А причем тут обида? То что мыслим одинаково - это похвально, значит и научились правильно:)

Читаю Дубейковского - пишет много, и правильно, но непонятно о чём На уровне общих слов понятно, как приложить к делу - непонятно.

Не читайте Дубейковского. Он хороший, но как-то очень многословен. Хотя есть серия его статей на interface.ru. Может поможет?

Но бог с ним, SADT так SADT, но начните с DFD.

А почему лучше с DFD? Почему спрашиваю? По DFD как-то меньше литературы, да и DFD как-то по-тихоньку помер

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

P.S. Получается, что мы не только мыслим одинаково, но уже синхронно.

P.P.S. про DFD. Потому что любая (практически) система автоматизации по сути своей предназначена только для одного - реализации информационных потоков определенного назначения. Т.е. информационный поток первичен. Так что если есть понимание конкретного потока (или наоборот, нужно его получить), то что-то проще DFD (особенно на уровне разработчика системы) придумать сложно. А с функциями, как видно из примера, несколько сложнее, IMHO потому как нужно еще и в определенной структуре их описать.

К тому же в контексте IDEF0 такого понятия как "событие" вроде нет (в отличие, например, от ARIS)

Да события нет, но есть управляющее воздействия, возникающее в результате события

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

Некропостинг про некростандарт  Я бы посоветовал учить BPMN.