Начала учить IDEF0. Столкнулась с проблемой при определении взгляда на модель.
Конкретнее: есть некая система документооборота.
Один и тот же документ рассматривается, корректируется и подписывается на различных уровнях.
Казалось бы, процесс пользователя определяется жизненным циклом документа:
1 Создание документа в отделе А
2 Согласование в отделе В
3 Согласование в отделе С
4 Утверждение в отделе Д
5 Окончательное визирование в отделе, который документ выпустил (отдел А).

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

Насколько логична модель, где используется подход "отдельные функции":
1 создание документа
2 редактирование документа (декомпозиция на удаление, редактирование, добавление)
3 подписание документа.
4 передача документа между отделами ( + выход на вход п.2)

Вроде функции ясны, но ЖЦ сразу исчез! С другой стороны, в первом варианте куда запихать редактирование, удаление и т.д. (не дублировать же)
Описала конечно примерно, чтобы суть была ясна.

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

Не хочу никого обидеть, но если бы американский DoD не требовал от своих подрядчиков в обязательном порядке использовать IDEF, эта нотация давно бы уже почила в бозе IMHO.

Я не обижаюсь. У меня дома есть Process Modeler, и UML-редактор...и BNMP скоро поставлю (жаль ARIS toolset не впечатлил, а его полнофункциональный собрат все ж труднодоступен).
Я думаю не надо играться из серии "это нотация клевая, а это фигня полная".
Если ты только учишься на аналитика, то работа с разными нотациями как-то расширяет горизонт понимания аспектов моделирования.
Если уж вопрос совсем тупой, то извиняюсь..... Мы все учились понемного, когда-нибудь да как-нибудь

Предлагаю почитать например здесь http://dit.isuct.ru/ivt/books/CASE/case8/sadt/gl8.htm

Читала. Пытаюсь понять.
Представьте, что вы утверждаете строительную смету в разных конторах. Документ между организациями передается, подписывается. Блок А0 ясен (утвердить смету). Но  по отношению к документу внутри каждого блока "Согласование в организации А", "Утверждение в организации В"... действия одинаковые. Самое смешное, что функций прилично, но они почти идентичны на всех уровнях ("Сохранение документа", "Анализ документа по отношению к нормативному акту", "Корректировка документа" и т.д.)
1. Модель интересна пользователю, который будет работать с системой (тогда казалось бы лучше вариант 1, где ЖЦ документа).
2. Модель интересна программисту, чтобы видеть все связи функций. Тогда, казалось бы, просто перечень функций и связь между ними. ЖЦ документа не важен. Ведь по сути, с точки зрения программиста, согласование и утверждение это одно и то же (просто меняется организация).

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

Может сумбурно объяснила. Но я как раз не пойму какой подход разумнее.
Или для программиста надо писать свою модель, а для пользователя системы - другую?
Что-то из серии модель и альтернативная модель?
поддерживать актуальность сложно

Начала учить IDEF0. Столкнулась с проблемой при определении взгляда на модель.
Конкретнее: есть некая система документооборота.
Один и тот же документ рассматривается, корректируется и подписывается на различных уровнях.
Казалось бы, процесс пользователя определяется жизненным циклом документа:
1 Создание документа в отделе А
2 Согласование в отделе В
3 Согласование в отделе С
4 Утверждение в отделе Д
5 Окончательное визирование в отделе, который документ выпустил (отдел А).

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

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

Ваша схема в принципе неплоха. Пара штрихов и будет хорошо.

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

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

Насколько логична модель, где используется подход "отдельные функции":
1 создание документа
2 редактирование документа (декомпозиция на удаление, редактирование, добавление)
3 подписание документа.
4 передача документа между отделами ( + выход на вход п.2)

Вроде функции ясны, но ЖЦ сразу исчез! С другой стороны, в первом варианте куда запихать редактирование, удаление и т.д. (не дублировать же)
Описала конечно примерно, чтобы суть была ясна.

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

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

Или вообще не стоит в IDEF0 пытаться это описать?

Стоит-стоит, хорошая тренировка, немного сложновато поначалу, но польза в целом превалирует над затратами.

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

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

Большое спасибо за ответ!
Мне надо чуть-чуть подумать.
Самое смешное, что есть:
* первая заинтересованная сторона (это утверждающая сторона). Она же заказчик программы
* вторая заинтересованная сторона (инициатор документа). Заинтересованная, но средне
* третья незаинтересованная сторона ))). хотела я и для программистов написать модель, чтобы они видели связи между функциями системы.

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

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

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

вот это мнение и пыталась выяснить на форуме! насколько корректно подменять целевые функции (рассмотреть документ с целью ...") простейшими функциями системы (что делает система). Такое желание на секунду возникло.

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

Это была моя жалкая попытка нарисовать для программистов функции системы.
Им же интересно, что после блока "Передать на другой уровень"  документ опять появляется на входе процесса "Рассмотрение документа на предприятии (а уж там декомпозиция на простые функции).

попробуйте сказать сотрудникам отдела А, что они всего лишь редактируют документ - да они Вас загрызть могут :о)))

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